"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.