@MSGID:
<c0a376dc-2c9b-440a-91df-0beea9c7d3c7n@googlegroups.com> 63f84763
@REPLY: 1@newsreader4.netcologne.de>
c9cb90bf
@REPLYADDR MitchAlsup <MitchAlsup@aol.com>
@REPLYTO 2:5075/128 MitchAlsup
@CHRS: CP866 2
@RFC: 1 0
@RFC-References: 1@dont-email.me>
<memo.20230916204926.16432A@jgd.cix.co.uk> 1@dont-email.me> 1@dont-email.me>
<287e35a5-e78f-4ae2-bbb1-606f7bbdfe98n@googlegroups.com> <jwv5y3ydyqr.fsf-monnier+comp.arch@gnu.org>
<901e43e0-902d-4f5d-8ae4-22c570a94191n@googlegroups.com> <95KRM.207899$Hih7.53988@fx11.iad>
<72b6255a-e9b5-4549-b243-49ab8c49b064n@googlegroups.com> <2023Sep30.092454@mips.complang.tuwien.ac.at>
<128abea4-a935-4ef6-b7fe-71f0f1f35be0n@googlegroups.com> 1@newsreader4.netcologne.de>
@RFC-Message-ID:
<c0a376dc-2c9b-440a-91df-0beea9c7d3c7n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
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}x{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}x{signs}x{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.
<
> > * signed and unsigned saturation triples the number of ADD operations 
> > (clipping in audio is important rather than getting wrapping distortion)
> Yes, then you also need separate eight-bit additions.
> > * "average-add" (x+y+1)>>1 (for Audio this is crucial) doubles again 
> > (if you only have 16 bit audio and a low-speed DSP you cannot afford 
> > to do that kind of calculation in 3 instructions, and you need 32-bit regs)
> So, another addition...
 > > we are up to 6 dimensions and a whopping NINETY SIX
*commercially necessary* 
> > variants on what is supposed to be one simple ADD operation!
<
Now take a look at what happens when the very vast majority of code
does not need any of "that" and you specify variants with prefixes (or
postfixes), you end up back in RISC land being able to specify each of
those variants but you have a sum of prefixing bits not a Cartesian product
of instructions. Here, when you double the width of a SIMD register, you 
add 1 prefix (instead of 60+ each) and you have access to all its functionality.
<
.....
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441