@MSGID: <jwv5y3ydyqr.fsf-monnier+comp.arch@gnu.org>
497f049c
@REPLY:
<287e35a5-e78f-4ae2-bbb1-606f7bbdfe98n@googlegroups.com> fab458c7
@REPLYADDR Stefan Monnier
<monnier@iro.umontreal.ca>
@REPLYTO 2:5075/128 Stefan Monnier
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
<jwv5y3ydyqr.fsf-monnier+comp.arch@gnu.org>
1@dont-email.me><memo.20230916204926.16432A@jgd.cix.co.uk> eh2$1@dont-email.me>1@dont-email.me><287e35a5-e78f-4ae2-bbb1-606f7bbdfe98n@googlegroups
.com>
@TZUTC: -0400
@PID: Gnus/5.13 (Gnus v5.13)
@TID: FIDOGATE-5.12-ge4e8b94
> there are a few solutions i have encountered (i would be
> interested to hear of more)
> * "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
> to some extent, i`d be interested to hear peoples` thoughts on
> how to overcome some of those problems.

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,
"prefixing" is just another name for variable-length instructions, and
what is considered as "opcode" vs "immediate operand" within an
instruction is largely philosophical).

As you point out, part of the complexity doesn`t come from
instruction encoding, really, but from the actual desired semantics.

So in terms of instruction encoding, the main issues would be:

A. Code size.
B. Not preventing the core from working at full speed.
C. The cost of decoding.

(C) can only bite when backward compatibility forces inconvenient
encodings, but even the amd64 architecture seems to do fine, so it
doesn`t seem to be a serious issue.

I think (B) is never an unsolvable problem.  E.g. CSR-based solutions
sometimes require pipeline drainage, but that`s usually solvable
without changing the encoding by passing the CSR through the pipeline.
But maybe tagged registers could be problematic because you end up
getting this info too late, in the execution rather than in the decode?

So I`d guess it`s really mostly a code-size issue (beside the semantic
issues when you want to make it so old code can work with new sizes, of
course, but IIUC you were talking about the scalar case where this seems
to be too problematic to even contemplate).

My gut tells me that in terms of code size, tagged registers should be
the better choice.  But I don`t know of any actual efforts to try and
confirm it experimentally.


        Stefan
--- Gnus/5.13 (Gnus v5.13)
 * Origin: A noiseless patient Spider (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