Re: fledgling assembler programmer

On Friday, March 24, 2023 at 7:10:00 AM UTC-7, Thomas Koenig wrote:


(snip about the lost art of small memory compilers.)


> On the Internet, there is a project for almost everything - in this
> case Tiny C, which still seems to be under active development. Or
> at least there are sill commits at https://repo.or.cz/w/tinycc.git .


> However, there is a reason why compilers got so big - there is
> always a balance to be struck between comilation speed, compiler
> size and optimization.


When I was writing the above, I was looking at the Program Logic
Manual for the OS/360 Fortran G compiler.
(G means it is supposed to run in 128K.)


Fortran G was not written by IBM, but contracted out. And is not
(mostly) in assembler, but in something called POP. That is, it
is interpreted by the POP interpreter, with POPcode written using
assembler macros. Doing that, for one, allows reusing the code
for other machines, though you still need to rewrite the code
generator. But also, at least likely, it decreases the size of
the compiler. POP instructions are optimized for things that
compiler need to do.


I also had the source to that so many years ago, but not the
manual describing it.


> An extreme example: According to "Abstracting Away the Machine", the
> very first FORTRAN compiler was so slow that the size of programs
> it could compile was limited by the MTBF of the IBM 704 of around
> eight hours.


I remember stories about how well its optimizer worked, when
it was believed that they had to compete in code speed with
experienced assembly programmers. I don't remember anything
about how fast it was.




> The balance has shifted over time, because of increasing computing
> power and available memory that can be applied to compilation,
> and because relatively more people use programs than use compilers
> than ever before. So, in today's environment, there is little
> incentive for writing small compilers.


I first thought about this, when reading about the Hercules project
of an IBM S/370 emulator, and couldn't run gcc in 16MB.
(Well, subtract some for the OS, but it still wouldn't fit.)


> Also, languages have become bigger, more expressive, more powerful,
> more bloated (take your pick), which also increases the size
> of compilers.


OK, the IBM PL/I (F) compiler, for what many consider a bloated
language, is designed to run (maybe not well) in 64K.
At the end of every compilation it tells how much memory was
used, how much available, and how much to keep the symbol table
in memory.

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