Menu
▾
▴
basilisk-devel
|
From: <gb...@di...> - 2000-10-07 11:58:50
|
Hi, I have placed a JIT-enabled version of BasiliskII at: <http://www.multimania.com/gbeauche/basilisk2/wip/> File: BasiliskII-JIT5.tar.gz Run the ./devconfig script in the Unix directory in order to create the Makefile. Then just type make and enjoy. ;-) I don't know when I will commit in the main B2 source tree since I am rather busy those days and it might still be bug-friendly. Some other optimizations are still possible and I will also have to sync with Bernie's bleeding edge patches from his website. Bye. -- Gwenolé Beauchesne |
|
From: Christian B. <cb...@st...> - 2000-10-08 18:55:59
|
Hi! On Sat, Oct 07, 2000 at 02:08:19PM +0200, Gwenole Beauchesne wrote: > Run the ./devconfig script in the Unix directory in order to create the > Makefile. Then just type make and enjoy. ;-) Hm, at the linking stage I get /usr/lib/libbfd.so: undefined reference to `objjalloc_create' /usr/lib/libbfd.so: undefined reference to `xstrerror' /usr/lib/libbfd.so: undefined reference to `hex_init' /usr/lib/libbfd.so: undefined reference to `concat' /usr/lib/libbfd.so: undefined reference to `_objalloc_alloc' /usr/lib/libbfd.so: undefined reference to `_hex_value' /usr/lib/libbfd.so: undefined reference to `objalloc_free_block' /usr/lib/libbfd.so: undefined reference to `objalloc_free' /usr/lib/libbfd.so: undefined reference to `xexit' collect2: ld returned 1 exit status make: *** [BasiliskII] Error 1 This is with binutils-2.10.0.18-1. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
|
From: <gb...@di...> - 2000-10-08 22:31:48
|
Hi, > Hm, at the linking stage I get > > /usr/lib/libbfd.so: undefined reference to `objjalloc_create' That appears to be from libiberty, probably that my compiler (GCC 2.95.2) automagically added -liberty. Anyhow, I uploaded the JIT-5d version which disables JIT_DEBUG (what bfd was needed for) and improves a little some applications like GraphicConverter through the lazy instruction cache flush method. Bye. -- Gwenolé Beauchesne |
|
From: Christian B. <cb...@st...> - 2000-10-12 14:40:14
|
Hi! On Mon, Oct 09, 2000 at 12:41:26AM +0200, Gwenole Beauchesne wrote: > I uploaded the JIT-5d version which disables JIT_DEBUG Ah yes, it compiles now. It seems somewhat unstable, though. If I set the CPU type to anything other than 68040, all I get is a black window. And even with 68040, I can't get it to complete booting MacOS (tried 7.0.1, 7.5.3 and 7.6.1, with and without extensions). The error messages are various, ranging from "illegal instruction"/ "fpu not installed" MacOS dialog boxes to "Illegal instruction" messages from B2 and segmentation faults. I tried "jitcachesize" values of 128K and 512K (prefs_items.cpp/ AddPrefsDefaults() should set a reasonable default value). Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
|
From: Gwenole B. <gb...@di...> - 2000-10-12 15:31:25
|
Christian Bauer wrote: Hi, > It seems somewhat unstable, though. If I set the CPU type to anything other > than 68040, all I get is a black window. Hmm, that might be because we don't have specialised versions of comp_smalltbls for CPU lower that 68040. i.e. 68040 is always assumed. I will try to fix it soon. > And even with 68040, I can't get it > to complete booting MacOS (tried 7.0.1, 7.5.3 and 7.6.1, with and without > extensions). The error messages are various, ranging from "illegal instruction"/ > "fpu not installed" MacOS dialog boxes to "Illegal instruction" messages from > B2 and segmentation faults. Seems to be due to the lazy flusher :-( I got similar problems while developing it but it did work for me with MacOS 8.1. I should have tried with earlier versions of MacOS... Try to disable the lazy flusher in compemu.h by setting ENABLE_SOFT_FLUSH to 0. > I tried "jitcachesize" values of 128K and 512K (prefs_items.cpp/ > AddPrefsDefaults() should set a reasonable default value). The value I use is the minimal cache size value used for the DR-emulator from Apple, that is to say 256 KB. I think it's reasonnable but higher values will get better performance with the lazy flusher while no gain is accomplished otherwise. Thanks Christian for all those reports. I think I will make publicly available some builds before commiting to the CVS. Bye. |
|
From: <gb...@di...> - 2000-10-12 17:39:37
|
Hi, > Seems to be due to the lazy flusher :-( I got similar problems while > developing it but it did work for me with MacOS 8.1. I should have tried > with earlier versions of MacOS... I have just tried with MacOS 7.1.2 and the lazy flusher in 68040 mode. It still works. I should read again the compiler... BTW, could someone with a PentiumII-class cpu compile and try the program at: <http://www.multimania.com/gbeauche/basilisk2/wip/> File: cmov_test.c And tell me if it actually shows up "Your CPU does support CMOV." ? Thanks. -- Gwenolé Beauchesne |
|
From: Christian B. <cb...@st...> - 2000-10-12 20:02:10
|
Hi! On Thu, Oct 12, 2000 at 07:49:21PM +0200, Gwenole Beauchesne wrote: > BTW, could someone with a PentiumII-class cpu compile and try the > program at: <http://www.multimania.com/gbeauche/basilisk2/wip/> > File: cmov_test.c I've tried it on a Pentium II/Deschutes (where it reports "yes", as on a PIII and Athlon) and on a K6-II (where it reports "no"), consistent with what /proc/cpuinfo says. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
|
From: Christian B. <cb...@st...> - 2000-10-12 20:30:16
|
Hi! On Thu, Oct 12, 2000 at 05:31:19PM +0200, Gwenole Beauchesne wrote: > I got similar problems while developing it but it did work for me with > MacOS 8.1. I should have tried with earlier versions of MacOS... Hey, 7.6.1 is the best version of MacOS ever! :-) > Try to disable the lazy flusher in compemu.h by setting > ENABLE_SOFT_FLUSH to 0. That did it! The performance is very impressive. In "Julia's Dream" there are some artifacts in the display, though (mostly in the window center). Looks like an arithmetic sign or flag is miscalculated somewhere. > I think I will make publicly available some builds before commiting to the > CVS. BTW: Can the USE_MAPPED_MEMORY and related stuff be removed? This would clean up the code a little. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
|
From: <gb...@di...> - 2000-10-12 21:32:44
|
Hi, > Hey, 7.6.1 is the best version of MacOS ever! :-) Indeed, I have been told that but I directly jumped from 7.5.x to 8.x so I missed that one ;-) > > Try to disable the lazy flusher in compemu.h by setting > > ENABLE_SOFT_FLUSH to 0. > > That did it! The performance is very impressive. You know, I always wanted to have BasiliskII at least faster than my real Quadra 630 under my little AMD K6-2/300 powered Linux box. ;-) How much faster do you think it is ? Among my quick tests with Speedometer, Apple Personal Diagnostics, and Graphic Converter, I can say that on the average, it is only twice as fast as Fusion 3.0 in dos mode :-( BTW, do you still intend to add some emul_ops for QuickDraw acceleration ? > In "Julia's Dream" there are some artifacts in the display, though (mostly > in the window center). Looks like an arithmetic sign or flag is > miscalculated somewhere. After having read gencpu.c, I noticed a possible bug with CAS and CAS2 instructions when the noflags handler comes to be used. In any case, it should set the flags because Z flag for example is used to determine where to write the result (put_long / dreg ?). Bernie has now fixed it in his source tree and I will probably do the same on next weekend. Good news: Bernie implemented some FPU instructions for the JIT. > BTW: Can the USE_MAPPED_MEMORY and related stuff be removed? This would > clean up the code a little. Yes, I don't need it. Eventually, the configure script will test the possibility of mmap() if neither direct or real addressing is used (mmap is already tested for in those modes). mmap() is "mandatory" because malloc() probably isn't guaranteed to set the EXECutable bit for the allocated region. Actually, I would have liked to use the USE_COMPILER macro and the compiler.cpp file name. Less files, shorter names, that's good ;-) BTW: last time I tried, real addressing didn't work with the compiler. mem_banks should still work but I think they consume too much cpu power. I noticed you also had problems with VOSF under NetBSD/m68k. In video_blit.h, does replacing the Duff's Device based blitter with a dumb loop copying byte per byte, do any good ? If not, I really don't know where the problem could be from. Bye. -- Gwenolé Beauchesne |
|
From: Christian B. <cb...@st...> - 2000-10-13 14:03:29
|
Hi! On Thu, Oct 12, 2000 at 11:42:22PM +0200, Gwenole Beauchesne wrote: > How much faster do you think it is ? If I believe the Speedometer tests, it's 4 times faster than the non-JIT version. Somewhat like a 100MHz PPC 601 on this PIII/500. > BTW, do you still intend to add some emul_ops for QuickDraw acceleration ? Yes, but that would require a non-refreshed video mode, which is hard to come by these days... > [Julia's Dream] > After having read gencpu.c, I noticed a possible bug with CAS and CAS2 > instructions when the noflags handler comes to be used. Julia's Dream doesn't use CAS, but it uses BFEXTS and the V flag. Might these be a problem? > I noticed you also had problems with VOSF under NetBSD/m68k. In > video_blit.h, does replacing the Duff's Device based blitter with a dumb > loop copying byte per byte, do any good ? I will try that. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
×
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