gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

OffTopic > Optimizing C code into ASM

#11641 - poslundc - Wed Oct 15, 2003 12:24 am

...aka working twice as hard and twice as long just to do whatever it was you already did in C, but a bit faster. And debugging is harder, too.

Talk about unrewarding! :P

Dan.

#11649 - DekuTree64 - Wed Oct 15, 2003 3:25 am

Sure it's boring if it's something that worked fine already, but if you want to really push the limits of the system you'll never know just how far you can take it without doing it in ASM yourself. It's a real thrill when something runs really slow, even when you compile it to ARM in IWRAM, and then you write your own ASM version and it takes half the space and runs many times faster^_^
Or there might just be something wrong with me. I guess that's why I have trouble finishing large projects^^'
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#11652 - tepples - Wed Oct 15, 2003 4:21 am

(And why is this in the offtopic section? It sounds like it could be more appropriately placed in asm.)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#11653 - poslundc - Wed Oct 15, 2003 4:34 am

DekuTree64 wrote:
Sure it's boring if it's something that worked fine already, but if you want to really push the limits of the system you'll never know just how far you can take it without doing it in ASM yourself. It's a real thrill when something runs really slow, even when you compile it to ARM in IWRAM, and then you write your own ASM version and it takes half the space and runs many times faster^_^
Or there might just be something wrong with me. I guess that's why I have trouble finishing large projects^^'


I tend to agree, except that I just recoded my map-update routine in ARM ASM, optimized the hell out of it, debugged the hell out of it, and it still takes too long. Which means I need to reformulate my approach to the problem. (In this case it just comes down to too much stuff needing to be transferred via DMA, which is unfortunately something I can't improve upon by recoding in assembler.)

Blast... back to the drawing board...

Dan.

#11655 - poslundc - Wed Oct 15, 2003 4:41 am

tepples wrote:
(And why is this in the offtopic section? It sounds like it could be more appropriately placed in asm.)


Um, I didn't want to crowd any of the on-topic forums with what was pretty much me shaking my fist at the clouds? :)

In regards to the other contents of your post which have mysteriously (accidentally, I assume) disappeared, it's only taken a few days of studying the gcc -S -O3 outputs of my C files to really impress me with how straightforward and simple-minded the compiler actually is.

I kind of get the impression that before I'm done with this project I will probably have recoded 80% or so of it into ASM. So much for just optimizing the 5% that consumes 95% of the processor...

Dan.