Re: Oops (Concertina II Going Around in Circles)

On Thu, 25 Apr 2024 16:00:14 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:

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.

This is a point I think I should address.

Why are my various iterations of Concertina II _all_, consistently,
"full to the brim"?

This is true if I compromise the basic load/store instructions, say by
limiting them to three base registers for 16-bit displacements, so I
can reserve 1/4 of the opcode space for paired 16-bit short
instructions - which was one of the most common combinations -

or if I reserve half the opcode space for two kinds of 16-bit short
instructions,

or if I don't compromise the basic load/store instructions, and only
allow 16-bit instructions with a special header.

These are the three basic variants of Concertina II that I have been
vacillating between. But whichever I choose, I use nearly all possible
opcode space, at least for basic 32-bit instructions.

That didn't worry me much for two reasons.

If I need an enormous amount of opcode space for some new kind of
instructions for some new feature...

I would still have _enormous_ amounts of opcode space available up in
the stratosphere of 64-bit instructions and longer. (In some
iterations, I did manage to use nearly all the 48-bit opcode space,
because I tried to squeeze a form of string and packed decimal
instructions there.)

But what if the new feature was so important that I needed to have
*short* instructions for the operations using that feature - 32-bit
long instructions?

Well, because of the block structure of Concertina II, which is
primarily present to support pseudo-immediates (my idea of how to
reconcile immediate values in instructions, which you've pointed out
are very valuable, with my Concertina II design goal of fully
independent and parallel decoding of every instruction in a block) and
secondarily to allow VLIW features...

I can always add one new type of header which specifies alternate
instructions with fairly low overhead... and then, at a modest cost,
even the most enormous new feature can have its own 32-bit
instructions!

John Savard