Re: [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.

Implemented. And indeed, what a nice piece of improvement: near twice
the speed!

TODO:
- handle DGA modes
- handle siginfo_t
- make other blitters than RGB555_RGB565 (either big or little endian
versions).
[In fact, other layouts than 16-bit on a little-endian machine would
just require a byteswapping]
- clean up before committing (?)
- reversed address space (see below)

4. Reversed Address Space
   ----------------------

I had some success with reversed address space and the memory banking
method although the gain was not that impressive (~5%, as expected)
except for FPU-related operations (~30%, !?).

<http://www.multimania.com/gbeauche/basilisk2/wip/>
File: BasiliskII_RAS.tar.gz

The diffs can be easily found since I prefixed them with "ras--" into
comments. The key functions were:

- RAS_Mac2HostAddr_Reverse(addr, n)
  return the translated address of the block freshly reversed
- RAS_Mac2HostAddr(addr, n)
  return the translated address correctly offset
- RAS_Reverse(addr, n)
  reverse the specified region of memory
Those functions are defined in cpu_emulation.h

Note however that I didn't checked all the patches for "correctness"
yet, especially audio that makes strange sounds.

Now I know this method can work and could actually be beneficial (?) if
we use direct memory accessing, I wonder how hard it would be to make
clean changes into the base source tree.

A more clever way has to be found if one would like to easily experiment
another addressing method: Byte-swapped Address Space, that will work
well provided that unaligned accesses don't occur. I was hinted that a
real m68k does not handle unaligned access, does it ?

Another problem with reversed address space arises with the use of
direct addressing when patching the ROM since PatchROM() relies on a
native m68k byte-order.

As I used memory banks, I could bypass this problem because I had
specialised accessors that would handle ROM read/writes either in a
reversed fashion or in the standard way.

i.e. First, the ROM is left unreversed and accessors don't handle
reversal. Then, after PatchROM() is executed (say Start680x0), the ROM
is reversed and the new handlers are set.

Since changing (with use of Read/WriteMacIntXX) rom_patches.cpp to
handle direct memory accessing and reversed address space would require
too much work, a simple solution would be to wrap the (uintXX *) that is
used to iterate over the ROM, into an object that will do the job.

e.g. uint16 * wp = <something>;
would be translated into: rom_word_ptr wp = <something>;
rom_word_ptr would have proper operator overloading.
If that does not suffice, operator * could also return a helper-object
that will do the byteswapping, if required.

-- 
Gwenolé Beauchesne