| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 26 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 48:44:40 |
| Calls: | 632 |
| Files: | 1,187 |
| D/L today: |
3 files (4,227K bytes) |
| Messages: | 177,138 |
My 66000 2.0
After 4-odd years of ISA stability, I ran into a case where
I <pretty much> needed to change the instruction formats.
And after bragging to Quadribloc about its stability--it
reached the point where it was time to switch to version 2.0.
Well, its time to eat crow. --------------------------------------------------------------
Memory reference instructions already produce 64-bit values
from Byte, HalfWord, Word and DoubleWord memory references
in both Signed and unSigned flavors. These supports both
integer and floating point due to the single register file.
Essentially, I need that property in both integer and floating
point calculations to eliminate instructions that merely apply
value range constraints--just like memory !
ISA 2.0 changes allows calculation instructions; both Integer
and Floating Point; and a few other miscellaneous instructions
(not so easily classified) the same uniformity.
In all cases, an integer calculation produces a 64-bit value
range limited to that of the {Sign}|u{Size}--no garbage bits
in the high parts of the registers--the register accurately
represents the calculation as specified {Sign}|u{Size}.
Integer and floating point compare instructions only compare
bits of the specified {Size}.
Conversions between integer and floating point are now also
governed by {Size} so one can directly convert FP64 directly
into {unSigned}|u{Int16}--more fully supporting strongly typed
languages.
--------------------------------------------------------------
Integer instructions are now::
{Signed and unSigned}|u{Byte, HalfWord, Word, DoubleWord}
while FP instructions are now:
{Byte, HalfWord, Word, DoubleWord}
Although I am oscillating whether to support FP8 or FP128.
With this rearrangement of bit in the instruction formats, I
was able to get all Constant and routing control bits in the
same place and format in all {1, 2, and 3}-Operand instructions
uniformly. This simplifies <trifling> the Decoder, but more
importantly; the Operand delivery (and/or reception) mechanism.
I was also able to compress the 7 extended operation formats
into a single extended operation format. The instruction
format now looks like:
inst<31:26> Major OpCode
inst<20:16> {Rd, Cnd field}
inst<25:21> {SRC1, Rbase}
inst<15:10> {SH width, else, {I,d,Sign,Size}}
inst< 9: 6> {Minor OpCode, SRC3}
inst< 4: 0> {offset,SRC2,Rindex,1-OP|u}
So there is 1 uniformly positioned field of Minor OpCodes,
and one uniformly interpreted field of Operand Modifiers.
Operand Modifiers applies routing registers and inserting
of constants to XOP Instructions. --------------------------------------------------------------
So, what does this buy the Instruction Set ??
A) All integer calculations are performed at the size and
type of the result as required by the high level language::
{Signed and unSigned}|u{Byte, HalfWord, Word, DoubleWord}.
This, gets rid of all smash instructions across all data
types. {smash == {sext, zext, ((x<<2^n)>>2^n), ...}
B) I actually gained 1 more extended OpCode for future expansion.
C) assembler/disassembler was simplified
D) and while I did not add any new 'instructions' I made those
already present more uniform and supporting of the requirements
of higher level languages (like ADA) and more suitable to the
stricter typing LLVM provides over GCC.
In some ways I 'doubled' the instruction count while not adding
a single instruction {spelling or field-pattern} to ISA. --------------------------------------------------------------
The elimination of 'smashes' shrinks the instruction count of
GNUPLOT by 4%--maybe a bit more once we sort out all of the
compiler patterns it needs to recognize. --------------------------------------------------------------
I wonder if crow tastes good in shepard's pie ?!?
On 2025-10-02 10:50 p.m., MitchAlsup wrote:No, there are 5-bits--inst<9:5>--woops.
My 66000 2.0
After 4-odd years of ISA stability, I ran into a case where
I <pretty much> needed to change the instruction formats.
And after bragging to Quadribloc about its stability--it
reached the point where it was time to switch to version 2.0.
Well, its time to eat crow. --------------------------------------------------------------
Memory reference instructions already produce 64-bit values
from Byte, HalfWord, Word and DoubleWord memory references
in both Signed and unSigned flavors. These supports both
integer and floating point due to the single register file.
Essentially, I need that property in both integer and floating
point calculations to eliminate instructions that merely apply
value range constraints--just like memory !
ISA 2.0 changes allows calculation instructions; both Integer
and Floating Point; and a few other miscellaneous instructions
(not so easily classified) the same uniformity.
In all cases, an integer calculation produces a 64-bit value
range limited to that of the {Sign}|u{Size}--no garbage bits
in the high parts of the registers--the register accurately
represents the calculation as specified {Sign}|u{Size}.
Integer and floating point compare instructions only compare
bits of the specified {Size}.
Conversions between integer and floating point are now also
governed by {Size} so one can directly convert FP64 directly
into {unSigned}|u{Int16}--more fully supporting strongly typed
languages.
--------------------------------------------------------------
Integer instructions are now::
{Signed and unSigned}|u{Byte, HalfWord, Word, DoubleWord}
while FP instructions are now:
{Byte, HalfWord, Word, DoubleWord}
Although I am oscillating whether to support FP8 or FP128.
For my arch, I decided to support FP128 thinking that FP8 could be implemented with lookup tables, given that eight bit floats tend to vary
in composition. Of course, I like more precision.
Could it be a build option? Or a bit in a control register to flip
between FP8 and FP128?
With this rearrangement of bit in the instruction formats, I
was able to get all Constant and routing control bits in the
same place and format in all {1, 2, and 3}-Operand instructions
uniformly. This simplifies <trifling> the Decoder, but more
importantly; the Operand delivery (and/or reception) mechanism.
I was also able to compress the 7 extended operation formats
into a single extended operation format. The instruction
format now looks like:
inst<31:26> Major OpCode
inst<20:16> {Rd, Cnd field}
inst<25:21> {SRC1, Rbase}
inst<15:10> {SH width, else, {I,d,Sign,Size}}
inst< 9: 6> {Minor OpCode, SRC3}
inst< 4: 0> {offset,SRC2,Rindex,1-OP|u}
Only four bits for SRC3?
So there is 1 uniformly positioned field of Minor OpCodes,
and one uniformly interpreted field of Operand Modifiers.
Operand Modifiers applies routing registers and inserting
of constants to XOP Instructions. --------------------------------------------------------------
So, what does this buy the Instruction Set ??
A) All integer calculations are performed at the size and
type of the result as required by the high level language::
{Signed and unSigned}|u{Byte, HalfWord, Word, DoubleWord}.
This, gets rid of all smash instructions across all data
types. {smash == {sext, zext, ((x<<2^n)>>2^n), ...}
B) I actually gained 1 more extended OpCode for future expansion.
C) assembler/disassembler was simplified
D) and while I did not add any new 'instructions' I made those
already present more uniform and supporting of the requirements
of higher level languages (like ADA) and more suitable to the
stricter typing LLVM provides over GCC.
In some ways I 'doubled' the instruction count while not adding
a single instruction {spelling or field-pattern} to ISA. --------------------------------------------------------------
The elimination of 'smashes' shrinks the instruction count of
GNUPLOT by 4%--maybe a bit more once we sort out all of the
compiler patterns it needs to recognize. --------------------------------------------------------------
I wonder if crow tastes good in shepard's pie ?!?
My 66000 2.0
After 4-odd years of ISA stability, I ran into a case where
I <pretty much> needed to change the instruction formats.
And after bragging to Quadribloc about its stability--it
reached the point where it was time to switch to version 2.0.
Well, its time to eat crow. --------------------------------------------------------------
Memory reference instructions already produce 64-bit values
from Byte, HalfWord, Word and DoubleWord memory references
in both Signed and unSigned flavors. These supports both
integer and floating point due to the single register file.
Essentially, I need that property in both integer and floating
point calculations to eliminate instructions that merely apply
value range constraints--just like memory !
ISA 2.0 changes allows calculation instructions; both Integer
and Floating Point; and a few other miscellaneous instructions
(not so easily classified) the same uniformity.
In all cases, an integer calculation produces a 64-bit value
range limited to that of the {Sign}|u{Size}--no garbage bits
in the high parts of the registers--the register accurately
represents the calculation as specified {Sign}|u{Size}.
Integer and floating point compare instructions only compare
bits of the specified {Size}.
Conversions between integer and floating point are now also
governed by {Size} so one can directly convert FP64 directly
into {unSigned}|u{Int16}--more fully supporting strongly typed
languages.
--------------------------------------------------------------
Integer instructions are now::
{Signed and unSigned}|u{Byte, HalfWord, Word, DoubleWord}
while FP instructions are now:
{Byte, HalfWord, Word, DoubleWord}
Although I am oscillating whether to support FP8 or FP128.
My 66000 2.0
After 4-odd years of ISA stability, I ran into a case where
I <pretty much> needed to change the instruction formats.
And after bragging to Quadribloc about its stability--it
reached the point where it was time to switch to version 2.0.
Well, its time to eat crow. --------------------------------------------------------------
Memory reference instructions already produce 64-bit values
from Byte, HalfWord, Word and DoubleWord memory references
in both Signed and unSigned flavors. These supports both
integer and floating point due to the single register file.
Essentially, I need that property in both integer and floating
point calculations to eliminate instructions that merely apply
value range constraints--just like memory !
ISA 2.0 changes allows calculation instructions; both Integer
and Floating Point; and a few other miscellaneous instructions
(not so easily classified) the same uniformity.
In all cases, an integer calculation produces a 64-bit value
range limited to that of the {Sign}|u{Size}--no garbage bits
in the high parts of the registers--the register accurately
represents the calculation as specified {Sign}|u{Size}.
--------------------------------------------------------------
Integer instructions are now:: {Signed and unSigned}+{Byte, HalfWord, >> Word, DoubleWord}
while FP instructions are now:
{Byte, HalfWord, Word, DoubleWord}
I doubt any compilers will use this feature.
Strong typed languages don't have predefined operators that allow mixing.
On 10/2/2025 7:50 PM, MitchAlsup wrote:
My 66000 2.0
After 4-odd years of ISA stability, I ran into a case where
I <pretty much> needed to change the instruction formats.
And after bragging to Quadribloc about its stability--it
reached the point where it was time to switch to version 2.0.
Well, its time to eat crow. --------------------------------------------------------------
Memory reference instructions already produce 64-bit values
from Byte, HalfWord, Word and DoubleWord memory references
in both Signed and unSigned flavors. These supports both
integer and floating point due to the single register file.
Essentially, I need that property in both integer and floating
point calculations to eliminate instructions that merely apply
value range constraints--just like memory !
ISA 2.0 changes allows calculation instructions; both Integer
and Floating Point; and a few other miscellaneous instructions
(not so easily classified) the same uniformity.
In all cases, an integer calculation produces a 64-bit value
range limited to that of the {Sign}|u{Size}--no garbage bits
in the high parts of the registers--the register accurately
represents the calculation as specified {Sign}|u{Size}.
I must be missing something. Suppose I have
C := A + B
where A and C are 16 bit signed integers and B is an 8 bit signed
integer. As I understand what you are doing, loading B into a register
will leave the high order 56 bits zero. But the add instruction will presumably be half word, so if B is negative, it will get an incorrect answer (because B is not sign extended to 16 bits).
What am I missing?
MitchAlsup wrote:
My 66000 2.0
After 4-odd years of ISA stability, I ran into a case where
I <pretty much> needed to change the instruction formats.
And after bragging to Quadribloc about its stability--it
reached the point where it was time to switch to version 2.0.
Well, its time to eat crow.
--------------------------------------------------------------
Memory reference instructions already produce 64-bit values
from Byte, HalfWord, Word and DoubleWord memory references
in both Signed and unSigned flavors. These supports both
integer and floating point due to the single register file.
Essentially, I need that property in both integer and floating
point calculations to eliminate instructions that merely apply
value range constraints--just like memory !
Why? Compilers do not have any problem with this
as its been handled by overload resolution since forever.
--------------------------------------------------------------
Integer instructions are now:: {Signed and unSigned}|u{Byte, HalfWord, >>> Word, DoubleWord}
while FP instructions are now:
{Byte, HalfWord, Word, DoubleWord}
I doubt any compilers will use this feature.
Strong typed languages don't have predefined operators that allow mixing.
Not sure who's confused, but my reading of the above is not some sort of "mixing": I believe Mitch is just saying that his addition operation
(for example) can be specified to operate on either one of int8, uint8, int16, uint16, ...
But that specification applies to all inputs and outputs of the
instruction, so it does not support adding an int8 to an int32, or other "mixes".
MitchAlsup wrote:
My 66000 2.0
After 4-odd years of ISA stability, I ran into a case where
I <pretty much> needed to change the instruction formats.
And after bragging to Quadribloc about its stability--it
reached the point where it was time to switch to version 2.0.
Well, its time to eat crow. --------------------------------------------------------------
Memory reference instructions already produce 64-bit values
from Byte, HalfWord, Word and DoubleWord memory references
in both Signed and unSigned flavors. These supports both
integer and floating point due to the single register file.
Essentially, I need that property in both integer and floating
point calculations to eliminate instructions that merely apply
value range constraints--just like memory !
Why? Compilers do not have any problem with this
as its been handled by overload resolution since forever.
Its people who have the problems following type changes and most
compilers will warn of mixed type operations for exactly that reason.
ISA 2.0 changes allows calculation instructions; both Integer
and Floating Point; and a few other miscellaneous instructions
(not so easily classified) the same uniformity.
In all cases, an integer calculation produces a 64-bit value
range limited to that of the {Sign}|u{Size}--no garbage bits
in the high parts of the registers--the register accurately
represents the calculation as specified {Sign}|u{Size}.
Integer and floating point compare instructions only compare
bits of the specified {Size}.
Conversions between integer and floating point are now also
governed by {Size} so one can directly convert FP64 directly
into {unSigned}|u{Int16}--more fully supporting strongly typed
languages.
Strongly typed languages don't natively support mixed type operations.
They come with a set of predefined operations for specific types that
produce specific results.
If YOU want operators/functions that allow mixed types then they force
you to define your own functions to perform your specific operations,
and it forces you to deal with the consequences of your type mixing.
All this does is force YOU, the programmer, to be explicit in your
definition and not depend on invisible compiler specific interpretations.
If you want to support Uns8 * Int8 then it forces you, the programmer,
to deal with the fact that this produces a signed 16-bit result
in the range -128*256..+127*256 = -32768..32512.
Now if you want to convert that result bit pattern to Uns8 by truncating
it to the lower 8 bits,
or worse treat the result as Int8 and take
whatever random value falls in bit [7] as the sign, then that's on you.
They just force you to be explicit what you are doing.
--------------------------------------------------------------
Integer instructions are now::
{Signed and unSigned}|u{Byte, HalfWord, Word, DoubleWord}
while FP instructions are now:
{Byte, HalfWord, Word, DoubleWord}
I doubt any compilers will use this feature.
Strong typed languages don't have predefined operators that allow mixing. Weak typed languages deal with this in overload resolution and by having predefined invisible type conversions in those operators and then using
the normal single type arithmetic instructions.
Although I am oscillating whether to support FP8 or FP128.
The issue with FP8 support seems to be that everyone who wants it also
wants their own definition so no matter what you do, it will be unused.
The issue with FP128 seems associated with scaling on LD and ST
because now scaling is 1,2,4,8,16 which adds 1 bit to the scale field.
And in the case of a combined int-float register file deciding whether
to expand all registers to 128 bits, or use 64-bit register pairs.
Using 128-bit registers raises the question of 128-bit integer support,
and using register pairs opens a whole new category of pair instructions.
Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
Not sure who's confused, but my reading of the above is not some sort of--------------------------------------------------------------
Integer instructions are now:: {Signed and unSigned}|u{Byte, HalfWord,
Word, DoubleWord}
while FP instructions are now:
{Byte, HalfWord, Word, DoubleWord}
I doubt any compilers will use this feature.
Strong typed languages don't have predefined operators that allow mixing. >>
"mixing": I believe Mitch is just saying that his addition operation
(for example) can be specified to operate on either one of int8, uint8,
int16, uint16, ...
But that specification applies to all inputs and outputs of the
instruction, so it does not support adding an int8 to an int32, or other
"mixes".
The outputs are correctly extended to a 64-bit number (signed or
unsigned) so it is possible to pass results to wider operations
without conversion.
One example would be
unsigned long foo (unsigned int a, unsigned int b)
{
return a + b;
}
which would need an adjustment after the add, and which would
just be somethign like
adduw r1,r1,r2
ret
using Mitch's new encoding.
MitchAlsup wrote:
My 66000 2.0
After 4-odd years of ISA stability, I ran into a case where
I <pretty much> needed to change the instruction formats.
And after bragging to Quadribloc about its stability--it reached the
point where it was time to switch to version 2.0.
Well, its time to eat crow.
--------------------------------------------------------------
Memory reference instructions already produce 64-bit values
from Byte, HalfWord, Word and DoubleWord memory references
in both Signed and unSigned flavors. These supports both integer and
floating point due to the single register file.
Essentially, I need that property in both integer and floating
point calculations to eliminate instructions that merely apply value
range constraints--just like memory !
Why? Compilers do not have any problem with this
as its been handled by overload resolution since forever.
Its people who have the problems following type changes and most
compilers will warn of mixed type operations for exactly that reason.
ISA 2.0 changes allows calculation instructions; both Integer and
Floating Point; and a few other miscellaneous instructions (not so
easily classified) the same uniformity.
In all cases, an integer calculation produces a 64-bit value
range limited to that of the {Sign}|u{Size}--no garbage bits
in the high parts of the registers--the register accurately
represents the calculation as specified {Sign}|u{Size}.
Integer and floating point compare instructions only compare
bits of the specified {Size}.
Conversions between integer and floating point are now also
governed by {Size} so one can directly convert FP64 directly
into {unSigned}|u{Int16}--more fully supporting strongly typed
languages.
Strongly typed languages don't natively support mixed type operations.
They come with a set of predefined operations for specific types that
produce specific results.
If YOU want operators/functions that allow mixed types then they force
you to define your own functions to perform your specific operations,
and it forces you to deal with the consequences of your type mixing.
All this does is force YOU, the programmer, to be explicit in your
definition and not depend on invisible compiler specific interpretations.
If you want to support Uns8 * Int8 then it forces you, the programmer,
to deal with the fact that this produces a signed 16-bit result
in the range -128*256..+127*256 = -32768..32512.
Now if you want to convert that result bit pattern to Uns8 by truncating
it to the lower 8 bits, or worse treat the result as Int8 and take
whatever random value falls in bit [7] as the sign, then that's on you.
They just force you to be explicit what you are doing.
--------------------------------------------------------------
Integer instructions are now:: -a-a-a-a {Signed and unSigned}|u{Byte,
HalfWord, Word, DoubleWord}
while FP instructions are now:
-a-a-a-a {Byte, HalfWord, Word, DoubleWord}
I doubt any compilers will use this feature.
Strong typed languages don't have predefined operators that allow mixing. Weak typed languages deal with this in overload resolution and by having predefined invisible type conversions in those operators and then using
the normal single type arithmetic instructions.
Although I am oscillating whether to support FP8 or FP128.
The issue with FP8 support seems to be that everyone who wants it also
wants their own definition so no matter what you do, it will be unused.
The issue with FP128 seems associated with scaling on LD and ST
because now scaling is 1,2,4,8,16 which adds 1 bit to the scale field.
And in the case of a combined int-float register file deciding whether
to expand all registers to 128 bits, or use 64-bit register pairs.
Using 128-bit registers raises the question of 128-bit integer support,
and using register pairs opens a whole new category of pair instructions.
On 10/2/2025 7:50 PM, MitchAlsup wrote:
My 66000 2.0
After 4-odd years of ISA stability, I ran into a case where
I <pretty much> needed to change the instruction formats.
And after bragging to Quadribloc about its stability--it
reached the point where it was time to switch to version 2.0.
Well, its time to eat crow.
--------------------------------------------------------------
Memory reference instructions already produce 64-bit values
from Byte, HalfWord, Word and DoubleWord memory references
in both Signed and unSigned flavors. These supports both
integer and floating point due to the single register file.
Essentially, I need that property in both integer and floating
point calculations to eliminate instructions that merely apply
value range constraints--just like memory !
ISA 2.0 changes allows calculation instructions; both Integer
and Floating Point; and a few other miscellaneous instructions
(not so easily classified) the same uniformity.
In all cases, an integer calculation produces a 64-bit value
range limited to that of the {Sign}|arCo{Size}--no garbage bits
in the high parts of the registers--the register accurately
represents the calculation as specified {Sign}|arCo{Size}.
I must be missing something.-a Suppose I have
C := A + B
where A and C are 16 bit signed integers and B is an 8 bit signed
integer.-a As I understand what you are doing, loading B into a register will leave the high order 56 bits zero.-a But the add instruction will presumably be half word, so if B is negative, it will get an incorrect > answer (because B is not sign extended to 16 bits).
What am I missing?
LLVM compiles C with stricter typing than GCC resulting in a lot
of smashes:: For example::
int subroutine( int a, int b )
{
return a+b;
}
Compiles into:
subroutine:
ADD R1,R1,R2
SRA R1,R1,<32,0> // limit result to (int)
RET
LLVM thinks the smash is required because [-2^31..+2^31-1] +
[-2^31..+2^31-1] does not always fit into [-2^31..+2^31-1] !!!
and chasing down all the cases is harder than the compiler is
ready to do.
At first I though that the Value propagation in
LLVM would find that the vast majority of arithmetic does not
need smashing. This proved frustrating to both myself and to
Brian. The more I read RSIC-V and ARM assembly code, the more
I realized that adding sized integer arithmetic is the only
way to get through to the LLVM infrastructure.
RISC-V has ADDW (but no ADDH or ADDB) to alleviate the issue on
a majority of calculations.
ARM has word sized Registers to
alleviate the issue. Since ARM started as 32-bits ADDW is natural.
I am exploring how to provide integer arithmetic such that smashing
never has to happen.
So let's look at some egregious cases::
cvtds r2,r2 // convert double to signed 64
srl r3,r2,#0,#32 // convert signed 64 to signed 32
--------
sra r1,r23,#0,#32 // smash to signed 32
sra r2,r20,#0,#32 // smash to signed 32
maxs r23,r2,r1 // max of signed 32
--------
ldd r24,[r24] // LD signed 64
add r1,r28,#1 // innocently add #1
sra r28,r1,#0,#32 // smash to Signed 32
cmp r1,r28,r16 // to match the other operand of CMP
--------
call strspn
srl r2,r1,#0,#32 // smash result Signed 32
add r1,r25,-r1
sra r1,r1,#0,#32 // smash Signed 32
cmp r2,r19,r2
srl r2,r2,#2,#1
add r21,r21,r2 // add Bool to Signed 32
sra r2,r20,#0,#32 // smash Signed 32
maxs r20,r1,r2 // MAX Signed 32
--------
mov r1,r29 // Signed 64
ple0 r17,FFFFFFF // ignore
stw r17,[ip,key_rows] // ignore
add r1,r29,#-1 // innocent subtract
sra r1,r1,#0,#32 // smash to Signed 32
divs r1,r1,r17 // DIV Signed 32
I doubt any compilers will use this feature.
RISC-V and ARM LLVM compilers already do this and use it to eliminate >smashes.
On the other hand:: ILP64 ALSO gets rid of the problem (at a different cost).
The I32LP64 mistake
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
The I32LP64 mistake
If you consider I32LP64 a mistake, how should FORTRAN's (note the
upper case, this is pre-Fortran-90) storage association rules have
been handled, in your opinion?
If you are not familiar with them, they are:
- INTEGER takes up one storage unit
- REAL takes up one storage unit
- DOUBLE PRECISION takes up two storage units
where storage units are implementation-defined. Also consider
that 32-bit REALs and 64-bit REALs are both useful and needed,
and that (unofficially) C's integers were identical to
FORTRAN's INTEGER.
AFAIK Rust does not have a machine-word-sized integer type; instead,
each type has its size in its name (e.g., i32, u64).
Thomas Koenig <tkoenig@netcologne.de> writes:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
The I32LP64 mistake
If you consider I32LP64 a mistake, how should FORTRAN's (note the
upper case, this is pre-Fortran-90) storage association rules have
been handled, in your opinion?
I am not familiar enough with FORTRAN to give a recommendation on
that. However, two observations:
* The Cray-1 is primarily a Fortran machine, and it's C implementation
is ILP64, and it is successful. So obviously an ILP64 C can live
fine with FORTRAN.
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
The I32LP64 mistake
If you consider I32LP64 a mistake, how should FORTRAN's (note the
upper case, this is pre-Fortran-90) storage association rules have
been handled, in your opinion?
If you are not familiar with them, they are:--- Synchronet 3.21a-Linux NewsLink 1.2
- INTEGER takes up one storage unit
- REAL takes up one storage unit
- DOUBLE PRECISION takes up two storage units
where storage units are implementation-defined. Also consider
that 32-bit REALs and 64-bit REALs are both useful and needed,
and that (unofficially) C's integers were identical to
FORTRAN's INTEGER.
Thomas Koenig <tkoenig@netcologne.de> writes:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
The I32LP64 mistake
If you consider I32LP64 a mistake, how should FORTRAN's (note the
upper case, this is pre-Fortran-90) storage association rules have
been handled, in your opinion?
I am not familiar enough with FORTRAN to give a recommendation on
that. However, two observations:
* The Cray-1 is primarily a Fortran machine, and it's C implementation
is ILP64, and it is successful. So obviously an ILP64 C can live
fine with FORTRAN.
* Whatever inconvenience ILP64 would have caused to Fortran
implementors is small compared to the cost in performance and
reliability that I32LP64 has cost in the C world and the cost in
encoding space (and thus code size) and implementation effort and
transistors (probably not that many, but still) that it is costing
all customers of 64-bit processors.
If you are not familiar with them, they are:
- INTEGER takes up one storage unit
- REAL takes up one storage unit
- DOUBLE PRECISION takes up two storage units
where storage units are implementation-defined. Also consider
that 32-bit REALs and 64-bit REALs are both useful and needed,
and that (unofficially) C's integers were identical to
FORTRAN's INTEGER.
And unofficially C's integers were as long as pointers (with a legacy reaching back to BCPL). If I had to choose between breaking an
unofficial FORTRAN-C interface tradition and a C-internal tradition, I
would choose the C-internal tradition every time.
- anton--- Synchronet 3.21a-Linux NewsLink 1.2
EricP <ThatWouldBeTelling@thevillage.com> schrieb:
MitchAlsup wrote:
My 66000 2.0Why? Compilers do not have any problem with this
After 4-odd years of ISA stability, I ran into a case where
I <pretty much> needed to change the instruction formats.
And after bragging to Quadribloc about its stability--it
reached the point where it was time to switch to version 2.0.
Well, its time to eat crow.
--------------------------------------------------------------
Memory reference instructions already produce 64-bit values
from Byte, HalfWord, Word and DoubleWord memory references
in both Signed and unSigned flavors. These supports both
integer and floating point due to the single register file.
Essentially, I need that property in both integer and floating
point calculations to eliminate instructions that merely apply
value range constraints--just like memory !
as its been handled by overload resolution since forever.
A non-My66000 example:
int add (int a, int b)
{
return a + b;
}
is translated on powerpc64le-unknown-linux-gnu (with -O3 to)
add 3,3,4
extsw 3,3
blr
extsw fills the 32 high-value bits with because numbers returned
in registers have to be correct, either as 32- or 64-bit values.
Thomas Koenig <tkoenig@netcologne.de> writes:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
The I32LP64 mistake
If you consider I32LP64 a mistake, how should FORTRAN's (note the
upper case, this is pre-Fortran-90) storage association rules have
been handled, in your opinion?
I am not familiar enough with FORTRAN to give a recommendation on
that. However, two observations:
* The Cray-1 is primarily a Fortran machine, and it's C implementation
is ILP64, and it is successful. So obviously an ILP64 C can live
fine with FORTRAN.
* Whatever inconvenience ILP64 would have caused to Fortran
implementors is small compared to the cost in performance and
reliability that I32LP64 has cost in the C world and the cost in
encoding space (and thus code size) and implementation effort and
transistors (probably not that many, but still) that it is costing
all customers of 64-bit processors.
On Sat, 04 Oct 2025 16:11:37 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
AFAIK Rust does not have a machine-word-sized integer type; instead,
each type has its size in its name (e.g., i32, u64).
Rust has machine-dependent isize and usize types, identical to ptrdiff_t
and size_t in C.
On 10/3/2025 4:04 PM, Thomas Koenig wrote:
Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
--------------------------------------------------------------
Integer instructions are now::-a-a-a-a-a {Signed and unSigned}|u{Byte, >>>>> HalfWord,
Word, DoubleWord}
while FP instructions are now:
-a-a-a-a-a {Byte, HalfWord, Word, DoubleWord}
I doubt any compilers will use this feature.
Strong typed languages don't have predefined operators that allow
mixing.
Not sure who's confused, but my reading of the above is not some sort of >>> "mixing": I believe Mitch is just saying that his addition operation
(for example) can be specified to operate on either one of int8, uint8,
int16, uint16, ...
But that specification applies to all inputs and outputs of the
instruction, so it does not support adding an int8 to an int32, or other >>> "mixes".
The outputs are correctly extended to a 64-bit number (signed or
unsigned) so it is possible to pass results to wider operations
without conversion.
One example would be
unsigned long foo (unsigned int a, unsigned int b)
{
-a-a return a + b;
}
which would need an adjustment after the add, and which would
just be somethign like
-a-a-a-aadduw-a-a-a r1,r1,r2
-a-a-a-aret
using Mitch's new encoding.
Yes.
Sign extend signed types, zero extend unsigned types.
Up-conversion is free.
This is something the RISC-V people got wrong IMO, and adding a bunch of ".UW" instructions in an attempt to patch over it is just kinda ugly.
Partly for my own uses revived ADDWU and SUBWU (which had been dropped
in BitManip), because these are less bad than the alternative.
I get annoyed that new extensions keep trying to add ever more ".UW" instructions rather than just having the compiler go over to zero-
extended unsigned and make this whole mess go away.
...
Ironically, the number of new instructions being added to my own ISA has mostly died off recently, largely because there is little particularly relevant to add at this point (within the realm of stuff that could be added).
On Sat, 04 Oct 2025 16:11:37 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
AFAIK Rust does not have a machine-word-sized integer type; instead,
each type has its size in its name (e.g., i32, u64).
Rust has machine-dependent isize and usize types
identical to ptrdiff_t and size_t in C.
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:...
Thomas Koenig <tkoenig@netcologne.de> writes:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
The I32LP64 mistake
If you consider I32LP64 a mistake, how should FORTRAN's (note the
upper case, this is pre-Fortran-90) storage association rules have
been handled, in your opinion?
By the time the 64-bit worksations
were being designed, REAL was firmly established as 32-bit and
DOUBLE PRECISION as 64-bit, from the /360, the PDP-11, the VAX
and the very 32-bit workstations that the 64-bit workstations were
supposed to replace.
So, put yourself into the shoes of the people designing workstations
RS4000 they could allow their scientific and technical customers
to use the same codes "as is", with no conversion, or tell them
they cannot use 32-bit REAL any more, and that they need to rewrite
all their software.
What would they have expected their customers to do? Buy a system
which forces them to do this, or buy a competitor's system where
they can just recompile their software?
You're always harping about how compilers should be bug-comptatible
to previous releases.
Not in the least. I did not ask for bug compatibility.
I also did not ask for "compiling as is" on a different architecture,
much less on a system with different address size.
I have actually written up what I ask for: <https://www.complang.tuwien.ac.at/papers/ertl17kps.pdf>. Maybe you
should read it one day, or reread it given that you have forgotten it.
- anton--- Synchronet 3.21a-Linux NewsLink 1.2
On the PDP-11 C's int is 16 bits. I don't know what FORTRAN's INTEGER
is on the PDP-11 (but I remember reading about INTEGER*2 and
INTEGER*4, AFAIK not in a PDP-11 context). In any case, I expect that >FORTRAN's REAL was 32-bit on a PDP-11, and that any rule chain that
requires that C's int is as wide as FORTRAN's REAL is broken at some
point on the PDP-11.
Thomas Koenig <tkoenig@netcologne.de> writes:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:...
Thomas Koenig <tkoenig@netcologne.de> writes:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
The I32LP64 mistake
If you consider I32LP64 a mistake, how should FORTRAN's (note the
upper case, this is pre-Fortran-90) storage association rules have
been handled, in your opinion?
By the time the 64-bit worksations
were being designed, REAL was firmly established as 32-bit and
DOUBLE PRECISION as 64-bit, from the /360, the PDP-11, the VAX
and the very 32-bit workstations that the 64-bit workstations were
supposed to replace.
On the PDP-11 C's int is 16 bits. I don't know what FORTRAN's INTEGER
is on the PDP-11 (but I remember reading about INTEGER*2 and
INTEGER*4, AFAIK not in a PDP-11 context). In any case, I expect that FORTRAN's REAL was 32-bit on a PDP-11, and that any rule chain that
requires that C's int is as wide as FORTRAN's REAL is broken at some
point on the PDP-11.
So, put yourself into the shoes of the people designing workstations
RS4000 they could allow their scientific and technical customers
to use the same codes "as is", with no conversion, or tell them
they cannot use 32-bit REAL any more, and that they need to rewrite
all their software.
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.
What would they have expected their customers to do? Buy a system
which forces them to do this, or buy a competitor's system where
they can just recompile their software?
If just recompiling is the requirement, what follows is ILP32.
You're always harping about how compilers should be bug-comptatible
to previous releases.
Not in the least. I did not ask for bug compatibility.
If variable v and variable w are "stack variables" local to their own >subroutines, it seems perfectly reasonable to assume that all deallocated >stack variables become inaccessible.
Then, later when new stack space is
allocated those new variables have no relationship to any previously >deallocated variables.
That is: when the stack pointer is incremented the space is no longer >accessible and::
a) any modified cache lines are discarded instead of being written
to memory--the space is no longer accessible so don't waste power
making DRAM coherent with inaccessible stack space.
Later, when the stack pointer is decremented::
b) new cache line area can be "allocated" without reading DRAM and
being <conceptually> initialized to zero.
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:[...]
It is possible to have a two-byte integer and a 32-byte real.
The same held for the Cray-1 - default ingegers (24 bit)
and their weird 64-bit reals
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.
If just recompiling is the requirement, what follows is ILP32.
There is absolutely no problem with 64-bit pointers when recompiling
Fortran.
Thomas Koenig <tkoenig@netcologne.de> writes:<snip>
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:[...]
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.
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
Thomas Koenig <tkoenig@netcologne.de> writes:<snip>
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:[...]
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.
The vast majority of C/C++ programs ran just fine on I32LP64. There
were some that didn't, but it was certainly not "most".
Thomas Koenig <tkoenig@netcologne.de> writes:
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.
Not in the least. Most C programs did not run as-is on I32LP64, and
that did not kill these machines, either.
Only those who assumed sizeof(int) = sizeof(char *). This was
not true on the PDP-11, ...
According to Thomas Koenig <tkoenig@netcologne.de>:
Not in the least. Most C programs did not run as-is on I32LP64, and
that did not kill these machines, either.
Only those who assumed sizeof(int) = sizeof(char *). This was
not true on the PDP-11, ...
The PDP-11 was a 16 bit machine with 16 bit ints and 16 bit pointers.
There were 32 bit long and float, and 64 bit double.
I didn't port a lot of code from the 11 to other machines, but my recollection >is that the widespread assumption in Berkeley Vax code that location zero was >addressable and contained binary zeros was much more painful to fix than
size issues.
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
LLVM compiles C with stricter typing than GCC resulting in a lot
of smashes:: For example::
int subroutine( int a, int b )
{
return a+b;
}
Compiles into:
subroutine:
ADD R1,R1,R2
SRA R1,R1,<32,0> // limit result to (int)
RET
I tested this on AMD64, and did not find sign-extension in the caller, >neither with gcc-14 nor with clang-19; both produce the following code
for your example (with "subroutine" renamed into "subroutine1").
0000000000000000 <subroutine1>:
0: 8d 04 37 lea (%rdi,%rsi,1),%eax
3: c3 ret
It's not about strict or lax typing, it's about what the calling
convention promises about types that are smaller than a machine word.
If the calling convention requires/guarantees that ints are
sign-extended, the compiler must use instructions that produce a >sign-extended result. If the calling convention guarantees that ints
are zero-extended (sounds perverse, but RV64 has the guarantee that
unsigned is passed in sign-extended form, which is equally perverse),
then the compiler must use instructions that produce a zero-extended
result (e.g., AMD64's addl). If the calling convention only requires
and guarantees the low-order 32 bits (I call this garbage-extended),
then the compiler can use instructions that perform 64-bit adds; this
is what we are seeing above.
The other side of the medal is what is needed at the caller: If the
caller needs to cconvert a sign-extended int into a long, it does not
have to do anything. If it needs to convert a zero-extended or >garbage-extended int into a long, it has to sign-extend the value.
In article <2025Oct4.121741@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
LLVM compiles C with stricter typing than GCC resulting in a lot
of smashes:: For example::
int subroutine( int a, int b )
{
return a+b;
}
Compiles into:
subroutine:
ADD R1,R1,R2
SRA R1,R1,<32,0> // limit result to (int)
RET
I tested this on AMD64, and did not find sign-extension in the caller, >neither with gcc-14 nor with clang-19; both produce the following code
for your example (with "subroutine" renamed into "subroutine1").
0000000000000000 <subroutine1>:
0: 8d 04 37 lea (%rdi,%rsi,1),%eax
3: c3 ret
It's not about strict or lax typing, it's about what the calling
convention promises about types that are smaller than a machine word.
If the calling convention requires/guarantees that ints are
sign-extended, the compiler must use instructions that produce a >sign-extended result. If the calling convention guarantees that ints
are zero-extended (sounds perverse, but RV64 has the guarantee that >unsigned is passed in sign-extended form, which is equally perverse),
then the compiler must use instructions that produce a zero-extended
result (e.g., AMD64's addl). If the calling convention only requires
and guarantees the low-order 32 bits (I call this garbage-extended),
then the compiler can use instructions that perform 64-bit adds; this
is what we are seeing above.
The other side of the medal is what is needed at the caller: If the
caller needs to cconvert a sign-extended int into a long, it does not
have to do anything. If it needs to convert a zero-extended or >garbage-extended int into a long, it has to sign-extend the value.
AMD64 in hardware does 0 extension of 32-bit operations. From your
example "lea (%rdi,%rsi,1),%eax" (AT&T notation, so %eax is the dest),
the 64-bit register %rax will have 0's written into bits [63:32].
So the AMD64 convention for 32-bit values in 64-bit registers is to zero-extend on writes. And to ignore the upper 32-bits on reads, so
using a 64-bit register should use the %exx name.
I agree with you that I32LP64 was a mistake, but it exists, and I
think ARM64 did a good job handling it. It has all integer operations working on two sizes: 32-bit and 64-bit, and when writing a 32-bit result,
it 0-extends the register value.
You don't want "garbage extend" since you want a predictable answer.
Your choices for writing 32-bit results in a 64-bit register are thus sign-extend (not a good choice) or zero-extend (what almost
everyone chose). RISC-V is in another land, where they effectively have
no 32-bit operations, but rather a convention that all 32-bit inputs
must be sign-extended in a 64-bit register.
For C and C++ code, the standard dictates that all integer operations are done with "int" precision, unless some operand is larger than int, and then do it in that precision. So there's no real need for 8-bit and 16-bit operations to be natively by the CPU--these operations are actually done
as int's already. If you have a variable which is a byte, then assigning
to that variable, and then using that variable again you will need to zero-extend,
but honestly, this is not usually a performance path. It's likely to be stored to memory instead, so no masking or sign extending
should be needed.
If you pick ILP64 for your ABI, then you will get rid of almost all of
these zero- and sign-extensions of 32-bit C and C++ code.
It will just--- Synchronet 3.21a-Linux NewsLink 1.2
work. If you pick I32LP64, then you should have a full suite of 32-bit operations and 64-bit operations, at least for all add, subtract, and
compare operations. And if you do I32LP64, your indexed addressing
modes should have 3 types of indexed registers: 64-bit, 32-bit signed,
and 32-bit unsigned. That worked well for ARM64.
Kent
In article <2025Oct4.121741@mips.complang.tuwien.ac.at>,...
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
int subroutine( int a, int b )
{
return a+b;
}
...I tested this on AMD64, and did not find sign-extension in the caller, >>neither with gcc-14 nor with clang-19; both produce the following code
for your example (with "subroutine" renamed into "subroutine1").
0000000000000000 <subroutine1>:
0: 8d 04 37 lea (%rdi,%rsi,1),%eax
3: c3 ret
AMD64 in hardware does 0 extension of 32-bit operations. From your
example "lea (%rdi,%rsi,1),%eax" (AT&T notation, so %eax is the dest),
the 64-bit register %rax will have 0's written into bits [63:32].
So the AMD64 convention for 32-bit values in 64-bit registers is to >zero-extend on writes. And to ignore the upper 32-bits on reads, so
using a 64-bit register should use the %exx name.
I agree with you that I32LP64 was a mistake, but it exists, and I
think ARM64 did a good job handling it. It has all integer operations >working on two sizes: 32-bit and 64-bit, and when writing a 32-bit result,
it 0-extends the register value.
You don't want "garbage extend" since you want a predictable answer.
Your choices for writing 32-bit results in a 64-bit register are thus >sign-extend (not a good choice) or zero-extend (what almost everyone chose).
RISC-V is in another land, where they effectively have
no 32-bit operations, but rather a convention that all 32-bit inputs
must be sign-extended in a 64-bit register.
If you pick ILP64 for your ABI, then you will get rid of almost all of
these zero- and sign-extensions of 32-bit C and C++ code. It will just
work. If you pick I32LP64, then you should have a full suite of 32-bit >operations and 64-bit operations, at least for all add, subtract, and
compare operations.
And if you do I32LP64, your indexed addressing
modes should have 3 types of indexed registers: 64-bit, 32-bit signed,
and 32-bit unsigned. That worked well for ARM64.
kegs@provalid.com (Kent Dickey) writes:
In article <2025Oct4.121741@mips.complang.tuwien.ac.at>,...
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
int subroutine( int a, int b )
{
return a+b;
}
...I tested this on AMD64, and did not find sign-extension in the caller, >>>neither with gcc-14 nor with clang-19; both produce the following code >>>for your example (with "subroutine" renamed into "subroutine1").
0000000000000000 <subroutine1>:
0: 8d 04 37 lea (%rdi,%rsi,1),%eax
3: c3 ret
AMD64 in hardware does 0 extension of 32-bit operations. From your
example "lea (%rdi,%rsi,1),%eax" (AT&T notation, so %eax is the dest),
the 64-bit register %rax will have 0's written into bits [63:32].
So the AMD64 convention for 32-bit values in 64-bit registers is to >>zero-extend on writes. And to ignore the upper 32-bits on reads, so
using a 64-bit register should use the %exx name.
Interesting. At some point I got the impression that LEA produces a
64-bit result, because it produces an address, but testing reveals
that LEA has a 32-bit zero-extended variant indeed.
kegs@provalid.com (Kent Dickey) writes:------------------------------------------------------------
In article <2025Oct4.121741@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
int subroutine( int a, int b )
{
return a+b;
}
RISC-V is in another land, where they effectively have
no 32-bit operations, but rather a convention that all 32-bit inputs
must be sign-extended in a 64-bit register.
RISC-V has a number of sign-extending 32-bit instructions, and a
calling convention to go with it.
There seem to be the following options:
Have no 32-bit instructions, and insert sign-extension or
zero-extension instructions where necessary (or implicitly in all
operands, as I outlined earlier). SPARC V9 and PowerPC64 seem to take
this approach.
Have 32-bit instructions that sign-extend: MIPS64, Alpha, and RV64.
Have 32-bit instructions that zero-extend: AMD64 and ARM A64.
Have 32-bit instructions that sign-extend and 32-bit instructions that zero-extend. No architecture that does that is known to me. It would
be a good match for the SPARC-V9 and PowerPC64 calling convention.
There is also one instruction set (ARM A64) that has special 32-bit sign-extension and zero-extension forms for some operands.
And you can then adapt the calling convention to match the instruction
set. For "no 32-bit instructions", garbage-extension seems to be the cheapest approach to me, but I expect that when SPARC-V9 and PowerPC64
came on the market, there was enough C code with missing prototypes
around that they preferred a more forgiving calling convention.
If you pick ILP64 for your ABI, then you will get rid of almost all of >these zero- and sign-extensions of 32-bit C and C++ code. It will just >work. If you pick I32LP64, then you should have a full suite of 32-bit >operations and 64-bit operations, at least for all add, subtract, and >compare operations.
For compare, divide, shift-right and rotate, you either first need to sign/zero-extend the register, or you need 32-bit versions (possibly
both signed and unsigned).
And if you do I32LP64, your indexed addressing
modes should have 3 types of indexed registers: 64-bit, 32-bit signed,
and 32-bit unsigned. That worked well for ARM64.
It is certainly part of the way towards my idea of having sign- and zero-extended 32-bit operands for every operand of every instruction.
It would be interesting to see how many sign-extensions and
zero-extensions (whether explicit or implicitly part of the
instruction) are executed in code that is generated from various C
sources (with and without -fwrapv).
I expect that it's highly
dependent on the programming style. Sure there are types like pid_t
where you have no choice, but in frequently occuring cases you can
choose:
for (i=0; i<n; i++) {
... a[i] ...
}
Here you can choose whether to define i as int, unsigned, long,
unsigned long, size_t, etc. If you care for portability to 16-bit
machines, size_t is a good idea here, otherwise long and unsigned long
also are efficient.
If n is unsigned, you can also choose unsigned,
but then this code will be slow on RV64 (and MIPS64 and SPARC V9 and PowerPC64 and Alpha).
If n is int, you can also choose int, and there is actually enough information here to make the code efficient (even with -fwrapv),
because in this code int overflow really cannot happen,
but in code
that's not much different from this one (e.g., using != instead of <), -fwrapv will result in an inserted sign extension on AMD64, and not
using -fwrapv may result in unintended behaviour thanks to the
compiler assuming that int overflow does not happen.
ILP64 would have spared us all these considerations.
- anton--- Synchronet 3.21a-Linux NewsLink 1.2
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
On 10/2/2025 7:50 PM, MitchAlsup wrote:
My 66000 2.0
After 4-odd years of ISA stability, I ran into a case where
I <pretty much> needed to change the instruction formats.
And after bragging to Quadribloc about its stability--it
reached the point where it was time to switch to version 2.0.
Well, its time to eat crow.
--------------------------------------------------------------
Memory reference instructions already produce 64-bit values
from Byte, HalfWord, Word and DoubleWord memory references
in both Signed and unSigned flavors. These supports both
integer and floating point due to the single register file.
Essentially, I need that property in both integer and floating
point calculations to eliminate instructions that merely apply
value range constraints--just like memory !
ISA 2.0 changes allows calculation instructions; both Integer
and Floating Point; and a few other miscellaneous instructions
(not so easily classified) the same uniformity.
In all cases, an integer calculation produces a 64-bit value
range limited to that of the {Sign}|u{Size}--no garbage bits
in the high parts of the registers--the register accurately
represents the calculation as specified {Sign}|u{Size}.
I must be missing something. Suppose I have
C := A + B
where A and C are 16 bit signed integers and B is an 8 bit signed
integer. As I understand what you are doing, loading B into a register
will leave the high order 56 bits zero. But the add instruction will
presumably be half word, so if B is negative, it will get an incorrect
answer (because B is not sign extended to 16 bits).
What am I missing?
A is loaded as 16-bits properly sign to 64-bits: range[-32768..32767]
B is loaded as 8-bits properly sign to 64-bits: range[-128..127]
ADDSH Rc,Ra,Rb
Adds 64-bit Ra and 64-bit Rb and then sign extends the result from bit<15>. The result is a properly signed 64-bit value: range [-32768..32767]
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:...
My 66000 CMP is signless--it compares two integer registers and delivers
a bit vector of all possible comparisons {2 equality, 4 signed, 4 unsigned,
4 range checks, [and in FP land 10-bits are the class of the RS1 operand]}
It is certainly part of the way towards my idea of having sign- and
zero-extended 32-bit operands for every operand of every instruction.
Unnecessary if the integer calculation deliver properly range-limited
64-bit results.
It would be interesting to see how many sign-extensions and
zero-extensions (whether explicit or implicitly part of the
instruction) are executed in code that is generated from various C
sources (with and without -fwrapv).
In GNUPLOT is is just over 4% of instruction count for 64-bit-only
integer calculations.
Counted for() loops are somewhat special in that it is quite easy to >determine that the loop index never exceeds the range-limit of the >container.
If n is unsigned, you can also choose unsigned,
but then this code will be slow on RV64 (and MIPS64 and SPARC V9 and
PowerPC64 and Alpha).
Example please !?!
If n is int, you can also choose int, and there is actually enough
information here to make the code efficient (even with -fwrapv),
because in this code int overflow really cannot happen,
Consider the case where n is int64_t or uint64_t !?!
Consider the C-preprocessor with::
# define int (short int) // !!
in scope.
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:..
My 66000 CMP is signless--it compares two integer registers and delivers
a bit vector of all possible comparisons {2 equality, 4 signed, 4 unsigned, >4 range checks, [and in FP land 10-bits are the class of the RS1 operand]}
With an 88000-style compare and a result register of 64 bits, you can
spend 14 bits on 64-bit comparison, 14 bits on 32-bit comparison, 14
bits on 16-bit comparison, and 14 bits on 8-bit comparison, and still
have 8 bits left. What is a "range check" and why does it take 4
bits?
It is certainly part of the way towards my idea of having sign- and
zero-extended 32-bit operands for every operand of every instruction.
Unnecessary if the integer calculation deliver properly range-limited >64-bit results.
Sign- or zero extension will still be necessary for things like
long a=...
int b=a;
.. c[b];
With the extension in the operands, you do not need any extension instructions, not even for division, right-shift etc.
The question, however, is if the extensions occur often enough to
merit such features. I lean towards the SPARC/PowerPC/My 66000-v1
approach here.
It would be interesting to see how many sign-extensions and
zero-extensions (whether explicit or implicitly part of the
instruction) are executed in code that is generated from various C
sources (with and without -fwrapv).
In GNUPLOT is is just over 4% of instruction count for 64-bit-only
integer calculations.
Now what if you had a calling convention with garbage-extension? A
number of extensions in your examples would go away.
Counted for() loops are somewhat special in that it is quite easy to >determine that the loop index never exceeds the range-limit of the >container.
There have been enough cases where such reasoning led to "optimizing"
code into an infinite loop and other fallout of adversarial compilers.
If n is unsigned, you can also choose unsigned,
but then this code will be slow on RV64 (and MIPS64 and SPARC V9 and
PowerPC64 and Alpha).
Example please !?!
With a slightly different loop:
long foo(long a[], unsigned l, unsigned h)
{
unsigned i; // <---this variable should be uint64_t
long r=0;
for (i=l; i!=h; i++)
r+=a[i];
return r;
}
gcc-10 -O3 produces on RV64G:
0000000000000000 <foo>:
0: 872a mv a4,a0
2: 4501 li a0,0
4: 00c58c63 beq a1,a2,1c <.L4>
0000000000000008 <.L3>:
8: 02059793 slli a5,a1,0x20 // eliminate HoBs
c: 83f5 srli a5,a5,0x1d // does not have scaled indexing
e: 97ba add a5,a5,a4 // does not have indexing
10: 639c ld a5,0(a5) // all that work
12: 2585 addiw a1,a1,1
14: 953e add a0,a0,a5 // loop induction
16: feb619e3 bne a2,a1,8 <.L3>
1a: 8082 ret
000000000000001c <.L4>:
1c: 8082 ret
--- Synchronet 3.21a-Linux NewsLink 1.2If n is int, you can also choose int, and there is actually enough
information here to make the code efficient (even with -fwrapv),
because in this code int overflow really cannot happen,
Consider the case where n is int64_t or uint64_t !?!
Then the first condition does not hold on I32LP64.
Consider the C-preprocessor with::
# define int (short int) // !!
in scope.
Then the compiler will see short int, and generate code accordingly.
What's your point?
- anton
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
...
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
If n is unsigned, you can also choose unsigned,
but then this code will be slow on RV64 (and MIPS64 and SPARC V9 and
PowerPC64 and Alpha).
Example please !?!
With a slightly different loop:
long foo(long a[], unsigned l, unsigned h)
{
unsigned i;
long r=0;
for (i=l; i!=h; i++)
r+=a[i];
return r;
}
gcc-10 -O3 produces on RV64G:
0000000000000000 <foo>:
0: 872a mv a4,a0
2: 4501 li a0,0
4: 00c58c63 beq a1,a2,1c <.L4>
0000000000000008 <.L3>:
8: 02059793 slli a5,a1,0x20
c: 83f5 srli a5,a5,0x1d
e: 97ba add a5,a5,a4
10: 639c ld a5,0(a5)
12: 2585 addiw a1,a1,1
14: 953e add a0,a0,a5
16: feb619e3 bne a2,a1,8 <.L3>
1a: 8082 ret
000000000000001c <.L4>:
1c: 8082 ret
In article <2025Oct7.210925@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
...
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
If n is unsigned, you can also choose unsigned,
but then this code will be slow on RV64 (and MIPS64 and SPARC V9 and
PowerPC64 and Alpha).
Example please !?!
With a slightly different loop:
long foo(long a[], unsigned l, unsigned h)
{
unsigned i;
long r=0;
for (i=l; i!=h; i++)
r+=a[i];
return r;
}
gcc-10 -O3 produces on RV64G:
0000000000000000 <foo>:
0: 872a mv a4,a0
2: 4501 li a0,0
4: 00c58c63 beq a1,a2,1c <.L4>
0000000000000008 <.L3>:
8: 02059793 slli a5,a1,0x20
c: 83f5 srli a5,a5,0x1d
e: 97ba add a5,a5,a4
10: 639c ld a5,0(a5)
12: 2585 addiw a1,a1,1
14: 953e add a0,a0,a5
16: feb619e3 bne a2,a1,8 <.L3>
1a: 8082 ret
000000000000001c <.L4>:
1c: 8082 ret
Unsigned 32-bit stuff on RISC-V has a habit of blowing up with lots of overhead instructions. Change the loop condition to "i < h", and you get
on godbolt.org with -O2 -march=rv64g
foo(long*, unsigned int, unsigned int):
mv a5,a0
bgeu a1,a2,.L4
addiw a4,a2,-1
subw a4,a4,a1
slli a4,a4,32
slli a1,a1,32
srli a1,a1,32
srli a4,a4,32
add a4,a4,a1
addi a3,a0,8
slli a4,a4,3
slli a1,a1,3
li a0,0
add a5,a5,a1
add a4,a4,a3
.L3:
ld a3,0(a5)
addi a5,a5,8
add a0,a0,a3
bne a5,a4,.L3
ret
.L4:
li a0,0
ret
This does get better with "-march=rv64g_zab", but Zab isn't part of RV64G.
GCC has actually optimized the loop itself better, but it has lots of
fixup code to create 64-bit register versions of the unsigned inputs
(because the RISC-V ABI specifies all 32-bit quantities must be
sign-extended at the function call boundaries, even if they are
unsigned).
In many cases, the sign-extension works well (BGEU on 64-bit registers
that are 32-bit sign-extended, works as it would if the values were 0-extended). But mixing true 64-bit unsigned with 32-bit unsigned
requires fixup instructions. And the lack of a ZEXT.W in the basic
64-bit instruction set was a mistake. RISC-V gives us a modern example
of how to handle not having a full suite of 32-bit instructions, and
what that would look like.
Kent
GCC has actually optimized the loop itself better, but it has lots of
fixup code to create 64-bit register versions of the unsigned inputs
(because the RISC-V ABI specifies all 32-bit quantities must be
sign-extended at the function call boundaries, even if they are
unsigned).
RISC-V gives us a modern example
of how to handle not having a full suite of 32-bit instructions, and
what that would look like.
Kent Dickey <kegs@provalid.com> schrieb:
GCC has actually optimized the loop itself better, but it has lots of
fixup code to create 64-bit register versions of the unsigned inputs
(because the RISC-V ABI specifies all 32-bit quantities must be
sign-extended at the function call boundaries, even if they are
unsigned).
You mean 0xffffffff as unsigned has to be passed as
0xffffffffffffffff ? Somebody was not thinking that one through...
At least Loongarch gets that one right; unsigned and signed are
zero- and sign-extended, respectively.
[...]
RISC-V gives us a modern example
of how to handle not having a full suite of 32-bit instructions, and
what that would look like.
Seems like it...
And after bragging to Quadribloc about its stability--it reached the
point where it was time to switch to version 2.0.
In article <2025Oct7.210925@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
...
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
If n is unsigned, you can also choose unsigned,
but then this code will be slow on RV64 (and MIPS64 and SPARC V9 and
PowerPC64 and Alpha).
Example please !?!
With a slightly different loop:
long foo(long a[], unsigned l, unsigned h)
{
unsigned i;
long r=0;
for (i=l; i!=h; i++)
r+=a[i];
return r;
}
gcc-10 -O3 produces on RV64G:
0000000000000000 <foo>:
0: 872a mv a4,a0
2: 4501 li a0,0
4: 00c58c63 beq a1,a2,1c <.L4>
0000000000000008 <.L3>:
8: 02059793 slli a5,a1,0x20
c: 83f5 srli a5,a5,0x1d
e: 97ba add a5,a5,a4
10: 639c ld a5,0(a5)
12: 2585 addiw a1,a1,1
14: 953e add a0,a0,a5
16: feb619e3 bne a2,a1,8 <.L3>
1a: 8082 ret
000000000000001c <.L4>:
1c: 8082 ret
Unsigned 32-bit stuff on RISC-V has a habit of blowing up with lots of >overhead instructions. Change the loop condition to "i < h", and you get
on godbolt.org with -O2 -march=rv64g
foo(long*, unsigned int, unsigned int):
mv a5,a0
bgeu a1,a2,.L4
addiw a4,a2,-1
subw a4,a4,a1
slli a4,a4,32
slli a1,a1,32
srli a1,a1,32
srli a4,a4,32
add a4,a4,a1
addi a3,a0,8
slli a4,a4,3
slli a1,a1,3
li a0,0
add a5,a5,a1
add a4,a4,a3
.L3:
ld a3,0(a5)
addi a5,a5,8
add a0,a0,a3
bne a5,a4,.L3
ret
.L4:
li a0,0
ret
And the lack of a ZEXT.W in the basic
64-bit instruction set was a mistake.
RISC-V gives us a modern example
of how to handle not having a full suite of 32-bit instructions, and
what that would look like.
Kent Dickey <kegs@provalid.com> schrieb:
GCC has actually optimized the loop itself better, but it has lots of
fixup code to create 64-bit register versions of the unsigned inputs
(because the RISC-V ABI specifies all 32-bit quantities must be
sign-extended at the function call boundaries, even if they are
unsigned).
You mean 0xffffffff as unsigned has to be passed as
0xffffffffffffffff ? Somebody was not thinking that one through...
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
It is certainly part of the way towards my idea of having sign- and
zero-extended 32-bit operands for every operand of every instruction.
Unnecessary if the integer calculation deliver properly range-limited
64-bit results.
Sign- or zero extension will still be necessary for things like
long a=...
int b=a;
.. c[b];
The movement of long to int will 'smash' out extraneous significance.
I did too, until <many> conversations with LLVM compiler writer.
GNUPLOT seems to be a banner application wrt range-limited calcu-
lations.
Now what if you had a calling convention with garbage-extension? A
number of extensions in your examples would go away.
Not many, few are on ABI and most of the ones that are are dealt with
when moving arguments to preserved registers.
So, you could send HoBs
that are never observed since the MOV Rpreserved,Rargument gets changed
into a SR[AL] Rpreserved,Rargument<32:0> at no space or time cost.
If the calling convention guarantees that ints are zero-extended (sounds perverse, but RV64 has the guarantee that unsigned is passed in
sign-extended form, which is equally perverse), then the compiler must
use instructions that produce a zero-extended result (e.g., AMD64's
addl). If the calling convention only requires and guarantees the
low-order 32 bits (I call this garbage-extended), then the compiler can
use instructions that perform 64-bit adds; this is what we are seeing
above.
The other side of the medal is what is needed at the caller: If the
caller needs to cconvert a sign-extended int into a long, it does not
have to do anything.
kegs@provalid.com (Kent Dickey) writes:
In article <2025Oct7.210925@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
MitchAlsup <user5857@newsgrouper.org.invalid> writes:<snip>
No instruction set has a full suite of 32-bit instructions with both sign-extended and zero-extended results. They all have workarounds
for the lack of the full suite, with various associated costs that
have to be balanced against the costs of providing the full suite.
- anton--- Synchronet 3.21a-Linux NewsLink 1.2
On Fri, 03 Oct 2025 02:50:23 +0000, MitchAlsup wrote:
And after bragging to Quadribloc about its stability--it reached the
point where it was time to switch to version 2.0.
I really don't think you have anything to be ashamed of.
Getting new ideas that are capable of radically improving your ISA and modifying it to make use of them is an entirely appropriate thing to do.--- Synchronet 3.21a-Linux NewsLink 1.2
And your ideas are ones which fit into your philosophy - it's not as if
you found yourself doing something wrong where _my_ way was better.
That would be a valid occasion for "eating crow", but that isn't what happened.
John Savard
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
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.
Only those who assumed sizeof(int) = sizeof(char *).
This was
not true on the PDP-11,
and it was a standards violation, anyway.
And I am sure that C
programs were much more relevant for selling these machines than
FORTRAN programs.
Based on what data?
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.
The problem with 64-bit INTEGERs for Fortran is that they make REAL
unusable for lots of existing code.
I didn't port a lot of code from the 11 to other machines, but my recollection >is that the widespread assumption in Berkeley Vax code that location zero was >addressable and contained binary zeros was much more painful to fix than
size issues.
John Levine <johnl@taugh.com> writes:
I didn't port a lot of code from the 11 to other machines, but my recollection
is that the widespread assumption in Berkeley Vax code that location zero was >>addressable and contained binary zeros was much more painful to fix than >>size issues.
Sure, lots of things are more painful to fix, but Thomas Koenig's
claim was that if the 64-bit machines would not run FORTRAN code "as
is", nobody would buy them.
Thomas Koenig <tkoenig@netcologne.de> writes:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
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.
Only those who assumed sizeof(int) = sizeof(char *).
And lots of others, e.g., those that assumed that longs are 4 bytes in
size.
This was
not true on the PDP-11,
Can you elaborate on this?
Based on 4 months of internship at HP in 1988 and 1989, in a group
that did sales support, tech support, and courses on HP 9000
workstations and servers and HP/UX (the OS of the HP 9000 machines).
I don't remember hearing about a customer that used FORTRAN.
Based also on the impressions I got on Usenet. Apart from SPECfp,
Fortran was nowhere to be seen.
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
Based also on the impressions I got on Usenet. Apart from SPECfp,
Fortran was nowhere to be seen.
New flash: Engineers rarely use Usenet (I'm a bit of an exception
there).
Thomas Koenig wrote:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:That depends strongly on when and where you are talking about:
Based also on the impressions I got on Usenet. Apart from SPECfp,
Fortran was nowhere to be seen.
New flash: Engineers rarely use Usenet (I'm a bit of an exception
there).
Back when the Internet (Arpanet) got its first node outside of the US,
it was in Norway in 1973, but our universities did not get a link until 1983.
When I started working for Norsk Hydro in 1984, they had already setup a 64-kbit/s line from our Bergen office to the university there, and the reason it was installed was that we had engineers who needed Usenet access.
Personally I've been on Usenet for close to 40 years. It could have been
a bit more but I did not use Usenet at NTH in Trondheim and I did not
setup a news reader immediately when I started in Hydro, with
responsibility for all IBM PC compatibles worldwide.
For C and C++ code, the standard dictates that all integer operations are done with "int" precision, unless some operand is larger than int, and then do it in that precision. So there's no real need for 8-bit and 16-bit operations to be natively by the CPU--these operations are actually done
as int's already. If you have a variable which is a byte, then assigning
to that variable, and then using that variable again you will need to zero-extend, but honestly, this is not usually a performance path. It's likely to be stored to memory instead, so no masking or sign extending
should be needed.
Kent
John Levine <johnl@taugh.com> writes:
I didn't port a lot of code from the 11 to other machines, but my recollection
is that the widespread assumption in Berkeley Vax code that location zero was
addressable and contained binary zeros was much more painful to fix than >size issues.
Sure, lots of things are more painful to fix, but Thomas Koenig's
claim was that if the 64-bit machines would not run FORTRAN code "as
is", nobody would buy them.
Concerning pain, I found that in Gforth (which contains C code and
Forth code) we had many more portability bugs in the C code than in
the Forth code, where we had almost no portability bugs.
That's because Forth has only two integer types: cell (a machine word)
and double cell (two machine words); and if you use one instead of the
other, the code fails, whatever the cell size is.
By contrast, in the C code we have to deal with a large number of^only
integer types (not just int, long, etc., but also, e.g., off_t), with
the relations between the types being different on different
platforms, or, in the case of off_t, also depending #defines. On one
machine some function parameter was a long or whatever, on a different
one it was a bla_t or whatever. Of course, these days one might
target only Linux and MacOS and reach >99% of desktops and servers
(the result runs on Windows through WSL2), but that solves the problem
by reducing the portability requirements.
- anton--- Synchronet 3.21a-Linux NewsLink 1.2
Thomas Koenig <tkoenig@netcologne.de> writes:
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
Thomas Koenig <tkoenig@netcologne.de> writes:
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.
Only those who assumed sizeof(int) = sizeof(char *).
And lots of others, e.g., those that assumed that longs are 4 bytes in
size.
This was
not true on the PDP-11,
Can you elaborate on this? What do you think is sizeof(int) on a
PDP-11, and what do you think is sizeof(char *) on a PDP-11?
and it was a standards violation, anyway.
That's hilarious. C89 was three years old in 1992. The majority of C programs available in 1992 were started before ANSI C was released,
and thus contained code from before ANSI C. And like today,
programmers are asked to spend time on other things than fixing things
that are not broken.
And I am sure that C
programs were much more relevant for selling these machines than
FORTRAN programs.
Based on what data?
Based on 4 months of internship at HP in 1988 and 1989, in a group
that did sales support, tech support, and courses on HP 9000
workstations and servers and HP/UX (the OS of the HP 9000 machines).
I don't remember hearing about a customer that used FORTRAN.
Based also on the impressions I got on Usenet. Apart from SPECfp,
Fortran was nowhere to be seen.
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.
The problem with 64-bit INTEGERs for Fortran is that they make REAL >unusable for lots of existing code.
The size of FORTRAN INTEGERs is something the FORTAN people have to
decide, and I made no statement on that.
If FORTRAN programs make the assumptions that sizeof(int)==4, maybe
you should tell the FORTRAN programmers something along these lines:
"it is a standards violation, anyway. Only people who like to play
these kind of games are caught."
- anton--- Synchronet 3.21a-Linux NewsLink 1.2
On 10/3/2025 11:40 AM, EricP wrote:
The issue with FP8 support seems to be that everyone who wants it also
wants their own definition so no matter what you do, it will be unused.
As for FP8:
There are multiple formats in use:
S.E3.M4: Bias=7 (Quats / Unit Vectors)
S.E3.M4: Bias=8 (Audio)
S.E4.M3: Bias=7 (NN's)
E4.M4: Bias=7 (HDR images)
On 10/6/25 8:38 PM, Kent Dickey wrote:
[SNIP]
For C and C++ code, the standard dictates that all integer operations are[SNIP]
done with "int" precision, unless some operand is larger than int, and
then
do it in that precision. So there's no real need for 8-bit and 16-bit
operations to be natively by the CPU--these operations are actually done
as int's already. If you have a variable which is a byte, then assigning
to that variable, and then using that variable again you will need to
zero-extend, but honestly, this is not usually a performance path. It's
likely to be stored to memory instead, so no masking or sign extending
should be needed.
Kent
Can you point me to the section in "the standard" which indicates
'all integer operations are done with "int" precision'?
What if the wording was changed to:
'all integer operations are done with _at least_ "int" precision',
e.g. one could use long. Would that break conforming code?
Brian
6.3 Conversions
6.3.1.3 Signed and unsigned integers
1 When a value with integer type is converted to another integer type
other than _Bool, if the value can be represented by the new type,
it is unchanged.
2 Otherwise, if the new type is unsigned, the value is converted by >repeatedly adding or subtracting one more than the maximum value that
can be represented in the new type until the value is in the range of
the new type.60)
[EricP: this is the same as zero extend]
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
Thomas Koenig <tkoenig@netcologne.de> writes:
and it was a standards violation, anyway.
That's hilarious. C89 was three years old in 1992. The majority of C
programs available in 1992 were started before ANSI C was released,
and thus contained code from before ANSI C. And like today,
programmers are asked to spend time on other things than fixing things
that are not broken.
If application vendors were subject to the same recall standards that
the auto industry is subject, that might change. {Remember the Pinto}
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
Thomas Koenig <tkoenig@netcologne.de> writes:<snip>
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:[...]
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.
The vast majority of C/C++ programs ran just fine on I32LP64. There
were some that didn't, but it was certainly not "most".
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
Concerning pain, I found that in Gforth (which contains C code and
Forth code) we had many more portability bugs in the C code than in
the Forth code, where we had almost no portability bugs.
C, itself, would be3 a "lot less painful" if C only had 2 integer types >1-word and 2-words. But, instead, they typical 2^(n+3) machines have >8-integer types (Signed, unSigned}|u{Byte, Half, Word, DBLE}, and then
to make it as bad as possible, there are a myriad of types {ptr_dif,
size_t, off_t, ...} that change {Sign}|u{Size} on an architecture basis.
That's because Forth has only two integer types: cell (a machine word)
and double cell (two machine words); and if you use one instead of the
other, the code fails, whatever the cell size is.
Same as <old> FORTRAN.
By contrast, in the C code we have to deal with a large number of^only
integer types (not just int, long, etc., but also, e.g., off_t), with
the relations between the types being different on different
platforms, or, in the case of off_t, also depending #defines. On one
machine some function parameter was a long or whatever, on a different
one it was a bla_t or whatever. Of course, these days one might
target only Linux and MacOS and reach >99% of desktops and servers
(the result runs on Windows through WSL2), but that solves the problem
by reducing the portability requirements.
Blame goes to:: ISO/IEC 9899:1999 for trying to accommodate everyone
and ending up screwing everyone.
BGB wrote:
On 10/3/2025 11:40 AM, EricP wrote:
The issue with FP8 support seems to be that everyone who wants it also
wants their own definition so no matter what you do, it will be unused.
As for FP8:
-a There are multiple formats in use:
-a-a-a S.E3.M4: Bias=7 (Quats / Unit Vectors)
-a-a-a S.E3.M4: Bias=8 (Audio)
-a-a-a S.E4.M3: Bias=7 (NN's)
-a-a-a E4.M4: Bias=7-a-a (HDR images)
Its not just the memory formats, its also the operations.
In FP8 few may want to waste 1/8th of the encode space on NaN's.
Maybe not sticky infinity, rather saturate at max but not stick there.
Maybe no negative zero.
All of those encodings might be reallocated to values more useful
for that application.
They won't want to calculate single argument transcendentals like tan(x), they will use 256 byte lookup tables.
The multi-operand functions ADD, SUB, MUL, would be faster in hardware
than 64kB lookup tables.
Also a lot of these are used matrix ops - super-duper-SIMD.
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
Thomas Koenig <tkoenig@netcologne.de> writes:
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.
The problem with 64-bit INTEGERs for Fortran is that they make REAL
unusable for lots of existing code.
Nonsense::
CDC only had Double Precision FP data (60-bit)
with 18-bit integers
CRAY only had Double Precision FP data (64-bit)
with 24-bit integers
{{Even numerical analysists liked Seymore's 60-bit and 64-bit arithmetic compared to 32-bit IBM and 36-bit Univac FP arithmetic--even with those littered with huge mistakes we would not allow today.}}
The size of FORTRAN INTEGERs is something the FORTAN people have to
decide, and I made no statement on that.
If FORTRAN programs make the assumptions that sizeof(int)==4, maybe
you should tell the FORTRAN programmers something along these lines:
"it is a standards violation, anyway. Only people who like to play
these kind of games are caught."
FORTRAN programmers think of integer as 1 storage container--even on
CDC and CRAY.
The integer in memory is 60 or 64 bits, the integer in
register is 18-bit or 24-bit. FORTRAN programmers do not have problems
with putting 6|u6-bit characters in PDP-10 memory container, or 10|u6 field-data characters in one CDC memory container.