GP32 Wtf


All,

Just to confirm what has been said and state the situation with DevKitArm.
The solution is a lot less horrid then the examples shown above ;).

DevKitArm includes SPECS files to prevent just this problem for both the GamePark SDK and Mirko's/Non-SDK. –nostartfiles is a very bad idea and can lead to many, many issues when using C++ (and C under some odd circumstances) with things not being put together as you expect.

In order to use these specs you call -specs=gp32.specs or -specs=gp32_gpsdk.specs (If your using the GamePark SDK) when you link instead of calling a CRT0.O, a linker script or any other rubbish.

The correctly sets up the link order for all the start-up objects including all your C++ environment etc. etc. and passes the appropriate GP32 files from arm-elf/lib in when required.

To give an example of how this is used I have snipped this from the sample DevKitArm makefiles I hand out. It’s for the GPSDK specs but you should get the idea.

Code:
LDSPECS	=	-specs=gp32_gpsdk.specs

LDFLAGS  =  $(LDSPECS) \
  	-Wl,-Map,$(MAPFILE) \
  	$(LIBDIRS) \
  	$(GP_LIBS) \
  	$(LIBS_USER)

Notice the lack of a linker script ;) and don’t forget to ditch CRT0.O from your compile setup oh and PLEASE remove –nostartfiles :D.

One last tip, don't link with LD directly go via your compiler ;).

On another note, the best tuning flag for the GP32 (with recent GCC builds) would be

Code:
-march=armv4t

-mtune=arm920t (yes, the arm920t IS a valid opt flag on GCC 3.3 and up) just resolves to -march=armv4t under the hood anyway.

I use the setup I have just described with the GP32 SDK, DevKitArm (and for that matter, all manor of hand built GCC’s) with my C++ projects, ScummVM etc. and it works very nicely.

One thing to be aware of is that the files I patched for the basis of the GP32_GPSDK.SPECS assume the start-up object to be main() not the Main() that gpstart.c files seem to be configured with (ADS handover?). The SDK pack from the DevKitArm site has a ‘good’ gpstart.c you can just compile and link if you want.

If you edit your gpstart.c you really should also set the return type of main() to be int not void as gpstart.c does.

I.e.

void Main (int arg_len, char * arg_v)
becomes
int main (int arg_len, char * arg_v)

Thats it for now :D.
 
DJWillis posted on Aug 2 2004 at 05:11 PM said:
foft posted on Aug 2 2004 at 06:06 PM said:
BTW is there a way of calling some init code before the constructors are called?
Hmmm, want to elaborate on what you mean? What 'sort' of init code?
It is quite possible a constructor will call malloc. If malloc is implemented in terms of the gp sdk then the gp sdk needs to be initialised.

Or is this already taken care of?

Thanks,

Mark
 
Last edited by a moderator:
DJWillis posted on Aug 2 2004 at 03:00 PM said:
On another note, the best tuning flag for the GP32 (with recent GCC builds) would be

Code:
-march=armv4t

-mtune=arm920t (yes, the arm920t IS a valid opt flag on GCC 3.3 and up) just resolves to -march=armv4t under the hood anyway.
Hmmm, I was already using -march=arv4t. Adding the -mtune=arm920 definitely sped up the emulator by a few fps. Were some of my other options (shown below) breaking it?

Code:
CFLAGS  = -Wall -O3 -march=armv4t -mtune=arm920 -marm -mthumb-interwork -msoft-float -ffast-math -fshort-enums -nostdlib -fno-common -fno-builtin -fno-exceptions -mstructure-size-boundary=8 $(INCLUDE)

Thanks,

Mark
 
Last edited by a moderator:
Well ditch -mthumb-interwork and -msoft-float for a start ;).

The GamePark SDK packaged with DevKitArm is not compiled for interworking (thankfully) so don’t try and build your ELF’s with interworking enabled, you will just create a noose for your own neck :). Actually explicitly setting –mno-thumb-interworking is a very good idea IMHO.

-msoft-float is hugely misunderstood and should NEVER be used unless you have a hardware floating point co-processor and wish to use the inbuilt ARM soft routines rather then the FPU. By default GCC is smart enough to work out that it’s on ARM and set the correct soft floating point routines. –msoft-float just causes code to get incorrectly marked even though the resulting object code is identical as the same routines are used.

Could you also try with -mtune=arm920t and report back? Don’t forget the GP32 uses the 920T CPU instruction set and not the vanilla 920. I would be very interested to see scientific results of the different opt settings (do you have a frame counter in the EMU for example).
 
With the flags I mentioned above in gcc 3.4.0:

This is the results from the drawn fps in a heavy demo...
without:27/28
with -mtune=arm920: 29/30
with -mtune=arm920t: 29/30

Seems to give a few percent (I exaggerated with the 10% earlier...).

I only put soft-float and thumb-interwork because my gp sdk libraries were built with it! How come there are different builds floating around -> is the src available? I've not used it through my whole toolchain build - doh! Time to switch to devkitarm, use spec files and cull stupid build flags I reckon...

Is there a performance penalty to turning on thumb interworking?

Mark
 
Is there a performance penalty to turning on thumb interworking?

A little ;).

I only put soft-float and thumb-interwork because my gp sdk libraries were built with it! How come there are different builds floating around -> is the src available?

There are 2 GCC SDK builds, a good clean build (non-interworking, no funny soft-fp marks, also has good working 16bit libs etc.) and the hacked build that is in DevKitAdv with all manor of evil 'tweaks' to make it work with a mainly GBA tool chain.

Most people ripped the crappy SDK build from DevKitAdv and re-packed it so that is now all over the place :(.

If you want some help switching to DevKitArm or building your own tool chain with the specs, SDK etc. just drop me an email or pop on to IRC and I will help all I can.

Thanks for the info on FPS, what version of GCC are you using?
 
Back
Top