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: Tonights Tradeoff - Background Execution Buffers
Date: Thu, 26 Sep 2024 14:11:09 +0000
Organization: Rocksolid Light
Message-ID: <5f8ee3d3b2321ffa7e6c570882686b57@www.novabbs.org>
References: <vbgdms$152jq$1@dont-email.me> <17537125c53e616e22f772e5bcd61943@www.novabbs.org> <vbj5af$1puhu$1@dont-email.me> <a37e9bd652d7674493750ccc04674759@www.novabbs.org> <vbog6d$2p2rc$1@dont-email.me> <f2d99c60ba76af28c8b63b9628fb56fa@www.novabbs.org> <vc61e6$21skv$1@dont-email.me> <vc8gl4$2m5tp$1@dont-email.me> <vcv5uj$3arh6$1@dont-email.me> <37067f65c5982e4d03825b997b23c128@www.novabbs.org> <vd352q$3s1e$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3584008"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$d6TI7KJ9xXpR46x8AWW8x.X.JVdt0yvA9HgvIxEq0C8kicYO8hlZO
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 3562
Lines: 42

On Thu, 26 Sep 2024 8:13:12 +0000, Robert Finch wrote:

> On 2024-09-24 4:38 p.m., MitchAlsup1 wrote:
>> On Tue, 24 Sep 2024 20:03:29 +0000, Robert Finch wrote:
>>
>>> Under construction: Q+ background execution buffers for the block memory
>>> operations. For instance, a block store operation can be executed in the
>>> background while other instructions are executing. Store operations are
>>> issued when the MEM unit is not busy. Background instructions continue
>>> to execute even when interrupts occur. The background operations may be
>>> useful for initializing blocks of memory that are not needed right-away.
>>> When the operation is issued a handle for the buffer is returned in the
>>> destination register so that the status of the operation may be queried,
>>> or the operation cancelled.
>>
>> This is how My 66000 performs:: LDM, STM, ENTER, EXIT, MM, and MS.
>> Addresses are AGENED and then a state machine over in the memory
>> unit performs the required steps. {{Not usefully different than the
>> divider performing the individual steps of division.}} While the
>> unit performs its duties, other units can be fed and complete
>> other instructions.
>>
>> You just have to mark the affected registers to prevent hazards.
>
> Q+ releases the registers right away, so things can continue on.
> Q+ captures the register values at issue then does not modify the
> registers. Did not want an instruction with three updates happening. It
> keeps track of its own values. In theory anyway. Have not got to testing
> it yet. A status operation might be used to query the final operation
> results.
>
> Altering Q+ to use 64-bit instructions and 256 registers instead of
> supporting a vector instruction set. Two pipeline stages can be removed
> then and it is a simpler design. Code density will decrease <200%.
> Relying on software to assign registers for vectors.
>
> Also adding a predicate field to instructions. Branches are horrendously
> slow in this simple implementation. It may be faster to predicate a
> dozen instructions.

The depth of predication should be such that if FETCH will "get there"
by the time the branch "resolves" that number of instructions should
be predicated.