Date: Mon, 28 Oct 2013 22:19:59 +0100

El 28/10/2013 1:07, Lawrence Crowl escribió:

>> ------------------------------------------------

>>

>> Char Types

>>

>> Characters are 8 bits wide. The plain char type is unsigned by

>> default. This default can be changed to be signed by the

>> $PORT (SIGNEDCHAR) option. This affects all variables of type

>> char, even in arrays and structures.

>>

>> Signed characters are stored in two’s-complement format. The>> values 0 through have the same bit pattern for signed and

>> unsigned types. Unsigned characters are stored in two’s

>> complement format if the $PORT (CHAR2) option is enabled.

>

> How would the representation of an unsigned number change with this

> option?

I think the option controls how a negative number can be assigned or

compared with an unsigned type:

Signed and Unsigned Type Comparisons

------------------------------------

The comparison of negative numbers with unsigned types may behave

differently on A Series systems than on other platforms. Platforms that

store arithmetic values in one’s or two’s complement form store the sign

when assigning to an unsigned type. On A Series systems, the sign is not

stored when assigning to an unsigned type. On A Series systems,

comparing a negative value with the value in an unsigned type will never

be true unless the CHAR2 or UNSIGNED subordinate options of the PORT

compiler control option are used to emulate two’s complement arithmetic

on unsigned types. Another workaround is to change negative literals to

their one’s complement values (for example, -1 becomes 0xFF).

-----------------------------------------

>> Bit operations (bitwise AND, OR, exclusive OR, and NOT) on signed

>> values affect only the 40 bits used by integers. Bit operations on

>> unsigned values conform to the mathematical definitions given in the

>> ANSI C standard. Because the sign bit is not adjacent to the other

>> bits, it is not possible to shift into or out of the sign bit.

>

> Which, I think conflicts with the recent change we made to allow

> shifting into the sign bit. I was never comfortable with that change

> because it broke the model of shift being isomorphic to multiplication

> by a power of two.

Yes, that's why requiring shifting into the sign bit could be allowed

only for (two's complement?) types with no padding bits.

> In other words, they have implemented the "overflow undefined

> unsigned integer" type that I have been wanting.

>

> Porting a program with a global option like that is likely not

> trivial. We really need two separate types.

Or maybe an attribute, but things start to complicate when trying to

define mixed arithmetic between overflow undefined and wraparound

unsigned types.

Best,

Ion

>> ------------------------------------------------

>>

>> Char Types

>>

>> Characters are 8 bits wide. The plain char type is unsigned by

>> default. This default can be changed to be signed by the

>> $PORT (SIGNEDCHAR) option. This affects all variables of type

>> char, even in arrays and structures.

>>

>> Signed characters are stored in two’s-complement format. The>> values 0 through have the same bit pattern for signed and

>> unsigned types. Unsigned characters are stored in two’s

>> complement format if the $PORT (CHAR2) option is enabled.

>

> How would the representation of an unsigned number change with this

> option?

I think the option controls how a negative number can be assigned or

compared with an unsigned type:

Signed and Unsigned Type Comparisons

------------------------------------

The comparison of negative numbers with unsigned types may behave

differently on A Series systems than on other platforms. Platforms that

store arithmetic values in one’s or two’s complement form store the sign

when assigning to an unsigned type. On A Series systems, the sign is not

stored when assigning to an unsigned type. On A Series systems,

comparing a negative value with the value in an unsigned type will never

be true unless the CHAR2 or UNSIGNED subordinate options of the PORT

compiler control option are used to emulate two’s complement arithmetic

on unsigned types. Another workaround is to change negative literals to

their one’s complement values (for example, -1 becomes 0xFF).

-----------------------------------------

>> Bit operations (bitwise AND, OR, exclusive OR, and NOT) on signed

>> values affect only the 40 bits used by integers. Bit operations on

>> unsigned values conform to the mathematical definitions given in the

>> ANSI C standard. Because the sign bit is not adjacent to the other

>> bits, it is not possible to shift into or out of the sign bit.

>

> Which, I think conflicts with the recent change we made to allow

> shifting into the sign bit. I was never comfortable with that change

> because it broke the model of shift being isomorphic to multiplication

> by a power of two.

Yes, that's why requiring shifting into the sign bit could be allowed

only for (two's complement?) types with no padding bits.

> In other words, they have implemented the "overflow undefined

> unsigned integer" type that I have been wanting.

>

> Porting a program with a global option like that is likely not

> trivial. We really need two separate types.

Or maybe an attribute, but things start to complicate when trying to

define mixed arithmetic between overflow undefined and wraparound

unsigned types.

Best,

Ion

Received on 2013-10-28 22:20:17