Søk etter:

← → Started 13May2021. Updated «after that». This note is in group Technology and My XMOS pages. It is about the XMOS tools paradigm shift with C and lib_xcore.

C plus lib_xcore = xC

Of course the below info makes me sad! For myself: I have enjoyed xC so much!

But I am afraid, XMOS probably have got real. xC was a dream. It still is. A soft dream, in hard real-time. But I will try to stick with xC as long as possible, having to have three thoughts in my head at the same time: xC, xCore but also lib_xcore. The latter is the sole reason for this post. Since this version is only at 15.0.6 (first paradigm shift release) – 14.4.1 (last as pure xC) = 0.6.5. After all, I am a HW engineer and rather good at such algebra after quite some years in the field. But alas, I must confess, I also, am a programmer:

My occupational group of programmers is one of the most conservative bunch of people in the world. Albeit, some times for good reasons. But since many probably didn’t think they dared xC (as I in fact did) and the xCore, they got it right in the end. It is so sad.

When a language is required to be even more C than xC, time is up sooner or later up. Especially when the answers xC provided, were not appreciated. When it can be solved in C (plus perhaps some home brewed «RTOS») on an AVR or ATMEGA, who needs xC and xCore? Well, I fit both of those roles. I hoped for some XMOS talks on safety critical, when sound came up. However, both would apply.

XMOS CEO Mark Lippet painted the picture on the wall already more than a year ago 200:[me worry 2].

Quoting from the (as of 12may2021) – new for me – XTC Tools page (here) 15.0.6 release notes (here) I quote:

Enhanced support for programming in C

• Inclusion of the lib_xcore system library and headers marks a shift in emphasis towards programming the xcore in C, rather than XC (My comment: they seem to glide into new spelling «xcore» for «xCore» or even «xCORE». I’ll try to stick to «xCore» until it’s official. It’s a bumpy path to start using camelCase (or was it CamelCase?) for marketing. And now also «XC» for «xC» or «xc»)
• The lib_xcore system library allows equivalents of XC constructs including select{} and par{} to be written without leaving the C language
• XC compiler still included, though it is recommended that new code be written in C (end quote)
• A comment. Have a look at the TIOBE Index (like 016:[10]) and seee where C is compared to «XC» (listed in the «TIOBE Programming Community Index Definition» page). I have noted that on 28Oct2020 XC was #119. In Aug2021, since it does not have a Wikipedia page any more, it doesn’t even qualify. I guess, getting it back on Wikipedia (My lexical attempt at xC) certainly won’t help getting it any higher in usage. So, who’s is most reality oriented here, those of us who love xC or XMOS?

I have had the feeling for some time 200:[What me worrying about the role of xC?]. xTIMEcomposer‘s last update (14.4.1) was released 1.5 years ago (Dec2019). From all the info I read about the xcore.ai there wasn’t anything about xC. All about C. But then, xC has been kind of under-communicated for years, which to some degree masked my worrying. The silent tongue has not slipped. But then, even whispering the x in front of the C probably sounded like a roar to some.

However, a company that has the intellectual capacity to design the xCore architecture, and then ship them by the bucket (Comments:1), might not necessarily have the capacity to keep a non public domain language afloat. The xC compiler tool suite is complicated, I have seen that by observing the behaviour of the black box. I don’t think it has been a smooth voyage for XMOS. I do hope that keeping the lib_xcore afloat might be a less strenuous encounter. They may just have factorised out a set of problems or two, hoping that they then also didn’t add complexity. Or, to help transistion from xC, that they didn’t barber much.

Alfred E. Neuman may just come me to the rescue. Not for supplying smart answers, but for the face of him. I can compile and work with my xC projects for quite some time, I guess. XMOS say so, and seem to mean it: with 15.0.6: xcc --version Build 8-2f98842, Mar-25-2021. There must be some more old customers out there with lots «legacy xC«. (I all of a sudden saw how stupid Alfred is, I didn’t like that term.) However, the XMOS IDE, the xTIMEcomposer (not the binaries) – is the sole reason that I am still at a five years old macOS 10.13.6 High Sierra (Sep 2016) on this machine. After this there were macOS Mojave (Sep 2018), Catalina (Oct 2019) and Big Sur (Nov 2020). I cant’ wait to upgrade to any one of them (Comments:2).

I must admit that I have enjoyed xC as much as the xCore. Almost. Like 49/51? And now I’m able to learn about lib_xcore‘s pooled resources! (Comments:3). Plus choose between several programming models: «Hardware as Software«, «Vector accelerator» (for the new AI additions) and «Application processor«. But I have to do it C plus lib_xcore. So,.. what (me worry?) (Comments:4)

Then there are the ideas behind xC. Hiding xC, in this new context, inside a black box, making it invisible for me, and doing it all with function calls and macros in C «proper», I can still observe the beauty of this, from the outside (Comments:5). I dare say, those XMOS engineers know more about all the secrets of the xCore than I do. I certainly hope that’s homegeneous throughout the organisation. And they have learned from the feedback from all of us users over quite some years. I did write some CSP based runtime systems in C for real-time embedded systems over the years (they had a task abstraction and channels), but I felt so much in short of what that code was to run on.

I really can’t wait to see what XMOS and lib_xcore have in store for me! I cant’ wait to double-click Tools-15---MacOSX_15.0.6.dmg (Comments:6). I want to feel real again, armed with XMOS’ ideas and their new wrapping. Maybe there’s even some Hawking radiation from this black box to discover? (Like handling the xCore locks?)

Now, perhaps I can use the macOS’ Xcode and forget about Java updates?

I will not update much here. Go to My XMOS pages for new blog note (or follow the arrows).

Comments

1. But it has taken a full year since XMOS opened the lid of the xcore.ai Explorer board (151:[xcore.ai Explorer Board]), and it’s still not released to the public. We have had the corona pandemic, which I am sure has not helped. But adding a neural processor for machine learning, I assume is a rather new field – and also very complex.
   • Update Nov21: Machine learning is often called Software 2.0, if traditional programming is Software 1.0. I think that XMOS now is moving into the MLOps area («MLOps or ML Ops is a set of practices that aims to deploy and maintain machine learning models in production reliably and efficiently.» I guess this is an area where attempted systems to actually become deployed is in demand
2. Even the newest XTC Tools 15.0.6 comes with this message for me: «This toolkit release is not properly signed, meaning that the stricter security rules on MacOS Catelina (sic) will cause security dialogs to be raised when the tools are run. This design advisory: (here) describes the workaround.» Maybe I’ll update to Mojave then, and wait with Catalina. (The reference also covers the Java SE 6 runtime requirement that I think is not required any more?)
   * Since I’m so far behind anyhow, should I wait for proper signing?
3. I wonder what that might do with the deterministic xCore architecture. They have now removed the xta static analysis tool, which helped getting control of that feature (*1)
   Update 02Nov2022: In an ad for a Software Engineer, Tools (full time in Bristol) XMOS asks for engineers whose responsibilities should be, amongst other, «Timing analyser, for static timing analysis and constraint checking of software». So maybe they haven’t given up on it after all. Which of course would have been very odd, in view of their hw architecture
4. I do hope that the exciting neural network processor of the xcore.ai is useful, even for me, with zero product portfolio – I mean, that it’s not a cuckoo in the nest
5. I am excited to learn how the FreeRTOS (here) operating system might be able to coexist with the lib_xcore, if at all. Due to the MIPS delivered on a logical core alone (1/8th), both FreeRTOS and its tasks just cannot be run on a single core only. I wonder how lib_xcore + FreeRTOS == true can be true?
   * Here is what XMOS wrote on their intro page: www.xmos.ai/software-tools/ (13May2021)
   «xcore delivers in hardware, many of the elements that you’d expect to see in a real-time operating system (RTOS). Separate logical cores for real-time tasks make it more predictable, more scalable and faster to respond than conventional RTOS based sequential processor systems.»
   I don’t see neither RTOS nor determinism by certainty talked up in that quote (*1)
6. I also wonder whether Apple’s transition from Intel to Apple’s own Arm based M1processor and the use of Rosetta 2 to translate from Intel binary to M1 binary might be a bump in the road for XTC Tools Apple users
7. XMOS still ship the simulator. Somebody could have made an xC compiler for any processor, but it might have been rather meaningless, so I don’t think anybody did this. The xCore doesn’t look like anything else. But now, with the lib_xcore, a port may be easier. But will it be just as meaningless?
8. (*1) Update 26Jul2021: Determinism certainly is treated in the XMOS FreeRTOS port! See 200:[FreeRTOS whitepaper]
9. I wonder how interface, [[notification]], [[clears_notification]], [[combinable]] and [[distributable]] will be solved. Can’t wait to study RTC’s resource pools, transactions and task group and inline function calls. PAR_JOBS can’t do it alone, I think. Yes I have installed and done a sneak preview.. Or will they rely on xC still handling this?
   Update: [1] says no interface, only channels
   Update: [1] says no [[combinable]] meaning the number of PJOB inside all PAR_JOBS cannot exceed the number of logical cores. Exceeding this will cause a runtime error.
   XMOS must obviously have burnt their fingers on these «new» xC features (I admit, they have caused me a lot of blog notes!) But lib_xcore has so much inherent complexity!
   Update: [2] says: «XC’s [[combine]] and [[combinable]] keywords are not available in C. Combine the functions manually.» Very interesting! Can’t wait to see the examples!
10. FlexPRET: A student (at NTNU) pointed out to me the similarity between the FlexPRET architecture and the xCore architecture. Is XMOS on some move here, with the new SW architecture on top of the new XS3 architecture (overview here))? (FlexPRET: A Processor Platform for Mixed-Criticality Systems (2014) by Zimmer, Broman, Shaver, Edward A. Lee (here – last updated in 2017)).
11. Update 27Sep2023: See 222:[XC compiler lives]. Very important!

A quote of XMOS

From [1]: They even mention «CSP» (Wiki-ref), which is not very customary to them. Even if it’s been there all the time. I kind of like this:

«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.»

Update 27Sep2023, some time after this this XMOS have changed poilicy. See 222:[XC compiler lives]. But then, personally I would have preferred the abstraction level of a continually developed xC language, not just one that is frozen. XTC is a pragmatic step down.

References

1. Transitioning from older tools releases by XMOS. See https://www.xmos.ai/documentation/XM-014363-PC-4/html/tools-guide/install-configure/transitioning/index.html – especially the video
2. XC to C Cheat sheet by XMOS. See https://www.xmos.ai/documentation/XM-014363-PC-4/html/prog-guide/prog-ref/cheat.html#cheat

← →