linux-alpha.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	 Arnd Bergmann <arnd@kernel.org>,
	linux-alpha@vger.kernel.org,
	 Richard Henderson <richard.henderson@linaro.org>,
	 Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	 Matt Turner <mattst88@gmail.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	 Marc Zyngier <maz@kernel.org>,
	linux-kernel@vger.kernel.org,  Michael Cree <mcree@orcon.net.nz>,
	Frank Scheiner <frank.scheiner@web.de>
Subject: Re: [PATCH 00/14] alpha: cleanups for 6.10
Date: Tue, 2 Jul 2024 00:48:00 +0100 (BST)	[thread overview]
Message-ID: <alpine.DEB.2.21.2406302009480.43454@angie.orcam.me.uk> (raw)
In-Reply-To: <CAHk-=wimJ2hQhKSq7+4O1EHtkg7eFBwY+fygxD+6sjWqgyDMTQ@mail.gmail.com>

On Fri, 31 May 2024, Linus Torvalds wrote:

> The fact is, the original alpha is the worst architecture ever made.
> The lack of byte instructions and the absolutely horrendous memory
> ordering are fatal flaws. And while the memory ordering arguably had
> excuses for it ("they didn't know better"), the lack of byte ops was
> wilful misdesign that the designers were proud of, and made a central
> tenet of their mess.
> 
> And I say that as somebody who *loved* it originally. Yes, the lack of
> byte operations always was a pain, because it really caused the IO
> subsystem to be a nightmare, but I was young, I was stupid, it was
> interesting, and I had bought into the kool aid.

 Looking from today's perspective it was clearly a bad choice.  However it 
was 30+ years ago, it wasn't so certain as it is now that x86 was there to 
stay -- indeed as I recall it DEC had the ambition to phase x86 out with 
their Alpha (whether they approached it the right way business-wise is 
another matter) -- so the notion of having a fully byte-addressed machine 
perhaps wasn't yet so obvious to DEC engineers as it is now, when most if 
not all the current CPU architectures have these fundamentals the same.  

 As I say it may have been the final attempt to do something differently 
before x86 domination forced everyone to be at least remotely compatible.

 And there used to be weirder architectures before people moved away from 
them and settled on the current paradigm, just as nobody wants to build a 
general-purpose atmospheric railway anymore and yet a while ago not only 
it didn't appear ridiculous, but such stuff was actually built and run, 
such as the South Devon Railway.

 And then it wasn't the only failed attempt: remember the i860 or the 
iAPX432?  At least the Alphas weren't a total disaster, they made their 
impact, the worst mistakes have been fixed as the architecture evolved, 
and the engineering legacy remains, often in unexpected places.

  Maciej

  parent reply	other threads:[~2024-07-01 23:48 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-03  8:11 [PATCH 00/14] alpha: cleanups for 6.10 Arnd Bergmann
2024-05-03  8:11 ` [PATCH 01/14] alpha: sort scr_mem{cpy,move}w() out Arnd Bergmann
2024-05-03  8:11 ` [PATCH 02/14] alpha: fix modversions for strcpy() et.al Arnd Bergmann
2024-05-03  8:11 ` [PATCH 03/14] alpha: add clone3() support Arnd Bergmann
2024-05-03  8:11 ` [PATCH 04/14] alpha: don't make functions public without a reason Arnd Bergmann
2024-05-03  8:11 ` [PATCH 05/14] alpha: sys_sio: fix misspelled ifdefs Arnd Bergmann
2024-05-03  8:11 ` [PATCH 06/14] alpha: missing includes Arnd Bergmann
2024-05-03  8:11 ` [PATCH 07/14] alpha: core_lca: take the unused functions out Arnd Bergmann
2024-05-03  8:11 ` [PATCH 08/14] alpha: jensen, t2 - make __EXTERN_INLINE same as for the rest Arnd Bergmann
2024-05-03  8:11 ` [PATCH 09/14] alpha: trim the unused stuff from asm-offsets.c Arnd Bergmann
2024-05-03  8:11 ` [PATCH 10/14] alpha: remove DECpc AXP150 (Jensen) support Arnd Bergmann
2024-05-03 16:07   ` Linus Torvalds
2024-05-03 17:00   ` Al Viro
2024-05-03 20:07     ` Arnd Bergmann
2024-05-03  8:11 ` [PATCH 11/14] alpha: sable: remove early machine support Arnd Bergmann
2024-05-03  8:11 ` [PATCH 12/14] alpha: remove LCA and APECS based machines Arnd Bergmann
2024-05-03  8:11 ` [PATCH 13/14] alpha: cabriolet: remove EV5 CPU support Arnd Bergmann
2024-05-03  8:11 ` [PATCH 14/14] alpha: drop pre-EV56 support Arnd Bergmann
2024-05-04 15:00   ` Richard Henderson
2024-05-06 10:06     ` Arnd Bergmann
2024-06-03  6:02   ` Jiri Slaby
2024-06-04 13:58     ` Greg KH
2024-05-03 16:06 ` [PATCH 00/14] alpha: cleanups for 6.10 Matt Turner
2024-05-03 20:15   ` Arnd Bergmann
2024-05-06  9:16     ` Michael Cree
2024-05-06 10:11       ` Arnd Bergmann
2024-05-03 16:53 ` John Paul Adrian Glaubitz
2024-05-03 17:19   ` Paul E. McKenney
2024-05-27 23:49   ` Maciej W. Rozycki
2024-05-28 14:43     ` Paul E. McKenney
2024-05-29 18:50       ` Maciej W. Rozycki
2024-05-29 22:09         ` Paul E. McKenney
2024-05-30 22:59           ` Maciej W. Rozycki
2024-05-31  3:56           ` Maciej W. Rozycki
2024-05-31 19:33             ` Paul E. McKenney
2024-06-03 16:22               ` Maciej W. Rozycki
2024-06-03 17:08                 ` Paul E. McKenney
2024-07-01 23:50                   ` Maciej W. Rozycki
2024-05-30  1:08         ` Linus Torvalds
2024-05-30 22:57           ` Maciej W. Rozycki
2024-05-31  0:10             ` Linus Torvalds
2024-06-03 11:09               ` Maciej W. Rozycki
2024-06-03 11:36                 ` John Paul Adrian Glaubitz
2024-06-03 16:57                 ` Linus Torvalds
2024-07-01 23:48                   ` Maciej W. Rozycki
2024-05-31 15:48         ` Arnd Bergmann
2024-05-31 16:32           ` Linus Torvalds
2024-05-31 16:54             ` Arnd Bergmann
2024-06-01 13:51             ` David Laight
2024-07-01 23:48             ` Maciej W. Rozycki [this message]
2024-07-02  1:13               ` Linus Torvalds
2024-07-03  0:12                 ` Maciej W. Rozycki
2024-07-03  0:50                   ` Linus Torvalds
2024-07-04 22:21                     ` Maciej W. Rozycki
2024-06-03 11:33           ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.21.2406302009480.43454@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=frank.scheiner@web.de \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=ink@jurassic.park.msu.ru \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mattst88@gmail.com \
    --cc=maz@kernel.org \
    --cc=mcree@orcon.net.nz \
    --cc=paulmck@kernel.org \
    --cc=richard.henderson@linaro.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).