[COFF] [TUHS] Re: Hypothetical: Could MULTICS have been written in C, if available?

[Paul Winalski via COFF]

On Wed, May 27, 2026 at 10:17 AM Dan Cross via COFF <coff at tuhs.org> wrote:

>
> During the 32->64 bit transition, there was a lot of variation and
> debate around the "ILP" widths: that is, what the widths of `int`,
> `long`, and pointers should be.


I was in DEC's compiler back end group and indeed there was a big debate
about it.


>   I think most Unix-y systems settled
> on I32LP64 (usually just written, "LP64"), where `int` is 32-bits and
> long and pointers are both 64-bits; some systems were ILP64 (`int`,
> `long`, and pointers are all 64-bits), and several are "LLP64" where
> `int` and `long` are 32-bits, but `long long` and pointers are
> 64-bits. There are several other variations on the theme; old Crays
> also made `short` 64-bits.
>

DEC's Tru64 Unix decided to go with ILP64 (int, long, pointer all 64
bits).  IIRC they did end up adding a LP64 (int 32 bits, long and pointer
64 bits) compiler option later on.

The C compiler for 64 bit OpenVMS is LP64.

Microsoft's 64 bit Windows C compiler is LLP64 (int and long 32 bits, long
long and pointer 64 bits).

>
> I asked a person working on clang and LLVM about 32-bit `int` on
> 64-bit machines once; why not make `int` 64-bits? The response was
> that that was "too big" for most things and there was no significant
> advantage otherwise. It might have also been marginally slower for
> stores on some machines around that time.
>

It was a lot more than marginally slower.  It was very significantly
slower.  And the problem existed with fetches as well as stores.  The issue
was the small (by modern standards) cache sizes on early 64 bit
processors.  Building a large application with 64 bit rather than 32 bit
ints often meant much larger data structure sizes and greatly increased
memory traffic and cache contention.  DEC ended up building their 64 bit
compilers as 32 bit applications because the compilers didn't need more
than a 32 bit address space and ran a lot faster that way.  With larger
modern cache sizes this usually is no longer an issue.

-Paul W.