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

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.

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

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.

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 f***ed it up :-) */

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.

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

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.

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

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

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.

I don't disagree.

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

:)

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

getting parts when they were promised.

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

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

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