Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: John Savard <quadibloc@servername.invalid>
Newsgroups: comp.arch
Subject: Re: Stealing a Great Idea from the 6600
Date: Mon, 22 Apr 2024 16:22:11 -0600
Organization: A noiseless patient Spider
Lines: 102
Message-ID: <hmod2jpvun417k1qjm04pvro5gvt3u21rg@4ax.com>
References: <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=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 23 Apr 2024 00:22:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7270acb597502ebace3edfa43b122dbb";
	logging-data="1265504"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+7uI5mVj81cZffKzkWrh/LDALirGuQ60k="
Cancel-Lock: sha1:GWa4IM+6N0YJT8tzApyE6EMTXls=
X-Newsreader: Forte Free Agent 3.3/32.846
Bytes: 5187

On Mon, 22 Apr 2024 14:13:41 -0600, John Savard
<quadibloc@servername.invalid> 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_!
>
>The new design, not yet online, will have the following features:
>
>The code stream will continue to be divided into 256-bit blocks.
>
>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.

The page has now been updated to reflect this modified design.

John Savard