Pandora A "new" Good Way To Program For The Pandora?


Don't forget you still need hardware to use that package though, such as a Beagleboard, until they release the simulator part of the package.
 
Crahels said:
A new keil development tool which seem interesting to develop for the Pandora:

"linux-ARM" development tools

Hoping to receive mine before the end of the trial period:D.

Why is this better than anything we have already? It's not even free (as in freedom)!

Also: "Note: The Cortex-A8 RTSM is not included in the current DS-5 trial version. It will be available during Q2,10."

The Pandora is a A8... This seems a little pointless.
 
Last edited by a moderator:
PhonicUK said:
Why is this better than anything we have already? It's not even free (as in freedom)!
The CodeSourcery tools that developers use at the moment aren't free either.
 
Last edited by a moderator:
From a compiler and IDE viewpoint this isn't very interesting since it's just GCC and Eclipse. I guess the point is for simulation, which can simulate a Cortex-A8. We have qemu for that, but this seems faster.

Now, if it weren't GCC I'd say there'd be good reason to use it because GCC is far from top of its game at ARM code generation. The situation has gradually improved over the years but even today ARM's RVCT compiler can beat it in output quality by a wide margin. See for yourself:

http://hardwarebug.org/2010/01/15/arm-compiler-update/
 
dflemstr -- CSL has a free (beer) download; most of us are just regular joe bloe gcc cross-compiled for ARM, but CSL just makes it easy.. anyone can suck it down and be up and going in 20 minutes; but that doesn't mean we're using it :) Certainly, the firmware images are not built with it.

jeff
 
skeezix said:
dflemstr -- CSL has a free (beer) download; most of us are just regular joe bloe gcc cross-compiled for ARM, but CSL just makes it easy.. anyone can suck it down and be up and going in 20 minutes; but that doesn't mean we're using it :) Certainly, the firmware images are not built with it.

jeff
Well sure, I use CodeSourcery for my builds. I meant free as in speech though (as indicated by the first post) :)

Also, why not use CSL for the image? I thought that CSL had better SIMD support...
 
Last edited by a moderator:
I would assume the offical ARM compiler RVCT is used? I heard it has the best performance out there and I guess that someone, somewhere has a license for it to compile for the team.
 
JayFoxRox said:
I would assume the offical ARM compiler RVCT is used? I heard it has the best performance out there and I guess that someone, somewhere has a license for it to compile for the team.

I doubt it. Lots of people are compiling for the team, and it's really expensive. Plus, I'm pretty sure the Linux kernel and a lot of Linuxy things require GCC.
 
Last edited by a moderator:
From reading the blog of Måns Rullgård http://hardwarebug.org/2010/01/15/arm-compiler-update/ He tend to recommend the use CodeSourcery 2009q1 for better code
 
Exophase said:
Plus, I'm pretty sure the Linux kernel and a lot of Linuxy things require GCC.

RVCT has got a lot better recently at compiling linux apps, but yes, it is still not possible to (easily) compile the kernel with it.
 
Last edited by a moderator:
Raman said:
Exophase said:
Plus, I'm pretty sure the Linux kernel and a lot of Linuxy things require GCC.

RVCT has got a lot better recently at compiling linux apps, but yes, it is still not possible to (easily) compile the kernel with it.

Ah, kay, nevermind then. But still wondering what exactly they use as I thought just GCC was slower than CSL and the only one which was actually working better and faster was said to be RVCT.
So unless I miss something here skeezix can only have talked about RVCT when he said that "Certainly, the firmware images are not built with it." (About CSL).
 
Last edited by a moderator:
Code Sourcery produces faster binaries than mainline GCC, but it's also well known to be buggier. It's basically the "experimental" branch for ARM GCC whose core/verified components eventually make it back into mainline.

It's probably best to build the firmware with something that produces more reliable code than something that produces faster code. Most CPU cycles aren't going to be spent in firmware code, but you definitely want those CPU cycles to be correct ones.
 
I've been using gcc 4.3.3. It's code generation is not great. In particular it does not support VFP. If given -mcpu=cortex-a8, it will use movw but not movt, putting constants greater than 2^16 into a constant pool. It has some unnecessary stack usage too.

The only bug I've found is that the optimizer tends to make some invalid assumptions about where extern pointers are located. It really didn't like rdram being 0x80000000 until I #defined it as such.
 
Ari64 said:
I've been using gcc 4.3.3. It's code generation is not great. In particular it does not support VFP.
Are you sure? Did you try this
Code:
-mcpu=cortex-a8 -mfpu=vfp -mfloat-abi=softfp

BTW I've been using CSL2009q3 for months without any issue.
 
Last edited by a moderator:
Laurent said:
Are you sure? Did you try this
Code:
-mcpu=cortex-a8 -mfpu=vfp -mfloat-abi=softfp
That does work. I had left out the -mfloat-abi=softfp when I tested it.

So what's the magic incantation to get it to use movt correctly? The way it generates literal pools makes inefficient use of the L1 cache.
 
Last edited by a moderator:
Ari64 said:
So what's the magic incantation to get it to use movt correctly? The way it generates literal pools makes inefficient use of the L1 cache.
For gcc 4.3.3, I can't say.

CSL2009q3 does it:
Code:
$ ~/work/Cross/arm-2009q3-67/bin/arm-none-linux-gnueabi-gcc -O2 -mcpu=cortex-a8 -S hello.c -o hello-test.s
$ cat hello-test.s
[...]
.LFB11:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	stmfd	sp!, {r3, lr}
	.save {r3, lr}
.LCFI0:
	movw	r3, #:lower16:stdout
	movt	r3, #:upper16:stdout
	mov	r1, #1
	mov	r2, #6
	movw	r0, #:lower16:.LC0
	ldr	r3, [r3, #0]
	movt	r0, #:upper16:.LC0
	bl	fwrite
	mov	r0, #0
	ldmfd	sp!, {r3, pc}

CSL2009q1 (based on 4.3.3) also does it:
Code:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	movw	r2, #:lower16:stdout
	movt	r2, #:upper16:stdout
	stmfd	sp!, {r4, lr}
	.save {r4, lr}
.LCFI0:
	ldr	r3, [r2, #0]
	mov	r1, #1
	mov	r2, #6
	movw	r0, #:lower16:.LC0
	movt	r0, #:upper16:.LC0
	bl	fwrite
	mov	r0, #0
	ldmfd	sp!, {r4, pc}
 
Last edited by a moderator:
gcc version 4.3.3:
Code:
$ cat hello.c
#include <stdio.h>
int main()
{
  printf("Hello world\n");
}
$ gcc -mcpu=cortex-a8 -S hello.c
$ cat hello.s
[...]
main:
        @ args = 0, pretend = 0, frame = 8
        @ frame_needed = 1, uses_anonymous_args = 0
        mov     ip, sp
        stmfd   sp!, {fp, ip, lr, pc}
        sub     fp, ip, #4
        sub     sp, sp, #8
        ldr     r0, .L3
        bl      puts
        sub     sp, fp, #12
        ldmfd   sp, {fp, sp, pc}
.L4:
        .align  2
.L3:
        .word   .LC0
[...]
$ gcc -mcpu=cortex-a8 -O2 -S hello.c
$ cat hello.s
[...]
main:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        ldr     r0, .L3
        b       puts
.L4:
        .align  2
.L3:
        .word   .LC0
Not sure what's going on with the stack usage in codesourcery gcc. It saves and restores r3/r4, which is unnecessary, but maybe it is for stack alignment?
 
It's because your code uses an undefined behaviour since it doesn't return a value for main.
Using it, CSL generates:
Code:
.LFB11:
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	@ link register save eliminated.
	movw	r0, #:lower16:.LC0
	movt	r0, #:upper16:.LC0
	b	puts
.LFE11:

So if you want movw/movt, you should use CSL compiler or perhaps gcc 4.4.n.
 
It's because your code uses an undefined behaviour since it doesn't return a value for main.

This is a very interesting observation - for more testing of these compiler differences, may I suggest the following gcc flags be used to more specifically narrow things down:

Code:
WARNINGS := -Wall -W -Wunused-parameter -Wmissing-declarations
WARNINGS += -Wstrict-prototypes -Wmissing-prototypes -Wsign-compare
WARNINGS += -Wno-conversion -Wshadow -Wcast-align -Wparentheses
WARNINGS += -Wsequence-point -Wdeclaration-after-statement -Wundef
WARNINGS += -Wpointer-arith -Wnested-externs -Wredundant-decls
WARNINGS += -Wdisabled-optimization -pedantic -Werror

STD = -std=c99

CFLAGS += $(WARNINGS)
CFLAGS += $(STD)


.. particularly important is to pay attention to $(STD) .. there may in fact be a more appropriate value of this flag for the ARM compilers, and a bit of investigation into which one is expected for more optimal path might be necessary ..

EDIT: maybe -Wdisabled-optimization is not so smart ..
 
Back
Top