Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2006-11

Bug in compiling memds.pp from fcl

9 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Thomas Schatzl

Hello,

can the following be fixed:

~/startcompiler/ppcppc -Fu../../../rtl/units/powerpc-linux -FE. -FU../../../fcl/units/powerpc-linux -dpowerpc memds.pp Free Pascal Compiler version 2.0.4 [2006/07/09] for powerpc Copyright (c) 1993-2006 by Florian Klaempfl
Target OS: Linux for PowerPC
Compiling memds.pp
memds.pp(354,3) Note: Local variable "OldPos" not used memds.pp(354,10) Note: Local variable "NewPos" not used memds.pp(354,17) Note: Local variable "CopySize1" not used memds.pp(354,27) Note: Local variable "CopySize2" not used memds.pp(555,5) Note: Local variable "ACount" not used memds.pp(556,3) Note: Local variable "FN" not used memds.pp(557,3) Note: Local variable "FS" not used memds.pp(558,3) Note: Local variable "B" not used
memds.pp(559,3) Note: Local variable "FT" not used memds.pp(770,3) Error: Identifier not found "Unaligned" <--------- memds.pp(777,3) Error: Identifier not found "Unaligned" memds.pp(778,3) Error: Identifier not found "Unaligned" memds.pp(784,3) Error: Identifier not found "Unaligned" memds.pp(952) Fatal: There were 4 errors compiling module, stopping memds.pp(952) Fatal: Compilation aborted
make[2]: *** [memds.ppu] Error 1
make[2]: Leaving directory
`/home/contest/tschatzl/fpcsrc/trunk/fcl/db/memds' make[1]: *** [memds_all] Error 2
make[1]: Leaving directory `/home/contest/tschatzl/fpcsrc/trunk/fcl/db' make: *** [db_all] Error 2

Since I have no clue what this "Unaligned" method should do and/or how to support this.

Regards,
Thomas

Reply by email

Karl-Michael Schindler
to Thomas Schatzl

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

Reply by email

Karl-Michael Schindler
to Thomas Schatzl: can the following be fixed: ~/startcompiler/ppcppc -Fu../../../rtl/units/powerpc-linux…

Hallo, it's me again.

Bug is fixed with revision 9785

Show quoted text 13 lines
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

Reply by email

Daniël Mantione
to Karl-Michael Schindler

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.

Show quoted text 10 lines
> 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

Reply by email

Peter Vreman
to Daniël Mantione
Show quoted text 13 lines
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.

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.

Peter

Reply by email

Jonas Maebe
to Peter Vreman
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/msg00005.html

Jonas

Reply by email

Daniël Mantione
to Jonas Maebe

Op Sat, 19 Jan 2008, schreef Jonas Maebe:

Show quoted text 13 lines
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/msg00005.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.

Daniël

Reply by email

Marc Weustink
to Daniël Mantione
Daniël Mantione wrote 23 lines
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/msg00005.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 call&pop will affect the callstack in case it is generated.

Marc

Reply by email

Daniël Mantione
to Marc Weustink

Op Sat, 19 Jan 2008, schreef Marc Weustink:

Show quoted text 27 lines
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/msg00005.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 call&pop 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

Reply by email