legalize at xmission.com
Tue Apr 4 22:37:57 CDT 2006
In article <200604050313.k353DEvL019892 at mwave.heeltoe.com>,
Brad Parker <brad at heeltoe.com> writes:
> clearly I am living too high on the hog... basking in the luxury
> of having a stack and all :-)
On the other hand, I've worked on the reverse.
A huge assembly language program that should have been written in C.
(Hi Fred Brooks!)
It was 1986 and I was so fresh out of UDel's EE department with my
degree that the chairs were still warm in the classroom from me
sitting on them. I got a contract job with the Glasgow facility in
DuPont (yes, *the* DuPont of Delaware). Glasgow was their medical
instrumentation division and they had bought out Sorvall, a company
that makes high-speed centrifuges.
I mean really high speed, like 50,000 rpm? (my memory is fuzzy on the
exact number, at least 10k). High speed enough that if the rotor
got loose from the motor shaft, it would turn you into hamburger.
They deliberately failed one of the rotors in a test chamber lined with
6 inch thick oak. The rotor made a 3 inch dent. But I digress....
They hired me as a contractor as squeeze labor to help get this software
done that they had been writing for the front panel user interface.
It was a 6809 processor with a membrane keypad (newish idea at the time),
some LEDs and a 2x40 character backlit LCD display. It communicated
to another 6809 processor that ran the motor. (Thank god the UI guy
didn't do the motor code or I would be scared.)
This project was being poorly managed and it was also being poorly
engineered. The UI panel code had somehow ballooned into 100,000
lines of partly commented 6809 assembly language code. It had a
floating-point library and was doing complex scientific calculations
and had a fairly elaborate menu for programming in various centrifuge
tasks. At one point I analyzed a data path and saw a number get
converted from integer to fixed-point to floating-point, do some math
on it, floating-point to fixed-point and converted back to integer.
This was just one example, the whole thing was a rat's nest of
When I signed on, we were using a cross-compiler on a PDP-11 (I think
it was a /34 or a /45 running something with a versioning file system?)
and were not using linkable object modules. Instead if you made a change
you had to reassemble the entire 100,000 line mess of source files.
It took 8 hours to assemble the output file for the test harness.
I reworked all the source files to export the entry point symbols and
import the symbols called by that source file. Since there were
hundreds of source files, this took a while, but was easy to do. Then
I could assemble the .asms into .objs and link .objs together to get
my final output for the test harness. This cut the edit/compile/test
cycle down to about 45 minutes (it still took a long time to link).
The target environment was pretty resource rich on the PROM and RAM
side, This was not a machine that was starved for resources, but it
was being treated as such. During the time I was there, I could have
single-handedly rewritten the entire thing in C using a cross-compiler.
Instead I was instructed to use assembly language, which I did. Aside
from homework projects, this was the only time I've really had to use
assembly language for anything work related. Had I rewritten it, I'm
fairly certain that the ROM image would have been smaller and I'm
absolutely certain that there would have been fewer bugs.
At one point, after having repeatedly embarrassed the lame engineer
who was coding the UI by fixing his bugs, he accosted me in the
hallway and told me (and I quote): "Your job is not to fix bugs. Your
job is to do what I tell you to do."
Umm...yeah. That pretty much sums up what was wrong with that project :).
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
Pilgrimage: Utah's annual demoparty
More information about the cctalk