@MSGID: 1@newsreader4.netcologne.de>
c9cb90bf
@REPLY:
<128abea4-a935-4ef6-b7fe-71f0f1f35be0n@googlegroups.com> eacf2e99
@REPLYADDR Thomas Koenig <tkoenig@netcologne.de>
@REPLYTO 2:5075/128 Thomas Koenig
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
1@newsreader4.netcologne.de>
@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>
@TZUTC: -0000
@PID: slrn/1.0.3 (Linux)
@TID: FIDOGATE-5.12-ge4e8b94
luke.l...@gmail.com <luke.leighton@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

and always doing 16-bit arithmetic.

Hm, that`s five loads and stores so far, still some room :-)

(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).

> * 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.

> * 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!
--- slrn/1.0.3 (Linux)
 * Origin: news.netcologne.de (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