Sujet : Re: Oops (Concertina II Going Around in Circles)
De : quadibloc (at) *nospam* servername.invalid (John Savard)
Groupes : comp.archDate : 05. May 2024, 07:57:44
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <moae3jhjbcqarvfpkcorta8av7g896rm75@4ax.com>
References : 1
User-Agent : Forte Free Agent 3.3/32.846
On Wed, 24 Apr 2024 23:49:25 -0600, John Savard
<
quadibloc@servername.invalid> wrote:
So this is unlikely to satisfy me for very long either.
And, given that, I've thought long and hard about what really is
needed.
The main opcode space for 32-bit instructions is now divided as
follows:
3/4 for uncompromised memory-reference instructions.
3/16 for uncompromised register-to-register operate instructions.
1/16 for the header required for variable-length instructions.
The variable-length instructions will allow, with 32 bits of overhead
per block, arbitrary mixing of 17-bit short instructions (the extra
bit goes into the two-bit prefix field in the header) and 32-bit
instructions - and longer instructions.
00 and 01 indicate 17-bit instructions starting with 0 and 1
respectively.
10 indicates a 16-bit extent that contains the start of an instruction
32 bits long or longer.
11 indicates a 16-bit extent that is not the start of an instruction.
In addition to the remaining parts of an instruction, space reserved
for pseudo-immediates can be indicated by this.
There will be three forms of header.
One just has a three-bit field indicating the number of 32-bit
instruction slots reserved for pseudo-immediates, in a restricted
register-to-register operate instruction squeezed into an odd bit of
leftover opcode space.
The other will provide VLIW functionality for code consisting only of
32-bit instructions: predication, and explicit indication of
parallelism.
The final one is 1111 that allows 17-bit instructions, 48, 64, 80, and
96 bit instructions, and their arbitrary mixing.
This has the advantage of providing all the functionality I'm looking
for - a large, extensible instruction set, compactness of code through
16-bit instructions that don't restict which registers can be used,
and memory-reference instructions that make full use of a 32-bit
length being the only version of those instructions, instead of having
to include both a cut-down form and a full-form, the latter only
accessible with a header.
Finally, this seems to be something that I will be forced to admit
that further restructurings won't be able to improve upon - this will
be the best way to squeeze everything I want into the 8-bit byte and
the 32-bit word.
John Savard