A very common comment I have receieved from several people on my Concertina II
ISA is that making the instruction stream vlock structured is a mistake.

However, computers having a VLIW architecture do normally have a block
structured instruction scheme, with the block being the very long instruction
word. While I've included VLIW functionality in Concertina II and Concertina
III, this has been to increase performance in some implementations, and, thus,
is a relatively minor part of the ISA.

What I've come up with now has the following characteristics:

The normal instruction set no longer has block structure, it's been squeezed
enough to go without that, and provide variable-length instructions.

But one can also choose to run in VLIW mode; then, the instruction stream
is divided into blocks of eight 32-bit instructions, with one block header
to indicate instruction predication.

So block structure is only present where it belongs. VLIW code can't be
distinguished from normal code by using the block header because
instructions in normal code can cross block boundaries, so the second
half of a 32-bit instruction could look like the start of a block header.

Is this worthwhile, I wonder...

John Savard

Block structure is only applicable to 1-width of execution
and fails for all other widths.....

So the question becomes:: is your architecture designed for exactly
one width of execution ???

On Wed, 24 Jan 2024 20:05:23 +0000, MitchAlsup1 wrote:

> Block structure is only applicable to 1-width of execution
> and fails for all other widths.....
>
> So the question becomes:: is your architecture designed for exactly
> one width of execution ???

Well, the VLIW mode is designed for eight-wide execution. But it
can also work well with four-wide or two-wide, I would think, since
it could still specify more efficient execution for those.

But this new design is about _abandoning_ block structure *except*
for VLIW programs. No more pseudo-immediates. 16-bit instructions
no longer come in pairs.

And here it is now:

http://www.quadibloc.com/arch/ct20int.htm

So basically I have finally taken your advice to dump block structure,
except that Concertina IV still offers VLIW in addition to CISC and
RISC; but now, VLIW is separate so the CISC/RISC instruction set is
no longer disfigured by block structure.

John Savard

On Thu, 25 Jan 2024 01:47:07 +0000, Quadibloc wrote:

> On Wed, 24 Jan 2024 20:05:23 +0000, MitchAlsup1 wrote:
>
>> Block structure is only applicable to 1-width of execution
>> and fails for all other widths.....
>>
>> So the question becomes:: is your architecture designed for exactly
>> one width of execution ???
>
> Well, the VLIW mode is designed for eight-wide execution. But it
> can also work well with four-wide or two-wide, I would think, since
> it could still specify more efficient execution for those.

With Concertina II in its various incarnations, if a header left
seven instructions in a block, I provided _six_ break bits with
them, as there was always a break before the first one because the
instructions needed to be fetched.

With Concertina IV, on the other hand, the break bit happens to be
the first bit of every instruction. So, while the block length of
eight instructions controls the format of the header that provides
predication, there actually would be nothing stopping an implementation
from treating that as simply a notational convention for predication...
and fetching and executing twelve instructions at a time.

Although presumably the compiler would take the issue width of the
target machine into account. So Concertina IV isn't necessarily
block structured in a way that limits the issue widths it can
work with, although that's just a happy accident, not something I
intended. And, of course, memory is simpler if powers of two are
fetched and executed.

Remember: now the only header is for predication. No longer is
decoding profoundly changed by some possible header values.

John Savard

On 1/24/24 11:14 AM, Quadibloc wrote:
> A very common comment I have receieved from several people on my Concertina II
> ISA is that making the instruction stream vlock structured is a mistake.

I am not certain that encoding based on a block larger than a
typical instruction is necessarily a mistake. If operations can
receive "left over" bits from a previous block and borrow bits
from the next block, large immediates (e.g.,) could still be
provided with less space wasted than if instructions were required
to fit within a block.

Immediate bits would be obvious choices for borrowed bits as they
do not affect the operation and delayed acquisition would often
not be problematic. However, some operation encoding bits might be
safely lent to the next block, especially if the buffer was
cleared on indirect jumps.

Such a block encoding could prevent jumping into the middle of an
instruction. Useful code snippets for return-oriented programming
would still exist, of course.

(My 66000 provides some protection from jumping into the middle of
an instruction by having the most common 32-bit immediates not be
a valid first parcel of an instruction. Various "safe stack"
proposals can prevent return-oriented programming [I suspect
limiting the "main stack" accesses to using immediate offsets from
frame or stack pointer would have a similar effect]. There have
also been proposals for "landing pads" for indirect jumps.)

Block encoding could also be more flexible in field placement, not
being limited to a single operation/instruction. There might also
be opportunities for compression from using a larger encoding
chunk. Dependent operations and "superinstructions" might be made
easier to detect with block-based encoding (at least those within
one block).

Block encoding might also facilitate predecoding. With variable
length encoding like My 66000 (which is simpler by having the
"instruction" in the first parcel with later parcels only being
immediates), hardware would have to know the start of the first
instruction in a cache block to do predecoding of the cache block.
This feature seems especially attractive to me.

A block encoding that supports bit-borrowing from other blocks and
seeks to optimize density and staged interpretation of bits
according to criticality would probably be rather complex.

I am not convinced that block-based encoding is worthwhile, but
such an encoding need not be less dense than an instruction-based
encoding.

(I have not thought deeply about it, but I feel that there should
be a way to encode instruction information such that it could be
"parsed" to fill a BTB (to avoid target mispredictions and
redundant tag checks) and perhaps facilitate hoisting of loads
(particularly those with base addresses known early) and otherwise
organize the information for faster or less expensive execution. I
also wonder if a dependence-oriented encoding, where results are
explicitly directed to consumers similar to transport-trigger
architectures, would be helpful. Reducing any-to-any communication
_seems_ desirable as does localization of communication. Sun's
MAJC seemed attractive in having global and "slice" (execution
lane) private registers, though with four slices I would have
thought pair-shared registers might also be useful. Other aspects
of MAJC such as its VLIW nature and uniform capabilities of three
of the four slices seem less than ideal. MAJC also sought to allow
cheaper communication between threads; however, sharing a 16KiB
dual-ported L1 data cache among two cores seems problematic. Sun's
Rock processor was similarly "interesting".)