Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: John Savard <quadibloc@servername.invalid>
Newsgroups: comp.arch
Subject: Oops (Concertina II Going Around in Circles)
Date: Wed, 24 Apr 2024 23:49:25 -0600
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <kipj2j5be9kuv8rn770iq6neq2cvu3s5oi@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 25 Apr 2024 07:49:27 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7cb425b3212d9c4a2716be1f4617d0fe";
	logging-data="2997584"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+rnEWtNDw5a9NQ2ab7VgRrqZyeAClAgUw="
Cancel-Lock: sha1:6KmHx1KqfQgBYfsCafkxchUrE2I=
X-Newsreader: Forte Free Agent 3.3/32.846
Bytes: 4332

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.

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...

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.

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