From Newsgroup: comp.arch

I just noticed a _major_ error in my description of the Concertina II architecture.
In order to allow 15-bit short instructions instead of 14-bit short instructions, I had to use a part of the opcode space taken up by words
with two short instructions for some of the 32-bit instructions.
But I failed to properly limit the first few bits of the 15-bit
instructions so as to actually leave that opcode space available.
So I realized that what I originally intended was for the 15-bit
instructions to be limited to operate instructions, not including shift
and branch instructions at all - and then it slipped my mind.
At the moment, my fix is to only limit the first of a pair of 15-bit short instructions to register-to-register operate instructions, while still allowing all types of 15-bit instructions for the second instruction.
While this is a _little_ better than limiting all 15-bit short
instructions, it is not particularly appealing, and now that I realize
that I haven't achieved the "impossible" quite as well as I had thought, I
am less satisfied with the design, and am looking into ways to modify it.
One possible option is to have a pair of short instructions consist of a 14-bit short instruction followed by a 15-bit short instruction. Then I'll have enough opcode space to have a header with a four-bit prefix, and so
drop 16-bit short instructions entirely, along with the complicated A, B,
and X scheme for variable-length instruction blocks; I can go back to 17-
bit short instructions anywhere with only a 32-bit header.
One bit of ugliness is removed, but another terrible bit of ugliness is
added.
I've squeezed the opcode space very tightly to get as far as I have. While there isn't much room left to squeeze any more, it is possible that, by looking very carefully at the situation, I might come up with a new option that is more elegant than any of those that immediately come to mind.

John Savard
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.arch

I have made an additional change.
At the cost of making the pairs of 15-bit instructions even messier, I
have removed some other ugliness from the ISA.
Now, there are only three types of header instead of five once again...
and the 16-bit short instructions have been eliminated, leaving only 17-
bit, 14-bit, and 15-bit short instructions.

John Savard

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sat, 14 Mar 2026 11:12:42 +0000, quadi wrote:

I have made an additional change.
At the cost of making the pairs of 15-bit instructions even messier, I
have removed some other ugliness from the ISA.
Now, there are only three types of header instead of five once again...
and the 16-bit short instructions have been eliminated, leaving only 17-
bit, 14-bit, and 15-bit short instructions.

And I've managed to squeeze out just a little more opcode space to make
the pairs of 15-bit short instructions somewhat less bad.

John Savard
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sat, 14 Mar 2026 11:12:42 +0000, quadi wrote:

Now, there are only three types of header instead of five once again...
and the 16-bit short instructions have been eliminated, leaving only 17-
bit, 14-bit, and 15-bit short instructions.

I have now also removed the 14 bit short instructions - along with CISC
mode. I had brought that in because I had thought this iteration was a
roaring success in achieving my code density goals. Since instead the
paired 15-bit short instructions have turned into a debacle, and the 14-
bit short instructions were too restricted to be genuinely practical, this feature no longer seemed to be appropriate.

John Savard
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 15 Mar 2026 02:41:08 +0000, quadi wrote:

I have now also removed the 14 bit short instructions - along with CISC
mode. I had brought that in because I had thought this iteration was a roaring success in achieving my code density goals. Since instead the
paired 15-bit short instructions have turned into a debacle, and the 14-
bit short instructions were too restricted to be genuinely practical,
this feature no longer seemed to be appropriate.

I have now squeezed out some more opcode space from the 32-bit operate instructions which allowed me to reduce the extent to which the two 15-bit short instructions in a word differ from each other. This, in my opinion, makes the terrible mess a little bit less messy.

Still really *too* messy to be acceptable, but it's still progress;
perhaps it can form a basis on which I can find a way to improve matters
still further.

John Savard
--- Synchronet 3.21d-Linux NewsLink 1.2