Menu
▾
▴
basilisk-devel
|
From: Hetz B. H. <he...@wi...> - 2002-01-16 19:21:28
|
> -fno-merge-constants is mandatory with "2.96"-RH/MDK, 3.0-RH/MDK, or FSF > 3.1. Probably due to a bug in the constants merging code. I have yet to > check with the current gcc 3.1 snapshots. Otherwise, B2 indeed crashes. > > Please try with s/-O2/-O0/ and keep -fno-merge-constants. Didn't help, same error. > > > I tried to compile with and without DGA support - same error. > > Sorry, I meant at runtime. ;-) OK ;) > > > Actually, it doesn't work well - I get on the "mac" - "sorry, a system > > error occured. "system" "illegal instruction" > > And on the console: Illegal instruction: 000b at 00034888 > > Thats on the 68030 with FPU, or with 68040. With the 68040 mode I get at > > the console: Illegal instruction: 000b at 0003c9dc > > Hmmm, then probably a cpu core bug. Please try this one: > > In the generated Makefile, change all occurrences of $(OBJ_DIR)/cpuopti > used in any cpufast?.s: rule with a cat. i.e. Don't use the cpuopti pass. I'm affraid I don't understand you well, could you give me an example from what to what to change please? > > > I'm on IRC in irc.kde.org server (on channel #winehq) - feel free to > > contact me and I'll let you in to 1 of my machines if you want to test or > > change B2.. > > Sorry, I have another idea but I really have to go now. Sure, thanks for your assistance. BTW: Any chance that the JIT will be merge into the 1.0 branch? as soon as there will be basilisk II 1.0 (that also works for me) I'll publish it on slashdot - I can promise you that (I'm a slashdot author under the nick HeUnique). ;) Hetz |
|
From: Hetz B. H. <he...@kd...> - 2002-01-16 19:17:48
|
> -fno-merge-constants is mandatory with "2.96"-RH/MDK, 3.0-RH/MDK, or FSF > 3.1. Probably due to a bug in the constants merging code. I have yet to > check with the current gcc 3.1 snapshots. Otherwise, B2 indeed crashes. > > Please try with s/-O2/-O0/ and keep -fno-merge-constants. Didn't help, same error. > > > I tried to compile with and without DGA support - same error. > > Sorry, I meant at runtime. ;-) OK ;) > > > Actually, it doesn't work well - I get on the "mac" - "sorry, a system > > error occured. "system" "illegal instruction" > > And on the console: Illegal instruction: 000b at 00034888 > > Thats on the 68030 with FPU, or with 68040. With the 68040 mode I get at > > the console: Illegal instruction: 000b at 0003c9dc > > Hmmm, then probably a cpu core bug. Please try this one: > > In the generated Makefile, change all occurrences of $(OBJ_DIR)/cpuopti > used in any cpufast?.s: rule with a cat. i.e. Don't use the cpuopti pass. I'm affraid I don't understand you well, could you give me an example from what to what to change please? > > > I'm on IRC in irc.kde.org server (on channel #winehq) - feel free to > > contact me and I'll let you in to 1 of my machines if you want to test or > > change B2.. > > Sorry, I have another idea but I really have to go now. Sure, thanks for your assistance. BTW: Any chance that the JIT will be merge into the 1.0 branch? as soon as there will be basilisk II 1.0 (that also works for me) I'll publish it on slashdot - I can promise you that (I'm a slashdot author under the nick HeUnique). ;) Hetz |
|
From: Gwenole B. <gb...@di...> - 2002-01-16 21:46:27
|
>> In the generated Makefile, change all occurrences of $(OBJ_DIR)/cpuopti >> used in any cpufast?.s: rule with a cat. i.e. Don't use the cpuopti >> pass. > > I'm affraid I don't understand you well, could you give me an example > from > what to what to change please? Sorry, I don't have the Makefile handy but there are rules looking as: cpufast5.s: <dependencies> <generation of cputmp5.s> $(OBJ_DIR)/cpuopti < cputmp5.s >$@ || ... rm -f cputmp5.s Replace $(OBJ_DIR)/cpuopti with a simple "cat" so that cpuopti is not used. Indeed, it could be that cpuopti removes too many instructions nowadays or registers are not properly saved in newcpu/m68k_run_1() before the call to the instruction handler. Anyway, I will probably get rid of cpuopti for B2 1.0 if the JIT compiler were to be integrated. BTW, please also consider the use of gcc3, for example. > BTW: Any chance that the JIT will be merge into the 1.0 branch? There are currently 3 problems (not necessarily JIT-related): - B2/JIT crashes just after the FPU tests from Speedometer 3.x under MacOS 8.x on a Pentium III but not on a K6-2 for example. - The APD (Apple Personal Diagnostics) crash at start in either version of B2 (JIT or non-JIT) and either fpu core (original UAE, "IEEE", x86 optimized) in 68040 emulation mode but not in 68030+FPU. - The problem you are facing right now. :-) Once those are fixed, we can consider the integration. Note that the latest B2/JIT is actually merged with the core from AmigaXL/Amithlon from mid/late December 2001. i.e. probably production-quality. Bye, Gwenole. |
|
From: Hetz B. H. <he...@wi...> - 2002-01-16 22:05:27
Attachments:
Makefile-1.gz
|
> Sorry, I don't have the Makefile handy but there are rules looking as: > > cpufast5.s: <dependencies> > <generation of cputmp5.s> > $(OBJ_DIR)/cpuopti < cputmp5.s >$@ || ... > rm -f cputmp5.s I enclose a gzipped copy of the Makefile after the modification. Could you tell me if I did ok please? > Replace $(OBJ_DIR)/cpuopti with a simple "cat" so that cpuopti is not > used. Indeed, it could be that cpuopti removes too many instructions > nowadays or registers are not properly saved in newcpu/m68k_run_1() > before the call to the instruction handler. > > Anyway, I will probably get rid of cpuopti for B2 1.0 if the JIT > compiler were to be integrated. Oh, please do, from my experience with other emulators that used JIT - it's a great thing... > > BTW, please also consider the use of gcc3, for example. Well, right now I'm in the middle of testing a better kernel for my needs. 2.4.17 sucks when you heavy overload it. Seems like 2.4.18-pre3-ac2 can do the job, still testing... > > BTW: Any chance that the JIT will be merge into the 1.0 branch? > > Once those are fixed, we can consider the integration. Note that the > latest B2/JIT is actually merged with the core from AmigaXL/Amithlon > from mid/late December 2001. i.e. probably production-quality. Oh? I thought that they did heavy optimization and made it proprietary. The Amithlon 68k engine is wildly fast - it's showing like 1Ghz 68040 processor. Do u think your JIT can achive this performance???? Makefile (gzipped) enclosed. Hetz |
|
From: Hetz B. H. <he...@wi...> - 2002-01-16 22:10:52
|
> Makefile (gzipped) enclosed. And I forgot to mention - it still does give the same problem with the Makefile I attached. ./BasiliskII Basilisk II V1.0 by Christian Bauer et al. ScratchMem starts at 0x44617000 (+/- 32 KB) Mac RAM starts at 0x4050f000 (00000000) Mac ROM starts at 0x4450f000 (04000000) Reading ROM file... Using /dev/dsp audio output LMGlob Ofs/4 Base 0x01d4 2 0x50f00000 0x01d8 3 0x50f04000 0x01dc 4 0x50f04000 0x01d8 17 0x50f0c020 0x01dc 17 0x04108000 0x01e0 5 0x50f16000 0x01e0 16 0x50f1e020 0x0b0a 6 0x00000000 0x0312 6 0x04108000 0x0266 7 0x00000000 0x0c00 8 0x50f10000 0x0c04 9 0x50f12000 0x0c08 10 0x50f06000 0x0cec 11 0x50f02000 0x0cc0 12 0x50f14000 0x0cec 13 0x50f26000 0x0c00 15 0x50f18000 0x0c04 15 0x04108000 0x0c08 15 0x04108000 0x0cec 18 0x00000000 do_handle_screen_fault: unhandled address 0x44ae0380 [IP=0x80cea47] D0: 00000000 D1: fffcffff D2: fffffffc D3: 0400000f D4: 0003fffc D5: 00000000 D6: 00000012 D7: 00000000 A0: 0000003c A1: 00000002 A2: 00006bd0 A3: 00006fdc A4: 000067c4 A5: 045d1380 A6: 00000000 A7: 020009a6 USP=00000000 ISP=020009a6 MSP=00000000 VBR=00000000 T=00 S=1 M=0 X=1 N=1 Z=0 V=0 C=0 IMASK=0 FP0: 0 FP1: 0 FP2: 0 FP3: 0 FP4: 0 FP5: 0 FP6: 0 FP7: 0 N=0 Z=0 I=0 NAN=0 0402e8e8: 2815 28c4 c081 c284 8287 MOVE.L (A5),D4 next PC: 0402e8ea Here is my config file: Unix]$ cat /home/hetz/.basilisk_ii_prefs disk /home/hetz/mac-emu/Basilisk_Linux_disk.dsk extfs / screen win/512/384 seriala /dev/ttyS0 serialb /dev/lp0 udptunnel true udpport 6066 rom /home/hetz/mac-emu/quadra.rom bootdrive 0 bootdriver 0 ramsize 67108864 frameskip 6 modelid 14 cpu 3 fpu true nocdrom true nosound false noclipconversion false nogui false keycodes true mousewheelmode 1 mousewheellines 3 Hetz |
|
From: Christian B. <cb...@st...> - 2002-01-17 16:16:05
|
Hi! On Thu, Jan 17, 2002 at 12:10:19AM +0200, Hetz Ben Hamo wrote: > Unix]$ cat /home/hetz/.basilisk_ii_prefs > [...] > modelid 14 Have you tried it with "modelid 5"? Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
|
From: Gwenole B. <gb...@di...> - 2002-01-16 23:10:24
|
> I enclose a gzipped copy of the Makefile after the modification. Could
> you
> tell me if I did ok please?
Hmm, not really. You have:
cpufast5.s: cpuemu.cpp $(OBJ_DIR)/cpuopti
$(CXX) $(CPPFLAGS) $(DEFS) -DPART_5 -S $(CXXFLAGS) $< -o
cputmp5.s
$(OBJ_DIR)/cat <cputmp5.s >$@ || mv cputmp5.s $@
rm -f cputmp5.s
instead of
cpufast5.s: cpuemu.cpp $(OBJ_DIR)/cpuopti
$(CXX) $(CPPFLAGS) $(DEFS) -DPART_5 -S $(CXXFLAGS) $< -o
cputmp5.s
/bin/cat <cputmp5.s >$@ || mv cputmp5.s $@
rm -f cputmp5.s
there is no cat program in the obj/ directory. ;-) then make clean; make
> Oh? I thought that they did heavy optimization and made it proprietary.
Actually, AFAIK, this is still UAE-JIT inside but for QNX. As such,
source has to be provided. H&P actually *removed* an optimization they
say is bogus but without providing a hint at what the problem is
exactly, despite a vague note about ADDI/SUBI.
Their core is based on Bernie's latest snapshot released before he went
on holidays nearly one year ago. Since, there were little bug fixes
(register allocator, shift/rotate instructions).
B2/JIT includes all of that and keeps the above-mentioned optimization
and even other fixes not yet available in Amithlon. e.g. a little fix to
the JIT/FPU code generation on non-P6+ cores, more complete 68040 MOVE16
translations. I keep in touch with Bernie for any updates from him or
myself.
> The Amithlon 68k engine is wildly fast - it's showing like 1Ghz 68040
> processor.
> Do u think your JIT can achive this performance????
I will say the core is basically the same but I won't claim such a
thing. Fact is that it's indeed fast. Speedometer 4.x integer tests on a
Pentium III/800 show performance in between 10x-20x as of a Quadra
605/LC 475 (68040 @ 25 MHz). Other reports showed B2/JIT faster than
Executor too.
Your mileage may vary. However, memory usage is quite huge now. :-/ i.e.
for a 8 MB translation cache size (recommended value), you will need an
extra 8 MB for internal data structures of the JIT engine. Plus, the
usual B2 requirements which are: <RAM size> + <ROM size> + more or less
1 MB for various tables and other scratch memory areas. Yes, that's
fatty and this is unlikely to change.
Bye,
Gwenole (really going to sleep that time)
|
|
From: Gwenole B. <gb...@di...> - 2002-01-16 23:13:10
|
> I enclose a gzipped copy of the Makefile after the modification. Could
> you
> tell me if I did ok please?
Hmm, not really. You have:
cpufast5.s: cpuemu.cpp $(OBJ_DIR)/cpuopti
$(CXX) $(CPPFLAGS) $(DEFS) -DPART_5 -S $(CXXFLAGS) $< -o
cputmp5.s
$(OBJ_DIR)/cat <cputmp5.s >$@ || mv cputmp5.s $@
rm -f cputmp5.s
instead of
cpufast5.s: cpuemu.cpp $(OBJ_DIR)/cpuopti
$(CXX) $(CPPFLAGS) $(DEFS) -DPART_5 -S $(CXXFLAGS) $< -o
cputmp5.s
/bin/cat <cputmp5.s >$@ || mv cputmp5.s $@
rm -f cputmp5.s
there is no cat program in the obj/ directory. ;-) then make clean; make
> Oh? I thought that they did heavy optimization and made it proprietary.
Actually, AFAIK, this is still UAE-JIT inside but for QNX. As such,
source has to be provided. H&P actually *removed* an optimization they
say is bogus but without providing a hint at what the problem is
exactly, despite a vague note about ADDI/SUBI.
Their core is based on Bernie's latest snapshot released before he went
on holidays nearly one year ago. Since, there were little bug fixes
(register allocator, shift/rotate instructions).
B2/JIT includes all of that and keeps the above-mentioned optimization
and even other fixes not yet available in Amithlon. e.g. a little fix to
the JIT/FPU code generation on non-P6+ cores, more complete 68040 MOVE16
translations. I keep in touch with Bernie for any updates from him or
myself.
> The Amithlon 68k engine is wildly fast - it's showing like 1Ghz 68040
> processor.
> Do u think your JIT can achive this performance????
I will say the core is basically the same but I won't claim such a
thing. Fact is that it's indeed fast. Speedometer 4.x integer tests on a
Pentium III/800 show performance in between 10x-20x as of a Quadra
605/LC 475 (68040 @ 25 MHz). Other reports showed B2/JIT faster than
Executor too.
Your mileage may vary. However, memory usage is quite huge now. :-/ i.e.
for a 8 MB translation cache size (recommended value), you will need an
extra 8 MB for internal data structures of the JIT engine. Plus, the
usual B2 requirements which are: <RAM size> + <ROM size> + more or less
1 MB for various tables and other scratch memory areas. Yes, that's
fatty and this is unlikely to change.
Bye,
Gwenole (really going to sleep that time)
|
|
From: Hetz B. H. <he...@wi...> - 2002-01-16 23:23:20
Attachments:
Makefile.gz
|
ARRRRGGGGHHHH! It's still doesn't help - so it's not the optimization part. I don't know if I mention it - but that happends also with the standard 0.9 version (not only with the JIT version)... yet same error... Makefile enclosed. Other suggestions? Hetz |
|
From: Gwenole B. <gb...@di...> - 2002-01-17 09:05:02
Attachments:
configure.in.patch
|
On Thu, 17 Jan 2002, Hetz Ben Hamo wrote: > It's still doesn't help - so it's not the optimization part. Hmmm, looking at the Makefile you provided, you could not rebuild B2 since make would have issued an error for "$/bin/cat" that doesn't exist either. i.e. Replace "$/bin/cat" with "/bin/cat". ;-) Anyway, please try the following instead: $ apply the attached patch $ make distclean $ ./autogen.sh $ make You will get an unoptimized (x86-wide) core. > I don't know if I mention it - but that happends also with the > standard 0.9 version (not only with the JIT version)... yet same > error... Does it also fail in --enable-addressing=banks mode? > Other suggestions? Is it a stock RH-7.2 installation? Bye, Gwenole. |
|
From: Hetz B. H. <he...@wi...> - 2002-01-17 09:55:22
|
> Hmmm, looking at the Makefile you provided, you could not rebuild B2 since > make would have issued an error for "$/bin/cat" that doesn't exist either. > i.e. Replace "$/bin/cat" with "/bin/cat". ;-) ok, me fool ;) After fixing it and retrying B2 - I got the same error. > Anyway, please try the following instead: > $ apply the attached patch > $ make distclean > $ ./autogen.sh > $ make > > You will get an unoptimized (x86-wide) core. And getting the same crash again ;( > > I don't know if I mention it - but that happends also with the > > standard 0.9 version (not only with the JIT version)... yet same > > error... > > Does it also fail in --enable-addressing=banks mode? it boots the Mac, but with immidiate error in the mac which says: sorry, a system error occured. "System" Illegal Instruction On the console I see: Illegal instruction: 000b at 000349cc (in 68030 mode) If I try 68030 with FPU the error in the console is: Illegal instruction: 000b at 00034888 Now - the funny thing is that those errors dissapear if I select MacIIci and the mac boots ok (I'm using the free Mac OS 7.5.3 - no matter what processor I select), but only in "banks" mode. Trying the same trick on normal (with direct mode) build doesn't work. BTW - showing some guys around here a mac IIci emulation running fullscreen 1600x1280 surely made excitement ;) Fullscreen mode gives an error: Gdk-ERROR **: BadMatch (invalid parameter attributes) serial 29 error_code 8 request_code 1 minor_code 0 (although it switches to this mode, then shows the error). > > Other suggestions? > Is it a stock RH-7.2 installation? Yes, with all the latest redhat official 7.2 updates (glibc, fam, etc) As I said yesterday, I'll be happy to let you login to one of my machines for testing, although the link is slow (my ADSL is dead now until our damn telco will fix it). Hetz |
|
From: Gwenole B. <gb...@di...> - 2002-01-17 10:50:39
|
On Thu, 17 Jan 2002, Hetz Ben Hamo wrote: > Now - the funny thing is that those errors dissapear if I select MacIIci and > the mac boots ok (I'm using the free Mac OS 7.5.3 - no matter what processor > I select), but only in "banks" mode. Trying the same trick on normal (with > direct mode) build doesn't work. Indeed, a Mac IIci ROM has to be used with "modelid 5". It works in banks mode because an access to a memory area other than RAM, ROM, Video is a no-op. In direct addressing mode, the sigsegv handler catches it but then crashes. B2 could be modified so that the instruction causing the fault is skipped but this is becoming tricky to deal with other architectures. Another cause is probably in the video code. The blitters are probably still trying to address a region that is reclaimed. Working on a patch to test. > Fullscreen mode gives an error: > Gdk-ERROR **: BadMatch (invalid parameter attributes) > serial 29 error_code 8 request_code 1 minor_code 0 > (although it switches to this mode, then shows the error). Yes, that's another problem I forgot to mention. ;-) > > Is it a stock RH-7.2 installation? > > Yes, with all the latest redhat official 7.2 updates (glibc, fam, etc) > As I said yesterday, I'll be happy to let you login to one of my machines for > testing, although the link is slow (my ADSL is dead now until our damn telco > will fix it). OK, that's something to take under consideration in the event I can't reproduce that on a similar configuration. Have you tried with gcc3 ? Bye, Gwenole. |
|
From: Hetz B. H. <he...@wi...> - 2002-01-17 16:06:30
|
> > Fullscreen mode gives an error: > > Gdk-ERROR **: BadMatch (invalid parameter attributes) > > serial 29 error_code 8 request_code 1 minor_code 0 > > (although it switches to this mode, then shows the error). > > Yes, that's another problem I forgot to mention. ;-) I see... > > > Is it a stock RH-7.2 installation? > > > > Yes, with all the latest redhat official 7.2 updates (glibc, fam, etc) > > As I said yesterday, I'll be happy to let you login to one of my machines > > for testing, although the link is slow (my ADSL is dead now until our > > damn telco will fix it). > > OK, that's something to take under consideration in the event I can't > reproduce that on a similar configuration. Have you tried with gcc3 ? Well, compiling gcc 3.0.3 is not a fun part so much, anyone knows RPMS for gcc 3.0.3 location or something for RH 7.2? Thanks, Hetz |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X