Endian changes, support 64bit big endian

Endian changes, support 64bit big endian

These are some changes split off from https://codereview.chromium.org/422063005

frames-inl.h, frames.h
based on https://github.com/andrewlow/v8ppc/commit/05db7d2d714c44bd4e0b710fdaa51d34938aaa27
On 64bit big endian systems, the integer value is in the second slot, thus we need a new offset.

objects-inl.h, objects.h
based on https://github.com/andrewlow/v8ppc/commit/09b680b2af7412fe8fa5a3a01f1b8e29698d7797
Similarly, the hash slot is an integer field and we need to do the right thing on 64bit big endian systems

objects.cc
based on: https://github.com/andrewlow/v8ppc/commit/065742b0783b0705d9f9711198248a92bac11d85
Prettier printing of constant pools

test-strings.cc
based on:  https://github.com/andrewlow/v8ppc/commit/9889d60cd6e68e0d248c4a362ffdff0755b92aec
endian fixes

BUG=
R=svenpanne@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=24365

[andrew_low, 2014-09-15 17:33:50]

andrew_low@ca.ibm.com changed reviewers:
+ danno@chromium.org, rmcilroy@chromium.org, svenpanne@chromium.org

[Sven Panne, 2014-09-16 10:48:40]

https://codereview.chromium.org/551803004/diff/1/src/objects-inl.h
File src/objects-inl.h (right):

https://codereview.chromium.org/551803004/diff/1/src/objects-inl.h#newcode3298
src/objects-inl.h:3298: WRITE_INTPTR_FIELD(this, kHashFieldSlot, value);
Hmmm, this is a bit brittle for 2 reasons: Writing an unsigned value via a
pointer to a signed value can lead to undefined behavior. Furthermore, intptr_t
could actually be *larger* than a pointer (it just needs to be big enough to
allow a conversion from/to a pointer, the other way it's not required to be a
no-op), but probably no implementation does it...

https://codereview.chromium.org/551803004/diff/1/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/551803004/diff/1/src/objects.h#newcode3171
src/objects.h:3171: kExtendedInt64CountOffset + kInt32Size;
I think that this is wrong: We access this via READ_INT_FIELD/WRITE_INT_FIELD,
and they use *int*, not *int32_t*. Same for the rest. kPointerSize was wrong,
too, BTW...

@Ross: What do you think? Somehow the accessors have to match these constants.

https://codereview.chromium.org/551803004/diff/1/src/objects.h#newcode7293
src/objects.h:7293: #elif V8_TARGET_BIG_ENDIAN
This is very fragile: At least we have to cross-reference these constants with
the (PSEUDO_)SMI_ACCESOR stuff in objects-inl.h, in both directions.

(What we *really* need is some kind of DSL describing our object layouts, this
is getting really ugly...)

https://codereview.chromium.org/551803004/diff/1/test/cctest/test-strings.cc
File test/cctest/test-strings.cc (right):

https://codereview.chromium.org/551803004/diff/1/test/cctest/test-strings.cc#...
test/cctest/test-strings.cc:1411: memset(dummy.start(), 0x0, dummy.length() *
sizeof(TYPE));                 \
Why exactly do we need this?

[rmcilroy, 2014-09-18 10:54:44]

https://codereview.chromium.org/551803004/diff/1/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/551803004/diff/1/src/objects.h#newcode3171
src/objects.h:3171: kExtendedInt64CountOffset + kInt32Size;
On 2014/09/16 10:48:40, Sven Panne wrote:
> I think that this is wrong: We access this via READ_INT_FIELD/WRITE_INT_FIELD,
> and they use *int*, not *int32_t*. Same for the rest. kPointerSize was wrong,
> too, BTW...
> 
> @Ross: What do you think? Somehow the accessors have to match these constants.

Yeah I agree - Andrew - could you change the accessors to use
READ/WRITE_INT32_FIELD as well please.

[andrew_low, 2014-09-22 17:49:18]

I've updated the patch to reflect the comments.

https://codereview.chromium.org/551803004/diff/1/src/objects-inl.h
File src/objects-inl.h (right):

https://codereview.chromium.org/551803004/diff/1/src/objects-inl.h#newcode3298
src/objects-inl.h:3298: WRITE_INTPTR_FIELD(this, kHashFieldSlot, value);
Changed to still use kHashFieldSlot to reference the storage space used by the
hash field, but using UINT32 writes.

https://codereview.chromium.org/551803004/diff/1/src/objects.h
File src/objects.h (right):

https://codereview.chromium.org/551803004/diff/1/src/objects.h#newcode3171
src/objects.h:3171: kExtendedInt64CountOffset + kInt32Size;
On 2014/09/18 10:54:44, rmcilroy wrote:
> On 2014/09/16 10:48:40, Sven Panne wrote:
> > I think that this is wrong: We access this via
READ_INT_FIELD/WRITE_INT_FIELD,
> > and they use *int*, not *int32_t*. Same for the rest. kPointerSize was
wrong,
> > too, BTW...
> > 
> > @Ross: What do you think? Somehow the accessors have to match these
constants.
> 
> Yeah I agree - Andrew - could you change the accessors to use
> READ/WRITE_INT32_FIELD as well please.

Done.

https://codereview.chromium.org/551803004/diff/1/src/objects.h#newcode7293
src/objects.h:7293: #elif V8_TARGET_BIG_ENDIAN
It's not clear what you're suggesting should be done here.

https://codereview.chromium.org/551803004/diff/1/test/cctest/test-strings.cc
File test/cctest/test-strings.cc (right):

https://codereview.chromium.org/551803004/diff/1/test/cctest/test-strings.cc#...
test/cctest/test-strings.cc:1411: memset(dummy.start(), 0x0, dummy.length() *
sizeof(TYPE));                 \
On 2014/09/16 10:48:40, Sven Panne wrote:
> Why exactly do we need this?

When we test on AIX there are tests that fail if this memset is not present.
I'll drop it from this patch for now.

[andrew_low, 2014-09-30 19:45:08]

Update to the latest code level. All comments addressed.

Anything else you guys need to approve this change set?

[Sven Panne, 2014-10-01 13:12:16]

LGTM, although I still had a slight brain explosion trying to visualize the
object layouts in my mind... :-}

I'll land it for you.

[Sven Panne, 2014-10-01 13:14:26]

Committed patchset #4 (id:60001) manually as 24365 (presubmit successful).