oops, bit vectors - not Re: struct bitfields - Re: C trivia - was Re: Dennis Ritchie has died

On 16 Oct 2011 at 14:17, Toby Thain wrote: Early in my career, I was placed under the tutelage of a consultant-- an ex-IBMer who was quite an authority on COBOL--he was part of the old COMTRAN team as well. He came to California and "found himself"-- but that's another story. The task at hand was a translator between dialects of COBOL. Ours was a multi-processor transaction-oriented system with communicating multiple threads, shared variables, etc. This was long before the "Dragon Book" or even YACC (I'm not sure how amenable YACC is to COBOL at any rate). He'd asked me how I would go about writing such a translator. I responded that the simple way would be to use a specialized language such as SNOBOL or perhaps even FORTRAN (our options were pretty limited back then) and then refine the result. He opined that I'd missed the point of the question. He then proceded to explain his idea of how to go about it. He proposed a fictitious machine that, instead of bits and bytes, handled abstract data types, such as tokens and had a very simple set of instructions that could query and alter properties of tokens as well as generate some on its own. It had its own symbol table primitives as well as a way to generate output. I was a little dubious, but we put it together anyway; we invented some instructions and the support software for this machine (my job) and wrote a bunch of very funny-looking assembler code using the macro facility of the assembler. The initial run was ready in an amazing 3 months--far faster than anyone had anticipated. We had customers trying it out on their own code and reporting back problems, which were taken care of rather simply. Because of the huge macro content, assembling the translator took the better part of an hour (on one of the fastest CPUs of the time). And because execution was interpretive, it was awfully slow. The next step was to rewrite the macros for the instructions to have them generate native code and demote the interpreter to a bunch of support routines for the native code. Things sped up by almost an order of magnitude and the end result turned out to be extremely stable, so much so that my job and his disappeared and maintenance was turned over to the COBOL compiler group, who didn't udnerstand one iota of what it was about. I learned a lot from that process and when I had to turn out a full business-oriented BASIC for the 8085 years later, we implemented the whole affair in 6 months (compiling to a type of P-code) and had a compiler-and-runtime that ran programs considerably faster than BillG's compiled BASIC. I received a note a couple of months ago from an ex-dealer who informed me that, as far as he knew, the BASIC was still in use, running on Unix, although said customer was attempting to make the leap to Visual BASIC and Windows. Nova Try some of the mainframe assemblers. Even late versions of MASM aren't too terrible. On the other hand, the AVR assembler feels as if it was written by an intern. While I can use it, I loathe it. --Chuck