Why does ARM mbed rely on C++? Is C++ the future?

[andyturk]

Unfortunately many of the younger and more naive C/C++ advocates believe the stories that C/C++ is necessary and sufficient for low level code. In reality it is neither necessary nor sufficient.

One can boot a Cortex-M processor and an application without a single line of hand-coded assembly (or asm statements). Standard C/C++ code is all that's required.

Why would C/C++ not be sufficient for low-level code on a Cortex-M?

[tggzzz]

Unfortunately many of the younger and more naive C/C++ advocates believe the stories that C/C++ is necessary and sufficient for low level code. In reality it is neither necessary nor sufficient.

One can boot a Cortex-M processor and an application without a single line of hand-coded assembly (or asm statements). Standard C/C++ code is all that's required.

Why would C/C++ not be sufficient for low-level code on a Cortex-M?

I refer you to the context of the conversation, specifically that you cannot[1] write threading code in C/C++ without relying on behaviour that is outside the language. See Hans Boehm's paper referred to earlier (and google Han Boehm) to see that he does know what he is talking about.

[1] that may have changed in the latest variant of the languages, >20 years after Java Got It Right and 50 years since the problems and solutions were understood.

[technix]

Unfortunately many of the younger and more naive C/C++ advocates believe the stories that C/C++ is necessary and sufficient for low level code. In reality it is neither necessary nor sufficient.

One can boot a Cortex-M processor and an application without a single line of hand-coded assembly (or asm statements). Standard C/C++ code is all that's required.

Why would C/C++ not be sufficient for low-level code on a Cortex-M?

I'd second that. C/C++ with that all-so-common inline assembler extension (different syntax across compilers, but most compilers have them nonetheless) is likely adequate on 99% the times.

[tggzzz]

What I mean is an interrupt interrupting itself, not two interrupts interrupting each other. What I mean is, for example, IRQ 5 fired inside IRQ 5 handler.

what you really mean is you'd best avoid it.

Not necessarily. Think about multiple devices sharing one interrupt and software demultiplexes the interrupt towards the various interrupt handlers. IIRC this happens on a PC with many PCI devices.

Or any microprocessor where the interrupt is signalled by a level on a line, not an edge. The 6800 (and most others of that vintage) worked well in that respect, with many peripherals wire-or'ed on the IRQ line.

[tggzzz]

Unfortunately many of the younger and more naive C/C++ advocates believe the stories that C/C++ is necessary and sufficient for low level code. In reality it is neither necessary nor sufficient.

One can boot a Cortex-M processor and an application without a single line of hand-coded assembly (or asm statements). Standard C/C++ code is all that's required.

Why would C/C++ not be sufficient for low-level code on a Cortex-M?

I'd second that. C/C++ with that all-so-common inline assembler extension (different syntax across compilers, but most compilers have them nonetheless) is likely adequate on 99% the times.

But that merely demonstrates the inadequacy of C/C++!

Yes it works, but blows the "C/C++ is sufficient" postulates out of the water!

[rounin]

[1] that may have changed in the latest variant of the languages, >20 years after Java Got It Right and 50 years since the problems and solutions were understood.

C++11 does standardize a memory and threading model, and atomic operations. It was way overdue. I've used the <atomic> features and verified that it uses the reserved form of the load and store instructions (on powerpc mcu) needed for multithread/multicore. C++17 is fixing some more things too.

Actually /using/ std::thread on a microcontroller though, yeah no. No libstdc++ supports your favorite embedded RTOS. But <atomic> works, so you can fence data correctly, std::atomic_thread_fence can force a memory sequence point...

[SiliconWizard]

But that merely demonstrates the inadequacy of C/C++!

Somewhat yes.

But as can be seen with the example of XMOS/xC, I don't think you can properly put general thread-aware constructs inside any language without designing the underlying architecture first.
All attempts of doing that and targetting many different and existing architectures is very difficult and usually bound to fail. That's why C has favored including pthreads-like stuff in the standard than adding specific native constructs, and of course this part is not mandatory and is not guaranteed to be available for any given specific target.

C++ (which again is a monster) latest attempts are interesting in this area, but again are not guaranteed to be completely available on any given target, especially such as microcontrollers.

A proper multi-threading model, IMO, would have to be designed upfront and in close conjunction between the languages and the hardware architectures. That's pretty much what XMOS did.

[tggzzz]

But that merely demonstrates the inadequacy of C/C++!

Somewhat yes.

But as can be seen with the example of XMOS/xC, I don't think you can properly put general thread-aware constructs inside any language without designing the underlying architecture first.
All attempts of doing that and targetting many different and existing architectures is very difficult and usually bound to fail.

I don't know enough to go quite that far, but I'm sure that the future multicore/processor systems will stress traditional tools beyond breaking point. That implies that there will have to be a significant rethink of the tools and how to create systems. That, in turn, isn't an unsurmountable problem since we've done it in the past, e.g. distributed systems and the internet/web.

There will, of course, be valiant but futile attempts to recast old concepts for the brave new world, but they will fail. For example, in the web arena SOAP was the "triumphant reinvention" of RPC over HTTP; fortunately that was manifest nonsense, and it only took a decade for the REST philosophy to become dominant.

That's why C has favored including pthreads-like stuff in the standard than adding specific native constructs, and of course this part is not mandatory and is not guaranteed to be available for any given specific target.

Until recently C explicitly absolved itself of anything to do with multiprocessors/multithreading, declaring they were the libraries' responsibility. Pthreads (and others) then took up the challenge, but had to rely on language features that were explicitly left, um, vague and incomplete.

=> Castles built on sand.

C++ (which again is a monster) latest attempts are interesting in this area, but again are not guaranteed to be completely available on any given target, especially such as microcontrollers.

Somewhere in the mid naughties I remember the triumphant announcement of the first complete C++ implementation of the latest standard. That was 5/6 years after the standard was published. That was a Big Red Flag.

A proper multi-threading model, IMO, would have to be designed upfront and in close conjunction between the languages and the hardware architectures. That's pretty much what XMOS did.

Not sure. A large part is going to depend on the level of abstraction chosen. But you may well be right.

[andyturk]

But that merely demonstrates the inadequacy of C/C++!

Yes it works, but blows the "C/C++ is sufficient" postulates out of the water!

That's just being argumentative. 

[legacy]

multiple devices sharing one interrupt and software demultiplexes the interrupt towards the various interrupt handlers

The Atlas board is a good old-school example. When an interrupt arises, a signal on the Cop0 goes down to "0" (it's negative logic), and the Cop0 decodes on which line (16lines-to-4binary), then it issues a machine exception to the RISC-ish CPU.

The pipeline is stalled, the BU is flushed, the PC is saved into EPC, and reloaded with the proper exception address, whose first instruction is usually a "disable interrupts". At this point the CPU checks on which line the exception cames from, and which subtype of exception is. There could be many pending events here, waiting to be served. You need to clear the bit to say "event got processed". Once understood and decided which one needs to be processed (priorities here are flexible), there is a simple "function call" to the proper sub exception routine that handles the whole task, and once completed, it returns back to the handler, that clears the proper event-bit and resumes the CPU from the exception mode. Exceptions are then re-enabled by the last instruction, and PC is assigned with EPC, thus the CPU is again ready to go on as nothing had ever happened (from the user-mode point of view).

It's a simple, efficient, and deterministic way to process things. And note that nothing is interruptible in exception-time (it might be, the hardware support it, but it's discouraged since it also confuses the debugger). One event triggers the machine-exception, with a priority, of course, and nothing can interrupt it. It's the best way to debug complex stuff happening in kernel space.

On my MIPS manual for the Atlas board, there is the same warning that is also written on the Microchip/Atmel manual about their XMega.

I think, there must be a reason for that.

[tggzzz]

But that merely demonstrates the inadequacy of C/C++!

Yes it works, but blows the "C/C++ is sufficient" postulates out of the water!

That's just being argumentative. 

Ah, by "argumentative" you presumably mean "I don't like it, but it is accurate".

I'll listen to reasoned counterpoints.

[legacy]

many peripherals wire-or'ed on the IRQ line.

In that board, you have 16 IRQ-lines for peripherals. Sixteen devices can be allocated. Usually, it's the best choice for low latency peripherals: each peripheral is wire-or'ed on its IRQ line.

Of course, you can also have many peripherals wire-or'ed on the IRQ line, but in this case, the handler needs to query "hey? oh! who has issued the exception?", usually issuing a bus request to know who had issued it, to which the requesting device must answer within a time window, otherwise, the exception is assumed by the cop0 as a bus error (with the high severity of being an hardfail)

When the interrupting device answers the request of Cop0, it usually sends its ID, so the exception handler knows which is *THE driver* to call (it gets it from a table, that maps IRQ-line-to-address) line, and it also knows which is the sub-device.

[technix]

multiple devices sharing one interrupt and software demultiplexes the interrupt towards the various interrupt handlers

The Atlas board is a good old-school example. When an interrupt arises, a signal on the Cop0 goes down to "0" (it's negative logic), and the Cop0 decodes on which line (16lines-to-4binary), then it issues a machine exception to the RISC-ish CPU.

The pipeline is stalled, the BU is flushed, the PC is saved into EPC, and reloaded with the proper exception address, whose first instruction is usually a "disable interrupts". At this point the CPU checks on which line the exception cames from, and which subtype of exception is. There could be many pending events here, waiting to be served. You need to clear the bit to say "event got processed". Once understood and decided which one needs to be processed (priorities here are flexible), there is a simple "function call" to the proper sub exception routine that handles the whole task, and once completed, it returns back to the handler, that clears the proper event-bit and resumes the CPU from the exception mode. Exceptions are then re-enabled by the last instruction, and PC is assigned with EPC, thus the CPU is again ready to go on as nothing had ever happened (from the user-mode point of view).

It's a simple, efficient, and deterministic way to process things. And note that nothing is interruptible in exception-time (it might be, the hardware support it, but it's discouraged since it also confuses the debugger). One event triggers the machine-exception, with a priority, of course, and nothing can interrupt it. It's the best way to debug complex stuff happening in kernel space.

On my MIPS manual for the Atlas board, there is the same warning that is also written on the Microchip/Atmel manual about their XMega.

I think, there must be a reason for that.

Those warnings is exactly why most modern interrupt controllers, be it APIC on x86 or NVIC on Cortex-M, does not allow an interrupt handler being interrupted by another interrupt of the same priority level. This, plus the design decision that no two interrupt handlers shall operate on the same memory and/or peripherals except when making use of a well defined IPC mechanism, makes all the above arguments of memory conflicting goes away in most cases. There is no way an interrupt handler can race against itself (due to the hardware guarantee) and no two interrupt handlers can interfere each other (guaranteed by design) most of the code does not need any atomics. As of the IPC mechanism, that is where atomics and thread-local storage might be needed, and being a small library after all, I am okay writing that portion (along with the swapper) using inline assembler.

[nctnico]

But that merely demonstrates the inadequacy of C/C++!
Yes it works, but blows the "C/C++ is sufficient" postulates out of the water!

That's just being argumentative. 

Ah, by "argumentative" you presumably mean "I don't like it, but it is accurate".

To the point where it doesn't matter. What would that language you are referering to be written in? It is likely C or C++ at some level.

[Bassman59]

Somewhere in the mid naughties I remember the triumphant announcement of the first complete C++ implementation of the latest standard. That was 5/6 years after the standard was published. That was a Big Red Flag.

Look how long it took the synthesis vendors to update their tools to support VHDL-93! And then VHDL-2002!  And then look how long it takes them to update their documentation ... too much of the examples they use still have the VHDL-87 idioms.

[tggzzz]

But that merely demonstrates the inadequacy of C/C++!
Yes it works, but blows the "C/C++ is sufficient" postulates out of the water!

That's just being argumentative. 

Ah, by "argumentative" you presumably mean "I don't like it, but it is accurate".

To the point where it doesn't matter.

It matters in that youngsters shouldn't be taken in by glib alt-facts. (I specifically exclude AndyTurk from that!)

What would that language you are referering to be written in? It is likely C or C++ at some level.

Irrelevant. What matters is the language you are using to develop your product. The tools should support abstractions that enable you to express intent clearly, succinctly, unambiguously, and correctly.

All the other tools that have been used to allow you to get to the point where you can develop your product are completely irrelevant. If you don't accept that, then where do you draw the line? VHDL/Verilog, Spice/ADS, diffusion furnaces, smelters, baskets on the head of Congolese miners etc?

[NorthGuy]

The tools should support abstractions that enable you to express intent clearly, succinctly, unambiguously, and correctly.

The language is a tool. You don't express the intent. You simply use the tool to accomplish your task.

If you want to sink a nail, you do not express your intent to the hummer, you just swing it. And it work the same regardless of the intent - whether you're building a cathedral or a coffin. The intent doesn't matter.

[tggzzz]

The tools should support abstractions that enable you to express intent clearly, succinctly, unambiguously, and correctly.

The language is a tool. You don't express the intent. You simply use the tool to accomplish your task.

If you want to sink a nail, you do not express your intent to the hummer, you just swing it. And it work the same regardless of the intent - whether you're building a cathedral or a coffin. The intent doesn't matter.

Oh dear. That's not right. That's not even wrong. (with apologies to Wolfgang Pauli)

How to enlighten you?... I suggest starting with "Zen and the Art of Motorcycle Maintenance" by Robert Persig.

[andyturk]

If you want to sink a nail, you do not express your intent to the hammer, you just swing it.

Well put! 

And if the hammer sinks nails sufficiently well, it doesn't really matter whether the creator of said tool actually set out to build a screwdriver and missed.

Corollary: A good tool has utility beyond its original design goals.

[andyturk]

^^^ Multiple inheritance.

 

[westfw]

One can boot a Cortex-M processor and an application without a single line of hand-coded assembly (or asm statements). Standard C/C++ code is all that's required.

Yeah, but you get into trouble pretty quickly if your compiler hasn't implemented the ARM-recommended intrinsic functions for doing things like turning on interrupts.   (although, it's a really good thing that ARM standardized these!)

The sad thing is that "embedded programming" (at least in the "small embedded sense) doesn't seem to be a big enough market for language developers to get excited about.  We're stuck with cast-offs and kludged subsets of the 'real' languages.  Java, C++, C#, and etc keep getting bigger and bigger, ignoring or contradicting the "needs" of the embedded market (for example, C (or perhaps just avr-gcc) added "named address spaces" to better deal with harvard architectures, but the C++ folks won't include it...)  The closest we get it an occasional "systems programming language", but it's not quite the same.  C (IMO) succeeded because the base definition is very "pure", easy to port to new architectures, and didn't actually require a full implementation of the various "standard libraries" to be useful.   C++ is mostly following suit, with a fair number of useful new features.

What SHOULD probably happen is that someone should work on defining subsets of languages and embedded libraries.  Arduino and mbed are efforts in that direction, but ... they're being defined by hobbyists, artists, and hardware vendors.   The computer scientists and language experts aren't very interested, and the occasional industry group seem mired in the past ("you should use Ada!"; "We'll disallow everything that has ever caused a bug."  (I mean, really - disallowing dynamic memory allocation pretty much turns off the last 30 years of algorithm development.))   Or perhaps we embedded programmers are mired in OUR past - insisting on performance at the instruction-count level long after we should have accepted that faster CPUs make things like (horribly redundant) run-time type checking reasonable after all.)

(and then, there's the customer, willing to accept less reliability in return for better performance and a lower price...  Sigh.)

[andersm]

Actually /using/ std::thread on a microcontroller though, yeah no. No libstdc++ supports your favorite embedded RTOS. But <atomic> works, so you can fence data correctly, std::atomic_thread_fence can force a memory sequence point...

I believe RTEMS supports C++11 threads, but they have ported the GNU toolchain to target their OS. I haven't looked at the libstdc++ implementation to see if it provides some generic hooks so you can add support with less effort.

[andersm]

One can boot a Cortex-M processor and an application without a single line of hand-coded assembly (or asm statements). Standard C/C++ code is all that's required.

Yeah, but you get into trouble pretty quickly if your compiler hasn't implemented the ARM-recommended intrinsic functions for doing things like turning on interrupts.   (although, it's a really good thing that ARM standardized these!)

The control registers are set up so that nothing is masked by default, and everything is ready to go. The enable bits and priority registers for individual external interrupts are memory-mapped.

[legacy]

"you should use Ada!"; "We'll disallow everything that has ever caused a bug."  I mean, really - disallowing dynamic memory allocation pretty much turns off the last 30 years of algorithm development.

yup, sir. And it has saved our lives several and several times in avionics 

[andyturk]

yup, sir. And it has saved our lives several and several times in avionics 

For other applications, a watchdog timer is sufficient. And necessary!