Does slime introduce errors into cmucl?
in [Lisp]
|
Prev: AUTHENTIC DESIGNER HANDBAGS & ACCESSORIES WWW.VOGUELANDE.COM CHANEL LOUIS VUITTON
Next: Re^2: slime errors in cmucl?
From: Norbert_Paul on 1 Apr 2010 05:16 Raymond Toy wrote: > This should be available in the 2010-04 snapshot that will be available > soon. Please try this out when you get a chance. > > Thanks, > > Ray Thanks to you. See you on the next bug. Norbert
From: Lieven Marchand on 1 Apr 2010 09:14 Tim Bradshaw <tfb(a)tfeb.org> writes: > On 2010-03-30 22:17:35 +0100, Lieven Marchand said: > >> They still can. Doubles in the FPU registers are 80 bits but are >> typically stored back to memory as 64 bits. So a computation can have >> different results depending on how many of the registers are already in >> use or when and how the compiler decides to store them back. > > This has to be wrong, doesn't it? Are you saying that on x86s the > multiplying two doubles produces results which have essentially random > bits in them? You can tell your compiler to store the full 80 bits. Or as Raymond Toy mentions in this thread, use 64 bits registers. This is a page from a compiler firm that discusses it in more detail: http://www.pgroup.com/support/execute.htm#diff_answers
From: Tim Bradshaw on 6 Apr 2010 06:40 On 2010-04-01 14:14:23 +0100, Lieven Marchand said: > You can tell your compiler to store the full 80 bits. Or as Raymond Toy > mentions in this thread, use 64 bits registers. This is a page from a > compiler firm that discusses it in more detail: Yes, but I don't think any of this means that for the same sequence of instructions on the same initial data (including whatever flags control the extended precision stuff), I will get differing results. I might get results I don't *expect*, but the processor does not dynamically decide whether to use 80-bit or 64-bit registers for the same instructions as far as I can tell. (And indeed it looks as if the underlying problem was CMUCL not saving enough state on interrupts, and (I guess) SLIME generating such interrupts)
From: Norbert_Paul on 6 Apr 2010 08:25 Tim Bradshaw wrote: > On 2010-04-01 14:14:23 +0100, Lieven Marchand said: > (And indeed it looks as if the underlying problem was CMUCL not saving > enough state on interrupts, and (I guess) SLIME generating such interrupts) I suppose that slime interrups (for gc-notification) use floating-point arithmetics thus destroying the corresponding processor state whereas cmucl doesn't, thus accidentally maintainig that sate. This would at least explain why the error doesn't occur on bare cmucl. My problem now is, that I am used to apt-get install prebuilt Debian packages but the fixed cmucl packages seem to differ somewhat from Debian's common-lisp policy. So I don't want to just paste them into my file system. What would a Debian-compliant replacement of cmucl by the latest release look like? Norbert
From: Raymond Toy on 6 Apr 2010 10:02
On 4/6/10 8:25 AM, Norbert_Paul wrote: > Tim Bradshaw wrote: >> On 2010-04-01 14:14:23 +0100, Lieven Marchand said: >> (And indeed it looks as if the underlying problem was CMUCL not saving >> enough state on interrupts, and (I guess) SLIME generating such >> interrupts) > > I suppose that slime interrups (for gc-notification) use floating-point > arithmetics thus destroying the corresponding processor state whereas > cmucl doesn't, thus accidentally maintainig that sate. This would at least > explain why the error doesn't occur on bare cmucl. As Helmet's example shows, it's not the interrupts from Slime. It was the GC hook. This happens because at certain times, GC will happen which causes cmucl to run some C code which will then run Lisp code to handle the GC hooks. But since Lisp doesn't understand this path, the routine that calls the Lisp code needs to save the FP state so that any live FP registers are preserved across the call. Normally the compiler will save any live registers before calling a Lisp function, but the compiler doesn't know about this. (Perhaps it should?) > > My problem now is, that I am used to apt-get install prebuilt Debian > packages > but the fixed cmucl packages seem to differ somewhat from Debian's > common-lisp > policy. So I don't want to just paste them into my file system. > > What would a Debian-compliant replacement of cmucl by the latest release > look like? I don't have a Debian system so I don't know, but is the layout different from what official tarballs from common-lisp.net? (CMUCL's layout is something like <path>/bin/lisp and <path>/lib/cmucl/<more cmucl stuff>.) Maybe you can install the tarballs somewhere and have a simple script call that for now. When there's a Debian update, point the script to the Debian location. Ray Ray |