|
|
|
In the second half of 1982, I had the extreme good fortune of working with Jim Dowling and for his then-wife Teresa at General Electric on the Multi-Spectral Scanner image processing system for NASA's LANDSAT-4 and -5 remote sensing satellites. (This was at Goddard Space Flight Center, Building 28, in Greenbelt, MD.) Both were exceptional programmers and Teresa was a superb supervisor.
Jim lived and breathed computers and computing the way I did (and do). I remember him coming in one morning, very excited, and with the latest DECUS (DEC Users Group) 9-track tape under his arm. "They've got a Z80 cross-assembler written in VAX/VMS's MACRO assembler!!!" Although I was a Motorola 6800 man myself, I still shared his excitement.
40-year-old memories can be hazy! When I researched the DECUS tape recently, I discovered that the VMS tape included the Kermit (Wikipedia) file-transfer/terminal program distribution. That distribution included an 8080/8085/Z80 cross-assembler — just not a VAX/VMS one — for the purpose of building KERMIT-80 for CP/M on the referenced microprocessors. From the KERMIT-80 user's guide:
A cross assembler is provided that runs on the DEC-10 and DEC-20, called MAC80, contributed by Bruce Tanner at Cerritos College, that may be used for cross assembling KERMIT-80 as shown in this example (for TOPS-20) ...
The cross-assembler would generate an ASCII ".HEX" file
that could be downloaded (by hook or crook) to CP/M, which had a
built-in command to convert the file to a CP/M executable.
Of course, the Kermit distribution also included a native VMS version written in BLISS-32 (Wikipedia) and MACRO-32 (Wikipedia). (Some or all of the MACRO-32 code might have been generated from the BLISS-32 code.)
Jim was passing by my cubicle one day and stopped to chat. We somehow got to talking about dealing with errors in software and he shared his philosophy on the subject with me — two rules:
Report an error at as low a level in the program as possible.
Handle the error at as high a level as possible.
Simple and sweet. Almost obvious, you might say, but, looking back, I would say that it is not so obvious. I don't remember making any conscious effort at the time to incorporate these rules in my programming, but Jim's words stuck with me over the years and, 15-20 years later, his wisdom helped me understand why I was looking askance at certain software technologies.
... more to come eventually ...
... more to come about how the middlewares I've had experience with violate Rule #2 ...