signed integers

[solardiz]

Why does Epiphany define signed integers as a separate data type, and are they actually different from the usual 2's complement notation? Can we intermix e.g. ADD and IADD instructions to perform the same kind of addition in the same formula (needing more than one addition), yet achieve greater throughput (use both datapaths)? For positive numbers? For numbers that would be deemed negative if treated as signed (but we treat them as unsigned)? For signed numbers, which may in fact be negative (if we treat them as signed everywhere, but sometimes use ADD rather than IADD on them)?

[ysapir]

[solardiz]

Thanks! I thought it was the other way around regarding IADD vs. ADD, since IMADD/IMSUB are similarly-named and are on FPU (right? they have to be because they're 3-input), and since FADD and IADD (not FADD and ADD) share an opcode (according to the instruction decode table in 3.12.12.18).

Anyhow, my question was whether and why the "signed integers" talked about in the arch reference use other than 2's complement (which would make e.g. IADD vs. ADD incompatible for some uses). If they're compatible, then why bother calling some integers "signed" in contexts such as addition (I understand why when talking about arithmetic right shift, but not in context of addition). I find the definition in "7.2.1 Signed Integer Representation" (page 37) confusing. It differs from the "Unsigned" definition only by a minus sign in front of the msb. Does it means that the msb is a sign bit, and the rest stays the same? If so, we have two zeroes, etc, and IADD (defined to operate on signed integers) can't be used for unsigned 32-bit integers (as needed e.g. for crypto).

Also, if it's not for reuse of some FPU circuits (you said you're reusing the address calculation instead), why would you use anything other than 2's complement? Why doesn't(?) address calculation use 2's complement?

[ysapir]

* As for ADD/IADD, you are right. ADD is an IALU instruction and IADD is an FPU instruction.

I am not sure where you get the impression that some signed integers are not 2's complement?

The definition in 7.2.1 is the canonical definition for signed integers. This is how native C int type is defined and works. The msb is more than a sign bit (in the floating-point type sense). It has a weight of negative 2^31 for 'int' types and negative 2^7 = -128 for 'char' types. This is why the signed byte numbers range is -128 -> +127.

Although the arithmetic addition result would be the same when treating the value as either signed or unsigend, the interpretation of the status flags may be different. For example, there should be no negative result when adding two unsigned numbers.

[solardiz]

Thanks for the clarifications!

I did misread/misinterpret the definition. Indeed, treating the component given for msb as (negative) weight matches the usual 2's complement notation. I only looked at the definition after I started to suspect that it could be something other than 2's complement, which may have contributed to my confusion.

I did suspect it could be just about the status flags, but the mentions of "signed" integers felt too prominent, and setting BZ=1 based on only RD[30:0] (not RD[31:0]) felt weird for 2's complement, so I also suspected it could potentially be worse. I am glad that it is not.

What's the point behind setting BZ=1 for 0x80000000 (e.g. on IADD), though, if we use 2's complement and this value is thus negative and not zero? Is this for compatibility with a condition used to check for floating-point equality? If so, it looks like this won't work: BBEQ is documented as checking BZ only, not "BZ & ~BN", so it'll be true for 0x80000000. Thus, e.g. comparing two integer values (regardless of whether we consider them signed or unsigned) with ISUB followed by BBEQ or BBNE (these check BZ only) would result in them being treated as equal when in fact they differ by 0x80000000. Documentation bug or design weirdness or specific reasons behind such choices?

[timpart]

[amylaar]

You can use the -mfp-iarith compiler option to make the compiler use iadd / isub for addition/subtraction.
This will can well-parallelizable integer code more effective instruction issue bandwidth, at the cost
of higher latencies.
The compiler port also has a peephole2 pattern to change some iadd/isub instructions back to add/sub
if the FPU pipeline appears overcommitted after register allocation.

Note, this option will also cause extra mode switching at function entry/call/exit unless you also use -mfp-mode=int .