GP2X Arm And Thumb. Which To Use?

[slygamer]

Firstly, I have never written anything for an ARM processor before, so this is all new to me. I've done some research on ARM and have read up on the THUMB instructions. The two processors in the GP2x support THUMB (based on the 'T' designation in their names). THUMB instructions are useful for fitting more code into smaller amounts of memory, but are they slower than ARM instructions? The doco I have read states that the 16-bit THUMB instructions are expanded into the 32-bit ARM instructions in the processor, but does that one THUMB instruction execute in the same time as if we executed the same expanded ARM instructions explicitly?

What were the experiences on the GP32 in this regard?

Is there is some more detailed doco on the ARM processors from a coders perspective? Or do I read through that 'unofficial' doco that was accidentally released last week?

 

[mr.spiv]

Firstly, I have never written anything for an ARM processor before, so this is all new to me. I've done some research on ARM and have read up on the THUMB instructions. The two processors in the GP2x support THUMB (based on the 'T' designation in their names). THUMB instructions are useful for fitting more code into smaller amounts of memory, but are they slower than ARM instructions? The doco I have read states that the 16-bit THUMB instructions are expanded into the 32-bit ARM instructions in the processor, but does that one THUMB instruction execute in the same time as if we executed the same expanded ARM instructions explicitly?

What were the experiences on the GP32 in this regard?

Is there is some more detailed doco on the ARM processors from a coders perspective? Or do I read through that 'unofficial' doco that was accidentally released last week?

​

From experience, systems like GP32/GP2X that have fairly large caches, ARM mode beats Thumb performance wise. Thumb is more dense of course but with the amount of RAM there is I wouldn't bother.

 

[Vimacs]

Thumb may be wise for the 940 of the gp2x as it only haves 4+4kb cache.

 

[DJWillis]

ARM was the one to use on the GP32, on the GP2X I would bet on ARM over THUMB.

As for the 940 mini-core. My bet would be on ARM for that also but I fully intend to play as and when.

 

[no_skill]

what about hardware floating point support? i somehow missed any information on this.

 

[DJWillis]

what about hardware floating point support? i somehow missed any information on this.

​

It's an ARM cpu without an FPU so nope .

 

[Hanz™]

what about hardware floating point support? i somehow missed any information on this.

​

It's an ARM cpu without an FPU so nope .

​

dyam.

 

[no_skill]

what about hardware floating point support? i somehow missed any information on this.

​

It's an ARM cpu without an FPU so nope .

​

nooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo


why on earth?

we have 200 mhz. with real cpu we'd have soo much power. but with this crippled xxx...

why did i buy one? oh why?
damn!

 

[fragment]

Nah, just learn how to use fixed point arithmetic. It is fast and accurate enough.

 

[no_skill]

gp2x runs ports
most often ports of open source pc games
pc games rely on fixed point math
a lot
especially 3d games
namely quake 1 and 2
which means
porting a whole system to fixed point math = TEH SUCK, TEH UNRELIABLE, TEH INACCURATE, TEH WORK

means: again 2-4 years (product livecycle knowledge anyone?) with a severe limitation for porting games.
the easy way.
the right way.

 

[DJWillis]

Blatant noooooo spam aside .

A lot of the GP32 devs who will be considering moving to the new platform will not be going in blind. Integer only arithmetic on small scale CPU's is the norm.

GPH is not somehow backwards in this regard. ARM based Pocket PC's still don't have FPU’s for example and the FPU’s that exist to work with ARM cores are hit and miss regards compiler support. Frankly I would rather have to use GCC’s soft Floating Point (that is VERY good in the 3.4 and 4.* braches) then some badly supported and implemented FPU that pushes the cost and delivery time of the GP2X up.

Having no FPU does not bother me in the slightest and should not phase anybody who has coded for a GP32, GBA, DS or any other mainstream portable media/game device (Zaurus, iPaq etc. etc.).

 

[mr.spiv]

Thumb may be wise for the 940 of the gp2x as it only haves 4+4kb cache.

​

4Kb of code in cache is pretty much -- I wouldn't worry about that. Also in ARM mode you got basically 13 free data registers to play around, whereas in Thumb mode 8 free data registers easily accessible. 5 extra register is really good extra.. Also the memory bus has something to say here..

 

[Vimacs]

foregive me
4kb seemd pretty low to me compared to the 16kb of the 920.
but nice to hear that its not that low.

 

[no_skill]

Blatant noooooo spam aside .

A lot of the GP32 devs who will be considering moving to the new platform will not be going in blind. Integer only arithmetic on small scale CPU's is the norm.

GPH is not somehow backwards in this regard. ARM based Pocket PC's still don't have FPU’s for example and the FPU’s that exist to work with ARM cores are hit and miss regards compiler support. Frankly I would rather have to use GCC’s soft Floating Point (that is VERY good in the 3.4 and 4.* braches) then some badly supported and implemented FPU that pushes the cost and delivery time of the GP2X up.

Having no FPU does not bother me in the slightest and should not phase anybody who has coded for a GP32, GBA, DS or any other mainstream portable media/game device (Zaurus, iPaq etc. etc.).

​

still the gp2x would've been the chance to eliminate this drawback.

don't get me wrong; i still already orderd my gp2x and really look forward to it, but i think gph missed something here.

 

[DaveC]

Blatant noooooo spam aside .

A lot of the GP32 devs who will be considering moving to the new platform will not be going in blind. Integer only arithmetic on small scale CPU's is the norm.

GPH is not somehow backwards in this regard. ARM based Pocket PC's still don't have FPU’s for example and the FPU’s that exist to work with ARM cores are hit and miss regards compiler support. Frankly I would rather have to use GCC’s soft Floating Point (that is VERY good in the 3.4 and 4.* braches) then some badly supported and implemented FPU that pushes the cost and delivery time of the GP2X up.

Having no FPU does not bother me in the slightest and should not phase anybody who has coded for a GP32, GBA, DS or any other mainstream portable media/game device (Zaurus, iPaq etc. etc.).

​

Couldn't the second core run code to do FP calculations? If it could do that then it could act as an FPU. The main core could run the main app and at the same time the second could be doing the calculations. A lib could be made so that everytime you try to access a FPU it would re-direct to the second core. Kind of like a virtual FPU. Could this work?

 

[slygamer]

Couldn't the second core run code to do FP calculations? If it could do that then it could act as an FPU. The main core could run the main app and at the same time the second could be doing the calculations. A lib could be made so that everytime you try to access a FPU it would re-direct to the second core. Kind of like a virtual FPU. Could this work?

​

That would not be very useful. The first core would always be waiting on the second core to finish the calculation because the first core needs the result, and the code would be full of mutexes, critical sections or semaphores to synchronize the two cores. The data going to and from the second core would have to go via main memory, so you would incur the cost of read and writing to main memory as well. With a dedicated FPU, all of this is handled behind the scenes.

 

[pea]

A better bet would be something like -

CORE A
Runs the game loop, physics, AI, input etc. It is basically everything apart from the graphics. It updates the positions of the sprites (but doesn't render them) and changes render values (such as alpha, tints, rotations etc)

CORE B
Runs as fast as it can actually rendering the scene independent of CORE A. So it takes the sprite information, does the blitting, the manipulation, the blending and outputs it to the screen. Maybe it does the sound too.

 

[DaveC]

Couldn't the second core run code to do FP calculations?  If it could do that then it could act as an FPU.  The main core could run the main app and at the same time the second could be doing the calculations.  A lib could be made so that everytime you try to access a FPU it would re-direct to the second core.  Kind of like a virtual FPU.  Could this work?

​

That would not be very useful. The first core would always be waiting on the second core to finish the calculation because the first core needs the result, and the code would be full of mutexes, critical sections or semaphores to synchronize the two cores. The data going to and from the second core would have to go via main memory, so you would incur the cost of read and writing to main memory as well. With a dedicated FPU, all of this is handled behind the scenes.

​

Well yes of course a dedicated FPU is much better. But since the GP2X doesn't have one you will have to find creative ways to simulate one. Doing that is slower than hardware but we have no choice.

What Pea said sounds good. Hopefully there will be some decent compromise.

 

[Insanemal]

thats essencally how the ps2 does its work.. and its the most sensable way of using this setup.. while the using the 2nd cpu as a fpu sounds like a good idea.. it will leave it WAY too under utalized.. and also require it to respond way to quickly.. with systems like this you want all cpus running as close to 100% as possible..

 

[slygamer]

thats essencally how the ps2 does its work.. and its the most sensable way of using this setup.. while the using the 2nd cpu as a fpu sounds like a good idea.. it will leave it WAY too under utalized.. and also require it to respond way to quickly.. with systems like this you want all cpus running as close to 100% as possible..

​

Now this is something that I do know about. Our PS2 engine works in such a way that we have double-buffered DMA. A DMA buffer is essentially a list of drawing instructions (GIF tags in PS2 terminology) for an entire screen. One DMA buffer is being executed by the graphics processor (rendered to the back buffer) while the other DMA buffer is being filled by the CPU for the next frame. When both processors are done (CPU has finished updating the game state and filling up the DMA buffer; the graphics processor has finished rendering the instructions in the other DMA buffer), it swaps DMA buffers, flips the back buffer to the front, and starts again.

I'm sure that something similar could be done on the GP2x. It would be interesting to give it a try.