GP2X Thumb Life

[gfoot]

I don't know if anyone here is interested in using the Thumb instruction set... but I've packed my tinylife down to 412 bytes by converting most of it.

http://www.glost.eclipse.co.uk/gfoot/gp2x/thumblife.zip

The functionality is the same, and some of the optimizations would probably have applied to the ARM code too, but even before trying too hard, using the Thumb instruction set did tend to reduce code size quite a bit.

If you want to learn Thumb, there are quick reference cards on www.arm.com, but beware - the mnemonics they list are based on a later version of the architecture and assembler than what we seem to be using, so even the instructions which are supported by the GP2X are not listed correctly. The main difference is that all the 's' suffixes shouldn't be there. I found this documentation of the ARM assembler to be a better reference overall, as the GNU assembler understands the mnemonics used here:

http://www.arm.com/pdfs/DUI0068B_ADS1_2_Assembler.pdf

Switching to/from thumb mode is easy enough - see the macros at the top of thumblife.S. It costs a bit of space, though, so you don't want to do it much - I just used the toggling to convert tinylife a piece at a time.

The Thumb instruction set is odd after ARM - on the one hand, the bits of ARM assembler which seem clever (optionally setting flags, conditional execution, the barrel shifter, and updating base registers after/before indirect addressing) are no longer available, but on the other hand, because the instructions are half as wide, you can get pretty much the same thing done in the same space by just writing out the shifts in full. Even ARM code which I thought was making good use of these features ended up smaller when I converted it to Thumb.

Obviously, Thumb is useless if you care about speed rather than size, and that's probably most often the case. All these instructions split into two cost twice as much as the compound instructions ARM supports. Still, it's been fun to try it out - not sure if I'll ever need to use it again, but you never know!

tinylife.gp2xe: 512 bytes
tinylife.gp2xe.gz: 449 bytes
thumblife.gp2xe: 412 bytes <= better than gzip!
thumblife.gp2xe.gz: 377 bytes <= not including unpacking overhead

 

[Yono]

Wow, that's great! About time for a 4k demo competition? B)

 

[Squidge]

How about a 4kB/1kB game compo?

 

[TheMinder]

[fan|stalker post]
Apologies for this because it's slightly off-topic, but after following the links in the initial post and looking around the webspace it suddenly became clear why the username GFOOT rang a nagging bell with me - you're the man who wrote Vivace !

Would just like to give you a belated "thank you" because many years ago (seems like many anyway) it got me going and interested with allegro, and pretty much got me back interested in coding in my own limited way so i salute you !

[/end fan|stalker post]

 

[jix]

Wow, that's great! About time for a 4k demo competition? B)

Yeah! But make the deadline like uhm 10/25...

 

[rabidcow]

Thumb might be faster if your inner loop is ~20% larger than the instruction cache. That's a pretty big loop though.

It should be possible to do life with the hardware blitter. I wonder if that would be smaller...

 

[PSyMastR]

How about a 4kB/1kB game compo?

Ill talk with Magnus about maybe adding that to the competition, even though the rules were already set, that may be cool, or maybe a later on competition.

 

[JyCet]

I'm very very interested for tiny game / demo but how bypass SDL lib with devkitgp2x ?

I'm not an expert of gcc configuration and today I use only the wiki full package with some little path config change, that's all

Thanks

 

[gfoot]

Dzz wrote some tutorials in the "Gp2x Demo Development" thread - it's a sticky in this forum. Bypassing SDL isn't a problem - just don't link it - but even linking the standard C library costs quite a few kilobytes, so wouldn't be suitable in a 4k contest.

You can still use C so long as you don't touch the standard library, and use special linker flags to prevent linking of the standard library. For really tiny things you need to use assembler, play tricks with the headers, overlap data, etc. It's not very scalable.

I use a program I wrote called "elfpatch", which initially used to strip redundant data from the ELF file, which is not needed for running it, but evolved to actually just extract the code section and write it out verbatim, so you can write your own headers in your assembler code. It detects this by looking for an elf haeder at the start of the code section. As it changes the relative address of the code segment, and strips the data segment completely, it would be hard to use with C code as it stands, but you could adapt it to run in a simpler mode that just strips the "section headers" from the end of the file - that wouldn't affect the offsets to the proper runtime sections, but would still cut off about 300 bytes of useless data.

I explained a lot of my methods in the tinypong thread.

FWIW, it doesn't sound like a general GP2X game competition ought to have such tight size limitations - surely for that it would be better to encourage people to make as impressive games as possible - but it would make a good separate contest later on.

 

[jix]

You can still use C so long as you don't touch the standard library, and use special linker flags to prevent linking of the standard library. For really tiny things you need to use assembler, play tricks with the headers, overlap data, etc. It's not very scalable.

I use a program I wrote called "elfpatch", which initially used to strip redundant data from the ELF file, which is not needed for running it, but evolved to actually just extract the code section and write it out verbatim, so you can write your own headers in your assembler code. It detects this by looking for an elf haeder at the start of the code section. As it changes the relative address of the code segment, and strips the data segment completely, it would be hard to use with C code as it stands, but you could adapt it to run in a simpler mode that just strips the "section headers" from the end of the file - that wouldn't affect the offsets to the proper runtime sections, but would still cut off about 300 bytes of useless data.

One should be able to get somewhat good sizes by linking with --strip-all -N. (joins data and code section saving a few bytes for the program headers (allows self modifying code too because that section has mode rwx)) This works of course with C... after that i usally strip the section headers + symbol table that still includes the section names with a self written script...

 

[gfoot]

Yes, that sounds better, and it'll work a lot better with C code than my method. The reason absolute addresses don't work with elfpatch is that removing the program header for the data and/or bss sections offsets the start of the text section relative to the beginning of the file.

Does the --strip-all option also remove the bss section? It always seemed to get generated, even if I didn't use it...

 

[jix]

Yes, that sounds better, and it'll work a lot better with C code than my method. The reason absolute addresses don't work with elfpatch is that removing the program header for the data and/or bss sections offsets the start of the text section relative to the beginning of the file.

Does the --strip-all option also remove the bss section? It always seemed to get generated, even if I didn't use it...

The bss section only exists within the section headers... those don't get stripped with --strip-all (i use a script for that) the relevant informations about the bss section are in the size of the data section program header (bss is generated if memsize > filesize) so it doesn't even make your file larger than it is.

PS: the reason i use --strip-all (which does the same thing as the strip tool) is that strip seems to re-inserts a data section

 

[Dzz]

I would be excited about a "tiny program" compo. I can see advantages and disadvantages for each of the possibilities:

1k demo
Pro: 1k is very small which is cool
Con: Results will not be visually impressive, insufficient code space to produce truly interesting effects

1k game
Pro: 1k is very small which is cool
Con: limited game quality possible

4k demo
Pro: standard demo category, sound might be possible, more flexibility in effects
Con: having 4k to work with might discourage entrants

4k game
Pro: the games will be more interesting than possible in 1k
Con: development time increases

So I don't care which, they all have their benefits and drawbacks. I think it would be best to pick one category though as there are only going to be a handful of entries anyway... little point in having a "compo" if there's only one entry per category.

As always, the thing that's needed is somebody to organize it. Luckily, with my other demo competition and the community game competition there are some rule sets that should be easily adaptable so it won't be too much work to set it up. I don't want to do it because I want to enter.

I will chip in a prize if somebody has a compo: a developer breakout board which I bought but never used as it turns out I don't need any of its functionality.

 

[sparr]

Considering all the things that can be done in <512 bytes (sp pong, life, plasma, etc), I think that a 1k demo or game compo would be awesome. I am reviving this long-dead thread because I am getting my new gp2x soon and plan to do some tiny asm games.