|
2004 |
|
pst |
|
fri |
BaronData was in trouble. Complete computer systems which they sold to court reporters at eight to ten thousand dollars apiece, plus a maintenance contract, to translate stenographer shorthand into plain text, a necessary tool of their trade, was about to be eclipsed by competitors using the relatively new IBM PC. Some competitors were actually giving away their product for free. This new wave was like a tsunami. I was to master and maintain the dinosaur, while other resources were poured into a BaronData flagship PC version to operate in real time. The court reporter would be keying shorthand into a specialized tablet, and plain text would be appearing on a CRT monitor at roughly the same time, maybe a sentence or two late. The dinosaur, written in (B*) DAZZLE, had an extensive bug list, maintained by the support group, which BaronData presented to new customers as a "feature list," sort of a list of warnings. It would be my job to reduce the length of that list. The (B*) DAZZLE program was spread over roughly four-hundred-thirty functions, procedures, and macros in about two-hundred-fifty physical files. So to examine the program, you would have to open each of these physical files separately, in a primitive text editor, and read it. I wasn't even sure about the name of the first file, though I did find someone who could tell me. They also told me about the buried treasure in all those files, which had been written by a star programmer who had left many years earlier; this buried treasure was why I had taken the job at BaronData. It was a programmer's secret you can't find in any book. The technical name for the secret is "execution overlays." You see, the output of the (B*) DAZZLE compiler would have two versions: the first would be an Assembly Language version for the development machine, which I would translate into an Execution module for my machine, on my monitor, at my desk, where I'd be able to test it. The second output of the (B*) DAZZLE compiler would be an Assembly Language version for the specialized computer being sold to court reporters. The trouble was, the final Execution module on this features-laden product was simply too large for its memory! The way out would be to program the entire system so that the final Execution module would be segmented into equal-size physical blocks, with a permanent ROOT BLOCK always in memory, bringing in other blocks (overwriting currently dormant blocks) on demand. This technology is called, "execution overlays," and for the case of an individually executing program, is not trivial. For one thing, it's real-time recursive, and if you want to get a flavor for recursion, read "DEADBEAT PAYING JOB" online, by Richard Ames Hart, in a separate browser window, until you get to this point, and fully understand you understand recursion. At which point, close that browser window; otherwise, if this is the only browser window left open on your desktop containing a version of that website, continue from here. Please note: the mental exercise you just encountered did not solve the memory problem. Each time you opened a new window to read a recursive version of this website, you used more memory on your PC or Macintosh! So there! The secret is still a secret. (Hint: I haven't told you exactly what part of the problem should be recursive, and what part shouldn't. Extra hint: a certain aspect of the dynamic memory map.) |
am |
|