Re: Oops (Concertina II Going Around in Circles)

John Savard wrote:

On Wed, 08 May 2024 01:46:41 -0600, John Savard
<quadibloc@servername.invalid> wrote:

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

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!

That only answersl a part of that question - why I feel I can _get
away_ with having an ISA that is "full to the brim". But why did I let
it get that way in the first place?

Well, the reason for that is actually quite simple. Because a major
design goal of Concertina II is to offer as much as possible of the
basic operations required of a computer in instructions of the
shortest possible length.

May I suggest that sacrificing 16-bit instructions may give you the room
whereby typical applications require less space without the 16-bit insts
that with them !?!
But this begs the question::
Would your implementations perform better by executing FEWER instructions
or executing MORE instructions at a faster rate ??? The tradeoffs are
complicated and subtle. In 1986±, Mark Horowitz stated that <Stanford>
MIPS executed 1.5× as many instructions as VAX 11/780 at 6× the frequency
to achieve a 4× performance advantage.
My 66000, on the other hand is executing 1.1× as many instructions as
VAX 11/780 and has a 5% (1/20) per pipeline stage gate overhead compared to RISC-V (maybe) for a 35% performance advantage over RISC-V.
I say (maybe) because the pipeline designs I see for RISC-V use a 2 cycle
latency LD pipeline with set associative caches. This puts a lot of gates
between AGEN and LD forwarding to fit in 2 cycles. My pipelines give this
loop 3 cycles.

16-bit displacements are the norm in microprocessor instruction sets,
so I offer them. I offer base-index addressing - which microprocessors
usually don't - because I feel it's needed for using arrays. And I
have register banks of 32 registers because that's what today's RISC
machines do.

So, you are getting eaten alive by the extra bit of register specifier !!
which, then, is forcing you into extreme encoding positions--gotcha.

All of that means that the load and store instructions - particularly
when integer load and store also include load unsigned and insert -
take up 3/4 of all 32-bit instructions (approximately; one doesn't
need unsigned load and insert for the 64-bit integer type, because it
fills the register). And that's with using only 8 of the 32 registers
for the base register and the index register each.

Do not put into ISA that which compiler CANNOT use !!
Oh, wait, you have no ability to know what the compiler can use--either.

Some parts of the instruction set do have slack. Two-address
register-to-register operate instructions have a large opcode field,
so there is some room for future expansion in parts of the instruction
set.

But, basically, it takes all the available bits to offer the level of
functionality I am trying to provide with the basic 32-bit instruction
set. Since that covers the traditional functionality of a CPU -
floating-point and integer types - nothing basic is missing.

Tisk.

John Savard