another bizarre architecture

[Spehro Pefhany]

On Thu, 01 Feb 2007 21:41:03 GMT, Vladimir Vassilevsky


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

<snip>

The MC68332 is about old enough to vote, innit?


Best regards,
Spehro Pefhany

 

[Didi]

...The 64-bit math ops (gone from Coldfire) ...

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

 

[John Larkin]

You use a version control system. A library like this would be
maintained and released as a unit, i.e. there will be an overall
version number like e.g libc 2.1.

Using a version control system it is easy to see exactly what has
changed between revisions, anywhere in the library. This saves having
to examine each file individually to see if its version number has
changed.

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?

If you really want to you could use the version control system to
automatically insert a comment with the file version number, but I
think this is not used much these days. At least I don't; it clutters
up the file.

Yes, comments are nasty things.

John

 

[Jan Panteltje]

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

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

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

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

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

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.

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

You must be programming for Microsoft :-(

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

Have to stay clear of that.

 

[Robert Latest]

["Followup-To:" header set to sci.electronics.design.]

Suppose it turns out to have a bug.

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

 

[Jan Panteltje]

It's no illusion that professional hardware design consistantly
produces solid products and that professional software design often
produces bloated, buggy crap.

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.

As I said, I use hardware a to
produce code, and that code inherits the simplicity and reliability of
the discipline.

Words are only words and words....

Software should be *more* reliable than hardware, since software has
no inherent failure modes,

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.

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.

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,

Software is buggy
Na.

because of miserable programming methodologies and practices. Mine's
not.

Oops, I like the claim to perfection though

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.

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.

I wonder if they've fixed any of the memory leaks.

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.

 

[Jan Panteltje]

I use C, it's now probably my 'mother tongue' for programming and I
have to agree with John on this. The comments are too sparse and
worse in the one other function I looked at (to see if more complex
functions were done better), the file header comment was completely
wrong. It's the sort of file where if you already know what's
happening and what it's supposed to do you can follow it but if you
are new to it or have been away for a long enough period to have
forgotten then you will be in for a hard time. The functions assume a
lot of knowledge that is not in the files and there are no pointers
external references containing the missing information.

Robert

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.

 

[CBFalconer]

.... snip ...

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.

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.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

 

[Vladimir Vassilevsky]

Jan Panteltje wrote:

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

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.

You must be kidding right???????????
Yo uare somebody hwo does this?

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.

FILE *fptr;

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

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

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

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

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

You must be programming for Microsoft :-(

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

Have to stay clear of that.

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

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

 

[Robert Latest]

["Followup-To:" header set to sci.electronics.design.]

Yup. Freescale would like to kill it, but there are enough users that
they can't.

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

 

[Robert Latest]

["Followup-To:" header set to sci.electronics.design.]

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.

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.

One of my customers makes megabuck analytical instruments and the
programming staff has fallen in love with Java and abstraction from
the hardware.

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

 

[Vladimir Vassilevsky]

That's seomthing I'll never understand. Why would they want to kill it?

Perhaps the profit margin is wider for the new stuff.

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?

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

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

 

[John Larkin]

Jan Panteltje wrote:



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

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

 

[John Larkin]

["Followup-To:" header set to sci.electronics.design.]

Yup. Freescale would like to kill it, but there are enough users that
they can't.

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

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

 

[John Larkin]

["Followup-To:" header set to sci.electronics.design.]

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.

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.

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.

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

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

 

[John Larkin]

You are generalising I think.
Look at Airbus fly by wire, _that_ is professional software with
lives at stake.

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

 

[Everett M. Greene]

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.

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.

 

[Vladimir Vassilevsky]

John Larkin wrote:

So, you will actually release software that you know is buggy, or that
you haven't tested, because of some schedule?

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.

Please tell me who you
work for, so I can be sure to never buy their stuff.

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

http://www.abvolt.com

 

[Spehro Pefhany]

["Followup-To:" header set to sci.electronics.design.]

Yup. Freescale would like to kill it, but there are enough users that
they can't.

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

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

 

[Spehro Pefhany]

["Followup-To:" header set to sci.electronics.design.]

The MC68332 is about old enough to vote, innit?

Yup. Freescale would like to kill it, but there are enough users that
they can't.

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

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

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


Best regards,
Spehro Pefhany