Re: Stealing a Great Idea from the 6600

On Mon, 22 Apr 2024 14:13:41 -0600, John Savard
<quadibloc@servername.invalid> wrote:

On Sat, 20 Apr 2024 17:07:11 +0000, mitchalsup@aol.com (MitchAlsup1)
wrote:

John Savard wrote:

>

And, hey, I'm not the first guy to get sunk because of forgetting what
lies under the tip of the iceberg that's above the water.

>

That also happened to the captain of the _Titanic_.

>
Concer-tina-tanic !?!

>
Oh, dear. This discussion has inspired me to rework the basic design
of Concertina II _yet again_!
>
The new design, not yet online, will have the following features:
>
The code stream will continue to be divided into 256-bit blocks.
>
However, block headers wil be eliminated. Instead, this functionality
will be subsumed into the instruction set.
>
Case I:
>
Indicating that from 1 to 7 32-bit instruction slots in a block are
not used for instructions, but instead may contain pseudo-immediates
will be achieved by:
>
Placing a two-address register-to-register operate instruction in the
first instruction slot in a block. These instructions will have a
three-bit field which, if nonzero, indicates the amount of space
reserved.
>
To avoid waste, when such an instruction is present in any slot other
than the first, that field will have the following function:
>
If nonzero, it points to an instruction slot (slots 1 through 7, in
the second through eighth positions) and a duplicate copy of the
instruction in that slot will be placed in the instruction stream
immediately following the instruction with that field.
>
The following special conditions apply:
>
If the instruction slot contains a pair of 16-bit instructions, only
the first of those instructions is so inserted for execution.
>
The instruction slot may not be one that is reserved for
pseudo-immediates, except that it may be the _first_ such slot, in
which case, the first 16 bits of that slot are taken as a 16-bit
instruction, with the format indicated by the first bit (as opposed to
the usual 17th bit) of that instruction slot's contents.
>
So it's possible to reserve an odd multiple of 16 bits for
pseudo-immediates, so as to avoid waste.
>
Case II:
>
Instructions longer than 32 bits are specified by being of the form:
>
The first instruction slot:
>
11111
00
(3 bits) length in instruction slots, from 2 to 7
(22 bits) rest of the first part of the instruction
>
All remaining instruction slots:
>
11111
(3 bits) position within instruction, from 2 to 7
(24 bits) rest of this part of the instruction
>
This mechanism, however, will _also_ be used for VLIW functionality or
prefix functionality which was formerly in block headers.
>
In that case, the first instruction slot, and the remaining
instruction slots, no longer need to be contiguous; instead, ordinary
32-bit instructions or pairs of 16-bit instlructions can occur between
the portions of the ensemble of prefixed instructions formed by this
means.
>
And there is a third improvement.
>
When Case I above is in effect, the block in which space for
pseudo-immediates is reserved will be stored in an internal register
in the processor.
>
Subsequent blocks can contain operate instructions with
pseudo-immediate operands even if no space for pseudo-immediates is
reserved in those blocks. In that case, the retained copy of the last
block encountered in which pseudo-immediates were reserved shall be
referenced instead.
>
I think these changes will improve code density... or, at least, they
will make it appear that no space is obviously forced to be wasted,
even if no real improvement in code density results.

The page has now been updated to reflect this modified design.

John Savard