basilisk-devel — Basilisk II development-related discussion

[B2-devel] VOSF problems with NetBSD/m68k resolved

[Christian B. <cb...@st...>]

Hi!

I figured out what caused the VOSF on NetBSD/m68k to fail. It was the
floating-point calculations used to convert the page size to a shift count.
With a page size of 4096, it returned 11 instead of 12 due to rounding
errors. This resulted in page numbers being usually twice as large as they
should be (explaining the stripes) which also caused memory to be
overwritten (explaining the crashes). I have replaced it with an integer bit
search and now it works perfectly.

I believe that this is also what's causing the problems I'm having on
my Linux machine at home. I will check this when I get there.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] JIT-enabled BasiliskII for Linux/i386

[Christian B. <cb...@st...>]

Hi!

On Thu, Oct 12, 2000 at 11:42:22PM +0200, Gwenole Beauchesne wrote:
> How much faster do you think it is ?

If I believe the Speedometer tests, it's 4 times faster than the non-JIT
version. Somewhat like a 100MHz PPC 601 on this PIII/500.

> BTW, do you still intend to add some emul_ops for QuickDraw acceleration ?

Yes, but that would require a non-refreshed video mode, which is hard to
come by these days...

> [Julia's Dream]
> After having read gencpu.c, I noticed a possible bug with CAS and CAS2
> instructions when the noflags handler comes to be used.

Julia's Dream doesn't use CAS, but it uses BFEXTS and the V flag. Might
these be a problem?

> I noticed you also had problems with VOSF under NetBSD/m68k. In
> video_blit.h, does replacing the Duff's Device based blitter with a dumb
> loop copying byte per byte, do any good ?

I will try that.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] JIT-enabled BasiliskII for Linux/i386

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

Hi,

> Hey, 7.6.1 is the best version of MacOS ever! :-)

Indeed, I have been told that but I directly jumped from 7.5.x to 8.x so
I missed that one ;-)

> > Try to disable the lazy flusher in compemu.h by setting
> > ENABLE_SOFT_FLUSH to 0.
> 
> That did it! The performance is very impressive.

You know, I always wanted to have BasiliskII at least faster than my
real Quadra 630 under my little AMD K6-2/300 powered Linux box. ;-)

How much faster do you think it is ? Among my quick tests with
Speedometer, Apple Personal Diagnostics, and Graphic Converter, I can
say that on the average, it is only twice as fast as Fusion 3.0 in dos
mode :-(

BTW, do you still intend to add some emul_ops for QuickDraw
acceleration ?

> In "Julia's Dream" there are some artifacts in the display, though (mostly
> in the window center). Looks like an arithmetic sign or flag is
> miscalculated somewhere.

After having read gencpu.c, I noticed a possible bug with CAS and CAS2
instructions when the noflags handler comes to be used. In any case, it
should set the flags because Z flag for example is used to determine
where to write the result (put_long / dreg ?). Bernie has now fixed it
in his source tree and I will probably do the same on next weekend.

Good news: Bernie implemented some FPU instructions for the JIT.

> BTW: Can the USE_MAPPED_MEMORY and related stuff be removed? This would
> clean up the code a little.

Yes, I don't need it. Eventually, the configure script will test the
possibility of mmap() if neither direct or real addressing is used (mmap
is already tested for in those modes). mmap() is "mandatory" because
malloc() probably isn't guaranteed to set the EXECutable bit for the
allocated region.

Actually, I would have liked to use the USE_COMPILER macro and the
compiler.cpp file name. Less files, shorter names, that's good ;-)

BTW: last time I tried, real addressing didn't work with the compiler.
mem_banks should still work but I think they consume too much cpu power.

I noticed you also had problems with VOSF under NetBSD/m68k. In
video_blit.h, does replacing the Duff's Device based blitter with a dumb
loop copying byte per byte, do any good ? If not, I really don't know
where the problem could be from.

Bye.
-- 
Gwenolé Beauchesne

Re: [B2-devel] JIT-enabled BasiliskII for Linux/i386

[Christian B. <cb...@st...>]

Hi!

On Thu, Oct 12, 2000 at 05:31:19PM +0200, Gwenole Beauchesne wrote:
> I got similar problems while developing it but it did work for me with
> MacOS 8.1. I should have tried with earlier versions of MacOS...

Hey, 7.6.1 is the best version of MacOS ever! :-)

> Try to disable the lazy flusher in compemu.h by setting
> ENABLE_SOFT_FLUSH to 0.

That did it! The performance is very impressive. In "Julia's Dream" there
are some artifacts in the display, though (mostly in the window center).
Looks like an arithmetic sign or flag is miscalculated somewhere.

> I think I will make publicly available some builds before commiting to the
> CVS.

BTW: Can the USE_MAPPED_MEMORY and related stuff be removed? This would
clean up the code a little.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] JIT-enabled BasiliskII for Linux/i386

[Christian B. <cb...@st...>]

Hi!

On Thu, Oct 12, 2000 at 07:49:21PM +0200, Gwenole Beauchesne wrote:
> BTW, could someone with a PentiumII-class cpu compile and try the
> program at: <http://www.multimania.com/gbeauche/basilisk2/wip/>
> File: cmov_test.c

I've tried it on a Pentium II/Deschutes (where it reports "yes", as on a
PIII and Athlon) and on a K6-II (where it reports "no"), consistent with
what /proc/cpuinfo says.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] JIT-enabled BasiliskII for Linux/i386

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

Hi,

> Seems to be due to the lazy flusher :-( I got similar problems while
> developing it but it did work for me with MacOS 8.1. I should have tried
> with earlier versions of MacOS...

I have just tried with MacOS 7.1.2 and the lazy flusher in 68040 mode.
It still works. I should read again the compiler...

BTW, could someone with a PentiumII-class cpu compile and try the
program at: <http://www.multimania.com/gbeauche/basilisk2/wip/>
File: cmov_test.c

And tell me if it actually shows up "Your CPU does support CMOV." ?

Thanks.
-- 
Gwenolé Beauchesne

Re: [B2-devel] JIT-enabled BasiliskII for Linux/i386

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

Christian Bauer wrote:

Hi,

> It seems somewhat unstable, though. If I set the CPU type to anything other
> than 68040, all I get is a black window.

Hmm, that might be because we don't have specialised versions of
comp_smalltbls for CPU lower that 68040. i.e. 68040 is always assumed. I
will try to fix it soon.

> And even with 68040, I can't get it
> to complete booting MacOS (tried 7.0.1, 7.5.3 and 7.6.1, with and without
> extensions). The error messages are various, ranging from "illegal instruction"/
> "fpu not installed" MacOS dialog boxes to "Illegal instruction" messages from
> B2 and segmentation faults.

Seems to be due to the lazy flusher :-( I got similar problems while
developing it but it did work for me with MacOS 8.1. I should have tried
with earlier versions of MacOS...

Try to disable the lazy flusher in compemu.h by setting
ENABLE_SOFT_FLUSH to 0.

> I tried "jitcachesize" values of 128K and 512K (prefs_items.cpp/
> AddPrefsDefaults() should set a reasonable default value).

The value I use is the minimal cache size value used for the DR-emulator
from Apple, that is to say 256 KB. I think it's reasonnable but higher
values will get better performance with the lazy flusher while no gain
is accomplished otherwise.

Thanks Christian for all those reports. I think I will make publicly
available some builds before commiting to the CVS.

Bye.

Re: [B2-devel] JIT-enabled BasiliskII for Linux/i386

[Christian B. <cb...@st...>]

Hi!

On Mon, Oct 09, 2000 at 12:41:26AM +0200, Gwenole Beauchesne wrote:
> I uploaded the JIT-5d version which disables JIT_DEBUG

Ah yes, it compiles now.

It seems somewhat unstable, though. If I set the CPU type to anything other
than 68040, all I get is a black window. And even with 68040, I can't get it
to complete booting MacOS (tried 7.0.1, 7.5.3 and 7.6.1, with and without
extensions). The error messages are various, ranging from "illegal instruction"/
"fpu not installed" MacOS dialog boxes to "Illegal instruction" messages from
B2 and segmentation faults.

I tried "jitcachesize" values of 128K and 512K (prefs_items.cpp/
AddPrefsDefaults() should set a reasonable default value).

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] JIT-enabled BasiliskII for Linux/i386

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

Hi,

> Hm, at the linking stage I get
> 
> /usr/lib/libbfd.so: undefined reference to `objjalloc_create'

That appears to be from libiberty, probably that my compiler (GCC
2.95.2) automagically added -liberty. Anyhow, I uploaded the JIT-5d
version which disables JIT_DEBUG (what bfd was needed for) and improves
a little some applications like GraphicConverter through the lazy
instruction cache flush method.

Bye.
-- 
Gwenolé Beauchesne

Re: [B2-devel] JIT-enabled BasiliskII for Linux/i386

[Christian B. <cb...@st...>]

Hi!

On Sat, Oct 07, 2000 at 02:08:19PM +0200, Gwenole Beauchesne wrote:
> Run the ./devconfig script in the Unix directory in order to create the
> Makefile. Then just type make and enjoy. ;-)

Hm, at the linking stage I get

/usr/lib/libbfd.so: undefined reference to `objjalloc_create'
/usr/lib/libbfd.so: undefined reference to `xstrerror'
/usr/lib/libbfd.so: undefined reference to `hex_init'
/usr/lib/libbfd.so: undefined reference to `concat'
/usr/lib/libbfd.so: undefined reference to `_objalloc_alloc'
/usr/lib/libbfd.so: undefined reference to `_hex_value'
/usr/lib/libbfd.so: undefined reference to `objalloc_free_block'
/usr/lib/libbfd.so: undefined reference to `objalloc_free'
/usr/lib/libbfd.so: undefined reference to `xexit'
collect2: ld returned 1 exit status
make: *** [BasiliskII] Error 1

This is with binutils-2.10.0.18-1.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Changes committed, please check out

[Christian B. <cb...@st...>]

Hi!

On Sat, Oct 07, 2000 at 04:16:47PM +0200, Christian Bauer wrote:
> The initial black screen? Yes, this is drawn correctly. :-)

Also, when the window gets an Expose event, one correct frame is drawn.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Changes committed, please check out

[Christian B. <cb...@st...>]

Hi!

On Mon, Sep 25, 2000 at 02:26:27AM +0200, Gwenole Beauchesne wrote:
> Hadn't there at least one frame (the first one in fact) that was fully and
> correctly drawed ?

The initial black screen? Yes, this is drawn correctly. :-)

> Oh, I got an idea. Does the display uses or not X-Shm ?

It uses Shm.

> Have you tried 8bpp DGA mode ?

This is the only mode that works. 16bpp and 8bpp/16bpp window modes all show
stripes, regardless of the display size. They sometimes also crash with a
"Segmentation fault at ..." message.

> BTW, here is another patch against the sources you now have:

This makes it revert to the former behaviour (i.e. before your first patch).

I've also tried it on a Debian 2.2 (PIII/500, Linux 2.2.17, XFree86 3.3.6)
system and there it works very nicely. I wonder whether XFree86 4.x might
be the culprit?

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

[B2-devel] JIT-enabled BasiliskII for Linux/i386

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

Hi,

I have placed a JIT-enabled version of BasiliskII at:
<http://www.multimania.com/gbeauche/basilisk2/wip/>
File: BasiliskII-JIT5.tar.gz

Run the ./devconfig script in the Unix directory in order to create the
Makefile. Then just type make and enjoy. ;-)

I don't know when I will commit in the main B2 source tree since I am
rather busy those days and it might still be bug-friendly. Some other
optimizations are still possible and I will also have to sync with
Bernie's bleeding edge patches from his website.

Bye.
-- 
Gwenolé Beauchesne

[B2-devel] 24 bpp video bug

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

Hi,

I will commit a patch for 32 bpp displays and VOSF shortly. As for
purely 24 bpp displays, we should not assume 4 bytes per pixel.
Actually, with my Xserver for an i740-based card, that's really 3 bytes
per pixel. This problem occurs in any case (with or without VOSF), so
it's not my fault ;-)

BTW, Christian, I still can't reproduce your bug. I will try again at a
later point with an XFree86 4 server as I have just received Debian 2.2
and FreeBSD 4.1 ;-)... though they only include an old 3.3.X version.

Bye.
-- 
Gwenolé Beauchesne

Re: [B2-devel] Changes committed, please check out

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

Hi!

> This rather makes it worse (see attachment).

I committed a change involving a cleaning up of the Expose event
handling code. Maybe could have it corrupted the dirtyPages structure ?
Hmm, I don't think so but who knows...

-- 
Gwenolé Beauchesne

[B2-devel] mon V3.0

[Christian B. <cb...@st...>]

Hi!

In the CVS, you will find a new version of mon (V3.0) with these enhancements:
 - the 680x0 and 80x86 disassemblers are replaced with the ones from GNU
   binutils 2.9.1 which means that they are now complete, including FPU and
   MMU opcodes
 - in addition to displaying symbolic names for the MacOS A-Traps, the 680x0
   disassembler now also displays symbolic names for low memory globals; both
   features are enabled by the "-m" option in the stand-alone mon (when mon
   is called from B2, they are of course always enabled)

The B2 source has been updated to work with mon V3.0.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Changes committed, please check out

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

Hi,

> On Sun, Sep 24, 2000 at 07:21:43PM +0200, Gwenole Beauchesne wrote:
> > Here is a patch that disables it.
> 
> This rather makes it worse (see attachment).

Arrgl :-/

I now really suspect the problem to be the information contained in the
mainBuffer structure. Hadn't there at least one frame (the first one in
fact) that was fully and correctly drawed ?

Oh, I got an idea. Does the display uses or not X-Shm ? All my tests in
windowed mode were carried out with Shm. One difference I see between
the_buffer_copy from Shm mode or from no-Shm mode is that in one case
width is used to create an XImage, and in the other case, aligned_width
is used. Another difference is that the bitmap_pad in the latter case
(given to XCreateImage) is 32 whereas aligned_width is aligned on
16-byte boundaries (XShmCreateImage).

By the nature of the blit functions, it is important to have the same
line width between the "host" buffer, the one created by a call to
XShmCreateImage() or XCreateImage(), and the temporary frame buffers.
Actually, I think they are identical... at least in X-Shm mode.

I also see a potential bug, in init_window() and direct or real
addressing mode, VideoMonitor.mac_frame_base is initted to the_buffer.
In fact, the alignment of the_buffer on page boundary carried out in
VideoInit(), should be done when the_buffer is assigned to
VideoMonitor.mac_frame_base. I don't think this is the bug we are
currently facing to, however. Otherwise, mprotect() would gently have
segfaulted if the address wasn't aligned on page boundary.

Have you tried 8bpp DGA mode ? This is bound to work since this is the
only mode for a little endian system where VOSF is not involved. I would
be really surprised if it still draws weird things...

BTW, here is another patch against the sources you now have:
It updates the XImage buffer line per line. Please tell me it works now
;-)

<--- begin patch 2 --->
--- BasiliskII.orig/src/Unix/video_vosf.h       Mon Sep 25 02:03:46 2000
+++ BasiliskII/src/Unix/video_vosf.h    Mon Sep 25 02:12:02 2000
@@ -333,10 +333,16 @@
                mprotect((caddr_t)(mainBuffer.memStart + offset),
length, PROT_READ);
                
 #if 1
-               do_update_framebuffer(the_host_buffer + offset,
the_buffer + offset, length);
-               
                const int y1 = mainBuffer.pageInfo[first_page].top;
                const int y2 = mainBuffer.pageInfo[page - 1].bottom;
+               
+               for (int i = y1; i <= y2; i++) {
+                       do_update_framebuffer(
+                               the_host_buffer + i *
img->bytes_per_line,
+                               the_buffer + i *
VideoMonitor.bytes_per_row,
+                               VideoMonitor.bytes_per_row );
+               }
+               
                const int width = VideoMonitor.x;
                const int height = y2 - y1 + 1;
                if (have_shm)
<--- end patch 2 --->

Bye.
-- 
Gwenolé Beauchesne

Re: [B2-devel] Changes committed, please check out

[Christian B. <cb...@st...>]

Hi!

On Sun, Sep 24, 2000 at 07:21:43PM +0200, Gwenole Beauchesne wrote:
> Here is a patch that disables it.

This rather makes it worse (see attachment).

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Changes committed, please check out

[Christian B. <cb...@st...>]

Hi!

On Sun, Sep 24, 2000 at 06:59:22PM +0200, Gwenole Beauchesne wrote:
> Could you please rerun your test with --enable-addressing=banks
> --enable-vosf ?

This shows the same bug.

> - What is your screen resolution ?

640x480x16

> - Which type of signal handler is used ? Extended signals (siginfo_t) or
> the hack for Linux/i386 (sigcontext) ?

The hack.

> If this is through the sigcontext hack... well, this is a hack and it
> works for me because the kenel sources (2.2.5) tell me that the cr2
> field contains the faultive address. (linux/arch/i386/mm/fault.c).

This also seems to be the case in 2.2.16.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Changes committed, please check out

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

Hi,

> Something is wrong. The (windowed) display looks very confused (see attached
> screenshot) on my machine (Linux 2.2.16 on a PII with XFree86 4.0.1). This
> is with both real and direct addressing. In banked mode, it works fine.

This could also simply be the fact that I mis-implemented the
incremental screen update method.

Here is a patch that disables it. Since I didn't put the correct
dependancies into the Makefile, you will have to touch video_x.cpp
first.

<--- begin patch --->
--- BasiliskII.orig/src/Unix/video_vosf.h       Sun Sep 24 19:08:26 2000
+++ BasiliskII/src/Unix/video_vosf.h    Sun Sep 24 19:08:33 2000
@@ -332,6 +332,18 @@
                const uint32 length = (page - first_page) <<
mainBuffer.pageBits;
                mprotect((caddr_t)(mainBuffer.memStart + offset),
length, PROT_READ);
                
+#if 1
+               do_update_framebuffer(the_host_buffer + offset,
the_buffer + offset, length);
+               
+               const int y1 = mainBuffer.pageInfo[first_page].top;
+               const int y2 = mainBuffer.pageInfo[page - 1].bottom;
+               const int width = VideoMonitor.x;
+               const int height = y2 - y1 + 1;
+               if (have_shm)
+                       XShmPutImage(x_display, the_win, the_gc, img, 0,
y1, 0, y1, width, height, 0);
+               else
+                       XPutImage(x_display, the_win, the_gc, img, 0,
y1, 0, y1, width, height);
+#else
                // There is at least one line to update
                const int y1 = mainBuffer.pageInfo[first_page].top;
                const int y2 = mainBuffer.pageInfo[page - 1].bottom;
@@ -383,6 +395,7 @@
                        XShmPutImage(x_display, the_win, the_gc, img,
x1, y1, x1, y1, width, height, 0);
                else
                        XPutImage(x_display, the_win, the_gc, img, x1,
y1, x1, y1, width, height);
+#endif
        }
 }

<--- end patch -->

Bye.
-- 
Gwenolé Beauchesne

Re: [B2-devel] Changes committed, please check out

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

Hi,

> Something is wrong. The (windowed) display looks very confused (see attached
> screenshot) on my machine (Linux 2.2.16 on a PII with XFree86 4.0.1). This
> is with both real and direct addressing. In banked mode, it works fine.

VOSF is disabled by default unless direct or real addressing mode is
enabled. Could you please rerun your test with --enable-addressing=banks
--enable-vosf ? I think you will get the same result, even in DGA mode.
If this was a bug with the direct or real memory access routines, MacOS
wouldn't boot I think.

Now that you still get strange screen updates, there are several
options:

- What is your screen resolution ? It seems that your page size is an
exact multiple of bytes_per_row. That's not a problem but this explains
why complete lines are missing or are not updated in time, instead of
several lines plus a portion of the last one from the set.

I will guess 640x480 in 8bpp mode according to the information I got
from the image. It's clear that 4096 is not an exact multiple of 640 and
I too use a 640x480 window and I tried every screen depth except 1 bpp
and 24 bpp.

- I probably miscalculated the offsets (video_x.cpp/VideoInitBuffer) in
the mainBuffer structure though I am pretty sure it is correct to take
VideoMonitor.bytes_per_row which turns out to be img->bytes_per_pixel
for a windowed display. 

- Which type of signal handler is used ? Extended signals (siginfo_t) or
the hack for Linux/i386 (sigcontext) ? I heard that some early versions
of Linux kernels with extended signals were boguous and didn't set up
si_addr correctly... Hmm, that's a too easy answer ;-)

If this is through the sigcontext hack... well, this is a hack and it
works for me because the kenel sources (2.2.5) tell me that the cr2
field contains the faultive address. (linux/arch/i386/mm/fault.c).

Bye.
-- 
Gwenolé Beauchesne

Re: [B2-devel] Changes committed, please check out

[Christian B. <cb...@st...>]

Hi!

On Fri, Sep 22, 2000 at 07:53:23PM +0200, Gwenole Beauchesne wrote:
> As for real addressing mode, I stepped down so direct addressing is now
> the default addressing mode. To enable real addressing, please use the
> --enable-addressing=real configure option.

Something is wrong. The (windowed) display looks very confused (see attached
screenshot) on my machine (Linux 2.2.16 on a PII with XFree86 4.0.1). This
is with both real and direct addressing. In banked mode, it works fine.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] Patches for Real Addressing

[Christian B. <cb...@st...>]

Hi!

On Thu, Sep 21, 2000 at 12:07:40PM +0200, Gwenole Beauchesne wrote:
> I determined that the unfriendly code starts at ROMBase + 0xdb9c.

Some internal Memory Manager code...

> Bit 0 of the byte located at 0x1efc (what is it ?) is always tested.

This bit specifies whether the MM is in 32 or 24 bit mode.

> for some reason, at the end of the Speedometer Graphics test, the branch
> with the stripping by AND'ing with Lo3Bytes is taken!

Probably a Speedometer bug. It shouldn't be possible/necessary to switch
to 24 bit addressing under B2.

> 0x48e7, 0x1c20, // movem.l      d3-d5/a2,-(a7)
> 0x382e, 0x0008, // move.w       $0008(a6), d4
> 0x3a2e, 0x000a, // move.w       $000A(a6),d5
> 0x554f,         // subq         #$2,a7
> 0x3eb8, 0x028e, // move.w       ROM85,(a7)

Looks like it should be "move.w #ROM85,(a7)" here.

> 0x301f,         // move.w       (a7)+,d0
> 0x48c0,         // ext.l        d0
> 0x2440,         // movea.l      d0,a2
> 0x2040,         // movea.l      d0,a0
> 0x3010,         // move.w       (a0),d0
> 0x0c40, 0x3fff, // cmpi.w       #$3fff,d0
> 0x6316          // bls.s        #$00000016

Very ugly code, BTW. Seems that Apple didn't have the money for a decent
C compiler...

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] New UAE JIT Compiler

[Christian B. <cb...@st...>]

Hi!

On Wed, Sep 20, 2000 at 04:09:43PM +0200, Gwenole Beauchesne wrote:
> The only thing I haven't enabled in regards to Real Addressing on the
> AmigaOS, is the patch to disable overwriting of SysBase. What is it ?

AmigaOS stores a pointer to ExecBase at address 4 (the only absolute address
used in AmigaOS) which must not be overwritten by MacOS.

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

Re: [B2-devel] MOVE16 (Ax)+,(Ay)+

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

Hi,

> we should probably do:
>  if(srcreg != dstreg) m68k_areg(regs, srcreg) += 16;\r\n");
>  m68k_areg(regs, dstreg) += 16;\r\n");

OK, I added your patch plus other MOVE16 instructions in the table68k.
For that purpose, I added "Al" meaning absolute long. I also enhanced
the table68k for better (I hope) flag usage information and control flow
information (an extra field).

Some optimizations can still be made for MOVE16 instructions by using
do_put/do_get mem functions instead of put/get functions and thus
avoiding the double byteswapping of the data. But as we are not in a
critical point yet, I left those as is ;-)

The MOVE16 instructions in the new table68k look like:
1111 0110 0010 0rrr:40:-----:-----:--:12: MOVE16   ArP,ARP
1111 0110 00ss sSSS:40:-----:-----:--:12: MOVE16   s[Dreg-Aipi],Al
1111 0110 00dd dDDD:40:-----:-----:--:12: MOVE16   Al,d[Areg-Aipi]
1111 0110 00ss sSSS:40:-----:-----:--:12: MOVE16   s[Aind],Al
1111 0110 00dd dDDD:40:-----:-----:--:12: MOVE16   Al,d[Aipi-Aind]

% EmulOp instructions
0111 0001 0000 0000:00:-----:-----:-R:00: EMULOP_RETURN
0111 0001 EEEE EEEE:00:-----:-----:--:10: EMULOP   #E

Since, I also temporarily disabled ARM, M68K, SPARC optimizations, I
won't commit before tommorrow night. I deactivated those because
optimized flag handling are now used under a common interface. i.e.
optflag_test_*, optflag_add_*, as in the latest UAE sources.

Bye.
-- 
Gwenolé Beauchesne