Re: [B2-devel] JIT Compiler: Direct Addressing likely to be mandatory

[<gb...@di...>]

Hi,

[New direct addressing scheme for Windows]

> In fact: I tested under OSR2/VMware and Win98 only after doing this
> aforementioned change, so it might be that you fixed it :)
> Would you like to try it out?

Sure, I would like to try it out but my Win98 is definitively dead now.
I ran scandisk and then it "fixed" the problems. And as their fixes tend
to remove things, I am good to reinstall Windows now.

I will try to have it up that week. My new 20 GB disk needs some
operating systems. ;-) I have just installed FreeBSD 4.1 and intend to
port JIT and support direct addressing for that OS too. That shouldn't
be difficult, though.

> >or simply implement the ScratchMem subterfuge as
> >well.
> 
> What's that? I have probably missed something.

That's the trick Christian uses under AmigaOS in order to prevent MacOS
from writing to ROM or some other places. You can check it from
rom_patches.cpp and rsrc_patches.cpp.
- ROM_IS_WRITE_PROTECTED is set to 0
- USE_SCRATCHMEM_SUBTERFUGE is set to 1

The hack is to patch the faultive handle so that it "points" to a
scratch region (64 KB) then just let MacOS writes to it as usual.

As nobody else seems to complain, I will drop support of banked
addressing mode if B2 is compiled with the JIT compiler. Direct
addressing is a so big deal, even with a pure interpretive core, that it
should be implemented on as many operating systems as possible. The only
problem is what you mentioned: a badly-written MacOS program could make
B2 to crash by writing to a valid host address.

There is an intermediate solution with the baseaddr[] trick as any
invalid bank would get mapped to a scratch memory area. That technique
associated with the JIT compiler is twice as slow as with the direct
addressing mode but it is, in my opinion, the fastest "safe" way to
operate.

OK, I have yet to fix the other bug (spcflags and "get out of compiled
code" process) then, we can start porting the JIT compiler to Windows
again. Talking about that, I won't be able to use your assembly
optimized core right now. Indeed, when an instruction is too complex to
be compiled (or no template is implemented yet), we just call the
"cpuemu*" handler and, as we don't return from an instruction handler in
your code, some changes would have to be done to the core. On one hand,
I am afraid those changes would probably slow down compiled code
execution. On the other hand, calls to "cpuemu*" handlers within
compiled code tend to be less and less frequent now, so that would
probably not slow down execution that much...