--- In gbadev@y..., "Dave Murphy" <wintermute2002@n...> wrote:
>
> Does anyone have any thoughts on the advantages/disadvantages
> of ARM code versus THUMB code?
>
> It seems to be generally accepted that Thumb is more efficient
> from ROM & ARM is more efficient from internal RAM.

Thumb is also more efficient from EWRAM. Code running from EWRAM
drains the battery much more slowly slower than code running from
ROM, even though it does run slightly slower.

> GCC compiled Thumb code is plenty fast enough for sprite based
> 2d games

Even when you have over 100 sprites on the screen? That's very
plausible in a space shooter or a Smash TV style game.
Is 200,000 cycles enough?

> It seems obvious that using ARM in internal RAM for rasterising
> code should be the way to go.

That, and for the audio mixer.

The biggest problem with putting code in IWRAM is that the most
common link scripts and libraries (such as the ones included with
devkitadv and HAM) do not directly support the IWRAM code overlay
trick used in most games for the Atari Jaguar console. Such
overlays let you copy a program segment into IWRAM using DMA,
which means that you don't waste memory by having the T&L code,
the rasterizer, and the mixer in IWRAM all at once.

> Has anyone tested the efficiency of hand optimised code
> for both modes in internal RAM?

Perhaps not hand-optimized code, but compiled code:
http://www.dwelch.com/gba/dhry.htm
ARM code runs about 60% faster from memory without wait states.

> Personally I prefer assembly to high level languages but I
> haven't yet found a decent macro assember for ARM that doesn't
> cost big bucks.

What's wrong with GNU Binutils?

> Keeping an eye on the assembly output of GCC seems to be the
> best way of optimising code & learning how to get the compiler
> to do what you want.

I can attest to that. It's how I (half-)optimized my mixer.

--
Damian