Re: Question on ProDOS SmartPort drive remapping

[pausch@saaf.se (Paul Schlyter)]

In article <a72dndTHw78mUcHanZ2dnUVZ_oGjnZ2d@comcast.com>,
Michael J. Mahon <mjmahon@aol.com> wrote:
>glen herrmannsfeldt wrote:
>> 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.
>
>And the size of the program being compiled was generally small
>enough to be able to be run on the compiling machine, which helps
>prevent pathological situations...
>
>>> 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.)
>
>I don't know about FORTRAN 66, but the standard for FORTRAN
>always used to be that a DO loop body executed at least one
>time--meaning test at the end.

Only up to FORTRAN-66.  Starting with FORTRAN-77, a DO loop
could execute zero times -- and loop variables could be
floating-point numbers as well.  This of course required that
the generated code had the test at the beginning of the loop
(with the possible exception of the loop limits being constants
in which case the number of times the loop would execute was
known in advance -- zero times and all the loop code could be
completely elinimated, once or more times and the test could be
at the end of the loop.

>Of course, the original code the Digitek compiler generated
>also tested at the end--it just didn't require jockying the
>registers around to make BXLE happy, and didn't require getting
>the increment into a register.
>
>BXLE was a misguided attempt to close the "semantic gap" between
>high level languages (which FORTRAN actually isn't) and machine
>language.  If if was natural to use BXLE (Branch on indeX Less
>than or Equal), fine, but to require that a third-part compiler
>use it for every DO loop was evidence of comical misunderstanding.
>
>>> 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.
>
>I'd forgotten about the debug packet.  ;-)  That was handled
>entirely by the compiler and runtime, IIRC.
>
>The FORTRAN runtime consists of two main parts:  the math library,
>much of which is often written in FORTRAN, and the FORTRAN I/O
>library (co-routines, actually) which are a major chunk of code
>that cannot be written in FORTRAN, and so is usually in assembler.
>
>The FORMAT statement was a real timesaver for programmers, but a
>real bear to interpret at runtime, with its implied DO loops, etc.
>
>-michael
>
>NadaPong: Network game demo for Apple II computers!
>Home page:  http://members.aol.com/MJMahon/
>
>"The wastebasket is our most important design
>tool--and it's seriously underused."


-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/