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

Brought to you by: cebix, ryan

basilisk-devel

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

From: Gwenole B. <gb...@di...> - 2004-11-09 22:52:07

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] [ANN] Basilisk II JIT snapshot 2004/11/09

From: Bob D. <bob...@te...> - 2004-11-10 06:48:53

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

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

From: Gwenole B. <gb...@di...> - 2004-11-10 07:38:30

mercredi 10 novembre 2004, =E0 07:48  am, Bob Deblier a =E9crit :

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

Thanks, fixed in CVS.

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

Could you copy this line (without -o obj/compemu_support.o and s/-c/-S)=20=

so that you cuold actually read the compemu_support.s generated file?

Then, if this is inline assembly code, it may be surrounded by=20
something like "#NO_APP". Otherwise, it's compiler generated code.

> 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

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

I don't know where it is coming from either. I have no explicit=20
reference to pushl or pushq as inline assembly.

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

From: Bob D. <bob...@te...> - 2004-11-10 08:37:16

On Wed, 2004-11-10 at 08:38 +0100, Gwenole Beauchesne wrote:
> Could you copy this line (without -o obj/compemu_support.o and s/-c/-S) 
> so that you cuold actually read the compemu_support.s generated file?
> 
> Then, if this is inline assembly code, it may be surrounded by 
> something like "#NO_APP". Otherwise, it's compiler generated code.

The lines in question are:
#APP
        push %eax; popf; bsf %esi,%esi; pushf; pop %eax
#NO_APP

Splitting the assembler over multiple lines shows that it's the push %
eax and pop %eax; tried fixing it with pushl and popl but that didn't do
the trick. Can 64-bit mode only push 64-bit quantities onto the stack?

Sincerely,

Bob

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

From: Tomek J. <to...@je...> - 2004-11-10 09:05:44

 

> -----Original Message-----
> From: bas...@li... 
> [mailto:bas...@li...] On Behalf 
> Of Bob Deblier
> Sent: Wednesday, November 10, 2004 9:37 AM
> To: bas...@li...
> Subject: Re: [B2-devel] [ANN] Basilisk II JIT snapshot 2004/11/09
> 
> On Wed, 2004-11-10 at 08:38 +0100, Gwenole Beauchesne wrote:
> > Could you copy this line (without -o obj/compemu_support.o and 
> > s/-c/-S) so that you cuold actually read the 
> compemu_support.s generated file?
> > 
> > Then, if this is inline assembly code, it may be surrounded by 
> > something like "#NO_APP". Otherwise, it's compiler generated code.
> 
> The lines in question are:
> #APP
>         push %eax; popf; bsf %esi,%esi; pushf; pop %eax #NO_APP
> 
> Splitting the assembler over multiple lines shows that it's 
> the push % eax and pop %eax; tried fixing it with pushl and 
> popl but that didn't do the trick. Can 64-bit mode only push 
> 64-bit quantities onto the stack?
> 
> Sincerely,
> 
> Bob

Take a look at this:
http://zebra.fh-weingarten.de/~maxi/html/mplayer-dev-eng/2004-10/msg00349.ht
ml

They mention something about limitations with regard to register usage on
x86_64. 

Jerzu

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

From: Bob D. <bob...@te...> - 2004-11-10 09:24:47

On Wed, 2004-11-10 at 10:04 +0100, Tomek Jerzykowski wrote:
> > The lines in question are:
> > #APP
> >         push %eax; popf; bsf %esi,%esi; pushf; pop %eax #NO_APP
> > 
> > Splitting the assembler over multiple lines shows that it's 
> > the push % eax and pop %eax; tried fixing it with pushl and 
> > popl but that didn't do the trick. Can 64-bit mode only push 
> > 64-bit quantities onto the stack?
> > 
> > Sincerely,
> > 
> > Bob
> 
> Take a look at this:
> http://zebra.fh-weingarten.de/~maxi/html/mplayer-dev-eng/2004-10/msg00349.ht
> ml
> 
> They mention something about limitations with regard to register usage on
> x86_64. 
> 
> Jerzu

That page only seems to mention that there are limitations with the 8
new registers (r8 through r15). I'll have to dive into the
documentation.

Bob

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

From: Gwenole B. <gb...@di...> - 2004-11-11 07:01:30

mercredi 10 novembre 2004, =E0 09:37  am, Bob Deblier a =E9crit :

> The lines in question are:
> #APP
>         push %eax; popf; bsf %esi,%esi; pushf; pop %eax
> #NO_APP

Oh, I see. I hadn't merged this bit from the very old prototype system.=20=

;-)

> Splitting the assembler over multiple lines shows that it's the push %
> eax and pop %eax; tried fixing it with pushl and popl but that didn't=20=

> do
> the trick. Can 64-bit mode only push 64-bit quantities onto the stack?

Yes.

Besides, 64-bit mode doesn't handle sahf/lahf, thus yielding a typical=20=

15% performance decrease when you have to use the pushf/pop variants to=20=

get native flags (noticed on a Pentium 4). Fortunately, upcoming AMD64=20=

processors will now bring sahf/lahf back to 64-bit mode too. But it=20
seems Intel doesn't plan to implement them. i.e. there will be another=20=

bit in some cpuid level to report this support.=

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

From: Tomek J. <to...@je...> - 2004-11-10 08:47:16

> -----Original Message-----
> From: bas...@li...=20
> [mailto:bas...@li...] On Behalf=20
> Of Gwenole Beauchesne
> Sent: Wednesday, November 10, 2004 8:38 AM
> To: bas...@li...
> Subject: Re: [B2-devel] [ANN] Basilisk II JIT snapshot 2004/11/09
>=20
> mercredi 10 novembre 2004, =E0 07:48  am, Bob Deblier a =E9crit :
>=20
> >  Seems this header on its own doesn't know type 'struct sockaddr',=20
> > hence it should include <sys/socket.h> in its test
>=20
> Thanks, fixed in CVS.
>=20
> > Trying to compile after ./configure --with-jit-compiler results in a
> > problem:
>=20
> Could you copy this line (without -o obj/compemu_support.o=20
> and s/-c/-S) so that you cuold actually read the=20
> compemu_support.s generated file?
>=20
> Then, if this is inline assembly code, it may be surrounded=20
> by something like "#NO_APP". Otherwise, it's compiler generated code.
>=20
> > g++ -I../include -I. -I../uae_cpu -DHAVE_CONFIG_H  -DOS_linux -
> > DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DX86_64_ASSEMBLY -=20
> > DOPTIMIZED_FLAGS -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -D_REENTRANT -=20
> > DDATADIR=3D\"/usr/local/share/BasiliskII\" -O2 -I/usr/X11R6/include =
-
> > I/usr/include/gtk-1.2 -I/usr/include/glib-1.2=20
> > -I/usr/lib64/glib/include -I/usr/X11R6/include -fno-merge-constants=20
> > -fno-gcse-sm - c ../uae_cpu/compiler/compemu_support.cpp -o=20
> > obj/compemu_support.o
>=20
> > /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
>=20
> I don't know where it is coming from either. I have no=20
> explicit reference to pushl or pushq as inline assembly.
>=20

When compiling Sheepshaver on x86_64 I'm experiencing similar errors
on FC3 test3 as well. There must be some wierdness here.
A bit of googling reveals that Sheepshaver is not the only one program
that suffers from this. It seems to happen only on x86_64 with the
newest GCC versions. I will investigate more later.

Jerzu

http://www.google.pl/search?q=3D%22Error:+suffix+or+operands+invalid+for+=
%60pu
sh%27%22&hl=3Dpl&lr=3D&start=3D0&sa=3DN

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

From: Bob D. <bob...@te...> - 2004-11-10 09:33:28

A cleaner patch will have to be developed, but the following
modification works for me:

diff -u -r1.24 codegen_x86.cpp
--- codegen_x86.cpp     8 Nov 2004 21:10:46 -0000       1.24
+++ codegen_x86.cpp     10 Nov 2004 09:30:16 -0000
@@ -3834,9 +3834,9 @@
        for (int g_OF = 0; g_OF <= 1; g_OF++) {
        for (int g_SF = 0; g_SF <= 1; g_SF++) {
                for (int value = -1; value <= 1; value++) {
-                       int flags = (g_SF << 7) | (g_OF << 11) | (g_ZF
<< 6) | g_CF;
+                       long long int flags = (g_SF << 7) | (g_OF << 11)
| (g_ZF << 6) | g_CF;
                        int tmp = value;
-                       __asm__ __volatile__ ("push %0; popf; bsf %1,%1;
pushf; pop %0"
+                       __asm__ __volatile__ ("pushq %0; popfq; bsf %1,%
1; pushfq; popq %0"
                                                                  :
"+r" (flags), "+r" (tmp) : : "cc");
                        int OF = (flags >> 11) & 1;
                        int SF = (flags >>  7) & 1;

There'll just have to be an #if #else #endif wrapped around this.

Bob

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

From: Gwenole B. <gb...@di...> - 2004-11-11 07:13:41

Hi,

> A cleaner patch will have to be developed, but the following
> modification works for me:

I have just committed the right fix. Note a long is enough and GAS 
knows about push without suffix. i.e. no need to #ifdef part of the 
code.