That's pretty much what crazyc implemented, wrapping saves/restores
around these functions. But it might affect indeed more than i think.

I added a small bugfix to my page with the latest changes: http://members.chello.sk/apauer/dosbox5/dosbox5.html#bugfix

I modified the arm backend to make it slightly faster and a bit more comprehensible.
The changes and description are here: http://members.chello.sk/apauer/dosbox7/dosbox7.html

Thank you, i only had a quick glance over it, and most stuff looks good
(didn't get the temp-reg change, got to have a closer look at that).

If you mean the change in step 3 (in files decoder_opcodes.h and operators.h), that was becuse FC_RETOP was used to hold the value of the 3rd parameter. And this was a problem if FC_RETOP and FC_OP1 were the same register (FC_OP1 is the 1st parameter and FC_OP2 the 2nd parameter). I checked the dynamic recompiler and this was the only place where such problem occured.

The change will break the other recompiler backends as far as i see, but i have
not had a closer look at it yet (needs a FC_OP3 or something).

I checked the other backends and I think they are OK with the change.
Did I miss something ?

In its current state the
if (immediate) gen_mov_byte_to_reg_low_imm(TEMP_REG_DRC,decode_fetchb());
would fail for x86/x64 because TEMP_REG_DRC is not byte-accessible.

I missed that.
So, one fix woud be to use function gen_mov_byte_to_reg_low_imm_canuseword instead of gen_mov_byte_to_reg_low_imm (and MOV_REG_BYTE_TO_HOST_REG_LOW_CANUSEWORD instead of MOV_REG_BYTE_TO_HOST_REG_LOW).

On x86, another fix would be to switch FC_ADDR (ebx) and TEMP_REG_DRC (esi).
On x64 I don't know if this switch would work or not.

Also I found two possible bugs.
1) on x86 and x64 in function gen_lea, TEMP_REG_DRC is used directly instead of scale_reg parameter.
2) on x86 in function gen_run_code, only ebx register is saved, but both ebx and esi should be saved.

I'll try to have a look at both issues, but for the moment i'll only commit
things that don't affect x64 before the release. The new defines for the
arm emitter look nice btw.

Is there already port of 0.73 that uses the arm backend for the recompiler,
or somebody (going to) work on it? As i'll be committing the remaining
updates and fixes of this thread, but some testing would be good along
with this.

wd wrote:

Is there already port of 0.73 that uses the arm backend for the recompiler, or somebody (going to) work on it? As i'll be commit […]
Show full quote

Is there already port of 0.73 that uses the arm backend for the recompiler,
or somebody (going to) work on it? As i'll be committing the remaining
updates and fixes of this thread, but some testing would be good along
with this.

Yes im running the CVS on the pandora hardware

Ok thanks, keep an eye on the changes and please report back if they cause trouble
(assuming you didn't directly incorporate M-HT's updates).

Hi.
Maybe it's Windows Mobile specific, but DOSBox built for this system using ARM dynrec (CVS from 2009-07-04) experience random exits without warning/error.
CVS from 2009-06-23 was OK (ARM dynrec worked fine and stable).

Can you pinpoint some change? Like removing the respective instruction
(the dshifts were changed) makes it stable again?

Oh, i'm really not that experienced, but i'll try.

Could you please check which of the commits caused it? One was on 25th
of june, one on the 27th of june (be sure to compare the contents of the
sources you grab with cvs tools against the sourceforge contents of the
respective version).

Also as a quick check (using your current sources) disable the double shift instructions
(see decoder.h of the dynrec directory, remove the cases that call dyn_dshift_ev_gv).

wd, thank you.
With dyn_dshift_ev_gv removed dynamic core works stable.
Also i should say that current ARM dynrec works faster than previous one by at least 5%.

Maybe you can check if the commit from the 25th was already causing it,
or if it's broken together with the followup optimizations (27th).

wd, i feel dumb.
I've tested dynrec 1.4 - works fine (Jagged Alliance throwed 8bit irq pending error once).
Tested 1.5 - it also runs fine.
Most probably it's just my old device behaves bad.
Sorry for taking your time.