[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Calling x86 code from 64-bit code



G'day Russell,

On Mon, Dec 15, 2003 at 05:54:59PM +1100, Russell Coker wrote:
> On Mon, 15 Dec 2003 16:40, Xavier Roche <rocheml@httrack.com> wrote:
> > Paul Brook wrote:
> > > Not really. It can run both 32-bit and 64-bit processes under the control
> > > of a 64-bit kernel. Linking 32-bit libraries into 64-bit apps is for most
> > > practical purposes impossible.
> >
> > The rellocation process is not done? This is something that could be
> > problematic Maybe there's a need for a "dlopen32" ?
> 
> Why not just have a proxy program?  You could have a 32bit program which calls 
> the DLL and communicates with the 64bit process via shared memory and unix 
> domain sockets.  You could also do the same thing for 64bit libraries and 
> 32bit applications.
> 
> For some libraries (libcrypto and zlib) having a 32bit application call 64bit 
> code by proxy may even provide a performance boost...

Since this is about a general cross-architectural issue, one point is that on
several 64/32 combos the 32 is often faster. So the default on LinuxPPC distros
for 64-bit PPC was (still is??) to have nearly everything 32-bits, for example
-- it simply made no difference for any ordinary app. A discussion of this
story and how it is different in the case of AMD is at
http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg00796.html.

This is called thunking btw and as far as I know it was invented by
IBM/Microsoft for OS/2 and made worse in Windows 95. From
http://www.ddj.com/documents/s=952/ddj9614c ...

> One of the most difficult areas of Windows 95 programming is thunking. Many of
> the 32-bit system DLLs in Windows 95 rely heavily on 16-bit code. For example,
> when your 32-bit program calls GetMessage, control ultimately ends up in the
> GetMessage routine in the 16-bit USER.EXE. Likewise, there are many places
> where 16-bit system code makes calls to 32-bit system DLLs. For example, when
> creating a new window, the 16-bit USER.EXE thunks up to KERNEL32.DLL to
> allocate memory for the window's data from a 32-bit heap. Windows 95 handles
> both types of thunks (32- to 16-bit, and 16- to 32-bit) seamlessly.

-- 
Dan Shearer
dan@shearer.org

Coming to http://linux.conf.au? See Russell Coker?, Rasmus, Havoc,
Conrad, Phil Hazel, Bdale, maddog, Grog, Keith P ... 



Reply to: