Path: ...!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Stealing a Great Idea from the 6600
Date: Tue, 23 Apr 2024 01:53:26 +0000
Organization: Rocksolid Light
Message-ID: <3fab253870efca80b8ea207faf3c9d29@www.novabbs.org>
References: <lge02j554ucc6h81n5q2ej0ue2icnnp7i5@4ax.com> <e2097beb24bf27eed0a92f14596bd59e@www.novabbs.org> <in312jlca131khq3vj0i24n6pb0hah2ur5@4ax.com> <71acfecad198c4e9a9b14ffab7fc1cb5@www.novabbs.org> <1s042jdli35gdo092v6uaupmrcmvo0i5vp@4ax.com> <oj742jdvpl21il2s5a1ndsp3oidsnfjmr6@4ax.com> <dd1866c4efb369b7b6cc499d718dc938@www.novabbs.org> <acq62j98dhmguil5ebce6lq4m9kkgt1fs2@4ax.com> <kkq62jppr53is4r70n151jl17bjd5kd6lv@4ax.com> <9d1fadaada2ec0683fc54688cce7cf27@www.novabbs.org> <h8gd2jduqgk7i6decn0lj902pob7bud984@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="2063311"; 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-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$dUKWHzr.FKpuXKmClBk6KOw6.7KcIvw7jwkV/CPDT1yx41qQL3q/C
Bytes: 5189
Lines: 102

John Savard wrote:

> On Sat, 20 Apr 2024 17:07:11 +0000, mitchalsup@aol.com (MitchAlsup1)
> wrote:
>>John Savard wrote:

>>> And, hey, I'm not the first guy to get sunk because of forgetting what
>>> lies under the tip of the iceberg that's above the water.
>>
>>> That also happened to the captain of the _Titanic_.
>>
>>Concer-tina-tanic !?!

> Oh, dear. This discussion has inspired me to rework the basic design
> of Concertina II _yet again_!

I suggest it is time for Concertina III.......

> The new design, not yet online, will have the following features:

> The code stream will continue to be divided into 256-bit blocks.

Why not a whole cache line ??

> However, block headers wil be eliminated. Instead, this functionality
> will be subsumed into the instruction set.

> Case I:

> Indicating that from 1 to 7 32-bit instruction slots in a block are
> not used for instructions, but instead may contain pseudo-immediates
> will be achieved by:

> Placing a two-address register-to-register operate instruction in the
> first instruction slot in a block. These instructions will have a
> three-bit field which, if nonzero, indicates the amount of space
> reserved.

> To avoid waste, when such an instruction is present in any slot other
> than the first, that field will have the following function:

> If nonzero, it points to an instruction slot (slots 1 through 7, in
> the second through eighth positions) and a duplicate copy of the
> instruction in that slot will be placed in the instruction stream
> immediately following the instruction with that field.

> The following special conditions apply:

> If the instruction slot contains a pair of 16-bit instructions, only
> the first of those instructions is so inserted for execution.

> The instruction slot may not be one that is reserved for
> pseudo-immediates, except that it may be the _first_ such slot, in
> which case, the first 16 bits of that slot are taken as a 16-bit
> instruction, with the format indicated by the first bit (as opposed to
> the usual 17th bit) of that instruction slot's contents.

> So it's possible to reserve an odd multiple of 16 bits for
> pseudo-immediates, so as to avoid waste.

> Case II:

> Instructions longer than 32 bits are specified by being of the form:

> The first instruction slot:

> 11111
> 00
> (3 bits) length in instruction slots, from 2 to 7
> (22 bits) rest of the first part of the instruction

> All remaining instruction slots:

> 11111
> (3 bits) position within instruction, from 2 to 7
> (24 bits) rest of this part of the instruction

> This mechanism, however, will _also_ be used for VLIW functionality or
> prefix functionality which was formerly in block headers.

> In that case, the first instruction slot, and the remaining
> instruction slots, no longer need to be contiguous; instead, ordinary
> 32-bit instructions or pairs of 16-bit instlructions can occur between
> the portions of the ensemble of prefixed instructions formed by this
> means.

> And there is a third improvement.

> When Case I above is in effect, the block in which space for
> pseudo-immediates is reserved will be stored in an internal register
> in the processor.

> Subsequent blocks can contain operate instructions with
> pseudo-immediate operands even if no space for pseudo-immediates is
> reserved in those blocks. In that case, the retained copy of the last
> block encountered in which pseudo-immediates were reserved shall be
> referenced instead.

> I think these changes will improve code density... or, at least, they
> will make it appear that no space is obviously forced to be wasted,
> even if no real improvement in code density results.

> John Savard