basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] [ANN] Basilisk II JIT snapshot 2004/11/09

[Bob D. <bob...@te...>]

On Tue, 2004-11-09 at 23:52 +0100, Gwenole Beauchesne wrote:
> Hi,
>=20
> I have uploaded a new snapshot of current Basilisk II CVS tree with JIT=
=20
> here:
> <http://gwenole.beauchesne.online.fr/basilisk2/>
>=20
> What's new since snapshot 2003/03/14:
> - Port JIT compiler to x86-64 platforms (AMD64, EM64T)
> - Add audio and video support through SDL, but prefer X11 video
> - Add ethernet support through the Linux TUN/TAP device driver
>=20
> Bye,
> Gwenol=C3=A9.

Experiences on a freshly installed FC3 x86_64:

After CVS update, running ./autogen.sh shows the following problem in
the configure script:

1)
  checking linux/if.h usability... no
  checking linux/if.h presence... yes
  configure: WARNING: linux/if.h: present but cannot be compiled
  configure: WARNING: linux/if.h:     check for missing prerequisite
headers?
  configure: WARNING: linux/if.h: see the Autoconf documentation
  configure: WARNING: linux/if.h:     section "Present But Cannot Be
Compiled"
  configure: WARNING: linux/if.h: proceeding with the preprocessor's
result
  configure: WARNING: linux/if.h: in the future, the compiler will take
precedence
  configure: WARNING:     ## -------------------------------------------
##
  configure: WARNING:     ## Report this to Chr...@un...
##
  configure: WARNING:     ## -------------------------------------------
##
  [Looking in config.log I find:In file included from conftest.c:142:
  /usr/include/linux/if.h:86: error: field `ifru_addr' has incomplete
type
  /usr/include/linux/if.h:87: error: field `ifru_dstaddr' has incomplete
type
  /usr/include/linux/if.h:88: error: field `ifru_broadaddr' has
incomplete type
  /usr/include/linux/if.h:89: error: field `ifru_netmask' has incomplete
type
  /usr/include/linux/if.h:90: error: field `ifru_hwaddr' has incomplete
type

 Seems this header on its own doesn't know type 'struct sockaddr', hence
it should include <sys/socket.h> in its test

 The following small patch fixes this:
--- configure.ac        8 Nov 2004 21:07:07 -0000       1.34
+++ configure.ac        10 Nov 2004 06:45:38 -0000
@@ -265,7 +265,9 @@
 AC_HEADER_STDC
 AC_CHECK_HEADERS(unistd.h fcntl.h sys/types.h sys/time.h sys/mman.h
mach/mach.h)
 AC_CHECK_HEADERS(readline.h history.h readline/readline.h
readline/history.h)
-AC_CHECK_HEADERS(linux/if.h linux/if_tun.h net/if.h net/if_tun.h)
+AC_CHECK_HEADERS(sys/socket.h)
+AC_CHECK_HEADERS(linux/if.h,[],[],[#include <sys/socket.h>])
+AC_CHECK_HEADERS(linux/if_tun.h net/if.h net/if_tun.h)
 AC_CHECK_HEADERS(AvailabilityMacros.h)

 dnl Checks for typedefs, structures, and compiler characteristics.
 ]

Trying to compile the nojit version works without any hitches, and it
runs a MacOS 8.0 image which I had previously created without apparent
problems.

Trying to compile after ./configure --with-jit-compiler results in a
problem:

g++ -I../include -I. -I../uae_cpu -DHAVE_CONFIG_H  -DOS_linux -
DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DX86_64_ASSEMBLY -
DOPTIMIZED_FLAGS -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -D_REENTRANT -
DDATADIR=3D\"/usr/local/share/BasiliskII\" -O2 -I/usr/X11R6/include -
I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib64/glib/include
-I/usr/X11R6/include -fno-merge-constants -fno-gcse-sm -
c ../uae_cpu/compiler/compemu_support.cpp -o obj/compemu_support.o
In file included from ../uae_cpu/compiler/compemu_support.cpp:753:
../uae_cpu/compiler/codegen_x86.cpp: In function `void raw_call
(uint32)':
../uae_cpu/compiler/codegen_x86.cpp:3043: warning: cast from pointer to
integer of different size
../uae_cpu/compiler/codegen_x86.cpp: In function `void raw_jmp(uint32)':
../uae_cpu/compiler/codegen_x86.cpp:3053: warning: cast from pointer to
integer of different size
/tmp/ccmQvYdd.s: Assembler messages:
/tmp/ccmQvYdd.s:40547: Error: suffix or operands invalid for `push'
/tmp/ccmQvYdd.s:40547: Error: suffix or operands invalid for `pop'
make: *** [obj/compemu_support.o] Error 1

This one will take a bit more time for me to try and understand.

Sincerely,

Bob Deblier

[B2-devel] [ANN] Basilisk II JIT snapshot 2004/11/09

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

Hi,

I have uploaded a new snapshot of current Basilisk II CVS tree with JIT=20=

here:
<http://gwenole.beauchesne.online.fr/basilisk2/>

What's new since snapshot 2003/03/14:
- Port JIT compiler to x86-64 platforms (AMD64, EM64T)
- Add audio and video support through SDL, but prefer X11 video
- Add ethernet support through the Linux TUN/TAP device driver

Bye,
Gwenol=E9.=

Re: [B2-devel] CVS server down

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

lundi 8 novembre 2004, =E0 11:04  am, Christian Bauer a =E9crit :

> The whole university was disconnected from the internet for most of =
the
> weekend. It appears to be OK now.

Thanks, indeed. I could commit a slight optimization to the 64-bit JIT=20=

with "33-bit" memory addressing, so that we can get rid of superfluous=20=

sign-extension of the offset in address translation + a merge from=20
Amithlon wrt. to BSF emulation on Pentium 4 (lower register wastage).=20
Still some optimizations to go.

Bye,
Gwenol=E9.=

Re: [B2-devel] CVS server down

[Bob D. <bob...@te...>]

On Mon, 2004-11-08 at 13:38, disad wrote:
> can some one confirm that its up for me?
> if it is, its time for me to go back to the old firewall config.
> 
> disad

Works for me.

Bob Deblier

Re: [B2-devel] CVS server down

[disad <di...@sw...>]

Christian Bauer wrote:

>Hi!
>
>On Mon, Nov 08, 2004 at 07:53:43AM +0100, Gwenole Beauchesne wrote:
>  
>
>>"down" seems to be down and I couldn't reach you yesterday. Could you 
>>have a look please?
>>    
>>
>
>The whole university was disconnected from the internet for most of the
>weekend. It appears to be OK now.
>
>Bye,
>Christian
>
>  
>
can some one confirm that its up for me?
if it is, its time for me to go back to the old firewall config.

disad

Re: [B2-devel] CVS server down

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

Hi!

On Mon, Nov 08, 2004 at 07:53:43AM +0100, Gwenole Beauchesne wrote:
> "down" seems to be down and I couldn't reach you yesterday. Could you 
> have a look please?

The whole university was disconnected from the internet for most of the
weekend. It appears to be OK now.

Bye,
Christian

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

[B2-devel] CVS server down

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

Hi,

"down" seems to be down and I couldn't reach you yesterday. Could you=20
have a look please?

Thanks,
Gwenol=E9.=

Re: [B2-devel] B2/JIT for x86_64

[Bob D. <bob...@te...>]

On Wed, 2004-11-03 at 09:39, Gwenole Beauchesne wrote:
> Hi,
> 
> > Fedora Core 2 on an Athlon64: compilation warnings but no errors.
> > Test combination of MacOS 8 CD with NewWorld ROM v. 1.0 p:
> 
> Hmm, are you talking about SheepShaver?

SheepShaver - sorry I got confused; it's one mailing list for both
emulators.

BasiliskII compiles without any problems, and runs fine; faster than any
68K Mac I've ever owned...

> > "Welcome to Mac OS" -> freezes.
> 
> If it's SheepShaver, freezes were supposed to be fixed in last 
> snapshot. Does it freezes without JIT? It would be slow though. Anyway, 
> I won't invest much time in the current SheepShaver/JIT since it's to 
> be obsoleted now that the run-time assembler is being debugged within 
> Basilisk II.

Latest CVS build of SheepShaver this morning; no problem - I'll hold out
for that release.

Test results without JIT: crash (SIGSEGV)

Installing drivers...
SIGSEGV
  pc 0x46929c
  ea 0x40461008
 r0 00000000   r1 25ff85f0   r2 00000000   r3 26000400
 r4 00002278   r5 fffffffa   r6 00004e75   r7 ffffffe8
 r8 00000000   r9 00000028  r10 0000006a  r11 2400694e
r12 ffffffff  r13 00000000  r14 200031cc  r15 23ffec00
r16 20078af8  r17 000013ff  r18 20077ec8  r19 40814c1e
r20 25ff8602  r21 26000190  r22 26000400  r23 00000000
r24 00001401  r25 00000020  r26 00000000  r27 ffff876e
r28 00000000  r29 40df1200  r30 40c60000  r31 68fff000
 f0 0.00000   f1 0.00000   f2 0.00000   f3 0.00000
 f4 0.00000   f5 0.00000   f6 0.00000   f7 0.00000
 f8 0.00000   f9 0.00000  f10 0.00000  f11 0.00000
f12 0.00000  f13 0.00000  f14 0.00000  f15 0.00000
f16 0.00000  f17 0.00000  f18 0.00000  f19 0.00000
f20 0.00000  f21 0.00000  f22 0.00000  f23 0.00000
f24 0.00000  f25 0.00000  f26 0.00000  f27 0.00000
f28 0.00000  f29 0.00000  f30 0.00000  f31 0.00000
 lr 40df1200  ctr 00000000   cr 40501c22  xer 00000000
 pc 40df1200 fpscr 00000000

Sincerely,

Bob Deblier

Re: [B2-devel] B2/JIT for x86_64

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

Hi,

> Fedora Core 2 on an Athlon64: compilation warnings but no errors.
> Test combination of MacOS 8 CD with NewWorld ROM v. 1.0 p:

Hmm, are you talking about SheepShaver?

> "Welcome to Mac OS" -> freezes.

If it's SheepShaver, freezes were supposed to be fixed in last 
snapshot. Does it freezes without JIT? It would be slow though. Anyway, 
I won't invest much time in the current SheepShaver/JIT since it's to 
be obsoleted now that the run-time assembler is being debugged within 
Basilisk II.

Re: [B2-devel] SheepShaver on x86_64

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

mardi 2 novembre 2004, =E0 09:44  pm, Tomek Jerzykowski a =E9crit :

> Now I execute 'make' and what do I see? The following errors appear:
> (...)
> g++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I. -
> DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=3D\"/usr/local/share/SheepShaver\"=
=20
> -
> g -O2  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -
> I/usr/include/glib-1.2 -I/usr/lib64/glib/include -I/usr/X11R6/include =20=

> -
> finline-limit=3D10000 -fno-reorder-blocks -fno-optimize-sibling-calls =
-
> c ../kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp -o =
obj/basic-dyngen-ops.o
> ../kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp: In function `void
> op_mov_32_T0_im()':
> ../kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp:82: error: ISO C++ forbids
> cast to non-reference type used as lvalue

I have experimented a fix for this, without the -fpermissive trick.

> Complete failure again...
> What should I do now? Any clues? Need more info?

I will try to check that over the next weekend since I now have means=20
to work on it at home. ;-)=

Re: [B2-devel] B2/JIT for x86_64

[Bob D. <bob...@te...>]

On Mon, 2004-11-01 at 22:53, Gwenole Beauchesne wrote:
> Hi,

Fedora Core 2 on an Athlon64: compilation warnings but no errors.

Test combination of MacOS 8 CD with NewWorld ROM v. 1.0 p:

"Welcome to Mac OS" -> freezes.

This is currently the only MacOS CD I have to test - I'll look around if
I can find anything else in the following weeks.

Keep up the great work.

Bob Deblier

[B2-devel] SheepShaver on x86_64

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

On Athlon 64 to be precise.

I decided to compile Sheepshaver on my new Athlon 64 rig, however
without succes.=20

=46irst of all, this is what I have:
=46edora Core 3 test 3 x86_64
gcc 3.4.2:
Configured with: ../configure --prefix=3D/usr --mandir=3D/usr/share/man=
 --
infodir=3D/usr/share/info --enable-shared --enable-threads=3Dposix --
disable-checking --with-system-zlib --enable-__cxa_atexit --disable-
libunwind-exceptions --enable-languages=3Dc,c++,objc,java,f77 --enable-
java-awt=3Dgtk --host=3Dx86_64-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6)

I downloaded the latest sources (today) from CVS, then executed:

cvs -d :pserver:an...@do...:/cvs checkout
BasiliskII
$ cvs -d :pserver:an...@do...:/cvs checkout
SheepShaver
$ cd SheepShaver
$ make links
$ cd src/Unix
$ ./autogen.sh

So far everything has been fine. This is the end of autogen output:
SheepShaver configuration summary:

SDL support ...................... : none
XFree86 DGA support .............. : yes
XFree86 VidMode support .......... : no
Using PowerPC emulator ........... : yes
Enable JIT compiler .............. : yes
Enable video on SEGV signals ..... : yes
ESD sound support ................ : yes
GTK user interface ............... : yes
mon debugger support ............. : no
Bad memory access recovery type .. : siginfo

Now I execute 'make' and what do I see? The following errors appear:
(...)
g++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I. -
DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=3D\"/usr/local/share/SheepShaver\=
" -
g -O2  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -
I/usr/include/glib-1.2 -I/usr/lib64/glib/include -I/usr/X11R6/include  =
-
finline-limit=3D10000 -fno-reorder-blocks -fno-optimize-sibling-calls -
c ../kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp -o obj/basic-dyngen-ops.o
=2E./kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp: In function `void
op_mov_32_T0_im()':
=2E./kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp:82: error: ISO C++ forbid=
s
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp: In function `void
op_mov_32_T0_T1()':
=2E./kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp:83: error: ISO C++ forbid=
s
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp: In function `void
op_mov_32_T0_T2()':
=2E./kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp:84: error: ISO C++ forbid=
s
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp: In function `void
op_mov_32_T0_A0()':
=2E./kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp:85: error: ISO C++ forbid=
s
cast to non-reference type used as lvalue
(...)


=46ine, I say, I know how to overcome it. So I add -fpermissive switch =
to
Makefile:
(...)
CXXFLAGS =3D -g -O2  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -
I/usr/include/glib-1.2 -I/usr/lib64/glib/include -I/usr/X11R6/include -
fpermissive
(...)


Now 'make clean' and 'make' again. It goes a but farther:
(...)
=2E./kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp: In function `void
op_load_s8_T0_A0_im()':
=2E./kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp:227: warning: ISO C++
forbids cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp: In function `void
op_load_u8_T0_A0_T1()':
=2E./kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp:228: warning: ISO C++
forbids cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp: In function `void
op_load_s8_T0_A0_T1()':
=2E./kpx_cpu/src/cpu/jit/basic-dyngen-ops.cpp:228: warning: ISO C++
forbids cast to non-reference type used as lvalue
gcc -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I. -
DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=3D\"/usr/local/share/SheepShaver\=
" -
g -O2  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -
I/usr/include/glib-1.2 -I/usr/lib64/glib/include -I/usr/X11R6/include  =
-
c ../kpx_cpu/src/cpu/jit/dyngen.c -o obj/dyngen.og++ -
I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I. -
DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=3D\"/usr/local/share/SheepShaver\=
" -
g -O2  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -
I/usr/include/glib-1.2 -I/usr/lib64/glib/include -I/usr/X11R6/include -
fpermissive -c ../kpx_cpu/src/cpu/jit/cxxdemangle.cpp -o
obj/cxxdemangle.o
g++ -o dyngen   obj/dyngen.o obj/cxxdemangle.o
=2E/dyngen -o basic-dyngen-ops.hpp obj/basic-dyngen-ops.o
dyngen: invalid section for opcode (0x0)
make: *** [basic-dyngen-ops.hpp] B=C5=82=C4=85d 1


Oh, I'm almost stuck now. But let's play a bit more. I change
optimization settings in Makefile from -02 to -O1 in the following way:
(...)
CFLAGS =3D -g -O1  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -
I/usr/include/glib-1.2 -I/usr/lib64/glib/include -I/usr/X11R6/include
CXXFLAGS =3D -g -O1  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -
I/usr/include/glib-1.2 -I/usr/lib64/glib/include -I/usr/X11R6/include -
fpermissive
(...)


Now 'make clean' and 'make' again:
(...)
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void
op_subfzeo_T0()':
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1216: warning: ISO C++ forb=
ids
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void op_nego_=
T0
()':
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1232: warning: ISO C++ forb=
ids
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void op_dcbz_=
T0
()':
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1237: warning: ISO C++ forb=
ids
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void do_lmw()
[with int N =3D 26]':
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1313:   instantiated from h=
ere
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1267: warning: ISO C++ forb=
ids
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void do_lmw()
[with int N =3D 27]':
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1268:   instantiated from
`void do_lmw() [with int N =3D 26]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1313:   instantiated from h=
ere
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1267: warning: ISO C++ forb=
ids
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void do_lmw()
[with int N =3D 28]':
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1268:   instantiated from
`void do_lmw() [with int N =3D 27]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1268:   instantiated from
`void do_lmw() [with int N =3D 26]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1313:   instantiated from h=
ere
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1267: warning: ISO C++ forb=
ids
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void do_lmw()
[with int N =3D 29]':
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1268:   instantiated from
`void do_lmw() [with int N =3D 28]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1268:   instantiated from
`void do_lmw() [with int N =3D 27]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1268:   instantiated from
`void do_lmw() [with int N =3D 26]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1313:   instantiated from h=
ere
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1267: warning: ISO C++ forb=
ids
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void do_lmw()
[with int N =3D 30]':
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1268:   instantiated from
`void do_lmw() [with int N =3D 29]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1268:   instantiated from
`void do_lmw() [with int N =3D 28]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1268:   instantiated from
`void do_lmw() [with int N =3D 27]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1268:   instantiated from
`void do_lmw() [with int N =3D 26]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1313:   instantiated from h=
ere
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1267: warning: ISO C++ forb=
ids
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void do_stmw(=
)
[with int N =3D 26]':
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1313:   instantiated from h=
ere
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1289: warning: ISO C++ forb=
ids
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void do_stmw(=
)
[with int N =3D 27]':
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1290:   instantiated from
`void do_stmw() [with int N =3D 26]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1313:   instantiated from h=
ere
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1289: warning: ISO C++ forb=
ids
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void do_stmw(=
)
[with int N =3D 28]':
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1290:   instantiated from
`void do_stmw() [with int N =3D 27]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1290:   instantiated from
`void do_stmw() [with int N =3D 26]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1313:   instantiated from h=
ere
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1289: warning: ISO C++ forb=
ids
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void do_stmw(=
)
[with int N =3D 29]':
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1290:   instantiated from
`void do_stmw() [with int N =3D 28]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1290:   instantiated from
`void do_stmw() [with int N =3D 27]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1290:   instantiated from
`void do_stmw() [with int N =3D 26]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1313:   instantiated from h=
ere
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1289: warning: ISO C++ forb=
ids
cast to non-reference type used as lvalue
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp: In function `void do_stmw(=
)
[with int N =3D 30]':
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1290:   instantiated from
`void do_stmw() [with int N =3D 29]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1290:   instantiated from
`void do_stmw() [with int N =3D 28]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1290:   instantiated from
`void do_stmw() [with int N =3D 27]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1290:   instantiated from
`void do_stmw() [with int N =3D 26]'
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1313:   instantiated from h=
ere
=2E./kpx_cpu/src/cpu/ppc/ppc-dyngen-ops.cpp:1289: warning: ISO C++ forb=
ids
cast to non-reference type used as lvalue
=2E/dyngen -o ppc-dyngen-ops.hpp obj/ppc-dyngen-ops.o
g++ -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I. -
DHAVE_CONFIG_H -D_REENTRANT -DDATADIR=3D\"/usr/local/share/SheepShaver\=
" -
g -O1  -I/usr/X11R6/include -I/usr/include/gtk-1.2 -
I/usr/include/glib-1.2 -I/usr/lib64/glib/include -I/usr/X11R6/include -
fpermissive -c ../kpx_cpu/src/cpu/ppc/ppc-dyngen.cpp -o obj/ppc-dyngen.=
o
/tmp/ccP0F64j.s: Assembler messages:
/tmp/ccP0F64j.s:54225: Error: suffix or operands invalid for `push'
/tmp/ccP0F64j.s:54225: Error: suffix or operands invalid for `push'
/tmp/ccP0F64j.s:54225: Error: suffix or operands invalid for `pop'
/tmp/ccP0F64j.s:54225: Error: suffix or operands invalid for `pop'
make: *** [obj/ppc-dyngen.o] B=C5=82=C4=85d 1


Complete failure again...
What should I do now? Any clues? Need more info?



=46ull autogen.sh output:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
+ Running aclocal: configure.ac:298: warning: underquoted definition of
AC_CHECK_FRAMEWORK
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending-
aclocal
configure.ac:378: warning: underquoted definition of AC_TRANSLATE_DEFIN=
E
done.
 + Running autoheader: done.
 + Running autoconf: done.
 + Running 'configure ':
   ** If you wish to pass arguments to ./configure, please
   ** specify them on the command line.
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking whether make sets $(MAKE)... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for egrep... grep -E
checking for PowerPC target CPU... no
checking for mon... no
configure: WARNING: Could not find mon, ignoring --with-mon.
checking for sem_init in -lposix4... no
checking for X... libraries /usr/X11R6/lib64, headers /usr/X11R6/includ=
e
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for pthread_create in -lpthread... yes
checking for pthread_cancel... yes
checking for pthread_mutexattr_setprotocol... no
checking for pthread_mutexattr_settype... yes
checking for pthread_mutexattr_setpshared... yes
checking for sem_init... yes
checking for XF86DGAQueryExtension in -lXxf86dga... yes
checking for gtk-config... /usr/bin/gtk-config
checking for GTK - version >=3D 1.2.0... yes
checking for esd-config... /usr/bin/esd-config
checking for ESD - version >=3D 0.2.8... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for _LARGE_FILES value needed for large files... no
checking for ANSI C header files... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking mach/vm_map.h usability... no
checking mach/vm_map.h presence... no
checking for mach/vm_map.h... no
checking mach/mach_init.h usability... no
checking mach/mach_init.h presence... no
checking for mach/mach_init.h... no
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking sys/times.h usability... yes
checking sys/times.h presence... yes
checking for sys/times.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking unistd.h usability... yes
checking unistd.h presence... yes
checking for unistd.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking byteswap.h usability... yes
checking byteswap.h presence... yes
checking for byteswap.h... yes
checking dirent.h usability... yes
checking dirent.h presence... yes
checking for dirent.h... yes
checking for linux/if.h... yes
checking linux/if_tun.h usability... yes
checking linux/if_tun.h presence... yes
checking for linux/if_tun.h... yes
checking net/if.h usability... yes
checking net/if.h presence... yes
checking for net/if.h... yes
checking net/if_tun.h usability... no
checking net/if_tun.h presence... no
checking for net/if_tun.h... no
checking whether byte ordering is bigendian... no
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for short... yes
checking size of short... 2
checking for int... yes
checking size of int... 4
checking for long... yes
checking size of long... 8
checking for long long... yes
checking size of long long... 8
checking for float... yes
checking size of float... 4
checking for double... yes
checking size of double... 8
checking for void *... yes
checking size of void *... 8
checking for off_t... yes
checking for loff_t... yes
checking for size_t... yes
checking return type of signal handlers... void
checking whether time.h and sys/time.h may both be included... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking whether struct sigaction has sa_restorer... yes
checking for strdup... yes
checking for strlcpy... no
checking for cfmakeraw... yes
checking for nanosleep... yes
checking for sigaction... yes
checking for signal... yes
checking for mmap... yes
checking for mprotect... yes
checking for munmap... yes
checking for vm_allocate... no
checking for vm_deallocate... no
checking for vm_protect... no
checking for posix_memalign... yes
checking for memalign... yes
checking for valloc... yes
checking for mach_task_self... no
checking for task_self... no
checking for library containing clock_gettime... -lrt
checking for clock_gettime... yes
checking whether compiler supports framework Carbon... no
checking whether compiler supports framework IOKit... no
checking whether TUN/TAP is supported... yes
checking whether mmap supports MAP_ANON... yes
checking whether mmap supports MAP_ANONYMOUS... yes
checking whether mprotect works... yes
checking whether __PAGEZERO can be Low Memory area 0x0000-0x3000... no
checking whether we can map Low Memory area 0x0000-0x3000... yes
checking whether signal handlers need to be reinstalled... no
checking whether sigaction handlers need to be reinstalled... no
checking whether your system supports Mach exceptions... no
checking whether your system supports extended signal handlers... yes
checking whether we can skip instruction in SIGSEGV handler... yes
checking for true... /bin/true
checking for GCC 2.7 or higher... yes
checking for GCC 3.0 or higher... yes
checking for ICC... no
checking whether the compiler can generate ELF objects... yes
checking whether dyngen can be used... yes
checking mmintrin.h usability... yes
checking mmintrin.h presence... yes
checking for mmintrin.h... yes
checking xmmintrin.h usability... yes
checking xmmintrin.h presence... yes
checking for xmmintrin.h... yes
checking emmintrin.h usability... yes
checking emmintrin.h presence... yes
checking for emmintrin.h... yes
checking whether static data regions are executable... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating ../MacOSX/Info.plist
config.status: creating config.h

SheepShaver configuration summary:

SDL support ...................... : none
XFree86 DGA support .............. : yes
XFree86 VidMode support .......... : no
Using PowerPC emulator ........... : yes
Enable JIT compiler .............. : yes
Enable video on SEGV signals ..... : yes
ESD sound support ................ : yes
GTK user interface ............... : yes
mon debugger support ............. : no
Bad memory access recovery type .. : siginfo

Configuration done. Now type "make".
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

[B2-devel] B2/JIT for x86_64

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

Hi,

I revived and fixed the x86_64 port that started almost two years ago.=20=

Performance may look lower than with the 32-bit binary because it's=20
currently lacking two key features that will yield an interesting speed=20=

boost. For now, it's a way to check the runtime assembler is working=20
properly for a new PowerPC JIT.

Talking about a verifier, I currently have a test code=20
(test_codegen_x86.cpp) that covers only 5.5 million variations and is=20
lacking some others. Someone may be interested in contributing a=20
rewrite that uses a derivative of GNU disassembler's internal=20
structures instead of string compares to check things. I simply=20
implemented that rapidly for other matters. ;-)

My test machine for the port is based on Xeon EM64T but it should work=20=

fine on AMD64 processors too. Relevant code is in CVS.

Bye,
Gwenol=E9.=

Re: [B2-devel] Patch for dyngen.c for Fedora 2 x86_64

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

Hi,

> I've managed to figure out the problem in dyngen.c on FC2 x86_64 and
> have prepared a patch, attached in this message.

Applied, thanks.

[B2-devel] Patch for dyngen.c for Fedora 2 x86_64

[Bob D. <bob...@te...>]

I've managed to figure out the problem in dyngen.c on FC2 x86_64 and
have prepared a patch, attached in this message.

Sincerely,

Bob Deblier

[B2-devel] SheepShaver build problem

[Bob D. <bob...@te...>]

Hi,

I'm trying to build SheepShaver on Fedora Core 2 x86_64. The current CVS
version and Gwenole's latest snapshot both give the same problem:

./dyngen -o ppc-dyngen-ops.hpp obj/ppc-dyngen-ops.o
dyngen: invalid section for local data .LC4 (a)

Does anyone have pointers on how to help in investigate/fix this? Is
there a version which can be compiled on this platform?

Sincerly,

Bob Deblier 

[B2-devel] Re: PowerMac ROM

[Toshimitsu T. <t_t...@db...>]

Hi.

On 2004/08/10, at 19:59, Mike Goggin wrote:
> Is there a tool that'll grab it for me?

I used ROM Grabber.

http://www.maconlinux.org/download.html
---
Toshimitsu Tanaka
t_t...@db...
http://homepage3.nifty.com/toshi3/index.html

[B2-devel] PowerMac ROM

[Mike G. <eb_...@sb...>]

Howdy.

This may sound like a stupid question, but how does one obtain a 
PowerMac ROM? I own a PowerMac, I just need to know how to get at the 
ROM it contains. Is there a tool that'll grab it for me?

Thanks.

- Mike

[B2-devel] Re: BasiliskII SDL on IRIX

[Brian J. <bjj...@us...>]

Gwenole Beauchesne wrote:
> Brian Johnson wrote:
> > Gdk-ERROR **: BadMatch (invalid parameter attributes)
> >   serial 1015 error_code 8 request_code 129 minor_code 3
>
> What I usually do is to disable gtk in order to determine more easily
> which X function it is.

I gave that a try.  Here's what I get:

X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  129 (MIT-SHM)
  Minor opcode of failed request:  3 (X_ShmPutImage)
  Serial number of failed request:  905
  Current serial number in output stream:  906

BTW, SDL audio seems to work on IRIX, at least in 16bit, 44khz mode.
8bit mode is icky and distorted (much like it is with the IRIX
libaudio driver); something seems wrong with the sample format.  22khz
16bit sometimes works, but doesn't always produce sound.  Sometimes
the sound seems delayed... buffering problem?  And 11khz doesn't make
any sound at all.

						Brian

--------------------------------------------------------------------

  "One problem thoroughly mastered is of more value than many poorly
   mastered."
                                           -- Booker T. Washington

Re: [B2-devel] BasiliskII SDL on IRIX

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

mardi 27 juillet 2004, =E0 11:12  pm, Gwenole Beauchesne a =E9crit :

> Nice catch, thanks. What about something like:
> int depth =3D (VIDEO_MODE_DEPTH <=3D VIDEO_DEPTH_8BIT ? 8 :=20
> sdl_depth_of_video_depth(screen_depth));

Forget about it, that's wrong.

Re: [B2-devel] BasiliskII SDL on IRIX

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

Hi,

> However, it was passing the requested Mac video depth as the 3rd
> parameter to Screen_blitter_init().

Nice catch, thanks. What about something like:
int depth =3D (VIDEO_MODE_DEPTH <=3D VIDEO_DEPTH_8BIT ? 8 :=20
sdl_depth_of_video_depth(screen_depth));

Since that code is used elsewhere, it could be factored into something=20=

like mac_depth_of_video_depth() but this name doesn't make sense.

> I still have problems changing depths using SGI's Xserver, which
> supports multiple visuals at multiple depths at once.  I get BadMatch
> errors:

Still using sdl output or raw X11 output? IIRC, in video_x.cpp,=20
Christian tried the best to respect visuals and to prefer the ones=20
(DirectColor) that can handle gamma first. Last I checked for SDL,=20
selection looked quite different than in B2/video_x.cpp.

> Gdk-ERROR **: BadMatch (invalid parameter attributes)
>   serial 1015 error_code 8 request_code 129 minor_code 3

What I usually do is to disable gtk in order to determine more easily=20
which X function it is.

Bye,
Gwenol=E9.=

Re: [B2-devel] BasiliskII SDL on IRIX

[Brian J. <bjj...@us...>]

I wrote:
> "Thousands" of colors mode squashes the entire
> display into the left half of the window, with an odd green cast.
> Looks like something's not quite right in the 16bpp blitter...

I think I found the problem:  BII was trying to use a 32bpp blitter in
16-bit video mode, so only half of the window was getting filled and
the colors were in the wrong bit positions.  The basic issue was that
driver_window::driver_window(SDL_monitor_desc &m) was setting its
"depth" variable, which is passed to SDL_SetVideoMode, from
screen_depth (which is set at init. time and then never changed.)
However, it was passing the requested Mac video depth as the 3rd
parameter to Screen_blitter_init().  So that parameter did not match
VisualFormat.depth, which broke the assumptions made by
Screen_blitter_init().

This seems to fix it:

bjjsgi> cvs diff -u SDL/video_sdl.cpp
Index: SDL/video_sdl.cpp
===================================================================
RCS file: /cvs/BasiliskII/src/SDL/video_sdl.cpp,v
retrieving revision 1.9
diff -u -r1.9 video_sdl.cpp
--- SDL/video_sdl.cpp   27 Jun 2004 17:31:21 -0000      1.9
+++ SDL/video_sdl.cpp   27 Jul 2004 18:22:20 -0000
@@ -618,7 +618,23 @@
        ADBSetRelMouseMode(mouse_grabbed);

        // Create surface
-       int depth = (VIDEO_MODE_DEPTH <= VIDEO_DEPTH_8BIT ? 8 : screen_depth);
+       int depth;
+       switch (VIDEO_MODE_DEPTH) {
+       case VIDEO_DEPTH_1BIT:
+       case VIDEO_DEPTH_2BIT:
+       case VIDEO_DEPTH_4BIT:
+       case VIDEO_DEPTH_8BIT:
+               depth = 8;
+               break;
+       case VIDEO_DEPTH_16BIT:
+               depth = 16;
+               break;
+       case VIDEO_DEPTH_32BIT:
+               depth = 32;
+               break;
+       default:
+               abort();
+       }
        if ((s = SDL_SetVideoMode(width, height, depth, SDL_HWSURFACE)) == NULL)
                return;

It sets depth based on the requested Mac video depth, rather than the
init. time SDL default depth.

I still have problems changing depths using SGI's Xserver, which
supports multiple visuals at multiple depths at once.  I get BadMatch
errors:

Gdk-ERROR **: BadMatch (invalid parameter attributes)
  serial 1015 error_code 8 request_code 129 minor_code 3

I don't have that problem using Xvnc, which is based on XFree86 and
supports only a single visual depth.  Any suggestions?

						Brian

--------------------------------------------------------------------

  ... He say, "One and one and one is one.  The one thing I can tell you is
      debug till it runs" ...
  If the Beatles had studied computer science

Re: [B2-devel] SheepShaver on MacOS X issues

[Dara H. <dha...@ya...>]

--- Gwenole Beauchesne <gb...@di...> wrote:
> There was an old bug in video code that prevented to
> shutdown 
> completely. i.e. the window remained active.

Ah, ok...
> 
> > At this point, I'd just like to understand why
> > disabling esound makes booting fail... Otherwise
> I'm
> > happy that OS 7.6 works fine now!
> 
> You will probably want to use SDL. For MacOS X, I am
> confiugring 
> SheepShaver as follows:
> --enable-sdl-static --enable-sdl-video
> --enable-sdl-audio --without-gtk
> 
> The interesting thing to test is --enable-sdl-audio.
> Then, you can 
> check if you still get errors with the ESD backend
> through SDL as 
> follows: SDL_AUDIODRIVER=esd ./SheepShaver. 
> Otherwise, SDL uses the 
> SoundManager by default and this one works for me.

Okay, built as described above. Neither with
SDL_AUDIODRIVER=esd nor without do I hear any sound.
It does the usual start-booting, crash,
continue-booting routine.

Crashreporter gives me the usual "thread 0 crashed"
stuff...

Thread 0 Crashed:
0   ???                         0x00022f6c
catch_exception_raise + 0x1310
1   ???                         0x00023634
catch_exception_raise + 0x19d8
2   ???                         0x00023c34
catch_exception_raise + 0x1fd8
3   ???                         0x000241a0
catch_exception_raise + 0x2544
4   ???                         0x000054bc 0x3000 +
0x24bc
5   ???                         0x00029e80
catch_exception_raise + 0x8224
6   com.apple.Foundation        0x909f7184
_nsnote_callback + 0xb0
7   com.apple.CoreFoundation    0x901aa650
__CFXNotificationPost + 0x1b4
8   com.apple.CoreFoundation    0x901af060
_CFXNotificationPostNotification + 0x340
9   com.apple.Foundation        0x909f4fd0
-[NSNotificationCenter
postNotificationName:object:userInfo:] + 0x74
10  com.apple.AppKit            0x92ee37b8
-[NSApplication _postDidFinishNotification] + 0x70
11  com.apple.AppKit            0x92ee36a4
-[NSApplication _sendFinishLaunchingNotification] +
0x5c
12  com.apple.AppKit            0x92ee38d4
-[NSApplication(NSAppleEventHandling)
_handleCoreEvent:withReplyEvent:] + 0x78
13  com.apple.Foundation        0x90a4a544
-[NSAppleEventManager
dispatchRawAppleEvent:withRawReply:handlerRefCon:] +
0x164
14  com.apple.Foundation        0x90a50c6c
_NSAppleEventManagerGenericHandler + 0x78
15  com.apple.AE                0x9167ea68
aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned
long, unsigned char*) + 0xd0
16  com.apple.AE                0x916818b0
dispatchEventAndSendReply(AEDesc const*, AEDesc*) +
0x2c
17  com.apple.AE                0x9167eca8
aeProcessAppleEvent + 0x11c
18  com.apple.HIToolbox         0x928c47f4
AEProcessAppleEvent + 0x3c
19  com.apple.AppKit            0x92dd2c0c
_DPSNextEvent + 0x358
20  com.apple.AppKit            0x92de93b0
-[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] +
0x74
21  com.apple.AppKit            0x92dfd718
-[NSApplication run] + 0x21c
22  ???                         0x00029e08
catch_exception_raise + 0x81ac
23  ???                         0x0002a0cc
catch_exception_raise + 0x8470
24  ???                         0x00004810 0x3000 +
0x1810
25  ???                         0x00004684 0x3000 +
0x1684PPC Thread 

State:  srr0: 0x00022f6c srr1: 0x0000f930             
  vrsave: 0x00000000    cr: 0x82004228  xer:
0x00000007   lr: 0x00022f3c  ctr: 0x90008900    r0:
0x0000012e   r1: 0xbfffe5e0   r2: 0x00000000   r3:
0x0003e00c    r4: 0xe8b56f5d   r5: 0x00000198   r6:
0x00009858   r7: 0x0003e00c    r8: 0x00000000   r9:
0x006b5000  r10: 0x00000001  r11: 0x00086a68   r12:
0x000f4240  r13: 0x00000000  r14: 0x00000000  r15:
0x00000000   r16: 0x00074b90  r17: 0x00074b90  r18:
0x00074b90  r19: 0x00074b90   r20: 0x0008351c  r21:
0x0008351c  r22: 0x00086a68  r23: 0xbfffe630   r24:
0x00000000  r25: 0x00086a68  r26: 0x00000000  r27:
0xbfffe620   r28: 0x00086a68  r29: 0x0003e00c  r30:
0xe8b56f5d  r31: 0x00022f08

The code segment in question looks something like:

0x00022f54 <catch_exception_raise+4856>:        mr    
 r11,r22
0x00022f58 <catch_exception_raise+4860>:        li    
 r8,0
0x00022f5c <catch_exception_raise+4864>:        lwz   
 r2,8(r11)
0x00022f60 <catch_exception_raise+4868>:        lwz   
 r9,0(r11)
0x00022f64 <catch_exception_raise+4872>:        mullw 
 r2,r10,r2
0x00022f68 <catch_exception_raise+4876>:        addi  
 r10,r10,1
0x00022f6c <catch_exception_raise+4880>:        stbx  
 r8,r9,r2
_________________________________________________________________
0x00022f70 <catch_exception_raise+4884>:        lwz   
 r0,16(r11)
0x00022f74 <catch_exception_raise+4888>:        cmplw 
 cr7,r10,r0


Do you think that this is probably a MacOS bug at this
point? If so, is it likely to be fixable? I can live
with it, but it is somewhat annoying...

On a completely different note, how hard would
something like tun-based ethernet be to implement for
OS X?

Cheers,

Dara

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [B2-devel] SheepShaver on MacOS X issues

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

Hi,

> Well, I just checked again, and I'm getting a little
> confused. OS 7.6 just booted fine (from CD). I shut it
> down, and it hangs.

There was an old bug in video code that prevented to shutdown 
completely. i.e. the window remained active.

> At this point, I'd just like to understand why
> disabling esound makes booting fail... Otherwise I'm
> happy that OS 7.6 works fine now!

You will probably want to use SDL. For MacOS X, I am confiugring 
SheepShaver as follows:
--enable-sdl-static --enable-sdl-video --enable-sdl-audio --without-gtk
the latter is because I have a snapshot of the Quartz version of GTK 
and it doesn't work well enough to be usable.

Then, you can build SheepShaver as a MacOS X bundle: make 
SheepShaver_app

The interesting thing to test is --enable-sdl-audio. Then, you can 
check if you still get errors with the ESD backend through SDL as 
follows: SDL_AUDIODRIVER=esd ./SheepShaver.  Otherwise, SDL uses the 
SoundManager by default and this one works for me.

Re: [B2-devel] SheepShaver on MacOS X issues

[Dara H. <dha...@ya...>]

--- Gwenole Beauchesne <gb...@di...> wrote:

Hello,

> > Interestingly enough, my OS 8.1 CD seems to work
> fine
> > with my previous build (with gtk+ and esd
> enabled)! It
> > seems somewhat bizarre that simply changing the
> config
> > options would make it not boot at all...
> 
> Then, the problem is probably from OS 7.6 which is
> not supported well 
> enough?

Well, I just checked again, and I'm getting a little
confused. OS 7.6 just booted fine (from CD). I shut it
down, and it hangs. Then I try again (to reproduce),
and it works fine. I could swear that it wouldn't boot
at all 3 days ago. At this point, seems like a
heisenbug, so maybe forget it...

However, my esound-disabled build crashes booting
anything, and doesn't continue.

It crashes with PC 0x00035e24
The code is as follows:

0x00035e1c <dyld_stub_memchr+1256>:     ori    
r25,r19,29797
0x00035e20 <dyld_stub_memchr+1260>:     .long 0x0
0x00035e24 <dyld_stub_memchr+1264>:     rlwimi 
r9,r26,8,29,1
0x00035e28 <dyld_stub_memchr+1268>:     rlwinm 
r19,r10,0,0,0
0x00035e2c <dyld_stub_memchr+1272>:     dozi   
r11,r19,2560
0x00035e30 <dyld_stub_memchr+1276>:     subfic 
r3,r19,26983
0x00035e34 <dyld_stub_memchr+1280>:     ori    
r15,r27,28276

At this point, I'd just like to understand why
disabling esound makes booting fail... Otherwise I'm
happy that OS 7.6 works fine now!

Thanks,

Dara


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail