[NOT FOR COMMIT] Native Client builds of V8 on ia32 and x64.

Native Client builds of V8 on ia32 and x64.

[NOTE: This master CL includes all the intended changes for NaCl support on V8. It is useful to see things the whole and for verification, although for commit I am creating smaller CLs that are hopefully easier to review.]

This port uses the ARM code generator and interpreter to allow a
temporary low-performance solution pending availability of NaCl
JIT ports or a fast portable interpreter.

This patch supports V8-style build and test targets, e.g.
   make nacl_ia32.check nacl_x64.check
All unit tests should pass, modulo skipped tests as per
mjsunit.status and cctests.status.

BUG=

[Brad Chen, 2013-04-03 23:39:47]

PTAL

[Brad Chen, 2013-04-04 03:17:16]

On 2013/04/03 23:39:47, Brad Chen wrote:
> PTAL

I was thinking on the way home this might be easier to review in smaller pieces,
although you would loose the big picture. Unless I hear objections from you I
will break this into smaller pieces (tomorrow).

[danno, 2013-04-04 11:36:26]

That's fine. 

I briefly looked at the changes, and the one thing that sticks out is the
simulator changes that are really hard-switched on x64 NaCL. Is there any way to
unify the implementation so that they are common, even if that means changing
the non-nacl impl?

[Brad Chen, 2013-04-04 14:28:05]

On 2013/04/04 11:36:26, danno wrote:
> That's fine. 
> 
> I briefly looked at the changes, and the one thing that sticks out is the
> simulator changes that are really hard-switched on x64 NaCL. Is there any way
to
> unify the implementation so that they are common, even if that means changing
> the non-nacl impl?

For integer calls that shouldn't be a problem. For calls with floating point
args, I would need to know the variety of function prototypes that need to be
supported, not obvious to me from the code. Would it be possible for somebody
who knows this code better to help me understand that?

Background: For x86-32, integer and FP arguments appear in order on the stack.
For x86-64, FP args (up to eight) are passed in FP registers. In the current
code, the call sites are generic. To make them portable they would need to be
matched to the callee prototype.

[danno, 2013-04-04 14:29:18]

ulan, can you please help answer some of Brad's questions?

[ulan, 2013-04-04 14:53:46]

> I would need to know the variety of function prototypes that need to be
supported, not obvious to me from the code.

src/assembler.h defines builtin types that take doubles:

    // Builtin that takes float arguments and returns an int.
    // int f(double, double).
    BUILTIN_COMPARE_CALL,

    // Builtin call that returns floating point.
    // double f(double, double).
    BUILTIN_FP_FP_CALL,

    // Builtin call that returns floating point.
    // double f(double).
    BUILTIN_FP_CALL,

    // Builtin call that returns floating point.
    // double f(double, int).
    BUILTIN_FP_INT_CALL,

[Brad Chen, 2013-04-04 15:23:08]

On 2013/04/04 14:53:46, ulan wrote:
> > I would need to know the variety of function prototypes that need to be
> supported, not obvious to me from the code.
> 
> src/assembler.h defines builtin types that take doubles:
> 
>     // Builtin that takes float arguments and returns an int.
>     // int f(double, double).
>     BUILTIN_COMPARE_CALL,
> 
>     // Builtin call that returns floating point.
>     // double f(double, double).
>     BUILTIN_FP_FP_CALL,
> 
>     // Builtin call that returns floating point.
>     // double f(double).
>     BUILTIN_FP_CALL,
> 
>     // Builtin call that returns floating point.
>     // double f(double, int).
>     BUILTIN_FP_INT_CALL,

Thanks; this looks relevant. Is it obvious that these are the only prototypes
that can be used? If so, the next question would be how to distinguish
BUILTIN_FP_INT_CALL from the others in simulator-arm.cc, although perhaps I'll
have to figure that out on my own.

[ulan, 2013-04-04 16:38:17]

https://codereview.chromium.org/13520004/diff/2001/src/arm/simulator-arm.cc
File src/arm/simulator-arm.cc (right):

https://codereview.chromium.org/13520004/diff/2001/src/arm/simulator-arm.cc#n...
src/arm/simulator-arm.cc:1767: UNREACHABLE();
> Is it obvious that these are the only prototypes that can be used?
Yes, I think so because of this line.
> If so, the next question would be how to distinguish
BUILTIN_FP_INT_CALL from the others in simulator-arm.cc
If I understood the question correctly, you can check redirection->type() like
it is done in this switch statement.

[Brad Chen, 2013-04-04 16:42:26]

On 2013/04/04 16:38:17, ulan wrote:
> https://codereview.chromium.org/13520004/diff/2001/src/arm/simulator-arm.cc
> File src/arm/simulator-arm.cc (right):
> 
>
https://codereview.chromium.org/13520004/diff/2001/src/arm/simulator-arm.cc#n...
> src/arm/simulator-arm.cc:1767: UNREACHABLE();
> > Is it obvious that these are the only prototypes that can be used?
> Yes, I think so because of this line.
> > If so, the next question would be how to distinguish
> BUILTIN_FP_INT_CALL from the others in simulator-arm.cc
> If I understood the question correctly, you can check redirection->type() like
> it is done in this switch statement.

Thanks; makes sense now.

[Brad Chen, 2013-04-09 15:20:06]

Thanks for your help getting the first four patches landed. The next few will
be:
- change native function invocation from simulator-arm.cc to use accurate
function prototypes
- exclude one more test in mjsunit
- build system changes

Unlike the previous CLs, some of these change paths used by all systems, so I
expect you will want to stare at them a little bit longer. Land the build
changes last. Once that's done hopefully setting up bots will follow naturally.

Brad

On 2013/04/04 16:42:26, Brad Chen wrote:
> On 2013/04/04 16:38:17, ulan wrote:
> > https://codereview.chromium.org/13520004/diff/2001/src/arm/simulator-arm.cc
> > File src/arm/simulator-arm.cc (right):
> > 
> >
>
https://codereview.chromium.org/13520004/diff/2001/src/arm/simulator-arm.cc#n...
> > src/arm/simulator-arm.cc:1767: UNREACHABLE();
> > > Is it obvious that these are the only prototypes that can be used?
> > Yes, I think so because of this line.
> > > If so, the next question would be how to distinguish
> > BUILTIN_FP_INT_CALL from the others in simulator-arm.cc
> > If I understood the question correctly, you can check redirection->type()
like
> > it is done in this switch statement.
> 
> Thanks; makes sense now.