Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
Newsgroups: comp.arch
Subject: Re: Instruction Parcel Size
Date: Sat, 8 Mar 2025 23:14:49 -0500
Organization: A noiseless patient Spider
Lines: 127
Message-ID: <vqj4jr$iomq$1@dont-email.me>
References: <vnglop$33lk0$1@dont-email.me> <vqiq34$db80$1@dont-email.me>
 <895b2a1ff3894c671bdf9343ca98eaf8@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 09 Mar 2025 05:14:52 +0100 (CET)
Injection-Info: dont-email.me; posting-host="082b99176ec5d10cb3c323227c66cb20";
	logging-data="615130"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19AznEMRDhU2g9SibnBx9PoLsXK+oD3WF0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:0ho4uQ6FVtnf0g4Qa0nOo+SAMtQ=
In-Reply-To: <895b2a1ff3894c671bdf9343ca98eaf8@www.novabbs.org>
Content-Language: en-US
Bytes: 6401

On 2025-03-08 8:43 p.m., MitchAlsup1 wrote:
> On Sun, 9 Mar 2025 1:15:14 +0000, Robert Finch wrote:
> 
>> Recently started Q+2 development.
>>
>> Trying to get code density closer to something like the 68k or VAX.
>> Sounds like My66000 also has good code density using 32-bit parcels. If
>> 32-bit parcels work well, I have thought to try 24-bit parcels.
> 
> Ok, go all Quadriblock on me .... see if I care !
> 
>> Decided to stay away from other odd sized parcels which create
>> addressing issues. Currently 3 sizes of instructions: 24 / 48 and
>> 96-bit. The 96-bit instructions are usually for encoding a 64-bit
>> immediate. The first two opcode bits determine the size. 00=24 bit,
>> 01=48 bit, 10=96 bit, 11 (reserved)
> 
> You might find 72-bit instructions useful in carrying a 32-bit
> immediate.

Yeah, I was sure I wanted to support 23-bit immediates (in the 48-bit 
format) and 64-bit immediates (96-bit format). But had not decided on 
supporting other sizes perhaps 128-bit immediates.A 72-bit format would 
allow over 40 bits for immediates.
> 
>> ADD, AND, OR, EOR, CMP have 24-bit instruction forms:
>> iiiii-aaaaa-ttttt-ooooooo-00    <- immediate
>> bbbbb-aaaaa-ttttt-ooooooo-00 <- register
>> 24-bit instruction forms allow using only the first 32 registers.
> 
> A 6-bit OpCode might let 1 more bit into immediate, or similar
> sign control over register operand. Remember, this is the highly
> used OpCode category. So, we have 32 Imm5(6) OpCodes.

Yeah, I have been scratching my head over how to free up another opcode 
bit. But the decode is simple. ooooooo always refers to the same opcode 
even if longer/shorter forms do not make sense.
There are only about 23 opcodes free out of 128. That is 105 
instructions. Sometimes the opcode bits are used to determine the 
precision of the operation. So, ooooooo is sometimes ooooopp. The data 
type is also sometimes encoded in ooooooo (ooooTTT).

> 
>> ADD, AND, OR, EOR, CMP 48-bit instruction forms:
>> fffffff-oooo-ccccccc-bbbbbbb-aaaaaaa-ttttttt-ooooooo-01
>> 48-bit instruction forms support a sign control bit on the register
>> spec, along with 64 registers.
> 
> It really looks like you are forming 2×24-bit instructions into
> (wait for it) 2×24-bit containers. Sign control on operands is
> useful 5-register operands may not be so. I am not against this
> format, but I think you are wasting a lot of entropy here.

It is almost two instructions, but there is only a single target 
register. That way in some cases up to 8 ops per clock can be processed 
instead of just 4. The compiler does not do a good job of making use of 
the dual ops yet.
There are only four register operands. fffffff is a function code. oooo
is a second operation between the result of (a op b) and c. The seven 
bit register spec includes sign control (there are only 64 GPRs). 
aaaaaaa is really saaaaaa.
Register ops do not needs anything beyond 48 bits so there is a lot 
wasted as the length field could also be 10 or 11 both of which are not 
used.

> 
>> LOAD / STORE word size have 24-bit forms
>> ddddd-aaaaa-ttttt-ooooooo-00
> 
> Where do you get stack and structure displacements ?? This is one
> place My 66000 ISA is significantly better than RISC-V.
ddddd is the displacement which is multiplied by 8 (word size).
> 
>> Conditional Branches (compare and branch) are 48-bit
>> pp-R-TTTTTTTTTTTTTTTTTTT-aaaaaa-bbbbbb-A-ffff-ooooooo-01
> 
> Careful choice of oooooo may allow it to contain the condition
> in the ffff field expanding the displacement to 25-effective
> bits.
There is a whole row (8 opcodes) in the opcode table dedicated to the 
branch data type. The data type could be integer, unsigned integer, 
float, decimal float, posit or capability.

ooooooo = 0101TTT (the same breakdown is used for loads and stores).
TTT
000 - unsigned
001 - signed
010 - float
011 - decimal float
100 - posit
101 - capability

1000TTT = loads
1001TTT = stores

It may be possible to gain a bit. I did not think it was critical. There 
are 19 displacement bits. 'A' indicates relative or absolute addressing 
for the target. Only relative addressing is really needed so a bit could 
be gained there as well. 'R' indicates to use register 'c' as the 
target, another bit that may not be needed. But it allows branch to 
register / conditional return.

> 
>> With load / store / basic arithmetic as 24-bit and 48-bit
>> compare-and-branch a good portion of instructions should occupy the same
>> or less storage space than a 32-bit ISA.
> 
> Questions remain wrt floating point constants and large integer
> constants.

iiiiiiiiiiiiiiiiiiiiiii-pp-saaaaaa-stttttt-ooooooo-01    <- immediate
iii--65 bits--iii-pp-saaaaaa-stttttt-ooooooo-10    <- immediate

Immediate postfixes may override register specs. Useful for encoding 
float constants too.

iiiiiiiiiiiii-SS-1111100-00 (18-bit immediate postfix - 24 bit insn
iii--36 bits--iii-SS-1111100-01 (41-bit immediate postfix - 48 bit insn
iii--79 bits--iii-SS-1111100-10 (89-bit immediate postfix - 96 bit insn

SS selects which register spec to override.

> 
>> I have not written the assembler yet, so nothing to measure.
> 
> The data will be interesting.