Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Mon, 05 Feb 2024 18:22:59 +0100, Kees Nuyt wrote:
>>> On Sat, 3 Feb 2024 21:37:55 -0000 (UTC), Lawrence D'Oliveiro wrote:
>>> Signed characters make no sense.
>>>
>>> Nor did 6 bit characters, but in the 1980s we had them:
>>> 3 characters in a 24 bit word.
>>
>> I see your sixbit and raise you Radix-50, which packed 3 characters into a
>> 16-bit word.
>>
>> None of these used signed character codes, by the way. So my point still
>> stands.
>
>My understanding is that on the PDP-11, making plain char signed made
>code that stored character values in int objects more efficient.
>Sign-extension was more efficient than zero-filling or something like
>that. I don't remember the details, but I'm sure it wouldn't be
>difficult to find out.

The PDP-11 had two move instructions:

MOV (r1)+,r2
MOVB (r2)+,r3

MOV moved source to destination. MOVB always sign-extended the byte
to the destination register size (16-bit).

On Mon, 05 Feb 2024 15:51:37 -0800, Keith Thompson wrote:

> My understanding is that on the PDP-11, making plain char signed made
> code that stored character values in int objects more efficient.
> Sign-extension was more efficient than zero-filling or something like
> that.

The move-byte instruction did sign-extension when loading into a register,
not storing into memory.

There was no convert-byte-to-word instruction as such.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 05 Feb 2024 15:51:37 -0800, Keith Thompson wrote:
>> My understanding is that on the PDP-11, making plain char signed made
>> code that stored character values in int objects more efficient.
>> Sign-extension was more efficient than zero-filling or something like
>> that.
>
> The move-byte instruction did sign-extension when loading into a register,
> not storing into memory.
>
> There was no convert-byte-to-word instruction as such.

Right, so if you wanted to copy an 8-bit value into a 16-bit register
with sign-extension, you do it in one instruction, whereas zeroing the
top 8 bits would require at least one additional instruction, probably a
BIC (bit-clear) following the MOVB. You'd probably need more
instruction space to store the mask value of 0xff00 -- pardon me,
0177400. And I expect that copying a character into a register would
have been a common operation.

Given those constraints, I'd say it made sense *at the time* for char to
be signed on the PDP-11, especially since it was pretty much assumed
that text would be plain ASCII that would never have the high bit set.

If the PDP-11 had had an alternative MOVB instruction that did
zero-extension, we might not be having this discussion.

Question: Do any more modern CPUs have similar characteristics that make
either signed or unsigned char more efficient?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Mon, 05 Feb 2024 18:31:36 -0800, Keith Thompson wrote:

> If the PDP-11 had had an alternative MOVB instruction that did
> zero-extension, we might not be having this discussion.

Which is effectively what I said:

On Fri, 02 Feb 2024 18:17:52 -0800, Keith Thompson wrote:

> The signedness of plain char is implementation-defined.

Why? Because the PDP-11 on which C and Unix were originally developed did
sign extension when loading a byte quantity into a (word-length) register.

Signed characters make no sense.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 05 Feb 2024 18:31:36 -0800, Keith Thompson wrote:
>
>> If the PDP-11 had had an alternative MOVB instruction that did
>> zero-extension, we might not be having this discussion.
>
> Which is effectively what I said:
>
> On Fri, 02 Feb 2024 18:17:52 -0800, Keith Thompson wrote:
>
> > The signedness of plain char is implementation-defined.
>
> Why? Because the PDP-11 on which C and Unix were originally developed did
> sign extension when loading a byte quantity into a (word-length) register.
>
> Signed characters make no sense.

You wrote that "Signed characters make no sense". I was talking about a
context in which they did make sense. How is that effectively what you
said? (I was agreeing with and expanding on your statement about the
PDP-11.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:

>> Signed characters make no sense.
>
> You wrote that "Signed characters make no sense". I was talking about a
> context in which they did make sense. How is that effectively what you
> said? (I was agreeing with and expanding on your statement about the
> PDP-11.)

I still don’t see any explanation for signed characters as such making
sense.

I think the situation is more accurately interpreted as letting a
PDP-11-specific optimization influence the language design, and
(temporarily) getting away with it because the character values they
cared about at the time happened to lie within a small enough range that
negative values didn’t arise.

--
https://www.greenend.org.uk/rjk/

Richard Kettlewell <invalid@invalid.invalid> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>> Signed characters make no sense.
>>
>> You wrote that "Signed characters make no sense". I was talking about a
>> context in which they did make sense. How is that effectively what you
>> said? (I was agreeing with and expanding on your statement about the
>> PDP-11.)
>
> I still don’t see any explanation for signed characters as such making
> sense.
>
> I think the situation is more accurately interpreted as letting a
> PDP-11-specific optimization influence the language design, and
> (temporarily) getting away with it because the character values they
> cared about at the time happened to lie within a small enough range that
> negative values didn’t arise.

I think that's just a (probably traditional) misnomer. A C char isn't a
character, it's an integer type and it's a signed integer type because
all other original C integer types (int and short) were signed as
well. Unsigned integer types, as something that's different from
pointer, were a later addition.

On 2024-02-06, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>>> Signed characters make no sense.
>>>
>>> You wrote that "Signed characters make no sense". I was talking about a
>>> context in which they did make sense. How is that effectively what you
>>> said? (I was agreeing with and expanding on your statement about the
>>> PDP-11.)
>>
>> I still don’t see any explanation for signed characters as such making
>> sense.
>>
>> I think the situation is more accurately interpreted as letting a
>> PDP-11-specific optimization influence the language design, and
>> (temporarily) getting away with it because the character values they
>> cared about at the time happened to lie within a small enough range that
>> negative values didn’t arise.
>
> I think that's just a (probably traditional) misnomer. A C char isn't a
> character, it's an integer type and it's a signed integer type because
> all other original C integer types (int and short) were signed as
> well. Unsigned integer types, as something that's different from
> pointer, were a later addition.

Sure, except for the part where "abcd" denotes an object that is a
null-terminated array of these *char* integers, that entity being formally
called a "string" in ISO C, and used for representing text. (Or else "abcd" is
initializer syntax for a four element (or larger) array of *char*).

If *char* is signed (and CHAR_BIT is 8), then '\xff` produces a negative value,
even though the constant has type *int*, and "\xff"[0] does likewise.

This has been connected to needless bugs in C programs. An expression like
table[str[i]] may result in table[] being negatively indexed.

The <ctype.h> function require an argument that is either EOF
or a value in the range of 0 to UCHAR_MAX, and so are incompatible
with string elements.

All this crap could have been avoided if *char* had been unsigned.
*unsigned char* never needed to exist except as a synonym for plain
*char*.

Speaking of synonyms, *char* is a distinct type, and not a synonym for either
*signed char* or *unsigned char*. It has to be that way, given the way it is
defined, but it's just another complication that need not have existed:

#include <stdio.h>

int main(void)
{ char *cp = 0;
unsigned char *ucp = 0;
signed char *scp = 0;
printf("%d %d %d\n", cp == ucp, cp == scp, ucp == scp);
printf("%d\n", '\xff');
}

char.c: In function ‘main’:
char.c:8:27: warning: comparison of distinct pointer types lacks a cast
printf("%d %d %d\n", cp == ucp, cp == scp, ucp == scp);
^~
char.c:8:38: warning: comparison of distinct pointer types lacks a cast
printf("%d %d %d\n", cp == ucp, cp == scp, ucp == scp);
^~
char.c:8:50: warning: comparison of distinct pointer types lacks a cast
printf("%d %d %d\n", cp == ucp, cp == scp, ucp == scp);

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-02-06, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Richard Kettlewell <invalid@invalid.invalid> writes:

[...]

>>> I still don’t see any explanation for signed characters as such making
>>> sense.
>>>
>>> I think the situation is more accurately interpreted as letting a
>>> PDP-11-specific optimization influence the language design, and
>>> (temporarily) getting away with it because the character values they
>>> cared about at the time happened to lie within a small enough range that
>>> negative values didn’t arise.
>>
>> I think that's just a (probably traditional) misnomer. A C char isn't a
>> character, it's an integer type and it's a signed integer type because
>> all other original C integer types (int and short) were signed as
>> well. Unsigned integer types, as something that's different from
>> pointer, were a later addition.
>
> Sure, except for the part where "abcd" denotes an object that is a
> null-terminated array of these *char* integers, that entity being formally
> called a "string" in ISO C, and used for representing text. (Or else "abcd" is
> initializer syntax for a four element (or larger) array of *char*).
>
> If *char* is signed (and CHAR_BIT is 8), then '\xff` produces a negative value,
> even though the constant has type *int*, and "\xff"[0] does likewise.
>
> This has been connected to needless bugs in C programs. An expression like
> table[str[i]] may result in table[] being negatively indexed.
>
> The <ctype.h> function require an argument that is either EOF
> or a value in the range of 0 to UCHAR_MAX, and so are incompatible
> with string elements.
>
> All this crap could have been avoided if *char* had been unsigned.
> *unsigned char* never needed to exist except as a synonym for plain
> *char*.

All of this may be true¹ but it's all besides the point. The original C
language had three integer types, char, short and int, which were all
signed types. It further supported declaring pointers to some type and
pointers were basically unsigned integer indices into a linear memory
array. Char couldn't have been an unsigned integer type, regardless if
this would have made more sense², because unsigned integer types didn't
exist in the language.

¹ My personal theory of human fallibility is that humans tend to fuck up
everything they possibly can. Hence, so-called C pitfalls expose human
traits (fallibility) and not language traits. Had they been avoided,
human ingenuity would have found something else to fuck up.

² Being wise in hindsight is always easy. But that's not an option for
people who need to create something which doesn't yet exist and not be
wisely critical of something that does.

On 2024-02-06, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> ¹ My personal theory of human fallibility is that humans tend to fuck up
> everything they possibly can. Hence, so-called C pitfalls expose human
> traits (fallibility) and not language traits.

Does that work for all safety devices? Isolation transformers, steel
toed boots, helmets, seat belts, roll bars, third outlet prongs, ...

A fractured skull reveals a human trait (accident proneness, weak bone)
rather than the workplace trait of not enforcing helmet use.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-02-06, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> ¹ My personal theory of human fallibility is that humans tend to fuck up
>> everything they possibly can. Hence, so-called C pitfalls expose human
>> traits (fallibility) and not language traits.
>
> Does that work for all safety devices? Isolation transformers, steel
> toed boots, helmets, seat belts, roll bars, third outlet prongs, ...

I wrote about C types and somewhat more generally, programming language
features, and not "safety devices" supposed to protect human bodies from
physical injury.

Richard Kettlewell <invalid@invalid.invalid> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> Signed characters make no sense.
>>
>> You wrote that "Signed characters make no sense". I was talking about a
>> context in which they did make sense. How is that effectively what you
>> said? (I was agreeing with and expanding on your statement about the
>> PDP-11.)
>
> I still don’t see any explanation for signed characters as such making
> sense.
>
> I think the situation is more accurately interpreted as letting a
> PDP-11-specific optimization influence the language design, and
> (temporarily) getting away with it because the character values they
> cared about at the time happened to lie within a small enough range that
> negative values didn’t arise.

I think we're mostly in agreement, perhaps with different understandings
of "making sense". What I'm saying is that the decision to make char a
signed type made sense for PDP-11 implementation, purely because of
performance issues.

I just did a quick test on x86_64, x86, and ARM. It appears that
assigning either an unsigned char or a signed char to an int object
takes a single instruction. (My test didn't distinguish between
register or memory target.) I suspect there's no longer any performance
justification on most modern platforms for making plain char signed.
But there's like to be (bad or at least non-portable) code that depends
on plain char being signed. As it happens, plain char is unsigned in
gcc for ARM. And gcc has "-fsigned-char" and "-funsigned-char" options
to override the default.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Rainer Weikusat <rweikusat@talktalk.net> writes:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>>> Signed characters make no sense.
>>>
>>> You wrote that "Signed characters make no sense". I was talking about a
>>> context in which they did make sense. How is that effectively what you
>>> said? (I was agreeing with and expanding on your statement about the
>>> PDP-11.)
>>
>> I still don’t see any explanation for signed characters as such making
>> sense.
>>
>> I think the situation is more accurately interpreted as letting a
>> PDP-11-specific optimization influence the language design, and
>> (temporarily) getting away with it because the character values they
>> cared about at the time happened to lie within a small enough range that
>> negative values didn’t arise.
>
> I think that's just a (probably traditional) misnomer. A C char isn't a
> character, it's an integer type and it's a signed integer type because
> all other original C integer types (int and short) were signed as
> well. Unsigned integer types, as something that's different from
> pointer, were a later addition.

Here's a quote from the 1974 and 1975 C reference manuals:

A char object may be used anywhere an int may be. In all cases the
char is converted to an int by propagating its sign through the
upper 8 bits of the resultant integer. This is consistent with the
two’s complement representation used for both characters and
integers. (However, the sign-propagation feature disappears in other
implementations.)

In more modern terms, that last sentence suggests that plain char was
unsigned in some implementations

K&R1, 1978, is more explicit:

There is one subtle point about the conversion of characters
to integers. The language does not specify whether variables
of type char are signed or unsigned quantities. When a
char is converted to an int, can it ever produce a negative
integer? Unfortunately, this varies from machine to machine,
reflecting differences in architecture. On some machines
(PDP-11, for instance), a char whose leftmost bit is 1 will be
converted to a negative integer ("sign extension"). On others,
a char is promoted to an int by adding zeros at the left end,
and thus is always positive.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Tue, 06 Feb 2024 18:30:46 +0000, Rainer Weikusat wrote:

> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> On 2024-02-06, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>> Richard Kettlewell <invalid@invalid.invalid> writes:
>
> [...]
>
>>>> I still don’t see any explanation for signed characters as such making
>>>> sense.
>>>>
>>>> I think the situation is more accurately interpreted as letting a
>>>> PDP-11-specific optimization influence the language design, and
>>>> (temporarily) getting away with it because the character values they
>>>> cared about at the time happened to lie within a small enough range that
>>>> negative values didn’t arise.
>>>
>>> I think that's just a (probably traditional) misnomer. A C char isn't a
>>> character, it's an integer type and it's a signed integer type because
>>> all other original C integer types (int and short) were signed as
>>> well. Unsigned integer types, as something that's different from
>>> pointer, were a later addition.
>>
>> Sure, except for the part where "abcd" denotes an object that is a
>> null-terminated array of these *char* integers, that entity being formally
>> called a "string" in ISO C, and used for representing text. (Or else "abcd" is
>> initializer syntax for a four element (or larger) array of *char*).
>>
>> If *char* is signed (and CHAR_BIT is 8), then '\xff` produces a negative value,
>> even though the constant has type *int*, and "\xff"[0] does likewise.
>>
>> This has been connected to needless bugs in C programs. An expression like
>> table[str[i]] may result in table[] being negatively indexed.
>>
>> The <ctype.h> function require an argument that is either EOF
>> or a value in the range of 0 to UCHAR_MAX, and so are incompatible
>> with string elements.
>>
>> All this crap could have been avoided if *char* had been unsigned.
>> *unsigned char* never needed to exist except as a synonym for plain
>> *char*.
>
> All of this may be true¹ but it's all besides the point. The original C
> language had three integer types, char, short and int, which were all
> signed types.

This view ignores the early implementation of (K&R) C on IBM 370 systems,
where a char was 8 bits of EBCDIC. In EBCDIC, all alphabetic and numeric
characters have their high bit set (alphabetics range from 0x80 through
0xe9, while numerics range from 0xf0 through 0xf9). A char in this
implementation, by necessity, was unsigned, as C "guarantees that any
character in the machine's standard character set will never be negative"
(K&R "The C Programming Language", p40)

> It further supported declaring pointers to some type and
> pointers were basically unsigned integer indices into a linear memory
> array. Char couldn't have been an unsigned integer type, regardless if
> this would have made more sense², because unsigned integer types didn't
> exist in the language.
>
> ¹ My personal theory of human fallibility is that humans tend to fuck up
> everything they possibly can. Hence, so-called C pitfalls expose human
> traits (fallibility) and not language traits. Had they been avoided,
> human ingenuity would have found something else to fuck up.
>
> ² Being wise in hindsight is always easy. But that's not an option for
> people who need to create something which doesn't yet exist and not be
> wisely critical of something that does.

--
Lew Pitcher
"In Skills We Trust"

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Tue, 06 Feb 2024 18:30:46 +0000, Rainer Weikusat wrote:

[Why-oh-why is char not unsigned?!?]

>> All of this may be true¹ but it's all besides the point. The original C
>> language had three integer types, char, short and int, which were all
>> signed types.
>
> This view ignores the early implementation of (K&R) C on IBM 370 systems,
> where a char was 8 bits of EBCDIC. In EBCDIC, all alphabetic and numeric
> characters have their high bit set (alphabetics range from 0x80 through
> 0xe9, while numerics range from 0xf0 through 0xf9).

Indeed. It refers to the C lanuage as it existed/ was created when UNIX
was brought over to the PDP-11. This language didn't have any unsigned
integer types as the concept didn't yet exist.

On 2024-02-06, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> On 2024-02-06, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>> ¹ My personal theory of human fallibility is that humans tend to fuck up
>>> everything they possibly can. Hence, so-called C pitfalls expose human
>>> traits (fallibility) and not language traits.
>>
>> Does that work for all safety devices? Isolation transformers, steel
>> toed boots, helmets, seat belts, roll bars, third outlet prongs, ...
>
> I wrote about C types and somewhat more generally, programming language
> features, and not "safety devices" supposed to protect human bodies from
> physical injury.

Type systems are safety devices. That's why we have terms like "type
safe" and "unsafe code".

Type safety helps prevent misbehavior, which results in problems like
incorrect results and data loss, which can have real economic harm.

In a safety-critical embedded system, a connection between type safety
and physical safety is readily identifiable.

"Type safety" it's not just some fanciful metaphor like "debugging";
there is a literal interpretation which is true.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-02-06, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>> On 2024-02-06, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>> ¹ My personal theory of human fallibility is that humans tend to fuck up
>>>> everything they possibly can. Hence, so-called C pitfalls expose human
>>>> traits (fallibility) and not language traits.
>>>
>>> Does that work for all safety devices? Isolation transformers, steel
>>> toed boots, helmets, seat belts, roll bars, third outlet prongs, ...
>>
>> I wrote about C types and somewhat more generally, programming language
>> features, and not "safety devices" supposed to protect human bodies from
>> physical injury.
>
> Type systems are safety devices. That's why we have terms like "type
> safe" and "unsafe code".

They're not, at least not when safety device is supposed to mean
something like hard hats. That's just an inappropriate analogy some
people like to employ. This is, however, completely besides the point of
my original text which was about providing an explanation why char is
signed in C despite all kinds of smart alecs with fifty years of
hindsight Ritchie didn't have in 1972 are extremely concvinced that this
was an extremely bad idea.

Den 2024-02-06 skrev Keith Thompson <Keith.S.Thompson+u@gmail.com>:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>> Signed characters make no sense.
>>>
>>> You wrote that "Signed characters make no sense". I was talking about a
>>> context in which they did make sense. How is that effectively what you
>>> said? (I was agreeing with and expanding on your statement about the
>>> PDP-11.)
>>
>> I still don’t see any explanation for signed characters as such making
>> sense.
>>
>> I think the situation is more accurately interpreted as letting a
>> PDP-11-specific optimization influence the language design, and
>> (temporarily) getting away with it because the character values they
>> cared about at the time happened to lie within a small enough range that
>> negative values didn’t arise.
>
> I think we're mostly in agreement, perhaps with different understandings
> of "making sense". What I'm saying is that the decision to make char a
> signed type made sense for PDP-11 implementation, purely because of
> performance issues.
>
> I just did a quick test on x86_64, x86, and ARM. It appears that
> assigning either an unsigned char or a signed char to an int object
> takes a single instruction. (My test didn't distinguish between
> register or memory target.) I suspect there's no longer any performance
> justification on most modern platforms for making plain char signed.
> But there's like to be (bad or at least non-portable) code that depends
> on plain char being signed. As it happens, plain char is unsigned in
> gcc for ARM. And gcc has "-fsigned-char" and "-funsigned-char" options
> to override the default.
>

I wouldn't expect any difference on a modern CPU. I did a microbench
on my laptop with an Intel i5-8350U. clang on my FreeBSD uses movzbl
and movsbl to move char to int so that's what I benched.

The bench was done by moving a byte from the stack to eax using a loop
of 10 movzbl/movsbl running 10M times. Both instructions gave on
average about 0.7 cycles per instruction measured using rdtsc. The
highest bit in the byte being set or unset made no difference.

Andreas Kempe <kempe@lysator.liu.se> writes:
>Den 2024-02-06 skrev Keith Thompson <Keith.S.Thompson+u@gmail.com>:
>> Richard Kettlewell <invalid@invalid.invalid> writes:

>>
>> I think we're mostly in agreement, perhaps with different understandings
>> of "making sense". What I'm saying is that the decision to make char a
>> signed type made sense for PDP-11 implementation, purely because of
>> performance issues.
>>
>> I just did a quick test on x86_64, x86, and ARM. It appears that
>> assigning either an unsigned char or a signed char to an int object
>> takes a single instruction. (My test didn't distinguish between
>> register or memory target.) I suspect there's no longer any performance
>> justification on most modern platforms for making plain char signed.
>> But there's like to be (bad or at least non-portable) code that depends
>> on plain char being signed. As it happens, plain char is unsigned in
>> gcc for ARM. And gcc has "-fsigned-char" and "-funsigned-char" options
>> to override the default.
>>
>
>I wouldn't expect any difference on a modern CPU. I did a microbench
>on my laptop with an Intel i5-8350U. clang on my FreeBSD uses movzbl
>and movsbl to move char to int so that's what I benched.

A move from register to register isn't even executed on most modern
processor designs. It is detected at fetch and the register is
just renamed in the pipeline.

Den 2024-02-06 skrev Scott Lurndal <scott@slp53.sl.home>:
> Andreas Kempe <kempe@lysator.liu.se> writes:
>>Den 2024-02-06 skrev Keith Thompson <Keith.S.Thompson+u@gmail.com>:
>>> Richard Kettlewell <invalid@invalid.invalid> writes:
>
>>>
>>> I think we're mostly in agreement, perhaps with different understandings
>>> of "making sense". What I'm saying is that the decision to make char a
>>> signed type made sense for PDP-11 implementation, purely because of
>>> performance issues.
>>>
>>> I just did a quick test on x86_64, x86, and ARM. It appears that
>>> assigning either an unsigned char or a signed char to an int object
>>> takes a single instruction. (My test didn't distinguish between
>>> register or memory target.) I suspect there's no longer any performance
>>> justification on most modern platforms for making plain char signed.
>>> But there's like to be (bad or at least non-portable) code that depends
>>> on plain char being signed. As it happens, plain char is unsigned in
>>> gcc for ARM. And gcc has "-fsigned-char" and "-funsigned-char" options
>>> to override the default.
>>>
>>
>>I wouldn't expect any difference on a modern CPU. I did a microbench
>>on my laptop with an Intel i5-8350U. clang on my FreeBSD uses movzbl
>>and movsbl to move char to int so that's what I benched.
>
> A move from register to register isn't even executed on most modern
> processor designs. It is detected at fetch and the register is
> just renamed in the pipeline.
>

Yeah. I tried some different variations and by adding some data
dependencies by incrementing the value and moving it around, I could
get some difference between the two, approx 10 to 30 %, but I'm not
sure how much is due to the instruction itself or other effects of
manipulating the data.

Funnily enough, the zero extend was the more performant in these tests
making unsigned char possibly more performant.

My intention wasn't really to claim they're exactly the same, but that
that I don't think there is any real performance benefit to be had by
switching char to unsigned. Even if the 10-30 % are a real thing, I
wonder how much software is actually using char types in a way where
it would make a difference?

Andreas Kempe <kempe@lysator.liu.se> writes:
>Den 2024-02-06 skrev Scott Lurndal <scott@slp53.sl.home>:
>> Andreas Kempe <kempe@lysator.liu.se> writes:
>>>Den 2024-02-06 skrev Keith Thompson <Keith.S.Thompson+u@gmail.com>:
>>>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>
>>>>
>>>> I think we're mostly in agreement, perhaps with different understandings
>>>> of "making sense". What I'm saying is that the decision to make char a
>>>> signed type made sense for PDP-11 implementation, purely because of
>>>> performance issues.
>>>>
>>>> I just did a quick test on x86_64, x86, and ARM. It appears that
>>>> assigning either an unsigned char or a signed char to an int object
>>>> takes a single instruction. (My test didn't distinguish between
>>>> register or memory target.) I suspect there's no longer any performance
>>>> justification on most modern platforms for making plain char signed.
>>>> But there's like to be (bad or at least non-portable) code that depends
>>>> on plain char being signed. As it happens, plain char is unsigned in
>>>> gcc for ARM. And gcc has "-fsigned-char" and "-funsigned-char" options
>>>> to override the default.
>>>>
>>>
>>>I wouldn't expect any difference on a modern CPU. I did a microbench
>>>on my laptop with an Intel i5-8350U. clang on my FreeBSD uses movzbl
>>>and movsbl to move char to int so that's what I benched.
>>
>> A move from register to register isn't even executed on most modern
>> processor designs. It is detected at fetch and the register is
>> just renamed in the pipeline.
>>
>
>Yeah. I tried some different variations and by adding some data
>dependencies by incrementing the value and moving it around, I could
>get some difference between the two, approx 10 to 30 %, but I'm not
>sure how much is due to the instruction itself or other effects of
>manipulating the data.
>

The logic for sign extension (MOVSX) isn't complex, the added gate delay
wouldn't affect the instruction timing. Fan the sign bit out
to the higher bits through a couple of gates to either select the
sign bit or the high order bits when storing into the new register.

Sign extension on load (MOV from memory) will happen in the load unit before
it hits the register file, most likely.

The x86 MOVBE instruction is a slight more complex example.

>Funnily enough, the zero extend was the more performant in these tests
>making unsigned char possibly more performant.

Within what margin of measurement error?

>
>My intention wasn't really to claim they're exactly the same, but that
>that I don't think there is any real performance benefit to be had by
>switching char to unsigned. Even if the 10-30 % are a real thing, I
>wonder how much software is actually using char types in a way where
>it would make a difference?

We use uint8_t extensively because the data is unsigned in the range 0-255.

And generally want wrapping behavior modulo 2^8.

Den 2024-02-07 skrev Scott Lurndal <scott@slp53.sl.home>:
> Andreas Kempe <kempe@lysator.liu.se> writes:
>>Den 2024-02-06 skrev Scott Lurndal <scott@slp53.sl.home>:
>>> Andreas Kempe <kempe@lysator.liu.se> writes:
>>>>
>>>>I wouldn't expect any difference on a modern CPU. I did a microbench
>>>>on my laptop with an Intel i5-8350U. clang on my FreeBSD uses movzbl
>>>>and movsbl to move char to int so that's what I benched.
>>>
>>> A move from register to register isn't even executed on most modern
>>> processor designs. It is detected at fetch and the register is
>>> just renamed in the pipeline.
>>>
>>
>>Yeah. I tried some different variations and by adding some data
>>dependencies by incrementing the value and moving it around, I could
>>get some difference between the two, approx 10 to 30 %, but I'm not
>>sure how much is due to the instruction itself or other effects of
>>manipulating the data.
>>
>
> The logic for sign extension (MOVSX) isn't complex, the added gate delay
> wouldn't affect the instruction timing. Fan the sign bit out
> to the higher bits through a couple of gates to either select the
> sign bit or the high order bits when storing into the new register.
>
> Sign extension on load (MOV from memory) will happen in the load unit before
> it hits the register file, most likely.
>
> The x86 MOVBE instruction is a slight more complex example.
>
>
>>Funnily enough, the zero extend was the more performant in these tests
>>making unsigned char possibly more performant.
>
> Within what margin of measurement error?
>

Here's an example of a test I played around with. The body of my loop
does this 10M times for this test. movzbl is switched for movsbl when
testing the other configuration.

movzbl -24(%rsp), %eax
movb %al, -25(%rsp)
movzbl -25(%rsp), %eax
movb %al, -26(%rsp)
movzbl -26(%rsp), %eax
movb %al, -27(%rsp)
movzbl -27(%rsp), %eax
movb %al, -28(%rsp)
movzbl -28(%rsp), %eax
incl %eax
movb %al, -24(%rsp)

This is the data, unit is total cycles for a run, from 2000 runs of
10M each for the two different instructions:

movzbl:
mean = 1.24E+08
variance = 3.95E+12

movsbl:
mean = 1.38E+08
variance = 3.44E+12

ratio movsbl/movzbl = 1.11

Performing a two-tail student t-test gives

p-value: 0.00E+00

Something is causing these two test runs to give different performance
results. I will not pretend I know enough about the inner workings of
Intel's magic box to explain why.

>>
>>My intention wasn't really to claim they're exactly the same, but that
>>that I don't think there is any real performance benefit to be had by
>>switching char to unsigned. Even if the 10-30 % are a real thing, I
>>wonder how much software is actually using char types in a way where
>>it would make a difference?
>
> We use uint8_t extensively because the data is unsigned in the range 0-255.
>
> And generally want wrapping behavior modulo 2^8.

Sure, but if you are using uint8_t, you have sidestepped the whole
issues of char being signed or unsigned so a change wouldn't really
affect you.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Richard Kettlewell <invalid@invalid.invalid> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>> Signed characters make no sense.
>>>
>>> You wrote that "Signed characters make no sense". I was talking about a
>>> context in which they did make sense. How is that effectively what you
>>> said? (I was agreeing with and expanding on your statement about the
>>> PDP-11.)
>>
>> I still don’t see any explanation for signed characters as such making
>> sense.
>>
>> I think the situation is more accurately interpreted as letting a
>> PDP-11-specific optimization influence the language design, and
>> (temporarily) getting away with it because the character values they
>> cared about at the time happened to lie within a small enough range that
>> negative values didn’t arise.
>
> I think we're mostly in agreement, perhaps with different understandings
> of "making sense". What I'm saying is that the decision to make char a
> signed type made sense for PDP-11 implementation, purely because of
> performance issues.

Having a basic 8-bit integer type be signed type makes sense (in
context) for performance reasons and perhaps for usability reasons too.

But that’s really not the same as “signed characters make sense”. For
signed characters to make sense there has to be encoding where some
signs (or control codes, etc) are encoded to negative values. I’ve never
heard of one.

“char” isn’t just a random string of symbols. It’s obvious both from the
name and the way it’s used in the language that it’s intended to
represent characters, not just small integer values. If the purpose was
purely the latter it would have been called ‘short short int’ or
something like that.

> I just did a quick test on x86_64, x86, and ARM. It appears that
> assigning either an unsigned char or a signed char to an int object
> takes a single instruction. (My test didn't distinguish between
> register or memory target.) I suspect there's no longer any performance
> justification on most modern platforms for making plain char signed.
> But there's like to be (bad or at least non-portable) code that depends
> on plain char being signed. As it happens, plain char is unsigned in
> gcc for ARM. And gcc has "-fsigned-char" and "-funsigned-char" options
> to override the default.

i.e. we’re still suffering the locked-in side-effects of an ancient
decision even though the original justification has become irrelevant.
It might or might not have been a reasonable trade-off at the time,
disregarding what were then hypotheticals about the future, but (indeed
with hindsight) I think from today’s point of view it was clearly the
wrong decision.

--
https://www.greenend.org.uk/rjk/

Andreas Kempe <kempe@lysator.liu.se> writes:
>Den 2024-02-07 skrev Scott Lurndal <scott@slp53.sl.home>:
>> Andreas Kempe <kempe@lysator.liu.se> writes:

>>>Funnily enough, the zero extend was the more performant in these tests
>>>making unsigned char possibly more performant.
>>
>> Within what margin of measurement error?
>>
>
>Here's an example of a test I played around with. The body of my loop
>does this 10M times for this test. movzbl is switched for movsbl when
>testing the other configuration.
>
>movzbl -24(%rsp), %eax
>movb %al, -25(%rsp)
>movzbl -25(%rsp), %eax
>movb %al, -26(%rsp)
>movzbl -26(%rsp), %eax
>movb %al, -27(%rsp)
>movzbl -27(%rsp), %eax
>movb %al, -28(%rsp)
>movzbl -28(%rsp), %eax
>incl %eax
>movb %al, -24(%rsp)
>
>This is the data, unit is total cycles for a run, from 2000 runs of
>10M each for the two different instructions:
>
>movzbl:
> mean = 1.24E+08
> variance = 3.95E+12
>
>movsbl:
> mean = 1.38E+08
> variance = 3.44E+12
>
>ratio movsbl/movzbl = 1.11

Sehr interresant. Ich weiss nicht, warum es ist.

>> We use uint8_t extensively because the data is unsigned in the range 0-255.
>>
>> And generally want wrapping behavior modulo 2^8.
>
>Sure, but if you are using uint8_t, you have sidestepped the whole
>issues of char being signed or unsigned so a change wouldn't really
>affect you.

While most C compilers have a compile-time option to select the signed-ness of
char, using uint8_t sidesteps the issue completely.

Richard Kettlewell <invalid@invalid.invalid> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

[...]

>> I think we're mostly in agreement, perhaps with different understandings
>> of "making sense". What I'm saying is that the decision to make char a
>> signed type made sense for PDP-11 implementation, purely because of
>> performance issues.
>
> Having a basic 8-bit integer type be signed type makes sense (in
> context) for performance reasons and perhaps for usability reasons too.
>
> But that’s really not the same as “signed characters make sense”. For
> signed characters to make sense there has to be encoding where some
> signs (or control codes, etc) are encoded to negative values. I’ve never
> heard of one.
>
> “char” isn’t just a random string of symbols. It’s obvious both from the
> name and the way it’s used in the language that it’s intended to
> represent characters, not just small integer values.

Computers have absolutely no idea of "characters". They handle numbers,
integer numbers in this case, and humans then interpret them as
characters based on some convention for encoding characters as
integers. Hence, a data type suitable for holding an encoded character
(ie, an integer value from 0 - 127 for the case in question) is not the
same as a character.