Everything Else

robespierre wrote: But I don't get the impression that the supported architectures are parallel.

SierraC is targeted for m68k, including CPU32 (683xx). I do not know why they added a flag to enable/disable the "shortcut" feature, however, I have learnt that you'd better spend half an hour to check the environment (SET variables, SierraC works on a DOS machine).

it comes out from this topic I have opened because I had a funny behavior with SierraC (job task)

interesting points about the C language

those who think that "being MISRA" could help C source codes to be written in elegant, concise manner, which implies "to diverge" from the standard, more specifically to ban a lot of C89/C99 constructs and features

and those who think that is a bullshit because it's always programmer's fault, they are superior like martial arts master who polishes its blame until it shines, while bad-C-programmers are like the last jerk child who gets his access to a computer console and writes bad C programs and then blames it on the language

Anything goes, ironically they are both true: the C language is a common problem

which makes me motivated to promote my idea of "SafeC", get a new C language with a "schoolmarm" built-in ( I hate to have a dumb compiler with an external MISRA checker), she (the compiler is now a she) will be integrated within the Compiler, and more pedantic in teaching MISRA than the best MISRA-2004 QAC ever (you have to pay for these "tools", there is nothing in the open source world), ready to promote an absolutely "new standard", called "SafeC/89" with no need to diverge -> problem solved

insert coins please, I want my copyright, honey money

ivelegacy wrote: The (the compiler is now a she) will be pedantic in teaching MISRA more strictly than MISRA-2004...

With gcc, just switch in -pedantic and you're already covered! Actually -pedantic -Wall -W are what you want. With MIPSPro, -fullwarn is supposed to do that but the IRIX system headers are so far out of compliance with the standard that MIPSPro supports that you're basically making the compiler do a ton of extra work to show you bads that you can't fix anyway. Unless you've got access to the IRIX source code. Anyone? Anyone? Bueller? Bueller?

vishnu wrote: With gcc, just switch in -pedantic and you're already covered!

it's


(partially covered)

but …

• do not waste and ruin my wicked plans, in first place (1)
• Step back gonna come at ya fast, the C language is driving us out of control, and with thousands multicore(2) is getting ready to crash, the solution is a schoolmarm, even if some days the schoolmarm looks like the worst bitch ever, next day she is your super girl out to save the world, the result is "keeps getting better"
• the Holy Holy MISRA school (which is a MUST in avionics) says that the above CFLAGS are like foam flakes .... emmm and before say "no", keep calm, and note they have ninja suicide squad with long swords, they can cut your head in a whistle (too angry against the humanity on their forum)
• (1) GaGA wants diamonds, unfortunately I have discovered they are toooooooooooo expensive, so ...

(2) Thinking about "improvements" in the C language
The real problem with the C language is that Threads Cannot be Implemented as a Common Library, this because C really sucks about concurrency. A bit of hyperbole, the problem is the concurrency model of shared (e.g. global) variable access. Not all concurrent programming make use of shared variables the way they imply - may be some, certainly, not all, and the C language and its implementation offer no built-in tricks, no help at all, you are alone on your way, so, with the C language, a better model for concurrency is probably using channels, which are encouraged by most languages which support concurrency anyway, and not shared memory. However, it's also true that possibly channels cannot be support as library code either.

In other words, it's not a problem, and it doesn't matter which language you want to use, You will always find a trick to handle the complexity and all goes well until you have not to handle hundred or thousand of cores: Hell begins where you can smell the smoke, with the C language you are alone, while the Ada languages already offers Protected Objects, and Modula-3 already offers Mutex Objects, and the RUST language claims to have a similar solution, reasonable because in Mozzilla they have interests about that (=money, business plans, man-power, final products)

Oh come on dude, tell me what useful/practical avionics software is ever going to need to run on hundreds or thousands of cores? If there's a plane that needs that I don't want to fly on it. And pthreads has offered effective mutexes since forever. The Linux SMP code (which for the most part was written by sgi programmers) has been running the world's largest supercomputers for years. Which isn't to say there aren't improvements to be made, so yeah, you should do that. But let's stick to the community pledge of "no forky"...

vishnu wrote: tell me what useful/practical avionics software is ever going to need to run on hundreds or thousands of cores?

Avionics loves 440/460 (e.g. used in M346 aircraft) and it's mono core, while e500 (PowerPC by Freescale) is 4 cores, currently used in Moto GP (Valentino Rossi has it in its motorcycle) and F1 (I worked with RedBull).

News & rumors: it will replaced by an 8 cores in FOM (formula one management), and still supported by Windriver/VxWorks , you have to pay 20K euro of license to have a "trusted compiler& ecosystem, including their Eclipse builder and code checker" (Green Hills costs 50K euro in licenses, including their QAC)

but it's not the point!

The point is that Avionics is mission critical, and due to the HW constrains, strongly uses the " shared memory model " in their equipment , which is completely unsupported by the C language

MISRA does not help, and you have to fix the hot jam (in low level ={ BSP, IBSP, drivers, CBIT, BIT, .. } everything else is written in higher language -> ADA) with a lot of #PRAGMA and ugly tricks ---> you have to handle extra testing activities in order to check if everything is ok within "normal" and "abnormal" working conditions.

That means you have the same problem because you have a lot of devices (with "redundancy" -> e.g. MTC=mission tactical computers) that want to read/write data under different real time OSes

e.g. you might have

• VxWorks/OS running on boardA
• interfaced to Integrity/OS running on boardB
• which might want to talk with Velocy/OS running on boardC

because all of these boards are installed in the same chassis, and they talk each other through shared memory (boardD)

and trust me: it's very hard human power! Thousand hours requested, thousand money involved, and very frustrating job (I say that in first person)

vishnu wrote: pthreads

pthread does not offer nothing in term of " safety " when you have to deal with safe-concurrency, I have articles about that, and again, you depend on #PRAGMA --> you depend on the C compiler implementation, GNU/GCC isNotEqual To DIAB/C , isNotEqual To GreenHills/C ----> say bye bye to the C portability and be prepared for a lot of troubles (and extra homework)

vishnu wrote: The Linux SMP code

Who cares ? Linux is not certifiable as DO178A level E

• Level-A , Failure condition is Catastrophic , Failure may cause a crash. Error or loss of critical function required to safely fly and land aircraft
• Level-B , Failure condition is Hazardous , Failure has a large negative impact on safety or performance, or reduces the ability of the crew to operate the aircraft due to physical distress or a higher workload, or causes serious or fatal injuries among the passengers. (Safety-significant)
• Level-C , Failure condition is Major , Failure is significant, but has a lesser impact than a Hazardous failure (for example, leads to passenger discomfort rather than injuries) or significantly increases crew workload (safety related)
• Level-D , Failure condition is Minor , Failure is noticeable, but has a lesser impact than a Major failure (for example, causing passenger inconvenience or a routine flight plan change)
• Level-E , Failure condition is No Effect , Failure has no impact on safety, aircraft operation, or crew workload

Concurrency model, offered by ADA as "language feature"

a few Interesting Articles

• Threads Cannot be Implemented as a Library , Internet Systems and Storage, Laboratory HP Laboratories Palo Alto
• The Problem with Threads (Electrical Engineering and Computer Sciences University of California at Berkeley)

Interesting language and book

• ADA & Protected Objects
• Modula3
• RUST
• Concurrent Euclid, Addison Wesley Computer-Science

Concurrent-Euclid is also known as " ConEuc ", it is a concurrent descendant of the Euclid programming language designed by James Cordy and Ric Holt, then at the University of Toronto, in 1980.

I guess that ConEuc can really teach good things to the next generation of the C standard
It was designed for

• concurrent
• high performance
• highly reliable

system software, and proved to be low level enough: the "TUNIS" Operating System is a Unix variant!

ivelegacy wrote: Step back gonna come at ya fast, the C language is driving us out of control

If you think that C is what's causing software to get worse, you haven't been paying attention for the last fifteen years. Most programmers today could learn a thing or two from being forced to abandon their XML and their PHP and their whatnot and just work in straight C.

commodorejohn wrote: last fifteen years

15 years ago we do not have the multi cores machines we have today, and today we do not have the multi core machines we will have in 2020. Predictions: it will be a disaster if we do not fix the jam. This is a partial reason to promote the next generation of the C++11, which will be more focused on "concurrency" offering "built-in" language-features. We are still in time. The articles that I have posted explain WHY and WHERE the C language is going to drive us out of control.

ivelegacy wrote: while e500 (PowerPC by Freescale) is 4 cores

This is complete nonsense. e500 is a PowerPC architecture specification. Freescale is producing various e500 (or e500v2) processors in its ``QorIQ'' family, and some of them (such as the P4080) happen to have four cores, but not all e500 processors do.

ivelegacy wrote: 15 years ago we do not have the multi cores machines we have today, and today we do not have the multi core machines we will have in 2020.

Who cares? Everything we do today we were doing satisfactorily 15 years ago, so there's nothing that actually requires multiple cores.

miod wrote: This is

this is not the point, I was speaking about my personal experience with the e500 we used in FOM and MotoGP (I guess two interesting examples in automotive).

Points were:

• they were both 4 cores, running VxWorks under the Windriver version of Eclipse/C89
• a lot of troubles to be solved before having a "working & verified product"
• a lot of these troubles were due to the C language which has NO features to support the concurrency in a safe way
• se we needed to split the project into three parts, high level in C, unsafe (C wrapper to assembly with a few asm-inline), and pure-assembly (critical code)
• and last but not least, in the next job task we abandoned the shared memory memory and we started to implement message passing, a sort of virtual lan switch implemented in software in where we reused the above approach, embedding it into a BSP. It simplified our life by different level of magnitude (even if it caused a little overhead -> performances drop)

commodorejohn wrote: Who cares?

Google cares! Why do you think they have invented the GoLang ?
(Google Language, there are 2 working compilers and Apps written in Go)

I figured they invented Go because of their compulsive need to control every facet of the software ecosystem...

commodorejohn wrote: Who cares? Everything we do today we were doing satisfactorily 15 years ago, so there's nothing that actually requires multiple cores.

Actually, this is why I fell in love with smp - twenty years ago OS/2 had "pervasive multi-threading" with multiple processors and it worked very very well.

But that was with real programmers

I think ivelegacy works for Lamborghini...

Besides Go and Rust, some "C like languages" with support for concurrency that I wanted to try are Cilk, Limbo, and XC (the latter from Xmos).

vishnu wrote: I think ivelegacy works for Lamborghini...

Freelancer, I was asked to support (as consulant) a team in FOM, and it was RedBull.

CompileTimeAssert, Because We Have Been Pooping The Wrong Way



I am really appreciating the GNU idea about _compile_time_assert_ (my sarcasm)

you can learn something new everyday: The Byzantine Problem

geGNUflect on Complexity
(lie cheat, last famous words)

talking with a G-BOY pro - " we GNUDO Obscure C programming because we can " -
(o really?) - "even if, we geGNUflect on Complexity" - He said!

asked: " and didn't you say what the Bugs Life is that ? "
answered: " our virtuosism, an addiction that needs feeding "

and it sounded like " I Don't Like the Drugs But the Drugs Like Me "
but "GNUDO" is actually "a verb" in their Dictionary, because " they can "
reinvent the wheel (squared shaped), invent and devise new words
new C features, even new phrases in their documentation !!!
don't be blasphemous, it's not "neologism", it's "GNUlogism" !!!
and geGNUflect on the altar of the GNUGOD-Complexity !!!


Respect! (my dry-sarcasm)