Re: Concertlina II: Full Circle

John Savard wrote:

I've noted earlier that I felt I had been going around in circles with
Concertina II, changing the instruction format back and forth, instead
of making progress to flesh it out.

At least no one can say you give up easily.

Recently, I added a new instruction to facilitate looping.
But the trouble was that it took up tooo much opcode space.

Yes, indeed...

One thing that occured to me was that if I went back to an old method
of specifying instructions longer than 32-bits: using a 4-bit pSupp
field to point into the same reserved area in the block as used for
pseudo-immediates, that would suit this instruction very well.

The reason is that if that techique were used, then I could use the
header that's also an instruction to just squeeze in the three-bit
decode field, and so access to the Loop instruction would be easy as
befits its importance.

Then I went back, and looked up an older version of Concertina II
which had it. It had complicated block headers. But worse than that,
it had _four_ different versions of the complete instruction set!
Which version was used depended on the header.The idea, of course,
that some headers required a pared-down version of the instruction set
so as to squeeze in more stuff.
It was also interesting to see how much further along I had gotten in
fleshing out that older version of the instruction set.

As to looping, I faced the same delimma and came to a different
conclusion::
You don't do it in 1 instruction, instead, you do it in a way where
your
2 instruction encoding executes one of the instructions only once. I
call
this bookending the loop.
So, I have an instruction called VEC, which donates a register and provides other guidance to the loop. And I have an instruction called
LOOP which performs the bottom of loop calculations. The register
donated
by VEC is given the address of the top of the loop so that the loop
terminating instruction is relieved of needing to supply it in the form of a displacement,...
VEC is executed once at the top of the loop, and provides guidance as
to which registers from within the loop are live-out of the loop.
This allows HW to avoid writing everything into RF and facilitates
running the loop across multiple lanes of function units.
LOOP, then, performs the ADD, a CMP, and a BC to the top of the loop.
I ended up with 3 kinds of LOOPs:
a) counted    -- for( i = 0; i < max;         i++ )
b) searching  -- for( i = 0; a[i] > 13;       i++ )
c) both       -- for( i = 0; i < max && a[i]; i++ )
This coves the majority of loops where the looping condition is
encodable.

John Savard