Re: Tonights Tradeoff - Carry and Overflow

On 2024-10-09 6:44 a.m., Robert Finch wrote:

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.
 

Mulled over carry and overflow in arithmetic operations. Looked at widening the datapath to 66-bits to hold carry and overflow bits. Thinking it may increase the size of the design by over 3% just to support carry and overflow. For now, an instruction, ADDGC, was added to generate the carry bit as a result. A 256-bit add looks like:
; 256 bit add
; A = r1,r2,r3,r4
; B = r5,r6,r7,r8
; S = r9,r10,r11,r12
add r9,r1,r5,r0
addgc r13,r1,r5,r0
add r10,r2,r6,r13
addgc r13,r2,r6,r13
add r11,r7,r3,r13
addgc r13,r7,r3,r13
add r12,r8,r4,r13
Not very elegant a solution, but it is simple. I think it requires minimal hardware. Three input ADD is already present and ADDGC just routes the carry bit to the output.