This has gotten a bit OT, don't you think?
Maybe the two of you can continue this
topic in private emails. Thank you.
William Garber
Email Address - willy46pa@garberstreet.com
Alt. Email - willy46pa@comcast.net
Web address - http://www.garberstreet.com
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 8rSdnb9dx6HeA8HanZ2dnUVZ_oimnZ2d@comcast.com">news:8rSdnb9dx6HeA8HanZ2dnUVZ_oimnZ2d@comcast.com...
: Michael J. Mahon wrote:
:
: > glen herrmannsfeldt wrote:
:
: (snip)
:
: >> And written in some special language (like P-code or JVM code) and
: >> interpreted. The operations are all generated by macros for the
: >> OS/360 assembler.
:
: > It was a requirement imposed by IBM that the standard IBM tools
: > be used to create the compiler, hence OS/360 assembler.
:
: > All of Digitek's compilers were produced using the same approach--
: > they were written on a virtual machine with multiple (32? 64?) stacks
: > as operands, and the input stream and output (code) stream.
:
: > After the compiler was running interpretively, the interpreter
: > profiled the interpreted code (in the other half of memory), then
: > the macros were tagged to generate either 1) the interpreted op,
: > 2) a quick linkage to the "execute routine" of the interpreter,
: > thus saving the fetch and decode overhead, or 3) an in-line
: > expansion of the execute routine, saving all interpretive
: > overhead.
:
: Hmm, a little like what IBM did with VM and microcode assist.
:
: > Normally, expanding just a few percent of the code resulted in
: > near native code performance, leading to the smallest, fastest
: > compilers extant, particularly on small memory machines.
:
: And the problem of writing compilers for small memory
: machines makes this relevant to this newsgroup.
:
: > The FORTRAN G (128KB) compiler has a special history. It was
: > commissioned as FORTRAN E (32KB)(or F (64KB), I forget), but it
: > ran faster in less memory than the IBM-produced FORTRAN G, so it
: > was "promoted" to be FORTRAN G--making it the smallest G-level
: > compiler, by far!
:
: The memory needed depends on the size of the program.
: The PL/I (F) compiler was supposed to be able to compile in 44K
: (That is, 64K machine minus 20K for OS). To do that it might
: have to keep the symbol table on disk. (The one thing you would
: expect a compiler to always keep in core.) At the end of compilation
: it tells the minimum region size needed to keep the symbol table
: in core.
:
: > IBM also had a religious committment to the use of the peculiar
: > 3-register setup BXLE op for closing DO loops (which is what it
: > was designed for). The Digitek compiler used normal ops for DO
: > loops, usually resulting in smaller, faster code. But, under
: > contractual pressure, they relented, and every DO loop closing
: > was replace by a LM (Load Multiple) of the usual 3 registers,
: > followed by the BXLE--one of the few cases I recall of "protest"
: > code generation! ;-)
:
: I do remember that IBM preferred the end test DO loop, such
: that many believe that Fortran 66 requires it. It doesn't,
: but it does allow it. (Technically, a loop with the end
: value less than the start value is not legal.)
:
: > Digitek compilers were very portable, requiring only three
: > interfaces to the OS: read a line, print a line, and write
: > a buffer of code.
:
: Both G and H use the same runtime library. The G compiler
: has an interesting debug feature that H doesn't have, that allows
: putting debug statements at the end, in a debug packet, but
: to have the effect of inserting them into other parts of the
: program.
:
: -- glen
: