According to Thomas Koenig <tkoenig@netcologne.de>:
>> That's not a power-of-two length, so how do I keep using these numbers both
>> efficient and simple?
>
>Make the architecture byte-addressable, with another width for the
>bytes; possible choices are 6 and 9.

I'm pretty sure the world has spoken and we are going to use 8-bit
bytes forever. I liked the PDP-8 and PDP-10 but they are, you know, dead.

>Then make your architecture capable of misaligned loads and stores
>and an extra floating point format, maybe 45 bits, with 9 bits
>exponent and 36 bits of significand.

If you're worried about performance, use your 45 bit format and store
it in a 64 bit word.

The IBM 360/44 was an odd machine intended for real-time applications.
It had a hard wired subset of the 360's instruction set, including all
the floating point. There was a knob on the front panel you could turn
to set the number of bytes for double precision operands, with shorter
being faster. They were still stored in 64 bit doublewords, ignoring
the low bytes. I've never seen anything saying whether it was useful
in practice or people just left the knob at the default 56 bits.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Sunday, September 17, 2023 at 3:30:19 PM UTC-5, John Levine wrote:
> According to Thomas Koenig <tko...@netcologne.de>:
> >> That's not a power-of-two length, so how do I keep using these numbers both
> >> efficient and simple?
> >
> >Make the architecture byte-addressable, with another width for the
> >bytes; possible choices are 6 and 9.
> I'm pretty sure the world has spoken and we are going to use 8-bit
> bytes forever. I liked the PDP-8 and PDP-10 but they are, you know, dead.
<
In addition, the world has spoken and little endian also won.
<
> >Then make your architecture capable of misaligned loads and stores
> >and an extra floating point format, maybe 45 bits, with 9 bits
> >exponent and 36 bits of significand.
<
> If you're worried about performance, use your 45 bit format and store
> it in a 64 bit word.
<
In 1985 one could get a descent 32-bit pipelined RISC architecture in 1cm^2
Today this design in < 0.1mm^2 or you can make a GBOoO version < 2mm^2.
<
And you really need 5mm^2 to get enough pins on the part to feed what you
can put inside; 7mm^2 makes even more sense on pins versus perf.
<
So, why are you catering to ANY bit counts less than 64 ??
Intel has version with 512-bit data paths, GPUs generally use 1024-bits in
and 1024 bits out per cycle continuously per shader core.
<
It is no longer 1990, adjust your thinking to the modern realities or our time !
>
> The IBM 360/44 was an odd machine intended for real-time applications.
> It had a hard wired subset of the 360's instruction set, including all
> the floating point. There was a knob on the front panel you could turn
> to set the number of bytes for double precision operands, with shorter
> being faster. They were still stored in 64 bit doublewords, ignoring
> the low bytes. I've never seen anything saying whether it was useful
> in practice or people just left the knob at the default 56 bits.
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

On Sunday, September 17, 2023 at 3:42:40 PM UTC-5, MitchAlsup wrote:
> On Sunday, September 17, 2023 at 3:30:19 PM UTC-5, John Levine wrote:
> > According to Thomas Koenig <tko...@netcologne.de>:
> > >> That's not a power-of-two length, so how do I keep using these numbers both
> > >> efficient and simple?
> > >
> > >Make the architecture byte-addressable, with another width for the
> > >bytes; possible choices are 6 and 9.
> > I'm pretty sure the world has spoken and we are going to use 8-bit
> > bytes forever. I liked the PDP-8 and PDP-10 but they are, you know, dead.
> <
> In addition, the world has spoken and little endian also won.
> <
> > >Then make your architecture capable of misaligned loads and stores
> > >and an extra floating point format, maybe 45 bits, with 9 bits
> > >exponent and 36 bits of significand.
> <
> > If you're worried about performance, use your 45 bit format and store
> > it in a 64 bit word.
> <
> In 1985 one could get a descent 32-bit pipelined RISC architecture in 1cm^2
> Today this design in < 0.1mm^2 or you can make a GBOoO version < 2mm^2.
> <
> And you really need 5mm^2 to get enough pins on the part to feed what you
> can put inside; 7mm^2 makes even more sense on pins versus perf.
> <
> So, why are you catering to ANY bit counts less than 64 ??
> Intel has version with 512-bit data paths, GPUs generally use 1024-bits in
> and 1024 bits out per cycle continuously per shader core.
> <
> It is no longer 1990, adjust your thinking to the modern realities or our time !
> >
> > The IBM 360/44 was an odd machine intended for real-time applications.
> > It had a hard wired subset of the 360's instruction set, including all
> > the floating point. There was a knob on the front panel you could turn
> > to set the number of bytes for double precision operands, with shorter
> > being faster. They were still stored in 64 bit doublewords, ignoring
> > the low bytes. I've never seen anything saying whether it was useful
> > in practice or people just left the knob at the default 56 bits.
> > --
> > Regards,
> > John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> > Please consider the environment before reading this e-mail. https://jl.ly

Ugh
|> It is no longer 1990, adjust your thinking to the modern realities or our time

So why do we still design register files of only 64 bit registers?

For an example ISA, assume sixteen 1024 bit registers
with 32-bit instructions specifying register sub-fields of 1024, 512, 256, 128, 64 and even 32-bits.
(four bit register selectors and zero to five bit sub-field selectors for a two operand, one result RISC instructions)
The bigger the subfield, the greater the effective IPC!
Load and store instructions burdened with alignment, mask setup and other duties.

All in all, a very basic RISC with large registers and potential for good performance,
to the extent that the problem software can make effective use of the large registers,
natural alignment of data and wide ALUs.

On 9/17/2023 4:07 PM, JimBrakefield wrote:

snip

> So why do we still design register files of only 64 bit registers?
>
> For an example ISA, assume sixteen 1024 bit registers
> with 32-bit instructions specifying register sub-fields of 1024, 512, 256, 128, 64 and even 32-bits.
> (four bit register selectors and zero to five bit sub-field selectors for a two operand, one result RISC instructions)

I am not sure what you want here. Are the sub field selectors per
operand or per instruction? If you specify say a 64 bit subfield, does
that mean use only the low order 64 bits of the register(s), or is it
like a SIMD thing where you treat the registers as 16 fields, each 64
bits, or something else?

> The bigger the subfield, the greater the effective IPC!
> Load and store instructions burdened with alignment, mask setup and other duties.
>
> All in all, a very basic RISC with large registers and potential for good performance,
> to the extent that the problem software can make effective use of the large registers,
> natural alignment of data and wide ALUs.
>

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Friday, September 15, 2023 at 12:51:36 PM UTC-5, EricP wrote:
>
> Considerations in the design of a computer with high
> logic-to-memory speed ratio 1962
> https://archive.computerhistory.org/resources/access/text/2020/10/102714096-05-01-acc.pdf
<
Thank you for this reference. James Thornton really had his finger on the pulse
of computer design--almost every problem he talks about in this reference still
is an actual problem on our most modern (and fastest) designs.
<
His analysis of wire delay and clock skew and having a library of fixed logic
building blocks mirrors advanced VLSI of today (except for the tooling between
concept and layout (Verilog synthesis).

On Friday, September 15, 2023 at 12:51:36 PM UTC-5, EricP wrote:
>
> Considerations in the design of a computer with high
> logic-to-memory speed ratio 1962
> https://archive.computerhistory.org/resources/access/text/2020/10/102714096-05-01-acc.pdf
<
Thank you for this reference. James Thornton really had his finger on the pulse
of computer design--almost every problem he talks about in this reference still
is an actual problem on our most modern (and fastest) designs.
<
His analysis of wire delay and clock skew and having a library of fixed logic
building blocks mirrors advanced VLSI of today (except for the tooling between
concept and layout (Verilog synthesis).

On Sunday, September 17, 2023 at 6:07:05 PM UTC-5, JimBrakefield wrote:
> On Sunday, September 17, 2023 at 3:42:40 PM UTC-5, MitchAlsup wrote:
> > <
> > It is no longer 1990, adjust your thinking to the modern realities or our time !
>
> |> It is no longer 1990, adjust your thinking to the modern realities or our time
<
> So why do we still design register files of only 64 bit registers?
>
> For an example ISA, assume sixteen 1024 bit registers
<
Basically there is a paradigm whereby 1 register contains 1 value.
Do you want 1024-bit integers, 1024-bit pointers, and 1024-bit FP values ??
If yes, make the RF be 1024 bits in size; else don't.
<
> with 32-bit instructions specifying register sub-fields of 1024, 512, 256, 128, 64 and even 32-bits.
<
Where do the encoding bits come from ?? The beauty of 64-bit ISA is that encoding of
the operand sizes takes 0-bits (except in LD/ST and possibly FP).
<
> (four bit register selectors and zero to five bit sub-field selectors for a two operand, one result RISC instructions)
<
How do you specify 16-bits and 8-bits ??
<
> The bigger the subfield, the greater the effective IPC!
<
Does this work for LISP programs ??
<
> Load and store instructions burdened with alignment, mask setup and other duties.
<
So, you have to set yourself up to read 1024-bits × sets + addressSize×2 and then
only use 8-64-bits most of the time. This is a great waste of power most of the time.
>
> All in all, a very basic RISC with large registers and potential for good performance,
> to the extent that the problem software can make effective use of the large registers,
> natural alignment of data and wide ALUs.

On Sunday, September 17, 2023 at 7:09:01 PM UTC-5, Stephen Fuld wrote:
> On 9/17/2023 4:07 PM, JimBrakefield wrote:
>
> snip
> > So why do we still design register files of only 64 bit registers?
> >
> > For an example ISA, assume sixteen 1024 bit registers
> > with 32-bit instructions specifying register sub-fields of 1024, 512, 256, 128, 64 and even 32-bits.
> > (four bit register selectors and zero to five bit sub-field selectors for a two operand, one result RISC instructions)
<
> I am not sure what you want here. Are the sub field selectors per
> operand or per instruction? If you specify say a 64 bit subfield, does
> that mean use only the low order 64 bits of the register(s), or is it
> like a SIMD thing where you treat the registers as 16 fields, each 64
> bits, or something else?
<
How would you encode::
<
uint8_t c[];
uint16_t h[];
uint32_t w[];
for( int j = 0; j < wMAX; j++ )
{
for( int i = 0; i < hMAX; i++ )
h[i] = c[i] * hMULT;
w[j] = h[j+hMAX/2]*c[j+hMAX/2+7];
}
<
?????
<
> > The bigger the subfield, the greater the effective IPC!
> > Load and store instructions burdened with alignment, mask setup and other duties.
> >
> > All in all, a very basic RISC with large registers and potential for good performance,
> > to the extent that the problem software can make effective use of the large registers,
> > natural alignment of data and wide ALUs.
> >
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On Sunday, September 17, 2023 at 7:09:01 PM UTC-5, Stephen Fuld wrote:
> On 9/17/2023 4:07 PM, JimBrakefield wrote:
>
> snip
> > So why do we still design register files of only 64 bit registers?
> >
> > For an example ISA, assume sixteen 1024 bit registers
> > with 32-bit instructions specifying register sub-fields of 1024, 512, 256, 128, 64 and even 32-bits.
> > (four bit register selectors and zero to five bit sub-field selectors for a two operand, one result RISC instructions)
> I am not sure what you want here. Are the sub field selectors per
> operand or per instruction? If you specify say a 64 bit subfield, does
> that mean use only the low order 64 bits of the register(s), or is it
> like a SIMD thing where you treat the registers as 16 fields, each 64
> bits, or something else?
> > The bigger the subfield, the greater the effective IPC!
> > Load and store instructions burdened with alignment, mask setup and other duties.
> >
> > All in all, a very basic RISC with large registers and potential for good performance,
> > to the extent that the problem software can make effective use of the large registers,
> > natural alignment of data and wide ALUs.
> >
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

Ugh,
|> Are the sub field selectors per
|> operand or per instruction? If you specify say a 64 bit subfield, does
|> that mean use only the low order 64 bits of the register(s), or is it
|> like a SIMD thing where you treat the registers as 16 fields, each 64
|> bits, or something else?

Haven't done an actual ISA encoding, so the details are fluid.
The idea is that there are instructions with 64 to 1024 power of two bit size operands.
So with 64-bit operands one can do a single 64-bit operation on any of the 256 possible 64-bit sub fields
Likewise a 1024-bit SIMD operation on any of the 16 "registers".
Thus one can still do 64-bit operations or it the algorithm allows wider operations at greater IPC.

On Sunday, September 17, 2023 at 7:26:40 PM UTC-5, MitchAlsup wrote:
> On Sunday, September 17, 2023 at 7:09:01 PM UTC-5, Stephen Fuld wrote:
> > On 9/17/2023 4:07 PM, JimBrakefield wrote:
> >
> > snip
> > > So why do we still design register files of only 64 bit registers?
> > >
> > > For an example ISA, assume sixteen 1024 bit registers
> > > with 32-bit instructions specifying register sub-fields of 1024, 512, 256, 128, 64 and even 32-bits.
> > > (four bit register selectors and zero to five bit sub-field selectors for a two operand, one result RISC instructions)
> <
> > I am not sure what you want here. Are the sub field selectors per
> > operand or per instruction? If you specify say a 64 bit subfield, does
> > that mean use only the low order 64 bits of the register(s), or is it
> > like a SIMD thing where you treat the registers as 16 fields, each 64
> > bits, or something else?
> <
> How would you encode::
> <
> uint8_t c[];
> uint16_t h[];
> uint32_t w[];
> for( int j = 0; j < wMAX; j++ )
> {
> for( int i = 0; i < hMAX; i++ )
> h[i] = c[i] * hMULT;
> w[j] = h[j+hMAX/2]*c[j+hMAX/2+7];
> }
> <
> ?????
> <
> > > The bigger the subfield, the greater the effective IPC!
> > > Load and store instructions burdened with alignment, mask setup and other duties.
> > >
> > > All in all, a very basic RISC with large registers and potential for good performance,
> > > to the extent that the problem software can make effective use of the large registers,
> > > natural alignment of data and wide ALUs.
> > >
> > --
> > - Stephen Fuld
> > (e-mail address disguised to prevent spam)

Ugh
> How would you encode::
> uint8_t c[];
> uint16_t h[];
> uint32_t w[];
> for( int j = 0; j < wMAX; j++ )
> {
> for( int i = 0; i < hMAX; i++ )
> h[i] = c[i] * hMULT;
> w[j] = h[j+hMAX/2]*c[j+hMAX/2+7];
> }
The load and store instructions would specify the memory data sizes, the data register sizes and a mask.
The mask implies the number of uint8, uint16 and uint32 in their respective load instructions.
The load instruction would probably also specify the subfield size which would need to be at least as large as the number of bits set in the mask.
Frequently the mask would be an immediate value following the instruction.

Am posting a "fresh" idea for discussion. Any student could probably do a rough implementation in short order.

On Sunday, September 17, 2023 at 2:42:40 PM UTC-6, MitchAlsup wrote:

> In addition, the world has spoken and little endian also won.

Little-endian has won, but I really don't think it's because anyone
really asked for it. The PDP-11, the 6502, and the 8080 just happened
to be little-endian, but were very popular for other reasons entirely.

The PDP-11 was a minicomputer which was powerful and cheap because
of a more modern architecture than other minis.

The 6502 was inexpensive compared to the 6800 and the 8080.

The 8080 was first.

John Savard

On Sunday, September 17, 2023 at 11:58:18 AM UTC-6, John Dallman wrote:
> No
> architecture can do everything efficiently.

Although that is doubtless true, I have been trying to think of
how to make *stride* more efficient, the way that the Burroughs
Scientific Processor did. But trying to make a version of the BSP
that works for different widths of data seems to be a route to
excessive complexity.

One thought I had was to have 17 memory banks for all widths,
and just use the memory in each bank for either 72-bit floats or
twice as many 36-bit floats. That would waste memory bus
bandwidth in the shorter case.

Another thought was to get rid of the complelxity of the BSP,
and just use 16-channel memory. Programmers can simply
remember to put their 2048 x 2048 matrices inside 2048 x 2049
(or 2049 x 2048 for some dialects of FORTRAN) arrays. That
could easily be adapted to work with 36-bit floats as well just by
having twice as many address buses.

John Savard

On Thursday, September 14, 2023 at 11:06:36 PM UTC-6, Quadibloc wrote:

> One can have a vector register composed of a number of 72-bit registers,
> and one can have it handle twice as many 36-bit values by having one in
> each half of the register. That would make for rapid transfers to and from
> memory that are simple conceptually.
>
> If one does it that way, one could handle intermediate precision by doubling
> the width of the individual portions of the vector register - so that it's made
> up of 144-bit registers that can hold two double-precision numbers or four
> single-precision numbers. That could also hold three intermediate precision
> numbers... that are 48 bits in length.

Here, I very definitely am drawing heavily on the design of one specific
classic computer.

It was the Integrated Scientific Processor that was offered for the Univac 1100/90
which offered a Cray-like architecture with vector registers, but which, in addition,
not only allowed the vector registers to be used for 36-bit floats as well as 72-bit
floats, but also let twice as many values be packed into the vectors in that case.

John Savard

JimBrakefield wrote:
> On Sunday, September 17, 2023 at 3:42:40 PM UTC-5, MitchAlsup wrote:
>> On Sunday, September 17, 2023 at 3:30:19 PM UTC-5, John Levine wrote:
>>> According to Thomas Koenig <tko...@netcologne.de>:
>>>>> That's not a power-of-two length, so how do I keep using these numbers both
>>>>> efficient and simple?
>>>>
>>>> Make the architecture byte-addressable, with another width for the
>>>> bytes; possible choices are 6 and 9.
>>> I'm pretty sure the world has spoken and we are going to use 8-bit
>>> bytes forever. I liked the PDP-8 and PDP-10 but they are, you know, dead.
>> <
>> In addition, the world has spoken and little endian also won.
>> <
>>>> Then make your architecture capable of misaligned loads and stores
>>>> and an extra floating point format, maybe 45 bits, with 9 bits
>>>> exponent and 36 bits of significand.
>> <
>>> If you're worried about performance, use your 45 bit format and store
>>> it in a 64 bit word.
>> <
>> In 1985 one could get a descent 32-bit pipelined RISC architecture in 1cm^2
>> Today this design in < 0.1mm^2 or you can make a GBOoO version < 2mm^2.
>> <
>> And you really need 5mm^2 to get enough pins on the part to feed what you
>> can put inside; 7mm^2 makes even more sense on pins versus perf.
>> <
>> So, why are you catering to ANY bit counts less than 64 ??
>> Intel has version with 512-bit data paths, GPUs generally use 1024-bits in
>> and 1024 bits out per cycle continuously per shader core.
>> <
>> It is no longer 1990, adjust your thinking to the modern realities or our time !
>>>
>>> The IBM 360/44 was an odd machine intended for real-time applications.
>>> It had a hard wired subset of the 360's instruction set, including all
>>> the floating point. There was a knob on the front panel you could turn
>>> to set the number of bytes for double precision operands, with shorter
>>> being faster. They were still stored in 64 bit doublewords, ignoring
>>> the low bytes. I've never seen anything saying whether it was useful
>>> in practice or people just left the knob at the default 56 bits.
>>> --
>>> Regards,
>>> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
>>> Please consider the environment before reading this e-mail. https://jl.ly
>
> Ugh
> |> It is no longer 1990, adjust your thinking to the modern realities or our time
>
> So why do we still design register files of only 64 bit registers?
>
> For an example ISA, assume sixteen 1024 bit registers
> with 32-bit instructions specifying register sub-fields of 1024, 512, 256, 128, 64 and even 32-bits.
> (four bit register selectors and zero to five bit sub-field selectors for a two operand, one result RISC instructions)
> The bigger the subfield, the greater the effective IPC!
> Load and store instructions burdened with alignment, mask setup and other duties.
>
> All in all, a very basic RISC with large registers and potential for good performance,
> to the extent that the problem software can make effective use of the large registers,
> natural alignment of data and wide ALUs.
>
This is more or less a description of the thinking behind Larrabee, with
the basic unit of computation being one cache line/512 bits.

History showed us quite clearly that it was missing somewhere in the 1.5
to 3 X range of performance compared to the same transistor budget used
on a dedicated GPU core.

For TPC, which is what Intel have been trying to move LRB towards since
then (and calling it AVX-512) it is more believable, but here it suffers
from exploding instruction set size. Mill with register (i.e. belt slot)
metadata allowing a single instruction to work across scalar/vector and
byte/short/word/dword/qword item sizes avoids this particular problem,
as does Mitch's MY 66000 VMM.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Sunday, September 17, 2023 at 11:58:18 AM UTC-6, John Dallman wrote:

> Quadibloc <jsa...@ecn.ab.ca> schrieb:
> > By "intermediate precision" I mean 48-bit or 54-bit floating-point
> > on the computer which is built around a 36-bit word in order to
> > provide 36-bit and 72-bit floats.

> I don't understand why you feel this is valuable. Are there any
> architectures that have been used since about 1970 (when the Atlas
> machines were shut down) that provide it? Is there software suffering
> because it doesn't have it and needs to make do with double precision? No
> architecture can do everything efficiently.

Can today's modern computers perform a 64-bit FP division with only
one clock cycle of latency? I don't think so; I don't think that they can even
do 64-bit FP multiplication that quickly.

That's why I think it is valuable to have other floating-point formats
smaller than 64 bits, but still large enough to be useful for scientific
computing, which 32 bits _isn't_, available.

Of course, though, this is less important now than in the days of the
IBM System/360 model 44. That machine's implementation of
floating-point arithmetic was such that the time of floating-point
operations was proportional to the length of the mantissa; with
today's advanced ALU designs, it's closer to being proportional to
the *logarithm* of that length, so the gains from a shorter FP format
aren't as dramatic.

John Savard

On Sunday, September 17, 2023 at 2:30:19 PM UTC-6, John Levine wrote:

> The IBM 360/44 was an odd machine intended for real-time applications.
> It had a hard wired subset of the 360's instruction set, including all
> the floating point. There was a knob on the front panel you could turn
> to set the number of bytes for double precision operands, with shorter
> being faster. They were still stored in 64 bit doublewords, ignoring
> the low bytes. I've never seen anything saying whether it was useful
> in practice or people just left the knob at the default 56 bits.

Given that the 360/44 wasn't a 360/91 or one of its cousins, the time
required for floating-point operations was proportional to mantissa length
rather than the logarithm of mantissa length. Thus, there was at least the
possibility that it would have indeed been useful under some circumstances
on occasion.

John Savard

On Monday, September 18, 2023 at 5:41:01 PM UTC+3, Quadibloc wrote:
> On Sunday, September 17, 2023 at 11:58:18 AM UTC-6, John Dallman wrote:
>
> > Quadibloc <jsa...@ecn.ab.ca> schrieb:
> > > By "intermediate precision" I mean 48-bit or 54-bit floating-point
> > > on the computer which is built around a 36-bit word in order to
> > > provide 36-bit and 72-bit floats.
>
> > I don't understand why you feel this is valuable. Are there any
> > architectures that have been used since about 1970 (when the Atlas
> > machines were shut down) that provide it? Is there software suffering
> > because it doesn't have it and needs to make do with double precision? No
> > architecture can do everything efficiently.
> Can today's modern computers perform a 64-bit FP division with only
> one clock cycle of latency? I don't think so; I don't think that they can even
> do 64-bit FP multiplication that quickly.
>
> That's why I think it is valuable to have other floating-point formats
> smaller than 64 bits, but still large enough to be useful for scientific
> computing, which 32 bits _isn't_, available.

Your logic is based on assumption that intermediate precision math can be
significantly faster, latency wise, than full IEEE binary64 math. But that's
not true. At least not according to my definition of the word 'significantly'.
If IEEE binary64 fmul latency = 4 then it's unlikely that you can shrink it
to 3 for your mid-precision format. 2 is completely out of question.
And for just about everything at full application level even the difference
between 4 and 2 is not significant, much less so difference between 4 and 3..
IEEE binary32 is valuable not due to lower latency, but due to higher throughput
on the SIMD side.

>
> Of course, though, this is less important now than in the days of the
> IBM System/360 model 44. That machine's implementation of
> floating-point arithmetic was such that the time of floating-point
> operations was proportional to the length of the mantissa; with
> today's advanced ALU designs, it's closer to being proportional to
> the *logarithm* of that length, so the gains from a shorter FP format
> aren't as dramatic.
>
> John Savard

Exactly.
So, you appear to know that your claimed motivation is wrong.
Now tell us what is your true motivation?

On Monday, September 18, 2023 at 9:41:01 AM UTC-5, Quadibloc wrote:
> On Sunday, September 17, 2023 at 11:58:18 AM UTC-6, John Dallman wrote:
>
> > Quadibloc <jsa...@ecn.ab.ca> schrieb:
> > > By "intermediate precision" I mean 48-bit or 54-bit floating-point
> > > on the computer which is built around a 36-bit word in order to
> > > provide 36-bit and 72-bit floats.
>
> > I don't understand why you feel this is valuable. Are there any
> > architectures that have been used since about 1970 (when the Atlas
> > machines were shut down) that provide it? Is there software suffering
> > because it doesn't have it and needs to make do with double precision? No
> > architecture can do everything efficiently.
<
> Can today's modern computers perform a 64-bit FP division with only
> one clock cycle of latency? I don't think so; I don't think that they can even
> do 64-bit FP multiplication that quickly.
<
Reciprocation can be pipelined to about 20 cycles of latency and 1 beat
throughput. It is BIG but doable. The problem is reciprocation followed
by multiplication is 0.5 bits less accurate than Division and IEEE 754 does
not allow this.
>
> That's why I think it is valuable to have other floating-point formats
> smaller than 64 bits, but still large enough to be useful for scientific
> computing, which 32 bits _isn't_, available.
>
> Of course, though, this is less important now than in the days of the
> IBM System/360 model 44. That machine's implementation of
> floating-point arithmetic was such that the time of floating-point
> operations was proportional to the length of the mantissa; with
> today's advanced ALU designs, it's closer to being proportional to
> the *logarithm* of that length, so the gains from a shorter FP format
> aren't as dramatic.
>
> John Savard

On Monday, September 18, 2023 at 11:08:58 AM UTC-5, Michael S wrote:
> On Monday, September 18, 2023 at 5:41:01 PM UTC+3, Quadibloc wrote:
> > On Sunday, September 17, 2023 at 11:58:18 AM UTC-6, John Dallman wrote:
> >
> > > Quadibloc <jsa...@ecn.ab.ca> schrieb:
> > > > By "intermediate precision" I mean 48-bit or 54-bit floating-point
> > > > on the computer which is built around a 36-bit word in order to
> > > > provide 36-bit and 72-bit floats.
> >
> > > I don't understand why you feel this is valuable. Are there any
> > > architectures that have been used since about 1970 (when the Atlas
> > > machines were shut down) that provide it? Is there software suffering
> > > because it doesn't have it and needs to make do with double precision? No
> > > architecture can do everything efficiently.
> > Can today's modern computers perform a 64-bit FP division with only
> > one clock cycle of latency? I don't think so; I don't think that they can even
> > do 64-bit FP multiplication that quickly.
> >
> > That's why I think it is valuable to have other floating-point formats
> > smaller than 64 bits, but still large enough to be useful for scientific
> > computing, which 32 bits _isn't_, available.
<
> Your logic is based on assumption that intermediate precision math can be
> significantly faster, latency wise, than full IEEE binary64 math. But that's
> not true. At least not according to my definition of the word 'significantly'.
> If IEEE binary64 fmul latency = 4 then it's unlikely that you can shrink it
> to 3 for your mid-precision format. 2 is completely out of question.
<
64-bit FMUL is about 60 gates of delay
32-bit FMUL is about 56 gates of delay
64-bit FADD is about 50 gates of delay
32-bit FADD is about 45 gates of delay
<
All intermediate precision is squeezed between these.
<
> And for just about everything at full application level even the difference
> between 4 and 2 is not significant, much less so difference between 4 and 3.
> IEEE binary32 is valuable not due to lower latency, but due to higher throughput
> on the SIMD side.
<
The difference between 2 cycle LDs and 3 cycle LDs is about 10% on
a 1-wide in-order machine, and less on an OoO machine. Some would
call 10% significant, others not.
<
> >
> > Of course, though, this is less important now than in the days of the
> > IBM System/360 model 44. That machine's implementation of
> > floating-point arithmetic was such that the time of floating-point
> > operations was proportional to the length of the mantissa; with
> > today's advanced ALU designs, it's closer to being proportional to
> > the *logarithm* of that length, so the gains from a shorter FP format
> > aren't as dramatic.
<
It is closer to ½×logarithmic and ½×linear.
<
> >
> > John Savard
> Exactly.
> So, you appear to know that your claimed motivation is wrong.
> Now tell us what is your true motivation?

On Monday, September 18, 2023 at 10:08:58 AM UTC-6, Michael S wrote:

> So, you appear to know that your claimed motivation is wrong.
> Now tell us what is your true motivation?

No, my claimed motivation is not wrong, since even shaving one cycle
off of an FP multiply can still be valuable or even imperative, when
the goal is to perform a computation which will take months of compuiter
time.

John Savard

On Monday, September 18, 2023 at 10:59:31 AM UTC-6, MitchAlsup wrote:

> 64-bit FMUL is about 60 gates of delay
> 32-bit FMUL is about 56 gates of delay
> 64-bit FADD is about 50 gates of delay
> 32-bit FADD is about 45 gates of delay
> <
> All intermediate precision is squeezed between these.

Oh. In *that* case, since 12-16 gates per cycle
is reasonable, my "claimed motivation" _is_
wrong.

I knew the gains from shorter precision would be
modest, but I didn't realize they would be _that_
modest.

John Savard

On Monday, September 18, 2023 at 10:53:31 AM UTC-6, MitchAlsup wrote:

> Reciprocation can be pipelined to about 20 cycles of latency and 1 beat
> throughput. It is BIG but doable. The problem is reciprocation followed
> by multiplication is 0.5 bits less accurate than Division and IEEE 754 does
> not allow this.

I am willing to give up on being fully compliant with IEEE 754. Presumably
as a user-selectable option, though, so that compliance is given up only when
maximum speed is required.

John Savard

Quadibloc wrote:
> On Sunday, September 17, 2023 at 11:58:18 AM UTC-6, John Dallman wrote:
>
>> Quadibloc <jsa...@ecn.ab.ca> schrieb:
>>> By "intermediate precision" I mean 48-bit or 54-bit floating-point
>>> on the computer which is built around a 36-bit word in order to
>>> provide 36-bit and 72-bit floats.
>
>> I don't understand why you feel this is valuable. Are there any
>> architectures that have been used since about 1970 (when the Atlas
>> machines were shut down) that provide it? Is there software suffering
>> because it doesn't have it and needs to make do with double precision? No
>> architecture can do everything efficiently.
>
> Can today's modern computers perform a 64-bit FP division with only
> one clock cycle of latency? I don't think so; I don't think that they can even
> do 64-bit FP multiplication that quickly.
>
> That's why I think it is valuable to have other floating-point formats
> smaller than 64 bits, but still large enough to be useful for scientific
> computing, which 32 bits _isn't_, available.

John, you seem to think that the actual multiplication is the critical
path here, while in reality, all the other stuff related to FP, i.e.
unpacking, adjusting exponent/inserting hidden bit, special-casing all
non-normal inputs, normalizing & rounding the result and packing it back
into the external format will take a significant part of the total cycle
budget, almost independent of the precision selected.

Mitch obviously have the exact numbers but my wild guess would be that
float is typically just one cycle faster than double due to a shorter
carry chain.

You have to go all the way down to 8-bit or so in order to make all ops
single-cycle. (i.e. table lookups!)
>
> Of course, though, this is less important now than in the days of the
> IBM System/360 model 44. That machine's implementation of
> floating-point arithmetic was such that the time of floating-point
> operations was proportional to the length of the mantissa; with
> today's advanced ALU designs, it's closer to being proportional to
> the *logarithm* of that length, so the gains from a shorter FP format
> aren't as dramatic.

Exactly right, so please forget about such ideas.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Monday, September 18, 2023 at 1:26:43 PM UTC-5, Terje Mathisen wrote:
> Quadibloc wrote:
> > On Sunday, September 17, 2023 at 11:58:18 AM UTC-6, John Dallman wrote:
> >
> >> Quadibloc <jsa...@ecn.ab.ca> schrieb:
> >>> By "intermediate precision" I mean 48-bit or 54-bit floating-point
> >>> on the computer which is built around a 36-bit word in order to
> >>> provide 36-bit and 72-bit floats.
> >
> >> I don't understand why you feel this is valuable. Are there any
> >> architectures that have been used since about 1970 (when the Atlas
> >> machines were shut down) that provide it? Is there software suffering
> >> because it doesn't have it and needs to make do with double precision? No
> >> architecture can do everything efficiently.
> >
> > Can today's modern computers perform a 64-bit FP division with only
> > one clock cycle of latency? I don't think so; I don't think that they can even
> > do 64-bit FP multiplication that quickly.
> >
> > That's why I think it is valuable to have other floating-point formats
> > smaller than 64 bits, but still large enough to be useful for scientific
> > computing, which 32 bits _isn't_, available.
<
> John, you seem to think that the actual multiplication is the critical
> path here, while in reality, all the other stuff related to FP, i.e.
> unpacking, adjusting exponent/inserting hidden bit, special-casing all
> non-normal inputs, normalizing & rounding the result and packing it back
> into the external format will take a significant part of the total cycle
> budget, almost independent of the precision selected.
<
53×53 multiplier tree is::
3 gates for Boothe Recoding
10 gates of multiply
14 gates of 2:1 carry propagate adder*
<
(*) the actual adder is 168-bits followed by a 52-bit incrementor with the
property that no carry propagation manipulates more than 112-bits of
result.
<
Normalization::
5 gates to unary select
5 gates of output select in parallel with 4 gates of unary-to-binary encode
2 gates of 11-bit plus 7-bit addition (left in carry save format)
<
Rounding::
2-gates sticky resolve
5-gates [4-bit]×[3-bit] RM select ROM gives {-1, +1, 0} rounding correction
11-gates of rounding plus exponent finalization
<
And 3 gates for various multiplexing along the way.
<
>
> Mitch obviously have the exact numbers but my wild guess would be that
> float is typically just one cycle faster than double due to a shorter
> carry chain.
<
Shaving ½ the length off the carry chain saves (theoretically) 1 gate of
delay (its logarithmic) but in practice it is more like 2 gates due to fan
out.
>
> You have to go all the way down to 8-bit or so in order to make all ops
> single-cycle. (i.e. table lookups!)
<
8× multiply is still not 1 cycle:: at least in a machine you are cycling at
8-bit adder cycle time.
<
> >
> > Of course, though, this is less important now than in the days of the
> > IBM System/360 model 44. That machine's implementation of
> > floating-point arithmetic was such that the time of floating-point
> > operations was proportional to the length of the mantissa; with
> > today's advanced ALU designs, it's closer to being proportional to
> > the *logarithm* of that length, so the gains from a shorter FP format
> > aren't as dramatic.
> Exactly right, so please forget about such ideas.
> Terje
>
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

What kind of precision is needed for space-time co-ordinates? I tried looking this
up and get the impression that 64-bit floats may not be enough, but 128-bit floats
are overkill. The reference was a space game based in a galaxy.