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? - Simon 2008/10/16 Feng Qian <[EMAIL PROTECTED]>: > > 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, <[EMAIL PROTECTED]> 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. >> >> Morgaine. >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
