On Sunday, May 28, 2023 at 1:19:33 PM UTC-5, luke.l...@gmail.com wrote:
> On Sunday, May 28, 2023 at 3:35:20 PM UTC+1, Thomas Koenig wrote:
> > MitchAlsup <Mitch...@aol.com> schrieb:
> > > Probably, but not much. And you can avoid numeric problems along
> > > the way. For example, say we have an integer with significance bigger
> > > than 1<<52. When converted to FP64 it will get rounded, but when
> > > auto-converted with tagged-registers it does NOT have to be rounded--
> > > it can be used directly with more significance than fits in FP64 !!
<
> > While true, this would go against the rules of many, if not all
> > programming langues. These prescribe conversion of integer to
> > floating point before doing a calculation with a floating point.
<
> also stops you from being able to service an Interrupt during
> the time that the instruction is issued until there is no longer
> a time it could be used. as that could be tens of millions of
> instructions later, you are hosed.
>
> * reg1: 9999<<52 (int)
> * instruction issued reg2 = BIGINT_to_FP64(reg1)
> * instruction(s) issued: reg3 = reg2 * 2.5
<
Any normal machine could take an interrupt here.
<
> * ...
> * ...
> * millions more instructions none overwritign reg2
> * another use of reg2: reg4 = reg2 + 0.0000001
>
> if reg2 is *NOT* exactly the same accuracy as what
> went into reg3 and reg4, where are the extraneous bits
> stored during the millions of instructions executed?
<
And that is because it is not a CVT followed by a MUL,
it is a CVT-MUL as 1 instruction.
>
> the only possibility would be an overwrite macro-op
> fusion:
>
> reg2 = BIGINT_to_FP64(reg1)
> reg2 = reg2 * 2.5
<
Just have a MUL instruction that looks at the tags and
sees 1 operand is (long) while the other is (double)
and perform CVT (double)Rd,(long)Rs followed by
MUL (double)Rd,(double)Rs1,(double)2.5
<
Op fusion buying performance is a symptom of 2 things
a) the ISA is not sufficiently expressive
b) you ran out of encoding bits
Although may ISA designers suffering from (a) blame it on (b)
because it is so easy to hide the trail of how your ISA got so
screwed up......
>
> and then it becomes vital to not allow interrupts
> between those two instructions, you also just made
> a mess of Multi-Issue Decode (because that's now
> a double-normal-length *ACTUAL* instruction and
> you just unintentionally introduced Variable-Length
> Encoding by the back door), and generally gotten
> into ISA hell from that point onward.
>
> sounds as Mitch suggests much better to do what
> everyone else does.
<
This truly has something to do with age--but I forgive you.
>
> l.

On Sunday, May 28, 2023 at 2:25:33 PM UTC-5, BGB wrote:
> On 5/28/2023 9:33 AM, Thomas Koenig wrote:
> > MitchAlsup <Mitch...@aol.com> schrieb:
> >
> >> Probably, but not much. And you can avoid numeric problems along
> >> the way. For example, say we have an integer with significance bigger
> >> than 1<<52. When converted to FP64 it will get rounded, but when
> >> auto-converted with tagged-registers it does NOT have to be rounded--
> >> it can be used directly with more significance than fits in FP64 !!
> >
> > While true, this would go against the rules of many, if not all
> > programming langues. These prescribe conversion of integer to
> > floating point before doing a calculation with a floating point.
> Agreed.
>
>
> Also it seems like it could lead to problems.
>
> What if an interrupt happens, does the precision of the calculation
> depend on the presence or absence of an interrupt?... Or, does the ISR
> now need to save and restore, say, 96-bit registers? ...
>
If the program can detect the size of the 96-bit containers IN ANY WAY,
they must be preserved across an interrupt, trap, or syscall. It is the
only SANE thing to do.
>
> For many problems, it seems more like repeatability matters more than
> absolute precision. Say, that the same calculation with the same inputs
> always produces the same result, even if this answer is "wrong" in a
> more strict interpretation.
>
> Say, with the amount of "implicit" architectural state being kept to a
> minimum.
>
>
>
> Ironically, in my case this led to things like emulator fun of needing
> to fake my CPU's arguably "bad" handling of floating-point in some
> cases, rather than using the "better" native FPU operations, since this
> led to behavioral divergence in some cases.
<
Kind of like an eXcel program that runs error-free on a machine with x87
that is replete with rounding errors on a machine without--even those
that purport to emulate x98 (eXcel binary from before the SSE2 time
period, running on a 10-year old Opteron versus a last year Core 7)
>
> Kinda similar ends up applying to things like RGB555 or block-texture
> decoding, where the "bad" definitions often end up being preferable to
> the "better" definitions for one reason or another.
>
> ...

Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>
>> Probably, but not much. And you can avoid numeric problems along
>> the way. For example, say we have an integer with significance bigger
>> than 1<<52. When converted to FP64 it will get rounded, but when
>> auto-converted with tagged-registers it does NOT have to be rounded--
>> it can be used directly with more significance than fits in FP64 !!
>
> While true, this would go against the rules of many, if not all
> programming langues. These prescribe conversion of integer to
> floating point before doing a calculation with a floating point.
>
Yes, but it would allow asm code to implement trig functions (and
others) with more precision/better performance than a pure FP version.

Terje

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

On Sunday, May 28, 2023 at 3:06:27 PM UTC-5, Terje Mathisen wrote:
> Thomas Koenig wrote:
> > MitchAlsup <Mitch...@aol.com> schrieb:
> >
> >> Probably, but not much. And you can avoid numeric problems along
> >> the way. For example, say we have an integer with significance bigger
> >> than 1<<52. When converted to FP64 it will get rounded, but when
> >> auto-converted with tagged-registers it does NOT have to be rounded--
> >> it can be used directly with more significance than fits in FP64 !!
> >
> > While true, this would go against the rules of many, if not all
> > programming langues. These prescribe conversion of integer to
> > floating point before doing a calculation with a floating point.
> >
> Yes, but it would allow asm code to implement trig functions (and
> others) with more precision/better performance than a pure FP version.
<
At that point why not go all the way and make the elementary functions
into instructions, so you can pull off even more tricks--like I do with argue-
ment reduction in SIN() and COS() and TAN() in 2 passes through the
multiplier instead of 4 using Payne and Hanek synthetization.
<
That is instead of a trick here and a trick there, just give them high
performance (few clocks) and high precision (better than 1 ULP)!!
<
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On 5/28/2023 2:55 PM, MitchAlsup wrote:
> On Sunday, May 28, 2023 at 2:25:33 PM UTC-5, BGB wrote:
>> On 5/28/2023 9:33 AM, Thomas Koenig wrote:
>>> MitchAlsup <Mitch...@aol.com> schrieb:
>>>
>>>> Probably, but not much. And you can avoid numeric problems along
>>>> the way. For example, say we have an integer with significance bigger
>>>> than 1<<52. When converted to FP64 it will get rounded, but when
>>>> auto-converted with tagged-registers it does NOT have to be rounded--
>>>> it can be used directly with more significance than fits in FP64 !!
>>>
>>> While true, this would go against the rules of many, if not all
>>> programming langues. These prescribe conversion of integer to
>>> floating point before doing a calculation with a floating point.
>> Agreed.
>>
>>
>> Also it seems like it could lead to problems.
>>
>> What if an interrupt happens, does the precision of the calculation
>> depend on the presence or absence of an interrupt?... Or, does the ISR
>> now need to save and restore, say, 96-bit registers? ...
>>
> If the program can detect the size of the 96-bit containers IN ANY WAY,
> they must be preserved across an interrupt, trap, or syscall. It is the
> only SANE thing to do.

Agreed.

>>
>> For many problems, it seems more like repeatability matters more than
>> absolute precision. Say, that the same calculation with the same inputs
>> always produces the same result, even if this answer is "wrong" in a
>> more strict interpretation.
>>
>> Say, with the amount of "implicit" architectural state being kept to a
>> minimum.
>>
>>
>>
>> Ironically, in my case this led to things like emulator fun of needing
>> to fake my CPU's arguably "bad" handling of floating-point in some
>> cases, rather than using the "better" native FPU operations, since this
>> led to behavioral divergence in some cases.
> <
> Kind of like an eXcel program that runs error-free on a machine with x87
> that is replete with rounding errors on a machine without--even those
> that purport to emulate x98 (eXcel binary from before the SSE2 time
> period, running on a 10-year old Opteron versus a last year Core 7)

Yeah.

In my case, it was stuff like:
Native FPU:
May give differently rounded results;
May alter the values when the bit pattern encodes a NaN;
Handle Int<->FP conversion differently for out-of-range values.
Handle FP conversion differently for out-of-range values;
...
BJX2 FPU:
Discards low bits from intermediate results
Sometimes effects the final rounding.
Conversion ops preserve the values of NaNs to what extent possible.
Conversion ops identity-map zero-range values between formats;
Small values clamp to 0;
Large values clamp to Inf;
Sub-normal values are assumed not to exist;
The zero-range hack is mostly so Fp32->Fp64->Fp32 is exact;
SSE clamps Fp->Int32 to 0x80000000 if out of range,
on BJX2 is modulo by default;
FP-SIMD ops and value conversions are truncate;
...

But, on the merit (or drawbacks) of using hard-wired truncate for SIMD
ops, it is not ideal if, say, the FPGA version uses truncate but the
emulator uses round-nearest-even, ...

I still make no claim of strict IEEE-754 conformance.

>>
>> Kinda similar ends up applying to things like RGB555 or block-texture
>> decoding, where the "bad" definitions often end up being preferable to
>> the "better" definitions for one reason or another.
>>
>> ...

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:
>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>
>>> Probably, but not much. And you can avoid numeric problems along
>>> the way. For example, say we have an integer with significance bigger
>>> than 1<<52. When converted to FP64 it will get rounded, but when
>>> auto-converted with tagged-registers it does NOT have to be rounded--
>>> it can be used directly with more significance than fits in FP64 !!
>>
>> While true, this would go against the rules of many, if not all
>> programming langues. These prescribe conversion of integer to
>> floating point before doing a calculation with a floating point.
>>
> Yes, but it would allow asm code to implement trig functions (and
> others) with more precision/better performance than a pure FP version.

Or we could re-introduce 80-bit floating point registers with a 64-bit
mantissa and have 64- and 80-bit instructions for them (both load/store
and calculation). You need 64-bit integer arithmetic anyway.

But I don't see that on the horizon any time soon - presumably, 128-bit
IEEE will be used instead (Like POWER does).

MitchAlsup wrote:
> On Sunday, May 28, 2023 at 3:06:27 PM UTC-5, Terje Mathisen wrote:
>> Thomas Koenig wrote:
>>> MitchAlsup <Mitch...@aol.com> schrieb:
>>>
>>>> Probably, but not much. And you can avoid numeric problems along
>>>> the way. For example, say we have an integer with significance bigger
>>>> than 1<<52. When converted to FP64 it will get rounded, but when
>>>> auto-converted with tagged-registers it does NOT have to be rounded--
>>>> it can be used directly with more significance than fits in FP64 !!
>>>
>>> While true, this would go against the rules of many, if not all
>>> programming langues. These prescribe conversion of integer to
>>> floating point before doing a calculation with a floating point.
>>>
>> Yes, but it would allow asm code to implement trig functions (and
>> others) with more precision/better performance than a pure FP version.
> <
> At that point why not go all the way and make the elementary functions
> into instructions, so you can pull off even more tricks--like I do with argue-
> ment reduction in SIN() and COS() and TAN() in 2 passes through the
> multiplier instead of 4 using Payne and Hanek synthetization.
> <
> That is instead of a trick here and a trick there, just give them high
> performance (few clocks) and high precision (better than 1 ULP)!!

Oh, I absolutely agree that your approach is much better for anything
you know up front that you will need!

I'm willing to put it even stronger: Your approach should be the only
one worth considering for new designs.

OTOH, having those extended primitives would make it easier to implement
arbitrary, but unsupported in HW, functions.

Terje

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

Thomas Koenig wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>> Thomas Koenig wrote:
>>> MitchAlsup <MitchAlsup@aol.com> schrieb:
>>>
>>>> Probably, but not much. And you can avoid numeric problems along
>>>> the way. For example, say we have an integer with significance bigger
>>>> than 1<<52. When converted to FP64 it will get rounded, but when
>>>> auto-converted with tagged-registers it does NOT have to be rounded--
>>>> it can be used directly with more significance than fits in FP64 !!
>>>
>>> While true, this would go against the rules of many, if not all
>>> programming langues. These prescribe conversion of integer to
>>> floating point before doing a calculation with a floating point.
>>>
>> Yes, but it would allow asm code to implement trig functions (and
>> others) with more precision/better performance than a pure FP version.
>
> Or we could re-introduce 80-bit floating point registers with a 64-bit
> mantissa and have 64- and 80-bit instructions for them (both load/store
> and calculation). You need 64-bit integer arithmetic anyway.
>
> But I don't see that on the horizon any time soon - presumably, 128-bit
> IEEE will be used instead (Like POWER does).
>
Absolutely correct, fp128 is the only sane way forward.

Even there you could take advantage of a few mixed FP/Int primitives for
core 128-bit functions.

Terje

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

On Monday, May 29, 2023 at 11:36:13 AM UTC+1, Terje Mathisen wrote:

> > But I don't see that on the horizon any time soon - presumably, 128-bit
> > IEEE will be used instead (Like POWER does).
> >
> Absolutely correct, fp128 is the only sane way forward.

unfortunately it comes with the implication that 128-bit
registers are now a first-order part of the ISA, or that
pairs of 64-bit registers are required. at which point
you have to think through how to handle up to 6-in
2-out register hazard management just for FMAC.
(there are solutions, none of them very pretty).

it puts any such design firmly out of reach of "desktop
notebook smartbook tablet chromebook Industrial
IOT Edge computing" and into "Server HPC Supercomputer
GPU" territory.

l.

"luke.l...@gmail.com" <luke.leighton@gmail.com> writes:
>On Monday, May 29, 2023 at 11:36:13=E2=80=AFAM UTC+1, Terje Mathisen wrote:
>
>> > But I don't see that on the horizon any time soon - presumably, 128-bit=
>=20
>> > IEEE will be used instead (Like POWER does).=20
>> >
>> Absolutely correct, fp128 is the only sane way forward.=20
>
>unfortunately it comes with the implication that 128-bit
>registers are now a first-order part of the ISA, or that
>pairs of 64-bit registers are required. at which point
>you have to think through how to handle up to 6-in
>2-out register hazard management just for FMAC.
>(there are solutions, none of them very pretty).
>
>it puts any such design firmly out of reach of "desktop
>notebook smartbook tablet chromebook Industrial
>IOT Edge computing" and into "Server HPC Supercomputer
>GPU" territory.

Does it? Pretty much every ARMv8 CPU has 128-bit registers
today for the Neon/SIMD unit, and the floating point unit uses
the same register file (supporting 8-bit, 16-bit, 32-bit and
64-bit floating point).

On Monday, May 29, 2023 at 2:46:29 PM UTC+1, Scott Lurndal wrote:

> Does it? Pretty much every ARMv8 CPU has 128-bit registers
> today for the Neon/SIMD unit,

with associated SIMD Hell Baggage, which is a whole new
topic, discussed many times even in the relatively short
years i've been on comp.arch
https://www.sigarch.org/simd-instructions-considered-harmful/

l.

luke.l...@gmail.com <luke.leighton@gmail.com> schrieb:
> On Monday, May 29, 2023 at 11:36:13 AM UTC+1, Terje Mathisen wrote:
>
>> > But I don't see that on the horizon any time soon - presumably, 128-bit
>> > IEEE will be used instead (Like POWER does).
>> >
>> Absolutely correct, fp128 is the only sane way forward.
>
> unfortunately it comes with the implication that 128-bit
> registers are now a first-order part of the ISA, or that
> pairs of 64-bit registers are required. at which point
> you have to think through how to handle up to 6-in
> 2-out register hazard management just for FMAC.
> (there are solutions, none of them very pretty).

If you need 8 registers just for an FMAC, chances are that 32
registers will become problematic, you will probably want 64
registers then.

And the arithmetic will presumably be microcoded^H^H^H^H^H^H^H^H^H^H
sequenced (I do not expect a 113-bit wide full multiplier) and
will take quite a few cycles anyway, even though it will still
likely be much faster than software.

> it puts any such design firmly out of reach of "desktop
> notebook smartbook tablet chromebook Industrial
> IOT Edge computing" and into "Server HPC Supercomputer
> GPU" territory.

I somehow doubt that, given the huge number of gates that a modern
CPU throws at runnding Windows and Teams...

luke.l...@gmail.com wrote:
> On Monday, May 29, 2023 at 11:36:13 AM UTC+1, Terje Mathisen wrote:
>
>>> But I don't see that on the horizon any time soon - presumably, 128-bit
>>> IEEE will be used instead (Like POWER does).
>>>
>> Absolutely correct, fp128 is the only sane way forward.
>
> unfortunately it comes with the implication that 128-bit
> registers are now a first-order part of the ISA, or that
> pairs of 64-bit registers are required. at which point
> you have to think through how to handle up to 6-in
> 2-out register hazard management just for FMAC.
> (there are solutions, none of them very pretty).

Except we already have SIMD vector regs of 128/256/512 bits and they
already support FMAC type operations, the only difference being that the
indivdual parts are 32 or 64 bits.

> it puts any such design firmly out of reach of "desktop
> notebook smartbook tablet chromebook Industrial
> IOT Edge computing" and into "Server HPC Supercomputer
> GPU" territory.
>
> l.
>
See above...

Terje

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

On 5/29/2023 5:50 AM, luke.l...@gmail.com wrote:
> On Monday, May 29, 2023 at 11:36:13 AM UTC+1, Terje Mathisen wrote:
>
>>> But I don't see that on the horizon any time soon - presumably, 128-bit
>>> IEEE will be used instead (Like POWER does).
>>>
>> Absolutely correct, fp128 is the only sane way forward.
>
> unfortunately it comes with the implication that 128-bit
> registers are now a first-order part of the ISA, or that
> pairs of 64-bit registers are required. at which point
> you have to think through how to handle up to 6-in
> 2-out register hazard management just for FMAC.
> (there are solutions, none of them very pretty).
>

FWIW: 6-in / 2-out is how 128-bit FP-SIMD works in the BJX2 core...

There was at one point a feature to allow truncated Binary128 as an
intermediary, basically:
S.E15.F80.Z32

Where the Z bits are "ignore on input, zeroed on output".

Where, the 80-bit mantissa was mostly because, the cost increase in
going from 80 to 112 bits is, quite steep...

But, even this was a bit too expensive, so I ended up backing off (to
using only Binary64 in hardware, and handling Binary128 in software).

Dropping to 64-bit mantissa would make this part a lot cheaper, but is
"kinda lame" if it has barely any more precision than normal Binary64.

Could in theory handle full Binary128 ops (including FDIV) in hardware
using a modified Shift-Add unit for FMUL (I had already used Shift-Add
for Binary64 FDIV), but this would likely be barely much faster than a
plain software implementation.

The above is more of a "we need it to check something off a checklist"
as opposed to something people would actually use (say, if one has a 120
cycle FMUL and 240 cycle FDIV, this is not exactly all that usable in
terms of performance).

But, still interesting if the "actual CPU" people can make this work.

> it puts any such design firmly out of reach of "desktop
> notebook smartbook tablet chromebook Industrial
> IOT Edge computing" and into "Server HPC Supercomputer
> GPU" territory.
>

Full Binary128: Quite possibly.

6-in / 2-out register ports for an operation:
Probably fine, most non microcontroller CPUs probably already have
enough register ports...

> l.

On 5/29/2023 10:10 AM, Thomas Koenig wrote:
> luke.l...@gmail.com <luke.leighton@gmail.com> schrieb:
>> On Monday, May 29, 2023 at 11:36:13 AM UTC+1, Terje Mathisen wrote:
>>
>>>> But I don't see that on the horizon any time soon - presumably, 128-bit
>>>> IEEE will be used instead (Like POWER does).
>>>>
>>> Absolutely correct, fp128 is the only sane way forward.
>>
>> unfortunately it comes with the implication that 128-bit
>> registers are now a first-order part of the ISA, or that
>> pairs of 64-bit registers are required. at which point
>> you have to think through how to handle up to 6-in
>> 2-out register hazard management just for FMAC.
>> (there are solutions, none of them very pretty).
>
> If you need 8 registers just for an FMAC, chances are that 32
> registers will become problematic, you will probably want 64
> registers then.
>

Cough, errm, can you guess why I ended up going for 64 GPRs with me
doing 128-bit SIMD ops in GPRs in my case?...

Yeah, this sort of thing was sort of a factor here...

It was effectively "all but required" for the ABI built around 128-bit
pointers as well.

> And the arithmetic will presumably be microcoded^H^H^H^H^H^H^H^H^H^H
> sequenced (I do not expect a 113-bit wide full multiplier) and
> will take quite a few cycles anyway, even though it will still
> likely be much faster than software.
>

It is debatable...

If one uses a naive Shift-Add design, it is possible in many cases for
the software implementation to actually be faster (say, if one has a
32-bit multiplier with a 3-cycle latency).

With division being the main exception case (both integer division in
software, and Newton-Raphson, are going to be slow).

Could consider it if, for whatever reason, a sudden need came up for
support for 128-bit integer multiply and divide, since Binary128 support
could just sort of be "thrown in" to the unit.

As-is, things like 128-bit integer ALU ops can help somewhat with
Binary128 emulation (without being too unreasonably expensive for the
hardware).

>> it puts any such design firmly out of reach of "desktop
>> notebook smartbook tablet chromebook Industrial
>> IOT Edge computing" and into "Server HPC Supercomputer
>> GPU" territory.
>
> I somehow doubt that, given the huge number of gates that a modern
> CPU throws at runnding Windows and Teams...

Probably...

If I just wanted it as a slow "checklist feature", it is already pretty
doable on the larger end of the Artix-7 class FPGAs, so an ASIC
shouldn't have too much issue...

On Monday, May 29, 2023 at 5:50:56 AM UTC-5, luke.l...@gmail.com wrote:
> On Monday, May 29, 2023 at 11:36:13 AM UTC+1, Terje Mathisen wrote:
>
> > > But I don't see that on the horizon any time soon - presumably, 128-bit
> > > IEEE will be used instead (Like POWER does).
> > >
> > Absolutely correct, fp128 is the only sane way forward.
<
128-bit might be the only sane way forward,
BUT pairing and sharing of registers is not.
<
> unfortunately it comes with the implication that 128-bit
> registers are now a first-order part of the ISA, or that
> pairs of 64-bit registers are required. at which point
> you have to think through how to handle up to 6-in
> 2-out register hazard management just for FMAC.
> (there are solutions, none of them very pretty).
<
Back when engineers only got 16-bit ALUs and had to build
systems that smelled like they supported 64-bit FP they used
a term that has very much fallen out of favor today:: µCode.
>
> it puts any such design firmly out of reach of "desktop
> notebook smartbook tablet chromebook Industrial
> IOT Edge computing" and into "Server HPC Supercomputer
> GPU" territory.
>
> l.

On Monday, May 29, 2023 at 9:14:15 AM UTC-5, luke.l...@gmail.com wrote:
> On Monday, May 29, 2023 at 2:46:29 PM UTC+1, Scott Lurndal wrote:
>
> > Does it? Pretty much every ARMv8 CPU has 128-bit registers
> > today for the Neon/SIMD unit,
> with associated SIMD Hell Baggage, which is a whole new
> topic, discussed many times even in the relatively short
> years i've been on comp.arch
> https://www.sigarch.org/simd-instructions-considered-harmful/
>
Not only is SIMD harmful to your ISA it is harmful to your though processes..
<
On the other hand:: If you want to call an architecture with 1300[0] instructions
RISC; all you have done is change the first letter of RISC into Rediculous.
<
> l.

On Monday, May 29, 2023 at 12:01:41 PM UTC-5, Terje Mathisen wrote:
> luke.l...@gmail.com wrote:
> > On Monday, May 29, 2023 at 11:36:13 AM UTC+1, Terje Mathisen wrote:
> >
> >>> But I don't see that on the horizon any time soon - presumably, 128-bit
> >>> IEEE will be used instead (Like POWER does).
> >>>
> >> Absolutely correct, fp128 is the only sane way forward.
> >
> > unfortunately it comes with the implication that 128-bit
> > registers are now a first-order part of the ISA, or that
> > pairs of 64-bit registers are required. at which point
> > you have to think through how to handle up to 6-in
> > 2-out register hazard management just for FMAC.
> > (there are solutions, none of them very pretty).
<
> Except we already have SIMD vector regs of 128/256/512 bits and they
> already support FMAC type operations, the only difference being that the
> indivdual parts are 32 or 64 bits.
<
Are you actually arguing that 512-bit registers are the right thing to do ?
<
> > it puts any such design firmly out of reach of "desktop
> > notebook smartbook tablet chromebook Industrial
> > IOT Edge computing" and into "Server HPC Supercomputer
> > GPU" territory.
> >
> > l.
> >
> See above...
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

MitchAlsup wrote:
> On Monday, May 29, 2023 at 12:01:41 PM UTC-5, Terje Mathisen wrote:
>> luke.l...@gmail.com wrote:
>>> On Monday, May 29, 2023 at 11:36:13 AM UTC+1, Terje Mathisen wrote:
>>>
>>>>> But I don't see that on the horizon any time soon - presumably, 128-bit
>>>>> IEEE will be used instead (Like POWER does).
>>>>>
>>>> Absolutely correct, fp128 is the only sane way forward.
>>>
>>> unfortunately it comes with the implication that 128-bit
>>> registers are now a first-order part of the ISA, or that
>>> pairs of 64-bit registers are required. at which point
>>> you have to think through how to handle up to 6-in
>>> 2-out register hazard management just for FMAC.
>>> (there are solutions, none of them very pretty).
> <
>> Except we already have SIMD vector regs of 128/256/512 bits and they
>> already support FMAC type operations, the only difference being that the
>> indivdual parts are 32 or 64 bits.
> <
> Are you actually arguing that 512-bit registers are the right thing to do ?

Not really, but OTOH, I do believe that cache-line size (i.e. typically
64 bytes/512 bits) is the natural working set/chunk size for the CPU
hardware. If you can do that with clever encoding tricks like your VMM,
then more power to you.

Demanding separate opcodes for every possible size SIMD is NOT the
proper way to do it. Also ref Mill and our recent register tag bits thread.

Terje

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

MitchAlsup <MitchAlsup@aol.com> writes:
>On Monday, May 29, 2023 at 12:01:41=E2=80=AFPM UTC-5, Terje Mathisen wrote:
>> luke.l...@gmail.com wrote:=20
>> > On Monday, May 29, 2023 at 11:36:13=E2=80=AFAM UTC+1, Terje Mathisen wr=
>ote:=20
>> >=20
>> >>> But I don't see that on the horizon any time soon - presumably, 128-b=
>it=20
>> >>> IEEE will be used instead (Like POWER does).=20
>> >>>=20
>> >> Absolutely correct, fp128 is the only sane way forward.=20
>> >=20
>> > unfortunately it comes with the implication that 128-bit=20
>> > registers are now a first-order part of the ISA, or that=20
>> > pairs of 64-bit registers are required. at which point=20
>> > you have to think through how to handle up to 6-in=20
>> > 2-out register hazard management just for FMAC.=20
>> > (there are solutions, none of them very pretty).
><
>> Except we already have SIMD vector regs of 128/256/512 bits and they=20
>> already support FMAC type operations, the only difference being that the=
>=20
>> indivdual parts are 32 or 64 bits.
><
>Are you actually arguing that 512-bit registers are the right thing to do ?

ARM's scalable vector extension allows implementations to choose
any power of two between 128 and 2048 bits. Current extant implementations
only support 128 bits so far as I am aware.

They are certainly useful for some set of workloads; albeit
specialized.

On Monday, May 29, 2023 at 3:30:59 PM UTC-5, Terje Mathisen wrote:
> MitchAlsup wrote:
> > On Monday, May 29, 2023 at 12:01:41 PM UTC-5, Terje Mathisen wrote:
> >> luke.l...@gmail.com wrote:
> >>> On Monday, May 29, 2023 at 11:36:13 AM UTC+1, Terje Mathisen wrote:
> >>>
> >>>>> But I don't see that on the horizon any time soon - presumably, 128-bit
> >>>>> IEEE will be used instead (Like POWER does).
> >>>>>
> >>>> Absolutely correct, fp128 is the only sane way forward.
> >>>
> >>> unfortunately it comes with the implication that 128-bit
> >>> registers are now a first-order part of the ISA, or that
> >>> pairs of 64-bit registers are required. at which point
> >>> you have to think through how to handle up to 6-in
> >>> 2-out register hazard management just for FMAC.
> >>> (there are solutions, none of them very pretty).
> > <
> >> Except we already have SIMD vector regs of 128/256/512 bits and they
> >> already support FMAC type operations, the only difference being that the
> >> indivdual parts are 32 or 64 bits.
> > <
> > Are you actually arguing that 512-bit registers are the right thing to do ?
> Not really, but OTOH, I do believe that cache-line size (i.e. typically
> 64 bytes/512 bits) is the natural working set/chunk size for the CPU
> hardware. If you can do that with clever encoding tricks like your VMM,
> then more power to you.
<
Yes, some 1/2^n ; n = { 0, 1, 2 } portion of cache line size is appropriate.
a) caches are built that way regardless.
b) cache width is natural.
c) one can calculation units build as wide as they can feed data.
<
But I found no particular reason these chunks of memory have to be exposed
in a register file, or have "a special OpCode Group" to utilize them. This is
what VVM gets rid of.
>
> Demanding separate opcodes for every possible size SIMD is NOT the
> proper way to do it. Also ref Mill and our recent register tag bits thread.
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On Monday, May 29, 2023 at 9:37:38 PM UTC+1, Scott Lurndal wrote:

> ARM's scalable vector extension allows implementations

the key being *implementations* choose. not ARM, and not programmers.

> to choose any power of two between 128 and 2048 bits.

fixed-length SIMD creates a different kind of hell: binary
incompatibility. https://www.youtube.com/watch?v=HNEm8zmkjBU
the two key instructions that catastrophically fail are element-permute
and element-rotate, both of which *silently* produce different results
for the exact same binary.

> Current extant implementations
> only support 128 bits so far as I am aware.

that is because at conferences the consensus between
ARM Licensees who knew of the binary-incompatibility
decided that the best way to avoid it was to simply never
implement anything other than 128.

l.

On Monday, May 29, 2023 at 9:30:59 PM UTC+1, Terje Mathisen wrote:

> Demanding separate opcodes for every possible size SIMD is NOT the
> proper way to do it.

according to Intel

....with AVX AVX2 AVX-512 and the mad number
of subsets and the mental number of times the registers have
been extended....

it most certainly is the best possible way!
https://en.wikipedia.org/wiki/Advanced_Vector_Extensions

(and what size and combinatorial-explosion of instruction-lengths
are they up to now, with over 10,000 instructions?)

l.

On Monday, May 29, 2023 at 9:11:12 PM UTC+1, MitchAlsup wrote:

> 128-bit might be the only sane way forward,
> BUT pairing and sharing of registers is not.

pairing is caring...

l.

On Monday, May 29, 2023 at 5:43:01 PM UTC-5, luke.l...@gmail.com wrote:
> On Monday, May 29, 2023 at 9:30:59 PM UTC+1, Terje Mathisen wrote:
>
> > Demanding separate opcodes for every possible size SIMD is NOT the
> > proper way to do it.
> according to Intel
>
> ...with AVX AVX2 AVX-512 and the mad number
> of subsets and the mental number of times the registers have
> been extended....
>
> it most certainly is the best possible way!
> https://en.wikipedia.org/wiki/Advanced_Vector_Extensions
>
> (and what size and combinatorial-explosion of instruction-lengths
> are they up to now, with over 10,000 instructions?)
<
My last count was 13,700±.......
<
I get similar functionality with +2 instructions...........
>
> l.