Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
Newsgroups: comp.arch
Subject: Re: Tonights Tradeoff - Background Execution Buffers
Date: Wed, 9 Oct 2024 06:44:08 -0400
Organization: A noiseless patient Spider
Lines: 81
Message-ID: <ve5mpq$2jt5k$1@dont-email.me>
References: <vbgdms$152jq$1@dont-email.me> <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>
 <5f8ee3d3b2321ffa7e6c570882686b57@www.novabbs.org>
 <vd6a5e$o0aj$2@dont-email.me> <vdnpg4$3c9e$2@dont-email.me>
 <2024Oct4.081931@mips.complang.tuwien.ac.at> <vdp343$9d38$1@dont-email.me>
 <2024Oct5.114309@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 09 Oct 2024 12:44:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="31d03ec2be85dcf700a1a9aefc34905c";
	logging-data="2749620"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+BfHFzpxbAF1ylo5Y3JBJbFxpmUHi+Kgs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:TPlzLHSOAc/BOEjICSvr4V1sX3Y=
In-Reply-To: <2024Oct5.114309@mips.complang.tuwien.ac.at>
Content-Language: en-US
Bytes: 5955

On 2024-10-05 5:43 a.m., Anton Ertl wrote:
> Robert Finch <robfi680@gmail.com> writes:
>> On 2024-10-04 2:19 a.m., Anton Ertl wrote:
>>> 4) Keep the flags results along with GPRs: have carry and overflow as
>>> bit 64 and 65, N is bit 63, and Z tells something about bits 0-63.
>>> The advantage is that you do not have to track the flags separately
>>> (and, in case of AMD64, track each of C, O, and NZP separately), but
>>> instead can use the RAT that is already there for the GPRs.  You can
>>> find a preliminary paper on that on
>>> <https://www.complang.tuwien.ac.at/anton/tmp/carry.pdf>.
> ...
>> One solution, not mentioned in your article, is to support arithmetic
>> with two bits less than the number of bit a register can support, so
>> that the carry and overflow can be stored. On a 64-bit machine have all
>> operations use only 62-bits. It would solve the issue of how to load or
>> store the carry and overflow bits associated with a register.
> 
> Yes, that's a solution, but the question is how well existing software
> would react to having no int64_t (and equivalent types, such as long
> long), but instead an int62_t (or maybe int63_t, if the 64th bit is
> used for both signed and unsigned overflow, by having separate signed
> and unsigned addition etc.).  I expect that such an architecture would
> have low acceptance.  By contrast, in my paper I suggest an addition
> to existing 64-bit architectures that has fewer of the same
> disadvantages as the widely-used condition-code-register approach has,
> but still has a few of them.
> 
>> Sometimes
>> arithmetic is performed with fewer bits, as for pointer representation.
>> I wonder if pointer masking could somehow be involved. It may be useful
>> to have a bit indicating the presence of a pointer. Also thinking of how
>> to track a binary point position for fixed point arithmetic. Perhaps
>> using the whole upper byte of a register for status/control bits would work.
> 
> There are some extensions for AMD64 in that direction.
> 
>> It may be possible with Q+ to support a second destination register
>> which is in a subset of the GPRs. For example, one of eight registers
>> could be specified to holds the carry/overflow status. That effectively
>> ties up a second ALU though as an extra write port is needed for the
>> instruction.
> 
> Needing only one write port is an advantage of my approach.
> 
> - anton

Been thinking some about the carry and overflow and what to do about 
register spills and reloads during expression processing. My thought was 
that on the machine with 256 registers, simply allocate a ridiculous 
number of registers for expression processing, for example 25 or even 
50. Then if the expression is too complex, have the compiler spit out an 
error message to the programmer to simplify the expression. Remnants of 
the ‘expression too complex’ error in BASIC. So, there are no spills or 
reloads during expression processing. I think the storextra / loadextra 
registers used during context switching would work okay. But in Q+ there 
are 256 regs which require eight storextra / loadextra registers. I 
think the store extra / load extra registers could be hidden in the 
context save and restore hardware. Not even requiring access via CSRs or 
whatever. I suppose context loads and stores could be done in blocks of 
32 registers. An issue is that the load extra needs to be done before 
registers are loaded. So, the extra word full of carry/overflow bits 
would need to be fetched in a non-sequential fashion. Assuming for 
instance, that saving register values is followed by a save of the CO 
word. Then it is positioned wrong for a sequential load. It may be 
better to have the wrong position for a store, so loads can proceed 
sequentially.
It strikes me that there is no real good solution, only perhaps an 
engineered one. Toyed with the idea of having 16 separate flags 
registers, but not liking that as a solution as much as the store/load 
extra.

Another thought is to store additional info such as a CRC check of the 
register file on context save and restore.

*****

Finally wrote the SM to walk the ROB backwards and restore register 
mappings for a checkpoint restore. Cannot get Q+ to do more than light 
up one LED in SIM. Register values are not propagating properly.