Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Oops (Concertina II Going Around in Circles)
Date: Wed, 8 May 2024 21:46:37 +0000
Organization: Rocksolid Light
Message-ID: <ee4741388de9887010e58dd1e2770a7c@www.novabbs.org>
References: <kipj2j5be9kuv8rn770iq6neq2cvu3s5oi@4ax.com> <b936220e0d198db43b18e58007401f42@www.novabbs.org> <6qam3jplo8oa9n46g70c48tn69ao8hn486@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="507687"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$npB3YPIHi86rIbvTNSkmCukl7.grh4rem34/KzK8jVAZr.JQ1DKXK
Bytes: 3886
Lines: 70

John Savard wrote:

> On Thu, 25 Apr 2024 16:00:14 +0000, mitchalsup@aol.com (MitchAlsup1)
> wrote:

>>In my opinion, your first cut at an ISA encoding should not consume more 
>>than ½ of the available encodings. Concer-tina-tanic is already full to
>>the brim and you are still just fleshing it out.

> This is a point I think I should address.

> Why are my various iterations of Concertina II _all_, consistently,
> "full to the brim"?

> This is true if I compromise the basic load/store instructions, say by
> limiting them to three base registers for 16-bit displacements, so I
> can reserve 1/4 of the opcode space for paired 16-bit short
> instructions - which was one of the most common combinations -

> or if I reserve half the opcode space for two kinds of 16-bit short
> instructions,

> or if I don't compromise the basic load/store instructions, and only
> allow 16-bit instructions with a special header.

> These are the three basic variants of Concertina II that I have been
> vacillating between. But whichever I choose, I use nearly all possible
> opcode space, at least for basic 32-bit instructions.

This should hint that you are long down the dark alley.

> That didn't worry me much for two reasons.

Perhaps you feel save down the dark alley....

> If I need an enormous amount of opcode space for some new kind of
> instructions for some new feature...

> I would still have _enormous_ amounts of opcode space available up in
> the stratosphere of 64-bit instructions and longer. (In some
> iterations, I did manage to use nearly all the 48-bit opcode space,
> because I tried to squeeze a form of string and packed decimal
> instructions there.)

So, why do you need a header AT ALL !!

{Notice that I get a full functional ISA where the instruction specifier
is always 32-bits and I still have room for constants and for extensions.}

If your bail out position is:: "some instructions can be 64-bits" --
S T A R T with that as an assumption !!

> But what if the new feature was so important that I needed to have
> *short* instructions for the operations using that feature - 32-bit
> long instructions?

G A S P ........why do I even try.....

> Well, because of the block structure of Concertina II, which is
> primarily present to support pseudo-immediates (my idea of how to
> reconcile immediate values in instructions, which you've pointed out
> are very valuable, with my Concertina II design goal of fully
> independent and parallel decoding of every instruction in a block) and
> secondarily to allow VLIW features...

> I can always add one new type of header which specifies alternate
> instructions with fairly low overhead... and then, at a modest cost,
> even the most enormous new feature can have its own 32-bit
> instructions!

> John Savard