basilisk-devel — Basilisk II development-related discussion

[B2-devel] CVS web interface available

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

Hi!

A web interface to the B2 (and others) CVS is now available on
  http://down.physik.uni-mainz.de/cgi-bin/cvsweb.cgi

Among other features, it provides a really nice way to view the differences
between file revisions.

Also, I've upgraded the version of CVS running on the server to 1.10.8.

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 Sun, Sep 03, 2000 at 11:16:49PM +0200, Gwenole Beauchesne wrote:
> > 1. Ability to directly access the Mac address space
> 
> Implemented. And indeed, what a nice piece of improvement: near twice
> the speed!

Cool!

> 4. Reversed Address Space
> [...]
> Note however that I didn't checked all the patches for "correctness"
> yet, especially audio that makes strange sounds.

It may not be obvious, but part of the intention behind the Mac2Host_memcpy()
etc. functions in cpu_emulation.h was to allow for a reversed address space.
It's not used consequently in all modules, however.

> I was hinted that a real m68k does not handle unaligned access, does it ?

Starting with the 68020, all 680x0 can access any data at any alignment
(except for the 68060 which needs operating system support under certain
circumstances).

> 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.

Yes, that's because the WriteMac*() functions may not yet be operational
at PatchROM() time.

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 Sun, Sep 03, 2000 at 01:26:06PM +0200, Gwenole Beauchesne wrote:
> (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 think the complete part in uae_cpu/basilisk_glue.cpp, lines 59..82
(#if REAL_ADDRESSING .. #endif) could be moved into main.cpp/InitAll(),
after the call to CheckROM() has been made.

> (b) In order to get a chance to mmap() the address space as
> above-mentioned, MacRAM would not get allocated before VideoInit() is
> executed.

This is harder. I placed VideoInit() at the latest possible point in the
initialization order because it may switch to a screen mode where it's
no longer possible to put up dialog boxes for error messages from modules
that are initialized earlier.

> (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.

But the whole point of DGA mode is to avoid a temporary frame buffer...

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

I'm using a similar method to access the CPU registers in the native
NetBSD/m68k version. Unfortunately, NetBSD doesn't seem to support siginfo_t.

> TC flush will occur when:
> - Code is created and executed from Execute68k(), Execute68kTrap()
> - FlushCodeCache() is called
> - A-Traps: FlushCodeCacheRange, FlushInstructionCache
> - BlockMove()

Why is this not simply done every time a MOVEC *,CACR or CPUSH is executed
to clear the emulated 680x0's caches?

> 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.

If you are convinced that it will still work on non-x86 machines and other
operating systems (including NetBSD/m68k, where it runs without CPU emulation),
you can check it in.

> Actually, I never used CVS

There's a nice tutorial at
http://www-classic.be.com/aboutbe/benewsletter/volume_III/Issue40.html#Insight

> Should I make it the default one when an i386 cpu is detected ?

If it's an improvement, then yes.

Bye,
Christian

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

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

[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

Re: [B2-devel] Fixes for the generic FPU emulation core

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

Hi,

> I just grepped all the compiler include files with "float80" and
> "quadruple" -- no [relevant] hits. But it's always possible that
> I'm missing something.

The compiler may handle tokens starting with "__" internally. I am sorry
but I don't have VC++ documentation. BTW, CodeWarrior only has 64-bit
long doubles as well.

> >I think that an implementation claiming IEEE-754 compliance would have
> >adequate float and double type representations. long doubles could also
> >be 128-bit long.
> 
> Yes ... strictly speaking it's compliant, but adequate? Not for
> our purposes at least :) 

Reading the C standard again, I came up with <fenv.h> which gives access
to the floating-point environment. Something to explore further. i.e.
check if the implementation provides fenv_t, fexcept_t, FE_INEXACT, ...

Problem: that doesn't appear to be part of the C++ standard but using C
from C++ is not a problem ;-)

Another problem: all C implementations may not provide those features
yet. CodeWarrior appears to support that. GCC and an old glibc 2.0.x
doesn't but it seems that glibc 2.1.x will (?).

-- 
Gwenolé Beauchesne

Re: [B2-devel] Fixes for the generic FPU emulation core

[Lauri P. <lpe...@ni...>]

On Sat, 19 Aug 2000 04:44:16 +0300, you wrote:

>if( value < -32768.0 || value > 32767.0 ) {
>	... set the INEXACT flag
>} else {
>	put_word(ad, (uae_s16) value);
>}

Second try:

if( value < -32768.0 || value > 32767.0 ) {
	// Overflow:
	... set the ACCR_IOP flag
} else {
	put_word(ad, (uae_s16) value);
	if( (double)(uae_s16)value != value ) {
		// Inexact
		... set the INEXACT flag
	}
}

Lauri

Re: [B2-devel] Fixes for the generic FPU emulation core

[Lauri P. <lpe...@ni...>]

On Wed, 16 Aug 2000 14:52:08 +0200 (CEST), Christian wrote:

>It has been hinted to me that the problem is the loading of unnormalized
>80-bit floats which is supported by Motorola FPUs but not Intel ones.

Another important thing is the accrued exception byte.
It does not contribute to the scroll bars problem, but the
library math functions. I had a tester code in CodeWarrior,
[floating point=Library, 8-Byte doubles]:

int exponent;
double d4 = frexp(3.5,&exponent); // Should return: 0.875, 2

There is code like this in Pack5 resource "Elems68k"
(the comments are from a test run of the C code above):

FMOVE.X    (A7)+,FP3     ;FP3 = 0.8074
MOVEQ      #$00,D4       ;D4 = 0
FMOVE      FPSR,D1       ;D1 = 0 (0.8074 status flags)
MOVE.L     #$0F000000,D2 ;D2 = 0x0F000000 (condition mask)
MOVE.L     D1,D3         ;D3 = 0
AND.L      D2,D3         ;D3 = 0.8074 condition code byte
LSL.L      #$5,D3        ;D3 MSBs = 0 (Z,I,NAN)
AND.L      D2,D0         ;D0 = 0 (entry condition code byte)
LSL.L      #$5,D0        ;D3 MSBs = 0 (Z,I,NAN of entry)
BNE.S      Anon6+$0010   ;No jump
BCS.S      Anon6+$0010   ;No jump, C would be set on N flag
TST.L      D3            ;D3 0
BNE.S      Anon6+$0010   ;No jump
FMOVE.W    FP3,D2        ;D2 = 1??
FMOVE      FPSR,D1       ;D1 = 0
BCLR       #$07,D1       
SNE        D2            ;Set if not equal; D2=0
FMOVE      D1,FPSR       ;D1 = 0
BTST       #$03,D1       ;Test bit 3, INEXACT
SNE        D0            ;D0 = 0 (is not INEXACT)

So the line "FMOVE.W    FP3,D2" should set the ACCR_INEX flag.

In the original fpu code, this means that in put_fp_value()
the put_word() call should set the INEXACT flag if the
"value" overflows.

In the Windows port I'm doing:

	put_word(ad, extended_to_signed_16(value));

where extended_to_signed_16() (assembly) sets the exception
flags if appropriate. In a non-assembly version, this
could be replaced by (untested):

// strictly speaking, rounding modes should be honored too :)
// Say, 32767.5 may ot may not cause the flag.
if( value < -32768.0 || value > 32767.0 ) {
	... set the INEXACT flag
} else {
	put_word(ad, (uae_s16) value);
}

For me it was a surprise that the floating point exceptions
are disabled but the ROM was still using the exception flags.
But why not.

Lauri

Re: [B2-devel] Fixes for the generic FPU emulation core

[Lauri P. <lpe...@ni...>]

On Thu, 17 Aug 2000 00:48:03 +0200, Gwenolé wrote:

>BTW, I am surprised MSVC++ doesn't provide its own long double type
>(80-bit long). Really nothing like __float80, __quadruple ?

Not that I know of. There were 80 bits long doubles in the old
16-bit version of the compiler, but for some reason this support
was dropped.

I just grepped all the compiler include files with "float80" and
"quadruple" -- no [relevant] hits. But it's always possible that
I'm missing something.

>I think that an implementation claiming IEEE-754 compliance would have
>adequate float and double type representations. long doubles could also
>be 128-bit long.

Yes ... strictly speaking it's compliant, but adequate? Not for
our purposes at least :) 

Lauri

Re: [B2-devel] Fixes for the generic FPU emulation core

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

Hi!

On Thu, 17 Aug 2000, Gwenole Beauchesne wrote:
> PPS: Christian, would it be possible to tell the mailing-list manager
> (or whatsoever) to automatically add a Reply-To: <this_list> field ?

This should be done now. I also like it better that way.

Bye,
Christian

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

Re: [B2-devel] Fixes for the generic FPU emulation core

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

Hi,

> Yes, the CVS sources still have that problem. I applied Lauri's changes to
> uae_cpu/fpp.cpp, but nothing more.

I have just tried to remove the assembly type conversion functions,
especially (only in fact) to_single() and restore the original one in C
from uae_cpu/fpp.cpp. Scrollbars stopped to work again.

The problem is that there is no check for NaN, Inf and Zero. So, if the
exponent is set to the maximum (possibly a NaN of Inf), doing exponent +
FP_DOUBLE(or EXTENDED)_EXP_BIAS - FP_SINGLE_EXP_BIAS without extra tests
is not correct.

I fixed it by assigning each part of the floating-point value through a
fp_single_shape type (32-bit float).

Maybe something like hereunder mentioned would work as well:

function::to_single()

union {
  fp_single as_single;
  uae_u32   as_uint32;
} fp_loader;

fp_loader.as_uint32 = byteswap(value);
return (fp_extended)fp_loader.as_single;

Hmm, actually, I tried to apply it on the CVS sources, this didn't work.
But it does with my current changes in fpu_ieee.cpp. i.e. only
to_single() is reimplemented in C++.

BTW, I also got inspired from binutils-2.x.x/libiberty/floatformat.c.
Unfortunately, the diffs I tried did not work...

PS: I reuploaded the file fpu_ieee.cpp on my website.

PPS: Christian, would it be possible to tell the mailing-list manager
(or whatsoever) to automatically add a Reply-To: <this_list> field ?

Thanks.
-- 
Gwenolé Beauchesne

Re: [B2-devel] Fixes for the generic FPU emulation core

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

Hi Lauri,

> It's really great if you can do everything without assembly, but
> some compilers (for example mine) have a fake long double, it's
> the same as double.

Yes, actually the standard just says that "the type double provides at
least as much precision as float, and the type long double provides at
least as much precision as double." ;-)

BTW, I am surprised MSVC++ doesn't provide its own long double type
(80-bit long). Really nothing like __float80, __quadruple ?

I think that an implementation claiming IEEE-754 compliance would have
adequate float and double type representations. long doubles could also
be 128-bit long.

I wonder if some checks could be done at ./configure time...
An alternative is still the implementation with hand-coded float types
as with the FPE from NetBSD/m68k. That's a lot of work. I would prefer
working on a faster m68k core or a PPC core ;-)))

-- 
Gwenolé Beauchesne

Re: [B2-devel] Fixes for the generic FPU emulation core

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

Hi!

On Tue, 15 Aug 2000, Gwenole Beauchesne wrote:
> Scrollbars now work with the generic FPU core. The problem looks like
> what I was suspecting: floating-point precision.

It has been hinted to me that the problem is the loading of unnormalized
80-bit floats which is supported by Motorola FPUs but not Intel ones.

> no differences and scrollbars don't work with the freshly compiled CVS
> sources, do they ?

Yes, the CVS sources still have that problem. I applied Lauri's changes to
uae_cpu/fpp.cpp, but nothing more.

Bye,
Christian

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

Re: [B2-devel] Fixes for the generic FPU emulation core

[Lauri P. <lpe...@ni...>]

Hi Gwenolé,

It seems that I have not updated the uae\fpp.cpp file
with some [portable] changes. At least the to_exten()
re-normalization code that is found in uae_windows\fpu.cpp
has some subtle but important fixes.

Just in case you didn't notice, I have not looked
into your new code yet.

Lauri

Re: [B2-devel] Fixes for the generic FPU emulation core

[Lauri P. <lpe...@ni...>]

>The standard does not (I'd guess it can't) specify what is the
>true accuracy of the long double.

Oops, sorry -- that's of course exactly what you said before.
I should not write in a hurry.

Lauri

Re: [B2-devel] Fixes for the generic FPU emulation core

[Lauri P. <lpe...@ni...>]

On Tue, 15 Aug 2000 01:22:03 +0200, you wrote:

Hi Gwenolé,

>- The long double type is part of the C++ standard. Any compliant
>compiler should know about it. The problem is that I make heavy
>assumptions about its data representation: IEEE-854. i.e. a 96-bit long
>double, what the C++ standard does not guarantee.

It's really great if you can do everything without assembly, but
some compilers (for example mine) have a fake long double, it's
the same as double. The standard does not (I'd guess it can't) specify
what is the true accuracy of the long double.

Lauri

[B2-devel] Fixes for the generic FPU emulation core

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

Hi,

Scrollbars now work with the generic FPU core. The problem looks like
what I was suspecting: floating-point precision. I am using long doubles
if and only if they are 96-bit long (detected by the configure script).

## Reasons why I think it was a precision-related problem

- I took the original fpp.cpp from BasiliskII 13/07/2000 and made
necessary changes to support uae_f96. Note however that type conversion
functions like to_single(), from_exten(), used X86 assembly.

At this time, scrollbars were still not working.

- I then applied Lauri's changes from his fpp.cpp (not fpu.cpp from the
Windows directory). It worked.

So what ?

-> Making diffs from Lauri's fpp.cpp and from the one in the CVS shows
no differences and scrollbars don't work with the freshly compiled CVS
sources, do they ?

-> I applied all changes from Lauri's fpp.cpp but enhanced them with
long doubles. Scrollbars work.

## Last notes.

- The long double type is part of the C++ standard. Any compliant
compiler should know about it. The problem is that I make heavy
assumptions about its data representation: IEEE-854. i.e. a 96-bit long
double, what the C++ standard does not guarantee.

- IMHO, #include <cmath> (not <math.h>) is mandatory because it provides
long double overloaded functions. The recent C99 standard however, now
supports long doubles (if available) and functions taking long doubles
in parameters are suffixed with 'l'. e.g. atanl().

- Testing for NaN, Infinities and such things could be done with
standard C (C99) functions, if available. e.g. isnan(), isinf().

<http://www.multimania.com/gbeauche/basilisk2/wip/>
File: fpu_ieee.cpp

## Todo

- beautifying
- generic type conversions instead of i386 assembly
- update exception and accrued exception bytes
(probably do a megamix from Linux/m68k math-emu code)

-- 
Gwenolé Beauchesne

Re: [B2-devel] [ANN] Lauri's FPE ported to other X86 systems

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

Hi!

On Sun, 13 Aug 2000, Gwenole Beauchesne wrote:
> I accomodated Lauri's FPU emulation to meet GCC's inline assembly
> syntax.

Way to go!

> Quick diffs:
> - configure.in: --enable-new-fpu-core, defaults to yes

Maybe it should only default to "yes" on i386 systems...

> PS: is it me or there was no traffic on this list since its creation ?
> ;-)

"First post" :-)

Bye,
Christian

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

[B2-devel] [ANN] Lauri's FPE ported to other X86 systems

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

Hi,

I accomodated Lauri's FPU emulation to meet GCC's inline assembly
syntax. The way I used GCC's extended asm features for the X86 FPU is
probably not the Right Way. Please report me any error.

BTW, I only tested it with Speedometer 3.X and 4.X and Apple Personal
Diagnostics. Scrollbars work as well.

A patch over BasiliskII v0.8-13/07/2000 sources is available at:
<http://www.multimania.com/gbeauche/wip/basilisk2/wip/>
File: patch_fpu_x86.gz (36 KB)

Quick installation notes:
gzip -dc patch_fpu_x86.gz | patch -p0

Quick diffs:
- configure.in: --enable-new-fpu-core, defaults to yes
- uae_cpu/fpu_x86.{h,cpp}

Todo:
- propagate the diffs to the main sources
-> looks like it will need real32, real64 and real96 types...

PS: is it me or there was no traffic on this list since its creation ?
;-)

-- 
Gwenolé Beauchesne