m4xw

Hey, cool to see someone else bothering with writing a new JIT as well. But i have doubts that it would even come close to new dynarec, the 10-15% you...

You might want to test with stop_after_jal = 1 (see new_dynarec.c), this causes the blocks to be shorter and recompilation times to be shorter too. usually that reduces perf but...

yea like that. I thought that would reduce the overhead for this kind of measurement, but guess it doesnt. I still have some doubts tho, but dont get me wrong...

Whats your implementation of the counter reg? did u orient yourself on new dynarec?

iirc the ones that desync with new_dynarec had some interpret_ flag but i cant remember if @Gillou68310 back then made it fully match. We started a bit of a effort...

One thing u could test is how both jit's perform at varying count per op levels. I suspect maybe we might not be triggering enough interrupts to explain this perf...

oh i didnt see you do a fastmem implementation. that would explain it. We actually started implementation for new dynarec before too but ran into some issues

> > mapping and reserving the maximum possible ROM size to RAM seems a bit excessive even for machines with more than 8 GiB of RAM > > Just because...