MitchAlsup wrote:
> On Saturday, September 30, 2023 at 4:41:16 PM UTC-5, Thomas Koenig wrote:
>> luke.l...@gmail.com <luke.l...@gmail.com> schrieb:
>>> as Mitch notes in a later post (today), the "Cartesian Product" turns out
>>> in say Audio DSPs doing SWAR (SIMD Within A Register) such as AndesStar
>>> to be an O(N^6) clusterpoop. these DSPs, they are under enormous cost
>>> and power budget pressure (think "C-Media sub-$1 USB Audio PHYs with
>>> built-in volume control", they potentially only run at 8-12 mhz and are likely
>>> in 130 or even 180 nm! USB1.1 and/or have a PLL that slaves to the host
>>> USB bus, the STM32F072 does this: really neat trick)
>>>
>>> take even just an ADD, you would think there
>>> would only ever be one add instruction in a RISC ISA? ehhhhm no
>>>
>>> * 8/16 bit source selection doubles that
>>> * 8/16 bit destination selection doubles it again
>> Assuming that these processors are indeed RISC (so, a load-
>> store architecture), then this could be handled by having
>>
>> - 8-bit sign-extending load
>> - 8-bit zero-extending load
>> - 16 bit load
>> - 8-bit store
>> - 16-bit store
> <
> 7 LDs, 4 STs:: the LDs need sign/zero extension (except for the largest).
> <
> But we started off with SIMD and there registers go up to 512-bits (so far)..
> At 512-bits, one needs {8, 16, 32, 64, 128, 256}×{s, u}+{512} for Loading data
>> and always doing 16-bit arithmetic.
>>
>> Hm, that's five loads and stores so far, still some room :-)
> <
> Yes, exactly; isolating data width to LD and ST instructions saves instruction
> count big time--UNTIL--you need multiple calculations within a single register
> width. So, a real RISC machine has 1 (or 2) ADDs, whereas a SIMD machine
> has {widths}×{signs}×{formats} (and more as EricP illustrated above.)
>> (Or is it a "RISC" in the sense of the MSP430, which is about as
>> much a RISC as the PDP-11? Then the above does not apply).
> <
> RISC means::
> LD/ST architecture (no LD-OPs or LD-OP-STs)
> Lots of GPRs (you might get away with 16 but 32 is general min)
> Hardwired sequencing
> Instruction pipelining
> Driven primarily by compiler (with just a dabbling of ASM)
> <
>>> * hi/lo half on source 1 doubles it again
>>> * hi/lo half on source 2 doubles it again
>> I'm not quite sure what the functionality is. Is it possible
>> to effectively treat each half of a register as a sub-register in
>> the ISA? Then, you need the bits for it.
> <
> EricP is talking about a 512-bit register having {64,32,16,8,{4,2,1}}
> values in that 1 register. And, yes, you need bits to specify each
> nuance.

I think you mean Thomas not me

I've never written a single simd instruction in my life.
For me it's just easier to let the normal load-store units
take care of all the aliasing and packing and unpacking.

The only simd instructions I might have use for is wide load and store with
a register or immediate byte count from 1..64, zero fill unused bytes.
Then use the simd registers as source/dest fields,
essentially an L0 cache with manual coherence.
But I have trouble justifying even that for other than byte-blob moves
as it sounds more trouble than its worth.

On Sunday, October 1, 2023 at 10:15:23 AM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > On Saturday, September 30, 2023 at 4:41:16 PM UTC-5, Thomas Koenig wrote:
> >> luke.l...@gmail.com <luke.l...@gmail.com> schrieb:
> >>> as Mitch notes in a later post (today), the "Cartesian Product" turns out
> >>> in say Audio DSPs doing SWAR (SIMD Within A Register) such as AndesStar
> >>> to be an O(N^6) clusterpoop. these DSPs, they are under enormous cost
> >>> and power budget pressure (think "C-Media sub-$1 USB Audio PHYs with
> >>> built-in volume control", they potentially only run at 8-12 mhz and are likely
> >>> in 130 or even 180 nm! USB1.1 and/or have a PLL that slaves to the host
> >>> USB bus, the STM32F072 does this: really neat trick)
> >>>
> >>> take even just an ADD, you would think there
> >>> would only ever be one add instruction in a RISC ISA? ehhhhm no
> >>>
> >>> * 8/16 bit source selection doubles that
> >>> * 8/16 bit destination selection doubles it again
> >> Assuming that these processors are indeed RISC (so, a load-
> >> store architecture), then this could be handled by having
> >>
> >> - 8-bit sign-extending load
> >> - 8-bit zero-extending load
> >> - 16 bit load
> >> - 8-bit store
> >> - 16-bit store
> > <
> > 7 LDs, 4 STs:: the LDs need sign/zero extension (except for the largest).
> > <
> > But we started off with SIMD and there registers go up to 512-bits (so far)..
> > At 512-bits, one needs {8, 16, 32, 64, 128, 256}×{s, u}+{512} for Loading data
> >> and always doing 16-bit arithmetic.
> >>
> >> Hm, that's five loads and stores so far, still some room :-)
> > <
> > Yes, exactly; isolating data width to LD and ST instructions saves instruction
> > count big time--UNTIL--you need multiple calculations within a single register
> > width. So, a real RISC machine has 1 (or 2) ADDs, whereas a SIMD machine
> > has {widths}×{signs}×{formats} (and more as EricP illustrated above.)
> >> (Or is it a "RISC" in the sense of the MSP430, which is about as
> >> much a RISC as the PDP-11? Then the above does not apply).
> > <
> > RISC means::
> > LD/ST architecture (no LD-OPs or LD-OP-STs)
> > Lots of GPRs (you might get away with 16 but 32 is general min)
> > Hardwired sequencing
> > Instruction pipelining
> > Driven primarily by compiler (with just a dabbling of ASM)
> > <
> >>> * hi/lo half on source 1 doubles it again
> >>> * hi/lo half on source 2 doubles it again
> >> I'm not quite sure what the functionality is. Is it possible
> >> to effectively treat each half of a register as a sub-register in
> >> the ISA? Then, you need the bits for it.
> > <
> > EricP is talking about a 512-bit register having {64,32,16,8,{4,2,1}}
> > values in that 1 register. And, yes, you need bits to specify each
> > nuance.
> I think you mean Thomas not me
<
Sorry, My mistake.........
>
> I've never written a single simd instruction in my life.
> For me it's just easier to let the normal load-store units
> take care of all the aliasing and packing and unpacking.
>
> The only simd instructions I might have use for is wide load and store with
> a register or immediate byte count from 1..64, zero fill unused bytes.
> Then use the simd registers as source/dest fields,
> essentially an L0 cache with manual coherence.
<
> But I have trouble justifying even that for other than byte-blob moves
> as it sounds more trouble than its worth.
<
I have MM (move multiple) for byte-blobs without going through the RF.

On Sunday, October 1, 2023 at 4:52:58 AM UTC-5, luke.l...@gmail.com wrote:
> On Sunday, October 1, 2023 at 12:39:34 AM UTC+1, MitchAlsup wrote:
> > On Saturday, September 30, 2023 at 6:13:16 PM UTC-5, luke.l...@gmail.com wrote:
> > > i designed some hardware to do that and for 12 LD/ST Reservation
> > > Stations it has something mad like 10,000 wires incoming/outgoing
> > > but only 4,000 actual gates.
> > <
> > That is the classical trade off between Scoreboards and Reservation
> > Stations.
<
> ah no sorry i wasn't clear: this was based on the EA-matching that is in
> your Scoreboard Mechanics book chapters (or perhaps the 88100 ones),
> where you take 10-12 bits and perform a triangular match to find conflicts.
> it's O(N^2) so by the time you get up to (say) 12 LD/STs a full crossbar
> on address/data/tag where data is 128-bit by that point (because 64-bit @
> up to 8 bytes shifted) it gets pretty hairy.
<
The 88100 was a simple register interlock not a scoreboard.
<
You should be able to get the triangular match into the issue part (so an
instruction can be issued together with an earlier instruction which delivers
an operand to the later instruction) and then it is ScoreBoardy from there
on out.
<
The thing I forgot to mention, is that after each FU broadcasts is tag (128
wires) all of the wires with the same index and be combined (OR) so the
global wiring is only 128-bits--to do this the waiting instruction has to know
what FU is broadcasting which operand.
<
It also occurred to me that this is the perfect way to deal with My 66000
predication (where one has x instructions in the then clause and y instructions
in the else clause (x and y) <= 8). You use the PRED instruction to broadcast
then or else which releases the <likely completed> instructions from the then
or else clause and cancels the other branch.
>
> l.

MitchAlsup wrote:
> On Sunday, October 1, 2023 at 10:15:23 AM UTC-5, EricP wrote:
>>
>> The only simd instructions I might have use for is wide load and store with
>> a register or immediate byte count from 1..64, zero fill unused bytes.
>> Then use the simd registers as source/dest fields,
>> essentially an L0 cache with manual coherence.
> <
>> But I have trouble justifying even that for other than byte-blob moves
>> as it sounds more trouble than its worth.
> <
> I have MM (move multiple) for byte-blobs without going through the RF.

I too would have mem-blob operate instructions specifically design to
mem-blobby things. (this whole business of having the run-time libraries
decide on the fly which instruction sets to use for an optimum move is nuts).

For that simd variable wide LD/ST I'm thinking of operating on structs
which have a byte size and alignment. For example, balancing an AVL tree,
the node struct has 3 pointers, left, right, parent, and a depth count,
plus other data for that node. It could load 4 structs into wide registers,
do the balance rotations by operating on byte fields in the simd registers,
and store the 4 changes.
Since I know these are all separate objects, I know no aliasing
is possible so operating on them in bulk is straight forward.

>> I think you can't get a good answer before clarifying what it is that
>> you consider as the problem in "opcode proliferation" (after all,
> The problem is that the Cartesian-product associated with SIMD
> causes thousands of microscopic instructions to be needed (for
> example ARM has at least 1,300 SIMD instructions, others worse.)

I don't see why that *in itself* is a problem.
I don't like this either, but that doesn't mean it's a problem.
We should be more clear about the actual concrete problems (which are
probably somewhere in the consequences of having so many opcodes).

> It is my contention that sooner or later one needs to respect the R
> as the first letter in RISC and make it stand for REDUCED !!

But the *R* was not so much about the number of distinct instructions
but about the complexity of each instruction, AFAIK.
[ And even that has proved to be not so terribly important with current
BigOoO machines. ]

> It is also my contention that nobody with more than <wave hands>
> 200 instructions can be called RISC.

The "RISC" name in itself doesn't sell nor does it help find answers
faster or more cheaply.

> Sooner or later it all adds up to shiploads of instructions. And the
> instructions are not backwards compatible,...

Ah, here's a concrete problem, thanks: indeed it requires recompiling
your code to take advantage of wider implementations.
The "scalable vectors" guys claim they don't suffer from that, but
according to Luke it doesn't work out quite so nicely either :-(
[ The cynic in me suggests this is a feature-not-a-bug. ]

Luke mentioned another case where the proliferation may put pressure on the
cost of the cheapest implementation, thus locking that ISA out of
certain markets. I don't have a clear enough idea of the relative costs
of the various alternatives to judge how serious this is, tho.

Stefan

Pop to the top

On Monday, October 2, 2023 at 4:37:34 PM UTC+1, Stefan Monnier wrote:

> But the *R* was not so much about the number of distinct instructions
> but about the complexity of each instruction, AFAIK.

yes in the case of the Power ISA i can confirm that. there are two
stories:

1. if you look at the VHDL for microwatt you find *one* add operation.
it takes A/~A, carry-in equal to 0/1/CA, it takes B as RB or zero,
it outputs RT/~RT and it produces CA/CA32.

in other words it can synthesise literally any operation, neg, sub,
add, add-carry, sub-carry, the total permutations of the above comes
to a whopping 2x3x2x2x2 72 different arithmetic operations!

therefore despite there being *one adder* we should not be
surprised to find *over forty* different Decoder add/sub arithmetic
operations in Power ISA.

2. the LD/ST, shift-and-mask, and and/or logical operations have some
extremely weird register names, RA RB RC RS and RT.

it turns out that (read the original POWER1 paper from 1991) there
wasn't enough space to put a separate shifter into 130 nm silicon
as well as one in the LD/ST unit, so they *shared* it by hiding it
behind RISC-based Micro-Coding.

the names RA RB RC RT and RS were the names of "Operand
Forwarding Broadcast Buses" that were used to communicate
*partial results* between three micro-operations, which, back-to-back
performed the full LD operation, where the "raw" LD was of course
word-aligned, and had to be extracted with a shift-and-mask.

of course now "silicon is cheap" so the trick is no longer deployed,
but it gives us some insight into the RISC concept, for when resources
matter.

> The "scalable vectors" guys claim they don't suffer from that, but
> according to Luke it doesn't work out quite so nicely either :-(
> [ The cynic in me suggests this is a feature-not-a-bug. ]

they attempt to *sell* the dog's dinner mess as a feature.
ARM *may* succeed at that, but Silicon partners are fighting
back because they don't like the binary incompatibility.
RISC-V i doubt will succeed technically and why would you
use something that has bipartisan US senator support for
cutting China off at the knees due to over 75% of Board
Members of RISC-V being from China?
> Luke mentioned another case where the proliferation may put pressure on the
> cost of the cheapest implementation, thus locking that ISA out of
> certain markets. I don't have a clear enough idea of the relative costs
> of the various alternatives to judge how serious this is, tho.

mass-volume pricing is brutal. you got a solution that allows
product to be manufactured for $0.75 instead of $0.90 you
lose all your customer orders - hundreds of millions of business -
within about 3 months.

Allwinner came out with the very first tablet/IPTV ARM Cortex A8
back in 2010 and caused a major recession in Guangdong due
to everyone else holding stock of ARM11-based tablet offerings.

the BOM for the Allwinner A10 tablets were $18 allowing tablets
to be sold for the first time for $35. everyone else had a $40 BOM
and was selling for appx $70 at the time.

anyone holding stock of those ARM11 tablets *or who had components*
went out of business within 3 months.

nobody outside of China noticed but it was really serious, the
Chinese Govt had to step in. there were a lot of
very pissed off China investors who jumped on the Allwinner
bandwagon and carved out their own "niches" which became
the 5-or-so (independent) business units within Allwinner,
beyond even its CEO's control.

l.

On Sunday, October 15, 2023 at 5:05:51 PM UTC-5, luke.l...@gmail.com wrote:
> On Monday, October 2, 2023 at 4:37:34 PM UTC+1, Stefan Monnier wrote:
>
> > But the *R* was not so much about the number of distinct instructions
> > but about the complexity of each instruction, AFAIK.
> yes in the case of the Power ISA i can confirm that. there are two
> stories:
>
> 1. if you look at the VHDL for microwatt you find *one* add operation.
> it takes A/~A, carry-in equal to 0/1/CA, it takes B as RB or zero,
> it outputs RT/~RT and it produces CA/CA32.
>
> in other words it can synthesise literally any operation, neg, sub,
> add, add-carry, sub-carry, the total permutations of the above comes
> to a whopping 2x3x2x2x2 72 different arithmetic operations!
<
Spot on. {except for the carry-in thing can be done in 2 states plus 1 gate
so I only count this as 2 states not 3}.
>
> therefore despite there being *one adder* we should not be
> surprised to find *over forty* different Decoder add/sub arithmetic
> operations in Power ISA.
<
At some point you will want to express each of these useful forms with
assembler spellings representing each feature {alone or aggregated}.
The question becomes how many spellings do you have to express all
those nuances:: so would you rather have::
<
ADD Rd,[-]Rs1,[-]Rs2
OR
ADD Rd,Rs1,Rs2
SUB Rd,Rs1,Rs2
RSUB Rd,Rs1,Rs2
>
> 2. the LD/ST, shift-and-mask, and and/or logical operations have some
> extremely weird register names, RA RB RC RS and RT.
>
> it turns out that (read the original POWER1 paper from 1991) there
> wasn't enough space to put a separate shifter into 130 nm silicon
> as well as one in the LD/ST unit, so they *shared* it by hiding it
> behind RISC-based Micro-Coding.
<
1991 should have been closer to 0.5µ
>
> the names RA RB RC RT and RS were the names of "Operand
> Forwarding Broadcast Buses" that were used to communicate
> *partial results* between three micro-operations, which, back-to-back
> performed the full LD operation, where the "raw" LD was of course
> word-aligned, and had to be extracted with a shift-and-mask.
<
These busses might have only had data persist for 3/4 a clock cycle.
>
> of course now "silicon is cheap" so the trick is no longer deployed,
> but it gives us some insight into the RISC concept, for when resources
> matter.
> > The "scalable vectors" guys claim they don't suffer from that, but
> > according to Luke it doesn't work out quite so nicely either :-(
> > [ The cynic in me suggests this is a feature-not-a-bug. ]
<
> they attempt to *sell* the dog's dinner mess as a feature.
<
LoL
<
> ARM *may* succeed at that, but Silicon partners are fighting
> back because they don't like the binary incompatibility.
> RISC-V i doubt will succeed technically and why would you
> use something that has bipartisan US senator support for
> cutting China off at the knees due to over 75% of Board
> Members of RISC-V being from China?
<
> > Luke mentioned another case where the proliferation may put pressure on the
> > cost of the cheapest implementation, thus locking that ISA out of
> > certain markets. I don't have a clear enough idea of the relative costs
> > of the various alternatives to judge how serious this is, tho.
<
> mass-volume pricing is brutal. you got a solution that allows
> product to be manufactured for $0.75 instead of $0.90 you
> lose all your customer orders - hundreds of millions of business -
> within about 3 months.
<
I think your logic is backwards:: If you can't find a cost competitive
solution, you can't make any product profit at the beginning and
won't have any cache flow 3 months down the road.
>
> Allwinner came out with the very first tablet/IPTV ARM Cortex A8
> back in 2010 and caused a major recession in Guangdong due
> to everyone else holding stock of ARM11-based tablet offerings.
>
> the BOM for the Allwinner A10 tablets were $18 allowing tablets
> to be sold for the first time for $35. everyone else had a $40 BOM
> and was selling for appx $70 at the time.
>
> anyone holding stock of those ARM11 tablets *or who had components*
> went out of business within 3 months.
>
> nobody outside of China noticed but it was really serious, the
> Chinese Govt had to step in. there were a lot of
> very pissed off China investors who jumped on the Allwinner
> bandwagon and carved out their own "niches" which became
> the 5-or-so (independent) business units within Allwinner,
> beyond even its CEO's control.
>
> l.