access emulated memory

[ara]

Hi,

Actually I have a question, not really a problem. The question is quite technical...

I would like to access the emulated Amiga memory from the x86 side as efficiently as possible. Is the following piece of code okay?

// Read a byte from (a0). Just an example!
uae_u8 b ;
if(canbang)
b=NATMEM_OFFSET[m68k_areg(regs,0)] ;
else
b=get_byte(m68k_areg(regs,0)) ;

Seems to work here for "ordinary" memory accesses. But what about accesses to custom chip registers, etc? The code generated by the JIT compiler seems to simply read and write the "real" x86 memory without further checks but I have to admit that I don't understand every detail (for example, the test of the "special_mem" flag in "compemu_support/readbyte.cpp").

[Toni Wilen]

Your code fails when accessing IO regions.

special_mem is the important bit. JIT uses normal (indirect) memory access functions when building native x86 code, direct access is only enabled if special_mem has correct flags set after memory access function returns.

Do not assume if memory region is directly accessible by checking address ranges. ("too easy solution but too fragile")

You only need to do normal indirect "check" access only once per memory "bank" to confirm if direct access is supported.

[ara]

Originally Posted by Toni Wilen

special_mem is the important bit. JIT uses normal (indirect) memory access functions when building native x86 code, direct access is only enabled if special_mem has correct flags set after memory access function returns.

Sorry for asking again, but it seems that the JIT compiler is a hard piece of code, at least for me. Could you explain how it works, please?:

In "newcpu/execute_normal", the emulator executes one instruction after the other until a jump instruction is reached (end of block). For each instruction, it remembers the status of the memory access:

pc_hist[blocklen].specmem = special_mem;

Then, it starts to compile in "compemu_support/compile_block". Each time it generates the x86 code for a 68000 instruction, it first restores the "special_mem" flag:

special_mem=pc_hist[i].specmem;

Does that mean that it generates direct-access x86 code if the corresponding 68000 instruction accessed "normal" memory? If the answer is yes, how can that work

1. in case of memory accesses via address register (variable destination address, sometimes normal memory, sometimes IO region)?
2. in case of instructions with two memory accesses (source and destination)?

It can't work like I described it above, can it? What is my mistake?

[Toni Wilen]

Originally Posted by ara

Sorry for asking again, but it seems that the JIT compiler is a hard piece of code, at least for me. Could you explain how it works, please?:

I don't know how it exactly works and I don't want to know

Does that mean that it generates direct-access x86 code if the corresponding 68000 instruction accessed "normal" memory? If the answer is yes, how can that work

Correct, it works because of installed exception (access violation) handler. All non-direct memory banks are not mapped in host's memory space (host OS does this magic), any direct read or write triggers the exception routine that analyses the failed access and fixes it. (I don't know how)

[Toni Wilen]

I think this is fast and safe and is not JIT specific:

if (valid_address(addr, len))
paddr = get_real_address(addr); // paddr can be used directly
else
// loop using get_byte() or similar

[ara]

Thanks for your help. The solution based on valid_address/get_real_address looks fine.

I just took a look at EvalException(...). Oh my god...
What happens if you have an illegal memory access inside the WinUAE code due to an ordinary bug? Will it also try to "fix" it?

[Toni Wilen]

Originally Posted by ara

Thanks for your help. The solution based on valid_address/get_real_address looks fine.

I just took a look at EvalException(...). Oh my god...

Now you know why nobody wants to work with JIT code

What happens if you have an illegal memory access inside the WinUAE code due to an ordinary bug? Will it also try to "fix" it?

I am not sure but I think exception handler will sometimes attempt to fix real bugs too.. (I have seen weird things happening like illegal access in GUI code causing weird insta-returns from C functions..)