Re: Why I've Dropped In

On Wed, 11 Jun 2025 18:56:56 +0000, EricP wrote:

quadibloc wrote:

On Wed, 11 Jun 2025 5:56:33 +0000, Thomas Koenig wrote:
>

Having different classes of base and index registers is very
un-RISCy, and not generally a good idea.  General purpose registers
is one of the great things that the /360 got right, as the VAX
later did, and the 68000 didn't.

>
This is true.
>
However, if the memory reference instructions had 5 bits for the
destination register, 5 bits for the index register, 5 bits for the base
register, and 16 bits for the displacement, then there would only be one
bit left for the opcode.

>
Plus 3 bits for the load/store operand type & size,
plus 2 or 3 bits for the index scaling (I use 3).
It all won't fit into a 32-bit fixed length instruction.
>
A separate LEA Load Effective Address instruction to calculate
rDest=[rBase+rIndex<<scale+offset13] indexed addresses is an
alternative.

For my part, LEA is the other form of LDD (since the signed/unsigned
notation is unused as there is no register distinction between signed
64-bit LD and an unsigned 64-bit LD.

Then rDest is used as a base in the LD or ST.
>
One or two constant prefix instruction(s) I mentioned before
(6 bit opcode, 26 bit constant) could extend the immediate value
to imm26<<13+imm13 = sign extended 39 bits,
or imm26<<39+imm26<<13+imm13 = 65 bits (truncated to 64).

My Mantra is to never use instructions to paste constants together.

As I required 5 bits for the opcode to allow both loads and stores for
several sizes each of integer and floating-point operands, I had to save
bits somewhere.

>
The problem is that there are 7 integer data types,
signed and unsigned (zero extended) 1, 2, 4 and 8 bytes,

There are 8 if you want to detect overflow differently between
signed and unsigned 64-bit values) 99.44% of programs don't care.
Which is why one "cooperates" with signedness in LDs, ignores
signedness in STs, and does exception detection only in calculation
instructions.

and potentially 5 float, fp8, fp16, fp32, fp64, fp128.
There might also be special (non-ieee) float formats for AI support.
Plus one might also want some register pair operations
(eg load a complex fp32 value into a pair of fp registers,
store a pair of integer registers as a single (atomic) int128).

Store a pair of registers into two different memory locations
atomically is more powerful.

So 3 bits for the data type for loads and stores,

3-bits for LDs, 2-bits for STs.

                                                  which if you
put that in the opcode field uses up almost all your opcodes.

With a Major OpCode size of 6-bits, the LDs + STs with DISP16
uses 3/8ths of the OpCode space, a far cry from "almost all";
but this is under the guise of a machine where GPRs and FPRs
coexist in the same file.
By using 1 Major OpCode to access another 6-bit encoding space
(called XOP1) one then has another 6-bit encoding space where
the typical LDs and STs consume 3/8ths leaving room to encode
indexing, scaling, locking behavior, and ST #value,[address]
which then avoids constant pasting instructions and waste of
registers.
I Also snuck in CALX--which is simply a LDD IP,[address] saving
either the LDD or the JMP depending on how you look at it.

So you take the data types out of the disp16 field and now your
offset range is 13 bits +/- 4kB.

The S.E.L. machines that did this only supported signed partial
word LDs (saving a bit)--probably not the best choice in todays
analysis and language uses.
Secondarily, one had LDbyte and LDsized instruction variants.

And a constant prefix instruction can extend the disp13 field
to 26+13=39 or 26+26+13=65(64) bits.