another bizarre architecture

On a sunny day (Thu, 01 Feb 2007 19:27:21 +0000) it happened John Devereux wrote in :

Yea and it sucks, because 'throw' is not in libc in C. And throwing an exeption may not always be what you want, expensive missiles have unexpectedly returned to earth that way. Maybe a if a malloc() fails, and continuing has no perspective, but just as well you could in this case return to a GUI that asks for a correct user input, so returns SUCKS or return OK, report in the function itself, and determine in the calling what to do if it sucks. The good thing he did was check for divide by zero. So I should have written:

BOOL calculate_current(double resistance, double voltage, double *current) { if(debug) { fprintf(stderr,\ "calculate_current: arg resistance, voltage\n",\ resistance, voltage); }

/* avoid divide by zero */ if(resistance == 0.0) { fprintf(stderr,\ "calculate_current: resistance is zero, you have a super duper conductor,\n\ refer to sci.physics for help.\n");

return SUCKS; }

if(resistance < 0.0) { fprintf(stderr,\ "My-Program: calculate_current():\n\ Your resistance is negative (%.2f), you must be kidding right? Aborting.\n",\ resistance);

return SUCKS; }

if(debug) { fprintf(stderr, "calculate_current(): calculated current=%.2f\n", *current); }

return OK }

hehe

On a sunny day (Thu, 01 Feb 2007 12:11:41 -0800) it happened John Larkin wrote in :

There are many versions of libc, for example on this version of Linux I am now at /lib/libc.so.6 -> libc-2.3.6.so 9a (link to) And each version of the compiler that comes with it has its own bugs. It is not possible with all these million lines of source to check it all.

But if you buy a transistor or chip, and it has a bug (does happen does it not), then what do yo udo? And if _you_ think it works OK does that mean there is no bug? So you jus tassume the silicon in the processor is wha tit is, and you do not know about that near short or eroded / damaged track burried deep in the siliocon. See, you depend on the same thing the work of others. And those depend on _your_ feedback. Do yo uwant to take responsibility for a defective micro? It is all illusion.

First, I read the datasheet and appnotes carefully for any hint of gotchas. If we're doing anything unusual or risky or sole-sourced, we test a few actual parts as well. If a part/mfr is deemed acceptable, we enter that mfr and his part number into our materials database as acceptable for purchase to satisfy out in-house part number. We know which assemblies use each part, and can control it if, for example, only an OnSemi part should be used on a particular assembly.

And engineers around here *only* design with approved parts. To create a new library/inventory part, they have to get approval from the parts czar, who happens just now to be me.

How many people have other people read their code?

Well, we test things pretty hard. If a bug does turn up, we find out why and document the facts, and the actions to be taken, in an ECO. We know the configuration of *every single* product in the field, and notify users if the bug affects them.

siliocon.

It's no illusion that professional hardware design consistantly produces solid products and that professional software design often produces bloated, buggy crap. As I said, I use hardware disclipines to produce code, and that code inherits the simplicity and reliability of the discipline.

Software should be *more* reliable than hardware, since software has no inherent failure modes, isn't subject to temperature changes, power glitches, parts variability or EMI, and is precisely reproducable times a million copies... no solder joints, no part tolerances. Yet it's the hardware that's usually most reliable. Software is buggy because of miserable programming methodologies and practices. Mine's not.

This is sad: FPGA design, these days, is dominated with struggling with the software tools, trying to get the compilers to grudgingly agree to do what you know you want done on-chip, and then trying to get the compilers to run to completion without crashing. See comp.arch.fpga: it's mostly about struggling against the tools. The FPGAs themselves - the hardware - work fine. Xilinx 9.1 is just out - a 1.5 gig download - and SP1 is already out, another gigabyte. I wonder if they've fixed any of the memory leaks.

John

There is only one language: C++. The so called C is the malformed realization of C++, where you have to do classes by hand.

It is better to stay on the earth rather then fall on somebody's head. Masking the errors is the worst practice.

Come on, get real. Nobody bothers about checking the return value.

Only the amateurs check the floating point for == or !=.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

And this is exactly what the market is asking for.

To be gone for good, almost every project requires about 3 times more time and money then it can be allocated for it.

As I said, I use hardware disclipines to

Hardware is getting more and more disgracefull. Look at the 50-page erratas for the modern CPUs.

No. It is that way because everybody is happy and just likes it to be that way.

What is your productivity/hourly rate ratio?

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

Or 300. Bad methodologies, slash-and-debug, and write-only code are expensive.

That's mostly firmware bugs! My MC68332's have no bugs that I know of.

Not my customers. They don't appreciate aborting a jet-engine test, or grounding a JSF, or shutting down a pipeline.

I'll typically spend about 1-2 man-weeks on an embedded product program, generally around 4-6 klines of code, from start to formal release of bug-free code. It will take me more calendar time, 2x maybe, because I do other things, like design hardware and run a company. I do maybe 4 such projects a year.

I think one reason I finish software quickly, and spend very little time debugging, is because I don't really like to program, and as soon as it's done (and tested, and released) I can do stuff that's more fun. If I were a "programmer" I'd be looking to a future of nothing but programming, so my incentive to finish is reduced (I'd never "finish" programming) and the desire to play with clever resume-padding "productivity" tools (abstraction, C++, OOP, Java, whatever) would be a lot stronger.

One of my customers makes megabuck analytical instruments and the programming staff has fallen in love with Java and abstraction from the hardware. They're averaging about 6-8 bug announcements per week and it's "spinning out of control." There's a verbal shorthand around the company, DGMS, which means "Don't Get Me Started" complaining about the software. The hardware guys are gradually taking over more and more of the system functionality, to keep it out of the hands of the programmers, so they'll have nothing much left but the GUI to screw up.

John

No wonder. It is a tiny project for one man, where everything can be polished to perfection or at least kept under control.

It will take me more calendar time, 2x

The abstraction and the object oriented tools are the necessity. The common software developers are the bunch of donkeys with the incredible ability to screw up anything. However, forcing the bunch into a simple, sensible and formal development framework allows you to make use of them.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

The project's not tiny, just the code.

Oh, I forgot to ask:

in response to my...

you replied

"No. It is that way because everybody is happy and just likes it to be that way."

So my question is, have you personally accepted the "we're happy with lots of bugs" position?

John

Personally I still have the artistic feelings about the development, and I am striving to make the design neat and elegant. However I realize that in many cases the business perspective is quite different if not completely opposite.

But it does not matter what do we think. Money talks, and the example of Microsoft and Walmart is a clear indication of what people really want. BTW, you complained about the FPGA design software. Are you willing to pay 10 times more for it if they fix the major bugs?

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

My statistics are quite similar - about 150 to 300k source/month, (300 being doable only if I rewrite somehting I have done before). Just checked a "typical" file, about 40 characters/line on average.

But John, I am sure you don't seriously expect to turn the mass perception about how programming is to be done. Those who can get it already know it. The rest try to _be_ like MS, this is their success model... All of the above has not stopped me from trying to do the turn myself, of course - perhaps no less frequently than you have... :-).

Dimiter

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

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

But the assembly language which comes with it is alive. Available as a subset within my VPA, which happily produces PPC code out of it.

Dimiter

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

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

Yup. Freescale would like to kill it, but there are enough users that they can't. I've been told they are still soliciting new business for it. One of these days we'll get around to Coldfire, I guess.

It's a nice machine, a pleasure to program in assembly. It works like a hammer works, no drama, just pounds nails. The 64-bit math ops (gone from Coldfire) are especially nice in my business, doing stuff like timing 1000 seconds to 1 ps resolution.

John

WalMart is what people want; Windows is what they are forced to pay for and put up with.

Luckily, I report to no-one, so I'm going to write clean, documented, commented, bug-free code, just because I want to.

Since it's free, certainly! But you'd think that Xilinx would realize that we'd buy more FPGAs if we could get more designs done.

John

The MC68332 is about old enough to vote, innit?

Best regards, Spehro Pefhany

More than that is gone. I considered the Coldfire about 6-7 years ago (the version 4 was just coming out but already good to be being considered) and decided against it - emulating my CPU32 code would have been less practical than it turned out to be on the PPC. Most notably because of the missing addressing modes - you only have those from the 68000, all the 68020 modes are gone. I spent 4 registers on the PPC to emulate these etc., I have told you the rest of the story. But if you don't intend to use old sources on the CF you'll be fine, I guess. Sure the PPC family of embedded products of Freescale (and others...) is worth a look, though - the most consistent architecture I know of is the PPC.

Dimiter

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

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

--------------------------------------------------------------- Yea , so what , do you mean you DONT want to make a paycheck from it ?

If it was easy and clear , like Forth , there'd be no $$ , no opportunity to drag it out for weeks , the application would be done in hours , and that would end the carreers of millions of "hangers-on" to the computer free-ride .

Fortunately for the public , it will happen shortly and suddenly . no human will speak the word Software in the future . Using smarter and faster compression , computers will have tiny Op Sys and huge data bases and answer all questions . and cost $25 .

If your vc system tells you that two subroutine sources differ, what do you do? It certainly can't tell you *why* they differ, or how they might behave differently. For that, you must either read the comments and revision notes (lots of luck finding them!) or compare the code character-by-character and try to figure out what's going on. Or just use the latest one, on the assumption that any bugs aren't your fault.

Now, what do you do when 12 versions differ?

Yes, comments are nasty things.

John

On a sunny day (Thu, 01 Feb 2007 21:24:37 GMT) it happened Vladimir Vassilevsky wrote in :

Na Stroussup coul not program, C++ is a speech disability.

Yes that is true. But you have to try one day to fly.... Errors will show you where to improve.

You must be kidding right???????????

Yo uare somebody hwo does this?

FILE *fptr;

fptr = fopen("filename", "r");

fread( fptr...) BANG if file did not exist!

Always, as much as possible, I check return values. It is absolutely essential.

You must be programming for Microsoft :-(

Have to stay clear of that.

Although I share your sentiments about the whole software business in general, I must inject here that the C Library (at least all major implementations of it) is pretty much like 68332 in terms of maturity and stability. It's OLD, and its features have been carved in stone by the C Standard since almost 20 years (don't let me get started on the C99 Standard though).

robert