Re: [Firebird-devel] 64/32 bit handle compatibility

[Jim S. <ja...@ne...>]

James K. Lowden wrote:

>Finally, it's clear to me.  Some newer (not Alpha or Sparc) 64-bit
>architectures support 32- and 64-bit addressing modes in a single process.
> On such a chip, a 32-bit clients won't be able to link safely to an
>embedded 64-bit server, because their definitions of void* differ.  Is
>that it?  
>
In theory, yes, in practice, I think not.  Both the Ultra-sparc and 
AMD64 support 64 bit with additional instructions leaving the original 
instruction set unchanged.  But doing so is chaos as the calling 
sequences are different.  I may be wrong, but I believe that neither the 
linkers not dynamic loaders allow mixing of 32 and 64 bit modules.  I 
don't know whether the OS knows whether the process is 32 or 64 bit, but 
I think it's moot since mixing doesn't work.

The system services have to be 64 on hybrid systems, requiring a 
thunking front end for 32 bit processes.

Interesting enough, Solaris compilers and linkers default to 32 bit 
while Fedora defaults to 64 bit.  This is probably more whim than 
anything else.  But very, very few use processes benefit from > 32 
address space.  This will grow, but most problems aren't that hard.  The 
exceptions justify the architecture, however.

Firebird doesn't know what to do with a large address space.  Hint: page 
cache isn't the answer.

For fixed resources, a mix of most 32 bit process and the few 64 bit 
process that can benefit is probably the right answer.  Time, 
presumably, will tell.

>
>If I understand you correctly, a 32-bit executable could link to a 64-bit
>shared object, blithely unaware that their pointers are different sizes. 
>It that really true?  Because, if so, it would be a much bigger problem
>than our one little handle.  How, for instance, would such a pair exchange
>file handles, which POSIX defines as a pointer to a "structure containing
>information about a file"?[1]  
>
Doesn't work at all.  The unit in all calling sequences has to be the 
address length, so mixing 32 and 64 bits is never going to work without 
a lot of effort.

>Why would anyone choose to run this kind of mixed model, when he could
>just recompile one or the other module?  
>
32 bit processes are much smaller, so you get more processes per unit of 
memory.  But memories are bigger (the smallest 32 bit machine I've seen 
offered for sale is 512MB, which used to be a huge honkin' hunk of memory).

>If it's advantageous to run a 32-bit client and a 64-bit server on the
>same machine, would it be just as well to force them to use a remote
>interface instead?
>  
>
It's highly application specific.  For many applications, a huge number 
of embedded engines is the way to go.  Until the thread stack space is 
blown, 32 bits looks attractive.  When you start to put the 32 address 
space limites, 64 bits is the escape, but each stack does double in 
size.  Heap bloats less, but not by a lot.

Thinking about it leave me with a headache.  The solution is an easily 
configurable system and a stop watch.  Reality trumps speculation every 
time.