[B2-devel] New UAE JIT Compiler

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

Hi,

I am in the process of porting the new UAE JIT Compiler for Linux/x86.
For that purpose, I need a few information and arrangements. ;-)

1. Ability to directly access the Mac address space
   ------------------------------------------------

For faster performance and actually simpler porting, I want BasiliskII
being able to directly access the Mac address space only through one
offset.

i.e. as Lauri did for Windows NT:
ROMBaseMac - RAMBaseMac == ROMBaseHost - RAMBaseHost
VIDBaseMac - ROMBaseMac == VIDBaseHost - ROMBaseHost

Implementation: the main trouble will come from the Mac Frame Buffer.

(a) In order to mmap() correctly the address space in VideoInit(), I
would like to know what is the current ROMBaseMac. This is currently not
possible since VideoInit() is executed before Init680x0(). I am not
willing to duplicate code.

(b) In order to get a chance to mmap() the address space as
above-mentioned, MacRAM would not get allocated before VideoInit() is
executed. MacROM will possibly have to be relocated later.

(c) The relocation may fail. i.e. the address space could not be
allocated as above-mentioned. BasiliskII will have to quit.

(d) Due to the different frame layout that could be used, I implemented
video handling on SIGSEGV (see below). Drawback: DGA mode will be slower
since a temp frame buffer will have to be used too.

2. Video on SIGSEGV signals
   ------------------------

The idea is to make the frame buffer write-protected. Then, when a SEGV
occurs, the protection is released but the page number is kept so that
the pages to redraw could be found quickly. When redrawing occurs, pages
are write-protected back.

I am using a Linux 2.2.5 kernel and retrieving the address that caused
the violation is hacky. Reading from the kernel sources, I guessed that
address would be kept in particular location of the stack when the
signal handler is run.

i.e. the hack is:
void Screen_fault_handler(int, struct sigcontext scs)
{
    uint32 faultive_address = scs.cr2;
    ...
}

The Video on SEGV method is portable provided that the host system
supports siginfo_t for signal handlers (such as Solaris or newer 2.3.x
and 2.4.x Linux kernels). i.e. the si_addr address field will contain
the address that caused the violation.

This method provides faster screen updates though that was not the
intended purpose. That purpose was to copy to the host frame buffer and
make the necessary color conversions when redrawing the regions that
changed. e.g. RGB 555 -> BGR 565.

3. Translation cache flush rules
   -----------------------------

The rules are a little different than for UAE. TC flush will occur when:
- Code is created and executed from Execute68k(), Execute68kTrap()
- FlushCodeCache() is called
- A-Traps: FlushCodeCacheRange, FlushInstructionCache
- BlockMove()

Please complete the above list if necessary.

Notes:
- The translation cache does not necessarily have to be flushed
completely.
- Correct flush rules are needed if one doesn't want to checksum the
entire block each time.
- M68K_EXEC_RETURN has to be made an end-block marker. Ideally, it would
be best to have it right into the table68k.

4. I don't want to break the CVS tree ;-)
   ----------------------------------

I don't really have a "port" so I don't know what I can change in fact.

I implemented (2) in video_x.cpp except support of siginfo_t and DGA
changes when direct memory will be implemented. It is conditioned on
through the ENABLE_VIDEO_ON_SEGV macro-def. I don't have a better name,
so please tell me if you have a better one.

I intend to make direct memory access conditioned through the
ENABLE_DIRECT_ADDRESSING macro-def. Here again, I am open to any other
suggestion.

Actually, I never used CVS but I would like to try to commit the port I
made from Lauri's FPU code. Should I make it the default one when an
i386 cpu is detected ? A check for GCC will be required as well.

-- 
Gwenolé Beauchesne