Arm Asm


this is the main part of a console (the CPU) but coded in ASM (assembly language)wich is really faster
with that it is possible to have a fullspeed emu I think...

see you :lol:
 
Yeah, arm asm is the specific language for the chip that the gamepark uses, so it gives the chip direct commands I believe. If coded correctly, this is the fastest you can run something B).
 
Question- would this drain the batteries any faster? I assume not since it dousn't oc the processor, but im still curious.
 
triksR4rabits posted on Apr 16 2004 at 11:59 PM said:
Question- would this drain the batteries any faster? I assume not since it dousn't oc the processor, but im still curious.
Well actually I think it might have a slight effect, in theory I think it wouldn't though. What got me thinking what how some people can overclock in some programs but not in others. Those programs that can't overclock seem to be the more developed ones which have been optimised more (like opensnes9x). This would suggest that more optimised programs put more of a strain on the processor and perhaps drain more battery power.

A coder might be able to say if I'm correct or not though.
 
Last edited by a moderator:
triksR4rabits posted on Apr 16 2004 at 11:59 PM said:
Question- would this drain the batteries any faster? I assume not since it dousn't oc the processor, but im still curious.
It'll probably be about the same...

When you compile a program written in C, the compiler actually builds asm from your C code, then the binary from that asm. The thing is, humans - particularily smart ones, can write more efficient asm directly.
Because asm has a pretty small set of instructions making complex programs with it is quite a challenge. If a program has a really cpu intensive routine in it, the coder might rewrite that routine in asm to make it less work for the cpu - which means the cpu can run that routine faster and get more stuff done for less clock cycles.

An emu generally has a set of jobs it must do in a particular amount of time. ie render the screen, process user input and produce the sound quick enough to be useable. This might not possible, so the coder will drop some of those jobs or make them easier to do - less accurate.
So the aim in converting the core to asm would probably be to make the code run faster, so the emu will run faster, and get more stuff done (drops less frames, produce the sound more accurately) but ultimately use the same amount of battery power.

In some cases the asm core might be so much better than the C compiled core that the emu finishes all it's jobs completely in time, which means it'll spend a few clocks sitting there waiting for the next emulated instruction or the emu might still be 100% accurate but run at a lower clock speed - this would mean it would use less power. This is quite unlikley for this particular core, but entirely possible for something less complex, like emulating a c64 or speccy.
 
Last edited by a moderator:
triksR4rabits posted on Apr 16 2004 at 05:59 PM said:
Question- would this drain the batteries any faster? I assume not since it dousn't oc the processor, but im still curious.
ummmm...hmmm...i don't think that it would affect the battery life...but if anything (if coded properly) it would let you gain battery life...IF coded properly...and optimized...but it prolly wouldn't be noticable...

and iirc, when the compiler compiles the C files, it is turning it into arm assembly, then it is turning it into cpu code...
 
Last edited by a moderator:
baked chunk posted on Apr 17 2004 at 01:37 AM said:
:blink: is there any way it'll be avalable to the average n00b such as myself anytime soon??
what do you mean? assembly?! it is a language... like C++...
 
Last edited by a moderator:
possibly the only language harder to work with than C

*still can't understand why they couldn't have built in proper String support*
 
Back
Top