GP32 Gp32 Assembly Programming


overmind

Still Fresh
Joined
Oct 4, 2004
Messages
7
Is really assembly programming too hard? Could be, but is not impossible. Actually i want to do it. But programs need some initialization procedures. Arm assembly code and tutorials are easy to find. But specific GP32 assembly programming don't. Assembly programs are small and fast. You could write really awesome games for GP32 with it. Are you interested?
 
Is really assembly programming too hard? Could be, but is not impossible.

Assembly programming is hard.
And in most cases, unnecessary.

Here is what normally happens:
High level program -> Assembly language -> Executable binary code

So if you want to be hard core, you just type plain binary.

Actually i want to do it. But programs need some initialization procedures. Arm assembly code and tutorials are easy to find. But specific GP32 assembly programming don't.

In case you fail to notice my sarcasm before: it is not good to do something, just because it is fast and cool. Furthermore, I do not think it is good to write pure assembly programs.

Pure assembly programs usually reside in small embedded systems, with no real support for higher level languages.

If you write your game in C or C++, you can use it in future in other systems (GP32 2 , Nintendo DS, whatever), just because it a language everybody uses. Assembly comes in many flavours and is nearly always machine specific. Do search word "portability" on your tutorials.

Assembly programs are small and fast. You could write really awesome games for GP32 with it. Are you interested?

Small, in what meaning? Program size, yes it is smaller, maybe 50%, maybe even 90%. But not assembly programs are usually short and specific. You don't create anything big using assembly. I have created a nibbles game for Windows PC in less than 100 bytes, but so? You don't do anything big in assembler.

Fast, yes but in terms of code optimization. I mean, that if you write the same code in assembler, your code will be faster, because usually you achieve better register allocation and memory pointer usage, than compilers. But not in algorithmic speed, meaning, that for large sets, effiecient algorithm would be faster than finetuned assembly brute force approach.

Not interrested. I only do small assembly games for fun, but C is fast enough.

However, it is usually 10% of the code, that takes 90% of your execution time. It would be smart to write an assembly code replacement for that part. That is what for example emulator people mean, when they say "assembly core". It means, that most critical parts are pure assembly, because they are executed often. I have checked some emulator source codes, and they still do initialization routines and file browsers, etc. in C. Why? Because speed is not needed there, and program is too big or complex to be written in 100% assembly.
 
Maybe your assembler code isn't faster than your C code. My assembler graphics routines are much, much, MUCH faster than my C routines. Same algorithm, only optimized.

If you are good at writing asm, you can do awesome things you could never achieve with C.

Also, don't even think about getting into a discussion with me about this, I know what I'm talking about :):):)
 
Maybe your assembler code isn't faster than your C code. My assembler graphics routines are much, much, MUCH faster than my C routines. Same algorithm, only optimized.

You are right. I said assembly is faster, but harder to understand and not so easily portable.

About algorithms: don't optimize - choose better algorithm, works in many places.

If you are good at writing asm, you can do awesome things you could never achieve with C.

Only speed. Nothing else.

Also, don't even think about getting into a discussion with me about this, I know what I'm talking about :):):)

Never argue with an idiot - he drags you down to his level and beats you with experience :) :) :)

Seriously, I think your David Hasselhoff pic is well.. funny :D
 
For me, assembly programming is mainly just a fun challenge to try and figure out. I probably won't actually make any finished games with it (I don't have the time), but I still enjoy trying to figure out complicated things (I love my pre-calculus class!).
 
I've found that in my experience, there are very few times when assembler gave me an improvement. For example, in the sound engine in Doom, the mixing is done in assembler because I could make it very tight and fast, but the (much more complex) OPL2 emulation is done in C. In fGen32, the rendering code is all in C because I just couldn't improve on it by hand-coding the assembler.

C compilers are better than people at doing the important things that just aren't fun for people: like deciding which variables to put in memory when they won't all fit in registers, shuffling the code to avoid load-use interlock stalls etc.

I'm sure that my failure to make awesome assembler comes from a lack of skill on my part :) and Inopia totally has my respect, but unless you really know what you're doing, you won't improve noticeably on a good compiler.

Notes:
1) it's worthwhile to know a bit about how the compiler converts various C sequences into assembler, so you can write your C such that it will produce good assembler output.
2) gcc (version 3.3 onwards anyway) is a good compiler, the difference between it and ADS is very small.
3) programming in assembler because it's a "fun challenge" is a perfectly good reason to do it! :D
 
I found out arm asm was a very interesting way of programming while I was working on GpFinalWar's zoom routines. I don't use it much also, just for very cpu-intensive things such as my zoom blitting routines or sound mixing.

But when I look back on my code it puts a big smile on my face. There are so much ways of doing the same things, but there is only one that will give you maximum peformance. That's a fun challenge in my opinion. But as it was said before, the gcc compiler is a great challenger. :)
 
Well just like you shouldn't drive a nail into a piece of wood with a spanner, you shouldn't write your entire program in ASM, DUH. you just need to choose the right tool for the right job, like any professional programmer will tell you. Assembler is the right tool for the speed job.

And your statement about algorithms is total bullshit. Ofcourse you should choose a right algorithm, but even after doing so, you must always seek optimizations for your special case. This is true for most time crucial algorithms I encountered on GBA and GP32.

So I agree with you that you should write stuff in C, and use good algorithms, but I grew up on demos and graphics programming. I know how much increase in speed you can get from a polygon routine if you rewrite the thing in ASM.

As for portability, you cannot optimize for speed AND keep portability. If you want to sacrifice speed for portability, in my opinion, you're just plain lazy :D
 
@robster: if you need tips on optimizing that render code, ask me anytime. I think I know a few tricks that might be new to you :)

Also, try reading my old gp32 optimization doc. It's about 1.5 years old, but should give you some tips like mul r0,r1,r2 might be slower/faster than mul r0,r2,r1 etc.
 
I normally write most things in plain vanilla C, and if the program turns out to run too slow, then profile the code, look at the generated assembly output of the compiler, and finally optimise the C or rewrite portions in assembler.

I find a lot of the time that a simple change to a C file can generate wildly different assembler code, so I normally try a few different ways in C before resorting to assembler.
 
Inopia posted on Oct 7 2004 at 08:14 AM said:
you shouldn't drive a nail into a piece of wood with a spanner

Whaat ? Why not ? >_>
I often do that :eek:
 
Last edited by a moderator:
A fight like this is unnecesary. "c" is a good language for most programmers. But some hardware features could never be used with it. Do you know that GP32 can achieve advanced real time 3D graphics are posible using the barrel shifter and fixed point math?

You could write assembly porgrams quickly, clearer and easy debugging if you hnow how to write them. Style Guidelines for Assembly Language Programmers is an useful manual to write clear and easy debugging assembly programms. x86 code must be replaced for arm instructions in this manual.

Assembly programs are too long for your typewriting skills? You could get a dvorak keyboard or reprogram your old keyboard free. For Windows users open Control Panel, Keyboard. Just set language english US, and properties select US dvorak. There left handed, right handed and standard dvorak. Just need to practice a couple of weeks and you'll be a very fast typewriter.

About portability: Portability could be ok for bussiness data systems. But console gaming is diferent. Porting console games requires more than simple programming. Every piece of data must be converted for suit the features of news consoles. And code is just a little percentage of total time in game development. (from two or three weeks with alpha test and source debugging) If I want to port my game to PC. I'll code in assembly the whole thing. Why? Because Streaming SIMD Extensions 2. Every computer system have special components that can be used if you're an assembly programmer. A normal 'c' program could no use these components for 'portability'.

Assembly programs really pay your effort. Efficient algorithms are even better if are written in assembly. Why lose so great oportunity?
 
There is something you have to know....

Do you really think that in the videogame industry, they would retype all their games from PS2 to Xbox and GC ????
Do you really think that because they have good keyboard configs they re-typed everything so that it would look EXACTLY the same ????
No chance for that mate, they just have specific functions for each platform (display, sound, input...) and they work on the project as a whole. Then they just compile for each platform, so conversion time is 0,0000000000s.

Second thing: you seem to be very sure that asm lets you make great things. So, try and show us !!!! But I really think before you make a platformer that way, Gp64 might be out... ;)

And last thing: compilers are aware of SIMD extensions if you configure it right. No need to use asm for that.
 
Ok, I'm Surrender!! Was not my intention start a Holy War.

It' said there are 1000 'c' programmers for every assembly programmer. I don't want to change anybody's beliefs. Because respect religious liberty in programming. I start this topic 'cuz i need some specifical technical data about GP32 LCD init code. Repeat I don't wanna fight, but to program!

Math said there are as least 2 or 3 potentially assembly programmers there. Assembly programmers are peaceful people and can be great people if you give them a chance. Repeat. I don't want to change anybody beliefs!

Howeaver, if 'c' is not enough for someone, exist an interesting doc written by Randall Hyde about 'c' and assembly:

The Great Debate Asm vs C. By Randall Hyde

Caution!! If you're happy with 'c', do not click link above. This Holy War must be over!
 
Back
Top