[fpc-devel] fpdoc fails to get full declaration of constants
Running fpdoc over fpGUI code, the Linear Output Writer (LaTeX and new IPF output) for constants do not contain the full declaration. The problem is detected inside the TLinearWriter.WriteConsts() method. Debugging the fpdoc code inside WriteConsts(), it retrieves the declaration as shown in the debug tooltip (screeenshot attached). fpdoc (linear writer descendant): clAliceBlue = The actual code (inside an include file) is: clAliceBlue = TfpgColor($f0f8ff); The problem seems to be localised to the Linear Output descendants. I double checked with the fpdoc HTML output, and the clAliceBlue declaration is full and correct. I'm using FPC 2.5.1 Trunk (updated yesterday). Is this down to a fcl-passrc parser bug, or a fpdoc processing bug. I believe the latter is true because otherwise the HTML Writer output would also have been wrong. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ attachment: Screenshot.png___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc fails to get full declaration of constants
Here is another screenshot showing the content of the ConstDecl: TPasConst variable inside TLinearWriter.WriteConsts() method. Graeme. attachment: Screenshot-1.png___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc fails to get full declaration of constants
On Wed, 4 Aug 2010, Graeme Geldenhuys wrote: Running fpdoc over fpGUI code, the Linear Output Writer (LaTeX and new IPF output) for constants do not contain the full declaration. The problem is detected inside the TLinearWriter.WriteConsts() method. Debugging the fpdoc code inside WriteConsts(), it retrieves the declaration as shown in the debug tooltip (screeenshot attached). fpdoc (linear writer descendant): clAliceBlue = The actual code (inside an include file) is: clAliceBlue = TfpgColor($f0f8ff); The problem seems to be localised to the Linear Output descendants. I double checked with the fpdoc HTML output, and the clAliceBlue declaration is full and correct. I'm using FPC 2.5.1 Trunk (updated yesterday). Is this down to a fcl-passrc parser bug, or a fpdoc processing bug. I believe the latter is true because otherwise the HTML Writer output would also have been wrong. The bug is due to a fcl-passrc bug in pastree: each element should be able to output itself. The HTML code does not use this feature, but the linear output engine does. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc fails to get full declaration of constants
Op 2010-08-04 09:48, Michael Van Canneyt het geskryf: The bug is due to a fcl-passrc bug in pastree: each element should be able to output itself. The HTML code does not use this feature, but the linear output engine does. If you don't have time to look at it, any hints of where in the fcl-passrc code I should start looking for the bug. I don't know fcl-passrc code at all. The pastree unit doesn't look to big, so if the bug is in there, hopefully I can find it. If the parser failed to generate a token/node for the required constant value information, then that's another story. I can confirm that the following fpdoc output all have this bug: * Plain Text (txt) * LaTeX (latex) * Rich Text (rtf) * New IPF (ipf) Not sure about * Man (this gives an Access Violation when run) * XML (this gives an Access Violation when run) This means your can't generate new documentation for FPC 2.4.2 release either. ;-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc fails to get full declaration of constants
On Wed, 4 Aug 2010, Graeme Geldenhuys wrote: Op 2010-08-04 09:48, Michael Van Canneyt het geskryf: The bug is due to a fcl-passrc bug in pastree: each element should be able to output itself. The HTML code does not use this feature, but the linear output engine does. If you don't have time to look at it, any hints of where in the fcl-passrc code I should start looking for the bug. I don't know fcl-passrc code at all. The pastree unit doesn't look to big, so if the bug is in there, hopefully I can find it. If the parser failed to generate a token/node for the required constant value information, then that's another story. I can confirm that the following fpdoc output all have this bug: * Plain Text (txt) * LaTeX (latex) * Rich Text (rtf) * New IPF (ipf) Not sure about * Man (this gives an Access Violation when run) * XML (this gives an Access Violation when run) This means your can't generate new documentation for FPC 2.4.2 release either. ;-) No, since we use the version in the fixes branch. That should not have the bug. It is the new expression support which creates the bug... In the pastree unit, the TPasExpr class must be made a descendent of TPasElement. Then the classes TUnaryExpr,TBinaryExpr,TPrimitiveExpr,TBoolConstExpr,TNilExpr,TParamsExpr,TRecordValues,TArrayValues must override the function GetDeclaration(full : Boolean) : string; virtual; function to output the pascal code that corresponds to the expression. And finally TPasVariable.GetDeclaration must be adapted so it adds Expr.GetDeclaration(Full) to the output. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] threadvar implementation
On 08/04/2010 03:57 AM, Hans-Peter Diettrich wrote: Getting the linear address of a threadvar depends on the OS/FPC implementation. Of course the compilker needs to adhere to what the OS provides. As already said multiple times, Win32 for each thread provides a block of user space memory that is addressed by FS and here the base address (to be used via DS) of the threadvar area thus the threadvr itself is rto be accessed using DS. OTOH, Linux X86 provides the address of the threadvar area directly in GS, so that the threadvar needs to be accessed using GS. As Pascal (other than C) does not provide a means to define that a pointer type is a pointer to a threadvar rather than to a normal var, Pascal alway uses DS to access any variable. As the user program only sees linear addresses (which have 32 Bit offsets are different regarding to which segment register (or segment register content is used) there are no means for the user land program to calculate a DS-denoted offset (to be used by a pointer) from the GS-denoted offset it knows for the threadvar. IMO FPC *should* allow to get the address of a threadvar by AddressOf(threadvar) Usually It does - using DS (the default, thus not explicitly noting a segment register in the ASM instruction). Only with X86/32-Linux when not using a pointer it can't do this (in a high-performance way), as the DS-based offset of the threadvar is not known. In fact it does it the slow way, doing a function call for any access to a threadvar. As Lazarus does not provide a means to do single setpping in ASM code, I was not able to find out what actually is done here. - test yourself. It may be possible to get that address also with an LEA instruction (untested). I did the test. lea eax, FS:[$34] resulst in EAX = $34, even though FS is $3B and mov eax, FS:[$34] results in correctly loading ax from memory and mov eax,[eax] with eax = $34 correctly results in an access violation in fact I did not suppose that lea eax, FS:[$34] would compile at all but it does the code of lea eax, FS:[$34] is 64 8D 05 34 00 00 00, using the DS prefix 64 while the code of lea eax, $34]is 8D 05 34 00 00 00 I don't see what lea eax, FS:[$34] in fact is supposed to do. AFAIR Delphi obtains the address of the threadvar memory block via FS/GS, Right via FS it gets the thread management block that contains the (DS-based) offset of the threadvar block, (as stated before. and exactly as M$ C does). so that it's possible to use the same instruction sequence, This is what I tried to express in the beginning. except that finally not the value of the threadvar is retrieved, Yep, this is as Win32 handles it (but other than Linux does ) but its address (LEA instead of MOV). Nope. to read a normal var it needs to do mov eax, normvar; (this is implicitely DS based) to get the pointer to a normal var it needs to do lea eax, normalvar; (this is implicitely DS based) to read a threadvar, it needs to do mov eax, FS:(threadmanagementblock+thrfeafvarblockoffset); (this results in the DS-based address of the threadvar block) mov eax, [eax+threadvar] to get the pointer to a thrfeadvar it can do mov eax, FS:(threadmanagementblock+thrfeafvarblockoffset); (this results in the DS-based address of the threadvar block) lea eax, [eax+threadvar]; (this results in the DS-based address of the threadvar) or mov eax, FS:(threadmanagementblock+thrfeafvarblockoffset); (this results in the DS-based address of the threadvar block) add eax, offset (threadvar)]; (this results in the DS-based address of the threadvar) this can't be done in a single ASM instruction -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc fails to get full declaration of constants
In our previous episode, Michael Van Canneyt said: No, since we use the version in the fixes branch. That should not have the bug. It is the new expression support which creates the bug... I hopefully fixed most of the deprecated bugs yesterday evening (mantis 16342). I was planning to have a look at const node anyway today. (see same mantis) If I have time, and understand what I'm doing I'll have a look at the rest too (but I doubt expression writing is as easy as in the past, when the expression was one string) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc fails to get full declaration of constants
On Wed, 4 Aug 2010, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: No, since we use the version in the fixes branch. That should not have the bug. It is the new expression support which creates the bug... I hopefully fixed most of the deprecated bugs yesterday evening (mantis 16342). Aha ? Congratulations, nice job :-) I was planning to have a look at const node anyway today. (see same mantis) If I have time, and understand what I'm doing I'll have a look at the rest too (but I doubt expression writing is as easy as in the past, when the expression was one string) Writing it out is not a problem. If you take care of the const node, I'll handle the writing. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] buildfaq
On 04/08/10 03:34, Hans-Peter Diettrich wrote: I've some problems with building and testing an new compiler. 1) The buildfaq mentions both PP= and FPC= for the compiler, to be used by Make. It should be made clear whether these are equivalent, or (better) only one option should be used across the entire FAQ. From Makefile (line 104): ifndef FPC ifdef PP FPC=$(PP) endif endif 2) An unqualified reference (PP=mypp) most proably fails - where exactly does Make search for that compiler? See Makefile from line 109 onwards. It first looks for fpc(.exe) on the path. If it finds that, it gets the real compiler exe with -PB. If fpc(.exe) isn't found, it tries to find ppc386(.exe) on the path. 5) A matter of convenience: Currently the easiest way to get both FPC and Lazarus up (on a Windows system) is the installation of Lazarus 0.9.28, including FPC 2.2.4 and all required build tools. That's the latest Lazarus/FPC distribution, available for almost all platforms, that runs off the shelf. Unfortunately the 2.2.4 compiler can not compile the 2.5 sources, so that another binary must be installed. In the worst case multiple (make and install) steps are required, until the 2.5 sources can be compiled by a 2.4 version - including all the RTL stuff. Can we get some more version compatibility? On Windows, I usually install latest fpc release, then I check out lazarus and build it. That's pretty simple, no? Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] buildfaq
In our previous episode, Hans-Peter Diettrich said: I've some problems with building and testing an new compiler. 1) The buildfaq mentions both PP= and FPC= for the compiler, to be used by Make. It should be made clear whether these are equivalent, or (better) only one option should be used across the entire FAQ. I've never noticed a difference. This because fpc and ppcx mostly support the same switches, and when crosscompiling you generally pass the exact compiler you want anyway. 2) An unqualified reference (PP=mypp) most proably fails - where exactly does Make search for that compiler? Works for me. It searches in the PATH. It might not look in the current dir though, is that what you mean? That is a make gotcha though. 3) Is it possible to give the new compiler an specific name, during Make, so that the original compiler is not inadvertently overwritten by a buggy version? IIRC EXENAME=pp_party 4) How does FPC handle different targets? IMO every target is implemented in a specific executable, so how does pp or fpc proceed when it is invoked with an target specifier, that it cannot handle itself? This is clearly explained in the FAQ. A binary per architecture is the minimal needed configuration. The maximal possible configuration is an m x m matrix (with m the number of targets), each with a different host-target, dest-target. 5) A matter of convenience: Currently the easiest way to get both FPC and Lazarus up (on a Windows system) is the installation of Lazarus 0.9.28, including FPC 2.2.4 and all required build tools. That's the latest Lazarus/FPC distribution, available for almost all platforms, that runs off the shelf. Unfortunately the 2.2.4 compiler can not compile the 2.5 sources, so that another binary must be installed. In the worst case multiple (make and install) steps are required, until the 2.5 sources can be compiled by a 2.4 version - including all the RTL stuff. Can we get some more version compatibility? I don't see any possibilities here. 2.2.4 + 2.4.0 bridges a major version cycle, and this would mean it would take 2,3 years before any new feature or fix can be used in the fpc repository codebase. Specially if the only reason is to avoid a small download. The current situation is already enough work. And of course we couldn't predict that Lazarus would not release anything for 2.4.0 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] buildfaq
On 04/08/10 11:31, Marco van de Voort wrote: In our previous episode, Hans-Peter Diettrich said: 3) Is it possible to give the new compiler an specific name, during Make, so that the original compiler is not inadvertently overwritten by a buggy version? IIRC EXENAME=pp_party It looks like you will also have to set PPNEW if you do this. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc fails to get full declaration of constants
Op 2010-08-04 11:29, Michael Van Canneyt het geskryf: Writing it out is not a problem. If you take care of the const node, I'll handle the writing. Thanks guys, this is much appreciated. I'll take a close look at the last few commits of fpdoc and fcl-passrc to learn some of the code. I'll be using the parser a lot more in two of my projects I am working on, so I'll need to find my way around that code anyway. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc fails to get full declaration of constants
In our previous episode, Graeme Geldenhuys said: Writing it out is not a problem. If you take care of the const node, I'll handle the writing. Thanks guys, this is much appreciated. I'll take a close look at the last few commits of fpdoc and fcl-passrc to learn some of the code. I'll be using the parser a lot more in two of my projects I am working on, so I'll need to find my way around that code anyway. See also comments in mantis 16342, and realize that the fact that semicolons can be omitted (see example) and that library is an own token are the main things to watch out for. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] buildfaq
Florian Klaempfl schrieb: 4) How does FPC handle different targets? IMO every target is implemented in a specific executable, so how does pp or fpc proceed when it is invoked with an target specifier, that it cannot handle itself? fpc is only a wrapper, it tries to find the right compiler. Thanks, this was the missing link ;-) In the worst case multiple (make and install) steps are required, until the 2.5 sources can be compiled by a 2.4 version - including all the RTL stuff. Can we get some more version compatibility? Just install lastest release lazarus and lastest release fpc: to debug the compiler etc. you can use a compiler compiled with 2.2.4. 2.2.4 cannot compile the 2.5 sources :-( To test full builds, just use the 2.4.0 compiler. With some shell or batch scripts adapted to your needs, this is quite easy. Finally I could use 2.4 to build and install 2.5 x86_64-win64 :-) But fpc now complains that it cannot run ppc386.exe - why? It should be ppcx64, of course, so why does fpc choose the wrong compiler? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc fails to get full declaration of constants
2010/8/4 Marco van de Voort mar...@stack.nl: In our previous episode, Graeme Geldenhuys said: Writing it out is not a problem. If you take care of the const node, I'll handle the writing. Thanks guys, this is much appreciated. I'll take a close look at the last few commits of fpdoc and fcl-passrc to learn some of the code. I'll be using the parser a lot more in two of my projects I am working on, so I'll need to find my way around that code anyway. See also comments in mantis 16342, and realize that the fact that semicolons can be omitted (see example) and that library is an own token are the main things to watch out for. Additionally fpdoc cannot parse the following const declaration: const DefaultLogFont: TLogFont = (lfHeight:0; lfWidth:0; lfEscapement:0; lfOrientation:0; lfWeight:0; lfItalic:0; lfUnderline:0; lfStrikeOut:0; lfCharSet:0; lfOutPrecision:0; lfClipPrecision:0; lfQuality:0; lfPitchAndFamily:0; lfFaceName:'default'; ); Note the semi colon before the ) at the end. Shall I create a new bug report for it? Or is it better to just remove that semi colon. The compiler seems to accept both syntaxes. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] buildfaq
On 04 Aug 2010, at 14:39, Hans-Peter Diettrich wrote: But fpc now complains that it cannot run ppc386.exe - why? It should be ppcx64, of course, so why does fpc choose the wrong compiler? It means that the fpc.exe that you are executing is an i386 binary. By default, it looks for a ppc binary for the same target architecture as the architecture of fpc.exe. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc fails to get full declaration of constants
2010/8/4 Marco van de Voort mar...@stack.nl: In our previous episode, Graeme Geldenhuys said: Writing it out is not a problem. If you take care of the const node, I'll handle the writing. Thanks guys, this is much appreciated. I'll take a close look at the last few commits of fpdoc and fcl-passrc to learn some of the code. I'll be using the parser a lot more in two of my projects I am working on, so I'll need to find my way around that code anyway. See also comments in mantis 16342, and realize that the fact that semicolons can be omitted (see example) and that library is an own token are the main things to watch out for. While testing fpdoc on the LCL, I found another issue: http://bugs.freepascal.org/view.php?id=17110 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] buildfaq
Henry Vermaak schrieb: 2) An unqualified reference (PP=mypp) most proably fails - where exactly does Make search for that compiler? See Makefile from line 109 onwards. It first looks for fpc(.exe) on the path. If it finds that, it gets the real compiler exe with -PB. If fpc(.exe) isn't found, it tries to find ppc386(.exe) on the path. I'm not very familiar with the make syntax :-( Why ppc386, on a 64 bit platform? Should I copy or add a link, from ppc386.exe to ppcx64.exe? 5) A matter of convenience: Currently the easiest way to get both FPC and Lazarus up (on a Windows system) is the installation of Lazarus 0.9.28, including FPC 2.2.4 and all required build tools. That's the latest Lazarus/FPC distribution, available for almost all platforms, that runs off the shelf. Unfortunately the 2.2.4 compiler can not compile the 2.5 sources, so that another binary must be installed. In the worst case multiple (make and install) steps are required, until the 2.5 sources can be compiled by a 2.4 version - including all the RTL stuff. Can we get some more version compatibility? On Windows, I usually install latest fpc release, then I check out lazarus and build it. That's pretty simple, no? Installing the latest fpc release is anything but simple :-( The (currently) last problem is the new fpc.exe, which assumes a 32 bit target, and tries to invoke the (non existing) ppc386.exe. The old 2.2.4 fpc.exe, that came with Lazarus 0.9.28, seems to work properly. But I don't want to test more, instead I simply copied the new ppcx64.exe to ppc386.exe :-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] buildfaq
Marco van de Voort schrieb: 2) An unqualified reference (PP=mypp) most proably fails - where exactly does Make search for that compiler? Works for me. It searches in the PATH. It might not look in the current dir though, is that what you mean? That is a make gotcha though. So it's not recommended to use an unqualified name. 4) How does FPC handle different targets? IMO every target is implemented in a specific executable, so how does pp or fpc proceed when it is invoked with an target specifier, that it cannot handle itself? This is clearly explained in the FAQ. A binary per architecture is the minimal needed configuration. This is not what I asked for :-( Possibly fpc is not rebuilt during make all or make install, when it had already been built for a different target before. Then it assumes the old target, for which it was built before. Possibly... The maximal possible configuration is an m x m matrix (with m the number of targets), each with a different host-target, dest-target. You mean when cross-compilers are cross-built? I'm happy with a single compiler for my current machine, it takes enough time to build on Windows :-( 5) A matter of convenience: Currently the easiest way to get both FPC and Lazarus up (on a Windows system) is the installation of Lazarus 0.9.28, including FPC 2.2.4 and all required build tools. That's the latest Lazarus/FPC distribution, available for almost all platforms, that runs off the shelf. Unfortunately the 2.2.4 compiler can not compile the 2.5 sources, so that another binary must be installed. In the worst case multiple (make and install) steps are required, until the 2.5 sources can be compiled by a 2.4 version - including all the RTL stuff. Can we get some more version compatibility? I don't see any possibilities here. 2.2.4 + 2.4.0 bridges a major version cycle, and this would mean it would take 2,3 years before any new feature or fix can be used in the fpc repository codebase. Specially if the only reason is to avoid a small download. The current situation is already enough work. The small download of the 2.4 64 bit cross-compiler cannot be avoided, and it requires another cross-build on the 64 bit host=target system. It would be nice to have an combined 32/64 bit release for Windows, not only an cross-compiler. This would be a small effort... And of course we couldn't predict that Lazarus would not release anything for 2.4.0 AFAIK the Lazarus people are still waiting for a final 2.4 release. Only Lazarus 0.9.29 requires at least FPC 2.4, before an FPC 2.2.4 was sufficient. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] buildfaq
On 4 August 2010 14:30, Hans-Peter Diettrich drdiettri...@aol.com wrote: Henry Vermaak schrieb: 2) An unqualified reference (PP=mypp) most proably fails - where exactly does Make search for that compiler? See Makefile from line 109 onwards. It first looks for fpc(.exe) on the path. If it finds that, it gets the real compiler exe with -PB. If fpc(.exe) isn't found, it tries to find ppc386(.exe) on the path. I'm not very familiar with the make syntax :-( Heh, prepare to lose your mind. Why ppc386, on a 64 bit platform? Don't know. It should look for something like ppc$(arch)$(exeext), I guess. Should I copy or add a link, from ppc386.exe to ppcx64.exe? Why not just pass FPC when you build? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] threadvar implementation
On 08/04/2010 12:04 PM, Hans-Peter Diettrich wrote: Well, different thread implementations exist for Linux. And the threadvar implementation is fully up to the compiler - so that FPC could use a Linux threadvar that holds the address of the FPC threadvar block - just like implemented for Windows. OK, the FPC RTL could create a one word sized thread management block, just to hold the DS-notation of the offset of the threadvar block. This is other than GNU C in Linux works, but maybe this in fact is a good idea as it allows for pointers to threadvars and is faster than the current implementation (with any access to a threadvar calling a function that I failed to analyze). Since all pointers are linear addresses, this is not a problem. Look at the document I mentioned: a linear address is 48 bits, while a pointer is only 32 bits (the Offset) . So with FPC and Delphi always DS is used to provide the additional 16 bits, while with C (supposedly) GS is used to provide the additional 16 bits in case of a pointer type that points to a variable of a type denoted with __thread. Too bad, I had thought that LEA takes into account the segment base :-( And I assumed it would not compile if a segment is denoted (also :-( :). If lea would take the segment base into account (a nice idea) it would need to know about both the segment to be used as a source as the segment that the result is to be used with. Giving multiple segment prefixes is not possible. Moreover LEA would need to result in an error if the source and/or target segment does not provide the requested address. Thus LEA without a segment notification assumes source and target segment register to be the same, i.e. just handles the 32 Bit Offset. I fail to understand what LEA is supposed to do if a (single) segment register is given :(. Funny stuff.. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] buildfaq
On 08/04/2010 03:30 PM, Hans-Peter Diettrich wrote: I'm not very familiar with the make syntax :-( There is a book by O'Reily on GNU MAKE sitting on my shelf. I did not yet dare to open it -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] buildfaq
Henry Vermaak schrieb: I'm not very familiar with the make syntax :-( Heh, prepare to lose your mind. It's like with the universe - once somebody will figure out, how it works, it will turn immediately into something even more weird. Some years ago I tried to install autobloat C packages work on Windows. After some tries I knew which foolish tests to erase, and that a Linux/C coder has to learn at least 4 more languages, apart from his programming language. Since that time I know what made C coders what they are ;-) DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] buildfaq
Michael Schnell schrieb: I'm not very familiar with the make syntax :-( There is a book by O'Reily on GNU MAKE sitting on my shelf. I did not yet dare to open it It's quite useless, since the C coder community does not accept most of the extensions. Instead they insist in using autobloat, worth 4 more books :-( DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] threadvar implementation
Von: Michael Schnell mschn...@lumino.de: As Pascal (other than C) does not provide a means to define that a pointer type is a pointer to a threadvar rather than to a normal var, Pascal alway uses DS to access any variable. JFTR, plain vanilla C (i.e. ISO C99) does not even have a notion of a thread variable, because it doesn't have threads. So I don't know what C you're referring to here. - test yourself. It may be possible to get that address also with an LEA instruction (untested). I did the test. No need to. The segment value is not used by LEA. It calculates the effective address which basically means the offset. lea eax, FS:[$34] resulst in EAX = $34, even though FS is $3B and mov eax, FS:[$34] results in correctly loading ax from memory and mov eax,[eax] with eax = $34 correctly results in an access violation in fact I did not suppose that lea eax, FS:[$34] would compile at all but it does the code of lea eax, FS:[$34] is 64 8D 05 34 00 00 00, using the DS prefix 64 while I'm sure you meant FS prefix. DS doesn't have one AFAIR. the code of lea eax, $34]is 8D 05 34 00 00 00 I don't see what lea eax, FS:[$34] in fact is supposed to do. Loading the effective address. Any decent assembler could optimize that code into a mov eax, 34h. to read a normal var it needs to do mov eax, normvar; (this is implicitely DS based) to get the pointer to a normal var it needs to do lea eax, normalvar; (this is implicitely DS based) to read a threadvar, it needs to do mov eax, FS:(threadmanagementblock+thrfeafvarblockoffset); (this results in the DS-based address of the threadvar block) mov eax, [eax+threadvar] Or do that beforehand and simply store the pointer to the threadvar. This must be done anyway, because via pointer is the only way to reference a threadvar. That means that: threadvar x : Integer; var y : ^Integer; should result in a proper initialization of x by the compiler when a thread is started and references would implicitly change like this: x := 1; = x^ := 1; y := @x; = y := x; In that way, there is not even the notion of a pointer to a threadvar needed, because the compiler can handle that transparently like another reference type. Actually, I was under the impression that the compiler does exactly such a transformation already. Vinzent. -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] threadvar implementation
Michael Schnell mschn...@lumino.de: I fail to understand what LEA is supposed to do if a (single) segment register is given :(. Ignoring it, because it is not part of the effective address which it is supposed to calculate? http://www.intel.com/software/products/documentation/vlin/mergedprojects/analyzer_ec/mergedprojects/reference_olh/mergedprojects/instructions/instruct32_hh/vc150.htm: |The source operand is a memory address (offset part) ^^^ Says that only the offset is used. |specified with one of the processors addressing modes ^^ Obviously this includes segmented addressing modes with segment (or descriptor) prefixes. So I don't know why you seem so confused. After all, it's x86. See signature. :) Vinzent. -- Intel CPUs are not defective, they just act that way. -- Henry Spencer -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OO rewrite - first round finished
Hans-Peter Diettrich wrote: Jonas Maebe schrieb: In whichever way you are used to debug: with a debugger, with writeln's, ... The compiler is no different than any other program in that respect. While I can use Lazarus to debug the compilation of a single source file, no such feature exists for Makefiles. I even don't know how to translate an error address to a source code position. In Delphi I had a jump to address... menu item... Use make all as Execute before step in Lazarus, check all 3 checks and uncheck the compiler Call on checks in the last page of the project options (Compiler options - compiler). Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
