Re: Cray style vectors

On 11/03/2024 22:29, Thomas Koenig wrote:

On 2024-02-25, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

The above description works for two's complement hardware where
unsigned types have the same width as their corresponding signed
types.  I think for most people that's all they need.  The three
other possibilities are all doable with minor adjustments, and
code appropriate to each particular implementation can be
selected using C preprocessor conditional, as for example

 ...
 but that's implementation-defined behavior, correct?

It is, as far as I understand it.  (Tim knows these things better than I do, so if he finds something in the standards to contradict me, he's probably right.)
For a signed integer type T in C, you have N value bits, P padding bits, and a single sign bit.  The N value bits can hold values between 0 and 2^N - 1.  The sign bit can either indicate a negative value (sign and magnitude), -2^N (two's complement), or -(2^N - 1) (ones' complement). There will also be a corresponding unsigned type, which has at least N value bits and takes the same number of bytes, and has no sign bit.  It can still have padding bits (except for unsigned char, which has no padding).  But all non-negative integers that can be represented in the signed type have exactly the same significant bits in both the signed and unsigned types.
So an implementation can have a 32-bit two's complement "int", and use that for unsigned types too, treating the MSB as a padding bit for unsigned usage.  (Of course, doing so would be inefficient in use on most cpus - you'd have to keep masking off the padding bit when using the value, or somehow guarantee that it is never non-zero.)
In such an implementation, converting an int to an unsigned int would mask off the top bit (fully defined by the standard), and converting from an unsigned int it to a signed int would leave it unchanged (implementation dependent in the standard).  That means (int)(unsigned int)(-1) would be positive 0x7fffffff, not -1.
Real-world systems, of course, all use two's complement types with no padding, and Tim's description will work fine.
(And in C23, only two's complement representations will be allowed.  I can't remember if padding bits are still allowed, however.  And of course signed integer overflow is still UB.)