basilisk-devel — Basilisk II development-related discussion

RE: [B2-devel] SheepShaver sound

[Tomasz J. <to...@je...>]

> On Thu, 3 Jun 2004, Tomasz Jerzykowski wrote:
> 
> > Is it true tha sound n SheepShaver can be enabled only if you are 
> > using OldWorld ROM file? It doesn't work with NewWorld one on my PC,
> 
> Actually, it does. I found it out by luck. In the sound 
> control panel, can't you select the output device (even if 
> it's already selected)? I don't know what exactly I did 
> though. I could not revert to the old non-functioning state.
> 

I can't select any sound device in the control panel because there is no one
listed - the box is empty.

> > I have also ran a game (www.spidweb.com) and it complains 
> about lack 
> > of sound output (beside this it works fine although not very fast).
> 
> which one? any free downloadable demo?
> 

Blades of Avernum (downloadable demo). Requires installing CarbonLib from
Apple site.

Re: [B2-devel] SheepShaver sound

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

On Thu, 3 Jun 2004, Tomasz Jerzykowski wrote:

> Is it true tha sound n SheepShaver can be enabled only if you are using
> OldWorld ROM file? It doesn't work with NewWorld one on my PC,

Actually, it does. I found it out by luck. In the sound control panel, 
can't you select the output device (even if it's already selected)? I 
don't know what exactly I did though. I could not revert to the old 
non-functioning state.

> I have also ran a game (www.spidweb.com) and it complains about lack of
> sound output (beside this it works fine although not very fast).

which one? any free downloadable demo?

[B2-devel] SheepShaver sound

[Tomasz J. <to...@je...>]

Is it true tha sound n SheepShaver can be enabled only if you are using
OldWorld ROM file? It doesn't work with NewWorld one on my PC, even though
host OS supports sound just fine. I cannot test it on another ROM for
obvious reasons - not having such a file.
There are no errors concerning inability of opening of /dev/dsp or anything
during startup, but still, there is no audio device in MacOS 8.6 control
panel. I have also ran a game (www.spidweb.com) and it complains about lack
of sound output (beside this it works fine although not very fast).


Jerzu

Re: [B2-devel] Native QuickDraw acceleration

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

Hi,

> Definitely. At least there is a supported interface for the 
> acceleration.
> The routines in ShapeShifter were based on complete guesswork (but the
> NQD hooks are not entirely different from it).

Would it be possible to get that guesswork into B2 too? Actually, I 
would like to use Apple's DR emulator there too (powerrom_cpu) and 
since video graphics is low on MacOS X (at least with X11 and VOSF 
tricks), that sort of NQD could help in determining dirty pages of the 
frame buffer.

On MacOS X proper, couldn't we forward CopyBits() et al. to Carbon 
equivalent either? That would suppose the real MacOS X version is used 
as I don't know how Carbon graphics and X11 could cooperate. I believe 
it would be cool to have a super fast Basilisk II within MacOS X.

Bye,
Gwenole.

Re: [B2-devel] New SheepShaver troubles continued...

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

mercredi 2 juin 2004, =E0 08:40  pm, Tomasz Jerzykowski a =E9crit :

> Let me follow my old thread. This is how SheepShaver CVS doesn't=20
> compile when HAVE_TEST_AND_SET is commented out (tested serveral days=20=

> ago):

Yes, I fixed that this afternoon, as the new spinlock code did not help=20=

so I disabled it and now use pthreads by default on x86 and amd64.=20
Otherwise, I indeed get some occasional hangs...

Re: [B2-devel] New SheepShaver troubles continued...

[Tomasz J. <to...@je...>]

Tomasz Jerzykowski wrote:
> Gwenole Beauchesne wrote:
> 
>>> I haven't measured how much faster is the newest version, but it still
>>> suffers from some strange 'stops'.
>>
>>
>>
>> I have noticed that on AMD64 with gcc 3.3.2 too when experimenting 
>> with the asm based locking code. I will probably try other 
>> alternatives. In Unix/sysdeps.h, could you try to disable 
>> HAVE_TEST_AND_SET for i386 and rebuild at least main_unix.cpp and 
>> video_x.cpp?
>>
> 
> It did the trick. Now SheepShaver rums smoothly and reasonably fast, 
> especially when color depth of the host display is set to 16 bit (32 bit 
> is somehow slower). This trick doesn't work on the latest CVS version 
> (compilation fails after modification).
> 

Let me follow my old thread. This is how SheepShaver CVS doesn't compile 
when HAVE_TEST_AND_SET is commented out (tested serveral days ago):

=========================
c++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\" -g
-O2  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/X11R6/include
-c ../kpx_cpu/src/cpu/jit/cxxdemangle.cpp -o obj/cxxdemangle.o
c++ -o dyngen   obj/dyngen.o obj/cxxdemangle.o
./dyngen -o basic-dyngen-ops.hpp obj/basic-dyngen-ops.o
c++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\" -g
-O2  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/X11R6/include
-c ../kpx_cpu/src/cpu/jit/basic-dyngen.cpp -o obj/basic-dyngen.o
c++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\" -g
-O2  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/X11R6/include  -fomit-frame-pointer
-mpreferred-stack-boundary=2 -falign-functions=0 -mmmx -msse -msse2
-finline-limit=10000 -fno-reorder-blocks -fno-optimize-sibling-calls
-c ../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp -o obj/ppc-dyngen-ops.o
In file included from ../kpx_cpu/src/cpu/ppc/ppc-registers.hpp:151,
                  from ../kpx_cpu/src/cpu/ppc/ppc-cpu.hpp:31,
                  from ../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:25:
../kpx_cpu/src/cpu/spcflags.hpp:39: error: 'spinlock_t' is used as a 
type, but
    is not defined as a type.
../kpx_cpu/src/cpu/spcflags.hpp: In constructor `
    basic_spcflags::basic_spcflags()':
../kpx_cpu/src/cpu/spcflags.hpp:44: error: class `basic_spcflags' does not
have
    any field named `lock'
../kpx_cpu/src/cpu/spcflags.hpp:44: error: `SPIN_LOCK_UNLOCKED' undeclared
    (first use this function)
../kpx_cpu/src/cpu/spcflags.hpp:44: error: (Each undeclared identifier is
    reported only once for each function it appears in.)
../kpx_cpu/src/cpu/spcflags.hpp: In member function `void
    basic_spcflags::init(unsigned int)':
../kpx_cpu/src/cpu/spcflags.hpp:54: error: `lock' undeclared (first use this
    function)
../kpx_cpu/src/cpu/spcflags.hpp:54: error: `spin_lock' undeclared (first use
    this function)
../kpx_cpu/src/cpu/spcflags.hpp:54: error: `spin_unlock' undeclared 
(first use
    this function)
../kpx_cpu/src/cpu/spcflags.hpp: In member function `void
    basic_spcflags::set(unsigned int)':
../kpx_cpu/src/cpu/spcflags.hpp:60: error: `spin_lock' undeclared (first use
    this function)
../kpx_cpu/src/cpu/spcflags.hpp:60: error: `spin_unlock' undeclared 
(first use
    this function)
../kpx_cpu/src/cpu/spcflags.hpp: In member function `void
    basic_spcflags::clear(unsigned int)':
../kpx_cpu/src/cpu/spcflags.hpp:63: error: `spin_lock' undeclared (first use
    this function)
../kpx_cpu/src/cpu/spcflags.hpp:63: error: `spin_unlock' undeclared 
(first use
    this function)
make: *** [obj/ppc-dyngen-ops.o] Error 1
=========================

Jerzu

[B2-devel] Activating Apple DR emulator

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

Hi,

I fixed patchery around Apple's DR emulator for NewWorld ROMs this 
morning. In native mode, I indeed get a nice speedup on 68k code. 
However, there doesn't seem to be any benefit for Execute68k(), at 
least as it could be seen through Disk performance in Speedometer 4 
testing. Besides, in emulated PPC mode, it appears the DR emulator has 
no chance to translate code, in other words, I don't see any benefit.

Last but not least, I noticed MacOS occasionally (really hard to 
reproduce) crashes within DR code. I don't know why but I could only 
see that 68k PC fetched from stack is total garbage. It could be that 
(i) one patch is still wrong, or (ii) stack got corrupted through 
multiple nested Execute68k()?

In summary, if you are interested to test it, cvs update -d and switch 
the #if in emul_op.cpp accordingly. For now, the 68k DR emulator is 
disabled.

PS: Could someone check I did not break BeOS/PPC compilation?

Bye,
Gwenole.

Re: [B2-devel] New SheepShaver troubles continued...

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

Hi,

> I will play with the crashes with -O2 later (following your advices).

If you used recent CVS code, I have committed this morning two=20
important fixes. One is related to NativeOp code generation (e.g. call=20=

to VideoVBL). The other is an incorrect block chaining to NULL. It does=20=

not seem to crash any longer randomly.

Hope this helps you too.

Bye,
Gwenol=E9.=

[B2-devel] Quake 1 works

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

Hi,

I had not noticed it yet but Quake 1 now runs (it used to crash in the=20=

past). However, games using InputSprockets currently won't work because=20=

there is no mouse event being caught. Do people have simple=20
InputSprockets sample application concerning cursor handling?

Note: I don't have CW at my current location so I would need=20
precompiled binaries first.

Thanks,
Gwenol=E9.=

Re: [B2-devel] New SheepShaver troubles continued...

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

Hi,

> It did the trick. Now SheepShaver rums smoothly and reasonably fast,=20=

> especially when color depth of the host display is set to 16 bit (32=20=

> bit is somehow slower).

This is understandable because we could need to do color conversion as=20=

well. The 16-bit version can be processed faster than the 32-bit=20
version because simply more pixels can be processed at a time.

However, since you indicate a noticeable difference, it then may be=20
interesting to write MMX/SSE blitters to bring 32-bit blitting to=20
current 16-bit blitting speeds.

> This trick doesn't work on the latest CVS version (compilation fails=20=

> after modification).

Please post the error message + date of CVS version. I have committed a=20=

hopefully fixed version of testandset(), aka the one from LinuxThreads=20=

so it should really work.

However, please only grab the sysdeps.h (testandset) change as the rest=20=

could break too. Aka, I sometimes get a crash when a *lot* of ADB=20
events are coming up (e.g. mouse).

> Now if only did SheepShaver run OS-X... I wish it were, but I am aware=20=

> that it would require adding MMU support, what is a major speed=20
> bottleneck in PearPC.

Actually, I think we can get rid of address translation or at least=20
minimize it a lot, even on 32-bit systems. However, we will still need=20=

memory protection, but this can be trivially achieved in a fast way=20
with a JIT compiler. An interpreter would require explicit recovery=20
points.

> Nonetheless, it's still fun to play with OS 8.6 on my PC. Speedometer=20=

> indicates that on P4 1.4 SheepShaver is faster than real PowerMac=20
> 80Mhz. Impressive.

And using an Athlon 64 or Opteron at the same speed could easily bring=20=

up to a 2x increase. That's because the current (portable) JIT1 engine=20=

makes heavy use of load/stores. The next could speed up things by at=20
least a factor of two. Imagine that the current JIT already does less=20
than 1/8 of native speed. ;-)

> I will play with the crashes with -O2 later (following your advices).

Another user reported that on the forum, setting DISABLE_DBC to 1 with=20=

the patch I sent you earlier fixed his problems. That's why I am=20
working on a more complete direct block chaining code that should fix=20
corner cases of the previous method. However, it currently breaks on=20
kpxrun test/test-powerpc, where test-powerpc is a statically linked ppc=20=

binary with the same emulator. I'd rather say it's slow and since I am=20=

an unlucky guy, it breaks after several minutes...

Bye,
Gwenol=E9.=

Re: [B2-devel] New SheepShaver troubles continued...

[Tomasz J. <to...@je...>]

Gwenole Beauchesne wrote:

>> I haven't measured how much faster is the newest version, but it still
>> suffers from some strange 'stops'.
> 
> 
> I have noticed that on AMD64 with gcc 3.3.2 too when experimenting with 
> the asm based locking code. I will probably try other alternatives. In 
> Unix/sysdeps.h, could you try to disable HAVE_TEST_AND_SET for i386 and 
> rebuild at least main_unix.cpp and video_x.cpp?
> 

It did the trick. Now SheepShaver rums smoothly and reasonably fast, 
especially when color depth of the host display is set to 16 bit (32 bit 
is somehow slower). This trick doesn't work on the latest CVS version 
(compilation fails after modification).

Now if only did SheepShaver run OS-X... I wish it were, but I am aware 
that it would require adding MMU support, what is a major speed 
bottleneck in PearPC. Nonetheless, it's still fun to play with OS 8.6 on 
my PC. Speedometer indicates that on P4 1.4 SheepShaver is faster than 
real PowerMac 80Mhz. Impressive.

I will play with the crashes with -O2 later (following your advices).

Jerzu

[B2-devel] Faster audio in emulated mode

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

Hi,

I have committed a few arrangements to make the JIT generated code 
somewhat reentrant. i.e. this means it is now possible to recursively 
generate and invoke compiled code. The reasoning was as follows:

1) NanoKernel interrupts could already run in a nested context from 
main execution loop. This is because we could run the interrupt only 
when we exited from a generated block. So, no problem for this one.

2) For nested Execute68k() compilation and invokation, that's trickier. 
Imagine we have the following scenario: ppc execution (toplevel loop) 
-> Execute68k (1) -> Execute68k (2). If Execute68k (2) were to 
invalidate the translation cache and possibly overwrite code from 
Execute68k (1) or toplevel loop return point, you are dead. The trick 
was to handle EmulOps on trampoline code that is not part of the real 
translation cache. That way, even if cache is invalidated, we could 
still run the continuation code at EmlOp return.

In summary, this is a *massive* performance improvement for 
applications that cause a lot of Execute68k(). e.g. audio related 
applications like PlayerPRO, where we end up to around 45% of time 
spent in Execute68k(). It's completely unusable without this 
optimization.

BTW, if you try PlayerPRO with current CVS code, it won't work, it 
needs a special workaround to avoid nested NanoKernel interrupt routine 
call. I still don't know why this would happen. It's not a problem in 
native mode because the whole CPU context is preserved. I could do the 
same with the emulator, but I still think this should not happen.

Bye,
Gwenole.

Re: [B2-devel] New SheepShaver troubles continued...

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

dimanche 16 mai 2004, =E0 08:42  am, Gwenole Beauchesne a =E9crit :

> Then, with the default flags (aka -O2 everywhere and in that case it=20=

> should crash again for you), please try the patch attached. And try,=20=

> in order, to disable some code generation for VMX, FPU, and ALU units.=20=

> But first try to set DISABLE_DBC to 1 so that you don't do block=20
> chaining.

And I forgot the patch.

Re: [B2-devel] New SheepShaver troubles continued...

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

Hi,

>> I am only aware of two types of miscompilation with gcc on x86:
>> 1) Don't use -mcpu=3Dpentiumpro, at least with -march=3Di586 with gcc
>> 3.3.2. You would get a hang during boot
>
> Hang of Linux or hang of the application?

Hang of the application after the happyface appeared.

> I must say that on Fedora 2
> SheepShaver sometimes hangs the OS (the newest one - the February=20
> version
> didn't). It does not happen on the other PC with Fedora 1 (this is=20
> where I
> managed to run it with -O1).

In that case please really tell me if you are running as root or not.=20
If so, this can change things wrt. threads behavior.

>>> However when I removed -O2 altogether, SheepShaver did not compile =
at
>>> all.
>>
>> Have you tried to only lower -O2 to -O1 in DYNGEN_OP_FLAGS?
>
> I can't. DYNGEN_OP_FLAGS does not contain any O's in my Makefile. See=20=

> below.

You can because DYNGEN_OP_FLAGS is used after CXXFLAGS. So, you can=20
leave -O2 in CXXFLAGS and simply add -O1 or -fno-strict-aliasing in=20
DYNGEN_OP_FLAGS so that only basic-dyngen-ops.cpp and=20
ppc-dyngen-ops.cpp are built with those.

Then, with the default flags (aka -O2 everywhere and in that case it=20
should crash again for you), please try the patch attached. And try, in=20=

order, to disable some code generation for VMX, FPU, and ALU units. But=20=

first try to set DISABLE_DBC to 1 so that you don't do block chaining.

If that still doesn't help, edit Unix/sysdeps.h to disable=20
DYNGEN_ASM_OPTS and rebuilt ppc-dyngen-ops.cpp.

Ideally, if you are patient enough to have all DISABLE_* set to 0 and=20
manually comment out case PPC_I(XXX) things, so that you can identify=20
the faulty synthetic opcode generated, that would be fine. Could you=20
make ppc-dyngen-ops.o available to me along with the exact compilation=20=

flags?

Thanks,
Gwenol=E9.=

Re: [B2-devel] New SheepShaver troubles continued...

[Tomasz J. <to...@je...>]

On Saturday 15 May 2004 22:52, Gwenole Beauchesne wrote:
> Hi,
>
> > I had to modify the generated Makefile and replace -O2 with -O1
> > everywhere.
>
> I am only aware of two types of miscompilation with gcc on x86:
> 1) Don't use -mcpu=pentiumpro, at least with -march=i586 with gcc
> 3.3.2. You would get a hang during boot

Hang of Linux or hang of the application? I must say that on Fedora 2 
SheepShaver sometimes hangs the OS (the newest one - the February version 
didn't). It does not happen on the other PC with Fedora 1 (this is where I 
managed to run it with -O1).

> 2) gcc 3.2.2 miscompiles some SSE code, but I workarounded that in the
> sources.
>
> > However when I removed -O2 altogether, SheepShaver did not compile at
> > all.
>
> Have you tried to only lower -O2 to -O1 in DYNGEN_OP_FLAGS? 

I can't. DYNGEN_OP_FLAGS does not contain any O's in my Makefile. See below.

========
DYNGEN_OP_FLAGS = -fomit-frame-pointer -mpreferred-stack-boundary=2 
-falign-functions=0 -mmmx -msse -mss
e2 -finline-limit=10000 -fno-reorder-blocks -fno-optimize-sibling-calls
========


> What about 
> adding -fno-strict-aliasing and keeping -O2? In the latter case, there
> could indeed be a bug in the code.
>

Didn't help.

> > ../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp -o obj/ppc-dyngen-ops.o
>
> *-ops.cpp files have to be compiled with optimizations. Otherwise you
> will end up with poorer performance.
>
> Do you really have a stock FSF gcc 3.3.2?

No. This is Fedora 1 GCC.

> Have you tried to upgrade to 
> 3.3.3? 

In Fedora 2 test 3 there is GCC 3.3.3 and it exhibits the same behaviour.
FC2 contains also GCC 3.4.0. The error is almost the same:

==============
g++34 -o dyngen         obj/dyngen.o obj/cxxdemangle.o
./dyngen -o basic-dyngen-ops.hpp obj/basic-dyngen-ops.o
g++34 -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I. 
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\" -g  
-I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 
-I/usr/lib/glib/include -I/usr/X11R6/include 
-c ../kpx_cpu/src/cpu/jit/basic-dyngen.cpp -o obj/basic-dyngen.o
g++34 -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I. 
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\" -g  
-I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 
-I/usr/lib/glib/include -I/usr/X11R6/include -fomit-frame-pointer 
-mpreferred-stack-boundary=2 -falign-functions=0 -mmmx -msse -msse2 
-finline-limit=10000 -fno-reorder-blocks -fno-optimize-sibling-calls 
-c ../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp -o obj/ppc-dyngen-ops.o
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In static member function `static 
void op_V2DI::set(powerpc_vr&, int, uint64)':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400:   instantiated from `static 
void do_vector_execute<OP, VX, VA, VB, VC, N>::apply() [with OP = op_and_64, 
VX = op_V2DI, VA = op_V2DI, VB = op_V2DI, VC = op_VNONE, int N = 1]'
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1437:   instantiated from `static 
void vector_execute<OP, VX, VA, VB, VC>::apply() [with OP = op_and_64, VX = 
op_V2DI, VA = op_V2DI, VB = op_V2DI, VC = op_VNONE]'
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1490:   instantiated from here
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400: error: unable to find a 
register to spill in class `GENERAL_REGS'
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400: error: this is the insn:
(insn 17 16 19 0 ../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400 (set 
(mem/s/j:DI (plus:SI (mult:SI (reg:SI 60 [ i ])
                    (const_int 8 [0x8]))
                (reg/f:SI 59 [ v ])) [0 <variable>.j S8 A64])
        (reg:DI 61 [ x ])) 58 {*movdi_2} (nil)
    (expr_list:REG_DEAD (reg:DI 61 [ x ])
        (expr_list:REG_DEAD (reg:SI 60 [ i ])
            (expr_list:REG_DEAD (reg/f:SI 59 [ v ])
                (nil)))))
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400: confused by earlier errors, 
bailing out
make: *** [obj/ppc-dyngen-ops.o] Error 1
============

> At some point, I wanted to exercise a testcase for my hang 
> problem with gcc 3.3.2, but getting a crash would be better. ;-)
>
> > I haven't measured how much faster is the newest version, but it still
> > suffers from some strange 'stops'.
>
> I have noticed that on AMD64 with gcc 3.3.2 too when experimenting with
> the asm based locking code. I will probably try other alternatives. In
> Unix/sysdeps.h, could you try to disable HAVE_TEST_AND_SET for i386 and
> rebuild at least main_unix.cpp and video_x.cpp?
>

I've noticed something noteworthy in KDE System Monitor. During such a stop 
CPU is 100% 'User' time, but during normal operation CPU is 100% 'Nice' time. 
I don't get it, but this information might be helpful. As of other hints, I 
will try them later.

> > There is also problem with configuration interface. In video modes tab
> > there is one checkbox that is not described (the 6th one). Selecting
> > only 'Windowed 800x600' result in termination of application and
> > message:
> > SheepShaver.ok: video_x.cpp:1166: bool VideoInit(): Assertion `cur_mode
> > != -1' failed.
>
> OK, I will have a look.
>
> Thanks,
> Gwenole.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] New SheepShaver troubles continued...

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

Hi,

> I had to modify the generated Makefile and replace -O2 with -O1 
> everywhere.

I am only aware of two types of miscompilation with gcc on x86:
1) Don't use -mcpu=pentiumpro, at least with -march=i586 with gcc 
3.3.2. You would get a hang during boot
2) gcc 3.2.2 miscompiles some SSE code, but I workarounded that in the 
sources.

> However when I removed -O2 altogether, SheepShaver did not compile at 
> all.

Have you tried to only lower -O2 to -O1 in DYNGEN_OP_FLAGS? What about 
adding -fno-strict-aliasing and keeping -O2? In the latter case, there 
could indeed be a bug in the code.

> ../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp -o obj/ppc-dyngen-ops.o

*-ops.cpp files have to be compiled with optimizations. Otherwise you 
will end up with poorer performance.

Do you really have a stock FSF gcc 3.3.2? Have you tried to upgrade to 
3.3.3? At some point, I wanted to exercise a testcase for my hang 
problem with gcc 3.3.2, but getting a crash would be better. ;-)

> I haven't measured how much faster is the newest version, but it still
> suffers from some strange 'stops'.

I have noticed that on AMD64 with gcc 3.3.2 too when experimenting with 
the asm based locking code. I will probably try other alternatives. In 
Unix/sysdeps.h, could you try to disable HAVE_TEST_AND_SET for i386 and 
rebuild at least main_unix.cpp and video_x.cpp?

> There is also problem with configuration interface. In video modes tab
> there is one checkbox that is not described (the 6th one). Selecting
> only 'Windowed 800x600' result in termination of application and
> message:
> SheepShaver.ok: video_x.cpp:1166: bool VideoInit(): Assertion `cur_mode
> != -1' failed.

OK, I will have a look.

Thanks,
Gwenole.

[B2-devel] New SheepShaver troubles continued...

[Tomasz J. <to...@je...>]

I've finally managed to run the newest snapshot of SheepShaver on
another PC (will probably also work on the previous one). I had to
modify the generated Makefile and replace -O2 with -O1 everywhere. Not
it works fine with JIT. It seems that there is a bug in GCC (3.3.2) or
your code is too hackish. However when I removed -O2 altogether,
SheepShaver did not compile at all.

This is a result of 'make' (last lines):
=========
c++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\"
-g  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/X11R6/include  -c
../kpx_cpu/src/cpu/jit/cxxdemangle.cpp -o obj/cxxdemangle.o
c++ -o dyngen   obj/dyngen.o obj/cxxdemangle.o
./dyngen -o basic-dyngen-ops.hpp obj/basic-dyngen-ops.o
c++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\"
-g  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/X11R6/include  -c
../kpx_cpu/src/cpu/jit/basic-dyngen.cpp -o obj/basic-dyngen.o
c++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
-DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=\"/usr/local/share/SheepShaver\"
-g  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2
-I/usr/lib/glib/include -I/usr/X11R6/include  -fomit-frame-pointer
-mpreferred-stack-boundary=2 -falign-functions=0 -mmmx -msse -msse2
-finline-limit=10000 -fno-reorder-blocks -fno-optimize-sibling-calls -c
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp -o obj/ppc-dyngen-ops.o
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In static member function
`static
   void op_V2DI::set(powerpc_vr&, int, long long unsigned int)':
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400: error: unable to find a
   register to spill in class `GENERAL_REGS'
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400: error: this is the insn:
(insn 15 14 17 0 0xbd201898 (set (mem/s/j:DI (plus:SI (mult:SI (reg:SI
60)
                    (const_int 8 [0x8]))
                (reg/f:SI 59)) [0 <variable>.j S8 A64])
        (reg:DI 61)) 59 {*movdi_2} (nil)
    (expr_list:REG_DEAD (reg:DI 61)
        (expr_list:REG_DEAD (reg:SI 60)
            (expr_list:REG_DEAD (reg/f:SI 59)
                (nil)))))
../kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1400: confused by earlier
errors, bailing out
make: *** [obj/ppc-dyngen-ops.o] Error 1
==========



I haven't measured how much faster is the newest version, but it still
suffers from some strange 'stops'. Sometimes you need to wait several
seconds until you can regain control of the emulated system (no response
from mouse or keyboard). Beside this, it is reasonably fast.

There is also problem with configuration interface. In video modes tab
there is one checkbox that is not described (the 6th one). Selecting
only 'Windowed 800x600' result in termination of application and
message:
SheepShaver.ok: video_x.cpp:1166: bool VideoInit(): Assertion `cur_mode
!= -1' failed.

Jerzu

Re: [B2-devel] JIT on x86 problem

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

Hi,

> Thank you very much! Unfortunately, it still crashes with JIT enabled.
> Moreover, when I ran it without JIT, but tried to boot with the wrong 
> CD,
> the tray ejected, I closed it again, but then my PC locked hard (had to
> reset it).

No matter your system is new or not, if it crashes with JIT enabled and 
not without, then there is a problem with JIT. Are you running as root? 
You could also try to get rid of your ~/.sheepshaver_nvram. BTW, what 
system and which ROM do you use?

Bye,
Gwenole.

[B2-devel] SheepShaver "idlewait" for BeOS

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

Hi,

I have added support for SynchIdleTime() to Linux versions and NewWorld 
ROMs. However, I noticed that BeOS code had a sleep(16667). Is that 
really intended? Currently, I have committed a Delay_usec() function to 
BeOS support code which uses snooze() instead, as it is implemented in 
SDL_Delay().

In Linux with a NewWorld v1.6 ROM, I can really see SheepShaver 
sleeping. ;-) However, in emulated mode, %CPU usage is around 5%. 
That's surely better than 97% anyway.

Bye,
Gwenole.

Re: [B2-devel] JIT on x86 problem

[Tomasz J. <to...@je...>]

----- Original Message ----- 
From: "Gwenole Beauchesne" <gb...@di...>
To: <bas...@li...>
Sent: Saturday, May 15, 2004 5:23 AM
Subject: Re: [B2-devel] JIT on x86 problem


> Hi,
>
> > So I'm not going to bother you now and will wait for the tarball...
>
> I have placed a temporary one here:
> <http://gwenole.beauchesne.free.fr/sheepshaver/files/SheepShaver-2.2-
> 20040514.tar.bz2>
>

Thank you very much! Unfortunately, it still crashes with JIT enabled.
Moreover, when I ran it without JIT, but tried to boot with the wrong CD,
the tray ejected, I closed it again, but then my PC locked hard (had to
reset it).

I think there is something wrong with my configuration. I'm using FC2 test
3, obviously with 2.6 kernel - maybe this is too new...
Today I will try to run it on a more conservative set-up. Expect a report
soon :)

Jerzu

Re: [B2-devel] JIT on x86 problem

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

Hi,

> So I'm not going to bother you now and will wait for the tarball...

I have placed a temporary one here:
<http://gwenole.beauchesne.free.fr/sheepshaver/files/SheepShaver-2.2- 
20040514.tar.bz2>

If you want ethernet support, you have to s/#ifdef WORDS_BIGENDIAN/#if  
1/ in kpx_cpu/sheepshaver_glue.cpp

Then, if you get some weird crashes or hangs with sheep_net enabled,  
try with MOL's module and the SheepShaver-2.2-misc.patch applied,  
available in the same directory. I have not yet checked why this  
happens that way.

Bye,
Gwenole.

Re: [B2-devel] CVS file permissions problem

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

On Fri, 14 May 2004, Christian Bauer wrote:

> On Fri, May 14, 2004 at 08:56:51AM +0200, Gwenole Beauchesne wrote:
> > I had added two files to CVS, namely dummy/ether_dummy.cpp and 
> > Unix/tunconfig. However, doing a fresh checkout of them, they have 755 
> > perms. Could you please turn them back to 644?
> 
> I've -x'd ether_dummy.cpp. Why shouldn't tunconfig be +x? It's an executable
> shell script, after all...

Yes, but I was under the impression that files added to the repository
normally are to not have exec bits. Anyhow, that's fine as is indeed.

Just that I was sure I had not +x'd those files prior to adding them.

Re: [B2-devel] CVS file permissions problem

[Christian B. <Chr...@un...>]

Hi!

On Fri, May 14, 2004 at 08:56:51AM +0200, Gwenole Beauchesne wrote:
> I had added two files to CVS, namely dummy/ether_dummy.cpp and 
> Unix/tunconfig. However, doing a fresh checkout of them, they have 755 
> perms. Could you please turn them back to 644?

I've -x'd ether_dummy.cpp. Why shouldn't tunconfig be +x? It's an executable
shell script, after all...

Bye,
Christian

-- 
  / Physics is an algorithm
\/ http://www.uni-mainz.de/~bauec002/

[B2-devel] CVS file permissions problem

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

Hi Christian,

I had added two files to CVS, namely dummy/ether_dummy.cpp and 
Unix/tunconfig. However, doing a fresh checkout of them, they have 755 
perms. Could you please turn them back to 644? I don't think there are 
working CVS commands for that.

Thanks,
Gwenole.

Re: [B2-devel] JIT on x86 problem

[Tomasz J. <to...@je...>]

> Hi,
>
> Sorry, I don't know why this happens for you. It could be a
> miscompilation, would you mind telling me which compiler do you use?
> For reference, I am using gcc 3.2.2 on x86 and gcc 3.3.2 on amd64.
>

I tried gcc 3.3.3 and 3.4.0 on x86 with the same effect. February snapshot
was fine on both compilers.

> Would you be so kind to prepare a new tarball snapshot?
>
> That was the plan to make it this week but there is another issue I
> want to check first.
>

So I'm not going to bother you now and will wait for the tarball...

> Bye,
> Gwenole.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel