Transitioning from older tools releases¶
Users of tools releases prior to 15.0.1 will notice some changes. This page intends to provide a rationale for those changes and help users move rapidly to the 15.0.x series of tools.
The 15.0.x tools releases represent a change in direction for the tools. The new direction is towards:
Use of established, industry-standard tools and techniques where appropriate
Preference of upstreamed changes to 3rd-party open source projects over maintenance of custom versions of the same
Conformance with widely used interfaces, formats and conventions such that users can:
Transition easily from other platforms to the XCore and its tools
Use their own preferred 3rd-party tools
The principal aim is to leverage the very latest advances in toolchain technology, whilst focussing XMOS effort where it can have the greatest impact.
The 15.0.x tools releases mark the beginning of this journey.
The most fundamental change within the 15.0.x tools is the move towards the use of C/C++ instead of XC as the preferred programming language for the XCore. The advantages of using C for XCore programming are:
Less restrictive than XC; specifically, C allows pointers by default
No ambiguity in semantics
Plenty of online support
Familiar to most embedded software developers
Better 3rd-party tool support
There are no fundamental features of the XCore architecture that demand a proprietary programming language.
Writing CSP-style tasks with their own private memory, like those used in XC, remains an excellent approach to parallel programming and the same mental model is recommended when programming in C. The move towards the use of C/C++ retains access to all of the unique benefits of the xcore architecture alongside the latest C and C++ features and fixes.
Existing code written in XC¶
Existing XC source code does not need to be ported to C.
The XC compiler, accessed via the XCC compiler driver, will remain part of the tools release. No date has been set for its removal.
Where a decision is made to port a library to C, users may consider porting only the public API for expediency, rather than the entire library.
The XC compiler itself will be maintained for existing applications and libraries. Feature requests or performance optimisations will not be considered.
For guidance on projects developed within older tools releases, see Migrating existing projects.
All new procedural code should be written in C.
Since the underlying hardware features of the XCore cannot be accessed directly through the C language itself, a new system library lib_xcore is provided. Use of the new library is introduced in the guide: Programming an XCore tile with C and lib_xcore.
Where new C code is required to interact with existing XC code, existing guidance should be followed. See Calling between C/C++ and XC.
Writing multi-tile applications currently still requires the writing of a
minimal declarative XC source file, often called
mapfile.xc as per the
examples: Targeting multiple tiles and Communicating between tiles. The file should not contain
any procedural code, and should contain only the bare minimum to:
Declare a C entry point on each tile
Bootstrap any subsequent inter-tile communications via the switch
Subsequent releases of the tools will provide alternative means of supplying the
declarative information and a corresponding C source code generator. Keeping the
content of the
mapfile.xc purely declarative will ensure that any
migration is straightforward.
The C language does not include equivalents for XC’s
[[combinable]] keywords. Combining tasks onto a single logical core can
now be done manually using collaborative scheduling or, using the power and
functionality exposed by C and lib_xcore, even using an RTOS.
Similarly, the C language does not have an equivalent for XC interfaces which
are accessed via the
interface keyword. Implementation of interfaces and
their underlying transport and protocol can now be performed by the application
developer, allowing greater scope for chosing an implementation appropriate to
the real-time requirements and any resource availabilty constraints.
Users who rely on the XC language protecting them against unsafe concurrent access to shared memory should take appropriate care when programming in the C language. Similarly, care should be taken to ensure that resources are correctly allocated and deallocated before/after use, since such allocation is not handled by the language itself. These are all normal considerations for a C programmer.
Experienced XC users transitioning to C/lib_xcore may find the following resources useful:
The following bookmarks provide a convenient access into the video for later reference:
The presentation used in the video may be downloaded:
In addition, an XC to C Cheat sheet is provided.
The 15.0.x tools do not contain a graphical IDE within the installation package. Instead, the tools are intended to be integrated with the user’s favourite IDE as per the examples in Configuring an IDE. This choice allows users to leverage the very latest IDE technology.
Viewing of offline XSCOPE output is similarly delegated to the user’s preferred VCD viewer. Use of GTKWave is demonstrated in Using XSCOPE for fast “printf debugging”, though other viewers are available.
Migrating existing projects¶
Some very minor changes in configuration files and procedures are required when using tools 15.0.x to develop existing projects whose life began under earlier tools releases. This page collects useful pointers on making the changes.