@MSGID:
<a1ffb79c-ce7e-459d-a254-effed976b6aan@googlegroups.com> 325f0cc6
@REPLY: 1@newsreader4.netcologne.de>
c9cb90bf
@REPLYADDR luke.l...@gmail.com
<luke.leighton@gmail.com>
@REPLYTO 2:5075/128 luke.l...@gmail.com
@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:
<a1ffb79c-ce7e-459d-a254-effed976b6aan@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
On Saturday, September 30, 2023 at 10:41:16 PM UTC+1, Thomas Koenig wrote:
> luke.l...@gmail.com <luke.l...@gmail.com> schrieb:

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

at which point the processor clock rate must be doubled
(making it commercially unviable due to power consumption,
e.g. outside of USB2 bus ampage) or the amount of silicon
doubled (same result).

the example I gave (AndesStar Audio DSP) is at the 8051 level
so 16 bit registers, 2 channel audio, $0.25 or less, 8 MHz clock.
doubling to 16 MHz in 180 nm because the opportunity is lost to use
the other 8 bits for doing left-right audio in the same clock rather
than needing 2x the time, this is the whole reason why the
seduction of SIMD even exists.
 

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

Left channel audio in lower half, right channel in upper,
you want to balance the left channel against the right
and yet detect clipping.  But then you want to do the
opposite way as well.

> So, another addition...

to which you then still need all the other options,
Hilo lohi 8/16 saturate etc and you might as well just consider
it to be another dimension of the Cartesian Product of options
on "add"

On Saturday, September 30, 2023 at 10:59:56 PM UTC+1, MitchAlsup wrote:

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

and if you do not need a particular augmentation you do not
add the prefix to request it. thus the ISA stream remains both
RISC and compact for the majority of programs.

One scheme I came up with 4 years ago was a *third* L1 cache,
containing highly compact "augmentations" rather than polluting
the main L1 I-Cache with "prefixing". where the main ISA might
be 32-bit the "augmentation" L1 cache might only be 16 bit.
Whereas if the prefixes had to be embedded in the 32 bit ISA
itself they take up valuable 32-bit RISC opcode space and you
are back to square one.

It is a trade-off basically.

L.

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