Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Concertlina II: Full Circle
Date: Mon, 17 Jun 2024 20:20:03 +0000
Organization: Rocksolid Light
Message-ID: <132536f47d1b160ad3ad0340fc479c1d@www.novabbs.org>
References: <mas07jhu9i876gsov2gh8tap17kem5n21p@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="318698"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$VmSTGhwRKq5tKueLlUmbTey/tP3zC0f1QPMgnZcWJdw0FTmDEUzF.
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 3648
Lines: 63

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