Lack of bit field instructions in x86 instruction set because of patents ?

I think that you have misunderstood his point, perhaps because it was a bit subtle. Let me add the line you snipped, which occurred after his name:

I am pretty sure that what he meant is that you can look at software and tick the box marked "High Quality" - that's easy to do :-) I am equally certain that he meant that farce is about all you can do.

Regards, Nick Maclaren.

What he means is that the software & firmware for his products work. He does it the old fashioned way by printing it out, reading the printout, and making lots of notes on the wide carriage paper, instead of dumping a bunch of crap into a compiler time after time, till it compiles into something that almost works. Look at his company's website to see what he builds, and who buys it.

A lot of software should be composted, not compiled. :(

How else are you going to get quality other than by inspecting the code?

We write embedded code and *read* it, and tweak/rewrite it, several passes before we actually try to run it. We spend 80% of our time doing that, 20% testing/debugging, and ship 100% bug-free products.

Did I talk fancy? OK, one of the words did have three syllables. Sorry.

John

That's not what I meant.

John

By designing it to be of high quality, and by using methodologies that maintain that through the coding?

Look up CICS and Z.

Regards, Nick Maclaren.

We throw a lot of code away, and rewrite it constantly when hardware specification changes. That's life in the R&D. When you are re- inventing the wheel it's easy to make fancy design documents and such, because you already know what the f**k you are doing in the first place.

Not so when you are doing something new. If you could write the design document it's based on something that you know already.. so where's the research part in the R&D?

I work in a field where the design is customer driven. They make roadmaps. We make our roadmaps to align with theirs. We look at what we have in our inventory, what new stuff the research has come up with. Then we plan. We come up with number of proposals.. they are introduced to the customers, shot down or looked into further. There are many different outcomes from this.. two common ones are the one where we agree what the product specification should be, more or less, and sign a contract to do the development. The other approach is that we design products on our own, come up with a platform or discrete product we want to license.

During this process there is a team of software engineers who work with the hardware engineers, who constantly update the spefication based on customer _and_ software requirements. It's ideal when they are similar so that compromise does not need to be done.. if you can put something in silicon that saves CPU time to setup stuff, that's great.. but it might consumer more power and exceed the power budget for the part.

And so the software is changed, revised, rewritten. It's alive entity. The KEY is to have a framework that is easy to modify and adapt to changes in the environment the software has to live in. These include different processor architectures, operating systems, system components, memory bus type, latencies of various things, timings, availability of mmu and so on and on.

If a guy comes and says with a straight face that he has a nice solid good design document for the next generation product, I can show you a pretty awesome liar.

At some point the design does come together, so to speak, after various models have been benchmarked and tested and stressed out. This is the time to draft a design document and let the technical writer(s) to do their magic. The goal of the document isn't as much to keep the design and software teams in sync or aware what they are doing; they know that already from 100's of meetings all the time. It is for the end-user of the part, so that they can integrate it into their products and doing it while they actually UNDERSTAND the design philisophy and all that goes with that. It's not just inputs and outputs, but it's a great deal if it were that simple. =3D)

Of course, if you can do the design ahead of time, that's awesome. Sometimes you can do that. But when you can't, see above for example, it's not fair to claim that any other way is wrong.

This CICS?

It ought to be fairly well debugged by now; it's been in development for 40 years. Do you think it was bug-free as first shipped?

We don't take that long to write and test our code; a few weeks is more like it. And we do ship the first units bug-free.

John

I know a great deal about that scenario :-) An even more extreme one is genuine research programming, where you often can't even tell whether a design will be workable until you have tried it! I have often thrown away programs after getting them working because, while the code worked, the algorithm didn't solve the problem - and the reason I hadn't analysed it in advance was that it was theoretically intractable (and I could prove that!)

But it's not the point, which was that of getting very high quality software (in RAS terms), preferably bulletproof. And the continual rewriting approach does NOT deliver that!

Regards, Nick Maclaren.

Yes, that CICS.

Close to it. As I said, look it up - its development was interesting.

Either you are tackling a trivial task, or your definition of bug-free is a little lax.

Regards, Nick Maclaren.

Nick, it sounds like you're just looking for an excuse to write sloppy code.

If you'd bother to learn the difference between your elbow and a hole in the ground, then you. too, could write bug-free code!

I've been writing bug-free code for decades - all you have to do is pay attention! ;-)

Good Luck! Rich

in the 60s, the university library got a ONR grant for online library catalogue, and got selected as beta-test site for original CICS product. one of the things i got tasked to do (as undergraudate) was initial support/deployment. I did some debugging related to CICS having been originally developed at a customer shop for specific operation ... and the university library was different kind of operation.

a lot of CICS performance came from initializing the environment at startup ... and running that way for extended period of time. the other was that user/customer written code ran effectively as small library routines as part of the CICS code (in the same address space). this resulted in some integrity issue since a bug in the user/customer code would take down whole CICS system. while CICS did its own multithreading ... multiprocessor support was difficult for it to support.

As systems moved from real storage to virtual memory operation ... and increased in size ... the approach to use all the additional resources was to run multiple CICS in parallel on the same machine.

A few years ago the 3rd party that provided most of the dataprocessing services for the cable TV industry ... not just billing, statementing, accounting ... but also downloading commands to settop boxes ... was running over 120 CICS regions.

Relatively recently, a huge amount of redesign work has gone into changing things so user/customer code wouldn't corrupt CICS ... and also to be able to support multiprocessors

CICS history

Evolution of CICS: CICS and Multiprocessor Exploitation (2004)

CICS 35yr site (2004)

misc. old posts mentioning CICS and/or BDAM

No and no.

John

I agree with you, John, although hopefully even you would admit that something on the order of complexity as Windows/Linux/Mac OS is effectively impossible to create (on a reasonable schedule) without some bugs.

Heck, even X Windows (the core GUI code and various support applications that Linux/OS X run on) has thousands of bugs:

It'll be interesting to see what his chart looks like after a handful of years -- e.g., what the overall slope is.

---Joel

"Paying attention" is part of it, but saying that by itself is not particularly helpful when trying to train other people in the art of zero-defect software development.

Yes, it *can* be done, and for sizable projects [e.g., communications processors], but it's *expensive* [manpower-intensive], takes about

Zero-defect software development *can* be done, if it's important enough. Back when I was working for DCA in Atlanta[1] in the late 1970's, there was a lengthy period where we were *so* cash-strapped that we simply could not afford to send out firmware update PROMs to all of our customers if we made a big mistake on a major release. The cost of the largish UVROMs of the day that we were using for the embedded firmware times the large number of (cheap) boxes in the installed base was more than a month's payroll! Since we wanted to continue being paid, we were *very* careful *not* to ship any showstopper bugs! And we were successful[2], even though the code was all in PDP-8 & Z-80 assembler!

But, yes, it's expensive & slow, compared to "hack & pray" methods...

-Rob

----- Rob Warnock

In alt.lang.asm John Larkin wrote in part:

Many, many ways. It is a big topic. Usually divided into two areas: pre-production (project design, coding standards) and post-production (walkthrus, measurement and testing).

Embedded has even worse problems: interrupt clashes and SCR latch-up to name two.

-- Robert

in part:

Interrupt clashes?

John

Yes, though "zero-defect" merely means that the probability of a defect is very, very low - there is always a chance of something completely unexpected - such as the established mathematics of a field having an unrecognised flaw (which has been discovered several times in the past 50 years).

And "design and code methodically" is only expensive and slow if you are costing only up to initial shipment - adding in the normal early release "maintenance" costs often makes it a lot CHEAPER. But that's NOT the same as your full "zero-defect" procedure (snipped), which I agree is expensive and I have never been involved with.

Regards, Nick Maclaren.

Yup, definitely someone inspecting their cluelessness.

Phil

wrote in part:

I'd also highlight the importance of selecting the appropriate tools (language/compiler, etc) for the project. IMO many trivial and embarrassing bugs are a result of using tools that are too complicated to understand and work with without making a mistake either due to inattention or because of pure misunderstanding (I mean C/C++).

And while it would be nice to finish coding first and then do testing and bugfixing (as I understood pre- and post-productions), it seems like it doesn't usually (=3Dnot always) work well that way. Putting off testing until the end of the development phase and not knowing what you've built is asking for trouble. On the other hand testing in a changing environment (whilst still developing and even designing) isn't very pleasant but gives some information during the development process, not when it's too late.

Testing is great, but it's not a panacea and there're issues associated with it. The code needs to be testable (designed for testing -- how many consider and actually do this?) in the first place. And even when it is, you may not have enough resources (processing power and/or time) to test it thoroughly because it's too complicated (or probabilistic -- would that be the right word, considering various forms of concurrent processing/execution and synchronization?) and there're too many states (both independent and dependent). Even with 100% code coverage (already a practically (=3Dusually, not always) impossible figure for a 100K KLOC project) you don't necessarily have a nearly comparable state coverage, which is as important as the code coverage.

It's not just embedded if I may exclude the PCs. Just yesterday I discovered a bug which wasn't a bug in our software (which was correctly implemented to the spec and the spec was correct too) although at first glance that was plausible, but appeared to be a bug in either the CPU or the circuitry around it. Turned out to be the circuitry -- the manufacturer decided to cut some corners and violate the spec and render our code incompatible with their hardware (or the other way around). And they're not fixing it. Their excuse? Nobody does what was done in our software because of perf issues. And those perf issues weren't issues in that code of ours, it wasn't something very highperforming, it was sufficient to just have it functionally correct.

Alex