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

[lists at openmailbox.org]

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.

-- 
Please DO NOT COPY ME on mailing list replies. I read the mailing list.
RSA 4096 fingerprint 7940 3F02 16D3 AFEE F2F8  ACAA 557C 4B36 98E4 4D49