Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Why I've Dropped In
Date: Wed, 11 Jun 2025 21:17:46 +0000
Organization: Rocksolid Light
Message-ID: <b40e19dc6dca9ed8d023c3cd0e5bc193@www.novabbs.org>
References: <0c857b8347f07f3a0ca61c403d0a8711@www.novabbs.com> <dd6e28b90190e249289add75780b204a@www.novabbs.com> <ec821d1d64555055271e3b72f241d39b@www.novabbs.com> <8addb3f96901904511fc9350c43917ef@www.novabbs.com> <102b5qh$1q55a$2@dont-email.me> <48c03284118d9d68d6ecf3c11b64a76b@www.novabbs.com> <tkk2Q.1582911$%pKb.350221@fx14.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="106612"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$oLfGxKsVQEKPG/Fp.gM3gOOyCo2BaKi9P0RZku8XVvSdCrYSRTd8q

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.