From Newsgroup: comp.arch

I found and corrected some errors in the opcode space allocated to headers. Some bit patterns were overlapping with instructions.
This happened as I was preparing to change the ISA of Concertina II. I
thought that the 14-bit short instructions weren't really all that useful,
and I would be better off by using the four-bit pattern it consumed to indicate a header indicating a block consisting of seven 36-bit
instructions.

But that seemed like just making a third basic instruction set format...
with all three of them being different ways of doing the same thing.
Something else suggested itself to me instead.

If I took the various methods to make more compact instructions, and
combined them all, going all out, I could make memory-reference
instructions that were only 22 bits long. That would leave enough room to allow them to be _predicated_ without a header!

But that had its own problems. Predication and break bits... were what was normally associated with a VLIW instruction set. And even if those didn't
need headers, I still didn't see a way to avoid them for pseudo-
immediates. This might reduce the need for headers and block structure,
and allow the scheme of headers to be simplified, but it wouldn't mean I
could do without it. So would this radical change _really_ make things
better?

So I'm getting to that point I dreaded - the one where instead of settling
on _this_ iteration of Concertina II, I go back to going around in
circles. Will I find a satisfying genuine improvement?

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

From Newsgroup: comp.arch

On Thu, 21 Aug 2025 00:03:28 +0000, John Savard wrote:

If I took the various methods to make more compact instructions, and
combined them all, going all out, I could make memory-reference
instructions that were only 22 bits long. That would leave enough room
to allow them to be _predicated_ without a header!

Alas, no. Even making instructions as short as possible to exist in a
limited form does _not_ permit them to coexist with the existing full instruction set as I had hoped in this particular fashion.

It may, however, be possible to salvage something from this idea.

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

From Newsgroup: comp.arch

On Thu, 21 Aug 2025 02:32:42 +0000, John Savard wrote:

Alas, no. Even making instructions as short as possible to exist in a
limited form does _not_ permit them to coexist with the existing full instruction set as I had hoped in this particular fashion.

It may, however, be possible to salvage something from this idea.

It was possible to salvage something, indeed.

I threw out the other idea, of having a header for 36-bit instructions,
since the same capabilities were already provided by variable-length instructions.

What I salvaged was memory to register operate instructions that could fit inside the basic 32-bit instruction set. To make them fit, though, I had
to take that opcode space hog, the load and store multiple instructions,
and shrink it down - by also restricting those instructions to aligned operands.

So, while the leading bits of the headers will get shuffled around a bit,
the basic structure of the headers won't end up getting changed
significantly. Although I would have liked to trim down the headers, I
also didn't want to lose the capabilities to which they offered access, so this does not dismay me too much.

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

From Newsgroup: comp.arch

John Savard <quadibloc@invalid.invalid> wrote:

I found and corrected some errors in the opcode space allocated to headers. Some bit patterns were overlapping with instructions.
This happened as I was preparing to change the ISA of Concertina II. I thought that the 14-bit short instructions weren't really all that useful, and I would be better off by using the four-bit pattern it consumed to indicate a header indicating a block consisting of seven 36-bit instructions.

But that seemed like just making a third basic instruction set format... with all three of them being different ways of doing the same thing. Something else suggested itself to me instead.

If I took the various methods to make more compact instructions, and combined them all, going all out, I could make memory-reference
instructions that were only 22 bits long. That would leave enough room to allow them to be _predicated_ without a header!

But that had its own problems. Predication and break bits... were what was normally associated with a VLIW instruction set. And even if those didn't need headers, I still didn't see a way to avoid them for pseudo-
immediates. This might reduce the need for headers and block structure,
and allow the scheme of headers to be simplified, but it wouldn't mean I could do without it. So would this radical change _really_ make things better?

So I'm getting to that point I dreaded - the one where instead of settling on _this_ iteration of Concertina II, I go back to going around in
circles. Will I find a satisfying genuine improvement?

Your messages suggest that you are building your instruction encoding
by hand. There are rather old algorithms like Huffman compression
and optimal search tree. If you define instructions and add weight
factors (importance or expected frequency) appropriate algorithm
shoul be able to pack your instructions as densly as possible
and guarantee that there are no overlap.
--
Waldek Hebisch
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Thu, 21 Aug 2025 16:08:43 +0000, Waldek Hebisch wrote:

Your messages suggest that you are building your instruction encoding by hand. There are rather old algorithms like Huffman compression and
optimal search tree. If you define instructions and add weight factors (importance or expected frequency) appropriate algorithm shoul be able
to pack your instructions as densly as possible and guarantee that there
are no overlap.

I'm aware of Huffman encoding; for example, I discuss it here:

http://www.quadibloc.com/crypto/mi0601.htm

However, I wouldn't consider it for the design of an instruction set,
since I want the opcodes of the instructions to be logically grouped and ordered. Look at how the opcodes of the PDP-8 or the IBM System/360 are
set out - in a plain, regular, easy-to-understand fashion.

John Savard

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Thu, 21 Aug 2025 05:10:33 +0000, John Savard wrote:

What I salvaged was memory to register operate instructions that could
fit inside the basic 32-bit instruction set.

And this new revision of Concertina II has finally been posted to my
updated web page.

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