Path: ...!feeds.phibee-telecom.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Tonights Tradeoff - Background Execution Buffers
Date: Sat, 05 Oct 2024 09:43:09 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 47
Message-ID: <2024Oct5.114309@mips.complang.tuwien.ac.at>
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>
Injection-Date: Sat, 05 Oct 2024 12:31:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4b486aea911af6f0cec786c98c1ac92e";
	logging-data="735238"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+WINMuCUyzDz4VB29lLyYZ"
Cancel-Lock: sha1:qAhX69pfcm0/G3Y/aaqkn5Tupec=
X-newsreader: xrn 10.11
Bytes: 3856

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
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>