9 May
2024
9 May
'24
12:29 a.m.
There was nothing unique about the size or the object code of Dennis's C
compiler. In the 1960s, Digitek had a thriving business of making Fortran
compilers for all manner of machines. To optimize space usage, the
compilers' internal memory model comprised variable-size movable tables,
called "rolls". To exploit this non-native architecture, the compilers
themselves were interpreted, although they generated native code. Bob
McClure tells me he used one on an SDS910 that had 8K 16-bit words.
Dennis was one-up on Digitek in having a self-maintaining compiler. Thus,
when he implemented an optimization, the source would grow, but the
compiler binary might even shrink thanks to self-application.
Doug
10 May
10 May
11:28 p.m.
New subject: On the uniqueness of DMR's C compiler
On Wed, May 8, 2024 at 2:29 PM Douglas McIlroy <
douglas.mcilroy(a)dartmouth.edu> wrote:
Dennis was one-up on Digitek in having a self-maintaining compiler. Thus,
when he implemented an optimization, the source would grow, but the
compiler binary might even shrink thanks to self-application.
Another somewhat non-intuitive aspect of optimizing compilers is that
simply adding optimizations can cause an increase in compilation speed by
reducing the amount of IL in the program being compiled. Less IL due to
optimization means less time spent in later phases of the compilation
process.
Regarding native compilers for small machines, IBM had compilers for
Fortran, COBOL, and PL/I that ran in 32K on System/360 and produced
tolerably good code (yes, one could do better with handwritten assembler).
And they generated real code, no threaded code cop-out. And we're talking
full PL/I here, not the subset that ANSI later standardized. The compilers
were table-driven as much as possible, heavily overlaid, and used three
scratch files on disk (split-cylinder allocated to minimize seek time).
-Paul W.
11 May
11 May
3:16 p.m.
New subject: On the uniqueness of DMR's C compiler
Hi,
Paul W. wrote:
The compilers were table-driven as much as possible,
heavily overlaid,
and used three scratch files on disk (split-cylinder allocated to
minimize seek time).
I didn't know the term ‘split cylinder’. A cylinder has multiple
tracks, each with its own read/write head. Allocate different tracks to
different files and switching files needs no physical movement or
settling time; just electronically switch R/W head.
--
Cheers, Ralph.
7:42 p.m.
New subject: On the uniqueness of DMR's C compiler
At 2024-05-10T13:28:40-0400, Paul Winalski wrote:
On Wed, May 8, 2024 at 2:29 PM Douglas McIlroy <
douglas.mcilroy(a)dartmouth.edu> wrote:
This fact was rediscovered later when people found that some code
compiled with "-Os" (optimize for space) was faster than some code
optimized for speed ("-O1", "-O2", and so on).
The reason turned out to be that the reduced code size meant fewer cache
evictions, so you gained performance by skipping instances of
instruction fetches all the way from the slow main memory bus.
Think of all those poor unrolled loops...
Regards,
Branden
Dennis was one-up on Digitek in having a
self-maintaining compiler.
Thus, when he implemented an optimization, the source would grow,
but the compiler binary might even shrink thanks to
self-application.
Another somewhat non-intuitive aspect of optimizing compilers is that
simply adding optimizations can cause an increase in compilation speed
by reducing the amount of IL in the program being compiled. Less IL
due to optimization means less time spent in later phases of the
compilation process.
216
days inactive
219
days old
3 comments
4 participants
participants (4)
-
Douglas McIlroy -
G. Branden Robinson -
Paul Winalski -
Ralph Corderoy