another bizarre architecture

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

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

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

On a sunny day (Thu, 01 Feb 2007 13:16:18 -0800) it happened John Larkin wrote in :

You are generalising I think. Look at Airbus fly by wire, _that_ is professional software with lives at stake. Probably reviewed a zillion times, and debugged as many times. My not professional Philip Expanium mp3 disk player skips parts of mp3 tracks, is it a soft or hardware bug? We will never know, I have a solid state mp3 player now. They have a only few weeks to market from design stage IIRC from my last visit to Eindhoven. No lives depend on that one, but they also make medical equipment, and I am sure that stuff is equally tested and debugged as that fly-by-wire software.

Words are only words and words....

Strange, as 'software' needs _hardware_ to run, and in many cases, _especially_ embedded, is specific to the hardware, difficult to separate. Hardware can function without software. Software cannot function without hardware.

I hope the simple example of calculating current has shown to you that there are many many issues with software, and many different approaches, and not everyone even agrees on what is best... In compiled languages often it is not clear what exactly the compiler generated, optimised away, combined, etc..., unless you look at the generated asm or single step, maybe even with an ICE. Just because you are no programmer, you do not see, or have not encountered, problems related to that,

Na.

Oops, I like the claim to perfection though :-)

Yes I was one of the first ones reporting to have it working in Linux. My version works fine, but I mainly use scripts and makefiles in Linux. And not very big projects. But the issue is not so much the ISE (or xst) but the design itself... you can make it as difficult as you want for yourself and the tools.

Mm, maybe it leaks, but who cares with 160 GB swap space (kidding ;-) ). You remind me to run 'vmstat' a couple of times next time, if it really leaked _that_ bad I should have noticed on my filter design.

I have been reading up on Virtex 5, now that is nice hardware, have not used one yet.

On a sunny day (Thu, 1 Feb 2007 20:38:15 -0500) it happened Robert Adsett wrote in :

I agree that more comments helps. But in spite of that, a deeper knowledge of the various interconnects is required, that cannot be put even in several pages of text (and who would read these). Take for example this newsreader (NewsFleX), I think I wrote it 10 years ago, and because of user requests features were added over time. If I have to program (say change) anything in it, it takes maybe a day but at least some hours to 'remember' how all stuff interacted. I have received 'patches' that I applied, and these then screwed up something else because the person doing the patch did not know how all stuff interacted. And NewsFleX has a ridiculous number of comments in the code. And in some places none whatsoever :-) As the other poster pointed out: I does what it needs to do, it has a problem once in a year, I am in the process of finding that bug, but after 3 years it is still there and it does not bother me, and everybody is happy.. So low priority issue.

I wrote the program for a purpose: A wanted a free agent like news reader in Linux. It does that. No claims to perfection, if there is a real problem I will fix it if I think I still need it. Is not that the way the whole world works? I never believed in perfect Utopia. Flowers flower for the bees, to multiply, they make nectar for that. As much as needed when needed.

... snip ...

At one point I used to include a function to report the modules version in each complete module. This allowed users to programatically check for suitability. By also including a #define in the header, this can be expanded to compile time checking. The latter is awkward, since it involves altering the header with each revision, which is counter-productive. Leaving the header alone ensures that a revised version is fundamentally compatible with earlier versions.

Deadlines. That's another reason for the software to be the far from perfect.

BTW, this world is created in the way that it is better to be the first then to be the best.

By MISRA rules, if a function returns an error value, this value should be checked. However not checking the return code is the very common mistake. The exception mechanism was invented to prevent this sort of mistakes.

And nothing happens. The error is unnoticed, fread() reads the garbage, the garbage is processed, and there is garbage at the output.

Good for you. Have you ever wrote anything longer then "Hello World" ?

Yes, I would really like to have MS on my client list.

Keep out. Dealing with the idiot is not worth money.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

That's seomthing I'll never understand. Why would they want to kill it? Everything's just there; all they have to do is just make the damn things. It doesn't cost them a bit, so why stop?

robert

But these are very small projects, in software terms. Any half-decent programmer can do that, no matter in what language. It's the huge, millions-of-lines codebases that break.

I once wrote (as an external contractor) a module for an intranet application. The CTO of my customer really wanted me to use Java just because it was "that's what eveybody uses these days". But since they couldn't find anybody else (those were dot-com boom days) they had to make do with the guy who used a language they'd never heard of -- C.

Last thing I knew was that their application never really got going, except for my bit which worked 100% right from the start.

I remember those panicky calls I got from them: "There's a bug in your module". Panicking myself I rushed into their office, only to see that

--again!-- they had fed invalid data into my module. This was easily demonstrated because it had been *me* who wrote all the specs. Billed them big bucks for that wasted time. Now they are broke.

robert

Perhaps the profit margin is wider for the new stuff.

Grandpa's processor. Ya know, it is not c00l any more :)

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

So, you will actually release software that you know is buggy, or that you haven't tested, because of some schedule? Please tell me who you work for, so I can be sure to never buy their stuff.

John

It's made on some older fabs that they might prefer to retire.

What they really ought to do is port it to a modern CMOS line, cut the die size by 4:1 or so, and run it at 100 MHz!

I have, incidentally, recently tested the 16 MHz, 3.3 volt version at various clock rates. It seems to fail at 45 MHz, so we've decided it's safe to run them at 20.

John

Well, this is sci.electronics.design, not some Windows app group. But I do see people using C++ class structures to set a bit in a parallel port, in the name of abstraction. Why would an embedded programmer seek abstraction, other than they don't actually like programming hardware?

But of course the big projects break; just look at the undocumented, uncommented, barely-tested, tangled messes they call subroutines. Nobody can build a reliable big system from the sorts of junk modules I see. The failures are wired into the culture.

Bad programming has killed a lot of companies, and a lot of people. We are living in the dark ages of a mess they like to call "computer science." The existing orthodoxy, most of the time, works poorly or not at all.

John

One of my best customers makes jet engines. The engine control computers are mounted under the engine cowling, in the airstream, and the engine fuel runs through the computer before being burned, to moderate the CPU's temperature swing. The programs have no bugs, because they are careful, work at the lowest possible levels of abstraction, use no OS, test exhaustively, and are entirely pragmatic about the consequences of a jet engine failing. And most of the "programmers" are actually engineers.

John

John Larkin writes: [snip]

While programming is not subject to mechanical failures, it is susceptible to other kinds of failures including failures of the underlying hardware. Then add the usual expectation that the programming should be able to compensate for if not recover from hardware problems and you've elevated programming reliability to a wholly different level.

Those are your speculations. I have never said that.

However, at the end of many projects, I know that it would be better to do the certain things different way.

Get real. From time to time shit happens to anyone, and only fools deny it. And in many cases it is more efficient to have certain allowance for the fault, rather then trying to polish everything to perfection. That's why most of the software and the hardware around is a crap, however it is cheap and available.

It does not matter if you like it or not. It does not have anything with me and my attitude. This is how the things are, and I am just trying to answer your question why everything is so bad.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

One reason might be that they want to retire the process. It could cost too much relative to the profits they can make elsewhere to adapt the design to the new process and deal with all the changes in characteristics, so they kill it.

Best regards, Spehro Pefhany

How much lower does it quit at the high temperature extreme?

Best regards, Spehro Pefhany