building v8 on arm A8: does not support 'bkpt 0'

[A.Rames]

I am trying to compile v8 shell example on my beagleboard, but the
build meets fails ont the following error:

g++ -o obj/release/arm/cpu-arm.o -c -Wall -Werror -W -Wno-unused-
parameter -Wnon-virtual-dtor -pedantic -O3 -fomit-frame-pointer -fdata-
sections -ffunction-sections -ansi -fno-rtti -fno-exceptions -Wall -
Werror -W -Wno-unused-parameter -Wnon-virtual-dtor -pedantic -O3 -
fomit-frame-pointer -fdata-sections -ffunction-sections -ansi -
DV8_TARGET_ARCH_ARM -DV8_NATIVE_REGEXP -DENABLE_LOGGING_AND_PROFILING -
Isrc src/arm/cpu-arm.cc

/tmp/ccMqAVAn.s: Assembler messages:
/tmp/ccMqAVAn.s:58: Error: selected processor does not support `bkpt
0'

I actually managed to get v8 javascript shell work by cross-compiling
it with the CodeSourcery toolchain, but I would like to compile it on
the board itself as the cross-compiled shell seems not very efficient:
I get a score around 93 on the v8 version 3 test. This seems quite low
compared to the 800 score on a 300MHz faster x86 intel processor, and
compared to SFX without JIT on the same board ( "only" 45% slower
whereas it's about 5 times slower on other processors)

I am not very skilled about arm architectures and how v8 supports
them, but reading through the code I noticed there is no
__ARM_ARCH_8__ test like for other arm architectures in macro-
assembler-arm.cc l.57. Is the arm 8 architecture not supported?


Could someone either help me fix this error or confirm (or infirm)
those weird results?

Thanks

[Rames]

I think I went a little further understanding my issue:
After commenting the cpu-arm.cc line 123 asm volatile("bkpt 0");
to get rid of this unknown instruction I get the following error:

src/arm/macro-assembler-arm.cc:62:2: error: #error "for thumb inter-
working we require architecture v5t or above
scons: *** [obj/release/arm/macro-assembler-arm.o] Error 1

So it seems that no correct __ARM_ARCH_XX__ macro is defined
(assembler-arm.cc line 57), meaning that my architecture does not
fit.
But I guess cortex A8 arms are compatible with previous arm
versions. Is there any way to get my beagleboard to compile v8?

[Erik Corry]

You need to do:

touch null.c
g++ -dM -E null.c

and see what __ARCH_ARM_xxx__ macro your gcc compiler defines. Then
you need to add that to src/arm/macro-assembler-arm.cc. I am adding
__ARM_ARCH_6__ to it today so perhaps that solves your problem.

Depending on the gcc version you are using you may need the following
patch. The -fno-strict-aliasing flag is because of a bug in V8, and
the -fno-tree-sink option is because of a bug in gcc-4.4.1 (gets
around an error where you get a 'pure virtual called' crash as soon as
you start up the VM).

Index: SConstruct
===================================================================
--- SConstruct (revision 2819)
+++ SConstruct (working copy)
@@ -48,9 +48,9 @@
# and avoid dtoa.c strict aliasing issues
if os.environ.get('GCC_VERSION') == '44':
GCC_EXTRA_CCFLAGS = ['-fno-tree-vrp']
- GCC_DTOA_EXTRA_CCFLAGS = ['-fno-strict-aliasing']
+ GCC_DTOA_EXTRA_CCFLAGS = ['-fno-strict-aliasing', '-fno-tree-sink']
else:
- GCC_EXTRA_CCFLAGS = []
+ GCC_EXTRA_CCFLAGS = ['-fno-strict-aliasing', '-fno-tree-sink']
GCC_DTOA_EXTRA_CCFLAGS = []

ANDROID_FLAGS = ['-march=armv5te',


2009/9/8 Rames <alex...@gmail.com>:

--
Erik Corry, Software Engineer
Google Denmark ApS. CVR nr. 28 86 69 84
c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018
Copenhagen K, Denmark.

[Erik Corry]

2009/9/8 A.Rames <alex...@gmail.com>:

ARM have a confusing system where their instruction set architectures
are numbered and their implementations are also numbered, but the
numbers have nothing to do with each other.

ARM7 implements ARMv4
ARM9 implements ARMv5
ARM11 implements ARMv6
Cortex A8 implements ARMv7

I probably got that wrong. It gives me a headache. The
__ARM_ARCH_xx__ macros refer to the instruction set.

>
>
> Could someone either help me fix this error or confirm (or infirm)
> those weird results?
>
> Thanks
> >
>

[Rames]

I get this result:
root@beagleboard:~# g++ -dM -E null.c | grep ARCH
#define __ARM_ARCH_4T__ 1

This first looked weird to me, but I checked ARM infos and got the
following:
( http://en.wikipedia.org/wiki/ARM_architecture )

Familiy: ARM8
Architecture version: ARMv4
Core: ARM810

So indeed the ARm8 has a v4 architechture, while for example ARM7TDMI
(but not ARM7) and ARM9E (but not ARM9TDMI) have an architecture with
version 5.

So my ARM architecture is indeed under v5 and is not supported.

Thanks for your help!

Alexandre

On Sep 9, 2:34 am, Erik Corry <erik.co...@gmail.com> wrote:
> 2009/9/8 A.Rames <alexra...@gmail.com>:

[Rames]

It is actually more complicated than that. I have a Cortex A8 and not
an ARM8.

I give some updates soon.

[Rames]

In my hurry I didn't read your answers properly. Sorry for that.

My cpu is a Cortex A8 with an ARMv7-a version architecture and my gcc
compiler uses #define __ARM_ARCH_4T__ 1 .
The patch you gave me didnt change the compile errors.
I really don't know about ARM Instruction Set versions, but I hope
this might help you to fix a potential bug.

Actually my problem is not to compile on the board itself, but rather
to be sure that my tests results are accurate and it could be solved
more easily if can you confirm me I can trust the cross-compiled shell
obtained the following way:

1) Modifying the v8 SConstruct adding 'CCFLAGS': ['-
march=armv7-a'] to the arm architecture (line 162)
2) Exporting my environment variables CC, CXX, AR, AS, RANLIB, LD to
my CodeSourcery crosstools (arm-none-linux-gnueabi-gcc , etc)
3) Cross-compiling with scons arch=arm sample=shell
4) Running the cross-compiled shell on my cpu

I know this may seems dumb, but I met quite a few issues doing these
tests...

[Erik Corry]

2009/9/9 Rames <alex...@gmail.com>:

>
> In my hurry I didn't read your answers properly. Sorry for that.
>
> My cpu is a Cortex A8 with an ARMv7-a version architecture and my gcc
> compiler uses    #define __ARM_ARCH_4T__ 1 .

Your gcc is designed by default to compile things that work with a
wide variety of ARM chips. V8 should work even with these pessimistic
assumptions, but you can't compile the VM in Thumb mode on such an old
chip. But as you note below you can use the -march flag to compile
for newer CPUs if you know you won't be running on such old hardware.

> The patch you gave me didnt change the compile errors.
> I really don't know about ARM Instruction Set versions, but I hope
> this might help you to fix a potential bug.
>
> Actually my problem is not to compile on the board itself, but rather
> to be sure that my tests results are accurate and it could be solved
> more easily if can you confirm me I can trust the cross-compiled shell
> obtained the following way:
>
> 1) Modifying the v8 SConstruct adding    'CCFLAGS':      ['-
> march=armv7-a']    to the arm architecture (line 162)
> 2) Exporting my environment variables CC, CXX, AR, AS, RANLIB, LD to
> my CodeSourcery crosstools (arm-none-linux-gnueabi-gcc , etc)
> 3) Cross-compiling with     scons arch=arm sample=shell
> 4) Running the cross-compiled shell on my cpu

That sounds fine and should give you a VM that works. To be certain,
there are some tests that are bundled with the VM source that you can
run with the test.py script. See
http://code.google.com/p/v8/wiki/Testing At the moment we pass all
tests on ARM apart from some debug tests. There's a way to tell
test.py to use the ARM test expectations, but I can't remember it
right now.

[Rames]

The -march=armv7-a indeed solved all my problems. Thank you
very much for all you answers.

So I eventually get a score around 94 for the v8 (version 3) tests
with v8 on an OMAP3530 (Cortex A8 600MHz).
I previously got a score around 800 on a 800Mhz Intel processor.

The score gap is amazing for only 200MHz difference. I have not
compared v8 arm and ia32 code. Do you know if this gap results from a
better code optimization and/or better native code usage (I see a lot
of posts relative to ARM work on the v8-dev group so I guess the ARM
work is not yet to the level of the ia32's) or if the x86 architecture
merely have a more efficient Instruction Set or architecture?

Sorry to bother you with such weird (but interesting!) questions!

Alexandre

On Sep 9, 2:30 pm, Erik Corry <erik.co...@gmail.com> wrote:
> 2009/9/9 Rames <alexra...@gmail.com>:

>
>
>
> > In my hurry I didn't read your answers properly. Sorry for that.
>
> > My cpu is a Cortex A8 with an ARMv7-a version architecture and my gcc
> > compiler uses    #define __ARM_ARCH_4T__ 1 .
>
> Your gcc is designed by default to compile things that work with a
> wide variety of ARM chips. V8 should work even with these pessimistic
> assumptions, but you can't compile the VM in Thumb mode on such an old
> chip.  But as you note below you can use the -march flag to compile
> for newer CPUs if you know you won't be running on such old hardware.
>
> > The patch you gave me didnt change the compile errors.
> > I really don't know about ARM Instruction Set versions, but I hope
> > this might help you to fix a potential bug.
>
> > Actually my problem is not to compile on the board itself, but rather
> > to be sure that my tests results are accurate and it could be solved
> > more easily if can you confirm me I can trust the cross-compiled shell
> > obtained the following way:
>
> > 1) Modifying the v8 SConstruct adding    'CCFLAGS':      ['-
> > march=armv7-a']    to the arm architecture (line 162)
> > 2) Exporting my environment variables CC, CXX, AR, AS, RANLIB, LD to
> > my CodeSourcery crosstools (arm-none-linux-gnueabi-gcc , etc)
> > 3) Cross-compiling with     scons arch=arm sample=shell
> > 4) Running the cross-compiled shell on my cpu
>
> That sounds fine and should give you a VM that works.  To be certain,
> there are some tests that are bundled with the VM source that you can

> run with the test.py script.  Seehttp://code.google.com/p/v8/wiki/Testing At the moment we pass all

[Erik Corry]

2009/9/10 Rames <alex...@gmail.com>:

>
> The     -march=armv7-a    indeed solved all my problems. Thank you
> very much for all you answers.
>
> So I eventually get a score around 94 for the v8 (version 3) tests
> with v8 on an OMAP3530 (Cortex A8 600MHz).
> I previously got a score around 800 on a 800Mhz Intel processor.
>
> The score gap is amazing for only 200MHz difference. I have not
> compared v8 arm and ia32 code. Do you know if this gap results from a
> better code optimization and/or better native code usage (I see a lot
> of posts relative to ARM work on the v8-dev group so I guess the ARM
> work is not yet to the level of the ia32's) or if the x86 architecture
> merely have a more efficient Instruction Set or architecture?

The code generator for ARM is not as advanced as the one for Intel.
My very rough guess is that the score on the V8 benchmark suite could
be almost doubled if the code generator were as advanced on ARM. The
tricky bit is to speed up the running code without slowing down
compilation, which can be a big factor in page load time on slow
devices.

Looking at raw MHz can be misleading. The Cortex A8 design in the
BeagleBoard is an in-order design, whereas the Cortex A9 ARM chip will
be a "multi-issue superscalar, out-of-order, speculating 8-stage
pipeline" according to ARM's white paper. This can make quite a
difference. The in-order Atom is said by Wikipedia to have half the
performance of the out-of-order low end Celerons with around the same
Mhz.

Apart from the MHz, the speed of the memory subsystem can be very
important. This is partly a property of the CPU core itself, but to a
larger extent a property of the second level cache size and speed as
well as the speed of the external RAM interface. There are many
tradeoffs here in system design to do with cost, space and power use.
It's fair to say that V8 (and browser) performance is very dependent
on the memory subsystem.

[Rames]

Thanks for these details. This makes sense.
So I'm going back to read v8 code now! :)

Alexandre

On Sep 10, 12:52 am, Erik Corry <erik.co...@gmail.com> wrote:
> 2009/9/10 Rames <alexra...@gmail.com>: