Introduce processor detection in globals.h, instead of from the build system.

Introduce two separate classes of processor detection:
- TARGET, the architecture we will generate code for.
  This is brought it from the build system.
- HOST, the architecture our C++ compiler is building for.
  This is detected automatically based on compiler defines.

This adds macros for 32 or 64 bit, and cleans up some
include conditionals, etc.

[Dean McNamee, 2009-05-04 17:56:19]

Hey Ivan,

I didn't have the chance to finish this today, so I just check pointed what I
had.

I am guessing there are lots of things like naming, and perhaps you don't want
the CPU families, etc.

Thanks

[iposva, 2009-05-05 04:44:27]

Dean,

Thanks for the very informative writeup on how to best determine the host
architecture. I would have badly needed something like this in the past.
Generally I like the way this is going except that we need the target
architecture to be specified from the build system. Please see the comments
below.

-Ivan

http://codereview.chromium.org/99355/diff/1/2
File src/codegen.h (right):

http://codereview.chromium.org/99355/diff/1/2#newcode83
Line 83: #elif ARCH_CPU_ARMEL
I like this style better, especially if it ends with a
#else
#error Unknown architecture.
#endif

This makes it a lot easier to find places to patch when implementing a new
platform.

http://codereview.chromium.org/99355/diff/1/3
File src/execution.cc (right):

http://codereview.chromium.org/99355/diff/1/3#newcode39
Line 39: #elif ARCH_CPU_ARMEL
ditto

http://codereview.chromium.org/99355/diff/1/4
File src/frames-inl.h (right):

http://codereview.chromium.org/99355/diff/1/4#newcode37
Line 37: #elif ARCH_CPU_ARMEL
ditto

http://codereview.chromium.org/99355/diff/1/5
File src/globals.h (right):

http://codereview.chromium.org/99355/diff/1/5#newcode36
Line 36: //   or with gcc, run: "echo | gcc -E -dM -"
For general C++ code this seems like a good approach. In the past I have had
issues with defining the general architecture like this because usually you need
to build virtual machines with the correct blah_<cpu>.cc files, which is
controlled by the build system.
Additionally this particular approach does not work at all, if architecture
simulators are involved for the generated code parts, but not the C++ parts.
I guess what that means is that we have two things to worry about: host
architecture and a target architecture. Unless we want the complexity to explode
the word size of the target and host architectures have to match. The host
architecture can be determined in the fashion below while the target
architecture needs to be defined when invoking the build system.

I would suggest the following changes to the code with name updates and
additions/deletions to the definitions suggested here. V8_ARCH_* is the only
value to be defined by the build system and indirectly the build system driver.

#if V8_ARCH_X64
#define V8_64BIT 1
#define V8_LITTLE_ENDIAN 1
#elif V8_ARCH_X86
...
#else
#error Unknown target architecture.
#endif

#if defined(_M_X64) || defined(__x86_64__)
#define V8_HOST_ARCH_X64 1
#define CAN_READ_UNALIGNED 1  // This is generally needed for the host C++-based
code. The code generators usually know whether unaligned reads are supported.
#ifndef V8_ARCH_X64
#define V8_USING_SIMULATOR 1  // It is sometimes useful to know whether a
simulator is active in runtime code. For example when handling exceptions or
walking stacks.
#endif
#ifdef V8_32BIT
#error Wordsize mismatch.
#endif
#elif defined(_M_IX86) || defined(__i386__)
...
#else
#error Unknown host architecture.
#endif

http://codereview.chromium.org/99355/diff/1/5#newcode40
Line 40: #define ARCH_CPU_64_BITS 1
Names without a V8 prefix are more likely to collide with other definitions. I
also am not sure that having the CPU family defined is going to be of tremendous
help. In general the names we can fight over forever, so let's leave them out of
the discussion for now.

http://codereview.chromium.org/99355/diff/1/5#newcode50
Line 50: #error Your architecture was not detected as supported by v8
This could be a bit more specific that architecture/compiler combination was not
detected as supported by V8.

[Lasse Reichstein, 2009-05-05 08:57:59]

http://codereview.chromium.org/99355/diff/1/2
File src/codegen.h (right):

http://codereview.chromium.org/99355/diff/1/2#newcode79
Line 79: #if ARCH_CPU_X86
Should it be #if defined(ARCH_CPU_X86) ?

Calling it CPU isn't exactly right. What we are selecting is our backend, which
is correclated with the CPU, but not identical to it.
CPU seems too specific (e.g., Intel Xeon EM64T Irwindale 3.4GHz is a CPU, but
X64 or IA32 are architectures shared by several CPUs). I would prefer just
ARCH_IA32, or even better: V8_ARCH_IA32 :)

And use the traditional names for wintel architectures: IA32 and X64.

http://codereview.chromium.org/99355/diff/1/5
File src/globals.h (right):

http://codereview.chromium.org/99355/diff/1/5#newcode36
Line 36: //   or with gcc, run: "echo | gcc -E -dM -"
I agree with Ivan: We should treat target architecture and host architecture
separately, and again separatly from the heap model. The target architecture is
the one we generate code for. The host architecture is the one the compiler
generates code for. 
The heap model is the structure of our heap. We need different structures for
heaps using 32 and 64 bit pointers, but the size of a pointer might not be the
only difference between the two models.

As long as we have only one heap model for each architecture, I see no problem
in defining it here, based on V8_ARCH_*, but it should be its own symbol that is
used to make heap model decissions, not the V8_ARCH_* symbol. Especially since
IA32 and ARM has the same heap model.

So, define V8_HEAP_32BIT or V8_HEAP_64BIT here, depending on the V8_ARCH_* that
is set.

If we ever want to run the ARM simulator on a 64-bit runtime system, we can't
even link the wordsize of the host system with the wordsize of the generated
code. I hope that won't be necessary, so we can use only 64-bit heap models on
64-bit systems.

http://codereview.chromium.org/99355/diff/1/5#newcode107
Line 107: #ifdef ARCH_CPU_X86_64
This would be a case where it's V8_HEAP_64BIT that should select the longer
pointers, not V8_ARCH_X64.

http://codereview.chromium.org/99355/diff/1/5#newcode144
Line 144: #ifdef ARCH_CPU_X86_64
Ditto.

http://codereview.chromium.org/99355/diff/1/5#newcode514
Line 514: // type o a variable of another type.  Of course the end result is
likely to
Could you fix the typo here, "o" -> "of" :)

http://codereview.chromium.org/99355/diff/1/7
File src/jsregexp.h (right):

http://codereview.chromium.org/99355/diff/1/7#newcode42
Line 42: #else
I actually prefer to not have a default case, so that a completely unknown
architecture generates an error.
I.e., test for all the known ones, and generate an error if none match.

[Dean McNamee, 2009-05-05 11:16:23]

http://codereview.chromium.org/99355/diff/1/2
File src/codegen.h (right):

http://codereview.chromium.org/99355/diff/1/2#newcode79
Line 79: #if ARCH_CPU_X86
On 2009/05/05 08:57:59, Lasse Reichstein wrote:
> Should it be #if defined(ARCH_CPU_X86) ?

We learned this lesson from chrome, where we still do it the more annoying way.

- In C++ an undefined macro will evaluate to 0.
- #if defined() is more annoying.
- It is sometimes useful to be able to set things to 0, from the build system,
etc.

I think it makes things easier to read, but if people are really worried about
it, we can move everything to defined() :(

> 
> Calling it CPU isn't exactly right. What we are selecting is our backend,
which
> is correclated with the CPU, but not identical to it.
> CPU seems too specific (e.g., Intel Xeon EM64T Irwindale 3.4GHz is a CPU, but
> X64 or IA32 are architectures shared by several CPUs). I would prefer just
> ARCH_IA32, or even better: V8_ARCH_IA32 :)
> 
> And use the traditional names for wintel architectures: IA32 and X64.

http://codereview.chromium.org/99355/diff/1/2#newcode83
Line 83: #elif ARCH_CPU_ARMEL
On 2009/05/05 04:44:27, iposva wrote:
> I like this style better, especially if it ends with a
> #else
> #error Unknown architecture.
> #endif
> 
> This makes it a lot easier to find places to patch when implementing a new
> platform.

We will already get a #error since everything is included globals.h.  I'd rather
keep that in one place, and not have a copy/pasted error everywhere.

http://codereview.chromium.org/99355/diff/1/7
File src/jsregexp.h (right):

http://codereview.chromium.org/99355/diff/1/7#newcode42
Line 42: #else
On 2009/05/05 08:57:59, Lasse Reichstein wrote:
> I actually prefer to not have a default case, so that a completely unknown
> architecture generates an error.
> I.e., test for all the known ones, and generate an error if none match.

Completely unknown architectures are already going to cause an error by
including globals.h.  I would rather not have a #error with the same error
message every place where we need to select based on the architecture.

[Dean McNamee, 2009-05-05 11:28:34]

Please take a look

[Lasse Reichstein, 2009-05-05 11:44:31]

LGTM, with comments.

http://codereview.chromium.org/99355/diff/2006/2011
File src/globals.h (right):

http://codereview.chromium.org/99355/diff/2006/2011#newcode50
Line 50: #endif
Much better.
I would prefer a non-host wordsize selector, e.g.,
V8_ARCH_32BIT or V8_HEAP_32BIT, although the V8_HOST_ARCH_32_BIT might also be
useful.

Perhaps a define the heap bit-ness depending on host bits and target
architecture (with errors if they don't match).

This is only because I don't want to say that it's the host wordsize alone that
determines our memory model. It really is the combination of target architecture
and runtime system architecture (which is why a 64-bit ARM simulator should
cause an error).

http://codereview.chromium.org/99355/diff/2006/2011#newcode79
Line 79: #define V8_UINT64_C(x)  (x ## ULL)
Change to #UL and only enable it in 64-bit mode.
Our way of compiling (probably -pedantic) does not allow long long literals.

[Dean McNamee, 2009-05-05 11:56:12]

http://codereview.chromium.org/99355/diff/2006/2011
File src/globals.h (right):

http://codereview.chromium.org/99355/diff/2006/2011#newcode50
Line 50: #endif
On 2009/05/05 11:44:31, Lasse Reichstein wrote:
> Much better.
> I would prefer a non-host wordsize selector, e.g.,
> V8_ARCH_32BIT or V8_HEAP_32BIT, although the V8_HOST_ARCH_32_BIT might also be
> useful.
> 
> Perhaps a define the heap bit-ness depending on host bits and target
> architecture (with errors if they don't match).
> 
> This is only because I don't want to say that it's the host wordsize alone
that
> determines our memory model. It really is the combination of target
architecture
> and runtime system architecture (which is why a 64-bit ARM simulator should
> cause an error).

I think right now this is an un-needed and confusing level of abstraction.  We
can't have a 64-bit heap on a 32-bit host.  They are not really independent
concepts.

We aren't going to be able to run the 32-bit arm simulator on 64-bit, because
the runtime will be using 64-bit pointers.  I think really for now it is
simplest to just go off of the host bit-ness.

If we decide we need this in the future, we could definitely add it, but right
now I think we're thinking too far ahead of ourselves and making things
confusing.  Let's keep them simple for now.

http://codereview.chromium.org/99355/diff/2006/2011#newcode79
Line 79: #define V8_UINT64_C(x)  (x ## ULL)
On 2009/05/05 11:44:31, Lasse Reichstein wrote:
> Change to #UL and only enable it in 64-bit mode.
> Our way of compiling (probably -pedantic) does not allow long long literals.

Fixed.