@MSGID:
<041e3c2e-3243-41d9-8cd0-14554e5414e5n@googlegroups.com> df839255
@REPLY:
<72b6255a-e9b5-4549-b243-49ab8c49b064n@googlegroups.com> 7a5e0ac7
@REPLYADDR robf...@gmail.com <robfi680@gmail.com>
@REPLYTO 2:5075/128 robf...@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>
@RFC-Message-ID:
<041e3c2e-3243-41d9-8cd0-14554e5414e5n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
On Friday, September 29, 2023 at 9:01:18 PM UTC-4, MitchAlsup wrote:
> On Friday, September 29, 2023 at 7:37:30 PM UTC-5, Scott Lurndal wrote: 
> > MitchAlsup <Mitch...@aol.com> writes: 
 > > >On Monday, September 25, 2023 at 11:25:30=E2=80=AFAM UTC-5,
Stefan Monnier = 
> > >wrote: 
> > >> > there are a few solutions i have encountered (i would be=20 
> > >> > interested to hear of more)=20 
> > >> > * "tagged" registers. ForwardCom actually has tags already 
> > >> [...] 
> > >> > * "Control Status Registers". Power ISA has "bit-accuracy" 
> > >> [...] 
> > >> > * "Prefixing". a RISC-uniform Prefix instruction (similar to 
> > >> [...] 
> > >> > fascinatingly, though, they *do* still impact the Decoder Phase=20 
> > >> > to some extent, i`d be interested to hear peoples` thoughts on=20 
> > >> > how to overcome some of those problems. 
> > >< 
> > >> I think you can`t get a good answer before clarifying what it is that=20 
> > >> you consider as the problem in "opcode proliferation" (after all,=20 
> > >< 
> > >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.) 
> < 
> > That`s a bit misleading, as you`re counting individual instruction 
> > words (opcode + all variations of source and destination register(s)). 
> <
> Not source and destination--but operand size and register size. 
> < 
> Register sizes {64, 128, 256, 512} 
> Operand size {8, 16, 32, 64} 
 > Calculation {int{+, -, x, /, &, |, ^,}, FP{+, -, x, /,},
swizzles, gather, scatter, ...} 
> ..... 
 > Sooner or later it all adds up to shiploads of instructions. And
the instructions 
> are not backwards compatible,... 
> < 
> And in comparison:: I got almost all of that capability with 2 instructions 
> that guarantees forward and backwards compatibility, and scales with 
> machine resources. 
> < 
> 2 versus 1300 :: Which one is really RISC ??

Those shiploads of instructions also require more bits to encode. Using the idea
there would be shiploads of instructions leads to wide instructions - 40-bits.
Otherwise, one ends up with piles of instruction prefixes. Operands could be
 128-bits too and register size might not stop at 512 bits, so
there are potentially even
 more instructions on the way. It requires a good nomenclature to
represent all the
instructions. Is there a nomenclature project somewhere?

 I keep musing over the idea of using a register file tagged with
the data type to try
 and reduce the instructions, but have discarded it a couple of
times. I get bogged
 down implementing the rules for the target data type. For example,
if an address is
added to an integer the result should be an address. Subtract two addresses and
 the result should be an integer. Compare-and-branch causes an
exception if the two
data types compared are not the same. Using tagged registers has its own set of
 complexities and I am not sure the extra logic would be worth it.
I think it may be
easier and less logic (faster) to have the compiler manage all the instructions.
These days most things are done in HLL so how valuable is having a compact
assembler language instruction set?

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