[Gllug] Kernel compile taking forever...!

[Nix]

On Wed, 2 Feb 2005, Jack Bertram whispered secretively:
> * Nix <nix at esperi.org.uk> [050202 00:45]:
>> On Tue, 1 Feb 2005, Jack Bertram murmured woefully:
>> > So I thought I would get this system working properly and then try
>> > an AMD64 installation on a new partition.
>> 
>> I'd use a chroot ;)
> 
> Hmmm.  What do you mean? - the rest of your email seems to suggest that
> you don't need a chroot.

The `chroot' bit is for the `separate installation', not for the
32/64-bit split.

> Surely I can't run 64bit code without a 64bit kernel, and I can't run
> one of those in a chroot.

Oh, I thought your *kernel* was already 64-bit. (I'm used to the
UltraSPARC universe, where the Linux kernel is always and only 64-bit.)

If AMD64 does things anything like UltraSPARC (and I've heard that it
does), you'll not need a 64-bit userspace to start with, so you could
try just replacing your current kernel with a 64-bit one.

> I suppose I could install AMD64 and set up a 32-bit chroot, but what is
> a 32-bit chroot?  Could I then run OO.o?

Basically it's a chroot with all separate binaries and libraries; but
you don't need a chroot for *that* at all. ld.so keeps 64-bit and 32-bit
libraries separate (stick the 64-bit libs in /lib64 and /usr/lib64
rather than /lib and /usr/lib).

>> Once you hit userspace, the 32- and 64-bit stuff is basically separate
>> universes. They split apart down inside the kernel, where an indirection
>> layer transforms 32-bit system call into the kernel's native 64-bit
>> ones, and all the code above that inherits that `bitness'.
>> 
>> So you need separate userspaces, pretty much: the filesystem is shared,
>> and interprocess communication can reach across the divide, but each
>> process is either 32- or 64-bit, never a mixture.
> 
> These seems to suggest that they're completely compatible as long as
> programs don't use assembler?

They're completely *incompatible*. The number of registers is different,
their sizes are different, the ABI and function calling conventions are
different (floating-point args are passed in SSE registers, to start
with)...

It *is* possible to have 64-bit and 32-bit code call each other (the
kernel has to do it to allow 32-bit code to make syscalls at all), but
it requires some fairly annoying assembler and even more annoying
argument size conversion code. Nobody except for the kernel bothers to
do any such conversion.

The filesystem formats and so on will be compatible, although idiot
programs that do things like writing binary lumps out to disk will break.
(There are very few such programs because they'd break on lots of other
architectures too, like architectures with a different byte-order.)

>> (I've got a mixed 32 and 64-bit SPARC/Linux userspace here: unlike on
>> AMD64, there are significant speed costs in compiling stuff as 64-bit on
>> UltraSPARC, so the majority of my userspace is 32-bit. The XEmacs I'm
>> typing this mail in is 64-bit, though.)
> 
> 64-bit code runs slower on an UltraSPARC than 32-bit code?

Assuming both are compiled for UltraSPARC, yes: unlike the x86-64, which
has a crippled 32-bit mode for IA32 compatibility, the UltraSPARC's
32-bit mode is pretty much as capable as its 64-bit one, with the single
notable difference that register sizes and natural alignment are 32-bit
rather than 64-bit.

So in 64-bit code, most code and data is twice the size it was when it
was 32-bit, which means it fills the cache faster, hits the memory bus
faster...

(The Emacs family, however, like most Lisp interpreters, do weird
bit-banging type-tagging tricks, and really like having 64 bits to play
with rather than 32: grabbing a few bits off the top of each Lisp object
for type tagging is a lot more ignorable when you have 64 of them to
play with...)

-- 
`Blish is clearly in love with language. Unfortunately,
 language dislikes him intensely.' --- Russ Allbery
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug