From Newsgroup: comp.arch

I have come up with yet another strange idea.
If neither variable-length instructions, or my latest instruction
prefix scheme, will work, then it seems like I have to go back to
giving the instruction stream a block structure.
But is there a way that I can make it seem less like a block
structure?
Suppose I go all the way down to 64-bit blocks.
Normally, a 64-bit unit contains two 32-bit instructions.
But if it starts with the bits 11, then it contains something else.

One option is: when it starts with 1100, the remaining 60 bits are
divided into three 20-bit units.
If a 20-bit unit begins with 00, it contains an 18-bit short
instruction. Between memory references and branches, a lot of a
program could be made up of short instructions, thus saving space.
If a 20-bit unit begins with 10, it contains the first 18 bits of an instruction that is 36 bits long or longer. If it begins with 11, it
contains an additional 18 bits of such an instruction.

This is consistent with parallel decoding.

When the 64 bit block starts with 1101, then it contains a long
instruction. There would be room for instructions with 32-bit
immediates here, and maybe even for instructions with 48-bit
immediates.

The problem is that it doesn't work with 64-bit immediates. I might
decide that I won't bother with 128-bit immediates, but 64-bit
immediates are essential. Of course I could parcel them out 16 bits at
a time within the 20-bit units of a variable-length instruction
stream, but I would prefer them to be contiguous and aligned.

Maybe then instead of 64-bit blocks, I should go to variable-length instructions, but of a very simple form.

If any 32 bits begin with 11, then they begin an instruction that is
either 64 bits or 96 bits in length. One type of 64-bit instruction
contains three 20-bit zones for short instructions, with the possible occasional mixture of other stuff. Another handles 32-bit immediates,
while a 96-bit instruction handles 64-bit immediates.

It's still complicated, but it's easy enough for logic circuitry to
parse and decode quickly.

However, there is another option that sticks with 64-bit aligned
blocks. Let the combination 1111 mean data that is not decoded, such
as the last 60 bits of a 64-bit immediate.
The preceding instruction which takes an immediate can just include
the four-bit prefix that will need.
Not fully contiguous, but close, and now everything is susceptible to
fully parallel decoding.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Tue, 15 Sep 2026 01:38:21 GMT, quadibloc@invalid.com (John Savard)
wrote:

Suppose I go all the way down to 64-bit blocks.

This seemed oh, so reasonable. But will a compiler want to use it?
After all, one can only switch from 32-bit instructions to 20-bit
short instructions after an even-numbered 32-bit instruction, and back
to 32-bit instructions after a multiple of three 20-bit short
instructions.
Except that one can also encode 32-bit instructions in the 20-bit
instruction stream, along with additional possibilities in that length
range. So positioning is arbitrary, albeit with a loss in efficiency.
When instructions have immediates, the location is fixed as being at a
64-bit boundary, but I still envisage the first or second 32-bit
instruction, or any 36-bit instruction within the 20-bit stream, as
potentially having an immediate; it would just come after the 64-bit
unit containing the instruction, leading to a requirement to fetch
ahead before execution.
The fact that 2 and 3 are relatively prime means that one can stop the
sequence of 20-bit short instructions anywhere; encoding none, one, or
two subsequent 32-bit instructions in two 20-bit slots will eventually
make everything come out even.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2