I was playing around with the v8 code today and I noticed it forces -
m32 into any build on a 64 bit machine.
I disabled that check so I can see why and noticed it's actually
covering up several 32 bit assumptions such as being able to cast a
pointer into and int etc..
A few of them look easy enough to fix because they are just error
printfs but some other ones probably would need a bit more
understanding of the repercussions to fix.
Are there plans to fix that so the code can build properly on 64
bit? It's a pretty big limitation to not be able to link against it
when the rest of your code is 64 bit compat.
On Mon, Sep 29, 2008 at 12:54 PM, <anthony.miness...@gmail.com> wrote:
> Are there plans to fix that so the code can build properly on 64 > bit? It's a pretty big limitation to not be able to link against it > when the rest of your code is 64 bit compat.
I think the V8 code generator only supports ia32 and ARM targets, and there is no support in the code generator for x86-64 nor an interpreted mode.
Also, and I don't think this is an official standpoint, but I've heard prominent figures within the V8/Chromium teams express reluctance to support x86-64 code generation anytime soon, since it would roughly double the amount of memory needed for V8 applications (it uses *a lot* of pointers), and is not currently necessary to support at all, since all major operating systems for x86-64 CPUs can run x86 code just fine.
Look into your heart and ask yourself the question: Am I wanting to compile V8 for x86-64 for any other reason than vanity, pride, and cosmetics? ;-)
Joking aside, it would be "nice" with a native x86-64 version of V8, but I don't believe it's a priority for the Google teams. V8 is open source, however, so if you feel like it, I'm sure it would be considered a very valuable addition to the code base. :-)
> On Mon, Sep 29, 2008 at 12:54 PM, <anthony.miness...@gmail.com> wrote:
>> Are there plans to fix that so the code can build properly on 64 >> bit? It's a pretty big limitation to not be able to link against it >> when the rest of your code is 64 bit compat.
> I think the V8 code generator only supports ia32 and ARM targets, and > there is no support in the code generator for x86-64 nor an > interpreted mode.
If V8 devs have good technical reasons why V8 should not run in 64-bit
mode (double the pointer size is a pretty flimsy reason, since the
vast majority of Javascript programs are too small for it to matter),
then that's fine. However, this is not a good reason for abandoning
everyone whose applications are 64-bit for solid technical reasons,
eg. thousands of scientific programmers, but who still want to run V8
for their scripting.
If V8 isn't going to be made available in a 64-bit version, then at
the very least a compatibility or 32-bit emulation/interfacing library
should be created, so that 64-bit applications can run with 32-bit V8
in some way other than by direct linkage.
> If V8 devs have good technical reasons why V8 should not run in 64-bit > mode (double the pointer size is a pretty flimsy reason, since the > vast majority of Javascript programs are too small for it to matter), > then that's fine. However, this is not a good reason for abandoning > everyone whose applications are 64-bit for solid technical reasons, > eg. thousands of scientific programmers, but who still want to run V8 > for their scripting.
> If V8 isn't going to be made available in a 64-bit version, then at > the very least a compatibility or 32-bit emulation/interfacing library > should be created, so that 64-bit applications can run with 32-bit V8 > in some way other than by direct linkage.
> I doubt the V8 tail will ever wag the Chrome dog.
On Oct 10, 2008, at 10:59 PM, Morgaine.Din...@googlemail.com wrote:
> But the tail is allowed to wag independently for 20% of the day at > Google. ;-)
It's conceivable, though "independently" isn't the word I would use. The bottom line is that there would need to be something resembling a business reason to add 64-bit support to V8. If there is one, you and I are not in a position to know what it is (though obviously we could speculate). In fact, if any such reason does exist, I expect it has little if anything to do with you and I.
On Thu, Oct 9, 2008 at 3:08 PM, <Morgaine.Din...@googlemail.com> wrote:
> If V8 devs have good technical reasons why V8 should not run in 64-bit > mode (double the pointer size is a pretty flimsy reason, since the > vast majority of Javascript programs are too small for it to matter), > then that's fine. However, this is not a good reason for abandoning > everyone whose applications are 64-bit for solid technical reasons, > eg. thousands of scientific programmers, but who still want to run V8 > for their scripting.
> If V8 isn't going to be made available in a 64-bit version, then at > the very least a compatibility or 32-bit emulation/interfacing library > should be created, so that 64-bit applications can run with 32-bit V8 > in some way other than by direct linkage.
Adding to that, there is also a fair amount of 32-bit assumptions in the code (such as the assumption that sizeof(int) == sizeof(void*)), which aren't guaranteed to hold on 64-bit platforms. Fixing these may turn out to be easy, or it may turn out to require a major restructuring (I certainly hope not).
Feng, or anyone from the V8 or Chromium team, what's your gut feeling about this?
> You missed most complicated part of porting V8 to 64-bit platform: > garbage collection.
> During GC, pointers are encoded using 32-bit address. To make V8 work on 64-bit, > there might be fair amount of work to get GC right.
> We'd like to see V8 run on more platforms, but limited by the time and > energy, we can > only support 32-bit and ARM at moment.
> On Thu, Oct 9, 2008 at 3:08 PM, <Morgaine.Din...@googlemail.com> wrote:
>> If V8 devs have good technical reasons why V8 should not run in 64-bit >> mode (double the pointer size is a pretty flimsy reason, since the >> vast majority of Javascript programs are too small for it to matter), >> then that's fine. However, this is not a good reason for abandoning >> everyone whose applications are 64-bit for solid technical reasons, >> eg. thousands of scientific programmers, but who still want to run V8 >> for their scripting.
>> If V8 isn't going to be made available in a 64-bit version, then at >> the very least a compatibility or 32-bit emulation/interfacing library >> should be created, so that 64-bit applications can run with 32-bit V8 >> in some way other than by direct linkage.
|
