short int = 16bit
long int = 32bit
int on it's own is supposed to be the platforms native integer as stored in a CPU register, so on a 64bit CPU running a 64bit OS, int = 64bit. On a 32bit Arm platform (like the Iphone) it's 32bits
Now if using a smaller size than native in ASM will break the code? well it depends on the operations you're carrying out, instructions/registers used etc the CPU can mix and perform operations on various combinations of integers of different sizes, no problem adding an 8bit number to a 64bit number and so on, it's the size of the register in which the CPU stores the result and the type of variable in memory in which the result is saved that matters, too small and it overflows. this is all handled in a compiler and warnings are given if you explicitly state the result to be stored in a smaller int (you may of seen compiler messages along the lines of 'mixing of two types gives 64bit result' etc) however even if you're storing a 16bit int, the actual operation might of took place in 32bit registers.
If you're using pointers for example they are the native int format, so would be 32 or 64bits depending on your CPU - OS - compiler. (and when I say 64bit OS, I mean an OS that puts the CPU into 64bit mode)
Anyway, all that said, you shouldn't be doing this graphics routine like this, it's woefully slow even if you use ASM (and just writing it in pascal will not result in code that's much slower) You should be using GLSL, judging by the techniques used in the C source, this was written before shaders existed, it's what you'd do if you didn't have a programmable pipeline. Plus this is x86 ASM, by using it you're not going to be porting to android/iphone unless you write equivlent ASM routines for ARM, or use the language and let the compiler do it.
Reply With Quote
Bookmarks