16 May
2020
16 May
'20
6:15 a.m.
Discussions today on the TUHS list about the signed/unsigned nature of
the C char type led me to reexamine logs of my feature test package at
http://www.math.utah.edu/pub/features/
I had 170 build logs for it from 2017.11.07, so I moved those aside
and ran another set of builds in our current enlarged test farm. That
generated another 361 fresh builds. Those tests are all with the C
compiler named "cc". I did not explore what other C compilers did,
but I strongly suspect that they all agree on any single platform.
On all but THREE systems, the tests report that "char" is signed, with
CHAR_MAX == +127.
The three outliers have char unsigned with CHAR_MAX == +255, and are
* ARM armv7l Linux 4.13.1 (2017) and 5.6.7 (2020)
* SGI O2 R10000-SC (150 MHz) IRIX 6.5 (2017 and 2020)
* IBM POWER8 CentOS Linux release 7.4.1708 (AltArch) (2017)
So, while the ISO C Standards, and historical practice, leave it
implementation dependent whether char is signed or unsigned, there is
a strong majority for a signed type.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
16 May
16 May
6:28 a.m.
New subject: v7 K&R C
Nelson H. F. Beebe wrote in
<CMM.0.95.0.1589588129.beebe(a)gamma.math.utah.edu>:
|Discussions today on the TUHS list about the signed/unsigned nature of
|the C char type led me to reexamine logs of my feature test package at
|
| http://www.math.utah.edu/pub/features/
|
|I had 170 build logs for it from 2017.11.07, so I moved those aside
|and ran another set of builds in our current enlarged test farm. That
|generated another 361 fresh builds. Those tests are all with the C
|compiler named "cc". I did not explore what other C compilers did,
|but I strongly suspect that they all agree on any single platform.
|
|On all but THREE systems, the tests report that "char" is signed, with
|CHAR_MAX == +127.
|
|The three outliers have char unsigned with CHAR_MAX == +255, and are
|
| * ARM armv7l Linux 4.13.1 (2017) and 5.6.7 (2020)
| * SGI O2 R10000-SC (150 MHz) IRIX 6.5 (2017 and 2020)
| * IBM POWER8 CentOS Linux release 7.4.1708 (AltArch) (2017)
|
|So, while the ISO C Standards, and historical practice, leave it
|implementation dependent whether char is signed or unsigned, there is
|a strong majority for a signed type.
Just to note Linus Torvalds "famous" "It better had been unsigned,
Virginia".
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
7:52 a.m.
New subject: v7 K&R C
On Fri, May 15, 2020 at 6:23 PM Nelson H. F. Beebe <beebe(a)math.utah.edu>
wrote:
Discussions today on the TUHS list about the
signed/unsigned nature of
the C char type led me to reexamine logs of my feature test package at
http://www.math.utah.edu/pub/features/
I had 170 build logs for it from 2017.11.07, so I moved those aside
and ran another set of builds in our current enlarged test farm. That
generated another 361 fresh builds. Those tests are all with the C
compiler named "cc". I did not explore what other C compilers did,
but I strongly suspect that they all agree on any single platform.
On all but THREE systems, the tests report that "char" is signed, with
CHAR_MAX == +127.
The three outliers have char unsigned with CHAR_MAX == +255, and are
* ARM armv7l Linux 4.13.1 (2017) and 5.6.7 (2020)
* SGI O2 R10000-SC (150 MHz) IRIX 6.5 (2017 and 2020)
* IBM POWER8 CentOS Linux release 7.4.1708 (AltArch) (2017)
So, while the ISO C Standards, and historical practice, leave it
implementation dependent whether char is signed or unsigned, there is
a strong majority for a signed type.
arm has been the biggest outlier in terms of unsigned char. In FreeBSD,
this has been the second largest source of bugs with the platform... the
OABI weird alignment requirements being the first (thankfully behind us)...
Warner
10:31 p.m.
New subject: v7 K&R C
On 5/15/20, Warner Losh <imp(a)bsdimp.com> wrote:
arm has been the biggest outlier in terms of unsigned char. In FreeBSD,
this has been the second largest source of bugs with the platform... the
OABI weird alignment requirements being the first (thankfully behind us)...
Why did the implementers of the Unix ABI for ARM decide to have char
be unsigned? Was there an architectural reason for it?
-Paul W.
17 May
17 May
2:35 a.m.
New subject: v7 K&R C
Paul Winalski <paul.winalski(a)gmail.com> writes:
On 5/15/20, Warner Losh <imp(a)bsdimp.com> wrote:
My understanding is that it is a lot more efficient to use unsigned char
on arm. You can make gcc, for example, deal with this, but it costs. I
remember having to tell gcc to deal with it when I ported the Doom
engine to a StrongARM processor device under NetBSD many years ago. I
mostly remember the code running well enough, but it was larger.
--
Brad Spencer - brad(a)anduin.eldar.org - KC8VKS - http://anduin.eldar.org
arm has been the biggest outlier in terms of unsigned char. In FreeBSD,
this has been the second largest source of bugs with the platform... the
OABI weird alignment requirements being the first (thankfully behind us)...
Why did the implementers of the Unix ABI for ARM decide to have char
be unsigned? Was there an architectural reason for it?
-Paul W.
2:37 a.m.
New subject: v7 K&R C
On Sat, May 16, 2020 at 2:35 PM Brad Spencer <brad(a)anduin.eldar.org> wrote:
Paul Winalski <paul.winalski(a)gmail.com> writes:
I've seen numbers that suggest it's about 10% smaller to use unsigned
characters, and the code runs 5-10% faster. I've not looked at the
generated code to understand why, exactly, that might be the case.
Warner
On 5/15/20, Warner Losh <imp(a)bsdimp.com>
wrote:
>
> arm has been the biggest outlier in terms of unsigned char. In FreeBSD,
> this has been the second largest source of bugs with the platform... the
> OABI weird alignment requirements being the first (thankfully behind
us)...
Why did the implementers of the Unix ABI for ARM decide to have char
be unsigned? Was there an architectural reason for it?
-Paul W.
My understanding is that it is a lot more efficient to use unsigned char
on arm. You can make gcc, for example, deal with this, but it costs. I
remember having to tell gcc to deal with it when I ported the Doom
engine to a StrongARM processor device under NetBSD many years ago. I
mostly remember the code running well enough, but it was larger.
18 May
18 May
6:25 p.m.
New subject: v7 K&R C
Paul Winalski <paul.winalski(a)gmail.com> wrote:
Why did the implementers of the Unix ABI for ARM decide to have char
be unsigned? Was there an architectural reason for it?
The early ARM didn't have a sign-extended byte load instruction.
I learned C with the Norcroft ARM C compiler on the Acorn Archimedes in
1991/2ish. Norcroft C had quite a lot of unix flavour despite running on a
system that was not at all unixy. (I didn't get my hands on actual unix
until a couple of years later.) Acorn had a BSD port to the Archimedes
which I've never seen myself - the R260 was a pretty powerful system for
its time which I coveted from afar. I believe the 32 bit ARM ABI evolved
from the early 26 bit ABI on the Archimedes. (32 bit word, 26 bit address
space.)
http://chrisacorns.computinghistory.org.uk/RISCiXComputers.html
More recent versions of the instruction set have more features. I believe
the arm64 ABI uses signed char to match what everyone is used to. I still
think unsigned bytes are more sensible, but that's what I was taught at an
impressionable age...
Tony.
--
f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/
Trafalgar: North 3 or 4, occasionally 5 later. Moderate, occasionally slight
in east. Fair. Good.
1678
days inactive
1680
days old
6 comments
6 participants
participants (6)
-
Brad Spencer -
Nelson H. F. Beebe -
Paul Winalski -
Steffen Nurpmeso -
Tony Finch -
Warner Losh