cool article, interesting quote

Poets and novelists are supposed to learn how to write to the extent greater than how to spell...

Unrestricted C is indeed a language for people who know what they are doing. For the rest of us, there are books, like "Safer C", to read and follow. Then there are good practices, including those captured in industry requirements and guidelines, e.g. MISRA. And then there are static code analysis tools, from relatively cheap (PC-Lint) to really expensive (LDRA). With all this infrastructure in place, I don't think C (especially, C99 - kudos to designated initializers) has close competitors, considering code compactness and efficiency delivered by best compilers.

I am not a C++ expert but I don't think it is a mature language (yet). If you disagree, consider pointers to member functions. The claim of not paying for features not used is overstated, too. Code efficiency aside, C++ static initialization does not support tentative definitions, so, for instance, there is no way to define a constant (compile-time, ROMable) circular data structure.

Isn't it obvious though that the tool has to be for the job? Even smaller embedded systems have distinct components and they can (and maybe, should) be programmed in the most appropriate language.

That's my $.02

- Ark

In case anyone is unaware of this chip, I have found a Wikipedia link which is very informative. It seems like Intersil is still making these CPU's.

I see you can use any of its 16 registers as a program counter :S, I wonder how that works.

-Isaac

You load a register with an address, and then use an instruction (SEP Rn) to make it the program counter. By the way, the 1802 didn't have any subroutine CALL-RET instructions. One had to do that through a couple of routines and heavy use of SEP. The routines were called SCRT (Standard Call and Return).

Here's my summary paragraph: formal methods exist, they work, but in general they aren't used much because few people can justify their cost.

It's been a bit over ten years since I was a grad student doing correctness proofs of nontrivial hardware devices. Others in my research group were working on software. I say this to establish my background and also to mention that my perspective is some ways back from 'state of the art'. It's hard to make blanket statements about proving "correctness" without some describing what they believe "correct" means to them.

Some people care about proving that a block of code yields the right output at the end of execution (compiler folks care about this to verify their code transformation) - this is do-able today.

Other people care about proving liveness and avoiding deadlock in complex parallel systems. Depending on the formalism you use to write your parallel code, this is do-able today.

Yet other people care about proving security properties about their code or communications protocol. Many well-known protocols have been analyzed already.

So if there are lots of areas where formal methods already work, why is there so much buggy, prone-to-deadlock, insecure software and systems? I can think of several smaller reasons, and one great big reason.

Smaller reasons: formal methods are quite expensive, in terms of man-hours, required training for the practitioners, and tools. Just learning the toolbox (language for writing specs, the tool itself, general verification strategies) that a practitioner needs can take a few semesters of grad school.

Big reason: writing requirements is hard. Because it's hard to document formally (ie, in a formal language - not English) the formal verification can't even get off the ground. Because requirements are hard, they take a long time to write and that costs money.

My colleagues from a decade ago are now professors in big Universities, teaching formal methods. Or they have taken industry positions with the companies big enough to pay for in-house practitioners and toolsmiths. When we talk about this we keep harping on what we learned long ago - writing specs is diamond hard, doing proofs is quartz hard.

Kelly

I designed a throttle control systen for a 32,000 shp steamship. The thing locked up and the steam valve wouldn't open. The turbine manufacturer (De Laval) blamed my servo, and I blamed their hydraulic actuator. During some hours of debate, the ship lay dead in the water out in the Gulf of Mexico, with the whole sea-trials set of officials (coast guard, owners, crew, yard people, tech reps like me) on board.

Turns out that they had a threaded block riding on a big leadscrew (the one my motor turned) that had two pins, one on each side, that fit into a big steel bar, with fork slots to meet the pins. (The other end of the bar was driven by the monster valve actuator, and partway down was the hydraulic control valve, which was the summing point of an mechanical-opamp inverter with a gain of about -3) When the angle was just right, the pins would ride up the slope of the slots, apply a twist to the threaded block, and the whole thing would seize up. I was about 19 years old, arguing with a bunch of crusty old steam engine designers, while everybody stewed in the heat, at about $30,000 per hour. The breakthrough came when they admitted, yes, they did recently change the design of the linkage. After that, it only took them five hours to fix it. The owners' rep ran out of Baby Ruths, so they flew some more in by helicopter.

John

Same experience (at about 150 to 200 kB working, well commented sources per month). The language has evolved into VPA, but the old CPU32 files do get assembled (compiled) for PPC as well. I will not (yet, at least) enter a C versus whatever debate, this is just to add to John Larkins point. Popularity does not mean efficiency, not so long ago the idea of a flat Earth was very popular.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

John Lark>

COBOL

in

vanilla

to

;-)

that

... snip ...

Still is, in some of the backward regions of the Earth, along with "Intelligent Design".

"I don't think Ganssle is realistic. What is the alternative to C?"

Not another text based language, for sure, but a higher level language that abstracts more easily to how humans think (like simulink, matrixx, they are a start but nowhere near what they should be). If you have to think about and use the concept of a pointer to get a job done then the language is a failure. How you communicate with a computer must be at a much higher level, we work at a much too low level now, errors just can't be avoided in any practical project.

No it wasn't. That's just a lie they teach to grade school kids to try to make it look like Columbus wasn't a fool.

Everybody with any education at all has known the earth is "round" for thousands of years. The diameter was measured to within 10% or so by two thousand years ago.

The big debate Columbus had with his detractors was about the size of the Earth. Columbus claimed it was about 40% smaller than it really is in order to justify his claim that sailing West to get to India wasn't insane. Everybody else knew how big the Earth was and told Columbus that he was nuts: sailing West was not the shortest route to India.

Everybody else was right. Columbus was wrong and was pretty much a clueless git who came ->

Actually it is text (alphabet) based languages, like English, which have been successfull in terms of technical progress. C (and other HLLs) is not alphabet based, it is too much hieroglyph oriented by nature (too much meaning in too few symbols). Humans are really good (well, some of them) at using a language at its complete flexibility, the more flexible, the better. Restricting flexibility (which is what all HLLs do because this is one of their purposes) only brings the need to get around the restriction - the higher the level, the more of these obstacles we get.

If we talk using computerised machines (say, office systems), yes, menus or whatever are great. Programming is a different job, though. We do need both the higher and the lower level at different moments while programming, we often have to switch between the two every few lines. I guess the much higher level you are talking about will eventually become practical, as soon as we can use everyday English to interactively explain the machine what we want and have it do the job. Until then, I'd stick to my VPA...

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

steve wrote:

Intelligent Design? haha, are those religious right wingers still pushing that?

-Isaac

Software engineering is a tool. Its a tool that needs to be used by a practitioner skilled in the domain in which they are working. In your example above, you are working down at the s/w h/w interface level. A good part of the domain knowledge (in this case) would be familiarity with the hardware you were working with. No EE worth his/her salt would even think of tackling this kind of problem without addressing the I/O timing requirements.

In the case of higher level systems, the hardware interface has been taken care of, but its the user interface and user domain knowledge that is important. Software engineering (not computer science), by itself is like going to trade school and learning how to use a wrench without learning how an auto engine works.

Its really a management problem. Compartmentalizing systems (and staff) into hardware and software frequently fails, but it seems to be a popular fad.

This can lead to another layer of proof. If you write out the spec in a formal language, you have to prove that this spec is what is intended before the verification really means anything. You may end up perfectly coding a mistake.

In theory, you can write a program that spits out random chunks of C code and then attempts to verify it. When it by chance hits one that works, you have your code. This turns the formal language of the spec into the source code for a very slow compiler.

For a fast single level, you could put the SEP that switched you back just above the entry point. This way when you jumped there the register was back at the entry point again.

In article , Isaac Bosompem wrote: [....]

'fraid so. It looks like God didn't use good design verification tools.

In article , Grant Edwards wrote: [...]

... or he fudged the numbers so he would get his funding.

That was certainly an irritating article. I don't have any idea what Ganssle thought he was saying.

Since C has been around for so long, and is so popular and well understood, C compilers usually generate excellent diagnostics.

Also, C debuggers usually work pretty well, unlike those for boutique languages. A good debugger does make the process less painful, if not actually fun.

Why doesn't he talk about the real killer: write only registers?

Or how about byte swapping? Shouldn't the industry standardize on big endian, before more people die?

Yes. Please.

-Mike

I program embedded systems in assembly. Abstraction = avoidance.

John