On 5/29/2023 1:11 PM, MitchAlsup wrote:
> 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.

You have mentioned before that compiler guys don't like register
pairing. But I did a (very)little research and thought that the work of
Preston Briggs (expressed in his thesis, several papers and a book) on
the subject of register allocation showed that it wasn't much of a
problem. Is that incorrect?

Of course, it is not optimal, but ISTM that the advantages of not having
to name additional registers in the instructions, and being able to use
load/store multiple (or even double) are pretty compelling.

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

On Monday, May 29, 2023 at 6:29:59 PM UTC-5, Stephen Fuld wrote:
> On 5/29/2023 1:11 PM, MitchAlsup wrote:
> > 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.
<
> You have mentioned before that compiler guys don't like register
> pairing. But I did a (very)little research and thought that the work of
> Preston Briggs (expressed in his thesis, several papers and a book) on
> the subject of register allocation showed that it wasn't much of a
> problem. Is that incorrect?
<
My word from people who actually write compilers is "do not pair or
share" registers with any sort of implication (S 360; R | 1; others R + 1).
<
What happens is that the register allocator goes through several
stages as things get converted from SSA into R[k]. And along the
way implicit pairing can end up attempting to do things like::
<
DADD {R8,R19},{R7,R6},{R1,R13}
<
And at this point, one has to go back and find a free R7 and back
substitute R19 to get {R8,R7}; an find a useable R0 and back-
substitute R13 so we can get {R1,R0}.
<
I trust the compiler guys on this. Is it impossible--obviously, is it
a hassle--obviously, does it lead to slower compiler times--absolutely,
....
>
> Of course, it is not optimal, but ISTM that the advantages of not having
> to name additional registers in the instructions, and being able to use
> load/store multiple (or even double) are pretty compelling.
<
The problem with that thinking is LDM often takes a couple of cycles
to reach optimal data/unit_time throughput whereas LDs do not.
>
>
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

On 5/29/2023 4:57 PM, MitchAlsup wrote:
> On Monday, May 29, 2023 at 6:29:59 PM UTC-5, Stephen Fuld wrote:
>> On 5/29/2023 1:11 PM, MitchAlsup wrote:
>>> 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.
> <
>> You have mentioned before that compiler guys don't like register
>> pairing. But I did a (very)little research and thought that the work of
>> Preston Briggs (expressed in his thesis, several papers and a book) on
>> the subject of register allocation showed that it wasn't much of a
>> problem. Is that incorrect?
> <
> My word from people who actually write compilers is "do not pair or
> share" registers with any sort of implication (S 360; R | 1; others R + 1).
> <
> What happens is that the register allocator goes through several
> stages as things get converted from SSA into R[k]. And along the
> way implicit pairing can end up attempting to do things like::
> <
> DADD {R8,R19},{R7,R6},{R1,R13}
> <
> And at this point, one has to go back and find a free R7 and back
> substitute R19 to get {R8,R7}; an find a useable R0 and back-
> substitute R13 so we can get {R1,R0}.
> <
> I trust the compiler guys on this. Is it impossible--obviously, is it
> a hassle--obviously, does it lead to slower compiler times--absolutely,

OK, thanks

> ...
>>
>> Of course, it is not optimal, but ISTM that the advantages of not having
>> to name additional registers in the instructions, and being able to use
>> load/store multiple (or even double) are pretty compelling.
> <
> The problem with that thinking is LDM often takes a couple of cycles
> to reach optimal data/unit_time throughput whereas LDs do not.

I am sure that is right, but not having optimal throughput (i.e. as good
as you can get) is not necessarily the same as being worse than two load
instructions. Specifically, are you saying that a LDM of two registers
would take longer elapsed time than two single load instructions?

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

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>You have mentioned before that compiler guys don't like register
>pairing. But I did a (very)little research and thought that the work of
>Preston Briggs (expressed in his thesis, several papers and a book) on
>the subject of register allocation showed that it wasn't much of a
>problem. Is that incorrect?

I dimly remember Preston Briggs' paper on paired-register allocation.
It shows that it can be done. However, I am not aware of this having
been integrated into register allocators of widely available compilers
(but maybe this happened without fanfare).

I am also not aware of recent instruction sets getting
pair-register-load and pair-register store instructions. Instead, ARM
A64 added load-pair and store-pair instructions where the instructions
in the pair can be determined independently, which is significantly
easier to utilize in a compiler.

The reason for not having paired registers in A64 may be that a paired
register may be just as hard to deal with in the register renamer as
two individual registers (Mitch Alsup claimed it was easy, but I did
not understand his explanation). If that is the case, the absence of
paired registers as an architectural feature does not say anything
about how hard paired registers are to deal with in a compiler; but if
paired registers are easier than two individual registers in hardware,
the use of individual registers in A64 may be due to compiler objections.

Back to compilers: Basic register allocation is not that hard, but
then you add in requirements coming from the calling convention, and
from this and that (e.g., architectural featured like paired
registers). You can do each requirement individually, but doing them
alltogether makes things very nasty, especially because you also want
the resulting code quality to be good. Already without paired
registers the register allocations I see are not as good as I would
like them to be*. So if the register allocator developers have any
developer capacity left, I'd prefer that they make the existing
allocation better rather than throwing new architectural misfeatures
at them.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On 5/30/2023 10:23 AM, Anton Ertl wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> You have mentioned before that compiler guys don't like register
>> pairing. But I did a (very)little research and thought that the work of
>> Preston Briggs (expressed in his thesis, several papers and a book) on
>> the subject of register allocation showed that it wasn't much of a
>> problem. Is that incorrect?
>
> I dimly remember Preston Briggs' paper on paired-register allocation.
> It shows that it can be done. However, I am not aware of this having
> been integrated into register allocators of widely available compilers
> (but maybe this happened without fanfare).
>
> I am also not aware of recent instruction sets getting
> pair-register-load and pair-register store instructions. Instead, ARM
> A64 added load-pair and store-pair instructions where the instructions
> in the pair can be determined independently, which is significantly
> easier to utilize in a compiler.
>
> The reason for not having paired registers in A64 may be that a paired
> register may be just as hard to deal with in the register renamer as
> two individual registers (Mitch Alsup claimed it was easy, but I did
> not understand his explanation). If that is the case, the absence of
> paired registers as an architectural feature does not say anything
> about how hard paired registers are to deal with in a compiler; but if
> paired registers are easier than two individual registers in hardware,
> the use of individual registers in A64 may be due to compiler objections.
>
> Back to compilers: Basic register allocation is not that hard, but
> then you add in requirements coming from the calling convention, and
> from this and that (e.g., architectural featured like paired
> registers). You can do each requirement individually, but doing them
> alltogether makes things very nasty, especially because you also want
> the resulting code quality to be good. Already without paired
> registers the register allocations I see are not as good as I would
> like them to be*. So if the register allocator developers have any
> developer capacity left, I'd prefer that they make the existing
> allocation better rather than throwing new architectural misfeatures
> at them.

I don't disagree with any of your points. But then how do you propose
handling 128 bit arithmetic (both integer and floating), assuming these
are requirements? ISTM that if you don't use paired registers, then you
have to double the number of register specifiers in each ALU
instruction or do something like Mitch's instruction modifier mechanism
or go to 128 bit registers. None of these seem "optimal" either. :-(

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

On Tuesday, May 30, 2023 at 12:54:38 PM UTC-5, Anton Ertl wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >You have mentioned before that compiler guys don't like register
> >pairing. But I did a (very)little research and thought that the work of
> >Preston Briggs (expressed in his thesis, several papers and a book) on
> >the subject of register allocation showed that it wasn't much of a
> >problem. Is that incorrect?
> I dimly remember Preston Briggs' paper on paired-register allocation.
> It shows that it can be done. However, I am not aware of this having
> been integrated into register allocators of widely available compilers
> (but maybe this happened without fanfare).
>
> I am also not aware of recent instruction sets getting
> pair-register-load and pair-register store instructions. Instead, ARM
> A64 added load-pair and store-pair instructions where the instructions
> in the pair can be determined independently, which is significantly
> easier to utilize in a compiler.
>
> The reason for not having paired registers in A64 may be that a paired
> register may be just as hard to deal with in the register renamer as
> two individual registers (Mitch Alsup claimed it was easy, but I did
> not understand his explanation).
<
If you have a DBLE instruction, you can simply write::
<
DBLE R9,R7,R5
QMUL R8,R6,R4
<
and the renamer has all the information it needs all the ports it needs
and all the registers remain independent--no pairing or sharing.
<
The thing to face is that you have an x-wide machine {32-bit or 64-bit}
and you want the ability to easily express 2×x-wide calculations, but
you don't foresee a need for doing 2×x-width every cycle, then DBLE
works just fine. It takes an instruction (size) but may not take a beat
in the pipeline.
<
If on the other hand, you foresee a need for 2×-wide more-or-less all
the time, it is time to add a 2×register file (or wider) and all the inst
needed to utilize the new register file.
<
A 32 register machine can do simple algorithms at 2×wide, dabble
with 3×wide algorithms, and the occasional 4×wide, but quickly runs
out of registers.
<
> If that is the case, the absence of
> paired registers as an architectural feature does not say anything
> about how hard paired registers are to deal with in a compiler; but if
> paired registers are easier than two individual registers in hardware,
> the use of individual registers in A64 may be due to compiler objections.
>
> Back to compilers: Basic register allocation is not that hard, but
> then you add in requirements coming from the calling convention, and
> from this and that (e.g., architectural featured like paired
> registers). You can do each requirement individually, but doing them
> alltogether makes things very nasty, especially because you also want
> the resulting code quality to be good.
<
Register allocation is not "that hard", but every addition {paired registers,
shared registers, mandated registers,...} adds 1 to the exponent of
complexity. Quickly getting to the "its really hard" point. The more
registers on has the easier it all gets.
<
> Already without paired
> registers the register allocations I see are not as good as I would
> like them to be*. So if the register allocator developers have any
> developer capacity left, I'd prefer that they make the existing
> allocation better rather than throwing new architectural misfeatures
> at them.
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Tuesday, May 30, 2023 at 1:25:33 PM UTC-5, Stephen Fuld wrote:
> On 5/30/2023 10:23 AM, Anton Ertl wrote:
> > Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >> You have mentioned before that compiler guys don't like register
> >> pairing. But I did a (very)little research and thought that the work of
> >> Preston Briggs (expressed in his thesis, several papers and a book) on
> >> the subject of register allocation showed that it wasn't much of a
> >> problem. Is that incorrect?
> >
> > I dimly remember Preston Briggs' paper on paired-register allocation.
> > It shows that it can be done. However, I am not aware of this having
> > been integrated into register allocators of widely available compilers
> > (but maybe this happened without fanfare).
> >
> > I am also not aware of recent instruction sets getting
> > pair-register-load and pair-register store instructions. Instead, ARM
> > A64 added load-pair and store-pair instructions where the instructions
> > in the pair can be determined independently, which is significantly
> > easier to utilize in a compiler.
> >
> > The reason for not having paired registers in A64 may be that a paired
> > register may be just as hard to deal with in the register renamer as
> > two individual registers (Mitch Alsup claimed it was easy, but I did
> > not understand his explanation). If that is the case, the absence of
> > paired registers as an architectural feature does not say anything
> > about how hard paired registers are to deal with in a compiler; but if
> > paired registers are easier than two individual registers in hardware,
> > the use of individual registers in A64 may be due to compiler objections.
> >
> > Back to compilers: Basic register allocation is not that hard, but
> > then you add in requirements coming from the calling convention, and
> > from this and that (e.g., architectural featured like paired
> > registers). You can do each requirement individually, but doing them
> > alltogether makes things very nasty, especially because you also want
> > the resulting code quality to be good. Already without paired
> > registers the register allocations I see are not as good as I would
> > like them to be*. So if the register allocator developers have any
> > developer capacity left, I'd prefer that they make the existing
> > allocation better rather than throwing new architectural misfeatures
> > at them.
<
> I don't disagree with any of your points. But then how do you propose
> handling 128 bit arithmetic (both integer and floating), assuming these
> are requirements? ISTM that if you don't use paired registers, then you
> have to double the number of register specifiers in each ALU
> instruction or do something like Mitch's instruction modifier mechanism
> or go to 128 bit registers. None of these seem "optimal" either. :-(
<
It really depends on what your target(s) is(are).
a) do you want to perform 128-bits occasionally,
b) do you want to perform 128-bits rather often,
c) do you want to perform 128-bits all the time.
<
One solution does not cover all the cases. My 66000 solution fits
between (a) and (b):: it is fundamentally a 64-bit machine {registers
data paths, memory hierarchy,...} with the ability to express wider
widths when needed (but you better not need it all the time.)
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

MitchAlsup <MitchAlsup@aol.com> writes:
>On Tuesday, May 30, 2023 at 1:25:33=E2=80=AFPM UTC-5, Stephen Fuld wrote:

>> I don't disagree with any of your points. But then how do you propose=20
>> handling 128 bit arithmetic (both integer and floating), assuming these=
>=20
>> are requirements? ISTM that if you don't use paired registers, then you=
>=20
>> have to double the number of register specifiers in each ALU=20
>> instruction or do something like Mitch's instruction modifier mechanism=
>=20
>> or go to 128 bit registers. None of these seem "optimal" either. :-(
><
>It really depends on what your target(s) is(are).=20
>a) do you want to perform 128-bits occasionally,
>b) do you want to perform 128-bits rather often,
>c) do you want to perform 128-bits all the time.
><
>One solution does not cover all the cases. My 66000 solution fits
>between (a) and (b):: it is fundamentally a 64-bit machine {registers
>data paths, memory hierarchy,...} with the ability to express wider
>widths when needed (but you better not need it all the time.)

In my experience, the primary use of 128-bit operations
is single-copy atomic stores to coprocessors, which fall
into (a) and/or (b).

On 5/30/2023 12:31 PM, MitchAlsup wrote:
> On Tuesday, May 30, 2023 at 1:25:33 PM UTC-5, Stephen Fuld wrote:
>> On 5/30/2023 10:23 AM, Anton Ertl wrote:
>>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
>>>> You have mentioned before that compiler guys don't like register
>>>> pairing. But I did a (very)little research and thought that the work of
>>>> Preston Briggs (expressed in his thesis, several papers and a book) on
>>>> the subject of register allocation showed that it wasn't much of a
>>>> problem. Is that incorrect?
>>>
>>> I dimly remember Preston Briggs' paper on paired-register allocation.
>>> It shows that it can be done. However, I am not aware of this having
>>> been integrated into register allocators of widely available compilers
>>> (but maybe this happened without fanfare).
>>>
>>> I am also not aware of recent instruction sets getting
>>> pair-register-load and pair-register store instructions. Instead, ARM
>>> A64 added load-pair and store-pair instructions where the instructions
>>> in the pair can be determined independently, which is significantly
>>> easier to utilize in a compiler.
>>>
>>> The reason for not having paired registers in A64 may be that a paired
>>> register may be just as hard to deal with in the register renamer as
>>> two individual registers (Mitch Alsup claimed it was easy, but I did
>>> not understand his explanation). If that is the case, the absence of
>>> paired registers as an architectural feature does not say anything
>>> about how hard paired registers are to deal with in a compiler; but if
>>> paired registers are easier than two individual registers in hardware,
>>> the use of individual registers in A64 may be due to compiler objections.
>>>
>>> Back to compilers: Basic register allocation is not that hard, but
>>> then you add in requirements coming from the calling convention, and
>>> from this and that (e.g., architectural featured like paired
>>> registers). You can do each requirement individually, but doing them
>>> alltogether makes things very nasty, especially because you also want
>>> the resulting code quality to be good. Already without paired
>>> registers the register allocations I see are not as good as I would
>>> like them to be*. So if the register allocator developers have any
>>> developer capacity left, I'd prefer that they make the existing
>>> allocation better rather than throwing new architectural misfeatures
>>> at them.
> <
>> I don't disagree with any of your points. But then how do you propose
>> handling 128 bit arithmetic (both integer and floating), assuming these
>> are requirements? ISTM that if you don't use paired registers, then you
>> have to double the number of register specifiers in each ALU
>> instruction or do something like Mitch's instruction modifier mechanism
>> or go to 128 bit registers. None of these seem "optimal" either. :-(
> <
> It really depends on what your target(s) is(are).
> a) do you want to perform 128-bits occasionally,
> b) do you want to perform 128-bits rather often,
> c) do you want to perform 128-bits all the time.

I think that is true, but with some caveats.

1. I don't know what the market today wants. Perhaps John Dallman or
Thomas Koenig, with their perspective can chime in.

2. Whatever the market is today, it will be different some years from
now. I don't have a prediction as to the speed of adoption, however,

3. There is a feedback effect. The easier/less costly it is to use, the
more it will be used. Your My 66000 is an example of that, where
essentially all calculations are done in 64 bit precision, not 32 bit
because the cost is so low. This wouldn't have happened say a decade
ago at least partially due to the increased cost differential of 64 bit
precision versus 32.

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

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>But then how do you propose
>handling 128 bit arithmetic (both integer and floating), assuming these
>are requirements? ISTM that if you don't use paired registers, then you
> have to double the number of register specifiers in each ALU
>instruction or do something like Mitch's instruction modifier mechanism
>or go to 128 bit registers.

128-bit registers look fine to me. AMD64 has them already (the xmm
registers), ARMv8-A has them already (and I think ARMv7-A, too;
ARMv9-A is an extension of ARMv8.5-A, and so also supports these
registers). So you just need to add the instructions that use them
for computing with 128-bit values.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On 5/29/2023 3:36 PM, Scott Lurndal wrote:
> 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.

IMHO, going much past 128 bits likely goes into diminishing returns
territory.

For practical working sizes for data, 32/64/128 make sense.
8 and 16 bits make sense for storage or for SIMD elements.
256 or 512 are almost "too big to be useful" in most cases.

Progressively doubling the size of the registers doesn't seem to make
sense from a cost POV.

Say, for example, I would imagine that 32x 512-bit registers will cost a
fair bit more than 32x 128-bit registers.

But, what can one "actually do with them" to justify the additional
costs?...

OTOH, paired 64-bit registers, while not necessarily the most elegant
solution, does seem to make sense in terms of implementation cost (or,
at least, vs having 128-bit registers and having most of the
instructions only use 1/2 or 1/4 of the register...).

Well, also I sort of like the idea of having the Lane 1 and 2 units
combine for 128-bit ops. In the design, most of the units are actually
only 64-bit internally, and one needs redundant units for ILP reasons.

If the 128-bit ops can be done through the 64-bit units, this seems good
(well, except that 128 bit ADD/SUB/CMPxx requires a carry-bit dependency
between the units).

....

But, implicitly, such a scheme does not give any obvious way to expand
things further.

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?)
>
> l.

It is possible to extend the register type field to support AVX/SIMD data: four types, four sizes and
1 to 64 repetitions, all info (~10 bits) present in extended load/store instructions? Additional types
such as complex, quaternion, RGB-alpha, ... should be considered/provisioned?

Speaking from software experience, every increase in data dimensionality calls for an order of magnitude
more subroutines/op-codes. E.g. scalar versus vector (signal processing) versus matrix (image processing), ...

An FPGA coprocessor would be ideal as it could handle wide data, except at one eighth the speed?
(only add the instructions needed for a specific job instead of the hundreds/thousands
needed in an all encompassing ISA). Would expect the FPGA manufacturers are working on this?

That said, VVM is the more pleasant approach.
Of course we already have FPGAs with multiple ARM cores,
and ARM cores keep getting faster. x86-64 is late to the party?
Would be useful if there was a basic/open VVM implementation to build on?

On 5/30/2023 10:54 PM, Anton Ertl wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> But then how do you propose
>> handling 128 bit arithmetic (both integer and floating), assuming these
>> are requirements? ISTM that if you don't use paired registers, then you
>> have to double the number of register specifiers in each ALU
>> instruction or do something like Mitch's instruction modifier mechanism
>> or go to 128 bit registers.
>
> 128-bit registers look fine to me. AMD64 has them already (the xmm
> registers), ARMv8-A has them already (and I think ARMv7-A, too;
> ARMv9-A is an extension of ARMv8.5-A, and so also supports these
> registers). So you just need to add the instructions that use them
> for computing with 128-bit values.

Fair enough. I agree with Mitch in that I don't like the separate SIMD
register approach, preferring VVM, but that would mean 128 bit GPRs,
which we are not ready for yet. (The key word here is yet. I expect
they will come.) If 128 bit arithmetic becomes popular, and it is only
implemented in the SIMD registers, you could end up with something like
the 68000 with separate data versus address registers. :-(

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

On 31 May 2023, Anton Ertl wrote
(in article<2023May31.075457@mips.complang.tuwien.ac.at>):

> Stephen Fuld<sfuld@alumni.cmu.edu.invalid> writes:
> > But then how do you propose
> > handling 128 bit arithmetic (both integer and floating), assuming these
> > are requirements? ISTM that if you don't use paired registers, then you
> > have to double the number of register specifiers in each ALU
> > instruction or do something like Mitch's instruction modifier mechanism
> > or go to 128 bit registers.
>
> 128-bit registers look fine to me. AMD64 has them already (the xmm
> registers), ARMv8-A has them already (and I think ARMv7-A, too;
> ARMv9-A is an extension of ARMv8.5-A, and so also supports these
> registers). So you just need to add the instructions that use them
> for computing with 128-bit values.
>
> - anton

The ICL 2900 had a 128-bit arithmetic register (top-of-stack) 50 years ago.

--
Bill Findlay

On Wednesday, May 31, 2023 at 12:38:08 PM UTC-4, Bill Findlay wrote:
> On 31 May 2023, Anton Ertl wrote
> (in article<2023May3...@mips.complang.tuwien.ac.at>):
> > Stephen Fuld<sf...@alumni.cmu.edu.invalid> writes:
> > > But then how do you propose
> > > handling 128 bit arithmetic (both integer and floating), assuming these
> > > are requirements? ISTM that if you don't use paired registers, then you
> > > have to double the number of register specifiers in each ALU
> > > instruction or do something like Mitch's instruction modifier mechanism
> > > or go to 128 bit registers.
> >
> > 128-bit registers look fine to me. AMD64 has them already (the xmm
> > registers), ARMv8-A has them already (and I think ARMv7-A, too;
> > ARMv9-A is an extension of ARMv8.5-A, and so also supports these
> > registers). So you just need to add the instructions that use them
> > for computing with 128-bit values.
> >
> > - anton
> The ICL 2900 had a 128-bit arithmetic register (top-of-stack) 50 years ago.
>
> --
> Bill Findlay

128-bit registers have been spec’d out for the Thor ISA basically because of
128-bit DFP. Current implementation is limited to 64-bits. It is tempting to do
the FP arithmetic in software and stay with 64-bit registers.

Personally, I am liking the SIMD approach, even though ugly. 512-bit cache-line
wide buckets. With some tag bits somewhere to specify the format.

Researching CORDIC ATM and I am reminded of IIR filters. Can CORDIC be
implemented with a modified IIR? Pondering adding filtering functions to Thor.

Supporting interruptible “micro-code” in Thor. The low order bits of the PC are
the micro-code address. Normally these bits are zero. I am wondering how
many bits to dedicate to micro-code. I am thinking 12-bits would be plenty.
But fewer bits would be better. The micro-code is just a dedicated table of
Thor ISA instructions used to implement macro instructions. How much
micro-code is required to implement FP functions like tan, tanh, etc?

On 5/31/2023 10:22 AM, Stephen Fuld wrote:
> On 5/30/2023 10:54 PM, Anton Ertl wrote:
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>> But then how do you propose
>>> handling 128 bit arithmetic (both integer and floating), assuming these
>>> are requirements?  ISTM that if you don't use paired registers, then you
>>>   have to double the number of register specifiers in each ALU
>>> instruction or do something like Mitch's instruction modifier mechanism
>>> or go to 128 bit registers.
>>
>> 128-bit registers look fine to me.  AMD64 has them already (the xmm
>> registers), ARMv8-A has them already (and I think ARMv7-A, too;
>> ARMv9-A is an extension of ARMv8.5-A, and so also supports these
>> registers).  So you just need to add the instructions that use them
>> for computing with 128-bit values.
>
> Fair enough.  I agree with Mitch in that I don't like the separate SIMD
> register approach, preferring VVM, but that would mean 128 bit GPRs,
> which we are not ready for yet. (The key word here is yet.  I expect
> they will come.)  If 128 bit arithmetic becomes popular, and it is only
> implemented in the SIMD registers, you could end up with something like
> the 68000 with separate data versus address registers.  :-(
>

I would personally much rather see a single unified register file, in
any case.

An ISA with 128-bit GPRs would be the more preferable option, and one
could likely use the large registers either for a large address space,
or maybe bounds-checked access or capabilities.

Say, Array Pointer:
( 63: 0): Address Field
( 83: 64): Array Size (Scaled)
(103: 84): Array Lower Bias
(108:104): Array Scale / Exponent
(111:109): Array RWX Mode
(123:112): Array Element Tag
(127:124): Top-Level Tag (Say, 0011 for Array)

Could still need fine adjustment, potentially 20 bits is overkill for
the size field when combined with an exponent.
Say, if we allow an 8B alignment, this allows an array that is 8MB which
is, most likely, going to be page-aligned.

If we assume a 4K alignment, this allows up to 4GB. OTOH, if the field
were smaller, this would mean more likely needing to pad arrays in many
cases.

Main drawback being that, if the program is primarily working with
32-bit 'int' values, then 128-bit registers would be kind of a waste.

It is usually only in edge cases that 128-bit integers really "make
sense", and even then, existing C compilers tend to not support them.

Like, if on many targets, if one does "__int128", the compiler is like
"Not supported on this target", this is a disincentive to use them, and
means that typically the program will (at most) end up only using half
the register.

Though, could have the amusing property if, say, one supports fixnum's,
and the fixnum ends up having a larger value range than C's 'long' and
'long long' types...

Other concerns:
Resource cost would likely be higher, as now supporting superscalar is a
bit more of an ask;
Maximum clock speed would likely be lower;
....

Could be OK for a 1-wide scalar machine though (or maybe a future 2-wide
superscalar).

But, yeah, could work...

>
>

On Wednesday, May 31, 2023 at 1:12:39 PM UTC-4, BGB wrote:
> On 5/31/2023 10:22 AM, Stephen Fuld wrote:
> > On 5/30/2023 10:54 PM, Anton Ertl wrote:
> >> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >>> But then how do you propose
> >>> handling 128 bit arithmetic (both integer and floating), assuming these
> >>> are requirements? ISTM that if you don't use paired registers, then you
> >>> have to double the number of register specifiers in each ALU
> >>> instruction or do something like Mitch's instruction modifier mechanism
> >>> or go to 128 bit registers.
> >>
> >> 128-bit registers look fine to me. AMD64 has them already (the xmm
> >> registers), ARMv8-A has them already (and I think ARMv7-A, too;
> >> ARMv9-A is an extension of ARMv8.5-A, and so also supports these
> >> registers). So you just need to add the instructions that use them
> >> for computing with 128-bit values.
> >
> > Fair enough. I agree with Mitch in that I don't like the separate SIMD
> > register approach, preferring VVM, but that would mean 128 bit GPRs,
> > which we are not ready for yet. (The key word here is yet. I expect
> > they will come.) If 128 bit arithmetic becomes popular, and it is only
> > implemented in the SIMD registers, you could end up with something like
> > the 68000 with separate data versus address registers. :-(
> >
> I would personally much rather see a single unified register file, in
> any case.
>
>
> An ISA with 128-bit GPRs would be the more preferable option, and one
> could likely use the large registers either for a large address space,
> or maybe bounds-checked access or capabilities.
>
>
> Say, Array Pointer:
> ( 63: 0): Address Field
> ( 83: 64): Array Size (Scaled)
> (103: 84): Array Lower Bias
> (108:104): Array Scale / Exponent
> (111:109): Array RWX Mode
> (123:112): Array Element Tag
> (127:124): Top-Level Tag (Say, 0011 for Array)
>
> Could still need fine adjustment, potentially 20 bits is overkill for
> the size field when combined with an exponent.
> Say, if we allow an 8B alignment, this allows an array that is 8MB which
> is, most likely, going to be page-aligned.
>
> If we assume a 4K alignment, this allows up to 4GB. OTOH, if the field
> were smaller, this would mean more likely needing to pad arrays in many
> cases.
>
>
> Main drawback being that, if the program is primarily working with
> 32-bit 'int' values, then 128-bit registers would be kind of a waste.
>
>
> It is usually only in edge cases that 128-bit integers really "make
> sense", and even then, existing C compilers tend to not support them.
>
> Like, if on many targets, if one does "__int128", the compiler is like
> "Not supported on this target", this is a disincentive to use them, and
> means that typically the program will (at most) end up only using half
> the register.
>
>
> Though, could have the amusing property if, say, one supports fixnum's,
> and the fixnum ends up having a larger value range than C's 'long' and
> 'long long' types...
>
>
> Other concerns:
> Resource cost would likely be higher, as now supporting superscalar is a
> bit more of an ask;
> Maximum clock speed would likely be lower;
> ...
>
> Could be OK for a 1-wide scalar machine though (or maybe a future 2-wide
> superscalar).
>
>
> But, yeah, could work...
>
>
> >
> >
I think 64-bits for the address field may not be enough for a virtual address. I
seem to recall a demand for 100-bit addressing in an alternate reality, but that
is probably quite a few years away. I also think it is better to have registers
just as a plain bucket. As soon as structure is added the design is stuck with
it. A separate tags file associated with registers might be easier to manage.

I am not so sure about the slowness of a superscalar. I think it may have more
to do with how full the FPGA is, the size and style of the design. I have been
able to hit close to 50 MHz timing according to the tools. I think 50 MHz is on
par with many other FPGA designs. Even if it is a few MHz slower the ability of
OoO to hide latency may make it worth it.

*****
I cannot believe I ignored Cordic for so long, having discovered its beauty..
Answering my own engineering question, 10-bits max micro-code it is; that
should be overkill. It should not take very many, if any micro-code words for
basic trig. Previously seven bits were used for Thor2021, but only about a half
dozen non-math instructions were micro-coded.

Having done some head scratching over cordic and how to calculate the tan,
I am thinking of just providing a cordic instruction that takes all three
arguments and calculates away, and then leave it up to the programmer to
decide on operands and what is being calculated. I get how to calculate sin
and cosine via cordic and I think tan finally. Specifying that x, y must be
fractions between 0 and 1, and that the angle must be radians between 0
and 2 pi.

I gather that modern processor do not use Cordic, and use polynomial
expansions instead.

For Thor Cordic is calculated out to 61-bits as that is eight more than the
53-bit significand.

13k LUTs to implement parallel cordic. So, switched to sequential cordic:
1.5 k LUTs. Might be supportable.

On Wednesday, May 31, 2023 at 8:04:47 PM UTC-5, robf...@gmail.com wrote:
> On Wednesday, May 31, 2023 at 1:12:39 PM UTC-4, BGB wrote:
> > On 5/31/2023 10:22 AM, Stephen Fuld wrote:
> > > On 5/30/2023 10:54 PM, Anton Ertl wrote:
> > >> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> > >>> But then how do you propose
> > >>> handling 128 bit arithmetic (both integer and floating), assuming these
> > >>> are requirements? ISTM that if you don't use paired registers, then you
> > >>> have to double the number of register specifiers in each ALU
> > >>> instruction or do something like Mitch's instruction modifier mechanism
> > >>> or go to 128 bit registers.
> > >>
> > >> 128-bit registers look fine to me. AMD64 has them already (the xmm
> > >> registers), ARMv8-A has them already (and I think ARMv7-A, too;
> > >> ARMv9-A is an extension of ARMv8.5-A, and so also supports these
> > >> registers). So you just need to add the instructions that use them
> > >> for computing with 128-bit values.
> > >
> > > Fair enough. I agree with Mitch in that I don't like the separate SIMD
> > > register approach, preferring VVM, but that would mean 128 bit GPRs,
> > > which we are not ready for yet. (The key word here is yet. I expect
> > > they will come.) If 128 bit arithmetic becomes popular, and it is only
> > > implemented in the SIMD registers, you could end up with something like
> > > the 68000 with separate data versus address registers. :-(
> > >
> > I would personally much rather see a single unified register file, in
> > any case.
> >
> >
> > An ISA with 128-bit GPRs would be the more preferable option, and one
> > could likely use the large registers either for a large address space,
> > or maybe bounds-checked access or capabilities.
> >
> >
> > Say, Array Pointer:
> > ( 63: 0): Address Field
> > ( 83: 64): Array Size (Scaled)
> > (103: 84): Array Lower Bias
> > (108:104): Array Scale / Exponent
> > (111:109): Array RWX Mode
> > (123:112): Array Element Tag
> > (127:124): Top-Level Tag (Say, 0011 for Array)
> >
> > Could still need fine adjustment, potentially 20 bits is overkill for
> > the size field when combined with an exponent.
> > Say, if we allow an 8B alignment, this allows an array that is 8MB which
> > is, most likely, going to be page-aligned.
> >
> > If we assume a 4K alignment, this allows up to 4GB. OTOH, if the field
> > were smaller, this would mean more likely needing to pad arrays in many
> > cases.
> >
> >
> > Main drawback being that, if the program is primarily working with
> > 32-bit 'int' values, then 128-bit registers would be kind of a waste.
> >
> >
> > It is usually only in edge cases that 128-bit integers really "make
> > sense", and even then, existing C compilers tend to not support them.
> >
> > Like, if on many targets, if one does "__int128", the compiler is like
> > "Not supported on this target", this is a disincentive to use them, and
> > means that typically the program will (at most) end up only using half
> > the register.
> >
> >
> > Though, could have the amusing property if, say, one supports fixnum's,
> > and the fixnum ends up having a larger value range than C's 'long' and
> > 'long long' types...
> >
> >
> > Other concerns:
> > Resource cost would likely be higher, as now supporting superscalar is a
> > bit more of an ask;
> > Maximum clock speed would likely be lower;
> > ...
> >
> > Could be OK for a 1-wide scalar machine though (or maybe a future 2-wide
> > superscalar).
> >
> >
> > But, yeah, could work...
> >
> >
> > >
> > >
> I think 64-bits for the address field may not be enough for a virtual address. I
> seem to recall a demand for 100-bit addressing in an alternate reality, but that
> is probably quite a few years away. I also think it is better to have registers
> just as a plain bucket. As soon as structure is added the design is stuck with
> it. A separate tags file associated with registers might be easier to manage.
>
> I am not so sure about the slowness of a superscalar. I think it may have more
> to do with how full the FPGA is, the size and style of the design. I have been
> able to hit close to 50 MHz timing according to the tools. I think 50 MHz is on
> par with many other FPGA designs. Even if it is a few MHz slower the ability of
> OoO to hide latency may make it worth it.
>
> *****
> I cannot believe I ignored Cordic for so long, having discovered its beauty.
<
Beautiful and slow as crap.
<
> Answering my own engineering question, 10-bits max micro-code it is; that
> should be overkill. It should not take very many, if any micro-code words for
> basic trig. Previously seven bits were used for Thor2021, but only about a half
> dozen non-math instructions were micro-coded.
>
> Having done some head scratching over cordic and how to calculate the tan,
> I am thinking of just providing a cordic instruction that takes all three
> arguments and calculates away, and then leave it up to the programmer to
> decide on operands and what is being calculated. I get how to calculate sin
> and cosine via cordic and I think tan finally. Specifying that x, y must be
> fractions between 0 and 1, and that the angle must be radians between 0
> and 2 pi.
>
> I gather that modern processor do not use Cordic, and use polynomial
> expansions instead.
<
Typical SW can perform tan() in 150± cycles.
My HW TMAC can do tan() in 19 or 36 cycles. between the latency of FDIV
and 2×FDIV. {This includes Payne and Hanek argument reduction.}
>
> For Thor Cordic is calculated out to 61-bits as that is eight more than the
> 53-bit significand.
>
> 13k LUTs to implement parallel cordic. So, switched to sequential cordic:
> 1.5 k LUTs. Might be supportable.
<
How many cycles of latency ?
<
For My 66000 TMAC unit::
................float...............double
sin()..........11...................19
cos().........11...................19
tan().......11-22..............19-33
ln2()............9...................15
exp2().........9...................15
atan2().....26....................36
pow()........21...................34
{including all argument reduction, polynomial evaluation, and reconstruction}

On 5/31/2023 8:04 PM, robf...@gmail.com wrote:
> On Wednesday, May 31, 2023 at 1:12:39 PM UTC-4, BGB wrote:
>> On 5/31/2023 10:22 AM, Stephen Fuld wrote:
>>> On 5/30/2023 10:54 PM, Anton Ertl wrote:
>>>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
>>>>> But then how do you propose
>>>>> handling 128 bit arithmetic (both integer and floating), assuming these
>>>>> are requirements? ISTM that if you don't use paired registers, then you
>>>>> have to double the number of register specifiers in each ALU
>>>>> instruction or do something like Mitch's instruction modifier mechanism
>>>>> or go to 128 bit registers.
>>>>
>>>> 128-bit registers look fine to me. AMD64 has them already (the xmm
>>>> registers), ARMv8-A has them already (and I think ARMv7-A, too;
>>>> ARMv9-A is an extension of ARMv8.5-A, and so also supports these
>>>> registers). So you just need to add the instructions that use them
>>>> for computing with 128-bit values.
>>>
>>> Fair enough. I agree with Mitch in that I don't like the separate SIMD
>>> register approach, preferring VVM, but that would mean 128 bit GPRs,
>>> which we are not ready for yet. (The key word here is yet. I expect
>>> they will come.) If 128 bit arithmetic becomes popular, and it is only
>>> implemented in the SIMD registers, you could end up with something like
>>> the 68000 with separate data versus address registers. :-(
>>>
>> I would personally much rather see a single unified register file, in
>> any case.
>>
>>
>> An ISA with 128-bit GPRs would be the more preferable option, and one
>> could likely use the large registers either for a large address space,
>> or maybe bounds-checked access or capabilities.
>>
>>
>> Say, Array Pointer:
>> ( 63: 0): Address Field
>> ( 83: 64): Array Size (Scaled)
>> (103: 84): Array Lower Bias
>> (108:104): Array Scale / Exponent
>> (111:109): Array RWX Mode
>> (123:112): Array Element Tag
>> (127:124): Top-Level Tag (Say, 0011 for Array)
>>
>> Could still need fine adjustment, potentially 20 bits is overkill for
>> the size field when combined with an exponent.
>> Say, if we allow an 8B alignment, this allows an array that is 8MB which
>> is, most likely, going to be page-aligned.
>>
>> If we assume a 4K alignment, this allows up to 4GB. OTOH, if the field
>> were smaller, this would mean more likely needing to pad arrays in many
>> cases.
>>
>>
>> Main drawback being that, if the program is primarily working with
>> 32-bit 'int' values, then 128-bit registers would be kind of a waste.
>>
>>
>> It is usually only in edge cases that 128-bit integers really "make
>> sense", and even then, existing C compilers tend to not support them.
>>
>> Like, if on many targets, if one does "__int128", the compiler is like
>> "Not supported on this target", this is a disincentive to use them, and
>> means that typically the program will (at most) end up only using half
>> the register.
>>
>>
>> Though, could have the amusing property if, say, one supports fixnum's,
>> and the fixnum ends up having a larger value range than C's 'long' and
>> 'long long' types...
>>
>>
>> Other concerns:
>> Resource cost would likely be higher, as now supporting superscalar is a
>> bit more of an ask;
>> Maximum clock speed would likely be lower;
>> ...
>>
>> Could be OK for a 1-wide scalar machine though (or maybe a future 2-wide
>> superscalar).
>>
>>
>> But, yeah, could work...
>>
>>
>>>
>>>
> I think 64-bits for the address field may not be enough for a virtual address. I
> seem to recall a demand for 100-bit addressing in an alternate reality, but that
> is probably quite a few years away. I also think it is better to have registers
> just as a plain bucket. As soon as structure is added the design is stuck with
> it. A separate tags file associated with registers might be easier to manage.
>

It is a tradeoff.

As-is, I have 96-bit, but this is likely overkill.

As noted, the registers themselves would be unstructured, but operations
on those registers could assume a certain amount of structure.

Sort of like, how 4x Binary32 SIMD ops, kinda assume that the vector is
4x Binary32.

As noted, pointer formats in my case are basically:
(47: 0): Address
(59:48): Type-Tag / Etc
(63:60): Top-Level Tag

But, for the most part, Load/Store ops, etc ignore the high 16 bits.

But, say, the top 4 bits are:
0000: Basic (Object) pointer
0001: Small Value Spaces
0010: Bound Array
0011: Bound Array
01xx: Fixnum (62 bit)
10xx: Flonum (62 bit)
1100: TagArray + Base Offset
1101: Dense Vector
1110: Typed Pointer
1111: Extended 60-bit Linear Address (Optional, 1)

1: This format would effectively map a 64-bit pointer to a range of
multiple "quadrants" (or, possibly a table of locations within the
larger 96-bit address space).

There is a 128-bit format:
( 47: 0): Address (Low 48-bits)
( 59: 48): Type-Tag / Etc
( 63: 60): Top-Level Tag
(111: 64): Address (High 48-bits)
(127:112): Additional Tag Metadata

The formats for bounded-arrays are expanded somewhat.

The Fixnum an Flonum formats would expand to 124 bits in this case.

Current format for function pointers and link register is:
( 0): Inter-ISA Bit
(47: 1): Address
(63:48): Mode Flags

If Addr(0) is 0, the high 16 bits are ignored (or Trap if the Link
Register is expected). If 1, the high bits encode the operating mode and
similar.

High bits:
* (63:56), Saved SR(15: 8), U0..U7
* (55:52), Saved SR(23:20), WX3, WX4, WM1, WM2
* (51:50), Saved SR(27:26), WXE, WX2
* (49:48), Saved SR( 1: 0), S and T

The WXn and WMn bits encode the operating mode (BJX2 vs XG2 vs RV64 vs
XG2RV).

U0..U7 are user-defined or context-dependent flag bits (2).

S and T are the values of the S and T flag bits (in the current form of
the ISA, these are saved across function calls as this makes it possible
to predicate blocks with function calls).

2: In an x86 emulator, it is possible that these could be used as a
stand-in for ALU status flags or similar. These are also preserved
across function calls. They may also be used for more complex
predication (predicating based on logical relations between U-bits).

> I am not so sure about the slowness of a superscalar. I think it may have more
> to do with how full the FPGA is, the size and style of the design. I have been
> able to hit close to 50 MHz timing according to the tools. I think 50 MHz is on
> par with many other FPGA designs. Even if it is a few MHz slower the ability of
> OoO to hide latency may make it worth it.
>

Issue is mostly "net delay" (and to an extent, "fanout"):
The bulkier/wider/etc the logic gets, the slower it gets...

And, say, one can do a "simple 16-bit machine" and run it at 200 MHz.
But, not so much anything much bigger than said simple 16-bit machine.

Or a 32-bit machine running at 100MHz (say, MicroBlaze falls in here).

But, a 3-wide 64-bit machine is limited to around 50 MHz.
Had gotten 1-wide variants running at 100 MHz, but not reliably.
A 1-wide core running at 75 MHz is a little easier to pull off though.

Making the caches bigger also make them slower, etc.

But, going from 64-bit to 128-bit is likely to result in a notable
increase in area (particularly for superscalar or VLIW), which is likely
going to make the "net delay" issues a lot worse.

For 128-bit, one might end up, say, with a scalar machine that runs at
50 MHz, but if they want to go 2-wide, they need to drop it to 33 or 25 MHz.

On the other side, 32-bit machines, while one can get them running at
potentially 100 or (maybe) 150 MHz, are more limited in some areas (and
32-bit is started to look a little "stale" at this point).

While a 16-bit core can get a higher clock-speed, a 16-bit machine is
too limited to really accomplish a whole lot (and pretty much anything
one can do to make it "actually useful" would either come at the expense
of reducing clock speed, or taking too many clock cycles to give it much
of an advantage).

But, yeah, the limitation for MHz on FPGA seems to be more about how
long it takes signals to propagate around the FPGA, rather than about
the speed of the individual LUTs and similar.

So, if a given piece of FPGA logic is small, it can be internally run at
a higher clock-speed. Though, for external IO, one is limited some in
that one can't drive the pins much faster than around 100 MHz without
using SERDES.

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>If 128 bit arithmetic becomes popular, and it is only
>implemented in the SIMD registers, you could end up with something like
>the 68000 with separate data versus address registers. :-(

Yes, or the CDC 6600 A/B and X registers. But I don't expect that
128-bit arithmetic will become popular enough that popular
architectures add 128-bit instructions for them. As for 128-bit
addresses, given the slowdown in semiconductor advances, we may never
get there.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

"robf...@gmail.com" <robfi680@gmail.com> writes:
>On Wednesday, May 31, 2023 at 1:12:39=E2=80=AFPM UTC-4, BGB wrote:
>> On 5/31/2023 10:22 AM, Stephen Fuld wrote:=20
>> > On 5/30/2023 10:54 PM, Anton Ertl wrote:=20

>>=20
>> An ISA with 128-bit GPRs would be the more preferable option, and one=20
>> could likely use the large registers either for a large address space,=20
>> or maybe bounds-checked access or capabilities.=20
>>=20
>>=20
>> Say, Array Pointer:=20
>> ( 63: 0): Address Field=20
>> ( 83: 64): Array Size (Scaled)=20
>> (103: 84): Array Lower Bias=20
>> (108:104): Array Scale / Exponent=20
>> (111:109): Array RWX Mode=20
>> (123:112): Array Element Tag=20
>> (127:124): Top-Level Tag (Say, 0011 for Array)=20

See https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

On 5/31/2023 11:18 PM, Anton Ertl wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> If 128 bit arithmetic becomes popular, and it is only
>> implemented in the SIMD registers, you could end up with something like
>> the 68000 with separate data versus address registers. :-(
>
> Yes, or the CDC 6600 A/B and X registers. But I don't expect that
> 128-bit arithmetic will become popular enough that popular
> architectures add 128-bit instructions for them.

You may be right, or it may be a question of when, not if. Of course,
if when is a long enough time, it becomes practically indistinguishable
from when. :-)

> As for 128-bit
> addresses, given the slowdown in semiconductor advances, we may never
> get there.

Agreed, but again, it may come down to a question of when.

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

On 6/1/2023 7:13 AM, Stephen Fuld wrote:
> On 5/31/2023 11:18 PM, Anton Ertl wrote:
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>> If 128 bit arithmetic becomes popular, and it is only
>>> implemented in the SIMD registers, you could end up with something like
>>> the 68000 with separate data versus address registers.  :-(
>>
>> Yes, or the CDC 6600 A/B and X registers.  But I don't expect that
>> 128-bit arithmetic will become popular enough that popular
>> architectures add 128-bit instructions for them.
>
> You may be right, or it may be a question of when, not if.  Of course,
> if when is a long enough time, it becomes practically indistinguishable
> from when.  :-)

Sorry, that last "when" should have been "if". :-(

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

On Thursday, June 1, 2023 at 12:13:31 AM UTC-5, BGB wrote:
>
> > I gather that modern processor do not use Cordic, and use polynomial
> > expansions instead.
> >
> Yeah.
>
> I mostly used Taylor Series expansions and similar...
<
Chebyshev not Taylor; and sometimes Remez correction of Chebyshev
coefficients.
>

scott@slp53.sl.home (Scott Lurndal) writes:
>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.

The Fujitsu A64FX supports 512-bit SVE; it was one of the earliest, if
not the earliest SVE implementation.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>