Re: Why I've Dropped In

Given that Concertina II poses obvious difficulties, it seems reasonable
to try to explain why it is the way it is.
The fundamental characteristic of Concertina II that is the most
controversial is how programs are organized around 256-bit blocks of
program code. So I think that this is what I need to explain and attempt
to justify.
Perhaps the most obvious apparent reason for block structure is to allow
VLIW functionality. Although VLIW doesn't seem to have been a success in
the market, the rationale behind it is the same as that of the promising
Mill design: control pipelining without having to cope with the
complexity of out-of-order execution. The Concertina II block structure
lets VLIW functionality be optional, so that one ISA can serve
processors of different sizes, designed forf different speeds; for some,
the cost of OoO makes sense, and VLIW doesn't, but this allows the
others to be addressed as well.
Switching between modes to allow the same bit patterns to be interpreted
as instructions belonging to different sets of instructions is
considered to be a security hazard. The block structure allows the
instruction set to be extended without that danger - one part of a block
may affect how the rest of the block is interpreted, but that's still a
static attribute of the code that can't be changed by branching to it
from elsewhere with special bits set.
It's been noted that having immediate values in instructions is a very
useful way of making values available to programs as a natural result of
program fetch, without having to do other memory accesses, which tend to
be slow. It was Mitch Alsup himself who noted the importance of this
feature. But because variables come in many types and sizes, I found it
hard to fit immediates of all available data types into an ISA where
variable-length instructions are indicated in a very simple manner. My
scheme of reserving part of a block as unused, and pointing to values in
that unused part of the block makes access more direct than the heads
and tails system, and avoids changing the length of the instruction
entirely.
So these are the reasons I've stuck with block structure. There might be
schemes to avoid block structure and yet meet any one of these goals,
but trying to meet all four and not have block structure seems to me to
be likely to cause a much more complicated instruction set even than
what I have.
Also, there are workarounds. If one wishes to generate code that ran on
a Concertina II implementation, but couldn't cope with managing a
division into blocks... then just use the plain 32-bit instruction set
without using immediates. One will have a complete instruction set that
already does more than any typical RISC instruction set; a lot is packed
into those 32-bit instructions.
And at the next level, one could always use the same header type for
every block. Then dealing with the block structure is only a simple
matter of arithmetic, and now one can, for example, have a
variable-length instruction set.
Yes, choosing the best header for any given block if you allow the
compiler to generate all the available instructions is complicated. But
while that gets the best possible performance, people aren't forced to
do that in order to make use of the architecture. Simpler workarounds
are available.
John Savard