MIPS: Fix big-endian after r21774/r21803.

MIPS: Fix big-endian after r21774/r21803.

Fix big-endian ordering of InstanceType and BitField by always loading
the pair as a 16-bit value, even in the API accessor. Clean up some
assertions.

R=danno@chromium.org, mtbrandy@gmail.com

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

[Paul Lind, 2014-06-17 06:22:18]

PTAL. I'm not thrilled with using the compiler big/little endian definitions in
v8.h, but the usual v8 definitions are not valid there. And since we play with
the offset of the instance type, and it is exposed thru the API, I don't see
much choice. I'm open to better suggestions.

Also, please check this for MS C compatibility. I don't have a platform to test
that. All the gcc's (x86, arm, arm64) support this, as does clang on the mac.

[Toon Verwaest, 2014-06-17 16:50:01]

https://codereview.chromium.org/334403003/diff/1/src/hydrogen-instructions.h
File src/hydrogen-instructions.h (right):

https://codereview.chromium.org/334403003/diff/1/src/hydrogen-instructions.h#...
src/hydrogen-instructions.h:6098: Map::kInstanceTypeOffset,
Can we use Map::kInstanceTypeAndBitFieldOffset and define that based on
endianness?

[mtbrandy, 2014-06-17 17:11:39]

https://codereview.chromium.org/334403003/diff/1/include/v8.h
File include/v8.h (right):

https://codereview.chromium.org/334403003/diff/1/include/v8.h#newcode5520
include/v8.h:5520: #if defined (__BYTE_ORDER__) && (__BYTE_ORDER__ ==
__ORDER_BIG_ENDIAN__)
I think this is an argument for making the v8-endian definitions available here 
similar to the v8-os definitions.  Not all platforms define __BYTE_ORDER__.

[danno, 2014-06-18 11:18:41]

https://codereview.chromium.org/334403003/diff/1/include/v8.h
File include/v8.h (right):

https://codereview.chromium.org/334403003/diff/1/include/v8.h#newcode5520
include/v8.h:5520: #if defined (__BYTE_ORDER__) && (__BYTE_ORDER__ ==
__ORDER_BIG_ENDIAN__)
On 2014/06/17 17:11:39, mtbrandy wrote:
> I think this is an argument for making the v8-endian definitions available
here 
> similar to the v8-os definitions.  Not all platforms define __BYTE_ORDER__.

This probably means taking the entire contents of src/base/build_config.h and
putting it in v8config.h. Adding Jochen to see how that fits into his master
plan for refactoring base.

https://codereview.chromium.org/334403003/diff/1/src/hydrogen-instructions.h
File src/hydrogen-instructions.h (right):

https://codereview.chromium.org/334403003/diff/1/src/hydrogen-instructions.h#...
src/hydrogen-instructions.h:6098: Map::kInstanceTypeOffset,
On 2014/06/17 16:50:01, Toon Verwaest wrote:
> Can we use Map::kInstanceTypeAndBitFieldOffset and define that based on
> endianness?

+1 to Toon's comment

[Paul Lind, 2014-06-19 07:31:22]

PTAL, got rid of the conditional compilation stuff from patch set 1.

https://codereview.chromium.org/334403003/diff/1/include/v8.h
File include/v8.h (right):

https://codereview.chromium.org/334403003/diff/1/include/v8.h#newcode5520
include/v8.h:5520: #if defined (__BYTE_ORDER__) && (__BYTE_ORDER__ ==
__ORDER_BIG_ENDIAN__)
By loading 16 bit word in this API accessor, but only using the LS 8 bits
(InstanceType), we can take advantage of the endianess, as Danno did in r21774.
And avoid conditional compilation here.

I think it would be good for the future to bring base/build_config.h into
v8config.h, or at least the CPU arch & endianess part of it, but we don't need
to do it for this issue.

https://codereview.chromium.org/334403003/diff/1/src/hydrogen-instructions.h
File src/hydrogen-instructions.h (right):

https://codereview.chromium.org/334403003/diff/1/src/hydrogen-instructions.h#...
src/hydrogen-instructions.h:6098: Map::kInstanceTypeOffset,
Nice suggestion, Toon, it makes it cleaner, and enables the above api cleanup as
well. Done.

[mtbrandy, 2014-06-19 13:43:04]

lgtm

[danno, 2014-06-20 07:50:21]

lgtm

[Paul Lind, 2014-06-20 23:02:49]

Committed patchset #2 manually as r21906 (presubmit successful).