GP32 Atari Lynx Emu. Can This Be An Optimization ?

[ConsoleTom]

Hi !

I would like to optimize a lynx emu for the gp32 by rewriting some parts in assembly. I asked this question already but now i have a new idea:

What would happen to the speed of the emu (or parts of it) when i would re-write in thumb assembly ? Good idea or nonsense ?

I had this idea because most used values in the emu have 16 Bit (unsigned short).

(Before someone tells me: I have a routine to profile code).

Is it possible to compile a program completly to thumb in gcc ? (Just for some experiments...)

Greetings

Tobias

 

[mr.spiv]

From my experience you get faster code with ARM mode asm than thumb.. mostly due more efficient instructions and more available registers. In theory thumb would be faster but ARM920T has so big caches that those compensate the 16bits membus..

Of course it is possible to compile whole program in thumb (except for few instructions in the crt0.o etc). Afaik the first snes emu was compiled to thumb. If you want to use SDK also.. then it will be tough to compile your code to thumb.

 

[skeezix]

Remember that Thiumb is supposed to be smaller, not faster.. it can be faster due to fitting into cache and such, but really ARM is where the speed is supposed to be.. more efficient, more registers etc. In practice.. hard to say. I've seen no improvement going between the two (from a compilter), to significant improvement.. depending on the cache etc. But doing it all by hand is a whole other story.. its best not to mix thumb and arm too much though

jeff

 

[Prime Suspect]

If you can stick to ARM - taking the right approach it's lightning quick - I thoroughly recommend reading the Samsung CPU doc to get a feel for exactly how you can get the best from it.

Prime

 

[Dave18]

Another big advantage of sticking to ARM code is that you can access all 15 registers with all instructions (THUMB only lets you access r0 - r7 with instructions other than mov or add).

Someone please correct me if I'm wrong (I often am!)

The more registers you have the more optimisations you can make. I've written a 6502 core that always holds each 6502 register in an ARM register until an interrupt is generated (doesn't do a lot else at the moment though) which makes it very fast (not sure it would be so fast for Lynx though due to all the custom hardware that no doubt have their own registers).

There is a ldrh ARM instruction to load halfwords but I could never get it to work properly for 16bit addressing. Maybe it can only load word aligned halfwords.

 

[Dave18]

Whoops, just noticed I repeated what Mr Spiv said about the extra registers. That'll teach to read all the other posts properly first!

 

[_tyrell_]

I remember having attempted to rewrite some part of my emulator in ARM asm. It ended up being slower than the original c code !

_tyrell_

Speccyal K

 

[ConsoleTom]

I remember having attempted to rewrite some part of my emulator in ARM asm. It ended up being slower than the original c code !

_tyrell_

Speccyal K

Hi !

Oh yes, i know this. I tried to rewrite the display routine but it got slower.

Greetings

Tobias

 

[tuskenraider2k]

Hi'

I really liked to improve the Lynx emu more, I tried a lot things in september, but then I liked to do other things more :-( ...

My conclusion was, that you really have to reorganize the complete interpretaion from the cpu-code from the lynx (or self modified code??).
I really don't know.

most time the code is now inside a function "UpdateExt()" from "c65c02.h". So there nearly no function calls "to the upper code". (in the current sources this is in the function "Update()")

Here is a big switch area for all cpu-codes which peek or poke and set some cpu-flags. I only analzied and tried to optimized the c-code so Chip's Challenge got playable

If nothing is put to the display it is about 10% faster, but we need a speedup of 100% so we get something really cool without sound ..

 

[aguirrech]

i love atari lynx, please finish teh emu, there are some good games to play, like as dracula or alien vs predator 3D...

i think that the code could be rewritten so it would optimize the emu... ARM powaaa

 

[ConsoleTom]

Hi'

I really liked to improve the Lynx emu more, I tried a lot things in september, but then I liked to do other things more :-( ...

My conclusion was, that you really have to reorganize the complete interpretaion from the cpu-code from the lynx (or self modified code??).
I really don't know.

most time the code is now inside a function "UpdateExt()" from "c65c02.h". So there nearly no function calls "to the upper code". (in the current sources this is in the function "Update()")

Here is a big switch area for all cpu-codes which peek or poke and set some cpu-flags. I only analzied and tried to optimized the c-code so Chip's Challenge got playable

If nothing is put to the display it is about 10% faster, but we need a speedup of 100% so we get something really cool without sound ..

Hi !

I don't see any optimization possibilities in assembler (at least for my programming skill).

But could it be possible to optimize some (floating point) calculations of the lynx by using tables (arrays) that contain all possible results ? Would it help somehow ?

Other thing. I designed an icon for the emu - interested ?

Greetings

Tobias

 

[NiN^_^NiN]

I talked to CHN (orignal author of the lynx emu) ages ago and the problem is with the cpu core. It really wasnt written proper and thats why it runs sluggish i tryed quite a few things to speed it up (am a newbie mind u) with chns help and it really wont help.

You need another lynx emu and there is only 1 other which is in that emulator that emulates quite a few emu's

can't remember the name but u might try looking at that code.

It had the same kinda naming as mame

but yeah the CPU core is the problem in the program either fix that or look for a emulator that has that fixed (only 2 lynx emu's thats exsist as far as i know)

Or try zophar.net i think they have a few unfinished Lynx emu's the core cpu might help you out on a few things

h34r:

 

[Alpha2]

I only see two emulators on Zophar, Handy090 and metalynx which is written in assembly but incomplete. only plays one homebrew game and intros.

 

[mr.spiv]

There are 6502 cores in ARM asm.. someone might look at those and try to integrate.. :unsure:

 

[MojoJojo]

Remember that Thiumb is supposed to be smaller, not faster.. it can be faster due to fitting into cache and such, but really ARM is where the speed is supposed to be.. more efficient, more registers etc. In practice.. hard to say. I've seen no improvement going between the two (from a compilter), to significant improvement.. depending on the cache etc. But doing it all by hand is a whole other story.. its best not to mix thumb and arm too much though

jeff

Hmmm, that is not entirely true. On the GBA, THUMB is used a lot, since there is no cache and the "external RAM" only has 16bit data bus, so each ARM instruction takes 2 cycles to execute. Using THUMB in this case can be faster.

On the GP32 the cache cancels a lot of this out (from what Mr. Spiv says), but I imagine you could probably come up with cases (paricular cpu/memory multipliers, cache settings etc) where THUMB would be faster. I imagine these would be pathological cases though, so ARM will probably always be faster...