Re: [fpc-devel] Re: Bug in revision 9781/2
Op Sat, 19 Jan 2008, schreef Karl-Michael Schindler: Hallo, it's me again. Bug is fixed with revision 9785 Well, not fixed, but just disabled on Darwin. However, it did finally succeed on Win32 this night. Hi there, when cycling fpc on macosx/darwin-386 (10.5) I get this error: i386.inc(1198,1) Error: Unknown label identifier .LPIC with revision 9781/2. I tried 2.3.1 and 2.2.1 call .LPic is actually one line before the declaration of .LPic. My knowledge of asm is near zero. So, no idea whether this is allowed or not. To access global variables in a PIC environment you need to get the value of the program counter. call puts the value on the stack and jumps to the label. You don't want to jump, just push the program counter, so you declare a label immedeately after the call instruction. The pop ebx after it retrieves the pushed program counter from the stack again in ebx. So this code is correct. The reason why it didn't compile was case sensitivity of the ATT assembler reader, which Jonas did correct. Jonas did disable it on Darwin as it apparently still did not work for him. It has to be the Darwin PIC code, allthough to the eye it seems correct to me. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Bug in revision 9781/2
On 19 Jan 2008, at 15:54, Peter Vreman wrote: This call and pop is old-style PIC and not good for new cpus because it breaks the call-stack. Please use the new style that calls a function (fpc_geteipasebx). This also generated by the compiler. See i386/cgcpu.pas and search for g_maybe_got_init. I recently read that on the more recent processors, call/pop is slightly faster again (I suppose they detect a call to next instruction and don't add it to the internal call stack or so). http://lists.apple.com/archives/perfoptimization-dev/2007/Nov/msg5.html Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Bug in revision 9781/2
Daniël Mantione wrote: Op Sat, 19 Jan 2008, schreef Jonas Maebe: On 19 Jan 2008, at 15:54, Peter Vreman wrote: This call and pop is old-style PIC and not good for new cpus because it breaks the call-stack. Please use the new style that calls a function (fpc_geteipasebx). This also generated by the compiler. See i386/cgcpu.pas and search for g_maybe_got_init. I recently read that on the more recent processors, call/pop is slightly faster again (I suppose they detect a call to next instruction and don't add it to the internal call stack or so). http://lists.apple.com/archives/perfoptimization-dev/2007/Nov/msg5.html Intel cpu's since Pentium M and AMD cpu's since Barcelona indeed have a stack analyzer. I'm still going to switch back to the fpc_geteipasebx helper since the extra call/ret penalty on those processors is small while the penalty of a broken call stack is large. Just for my information, this callstack, is it tracked by the CPU or generated by FPC. I somehow fail to see why a callpop will affect the callstack in case it is generated. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Bug in revision 9781/2
Op Sat, 19 Jan 2008, schreef Marc Weustink: Daniël Mantione wrote: Op Sat, 19 Jan 2008, schreef Jonas Maebe: On 19 Jan 2008, at 15:54, Peter Vreman wrote: This call and pop is old-style PIC and not good for new cpus because it breaks the call-stack. Please use the new style that calls a function (fpc_geteipasebx). This also generated by the compiler. See i386/cgcpu.pas and search for g_maybe_got_init. I recently read that on the more recent processors, call/pop is slightly faster again (I suppose they detect a call to next instruction and don't add it to the internal call stack or so). http://lists.apple.com/archives/perfoptimization-dev/2007/Nov/msg5.html Intel cpu's since Pentium M and AMD cpu's since Barcelona indeed have a stack analyzer. I'm still going to switch back to the fpc_geteipasebx helper since the extra call/ret penalty on those processors is small while the penalty of a broken call stack is large. Just for my information, this callstack, is it tracked by the CPU or generated by FPC. I somehow fail to see why a callpop will affect the callstack in case it is generated. It is tracked by the cpu. It exists to prevent the pipeline has to be flushed when encountering a ret; with the call stack the cpu can know where the program will continue. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Bug in revision 9781/2
Hallo, it's me again. Bug is fixed with revision 9785 Hi there, when cycling fpc on macosx/darwin-386 (10.5) I get this error: i386.inc(1198,1) Error: Unknown label identifier .LPIC with revision 9781/2. I tried 2.3.1 and 2.2.1 call .LPic is actually one line before the declaration of .LPic. My knowledge of asm is near zero. So, no idea whether this is allowed or not. All the best - Michael Schindler ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
