What's up with 64 bit Linux

[Chris Gehlker]

On Nov 23, 2007, at 7:59 AM, Darrin Chandler wrote:

> On Fri, Nov 23, 2007 at 07:29:38AM -0700, Chris Gehlker wrote:
>> And I'm increasing under the impression that it isn't except the very
>> small area, basically the virtual memory manager, where it needs to  
>> be
>> to support 64-bit applications. Windows got this wrong - basically
>> they went to an all 32-bit or all 64-bit world - and I was initially
>> under the impression that Linux did too. But now I think that linux
>> got it right. I don't know why Windows got it so wrong, those people
>> aren't stupid. If I had to speculate, AI'd guess it  had something to
>> do with their ABI. Maybe you  simply can't link 32-bit libraries into
>> 64-bit code in the Windows world.
>
> I've been reading along in this discussion, and it's been  
> interesting so
> far. :)
>
> If it's best to use 32-bit code unless you have a compelling reason  
> for
> 64-bit, doesn't the same hold true for 16-bit? It would be twice as
> compact as 32-bit code, so twice as much would fit in cache.

That's a keen observation and it leads to a story. When I got into  
computing, everybody knew that the x86 architecture was dead. One of  
the secrets to fast execution was fast decode and the secret to fast  
decode was a simplified and consistent instruction set. So the A team  
engineers went to work on Very Long Instruction Word architectures  
like Itanium and Power. Then a funny thing happened. CPUs got fast  
faster than cache memory. Cache memory got fast faster than main  
memory. Main memory got fast fast faster than disk. And while x86  
instructions may  be quirky, they are also terse. They  are the 16-bit  
instructions you  mention.

So now we have chips like the Core 2 family that are essentially a  
bunch of silicon dedicated to translating x86 instructions into  
Itanium instructions bolted in front of an Itanium. And they actually   
work because CPUs have gotten so fast that they can do that  
translation as fast as the bus can feed them instructions.
> IIRC, there
> are reasons why you want 32-bit for Intel processors to run a "real"  
> OS,
> having less to do with bit width than the mode the processor is in.

According to Wikipedia, the x86-64 architecture  doesn't have  
"modes".  It supports all the x86 instructions except for a few that  
were never actually used by compiler writers. In  addition it has some  
64 bit instructions. I'm still unclear as to whether there were/are  
some 64-bit Pentiums that do have modes. I increasingly doubt it.
>
>
> I have two 64-bit boxes running 64-bit OS. They are both in colo, and
> they run until I reboot them (i.e., they are quite stable). Two points
> about that: 1) neither box has an Intel processor (why use Intel for
> 64-bit?!  they seem to suck at it), and 2) the boxes are running  
> neither
> Windows nor Linux (I bring that up because I can't comment on Fedora
> stability or performace in 64-bit). I also have a couple of old 64-bit
> boxes at home. They are old enough to be slow, but one of which I used
> recently for quite a while as a desktop machine, including running
> Firefox, and it worked fine. Once again, not Windows or Linux, and not
> an Intel processor.
>
> I just find it interesting that there's all this talk of 64-bit on  
> Intel
> processors. I never considered them much of a player in 64-bit. I'd  
> love
> to hear how and why you people have done so. I don't want flames: I'm
> truly curious.

I think it's the whole terse is faster than elegant thing. If some  
technology can along that sped up disk and  main memory relative to  
the CPU,  the interest would fade again.


--
A young idea is a beautiful and a fragile thing. Attack people, not  
ideas.