Søk etter:

New 15Aug2018,updated 7Oct2022

This note is in group Technology (plus My XMOS pages). Also see «the next» Fringe, filled with the same theme: IEEE-COPA 2021 fringe.

For the TIOBE index 016:[10]: «xC programming». Also see IEEE-COPA 2021 fringe

The presentation

This presentation is for the CPA 2018 conference in Dresden (Update 6Oct2022: dead url (but Wayback Machine here), the only traces I can find are here, here and here.) It is a «fringe presentation», meaning that it is informal and has not gone through standard peer review, ie it is my sole responsibility – even if I have signed the Author’s Declaration about it. The title is meant to be laborious to exhaust the problem I try to unravel:

Unravelling xC concepts [[combine]], [[combinable]], [[distribute]], [[distributable]] and [[distributed(..)]] plus par and on..

Press picture to run it in Apple Keynote. A PDF export for reading pages and printing is here – and with all build stages here. I also have a PowerPoint .pptx export here (I’m not certain how well it runs).

Below is the Abstract. It will appear in the conference proceedings (press picture to read PDF):

Comments

Here are some of the comments that were given during and after the presentation plus when chatting with people. I did the presentation in the Campus Bar with a very long hdmi cable to the projector. So I should have kept to the around 20 lines per slide, since my code examples became blurred. Process, task and thread are the same thing here. But hw thread is another matter:

1. The transputer has so called «hardware and software equivalence» (HSE), meaning that the same software would run with the same behaviour, being placed on the same transputer, the neighbour computer of across transputers. Synchronisation, with acknowledge messages going back was also kept. However, any timing of races would differ for these cases. The question was whether the different placement of the code on the xCores would have the same property of hardware and software equivalence? My answer is that I would think so, provided the coding is thread safe, with no fiddling with pointers(?)
2. The transputer had a scheduler in hw but channels etc. were handled by sw helped by channel and ALT instructions etc. in microcode. For the xC «there is so much more in hw», like there would be a limited amount of timers and chanends for this very reason. The reason (said another guy) was that the xCore did make it possible to have better control of timing and guarantees. For that reason each core could handle one hw thread (one of the full tasks, with the cnt++ allowed in my code examples)
3. Therefore, when XMOS added (to the normal task type) a combinable and also a distributable task type (around 2012?), it was for the user to be able to run more than one sw task per logical core. I told that this was «before my time» so I had not thought of this as solving a problem introduced by the architecture. For me it was a way to pack more than one task on a logical core, which I certainly appreciated. (Hey, «packing» – might this be the missing common denominator for combinable and distributable?Any commen term for combinable and distributable? See Any commen term for combinable and distributable? on the xCore Exchange)
4. Still people believed that this was a rather elegant, and they said that being aware of the three types of tasks (everything allowed, (as always in occam since PROCs were pure sw), combinable and distributable) was really quite interesting. People saw that this gave an understanding of what it would mean to schedule and run each of these process types
5. The guys were wondering whether an interface with interface calls would be «like an object-oriented class with methods»?  I said «no». The original OO-object is not «Runnable» (like a Java object may be) (which in itself doesn’t make it to a Java Thread). xC functions, once started within a par with interface or channel params, are threads. xC chan is untyped, but xC interface has RPC-like functions (Remote Procedure Call) with input and output parameters. xC tasks may be client or server by those reserved words. This lets the xC compiler watch over and protect intermediate stages in a session sequence with the [[notification]] and [[clears_notification]] decorations used on the function definitions in the interface. Therefore an xC interface and xC tasks will also help you with being deadlock free by supporting thread safe and atomic usage of a client-server role realationshop. So, «no»,  xC tasks and interface would not at all be «like an object-oriented class with methods»? This also shows the major difference between an xC interface type and an xc chan.

Update

Synchronous and asynchronous

15Oct2018: I discovered that XMOS in some libraries coin [[distributable]] tasks as synchronous and as having blocking operations, while [[combinable]] tasks are asynchronous. Interesting! See xC is C plus x, chapter «XMOS libs: synchronous/blocking when [[distributable]] and asynchronous when [[combinable]]». The downside of this is that a [[distributable]] task that pathologically hangs (like looping around waiting for a bit from some input pin, without a counter or timeout) would block the calling task as well

[[distributable]] for sharing memory

Update 11Feb2019: [[distributable]] is nice for sharing global vairables. See Ways to share memory on xCore Exchange

Combinable all the way to no no progress

See My xC combined combinable notes.

Ada «one-shot task» profile and distributable

This is just speculation!

Will the concept of a distributable task come from the year 2000 paper by Davis et al when they worked at Realogy (ref 1 below)? They introduce a «one-shot task» there. And this seems to have been picked up by Rivas et al in 2019 again in a suggested Ada profile also called «one-shot task profile (ref. 2 below). They also presented an Ada runtime called M2OS.

I discovered this when preparing the 2019 invited lecture at NTNU. Here’s from a page in that presentation:

• The Ravenscar profile limits the tasking model quite a lot
  • It is for safety critical systems written in Ada. It basically takes the rendezvous and select statements away and uses protected types and objects instead
  • This opens for schedulability analysis
• The now being worked on Jorvik profile seems to limit the limitations somewhat
• Rivas and Tajero have just recently suggested a task model where the stack is reused. Also starts off with Ravenscar
  • «In this paper we present a new Ada run-time environment that includes a new scheduling policy based on the one-shot task profile that simplifies the implementation of the Ada tasking primitives and allows stack sharing techniques to be applied»
  • Much like [[distributable]]?
  • Also has requirements of code: «we need to restrict the structure of the tasks’ body to the one expected for a one-shot task»
  • The idea seems to stem from a paper from the year 2000 by Davis et al

1. How Embedded Applications using an RTOS can stay within On-chip Memory Limits by Robert Davis, Nick Merriam, Nigel Tracey at www.realogy.com (2000)
2. Leveraging real-time and multitasking Ada capabilities to small microcontrollers in Journal of Systems Architecture (March 2019) by Rivas and Tajero

Priority

25Apr2021: Combinable / combined tasks, as well as distributable / distributed tasks are considered «low priority«, even if the xC has no such concept. See 141:[Priority]