You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
(42) |
Oct
(17) |
Nov
(7) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(14) |
Feb
(8) |
Mar
(13) |
Apr
(10) |
May
(28) |
Jun
(28) |
Jul
(23) |
Aug
(7) |
Sep
(2) |
Oct
(24) |
Nov
(9) |
Dec
(2) |
2002 |
Jan
(58) |
Feb
(15) |
Mar
(57) |
Apr
(26) |
May
(7) |
Jun
|
Jul
(10) |
Aug
|
Sep
(19) |
Oct
(9) |
Nov
(6) |
Dec
(4) |
2003 |
Jan
(4) |
Feb
(1) |
Mar
(3) |
Apr
(5) |
May
(14) |
Jun
(3) |
Jul
(7) |
Aug
(4) |
Sep
(7) |
Oct
(4) |
Nov
(11) |
Dec
(3) |
2004 |
Jan
(32) |
Feb
(21) |
Mar
(3) |
Apr
(11) |
May
(33) |
Jun
(42) |
Jul
(46) |
Aug
(2) |
Sep
(3) |
Oct
|
Nov
(42) |
Dec
(23) |
2005 |
Jan
(5) |
Feb
(2) |
Mar
(12) |
Apr
(26) |
May
(8) |
Jun
(18) |
Jul
(21) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
(10) |
Dec
(1) |
2006 |
Jan
(17) |
Feb
(17) |
Mar
(3) |
Apr
(2) |
May
(2) |
Jun
(7) |
Jul
(6) |
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(7) |
Dec
(4) |
2007 |
Jan
(6) |
Feb
(4) |
Mar
|
Apr
(3) |
May
(7) |
Jun
(17) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
(5) |
2008 |
Jan
(14) |
Feb
(2) |
Mar
(2) |
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2009 |
Jan
(2) |
Feb
(22) |
Mar
(3) |
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
(15) |
Sep
|
Oct
(32) |
Nov
(9) |
Dec
|
2010 |
Jan
(18) |
Feb
(2) |
Mar
(14) |
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(7) |
Sep
(6) |
Oct
(35) |
Nov
(4) |
Dec
|
2011 |
Jan
(4) |
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
(9) |
Oct
|
Nov
|
Dec
(4) |
2012 |
Jan
(4) |
Feb
|
Mar
(8) |
Apr
(9) |
May
|
Jun
(176) |
Jul
(86) |
Aug
(20) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
(4) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2016 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
(13) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(11) |
Aug
|
Sep
(5) |
Oct
(2) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
From: Christian B. <cb...@st...> - 2000-09-04 18:00:43
|
Hi! A web interface to the B2 (and others) CVS is now available on http://down.physik.uni-mainz.de/cgi-bin/cvsweb.cgi Among other features, it provides a really nice way to view the differences between file revisions. Also, I've upgraded the version of CVS running on the server to 1.10.8. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
From: Christian B. <cb...@st...> - 2000-09-04 17:15:52
|
Hi! On Sun, Sep 03, 2000 at 11:16:49PM +0200, Gwenole Beauchesne wrote: > > 1. Ability to directly access the Mac address space > > Implemented. And indeed, what a nice piece of improvement: near twice > the speed! Cool! > 4. Reversed Address Space > [...] > Note however that I didn't checked all the patches for "correctness" > yet, especially audio that makes strange sounds. It may not be obvious, but part of the intention behind the Mac2Host_memcpy() etc. functions in cpu_emulation.h was to allow for a reversed address space. It's not used consequently in all modules, however. > I was hinted that a real m68k does not handle unaligned access, does it ? Starting with the 68020, all 680x0 can access any data at any alignment (except for the 68060 which needs operating system support under certain circumstances). > Another problem with reversed address space arises with the use of > direct addressing when patching the ROM since PatchROM() relies on a > native m68k byte-order. Yes, that's because the WriteMac*() functions may not yet be operational at PatchROM() time. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
From: Christian B. <cb...@st...> - 2000-09-04 17:02:54
|
Hi! On Sun, Sep 03, 2000 at 01:26:06PM +0200, Gwenole Beauchesne wrote: > (a) In order to mmap() correctly the address space in VideoInit(), I > would like to know what is the current ROMBaseMac. This is currently not > possible since VideoInit() is executed before Init680x0(). I think the complete part in uae_cpu/basilisk_glue.cpp, lines 59..82 (#if REAL_ADDRESSING .. #endif) could be moved into main.cpp/InitAll(), after the call to CheckROM() has been made. > (b) In order to get a chance to mmap() the address space as > above-mentioned, MacRAM would not get allocated before VideoInit() is > executed. This is harder. I placed VideoInit() at the latest possible point in the initialization order because it may switch to a screen mode where it's no longer possible to put up dialog boxes for error messages from modules that are initialized earlier. > (d) Due to the different frame layout that could be used, I implemented > video handling on SIGSEGV (see below). Drawback: DGA mode will be slower > since a temp frame buffer will have to be used too. But the whole point of DGA mode is to avoid a temporary frame buffer... > i.e. the hack is: > void Screen_fault_handler(int, struct sigcontext scs) > { > uint32 faultive_address = scs.cr2; I'm using a similar method to access the CPU registers in the native NetBSD/m68k version. Unfortunately, NetBSD doesn't seem to support siginfo_t. > TC flush will occur when: > - Code is created and executed from Execute68k(), Execute68kTrap() > - FlushCodeCache() is called > - A-Traps: FlushCodeCacheRange, FlushInstructionCache > - BlockMove() Why is this not simply done every time a MOVEC *,CACR or CPUSH is executed to clear the emulated 680x0's caches? > 4. I don't want to break the CVS tree ;-) > I don't really have a "port" so I don't know what I can change in fact. If you are convinced that it will still work on non-x86 machines and other operating systems (including NetBSD/m68k, where it runs without CPU emulation), you can check it in. > Actually, I never used CVS There's a nice tutorial at http://www-classic.be.com/aboutbe/benewsletter/volume_III/Issue40.html#Insight > Should I make it the default one when an i386 cpu is detected ? If it's an improvement, then yes. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
From: <gb...@di...> - 2000-09-03 21:08:21
|
Hi, > I am in the process of porting the new UAE JIT Compiler for Linux/x86. > For that purpose, I need a few information and arrangements. ;-) > > 1. Ability to directly access the Mac address space > ------------------------------------------------ > > For faster performance and actually simpler porting, I want BasiliskII > being able to directly access the Mac address space only through one > offset. Implemented. And indeed, what a nice piece of improvement: near twice the speed! TODO: - handle DGA modes - handle siginfo_t - make other blitters than RGB555_RGB565 (either big or little endian versions). [In fact, other layouts than 16-bit on a little-endian machine would just require a byteswapping] - clean up before committing (?) - reversed address space (see below) 4. Reversed Address Space ---------------------- I had some success with reversed address space and the memory banking method although the gain was not that impressive (~5%, as expected) except for FPU-related operations (~30%, !?). <http://www.multimania.com/gbeauche/basilisk2/wip/> File: BasiliskII_RAS.tar.gz The diffs can be easily found since I prefixed them with "ras--" into comments. The key functions were: - RAS_Mac2HostAddr_Reverse(addr, n) return the translated address of the block freshly reversed - RAS_Mac2HostAddr(addr, n) return the translated address correctly offset - RAS_Reverse(addr, n) reverse the specified region of memory Those functions are defined in cpu_emulation.h Note however that I didn't checked all the patches for "correctness" yet, especially audio that makes strange sounds. Now I know this method can work and could actually be beneficial (?) if we use direct memory accessing, I wonder how hard it would be to make clean changes into the base source tree. A more clever way has to be found if one would like to easily experiment another addressing method: Byte-swapped Address Space, that will work well provided that unaligned accesses don't occur. I was hinted that a real m68k does not handle unaligned access, does it ? Another problem with reversed address space arises with the use of direct addressing when patching the ROM since PatchROM() relies on a native m68k byte-order. As I used memory banks, I could bypass this problem because I had specialised accessors that would handle ROM read/writes either in a reversed fashion or in the standard way. i.e. First, the ROM is left unreversed and accessors don't handle reversal. Then, after PatchROM() is executed (say Start680x0), the ROM is reversed and the new handlers are set. Since changing (with use of Read/WriteMacIntXX) rom_patches.cpp to handle direct memory accessing and reversed address space would require too much work, a simple solution would be to wrap the (uintXX *) that is used to iterate over the ROM, into an object that will do the job. e.g. uint16 * wp = <something>; would be translated into: rom_word_ptr wp = <something>; rom_word_ptr would have proper operator overloading. If that does not suffice, operator * could also return a helper-object that will do the byteswapping, if required. -- Gwenolé Beauchesne |
From: <gb...@di...> - 2000-09-03 11:17:39
|
Hi, I am in the process of porting the new UAE JIT Compiler for Linux/x86. For that purpose, I need a few information and arrangements. ;-) 1. Ability to directly access the Mac address space ------------------------------------------------ For faster performance and actually simpler porting, I want BasiliskII being able to directly access the Mac address space only through one offset. i.e. as Lauri did for Windows NT: ROMBaseMac - RAMBaseMac == ROMBaseHost - RAMBaseHost VIDBaseMac - ROMBaseMac == VIDBaseHost - ROMBaseHost Implementation: the main trouble will come from the Mac Frame Buffer. (a) In order to mmap() correctly the address space in VideoInit(), I would like to know what is the current ROMBaseMac. This is currently not possible since VideoInit() is executed before Init680x0(). I am not willing to duplicate code. (b) In order to get a chance to mmap() the address space as above-mentioned, MacRAM would not get allocated before VideoInit() is executed. MacROM will possibly have to be relocated later. (c) The relocation may fail. i.e. the address space could not be allocated as above-mentioned. BasiliskII will have to quit. (d) Due to the different frame layout that could be used, I implemented video handling on SIGSEGV (see below). Drawback: DGA mode will be slower since a temp frame buffer will have to be used too. 2. Video on SIGSEGV signals ------------------------ The idea is to make the frame buffer write-protected. Then, when a SEGV occurs, the protection is released but the page number is kept so that the pages to redraw could be found quickly. When redrawing occurs, pages are write-protected back. I am using a Linux 2.2.5 kernel and retrieving the address that caused the violation is hacky. Reading from the kernel sources, I guessed that address would be kept in particular location of the stack when the signal handler is run. i.e. the hack is: void Screen_fault_handler(int, struct sigcontext scs) { uint32 faultive_address = scs.cr2; ... } The Video on SEGV method is portable provided that the host system supports siginfo_t for signal handlers (such as Solaris or newer 2.3.x and 2.4.x Linux kernels). i.e. the si_addr address field will contain the address that caused the violation. This method provides faster screen updates though that was not the intended purpose. That purpose was to copy to the host frame buffer and make the necessary color conversions when redrawing the regions that changed. e.g. RGB 555 -> BGR 565. 3. Translation cache flush rules ----------------------------- The rules are a little different than for UAE. TC flush will occur when: - Code is created and executed from Execute68k(), Execute68kTrap() - FlushCodeCache() is called - A-Traps: FlushCodeCacheRange, FlushInstructionCache - BlockMove() Please complete the above list if necessary. Notes: - The translation cache does not necessarily have to be flushed completely. - Correct flush rules are needed if one doesn't want to checksum the entire block each time. - M68K_EXEC_RETURN has to be made an end-block marker. Ideally, it would be best to have it right into the table68k. 4. I don't want to break the CVS tree ;-) ---------------------------------- I don't really have a "port" so I don't know what I can change in fact. I implemented (2) in video_x.cpp except support of siginfo_t and DGA changes when direct memory will be implemented. It is conditioned on through the ENABLE_VIDEO_ON_SEGV macro-def. I don't have a better name, so please tell me if you have a better one. I intend to make direct memory access conditioned through the ENABLE_DIRECT_ADDRESSING macro-def. Here again, I am open to any other suggestion. Actually, I never used CVS but I would like to try to commit the port I made from Lauri's FPU code. Should I make it the default one when an i386 cpu is detected ? A check for GCC will be required as well. -- Gwenolé Beauchesne |
From: <gb...@di...> - 2000-09-03 07:56:21
|
Hi, > I just grepped all the compiler include files with "float80" and > "quadruple" -- no [relevant] hits. But it's always possible that > I'm missing something. The compiler may handle tokens starting with "__" internally. I am sorry but I don't have VC++ documentation. BTW, CodeWarrior only has 64-bit long doubles as well. > >I think that an implementation claiming IEEE-754 compliance would have > >adequate float and double type representations. long doubles could also > >be 128-bit long. > > Yes ... strictly speaking it's compliant, but adequate? Not for > our purposes at least :) Reading the C standard again, I came up with <fenv.h> which gives access to the floating-point environment. Something to explore further. i.e. check if the implementation provides fenv_t, fexcept_t, FE_INEXACT, ... Problem: that doesn't appear to be part of the C++ standard but using C from C++ is not a problem ;-) Another problem: all C implementations may not provide those features yet. CodeWarrior appears to support that. GCC and an old glibc 2.0.x doesn't but it seems that glibc 2.1.x will (?). -- Gwenolé Beauchesne |
From: Lauri P. <lpe...@ni...> - 2000-08-19 01:52:45
|
On Sat, 19 Aug 2000 04:44:16 +0300, you wrote: >if( value < -32768.0 || value > 32767.0 ) { > ... set the INEXACT flag >} else { > put_word(ad, (uae_s16) value); >} Second try: if( value < -32768.0 || value > 32767.0 ) { // Overflow: ... set the ACCR_IOP flag } else { put_word(ad, (uae_s16) value); if( (double)(uae_s16)value != value ) { // Inexact ... set the INEXACT flag } } Lauri |
From: Lauri P. <lpe...@ni...> - 2000-08-19 01:38:47
|
On Wed, 16 Aug 2000 14:52:08 +0200 (CEST), Christian wrote: >It has been hinted to me that the problem is the loading of unnormalized >80-bit floats which is supported by Motorola FPUs but not Intel ones. Another important thing is the accrued exception byte. It does not contribute to the scroll bars problem, but the library math functions. I had a tester code in CodeWarrior, [floating point=Library, 8-Byte doubles]: int exponent; double d4 = frexp(3.5,&exponent); // Should return: 0.875, 2 There is code like this in Pack5 resource "Elems68k" (the comments are from a test run of the C code above): FMOVE.X (A7)+,FP3 ;FP3 = 0.8074 MOVEQ #$00,D4 ;D4 = 0 FMOVE FPSR,D1 ;D1 = 0 (0.8074 status flags) MOVE.L #$0F000000,D2 ;D2 = 0x0F000000 (condition mask) MOVE.L D1,D3 ;D3 = 0 AND.L D2,D3 ;D3 = 0.8074 condition code byte LSL.L #$5,D3 ;D3 MSBs = 0 (Z,I,NAN) AND.L D2,D0 ;D0 = 0 (entry condition code byte) LSL.L #$5,D0 ;D3 MSBs = 0 (Z,I,NAN of entry) BNE.S Anon6+$0010 ;No jump BCS.S Anon6+$0010 ;No jump, C would be set on N flag TST.L D3 ;D3 0 BNE.S Anon6+$0010 ;No jump FMOVE.W FP3,D2 ;D2 = 1?? FMOVE FPSR,D1 ;D1 = 0 BCLR #$07,D1 SNE D2 ;Set if not equal; D2=0 FMOVE D1,FPSR ;D1 = 0 BTST #$03,D1 ;Test bit 3, INEXACT SNE D0 ;D0 = 0 (is not INEXACT) So the line "FMOVE.W FP3,D2" should set the ACCR_INEX flag. In the original fpu code, this means that in put_fp_value() the put_word() call should set the INEXACT flag if the "value" overflows. In the Windows port I'm doing: put_word(ad, extended_to_signed_16(value)); where extended_to_signed_16() (assembly) sets the exception flags if appropriate. In a non-assembly version, this could be replaced by (untested): // strictly speaking, rounding modes should be honored too :) // Say, 32767.5 may ot may not cause the flag. if( value < -32768.0 || value > 32767.0 ) { ... set the INEXACT flag } else { put_word(ad, (uae_s16) value); } For me it was a surprise that the floating point exceptions are disabled but the ROM was still using the exception flags. But why not. Lauri |
From: Lauri P. <lpe...@ni...> - 2000-08-19 01:38:44
|
On Thu, 17 Aug 2000 00:48:03 +0200, Gwenolé wrote: >BTW, I am surprised MSVC++ doesn't provide its own long double type >(80-bit long). Really nothing like __float80, __quadruple ? Not that I know of. There were 80 bits long doubles in the old 16-bit version of the compiler, but for some reason this support was dropped. I just grepped all the compiler include files with "float80" and "quadruple" -- no [relevant] hits. But it's always possible that I'm missing something. >I think that an implementation claiming IEEE-754 compliance would have >adequate float and double type representations. long doubles could also >be 128-bit long. Yes ... strictly speaking it's compliant, but adequate? Not for our purposes at least :) Lauri |
From: Christian B. <cb...@st...> - 2000-08-17 15:31:15
|
Hi! On Thu, 17 Aug 2000, Gwenole Beauchesne wrote: > PPS: Christian, would it be possible to tell the mailing-list manager > (or whatsoever) to automatically add a Reply-To: <this_list> field ? This should be done now. I also like it better that way. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
From: <gb...@di...> - 2000-08-16 22:40:08
|
Hi, > Yes, the CVS sources still have that problem. I applied Lauri's changes to > uae_cpu/fpp.cpp, but nothing more. I have just tried to remove the assembly type conversion functions, especially (only in fact) to_single() and restore the original one in C from uae_cpu/fpp.cpp. Scrollbars stopped to work again. The problem is that there is no check for NaN, Inf and Zero. So, if the exponent is set to the maximum (possibly a NaN of Inf), doing exponent + FP_DOUBLE(or EXTENDED)_EXP_BIAS - FP_SINGLE_EXP_BIAS without extra tests is not correct. I fixed it by assigning each part of the floating-point value through a fp_single_shape type (32-bit float). Maybe something like hereunder mentioned would work as well: function::to_single() union { fp_single as_single; uae_u32 as_uint32; } fp_loader; fp_loader.as_uint32 = byteswap(value); return (fp_extended)fp_loader.as_single; Hmm, actually, I tried to apply it on the CVS sources, this didn't work. But it does with my current changes in fpu_ieee.cpp. i.e. only to_single() is reimplemented in C++. BTW, I also got inspired from binutils-2.x.x/libiberty/floatformat.c. Unfortunately, the diffs I tried did not work... PS: I reuploaded the file fpu_ieee.cpp on my website. PPS: Christian, would it be possible to tell the mailing-list manager (or whatsoever) to automatically add a Reply-To: <this_list> field ? Thanks. -- Gwenolé Beauchesne |
From: <gb...@di...> - 2000-08-16 22:40:07
|
Hi Lauri, > It's really great if you can do everything without assembly, but > some compilers (for example mine) have a fake long double, it's > the same as double. Yes, actually the standard just says that "the type double provides at least as much precision as float, and the type long double provides at least as much precision as double." ;-) BTW, I am surprised MSVC++ doesn't provide its own long double type (80-bit long). Really nothing like __float80, __quadruple ? I think that an implementation claiming IEEE-754 compliance would have adequate float and double type representations. long doubles could also be 128-bit long. I wonder if some checks could be done at ./configure time... An alternative is still the implementation with hand-coded float types as with the FPE from NetBSD/m68k. That's a lot of work. I would prefer working on a faster m68k core or a PPC core ;-))) -- Gwenolé Beauchesne |
From: Christian B. <cb...@st...> - 2000-08-16 12:52:10
|
Hi! On Tue, 15 Aug 2000, Gwenole Beauchesne wrote: > Scrollbars now work with the generic FPU core. The problem looks like > what I was suspecting: floating-point precision. It has been hinted to me that the problem is the loading of unnormalized 80-bit floats which is supported by Motorola FPUs but not Intel ones. > no differences and scrollbars don't work with the freshly compiled CVS > sources, do they ? Yes, the CVS sources still have that problem. I applied Lauri's changes to uae_cpu/fpp.cpp, but nothing more. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
From: Lauri P. <lpe...@ni...> - 2000-08-15 01:32:14
|
Hi Gwenolé, It seems that I have not updated the uae\fpp.cpp file with some [portable] changes. At least the to_exten() re-normalization code that is found in uae_windows\fpu.cpp has some subtle but important fixes. Just in case you didn't notice, I have not looked into your new code yet. Lauri |
From: Lauri P. <lpe...@ni...> - 2000-08-15 00:11:05
|
>The standard does not (I'd guess it can't) specify what is the >true accuracy of the long double. Oops, sorry -- that's of course exactly what you said before. I should not write in a hurry. Lauri |
From: Lauri P. <lpe...@ni...> - 2000-08-14 23:59:55
|
On Tue, 15 Aug 2000 01:22:03 +0200, you wrote: Hi Gwenolé, >- The long double type is part of the C++ standard. Any compliant >compiler should know about it. The problem is that I make heavy >assumptions about its data representation: IEEE-854. i.e. a 96-bit long >double, what the C++ standard does not guarantee. It's really great if you can do everything without assembly, but some compilers (for example mine) have a fake long double, it's the same as double. The standard does not (I'd guess it can't) specify what is the true accuracy of the long double. Lauri |
From: <gb...@di...> - 2000-08-14 23:14:13
|
Hi, Scrollbars now work with the generic FPU core. The problem looks like what I was suspecting: floating-point precision. I am using long doubles if and only if they are 96-bit long (detected by the configure script). ## Reasons why I think it was a precision-related problem - I took the original fpp.cpp from BasiliskII 13/07/2000 and made necessary changes to support uae_f96. Note however that type conversion functions like to_single(), from_exten(), used X86 assembly. At this time, scrollbars were still not working. - I then applied Lauri's changes from his fpp.cpp (not fpu.cpp from the Windows directory). It worked. So what ? -> Making diffs from Lauri's fpp.cpp and from the one in the CVS shows no differences and scrollbars don't work with the freshly compiled CVS sources, do they ? -> I applied all changes from Lauri's fpp.cpp but enhanced them with long doubles. Scrollbars work. ## Last notes. - The long double type is part of the C++ standard. Any compliant compiler should know about it. The problem is that I make heavy assumptions about its data representation: IEEE-854. i.e. a 96-bit long double, what the C++ standard does not guarantee. - IMHO, #include <cmath> (not <math.h>) is mandatory because it provides long double overloaded functions. The recent C99 standard however, now supports long doubles (if available) and functions taking long doubles in parameters are suffixed with 'l'. e.g. atanl(). - Testing for NaN, Infinities and such things could be done with standard C (C99) functions, if available. e.g. isnan(), isinf(). <http://www.multimania.com/gbeauche/basilisk2/wip/> File: fpu_ieee.cpp ## Todo - beautifying - generic type conversions instead of i386 assembly - update exception and accrued exception bytes (probably do a megamix from Linux/m68k math-emu code) -- Gwenolé Beauchesne |
From: Christian B. <cb...@st...> - 2000-08-14 13:26:20
|
Hi! On Sun, 13 Aug 2000, Gwenole Beauchesne wrote: > I accomodated Lauri's FPU emulation to meet GCC's inline assembly > syntax. Way to go! > Quick diffs: > - configure.in: --enable-new-fpu-core, defaults to yes Maybe it should only default to "yes" on i386 systems... > PS: is it me or there was no traffic on this list since its creation ? > ;-) "First post" :-) Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ |
From: <gb...@di...> - 2000-08-13 16:15:09
|
Hi, I accomodated Lauri's FPU emulation to meet GCC's inline assembly syntax. The way I used GCC's extended asm features for the X86 FPU is probably not the Right Way. Please report me any error. BTW, I only tested it with Speedometer 3.X and 4.X and Apple Personal Diagnostics. Scrollbars work as well. A patch over BasiliskII v0.8-13/07/2000 sources is available at: <http://www.multimania.com/gbeauche/wip/basilisk2/wip/> File: patch_fpu_x86.gz (36 KB) Quick installation notes: gzip -dc patch_fpu_x86.gz | patch -p0 Quick diffs: - configure.in: --enable-new-fpu-core, defaults to yes - uae_cpu/fpu_x86.{h,cpp} Todo: - propagate the diffs to the main sources -> looks like it will need real32, real64 and real96 types... PS: is it me or there was no traffic on this list since its creation ? ;-) -- Gwenolé Beauchesne |