I would like to discuss the possibility of providing cross-compilation support for XMOS processors on Linux, MacOS and Windows. I would welcome any advice for achieving this. The XMOS ‘xcc’ compiler supports C and C++ but also a custom C-like language called XC which has support for concurrency and various real-time chip architecture features built in. The current plan is:
Create a new XMOS platform
Create a new language, XC, for which the default file extension is ‘.xc’
Ensure that C & C++ files, and assembly files with a ‘.S’ suffix are compiled by the ‘xcc’ compiler.
Ensure that assembly files with a ‘.s’ suffix are assembled with the ‘xmosar’ assembler.
Possibly provide support such that, for an executable target named ‘xtarget’, the resulting binary file is called ‘xtarget**.xe**’
Does this sound sensible/consistent with CMake design?
Current questions I have:
What should go into the ‘XMOS’ Platform file? Preliminary work suggests it should exist if I call ‘set(CMAKE_SYSTEM_NAME XMOS)’ but I’m not sure what it should contain. Currently I have an ‘xmos_toolchain.cmake’ file that I include from CMAKE_MODULE_PATH that sets this. Would it make more sense to call ‘set(CMAKE_SYSTEM_NAME XMOS)’ from an XMOS cmake project, and put the current contents of the toolchain file into the Platform file?
Currently, for C, CXX and ASM compiler vars (CMAKE_XXX_COMPILER), we just set those to ‘xcc’ in the current toolchain file. Is that the best way forward, or should I create new compiler and/or assembler definitions?
Will I need separate platform sub-definitions for the host OSes (Linux, Mac, Win)?
If I do this work, what chance is there of it being acceptable/accepted?
I suggest starting with support for the XMOS xcc compiler’s C and C++ language modes along with the Platform/XMOS.cmake module. That shouldn’t involve much new infrastructure and can get you started with the contribution process. Is the xcc compiler based on another compiler that we already support?
After that we could move on to ASM support, and then look at the new XC language last.
What should go into the ‘XMOS’ Platform file?
Can you post your current xmos_toolchain.cmake file? Some parts of it may go in the platform module.
for C, CXX and ASM compiler vars, we just set those to ‘xcc’ in the current toolchain file.
That’s correct.
Will I need separate platform sub-definitions for the host OSes (Linux, Mac, Win)?
Probably not. The Platform/<os>-<id>-<lang>.cmake modules are base on the target <os>, not the host. There may be conditions within those modules based on the host platform though. The Android modules have some IIRC.
Toolchain file attached. A colleague of mine wrote and used it to compile a ‘C’ based project.
I took this file, and in combination with the attached CMakeLists.txt, managed to compile an XC project. To implement the ‘XC’ ‘language’, I took copies of all the required base C compiler files and hacked them until they worked Obviously, from this exercise, I learned that any help I could get would be useful, and that I may have used deprecated features along the way, which obviously I’d like to avoid. Also, I’m sure there’s a lot I’ve left in that is unnecessary.
I sort of came unstuck when trying to compile a real project, because our system code often uses pre-processed assembly files, hence my questions…
I await your comments with interest…
[Edit] I forget to address the other point you made - yes, the compiler is based on gcc, I believe… (though there may be a clang version in the pipeline - either way, yes, it’s based on a compiler you already support).
These will eventually be in Modules/CMakeFindBinUtils.cmake and Modules/Compiler/<id>-FindBinUtils.cmake where <id> is whatever compiler id we use for xcc.
These settings are not public and the public interface that used to set them is deprecated. It’s fine to use them locally for now, but once we get XMOS support integrated this shouldn’t be needed.
set(CMAKE_C_FLAGS “” CACHE STRING “C Compiler Base Flags” FORCE)
set(CMAKE_XC_FLAGS “” CACHE STRING “XC Compiler Base Flags” FORCE)
Hopefully these won’t be needed later either.
set(CMAKE_CXX_FLAGS “-std=c++11” CACHE STRING “C++ Compiler Base Flags” FORCE)
This should be in the CMakeLists.txt file, and should instead be represented by setting CMAKE_CXX_STANDARD to 11.
This will probably go in the platform module, if it is needed at all.
Comments on the CMakeLists.txt file:
There should be a cmake_minimum_required(VERSION ...) call at the very top.
include(xmos_toolchain)
This should not be included in the CMakeLists.txt file. The toolchain file should be specified by the user with -DCMAKE_TOOLCHAIN_FILE=... when creating the build tree.
The first step should be to identify the xcc compiler. Is it based on a common compiler like GNU or Clang?
Thanks for that.
I’ve committed the toolchain file to a repo, so I can keep track of the changes. I’ve basically committed the above, with a minimum cmake version requirement, put in comments on the bits to be removed, and removed the C++ std flags. I’ve then created two other toy repos, of a C and C++ project respectively, and configured and built them with
CMAKE_TOOLCHAIN_FILE=<path to file> cmake -B build && cmake --build build
I thought the compiler was gcc-based, but the output seems to identify it as clang-based? This is sufficient to compile the code correctly but probably confusing for the user (it confused me…). Here’s the output (I’ve remove the XMOS.cmake file from the module path as it doesn’t contain anything useful yet):
$ CMAKE_TOOLCHAIN_FILE=../xmos_cmake_toolchain/xmos_toolchain.cmake cmake --trace-expand --trace-redirect=log.txt --log-level=TRACE -B build && cmake --build build
Running with expanded trace output on.
Trace will be written to log.txt
-- The C compiler identification is Clang 3.6.0
-- The CXX compiler identification is Clang 3.6.0
System is unknown to cmake, create:
Platform/XMOS to use this system, please post your config file on discourse.cmake.org so it can be added to cmake
-- Configuring done
-- Generating done
-- Build files have been written to: /home/davea/sandboxes/xmos_cmake_cxx_example/build
[ 50%] Building CXX object CMakeFiles/example.dir/src/main.cpp.obj
[100%] Linking CXX executable example
[100%] Built target example
$
I’ve done the same thing for a ‘project’ ‘written’ in assembly language. Again, it just kinda works, with the caveat that the output messages are less then perfect:
$ CMAKE_TOOLCHAIN_FILE=../xmos_cmake_toolchain/xmos_toolchain.cmake cmake -B build && cmake --build build
-- The ASM compiler identification is unknown
-- Found assembler: /usr/local/bin/XMOS/XTC/15.1.0/bin/xcc
System is unknown to cmake, create:
Platform/XMOS to use this system, please post your config file on discourse.cmake.org so it can be added to cmake
-- Warning: Did not find file Compiler/-ASM
-- Configuring done
-- Generating done
-- Build files have been written to: /home/davea/sandboxes/xmos_cmake_asm_example/build
Scanning dependencies of target example
[ 33%] Building ASM object CMakeFiles/example.dir/src/main.S.obj
[ 66%] Building ASM object CMakeFiles/example.dir/src/func.s.obj
[100%] Linking ASM executable example
[100%] Built target example
$
@brad.king Thank you… Ok, I’ve created an xmos-platform branch on my fork of the repo from the latest nightly on the main repo, but I’m a little unsure how to proceed from here. Do you want me to add the XMOS.cmake platform file I shared earlier? Currently, it seems that setting the various CMAKE_*_COMPILER variables to ‘xcc’ in the toolchain file is sufficient to get CMake to use the XMOS xcc compiler to build from C, C++ and asm code. Obviously I want to cater for the possibility that someone else with write a compiler for the XMOS architecture, but I’m not sure what I need to do, CMake-wise, to achieve that. Any advice gratefully received…
