From: anton@mips.complang.tuwien.ac.at
Thomas Koenig writes:
>Anton Ertl schrieb:
[...]
>It is possible to have a two-byte integer and a 32-byte real.
But according to John Levine that is not what happens on the PDP-11.
Instead, it has 4-byte INTEGERs, demonstrating that your "unofficial
rule" that C int is as wide as FORTRAN INTEGER did not hold.
>The same held for the Cray-1 - default ingegers (24 bit)
>and their weird 64-bit reals
If FORTRAN INTEGERs are 24 bits on the Cray-1, this architecture is
another example where your "unofficial rule" does not hold. C ints
are 64-bit on the Cray 1.
>> If they want to use their software as-is, and it is written to work
>> with an ILP32 C implementation, the only solution is to continue using
>> an ILP32 implementation.
>
>So, kill the 64-bit machines in the scientific marketplace. I'm glad
>you agree.
Not in the least. Most C programs did not run as-is on I32LP64, and
that did not kill these machines, either. And I am sure that C
programs were much more relevant for selling these machines than
FORTRAN programs. C programmers changed the programs to run on
I32LP64 (this was called "making them 64-bit-clean"). And until that
was done, ILP32 was used.
>> If just recompiling is the requirement, what follows is ILP32.
>
>There is absolutely no problem with 64-bit pointers when recompiling
>Fortran.
Fortran is not the only consideration for designing an ABI for C, if
it is one at all. The large number of 32bit->64bit sign-extension and
zero-extension operations, either explicitly, or integrated into
instructions such as RISC-V's addw, plus the
"optimizations"/miscompilations to ged rid of some of the sign
extensions are a cost that we pay all the time for the I32LP64
mistake.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup,
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
