Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Oops (Concertina II Going Around in Circles)
Date: Thu, 25 Apr 2024 14:21:53 -0500
Organization: A noiseless patient Spider
Lines: 120
Message-ID: <v0eagk$35tj4$1@dont-email.me>
References: <kipj2j5be9kuv8rn770iq6neq2cvu3s5oi@4ax.com>
 <b936220e0d198db43b18e58007401f42@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 25 Apr 2024 21:21:56 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="cbd124d9ce6387535df909319fb3f85d";
	logging-data="3339876"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19eDdm8N8qsKQS12S95kQCvY95M3kKE4GY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:EbwJHV02+Nn9JrqZzBiLmr8x52c=
Content-Language: en-US
In-Reply-To: <b936220e0d198db43b18e58007401f42@www.novabbs.org>
Bytes: 6348

On 4/25/2024 11:00 AM, MitchAlsup1 wrote:
> John Savard wrote:
> 
>> I keep changing the basic design of Concertina II, instead of going
>> forward and completing the task of fleshing it out.
> 
>> The reason for that... has been obvious all along. None of my attempts
>> have satisfied me. I had goals for the architecture, some of which
>> weren't being met by each iteration. So I kept going back and forth
>> between compromising one set of goals, or compromising another set of
>> goals.
> 
>> If I could make up my mind on what was most important to me, perhaps I
>> could stop somewhere.
> 
>> Looking back at the various iterations, I did see that two goals were
>> very important to me.
> 
>> I wanted to be able to have 16-bit instructions, at least in pairs
>> within a 32-bit instruction slot, available without the overhead of a
>> block header, in the basic instruction set. For this, I need to
>> reserve 1/4 of the opcode space.
> 
>> Also, I wanted to have the basic load-store memory-reference
>> instructions be able to use 16-bit displacements, have a three-bit
>> index register field and a three-bit base register field, and be able
>> to use all 32 registers in a normal register bank as destinations.
>> This takes 3/4 of the opcode space.
> 
>> As 3/4 plus 1/4 is _not_ greater than 1, having both of these things
>> in a design simultaneously is not impossible.
> 
> Not impossible, sure: but reserving so much for so little is gonna hurt.
> 
>> And I've found some tiny scraps of opcode space left (in the 3/4 part;
>> flexible auto-increment with an odd index register, since only even
>> index registers are allowed in that mode) which are barely enough...
> 
> In my opinion, your first cut at an ISA encoding should not consume more 
> than ½ of the available encodings. Concer-tina-tanic is already full to
> the brim and you are still just fleshing it out.
> 

Yeah, this has also been a problem with most of my attempts to design a 
fully orthogonal encoding with 16 ans 32 bit instructions, predication + 
bundling, and 64 GPRs.

Encoding space quickly runs out (often well before I get to the 
feature-set of my current ISA design), so at least one of these needs to 
be cut.

But, even then, hard to come up with much "obviously better" than what I 
have already. Like, maybe I could have less dog chew in the register and 
immediate fields, but ...


And, there is seemingly no way to fit all the features of both Baseline 
and XG2 into a 32-bit instruction word. And, in this case, it is a 
tradeoff between better code density (Baseline) and higher performance 
(XG2).

But, was at least able to twiddle the compiler enough that at least XG2 
is "mostly not losing" in terms of code-density if compared with RV64G.



Have also seemingly made some gains in terms of Software Quake 
performance, as it is now (mostly) able to run in the upper single 
digits at 50MHz (~ 6-8 fps), except for the cases where it is still 
stuck at 3 or 4.

TBD what might happen if I tried reverting to the original 8bpp SW 
renderer, rather than the modified 16-bpp hi-color version I am using.


>> for two-address register to register operate instructions, _and_ for a
>> block header.
> 
>> The block header, while rudimentary, would be enough to allow...
> 
>> indicating some instruction slots as containing instructions from a
>> secondary instruction set, so as to allow things like three-address
>> operate instructions, multiple-register load and store instructions,
> 
>> and also allowing pseudo-immediates...
> 
>> and instructions longer than 32 bits.
> 
>> I have two unused opcodes in the load/store memory reference
>> instructions, so I can use one of them for jump to subroutine (offset
>> in the index register field, return address register in the
>> destination register field) - and one for conditional jump. Since the
>> condition code can go in the destinatin register field, and it only
>> needs four bits, not five... I can also have a Load Address
>> instruction, with the limitation that only registers 0-7 and 24-31 can
>> be used as destinations (the ones used as index registers and the
>> usual base registers).
> 
>> However, requiring the block header mechanism even for load and store
>> multiple registers, basic to subroutine calls, means that the basic
>> instruction set is... only _barely_ a complete one.
> 
>> So this is unlikely to satisfy me for very long either.
> 
> Sigh....
> 
>> One other possibility: stick with the current design - 1/4 of the
>> opcode space for 16-bit instructions and 1/4 of the opcode space for
>> instructions longer than 32 bits, so as to reduce their overhead and
>> possibly allow the mechanism to also be used for prefixing
>> instructions (not needed, though, if I decide to return to having
>> block headers in a less vestigial form)...
> 
>> I would have to squeeze the "rest" of the instruction set a bit more
>> if I switched from aligned-only load and store instructions to going
>> to using only four base registers for them (the least painful of the
>> restrictions I've considered so far), but it should be doable.
> 
>> John Savard