Re: compiler bugs

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> (John wrote)


> [Yup, HX, same program. I gather HX has the same broken optimizations
> that H did. In its defense, Fortran H did have to invent a lot of the
> analysis techniques it used, and run on a 128K (for the young folks, yes,
> that's a K) machine. -John]


If it generates bit compatible output, it would have to have
the same broken optimizations.


I believe, though, that would be 256K, though people I knew
gave it 300K.


IBM uses a binary system similar to roman numerals, where a lower
value to the right is added, and to the left is subtracted.


F is 64K, G is 128K, H is 256K, such that a 192K machine would be
indicated by GF and a 7MB machine by JM. The numbering doesn't work
quite as well for programs, but PL/I (F) was designed to run in 44K on
a 64K machine, leaving 20K for the OS. (That might result in the
symbol table residing on disk. At the end of every run, PL/I (F)
would indicate the smallest region that would keep the symbol table in
main memory.)


As virtual memory became more popular, one common thing to do was to
remove the overlay structure from Fortran H. Load it into the linker
without any OVERLAY control cards, and then write it out again.


-- glen
[Darn those off by one bugs. You're right, it needed a 256K machine
rather than 128K. And like pretty much every other OS program it
ran a lot faster if you had enough storage to undo the origami and
get rid of the overlays. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.