On Fri, Oct 5, 2012 at 3:29 PM, Paweł Hajdan, Jr.
<[email protected]>wrote:

> On Tue, Oct 2, 2012 at 4:32 PM, Jakob Kummerow <[email protected]>wrote:
>
>> V8 does not support x32 at this time. Sorry.
>
>
> OK - do you plan to add that support? Just asking e.g. so I can take the
> right action as maintainer of v8 package in Gentoo. It's fine for me if you
> don't have such plans. :)
>

No. (For reasoning, see below.)


>
>> Adding support is not just a matter of fixing a few lines. It would be an
>> entire new platform port (albeit similar to the existing ia32/x64 ports);
>> roughly 40K lines of code.
>>
>
> Got it. For reference - would you accept patches adding such a port? Note
> that I'm rather not going to work on it atm, but someone else might be
> interested.
>

It's not just the initial creation of a new platform port that's a bunch of
work, it's also the ongoing maintenance of it (i.e. making it keep up with
the continuing development of V8). As long as the potential user base for
x32 is as small as it currently is, it doesn't make sense for the team to
spend resources on that.

The obvious alternative is a third-party maintained port in a separate
repository that tracks V8, as our MIPS port is currently doing it (
https://github.com/paul99/v8m-rb). This model can work with or without
upstreaming of the changes, but either way with a clear statement that the
core V8 team does not commit to making sure the port works and is up to
date.


>
>> The reason is that V8 is not just any C++ program which you can simply
>> compile for x32 -- it's actually a compiler of its own and emits native
>> code, so it has to know about registers, machine instructions, calling
>> conventions and all the other stuff that differentiates x32 from ia32 and
>> x64. AFAIK x32 and ia32 are incompatible enough that V8's ia32 port will
>> probably just crash on an x32 system (I'm kind of surprised that it
>> compiles at all).
>>
>
> FYI, I ran ia32 d8 on that x32 system and on simple cases like "a = 8" or
> "for (a = 0; a < 10; a++);" it didn't crash. Anyway, trying to combine
> resulting v8 shared library with x32 ABI binaries would indeed cause
> trouble.
>

Hm... I would have expected the interaction of assembly stubs and C++
compiled code to be broken/crashy right inside V8. Maybe the ia32 and x32
calling conventions are more similar than I thought (haven't spent time
with the technical specification yet). Does the test suite ("make
ia32.release.check TESTJOBS=-j4" or whatever many cores you have) pass? Do
Chromium and/or node.js work on x32? There is no way the ia32 version of V8
will make use of x32's benefits (more registers, instructions and so on),
but if it happens to work without obvious errors, you could simply make it
available to users running x32 systems, as it would be better than nothing
:-)


>
>> On Tue, Oct 2, 2012 at 3:40 PM, Paweł Hajdan, Jr. <
>> [email protected]> wrote:
>>
>>> Is v8 expected to support x32 ABI? I tried "make native" (using v8
>>> bleeding_edge, r12652) on an x32 ABI Gentoo install, and it failed with
>>> e.g.:
>>>
>>> In file included from ../src/conversions-inl.h:35:0,
>>>                  from ../src/conversions.cc:32:
>>> ../src/globals.h:243:33: warning: overflow in implicit constant
>>> conversion [-Woverflow]
>>> ../src/globals.h:244:38: warning: large integer implicitly truncated to
>>> unsigned type [-Woverflow]
>>> ../src/atomicops_internals_x86_gcc.h: In function 'void
>>> v8::internal::Acquire_Store(volatile Atomic64*, v8::internal::Atomic64)':
>>> ../src/atomicops_internals_x86_gcc.h:222:13: error: redefinition of
>>> 'void v8::internal::Acquire_Store(volatile Atomic64*,
>>> v8::internal::Atomic64)'
>>> ../src/atomicops_internals_x86_gcc.h:122:13: error: 'void
>>> v8::internal::Acquire_Store(volatile Atomic32*, v8::internal::Atomic32)'
>>> previously defined here
>>> ../src/atomicops_internals_x86_gcc.h: In function 'void
>>> v8::internal::Release_Store(volatile Atomic64*, v8::internal::Atomic64)':
>>> ../src/atomicops_internals_x86_gcc.h:227:13: error: redefinition of
>>> 'void v8::internal::Release_Store(volatile Atomic64*,
>>> v8::internal::Atomic64)'
>>> ../src/atomicops_internals_x86_gcc.h:149:13: error: 'void
>>> v8::internal::Release_Store(volatile Atomic32*, v8::internal::Atomic32)'
>>> previously defined here
>>> ../src/atomicops_internals_x86_gcc.h: In function
>>> 'v8::internal::Atomic64 v8::internal::NoBarrier_Load(const volatile
>>> Atomic64*)':
>>> ../src/atomicops_internals_x86_gcc.h:248:17: error: redefinition of
>>> 'v8::internal::Atomic64 v8::internal::NoBarrier_Load(const volatile
>>> Atomic64*)'
>>> ../src/atomicops_internals_x86_gcc.h:155:17: error:
>>> 'v8::internal::Atomic32 v8::internal::NoBarrier_Load(const volatile
>>> Atomic32*)' previously defined here
>>> ../src/atomicops_internals_x86_gcc.h: In function
>>> 'v8::internal::Atomic64 v8::internal::Acquire_Load(const volatile
>>> Atomic64*)':
>>> ../src/atomicops_internals_x86_gcc.h:252:17: error: redefinition of
>>> 'v8::internal::Atomic64 v8::internal::Acquire_Load(const volatile
>>> Atomic64*)'
>>> ../src/atomicops_internals_x86_gcc.h:159:17: error:
>>> 'v8::internal::Atomic32 v8::internal::Acquire_Load(const volatile
>>> Atomic32*)' previously defined here
>>> ../src/atomicops_internals_x86_gcc.h: In function
>>> 'v8::internal::Atomic64 v8::internal::Release_Load(const volatile
>>> Atomic64*)':
>>> ../src/atomicops_internals_x86_gcc.h:260:17: error: redefinition of
>>> 'v8::internal::Atomic64 v8::internal::Release_Load(const volatile
>>> Atomic64*)'
>>> ../src/atomicops_internals_x86_gcc.h:166:17: error:
>>> 'v8::internal::Atomic32 v8::internal::Release_Load(const volatile
>>> Atomic32*)' previously defined here
>>> ../src/atomicops_internals_x86_gcc.h: In function
>>> 'v8::internal::Atomic64 v8::internal::Acquire_CompareAndSwap(volatile
>>> Atomic64*, v8::internal::Atomic64, v8::internal::Atomic64)':
>>> ../src/atomicops_internals_x86_gcc.h:265:17: error: redefinition of
>>> 'v8::internal::Atomic64 v8::internal::Acquire_CompareAndSwap(volatile
>>> Atomic64*, v8::internal::Atomic64, v8::internal::Atomic64)'
>>> ../src/atomicops_internals_x86_gcc.h:94:17: error:
>>> 'v8::internal::Atomic32 v8::internal::Acquire_CompareAndSwap(volatile
>>> Atomic32*, v8::internal::Atomic32, v8::internal::Atomic32)' previously
>>> defined here
>>> ../src/atomicops_internals_x86_gcc.h: In function
>>> 'v8::internal::Atomic64 v8::internal::Release_CompareAndSwap(volatile
>>> Atomic64*, v8::internal::Atomic64, v8::internal::Atomic64)':
>>> ../src/atomicops_internals_x86_gcc.h:275:17: error: redefinition of
>>> 'v8::internal::Atomic64 v8::internal::Release_CompareAndSwap(volatile
>>> Atomic64*, v8::internal::Atomic64, v8::internal::Atomic64)'
>>> ../src/atomicops_internals_x86_gcc.h:104:17: error:
>>> 'v8::internal::Atomic32 v8::internal::Release_CompareAndSwap(volatile
>>> Atomic32*, v8::internal::Atomic32, v8::internal::Atomic32)' previously
>>> defined here
>>>
>>> On the other hand, "make ia32.release" succeeded, but I'm not sure if
>>> that's what should be done on x32.
>>>
>>> For more info about this issue on Gentoo, see
>>> https://bugs.gentoo.org/show_bug.cgi?id=423815
>>>
>>> In case you wonder what x32 ABI is all about, please take a look at
>>> http://en.wikipedia.org/wiki/X32_ABI and
>>> https://sites.google.com/site/x32abi/
>>>
>>> I have a working x32 install and can contribute patches, but any
>>> guidance and feedback is welcome.
>>>
>>> --
>>> v8-users mailing list
>>> [email protected]
>>> http://groups.google.com/group/v8-users
>>
>>
>>  --
>> v8-users mailing list
>> [email protected]
>> http://groups.google.com/group/v8-users
>
>
>  --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
>

-- 
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users

Reply via email to