From: Sergey C. <sch...@oc...> - 2008-11-07 02:31:16
|
Hi, Trying to compile sbcl for PowerPC platform. It is actually PPC405EX processor. It compiles just fine but crashes in src/runtime/ppc-assem.S trying to call 'stfd ...' assembler command at initialization stage. This thing suppose to save floating point register to stack frame. The problem is that ppc405 does not have fp instructions. I tried to replace SAVE_FPR() and RESTORE_FPR() macros with nop's but then it fails at line 352 in src/runtime/ppc-assem.S when exiting from 'call_into_lisp' function with corrupted stack. Is there any good way to compile sbcl for ppc without HW floating point support or is there correct way to modify src/runtime/ppc-assem.S to avoid floating point instructions and have valid stack frame. Thanks. |
From: Brian M. <br...@ma...> - 2008-11-07 02:38:31
|
On Nov 6, 2008, at 8:31 PM, Sergey Chernikov wrote: > Hi, > Trying to compile sbcl for PowerPC platform. It is actually PPC405EX > processor. It compiles just fine but crashes in src/runtime/ppc- > assem.S > trying to call 'stfd ...' assembler command at initialization stage. > This thing suppose to save floating point register to stack frame. The > problem is that ppc405 does not have fp instructions. > > I tried to replace SAVE_FPR() and RESTORE_FPR() macros with nop's but > then it fails at line 352 in src/runtime/ppc-assem.S when exiting from > 'call_into_lisp' function with corrupted stack. > > Is there any good way to compile sbcl for ppc without HW floating > point > support or is there correct way to modify src/runtime/ppc-assem.S to > avoid floating point instructions and have valid stack frame. I don't think anyone's ever tried to remove floating-point from SBCL, likely because this would result in a non-conforming Common Lisp implementation. Have you considered turning on floating point emulation in your Linux kernel? This should allow SBCL to function on your 405EX-based system. -- Brian Mastenbrook br...@ma... http://brian.mastenbrook.net/ |
From: Brian M. <br...@ma...> - 2008-11-07 02:44:34
|
On Nov 6, 2008, at 8:38 PM, Brian Mastenbrook wrote: > I don't think anyone's ever tried to remove floating-point from SBCL, > likely because this would result in a non-conforming Common Lisp > implementation. Just to clarify, I meant that removing floating point support entirely would be problematic, not that using software floating point would be wrong. -- Brian Mastenbrook br...@ma... http://brian.mastenbrook.net/ |
From: Nathan F. <fr...@gm...> - 2008-11-07 02:39:53
|
On Thu, Nov 6, 2008 at 9:31 PM, Sergey Chernikov <sch...@oc...> wrote: > Is there any good way to compile sbcl for ppc without HW floating point > support or is there correct way to modify src/runtime/ppc-assem.S to > avoid floating point instructions and have valid stack frame. Nope; SBCL currently relies on having hardware floating-point available. There's no software floating-point support. Storing random bits into those stack frame locations might let you get a bit further, but doing virtually anything numeric (maybe even compiling things--not sure) is going to execute hardware FP instructions and crash your program. -Nathan |
From: Sergey C. <sch...@oc...> - 2008-11-07 02:45:53
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> As far as I understand the problem there is no issue about floating point itself. SBCL will have floating point as it supposed to, even c code sbcl is compiling from may have floating point instructions. It's all Ok and will work as long as gcc is aware of that. <br> My guess is that problem is in asm file with explicit fp instructions. If I will be able to get rid of them and have healthy stack frame it should work just fine.<br> <br> Nathan Froyd wrote: <blockquote cite="mid:280...@ma..." type="cite"> <pre wrap="">On Thu, Nov 6, 2008 at 9:31 PM, Sergey Chernikov <a class="moz-txt-link-rfc2396E" href="mailto:sch...@oc..."><sch...@oc...></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Is there any good way to compile sbcl for ppc without HW floating point support or is there correct way to modify src/runtime/ppc-assem.S to avoid floating point instructions and have valid stack frame. </pre> </blockquote> <pre wrap=""><!----> Nope; SBCL currently relies on having hardware floating-point available. There's no software floating-point support. Storing random bits into those stack frame locations might let you get a bit further, but doing virtually anything numeric (maybe even compiling things--not sure) is going to execute hardware FP instructions and crash your program. -Nathan </pre> </blockquote> <br> </body> </html> |
From: Sergey C. <sch...@oc...> - 2008-11-07 02:49:51
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> I mean that fixing ppc-assem.S file should be the only place to take care of the issue. Unless I missed some other pieces of asm code which also has to be taken care of.<br> <br> Sergey Chernikov wrote: <blockquote cite="mid:491...@oc..." type="cite"> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> As far as I understand the problem there is no issue about floating point itself. SBCL will have floating point as it supposed to, even c code sbcl is compiling from may have floating point instructions. It's all Ok and will work as long as gcc is aware of that. <br> My guess is that problem is in asm file with explicit fp instructions. If I will be able to get rid of them and have healthy stack frame it should work just fine.<br> <br> Nathan Froyd wrote: <blockquote cite="mid:280...@ma..." type="cite"> <pre wrap="">On Thu, Nov 6, 2008 at 9:31 PM, Sergey Chernikov <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:sch...@oc..."><sch...@oc...></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Is there any good way to compile sbcl for ppc without HW floating point support or is there correct way to modify src/runtime/ppc-assem.S to avoid floating point instructions and have valid stack frame. </pre> </blockquote> <pre wrap=""><!----> Nope; SBCL currently relies on having hardware floating-point available. There's no software floating-point support. Storing random bits into those stack frame locations might let you get a bit further, but doing virtually anything numeric (maybe even compiling things--not sure) is going to execute hardware FP instructions and crash your program. -Nathan </pre> </blockquote> <br> <pre wrap=""> <hr size="4" width="90%"> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world <a class="moz-txt-link-freetext" href="http://moblin-contest.org/redirect.php?banner_id=100&url=/">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a></pre> <pre wrap=""> <hr size="4" width="90%"> _______________________________________________ Sbcl-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Sbc...@li...">Sbc...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/sbcl-devel">https://lists.sourceforge.net/lists/listinfo/sbcl-devel</a> </pre> </blockquote> <br> </body> </html> |
From: Nathan F. <fr...@gm...> - 2008-11-07 02:55:06
|
On Thu, Nov 6, 2008 at 9:49 PM, Sergey Chernikov <sch...@oc...> wrote: > I mean that fixing ppc-assem.S file should be the only place to take care of > the issue. Unless I missed some other pieces of asm code which also has to > be taken care of. The instructions in src/compiler/ppc/{array,float}.lisp would be a good start. There's some bits to take care of in the FFI, too. What you are asking for is a big change in how the compiler works, not merely the patching out of a few instructions in one assembly file. -Nathan |
From: Sergey C. <sch...@oc...> - 2008-11-07 04:36:13
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> I think I got it. <br> I did not realize there is sbcl's 'on-the-fly' compiler to fix as well. <br> <br> Thank you all for your replies. <br> <br> Nathan Froyd wrote: <blockquote cite="mid:280...@ma..." type="cite"> <pre wrap="">On Thu, Nov 6, 2008 at 9:49 PM, Sergey Chernikov <a class="moz-txt-link-rfc2396E" href="mailto:sch...@oc..."><sch...@oc...></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">I mean that fixing ppc-assem.S file should be the only place to take care of the issue. Unless I missed some other pieces of asm code which also has to be taken care of. </pre> </blockquote> <pre wrap=""><!----> The instructions in src/compiler/ppc/{array,float}.lisp would be a good start. There's some bits to take care of in the FFI, too. What you are asking for is a big change in how the compiler works, not merely the patching out of a few instructions in one assembly file. -Nathan </pre> </blockquote> <br> </body> </html> |
From: Brian D. <bd-...@la...> - 2008-11-07 04:07:46
|
On Thu, Nov 06, 2008 at 06:45:47PM -0800, Sergey Chernikov wrote: > As far as I understand the problem there is no issue about floating > point itself. SBCL will have floating point as it supposed to, even c > code sbcl is compiling from may have floating point instructions. It's > all Ok and will work as long as gcc is aware of that. My guess is > that problem is in asm file with explicit fp instructions. If I will > be able to get rid of them and have healthy stack frame it should work > just fine. [resending from subscribed email address; I really need to fix that] I don't know much about embedded PPC, but if your assembler can't assemble FP instructions, yet your gcc can compile floating point code, it's probably linking to a soft-float library. How this works is that instead of putting in assembly instructions, it instead puts in calls to library routines that implement floating point. In this case turning on kernel FPU emulation (if such a thing even exists for PPC) will do you no good until you can get an assembler that can deal with FP instructions. Unfortunately, switching SBCL to use soft-float is going to be a huge job, not the least of which because you won't have 32 handy double-precision FP registers anymore for the compiler to use. -bcd |
From: Bruce O'N. <ec...@pc...> - 2008-11-07 15:56:25
|
Hi, My past experience with soft float on gcc (68k, not ppc) was exactly that. You added -msoft-float (which could be the default on the platform) to the gcc command line and gcc, rather than emitting something like fadd, emitted a call to __gcc_float_add (or so..) and you had to have that routine in libc. Of course, just because that's the way gcc did it on 68k doesn't mean that's how gcc does it on ppc :-) I do believe that ARM works this way as well though. cheers bruce On Thu, Nov 06, 2008 at 09:51:39PM -0600, Brian Downing wrote: > On Thu, Nov 06, 2008 at 06:45:47PM -0800, Sergey Chernikov wrote: > > As far as I understand the problem there is no issue about floating > > point itself. SBCL will have floating point as it supposed to, even c > > code sbcl is compiling from may have floating point instructions. It's > > all Ok and will work as long as gcc is aware of that. My guess is > > that problem is in asm file with explicit fp instructions. If I will > > be able to get rid of them and have healthy stack frame it should work > > just fine. > > [resending from subscribed email address; I really need to fix that] > > I don't know much about embedded PPC, but if your assembler can't > assemble FP instructions, yet your gcc can compile floating point code, > it's probably linking to a soft-float library. How this works is that > instead of putting in assembly instructions, it instead puts in calls to > library routines that implement floating point. In this case turning on > kernel FPU emulation (if such a thing even exists for PPC) will do you > no good until you can get an assembler that can deal with FP > instructions. > > Unfortunately, switching SBCL to use soft-float is going to be a huge > job, not the least of which because you won't have 32 handy > double-precision FP registers anymore for the compiler to use. > > -bcd > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |