From: Jonathan Kirwan
Subject: Re: To C or not to C
References: <email@example.com> <01c2b41a$cafe2d80$a893eb41@stupidwin95>
X-Newsreader: Forte Agent 1.92/32.572
NNTP-Posting-Date: Sun, 05 Jan 2003 20:11:23 GMT
Organization: AT&T Broadband
Date: Sun, 05 Jan 2003 20:11:23 GMT
On Sun, 5 Jan 2003 16:41:49 -0000, "Kevin Aylward"
>D Poinsett wrote:
>> Hi Kevin,
>> "Kevin Aylward" wrote in message
>>> The idea of not using floating point for certain types of
>>> mathematical software, e.g. spice, mathcad etc is plain daft.
>>> Indeed, you want higher levels mathematical constructions, e.g. a
>>> class for complex numbers to further reduce the details of routine
>>> multiplication and division. There is simple far to much going in in
>>> these types of programs to bother pissing about with something as
>>> basic as what a number is.
>> With the luxury of large memory and computational resources, you are
>> spot on right. In fact, some projects demand those kind of resources.
>> For smaller projects, especially embedded designs, those resources
>> would be inappropriate. In many cases, I could not afford the power
>> consumption budget let alone physical size and cost of anything but a
>> small 8-bit device. When speed and code-size resources are limited,
>> the choice of math routines can become an important consideration.
>I agree, its horses for courses,
>but I would probably try and change the
>course so that C/C++ could be used.
Not a bad idea, if other constraints allow.
>One reason is that for every person
>who can do asm, there are probably 10-100 times as many who can do C.
There is a reason for some of that. Good skill at assembly
operates at a different level of knowledge. One which is a
little more technical and detailed. There is a reason why
undergrad computer science courses introduce assembly as the 2nd
year, and not the first year, while usually introducing C as a
freshman class. (I've taught these classes.)
It's better to have skills at various levels of knowledge, from
assembly, to C, to BASIC, and so on. The more breadth and the
more layers one can mentally operate on, the better.
If the cost of the software system, it's development and
long-term maintenence, is your main 'unit cost', you'll probably
want to focus on C or C++ or some other high level language,
But if there are other competitive pressures, as there is in my
area where tiny size, extreme low power, high precision and
accuracy, precise input timing and output timing, and low
manufacturing unit cost (including calibration) are important...
then you might decide to hire the better skill sets to get the
job done. And those often include facility at several levels,
including but not limited to assembly programming. (You'll also
want good differential equations skills up through at least 2nd
order, some partials, familiarity with finite group theory,
various numerical methods, signal processing, physics... hmm...
perhaps someone like you. Can you do assembly? hehe.)
But just as for every analog engineer who can design from DC to
daylight, from transistor level to LSI IC level, there are 100
times as many who can only paste some digital logic together.
But there are times when you'd rather have the higher level of
technical skills because competition and the project area make
this a decided advantage. You simply can't always afford to use
an expensive DC-DC coverter brick, for example, when some PWM
software, a transistor, a coil, and a diode is all that's really
Assembly does come in handy, here and there. As you said,
"horses for courses."
>I would agree that the distinction is not really between embedded verses
>say, Windows or Unix applications, as there are large numbers of
>embedded applications where 100k to 1Meg+ code sizes are the norm.
There are, as evidenced by cell phones as just one such example.
But in my universe, placing a complex hybrid in a TO-8 can for
example, I don't get to have those kinds of nearly unlimited
resources. If I'm lucky, I have 4k of ram. An external memory
bus is simply not in the cards.
>Its the size of the project that matters.
No, that's not the determiner. You should be far more careful
of making such blanket statements, given your penchant to
warning others about making the same.
It's *all* the factors which matter. Not just the size.
>I would say that most projects
>nowadays are the big, difficult ones,
See below, I'll suggest one to you.
>all the easy ones have been done,
A far too blanket statement leading you to an incorrect
conclusion. First, because all the easy ones haven't been done.
Second, because even if they had, this doesn't say that assembly
is a bad choice for more complex ones (see above.)
And what the heck, let me give you an example of an easy one
which hadn't been done until I did it. I used a PIC12F629 as a
power-on reset, brown-out detector, product ID, plus EEPROM chip
with manual switch input for another CPU. Was easy and lots
cheaper than other options. Didn't take long to do and I can't
buy exactly what I needed off the shelf.
>well part from yet again another washing machine comtroller, but who
>wants to do them:-)
To each their own, eh?
>For me personally, I simply would not want to be involved in a project
>where you could only use 1k of RAM.
That's good for me, because you have all the skills needed to
compete well with me.
>Maybe some might get a kick from fitting it all in, but realistically,
>I don't see that there's any real meaty technical challenge to get ones
>teeth into with such constraints.
Some projects must be cooled. Let's say an example "hot side"
is limited by packaging and reasonable manufacturing costs (as
well as differential heating over the flat surface and
thermocouple effects) to perhaps 30mW total. But the signal
processing requirements include observing signal interference at
a few frequencies, both in phase and amplitude, so as to
properly compensate on the fly, using digital correlation
techniques. More, there are two sensors in the package and
Kalman filtering is used, with error covariances, to fuse or
combine these signals. It's a complex problem and one might
very well *want* to use C, but the power and size limitations
may force one to consider entirely integer techniques, and a
careful study of the mathematics using numerical methods, in
order to arrive at a product which will penetrate an important
>I find it much nicer to be working on systems where you don't have to
>worry about the lower level mundane details. There is a lot more
>interesting stuff going on, imo.
The reverse could also be said, Kevin. That the interesting
stuff is in dealing with those details in order to make a
product that does more with less than anyone else has managed
and thus producing a cheaper product with fewer elements needing
calibration effort and providing better repeatability and
accuracy, as well. A win-win.
It all depends on what tools you know and enjoy applying.