super hannakwannamastice to everyone!

is there a way to build v8 on 64bit linux so that it is a true 64 bit
library....or is it only possible as 32bit?

thanks! -august.

Currently the javascript compiler produces 32 bit machine code (Intel
or ARM).  There have been discussions in the past on this subject.  It
seems 64bit support is not considered a priority by the developers.
My impression is it will not be done until market conditions demand
it.

Personally I have not yet had any need to produce 64 bit executables.
The 32 bit executables run fine on a 64 bit Linux kernel and I don't
have to worry about managing different sets of binaries.

--
Bryan White

I'm just having trouble now trying to mix it with a library that I can
only compile in native 64 mode.   But, it really is just a lack of
knowledge on my part on how to compile from a 64 bit os into 32bit.  

Is it really that hard to make v8 64 bit compliant?

-a.

2008/12/24 august <aug...@alien.mur.at>:

Yes.

(the following is specific to OS X, which I'm working on, but I'm not
guessing that Linux or Windows are any less restricted in the
respective topics)

First of all, the generated code needs to be of the same arch as the
actual generator, which means we need an x86-64 codegen. The x86
codegen can probably form a solid base for this, but it will need a
nontrivial amount of work.  The reason is that you cannot run both
Protected Mode and Long Mode code in a single process on any operating
systems I know of, and machine instruction interpretation varies in
crucial areas between the two. One of the extra complexities involved
in this task is handling the different calling conventions between
*NIX and Windows (everybody but Microsoft uses the convention
specified by AMD, but guess who has the largest market share).

Second, the V8 code makes some 32-bit specific assumptions: That
sizeof(int) == sizeof(void*), that memory allocated by malloc/valloc
can be executed directly (in x86-64 it can't; you need to disable the
No eXecute bit with mprotect, and when memory is executable, it isn't
writable -- at least not on my system (OS X)).

Third, this has implications for garbage collection. V8 manages code
and data in the same heaps, but since code needs special handling in
x86-64, I can imagine that the garbage collector would need some
modification. As mentioned, on amd64 platforms you need to explicitly
allow execution of memory blocks, and this permission sytem works on
at least a per-page basis, so all blocks of code need to be allocated
on a page boundary, which restricts GC flexibility somewhat. If there
are ways to circumvent this, I'm not aware of them.

These problems are definitely solveable, but since there's not really
any real incentive to do so, I'm doubting that it will happen very
soon. :-P

- Simon