[Info-vax] OT: news from the trenches (re: Solaris)

[David Froble]

lists at openmailbox.org wrote:
> On Fri, 13 Mar 2015 08:29:54 -0700 (PDT)
> John Reagan via Info-vax <info-vax at rbnsn.com> wrote:
> 
>> On Friday, March 13, 2015 at 10:05:05 AM UTC-4, li... at openmailbox.org
>> wrote:
>>
>>> 64 bit support was and is a disaster. 32 bit and 64 bit code can't
>>> coexist. The ABI is not upward compatible. You can't use 64 bit
>>> registers in a 32 bit piece of code running on 64 bit hardware. You
>>> can't call 32 bit code from 64 bit code and vice versa and you can't
>>> combine code written in both ABIs in one executable.
>> That is all software...  Recent versions of binutils added support for
>> the x32 ABI which lets you use 64-bit registers/instructions in a 32-bit
>> program.
> 
> Is it software or is it broken hardware design exposed in software?
> Regardless, that Intel is at fault, again, is strongly suggested.
> 
> Does anybody believe the #1 financial sponsor of Linux kernel development
> has no input, and they *still* can't get anything right?
> 
> http://www.linuxfoundation.org/news-media/announcements/2015/02/linux-foundation-releases-linux-development-report
> 
> We haven't even gotten into what happens with crypto in hardware as Intel
> is pushing (this has been discussed, especially with regard to Intel chips)
> as opposed to open source software. Broken RNGs and other fun stuff is a big
> enabler for p0nwing the world given the recent revelations on just how
> low certain groups will stoop to bamboozle the public.
> 
> http://cryptome.org/2013/07/intel-bed-nsa.htm
> http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/
> 
> Bottom line, the world being run on one chip means no security for anybody.
> Intel is bad for the hardware and software world like Linux is bad for the
> hardware and software world. One technology oozing and sliming over
> everything and blots out all the native species is destructive. No choice,
> no security, no problem. All your data are owned by U.S.
> 
> Anyway back to our discussion. I said in my email of Fri, 13 Mar 2015
> 06:28:17 -0700 (PDT): 
> 
> "If you have 32 bit code you have to have a 32 bit libc and all the other
> necessary libraries and for 64 bit code you have to have a 64 bit libc and
> other libraries. Why all the duplication? It's a broken implementation that
> nobody thought ahead 5 minutes implementing. And then they came up with X32
> that still doesn't solve the problems. Intel and their designs are a
> complete failure and incur a lot costs with endless compatability
> breakages, expense of twice as much code to run legacy apps, and
> recompiling things just to get 32 and 64 bit versions. They have never made
> a smooth transition on anything."
> 
> To address your comment, X32 doesn't solve the problems completely, as is
> expected of Intel. What it does is add features that should have been there
> initially, at the cost of complexity and bloat. With X32:
> 
> 1. x86 and x86_64 programs and libraries are still not interoperable
> 2. X32 programs still can't access 64 bit storage
> 3. a third, incompatible ABI is created
> 4. an entire new set of X32 libraries is required to support the ABI
> 5. programs from various ABIs still can't be mixed in execution path nor
>    linked in one executable
> 
> Basically the X32 ABI is about letting x86 code have access to more of the
> x86_64s registers. But if they had thought this through there could have
> been one ABI and everything could have worked together smoothly.
> 
> The first 64 bit AMD chip was shipped in what, 2003? And here we are in
> 2015, twelve years later and almost 4 years after X32 was introduced and
> about all there is in the way of actual rubber meets the road
> implementation of X32 is in binutils and maybe Gentoo. I am not aware of
> any mainstream Linux distro that has adopted it. Debian still has the hood
> up. I have no idea (and don't care) what Windows is doing.
> 
> This is yet another example in an endless line of Intel screwups, jamming
> garbage out the door in the beta test stage, "fixing" it with a solution
> that's arguably worse than the problem, and at the end of the day leaving
> us with new, unaddressed problems that all lead to increased memory
> footprint and other increases in resource utilization. There is just no
> planning and no understanding evident in anything they do. Or maybe there
> is, because it sells new hardware.
> 
>> The 32 vs 64 ABI differnces are indeed a pain.  OpenVMS supports mixed
>> pointer sizes on Alpha and Itanium.  You don't see mixed-pointer sizes in
>> the Linux world.  (NonStop also supports mixed pointer sizes).  You end
>> up picking the 64-bit ABI and constantly sign-extending 32-bit pointers
>> all over the place.  Even the varargs in the 32-bit vs 64-bit ABI is
>> quite different.  I find the 64-bit version confusing but that is what is
>> out there.
> 
> I agree. And there are other platform where this was done intelligently and
> cleanly.
> 
>> Things like instruction encoding aren't meaningful to most people.  Look
>> at the Itanium bit encoding if you want to turn your stomach.
> 
> I know that and I have said it before. The problem is not Intel x86- it's
> Intel.
> 

Oh, come on, you can find more fault than that ....

What about the Intel compilers that check the CPU, and generate slower 
code for AMD CPUs ?????

It's a never ending list ....