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

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.

> 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

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.

Basically, I think that the reasonable length that a computer
instruction should occupy is that which a similar instruction occupied
on the IBM System/360 - which, in its day, was not regarded highly for
its code density.

However, I have banks of 32 registers instead of 16, and 16-bit
displacements instead of 12 bits. Having only load and store
memory-reference instructions, of course, helps to make up for this.

That's why I can only use 8 of the 32 registers as base registers and
as index registers, too.

For wanting the impossible, of course I basically deserve what I get.
If I _could_ manaage to pull it off, of course, the result would be of
some practical use; an instruction set that's plain, clear, and simple
(at least when compared to monstrosities like Itanium and x86) and
which is parsimonious in its use of memory is of some value.

While I'm rearranging the deck chairs, maybe I'll come up with an
original idea.

John Savard

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

On Thu, 25 Apr 2024 12:41:23 -0600, John Savard
<quadibloc@servername.invalid> wrote:

>While I'm rearranging the deck chairs, maybe I'll come up with an
>original idea.

This latest proposal, which does differ from my previous attempts,
does have _one_ advantage.

In this case, as in the previous attempts, I will need to use the
block header to indicate that some 32-bit instruction slots contain
32-bit instructions in an "alternate" format.

When the memory-reference instructions in the main format were
compromised, that alternate format included uncompromised
memory-reference instructions. So the extended instruction set,
normal plus alternate, included the normal instructions twice.

Here, I avoid that. Of course, though, the main format includes a
severely compromised version of the register-to-register operate
instructions. The alternate format would include the full version of
those.

Same thing, right?

Well, not really - because the compromised version of
register-to-register operate instructions contains only *one*
instruction format. So there _is_ less duplication and waste, the
instruction decode unit isn't set up to decode both the full version
of the operate instructions and a second compromised format which is
equally complex, but just has one bit trimmed off everywhere.

John Savard

On Wed, 24 Apr 2024 23:49:25 -0600, John Savard
<quadibloc@servername.invalid> wrote:

>So this is unlikely to satisfy me for very long either.

And, given that, I've thought long and hard about what really is
needed.

The main opcode space for 32-bit instructions is now divided as
follows:

3/4 for uncompromised memory-reference instructions.

3/16 for uncompromised register-to-register operate instructions.

1/16 for the header required for variable-length instructions.

The variable-length instructions will allow, with 32 bits of overhead
per block, arbitrary mixing of 17-bit short instructions (the extra
bit goes into the two-bit prefix field in the header) and 32-bit
instructions - and longer instructions.

00 and 01 indicate 17-bit instructions starting with 0 and 1
respectively.

10 indicates a 16-bit extent that contains the start of an instruction
32 bits long or longer.

11 indicates a 16-bit extent that is not the start of an instruction.
In addition to the remaining parts of an instruction, space reserved
for pseudo-immediates can be indicated by this.

There will be three forms of header.

One just has a three-bit field indicating the number of 32-bit
instruction slots reserved for pseudo-immediates, in a restricted
register-to-register operate instruction squeezed into an odd bit of
leftover opcode space.

The other will provide VLIW functionality for code consisting only of
32-bit instructions: predication, and explicit indication of
parallelism.

The final one is 1111 that allows 17-bit instructions, 48, 64, 80, and
96 bit instructions, and their arbitrary mixing.

This has the advantage of providing all the functionality I'm looking
for - a large, extensible instruction set, compactness of code through
16-bit instructions that don't restict which registers can be used,
and memory-reference instructions that make full use of a 32-bit
length being the only version of those instructions, instead of having
to include both a cut-down form and a full-form, the latter only
accessible with a header.

Finally, this seems to be something that I will be forced to admit
that further restructurings won't be able to improve upon - this will
be the best way to squeeze everything I want into the 8-bit byte and
the 32-bit word.

John Savard

On Sun, 05 May 2024 00:57:44 -0600, John Savard
<quadibloc@servername.invalid> wrote:

>The final one is 1111 that allows 17-bit instructions, 48, 64, 80, and
>96 bit instructions, and their arbitrary mixing.

However, one thing I wanted to do was have the 48-bit and longer
instructions also available outside of the variable-length format.

Previously, I had done this by having a second format of long
instructions. I wanted to avoid that, this time.

I came up with an idea. Just as 1111 _after_ the header in
variable-length mode was used to indicate long instructions, for other
modes, let 1111 after the header indicate each of two instruction
slots in which three 18-bit units from variable-length are
encapsulated. So a 48-bit instruction, taking up 64 bits, could be
placed in any of the other modes.

But because that code conflicts with the header, these things aren't
first-class citizens! I tried freeing up 1110 as well, but that was
clearly not going to work acceptably. So I took other measures that
only partly addressed that issue but consumed far less opcode space.

John Savard

On Sun, 05 May 2024 00:57:44 -0600, John Savard
<quadibloc@servername.invalid> wrote:

>The main opcode space for 32-bit instructions is now divided as
>follows:
>
>3/4 for uncompromised memory-reference instructions.
>
>3/16 for uncompromised register-to-register operate instructions.
>
>1/16 for the header required for variable-length instructions.

This is not quite right.

3/4 for uncompromised basic memory-reference instructions.

1/8 for other memory-reference instructions.

1/16 for uncompromised register-to-register operate instructions.

1/16 for the header required for variable-length instructions.

John Savard

John Savard wrote:

> On Sun, 05 May 2024 00:57:44 -0600, John Savard
> <quadibloc@servername.invalid> wrote:

>>The main opcode space for 32-bit instructions is now divided as
>>follows:
>>
>>3/4 for uncompromised memory-reference instructions.
>>
>>3/16 for uncompromised register-to-register operate instructions.
>>
>>1/16 for the header required for variable-length instructions.

> This is not quite right.

> 3/4 for uncompromised basic memory-reference instructions.

> 1/8 for other memory-reference instructions.

> 1/16 for uncompromised register-to-register operate instructions.

> 1/16 for the header required for variable-length instructions.

In comparison::

1/8 for [Rbase+@disp16]
1/8 for Rd = Rs1 OP imm16
1/64 for [Rbase,Ri<<scale,#disp]
1/64 for Rd = Rs1 OP Rs2
1/64 for Rd = 3OP( Rs1,Rs2,Rs3)
1/64 for Rd = 1OP( Rs1 )
1/64 for PRED
1/64 for <w:o>
1/8 for branching

> John Savard

On Mon, 06 May 2024 11:06:44 -0600, John Savard
<quadibloc@servername.invalid> wrote:

>But because that code conflicts with the header, these things aren't
>first-class citizens! I tried freeing up 1110 as well, but that was
>clearly not going to work acceptably. So I took other measures that
>only partly addressed that issue but consumed far less opcode space.

Although I had limited long vector and short vector operate
instructions in the basic 32 bit instruction set, I didn't have long
vector and short vector load and store instructions of any kind. Do I
needed to add them in some form in order for the basic 32 bit
instruction set to be complete.

However, if I were to include a 6-bit length field in the long vector
load and store instructions, once again I would have had to free up
1/16 of the opcode space. Instead of completely doing without the
ability to load and store any but full-length vectors, I eventually
was able to include a two-bit length register field to the long vector
load and store instructions.

So this new instruction set has survived another challenge.

John Savard

On Tue, 07 May 2024 02:21:54 -0600, John Savard
<quadibloc@servername.invalid> wrote:

>On Mon, 06 May 2024 11:06:44 -0600, John Savard
><quadibloc@servername.invalid> wrote:
>
>>But because that code conflicts with the header, these things aren't
>>first-class citizens! I tried freeing up 1110 as well, but that was
>>clearly not going to work acceptably. So I took other measures that
>>only partly addressed that issue but consumed far less opcode space.
>
>Although I had limited long vector and short vector operate
>instructions in the basic 32 bit instruction set, I didn't have long
>vector and short vector load and store instructions of any kind. Do I
>needed to add them in some form in order for the basic 32 bit
>instruction set to be complete.
>
>However, if I were to include a 6-bit length field in the long vector
>load and store instructions, once again I would have had to free up
>1/16 of the opcode space. Instead of completely doing without the
>ability to load and store any but full-length vectors, I eventually
>was able to include a two-bit length register field to the long vector
>load and store instructions.
>
>So this new instruction set has survived another challenge.

And I've vinally gotten around, therefore, to updating my web site to
present this latest incarnation as Concertina II.

John Savard

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

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.

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.

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.

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.

John Savard

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

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

And, naturally, after saying this, I had to go and prove it was
possible by revising the ISA to add one alternate set of 32-bit
instructions. Two more such sets are reserved for future expansion,
however.

John Savard

John Savard wrote:

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

This should hint that you are long down the dark alley.

> That didn't worry me much for two reasons.

Perhaps you feel save down the dark alley....

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

So, why do you need a header AT ALL !!

{Notice that I get a full functional ISA where the instruction specifier
is always 32-bits and I still have room for constants and for extensions.}

If your bail out position is:: "some instructions can be 64-bits" --
S T A R T with that as an assumption !!

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

G A S P ........why do I even try.....

> 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

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

On Wed, 8 May 2024 21:59:54 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:

>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 !?!

Your suggestions are always welcome, given your great breadth of
knowledge.

My latest "extreme encoding position" means that 16-bit instructinos
are now relegated to a secondary instruction format that must be
indicated by a header. However, now they're 17 bits long instead of 15
bits long, so they can operate on any two registers in a 32-register
bank.

Having 14 instructions in a block instead of 8 instructions normally
lets me do more. I know that in your MY 66000 architecture, the
instructions have extra functionality that lets you combine things
like negation and increment with an operation. While I certainly could
try to add such a feature to my architecture - in fact, I did try that
in one Concertina II iteration - I'm afraid that, not having your
knowledge, I wouldn't be able to do it in a way that resulted in any
significant savings in the number of instructions required for a
program.

And if I tried to add flexibility, I'd end up with an instruction set
that looked like that of the VAX 11/780, which is not a direction to
go in if performance is a concern.

On Wed, 8 May 2024 21:46:37 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:

>So, why do you need a header AT ALL !!

Assuming I don't want to ever allow the circuits of my computer to try
decoding an instruction that turns out later to be data (unless the
programmer has made an error, in which case the penalty of the program
being aborted is no problem)...

and I want the computer to be able to decode all the instructions in a
block in parallel, as a way to improve performance,

then I need a block header to say 'here are the instructions to
decode' IF I don't want to be absolutely limited to all instructions
having the same length.

While I could still have a pair of 16-bit instructions in a 32-bit
word, without headers I couldn't have immediates (at least not of most
lengths), or other instructions longer than 32 bits.

And headers let me add instruction predication, which is also good, as
branches do cause difficulties which predication partly avoids.
(There's still a dependency on what is being predicated upon.)

The header facilitates fast decoding of a flexible instruction set,
and allows VLIW features allowing the ISA to be used for embedded
processors.

John Savard

John Savard wrote:

> On Wed, 8 May 2024 21:46:37 +0000, mitchalsup@aol.com (MitchAlsup1)
> wrote:

>>So, why do you need a header AT ALL !!

> Assuming I don't want to ever allow the circuits of my computer to try
> decoding an instruction that turns out later to be data (unless the
> programmer has made an error, in which case the penalty of the program
> being aborted is no problem)...

> and I want the computer to be able to decode all the instructions in a
> block in parallel, as a way to improve performance,

What makes you think My 66000 ISA cannot be decoded in parallel ??
Over the last year I have illustrated how up to 16 instructions,
each variable length from 1..5 words, can be decoded in parallel.

First you select a suitable buffer which presents instructions to be
decoded. A 6-wide machine will be using 16 words.

Each word (320-gates of flip flops) has a 40-gate size decoder,
and this size is used to select its successor.

The first instruction starts at IP, the next is selected from the
decode of the first instructions (4 gates of delay). Here after,
the selection of the second instruction selects instructions 3 and
4. Next we select instructions 5 through 8, then 9 through 16.
8 total gates of logic and several gates of fan-out buffering.

I happen to call this parse--instructions are parsed into individual
starting points. and up to 16 instructions are presented to 16
instruction decoders. Each of these decoders decodes the entire ISA.
{Although there are ways to route instructions to more specialized
decoders if desired.}}

You are using a header, I am using logic.

By using logic, there is no waste of bits in the instruction encoding.

> then I need a block header to say 'here are the instructions to
> decode' IF I don't want to be absolutely limited to all instructions
> having the same length.

Seems like a horrible plan going forward with your goals in mind.

> While I could still have a pair of 16-bit instructions in a 32-bit
> word, without headers I couldn't have immediates (at least not of most
> lengths), or other instructions longer than 32 bits.

> And headers let me add instruction predication, which is also good, as
> branches do cause difficulties which predication partly avoids.
> (There's still a dependency on what is being predicated upon.)

I added predication without any such need.

> The header facilitates fast decoding of a flexible instruction set,
> and allows VLIW features allowing the ISA to be used for embedded
> processors.

The header allows subtracting 1 stage from the 12+ stage k-wide pipeline,
AND is causing all sorts of "other issues" to remain present.

> John Savard

On Wed, 8 May 2024 21:46:37 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:
>John Savard wrote:

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

>G A S P ........why do I even try.....

I'm not sure why what I said _there_ was so shocking.

But, yes, I do freely admit that Concertina II is _not_ an ISA that
"makes sense" from your point of view... or, indeed, the point of view
of many other people who value simplicity and elegance in a computer
architecture.

Instead, right from the start, it gives the appearance of having
accumulated the kind of cruft that usually is acquired though decades
of maintaining backwards compatibility.

Still, I know that what I'm leading up to is shocking.

The ISA looks - at first glance - like a plain old 32-bit RISC
architecture. With a few little peculiarities... base-index
addressing, like the 360, but not like any RISC architecture, for
example.

And then people notice the headers.

Code is divided into 256-bit blocks, so that instructions can have
"pseudo-immediates"; these values can be stacked at the end of a block
so that they're all aligned, and they don't cause the instructions
themselves to vary in length, so decoding is simple.

Could that be regarded as tolerable?

And the headers also allow... explicit indication of when instructions
can execute in parallel, and instruction predication. Oh, so it's
VLIW, too?

And then they notice the killer. Perhaps they, too, will "gasp" in
shock.

There's also a header type that allows code where 16, 32, 48, 64...
bit instructions can be combined in any order, for tracitional
CISC-like code with a variable instruction size. But there's a 12.5%
overhead penalty so that fast parallel decoding remains available.

But that header does something else.

It changes the instruction stream from being composed of 32-bit words
to one composed of 36-bit words, divided into 18-bit halfwords.

And if that isn't enough, the last two header types let you switch to
38-bit words composed of two 19-bit halfwords. *That's* what I do to
add a bunch of extra 32-bit instructions to the ISA, if some new
feature is so important that I don't want the instructions that deal
with it to have to be 48 bits long at least.

And, yes, I can indeed understand why you might gasp in horror at that
stage. But you said I was having problems running out of opcode space,
so I had to demonstrate that I could pull new opcode space out of thin
air, as it were, should I feel the need to do so.

John Savard

On Thu, 9 May 2024 03:05:55 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:

>What makes you think My 66000 ISA cannot be decoded in parallel ??
>Over the last year I have illustrated how up to 16 instructions,
>each variable length from 1..5 words, can be decoded in parallel.

>You are using a header, I am using logic.

One of the things I'm doing is trying to make my ISA capable of
efficient implementations by implementors who aren't necessarily as
smart as you are; with headers, it's obvious how instructions can be
decoded in parallel.

John Savard

On Wed, 08 May 2024 21:17:00 -0600, John Savard
<quadibloc@servername.invalid> wrote:

>And if that isn't enough, the last two header types let you switch to
>38-bit words composed of two 19-bit halfwords. *That's* what I do to
>add a bunch of extra 32-bit instructions to the ISA, if some new
>feature is so important that I don't want the instructions that deal
>with it to have to be 48 bits long at least.

I decided to plan ahead, and expand the opcode space even further by
adding another header type.

Now, one has access to three alternate instruction sets, but instead
of those being fixed, the first two can be chosen from a pool of
sixteen... and the third from a set of 128 different possibilities.

Also, I've noted that each of those alternate instruction sets, while
billed as sets of 32-bit instructions, can actually have opcode space
reserved for longer instructions, just as is done in the primary
instruction set.

John Savard

On Wed, 08 May 2024 23:09:09 -0600, John Savard
<quadibloc@servername.invalid> wrote:

>Now, one has access to three alternate instruction sets, but instead
>of those being fixed, the first two can be chosen from a pool of
>sixteen... and the third from a set of 128 different possibilities.

Of course, this sort of thing may leave you gasping in shock and
horror. But look at the bright side. While 128 is a somewhat large
number, it isn't astronomical; I haven't provided for an opcode space
so large th at there isn't enough matter in the whole Universe to
print a programmer's manual for the architecture.

Now, _that_ would be genuinely impracitcal!

John Savard

On Thu, 09 May 2024 07:16:58 -0600, John Savard
<quadibloc@servername.invalid> wrote:

>On Wed, 08 May 2024 23:09:09 -0600, John Savard
><quadibloc@servername.invalid> wrote:
>
>>Now, one has access to three alternate instruction sets, but instead
>>of those being fixed, the first two can be chosen from a pool of
>>sixteen... and the third from a set of 128 different possibilities.
>
>Of course, this sort of thing may leave you gasping in shock and
>horror. But look at the bright side. While 128 is a somewhat large
>number, it isn't astronomical; I haven't provided for an opcode space
>so large that there isn't enough matter in the whole Universe to
>print a programmer's manual for the architecture.
>
>Now, _that_ would be genuinely impracitcal!

Of course, as these many additional sets of instructions get fleshed
out, were the ISA to be implemented, such an ISA would lend new
meaning to the term "dark silicon", since, having so many instructions
available, they could hardly all be in common use.

Indeed, the situation could even be described with the catchy book
title...

Fifty Shades of Dark Silicon

John Savard

John Savard <quadibloc@servername.invalid> schrieb:
> On Thu, 9 May 2024 03:05:55 +0000, mitchalsup@aol.com (MitchAlsup1)
> wrote:
>
>>What makes you think My 66000 ISA cannot be decoded in parallel ??
>>Over the last year I have illustrated how up to 16 instructions,
>>each variable length from 1..5 words, can be decoded in parallel.
>
>>You are using a header, I am using logic.
>
> One of the things I'm doing is trying to make my ISA capable of
> efficient implementations by implementors who aren't necessarily as
> smart as you are; with headers, it's obvious how instructions can be
> decoded in parallel.

If you include a description of how to decode things in parallel
in the description of your ISA, as Mitch has done for his, then
implementers need not be particularly clever, they only need to
follow what you write.