another bizarre architecture

[John Devereux]

What a shamefull nonportable, unsafe and murky piece of code.

This is a way to go:

CURRENT calculate_current(VOLTAGE voltage, RESISTANCE resistance)
{
CURRENT current;

if(fabs(resistance) < VERY_SMALL_NUMBER)
{
throw BAD_RESISTANCE;
}
else
{
current = voltage/resistance;
}
return current;
}

Hey, that's C++! That's cheating!

 

[Jan Panteltje]

Hey, that's C++! That's cheating!

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;
}

*current = voltage / resistance;

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

return OK
}


hehe

 

[Ancient_Hacker]

This looks really weird to me...

http://www.maxim-ic.com/appnotes.cfm/appnote_number/3960

Does it resemble anything you've ever seen? It looks truly ghastly to
program.

I had the same opinion.

That and, maybe they did this soooo offbeat to avoid patent problems?

Computer architectures are usually screwy, cause the designers are
usually EE's, who have no idea what the programmers need, and vice-
versa.

 

[John Larkin]

You do realise that this is an implementation of the C standard
library? The behaviour of the functions is spelled out, in detail, in
the C standard, and any number of C reference books and online
references.

Suppose it turns out to have a bug. There's no indication of a
revision level, so every time you want to use this implementation you
have to (or certainly should) add your own comments as to where you
found it and when. And if a bug is ever found, will the one on the web
just change, so that you'd have to check every character against the
old one to see if anything has changed?

Or is the position that "since I didn't write this function, any bugs
are not my responsibility"?

What would you do, rewrite Windows XP in 68k assembler?

Microsoft gets rich off keeping you in the bug/upgrade loop, and has
convinced most of the world that all software has bugs. The biggest
software house on the planet has released tens of thousands of bugs
and vulnerabilities into paid-for products. Fortunately, all I have to
write, or at least all that matters, is hardcore embedded stuff, and I
do *not* use the methodologies that are accepted CS cirriculum and
that have given us Windows and Acrobat and the Oracle/SAP crap that
takes down entire companies. Put simply, I treat programming like any
other engineering function, controlled and documented, and it just
works.

If Only...

I've seen some. Each routine has a mandatory header, with fields like
"description of function", which is typically filled out with
something clever like "what it says."


Hey, here's some revision control:

*
* linux/lib/vsprintf.c
*
* Copyright (C) 1991, 1992 Linus Torvalds
*/

/* vsprintf.c -- Lars Wirzenius & Linus Torvalds. */
/*
* Wirzenius wrote this portably, Torvalds fucked it up
*/

 

[Jan Panteltje]

Suppose it turns out to have a bug. There's no indication of a
revision level, so every time you want to use this implementation you
have to (or certainly should) add your own comments as to where you
found it and when. And if a bug is ever found, will the one on the web
just change, so that you'd have to check every character against the
old one to see if anything has changed?

Or is the position that "since I didn't write this function, any bugs
are not my responsibility"?

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.

 

[CBFalconer]

No, you have to be able to read 'C'!!!!!!
I sort of like that link, maybe it is because I used DJ Delorie's
C compiler djgpp on MS DOS many many years ago...

<http://delorie.com/djgpp>

The DJGPP compiler is gcc, now using 4 up. 4.1.1 is available for
DJGPP at:

<http://ap1.pp.fi/djgpp/gcc/4.1.1/gcc411.html>

DJ's basic claim to fame is a library that mimics Unix and runs
under DOS, together with mechanisms to execute 32 bit code under
DOS. This is not a minor contribution. You can also use FreeDos,
and eliminate Microsoft entirely. It includes a good info page for
the C library.

 

[John Larkin]

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?

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.

*PLUS* schematics and pcb layouts are group reviewed before release.

How many people have other people read their code?

And if _you_ think it works OK does that mean there is no bug?

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.

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.

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

 

[Vladimir Vassilevsky]

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

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.

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

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.

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

The good thing he did was check for divide by zero.

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

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

 

[Vladimir Vassilevsky]

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

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

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.

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

Software is buggy
because of miserable programming methodologies and practices.

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

Mine's not.

What is your productivity/hourly rate ratio?


Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

 

[John Larkin]

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.

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

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.

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

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

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

What is your productivity/hourly rate ratio?

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

 

[Andy Peters]

Its been out for a while now - I don't see advantage over more
established cores like MSP430 and ARM. And lots of disadvantages.

Its primary disadvantage is that it's a Maxim part so forget about any
support, or being able to order less than a fab-run, or ...

-a

 

[John Devereux]

Suppose it turns out to have a bug. There's no indication of a
revision level, so every time you want to use this implementation you
have to (or certainly should) add your own comments as to where you
found it and when. And if a bug is ever found, will the one on the web
just change, so that you'd have to check every character against the
old one to see if anything has changed?

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 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.

Or is the position that "since I didn't write this function, any bugs
are not my responsibility"?


Microsoft gets rich off keeping you in the bug/upgrade loop, and has
convinced most of the world that all software has bugs. The biggest
software house on the planet has released tens of thousands of bugs
and vulnerabilities into paid-for products. Fortunately, all I have to
write, or at least all that matters, is hardcore embedded stuff, and I
do *not* use the methodologies that are accepted CS cirriculum and
that have given us Windows and Acrobat and the Oracle/SAP crap that
takes down entire companies.

I don't disagree.

Put simply, I treat programming like any other engineering function,
controlled and documented, and it just works.

And I am sure that they would say that this is what they already do!

I've seen some. Each routine has a mandatory header, with fields like
"description of function", which is typically filled out with
something clever like "what it says."


Hey, here's some revision control:

*
* linux/lib/vsprintf.c
*
* Copyright (C) 1991, 1992 Linus Torvalds
*/

/* vsprintf.c -- Lars Wirzenius & Linus Torvalds. */
/*
* Wirzenius wrote this portably, Torvalds fucked it up
*/

 

[Vladimir Vassilevsky]

John Larkin wrote:

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.

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

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."

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

http://www.abvolt.com

 

[John Larkin]

John Larkin wrote:



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

The project's not tiny, just the code.

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.

Oh, I forgot to ask:

in response to my...

Software is buggy
because of miserable programming methodologies and practices.

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

 

[John Larkin]

Its primary disadvantage is that it's a Maxim part so forget about any
support, or being able to order less than a fab-run, or ...

getting parts when they were promised.

John

 

[Vladimir Vassilevsky]

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?

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

http://www.abvolt.com

 

[Robert Adsett]

To even tell what the intent of a 100-line function is? The fact that
the comments are so few, and generally misspelled, suggest that what's
going on here is beyond simple inarticulateness.

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

 

[Didi]

The MC68332 is about old enough to vote, innit?

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

 

[John Larkin]

<snip>

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. 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

 

[John Larkin]

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.

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.

BTW, you complained about the FPGA design software. Are you willing to
pay 10 times more for it if they fix the major bugs?

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