Embedded Systems Engineering Standards Column vol 13.4 June 2005 C is dead! By Chris Hills

 

I have to give the usual disclaimer that that these are my own personal views and not those of the ESE Editor and publisher. They are also those of my employer. I am currently working for myself! I have had an eventful four months and need to put it all into perspective before I comment on it here.

 

Returning to one of my on-going topics is Certification for programmers, not Licensing of Engineers. There appears to be some interest in this. Now I have started the ball rolling with the IEE (and hopefully the BCS by the time you read this. The IEE are merging with the IIE who do the levels below C.Eng so they have an interest in this sort of certification. The question is what should be certified and how. There has already been a suggestion that there is a Certified Embedded/Graphics/Business Systems Programmer. That is three variations. So the question is will three suffice and what should be in each and conversely what should be excluded.

The Embedded community needs to get its act together so we can define the level and structure before one of the other areas (Business or Graphics) becomes the benchmark. So email me at Contact with any suggestions.

I had a surreal moment at a MISRA meeting a week ago. I realised C is dead! It was the inaugural meeting of the MISRA-Auto code group. This is for modeling tools that generate code. A bit of a surprise as it is Matlab/Simulink biased rather than UML which I and a few others were expecting. Most of the UML tool vendors have been asked for MISRA-C compliant code as an output. This was also discussed in the Autocode meeting. The same point came up… why the need to adhere to MISRA-C for the output from an autocoder?

MISRA-C is designed for human written code where the human can err. In the tools code is generated by rules. If you get “if(x=0){“ once, instead of the = =, you get the single = in every IF statement it generates not just sometimes. The some of the autocode problems were for example that some tools do not generate a default clause in switch statements though this could be sorted out in the modeling rules. The MISRA-C team is looking at this subject. Once the CASE tool code generator is stable and any new rules applied its output is predictable.

Most of the UML and other autocode tools can talk directly to the compiler. The model compiles to object code. The C source is no more used by the human than the assembler (if generated) or the object code. Note the assembler “if generated”. Whilst some people do still use assembler its use is quite a small number these days. Very few if any C programmers look at the assembly. In fact many compilers go from source to object code in, apparently, one pass.

 

Soon it will be common for many programmers, maybe the majority with the rise of the cheap ARM parts, to use UML, Matlab, Simulink code generators and never need to look at the C source code. Of course many will still work in C just as some still use assembler.

As the majority of industrial compilers are still based on C90+ a few bits and do not seem in any hurry to move to C99 (+TC 1 and 2). I understand that AT&T who had a major part in developing C are staying with C90 like the rest of us. Now some companies, in the IT field, are trying to do things with C but this will have no impact on the embedded world. For all intents C is, I think, if not on the decline, certainly stationary and not likely to move forward again.

This is good in very many ways for programmers as compiler writers can improve their tools and environments e.g. libraries, without having to worry about any more changes to the standard. Whilst I think that fewer people will be directly programming in C the demand for C compilers will not diminish as they will form the back end to all these new CASE tools and many will still use C directly on the 8 bit MCUs.

I know this has been heralded before: CASE tools to take over the world! This time it is different. At the MISRA-Autocode meeting there were representatives of all the main European car manufacturers. There were other major players in the automotive development world. The tool vendors were there because their major customers were. There is a real need from the industry.

This is something else I have noticed. The industry groups such as MISRA are the ones that generate the real standards. If you look around you will find that 99% of the “standards” in use today are those produced by the industry for itself: PCI, USB, CAN, LIN, RS232, UML, HEX, Hayes modem commands etc. There are several reasons for this.

Partly because they relevant parties usually work in the same commercial area and talk to each other, usually at trade shows, seminars and conferences… Over a coffee ideas spring up and if they have some real useful technical or commercial benefit or a real need is identified then people start to do things. The commercial imperative speeds things along.

Yes it all happens at these shows. I have a sure fire way of why you should go to the shows on the web site. Have a look it could liberate you from the office for a day and do you (and your company) the world of good.

In many cases these people are members of trade bodies or similar e.g. MISRA. Otherwise, if the requirement is large enough a trade body is formed. E.g. The OMG for UML. In some cases even ISO or BSI gets involved but this is usually after the event to “rubberstamp” the work an industry body has done. This has happened with C#.

As the industry usually has a commercial requirement it moves a hell of a lot faster than BSI or ISO can. There is another advantage. Most industry panels are almost self selecting from people who are qualified and experienced with a relevant understanding of the market and usually company resources to back it up.

On the other hand anyone can join the BSI C panel. Many are “sleepers” who have not contributed so much as an email in a decade. Conversely the C panel has as one of its more active, at least noisy, members some one who has never, according to his wife, written a line of code in a commercial/industrial environment in his life and certainly not worked in any software development environment. Though all is not lost. For example the IEC 61508-3 panel has it right even though they work out of BSI. When you ask to get involved they phone you for a chat. Not quite “a glass of sherry at Claridges” but still an interview. There will also be a request for your CV…. I am sure that if you don’t measure up you won’t get the connection. I think that this sort of screening is essential.

It has been stated by the parent panel to the C panel that the ISO C panel will be disbanded later this year because of the state it is in and possibly reformed in which case it will hopefully use similar selection criteria. By then I will be able to report of the situation that has been rumbling on all year. If I haven’t written about it by ESS ask me about it at the show. You are going to ESS aren’t you? See the link on the web site for “getting to shows”. This is a simple guide on why you need to go to at least one show a year. For your sanity and the good of the company. The largest one is of course ESS at the NEC in October in Birmingham.

Just before the copy date I had an email from Derek Jones of Knowledge Software about his new book. Although I don’t usually do free adverts, the advertising manager at ESE would have a fit, this is different. Derek has been an active member of the UK C panel since 1988.

Derek has written a very detailed and authorative 1616 page commentary on the new C99 standard. Clause by clause. It is so large because it actually contains the complete ISO C standard! Yes the full, annotated, C99 standard as of December 2004. Well how else to you do a clause by clause analysis of the standard?

Derek says” The copyright issues have now been sorted out and you can now download my book "The New C Standard" from http://www.knosof.co.uk/cbook/cbook.html “ That’s right a FREE download of the complete book! This is a completely legitimate copy of C99.

The full title is “The New C Standard: An Economic and Cultural History” It contains a lot more than just an annotated C standard. My copy of the C standard is 554 pages, so the standard only makes up a third of the book. Derek has written several compilers, code translators and analysers including some that have been validated fully compliant to the relevant standard. He says that you don’t really understand a language until you have written a [validated] compiler for it.

Derek goes on to say “Comments welcome (I know that some of the margin references at the bottom of the page apply to material at the top of the next page; I have given up wrestling with the page layout system for the time being). Updated subsets of the material will be appearing on the books web page over the coming days.Http://www.knosof.co.uk/cbook/cbook.html

NOTE: This is an 8MB file so you will need broad band to download it. It prints out to a about a 4 inch (10CM) stack of paper…. If you print it double sided. As Derek has, all be it a rather large, download quota, but if you find his web site is locked then try http://websites.ntl.com/~dmjones/cbook1_0a.pdf or please email me contact and I will make it available.

If you download it please send an email to Derek saying you have done so. This is just to prove a point to a publisher who thought there would be no interest in this sort of book!

Finally don’t forget to send comments re Certification for Programmers. The question is what should be certified and how. There has already been a suggestion that there is a

Certified

Embedded Graphics Business

Systems Programmer.

That is three variations. So the question is will three suffice and what should be in each and conversely what should be excluded?

The Embedded community needs to get its act together so we can define the level and structure before one of the other areas (Business or Graphics) becomes the benchmark. So email me at cert@phaedsys.org with any suggestions.

 

Author Details and contact

 

Eur Ing Chris Hills BSc CEng MIET MBCS MIEEE  FRGS   FRSA is a Technical Specialist and can be reached at This Contact

 

Copyright Chris A Hills  2003 -2008
The right of Chris A Hills to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988