Re: Why I've Dropped In

I have thought some more about why I have been going around and around
in circles.
Since the basis of the ISA is a RISC-like ISA, even if I add VLIW and
CISC functionality, I want that RISC-like ISA to be acceptable.
The basic memory-reference instructions for the ISA as I envisage it
take up 3/4 of the total opcode space for 32-bit instructions.
I've toyed with various ways to reduce this. These have included:
1) Reducing the size of displacements in instructions from 16 bits to 15
bits.
2) Using the technique from the SEL32 of using the least significant
bits of the displacement to indicate the operand length, so that all
operand types other than byte can share a single opcode (well, two; one
for integer, one for floating). This means the computer can only address
aligned data.
3) Use only four base registers instead of eight.
4) Use only three index registers instead of seven.
5) Use only six index registers instead of seven, and use only four base
registers instead of eight when indexing is used.
I have not found any of them acceptable.
Basic memory-reference instructions using up 3/4 of the opcode space,
though, isn't a problem for a basic RISC ISA. The remaining 1/4 is
enough to add additional special memory-reference instructions like
branch, jump to subroutine, and load and store multiple registers, as
well as all the 32-bit register-to-register operate instructions.
The trouble has been, though, that I *also* wanted to include in my ISA
a feature that allowed two _short_ register-to-register instructions to
be placed in a single 32-bit word. This would make for more compact
code, approaching that of CISC architectures which have 32-bit
memory-reference instructions and 16-bit register operate instructions.
3/4 plus 1/4 doesn't provide anything left over.
Since the architecture also uses a block organization, with a first
header word, I had been able to deal with this simply by starting with
one basic ISA, either compromised with paired short instructions or not
compromised without them, and also allowing a modified ISA to be used in
which the opposite choice is made, at the overhead of using the first
instruction as a block header.
Since I didn't really like that either, I kept going around and around
in circles. That approach had two problems for me: it was too
complicated, and it also imposed too high an overhead cost for doing one
of the things I wanted to include in the basic ISA without having to
switch over.
I think, though, that I've finally come up with something I haven't
tried before that puts the necessary compromises in a place I can live
with. I will still have to use block headers, but only where they're
needed:
a) to indicate space in a block not to be used for instructions, so that
instructions can have immediate data (in the form of pseudo-immediates,
as they're still pointed to by the instruction, but the pointer is a
short one, pointing within the instruction block that has been fetched
from memory, so it's efficient like a real immediate value in an
instruction);
b) to include data for VLIW functionality - instruction predication, and
explicit indication of when instructions can be executed in parallel;
c) CISC-style variable length instructions - instructions that are 48
bits, 64 bits, and so on, in length, with a bit vector indicating where
each instruction starts, so that decoding is still parallel and fast
..and _not_ for switching to an alternate 32-bit instruction set,
because the basic one is fundamentally inadequate.
So _maybe_, unless I realize before it is too late that my latest
brainstorm is also fundamentally flawed, a new iteration of Concertina
II may be coming soon.
My latest brainstorm?
Include pairs of short instructions as part of the ISA, but make the
short instructions 14 bits long instead of 15 so they get only 1/16 of
the opcode space. This way, the compromise is placed in something that's
less important. In the CISC mode, 17-bit short instructions will still
be present, after all.
John Savard