John,

I read what Linus wrote and I think the most important paragraph is the last two.

This "deficiency" in the Alpha design was not that consequential to anyone but a very small number of people, and still allowed the Alpha to be the world's fastest microprocessor for (if I remember correctly) eight years in a row according to the Guinness Book of Records.

As to the little vs big endian issues, the worst part was in reading undefined data across the network.   What do I mean by "undefined data"?

o The union statement in "C"
o The equivalence statement in FORTRAN
o The Linkage section in Cobol

All statements that allow you to write the same data looking at it in different ways.   If you write out a "block" of Integers into a file, there is no way that a system reading that file some time later could tell if those integers were written by a little endian system or a big endian system, so the Integers would be read incorrectly.

NFS made it worse....much worse, but it was bad before NFS.

md



On Thu, Feb 4, 2021 at 5:37 PM John Stoffel <john@stoffel.org> wrote:
>>>>> "Jon" == Jon \"maddog\" Hall <jon.maddog.hall@gmail.com> writes:

Jon> John,
>> Yes, but I don't properly recall if the Itanium design was started
>> before AMD64 came or as a reaction to the AMD64.  Haven't done any
>> research for the real timelines.

Jon> Two single-line searches found that the Itanium was launched in
Jon> 2001 and the AMD x64 was launched in 2003.

Been neck deep in SFLT tape restore wrangling today.  Whee!!!

>> It's a shame the Alpha architecture didn't make it, even though it did
>> have some bad design decisions inside it's ISA and internal
>> architecture.  It was still a pretty nice and clean 64-bit design.  As
>> I recall, it's mostly the memory ordering around byte accesses that
>> are the problem.

Jon> This is the first I have heard of these bad decisions.  Would you care to elaborate?

It's in regards to memory ordering.  See this LKML post by Linus on
the topic.  This is what I'm talking about mostly.

   https://lkml.org/lkml/2012/2/1/521


Jon> The memory ordering around byte accesses might have been because
Jon> the Alpha was designed to be both little endian and big endian. 
Jon> So were the MIPS chips.   While many vendors supported only big
Jon> endian (Motorola, SPARC, etc.) DEC had been supporting little
Jon> endian in their PDP-11s, VAX, MIPS and Alphas for data
Jon> compatibility.   DEC supported little endian because it was
Jon> cheaper electronically to have the data held in that fashion.

Very much could be that is the reason.  I don't know. 

Jon> Sun made much fun of DEC for years having Unix systems that were
Jon> little endian instead of big endian like "real workstations".   I
Jon> kept asking them about these "Intel things" which were little
Jon> endian too.   Sun sneered at me and told me that "Intel chips
Jon> were not used in real computers".....that is until they ported
Jon> Solaris to Intel and tried to mix them into their network.   Then
Jon> I took real glee in asking them how they had data compatibility
Jon> across NFS between SPARC and Intel.

Gah, all the problems with writing socket code and having to do
translations from Network Byte Ordering to Host Byte Ordering.
hton[ls]() and the inverse.

Jon> As I said, you are the first to mention to me these bad
Jon> decisions.  I am curious to know what they are.

It's in terms of memory ordering on access.  See the above link.