linux-kernel - Re: [PATCH 00/14] alpha: cleanups for 6.10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2407020219040.38148@angie.orcam.me.uk>
Date: Wed, 3 Jul 2024 01:12:52 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: Arnd Bergmann <arnd@...db.de>, "Paul E. McKenney" <paulmck@...nel.org>, 
    John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, 
    Arnd Bergmann <arnd@...nel.org>, linux-alpha@...r.kernel.org, 
    Richard Henderson <richard.henderson@...aro.org>, 
    Ivan Kokshaysky <ink@...assic.park.msu.ru>, 
    Matt Turner <mattst88@...il.com>, Alexander Viro <viro@...iv.linux.org.uk>, 
    Marc Zyngier <maz@...nel.org>, linux-kernel@...r.kernel.org, 
    Michael Cree <mcree@...on.net.nz>, Frank Scheiner <frank.scheiner@....de>
Subject: Re: [PATCH 00/14] alpha: cleanups for 6.10

On Mon, 1 Jul 2024, Linus Torvalds wrote:

> The architecture was wrong 30 years ago. It's not that it "became"
> wrong in hindsight. It was wrong originally, and it's just that people
> hadn't thought things through enough to realize how wrong it was.
> 
> The only way it's not wrong is if you say "byte accesses do not
> matter". That's a very Cray way of looking at things - Cray 1 had a
> 64-bit "char" in C, because there were no byte accesses.
> 
> That's fine if your only goal in life is to do HPC.
> 
> So if you simply don't care about bytes, and you *only* work with
> words and quad-words, then alpha looks ok.
> 
> But honestly, that's basically saying "in a different universe, alpha
> is not a mis-design".

 Precisely my point!  We got so used to think in multiples of 8 bits that 
other approaches seem ridiculous.

 The PDP-10 operated on 36-bit quantities and strings were essentially 
clusters of 6-bit characters packed into 6-packs (which is also allegedly 
where the C language's original limitation of using at most six characters 
for identifiers came from -- so that the PDP-10 could compare a pair with 
a single machine instruction).

 So there was already legacy of doing things this way at DEC back in ~1990 
and I can envisage engineers there actually thought that to have a machine 
that in C terms has 32-bit shorts and ints, 64-bit longs and pointers, and 
strings as clusters of 8-bit characters packed into 4-packs or 8-packs was 
not at all unreasonable.  Or maybe just plain 32-bit characters.  After 
all you don't absolutely *have* to use data types of 8 or 16 bits exactly 
in width for anything, do you?  NB for strings nowadays we have Unicode 
and we could just use UTF-32 if not to waste memory.

 And even now ISO C is very flexible on data type widths and only requires 
the character data type to be at least 8 bits wide, and 16-bit and 24-bit 
examples are actually given in the standard itself.  Yes, POSIX requires 
the character data type to be 8 bits wide exactly now, but POSIX.1-1988 
deferred to ANSI C AFAICT.

  Maciej