Re: [fpc-devel] Stack alignment on i386
Am 18.12.2011 14:05, schrieb Jonas Maebe:
On 18 Dec 2011, at 13:37, Den Jean wrote:
However current fpc 2.4.4 does not align the stack as such.
I do not know if this correct or not when reading things like:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838#c8
http://groups.google.com/group/ia32-abi/browse_thread/thread/4f9b3e5069943bf1
I tried to change alignment with {$CODEALIGN 16} but this didn't work.
That's because it changes the alignment of procedures (code), rather than that
of the stack. You cannot change this setting via a switch, it's hardcoded in
the compiler as part of the ABI.
Changing this will also require quite a few changes in the RTL as well to be
safe (e.g., in case cmem is used and if the glibc memory manager one day would
use sse), because the RTL contains lots of assembler code that doesn't care at
all about stack alignment. The places where there's an {$ifndef darwin} in
i386-specific files can probably help, since Darwin/i386 also requires a
16-byte aligned stack. The assembler startup code for Linux/i386 probably also
needs to be adapted.
Overall, it's not a trivial change to make properly.
Hmm... I have thought a bit. Do you (or someone else) think it's
feasible (and useful) to add a procedure modifier that allows you to
specify the stack alignment that should be used when calling that
procedure? (of course this modifier should be considered as from great
power comes great responsibilty ^^)
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stack alignment on i386
On 22 Dec 2011, at 15:12, Sven Barth wrote: Hmm... I have thought a bit. Do you (or someone else) think it's feasible (and useful) to add a procedure modifier that allows you to specify the stack alignment that should be used when calling that procedure? (of course this modifier should be considered as from great power comes great responsibilty ^^) I think that the i386/Linux compiler and RTL should be modified to guarantee 16 byte alignment at all times, since that's how they apparently redefined their ABI. The generated code will also be backwards compatible. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stack alignment on i386
Am 22.12.2011 15:31, schrieb Jonas Maebe: On 22 Dec 2011, at 15:12, Sven Barth wrote: Hmm... I have thought a bit. Do you (or someone else) think it's feasible (and useful) to add a procedure modifier that allows you to specify the stack alignment that should be used when calling that procedure? (of course this modifier should be considered as from great power comes great responsibilty ^^) I think that the i386/Linux compiler and RTL should be modified to guarantee 16 byte alignment at all times, since that's how they apparently redefined their ABI. The generated code will also be backwards compatible. i386/Win32 should be adjusted then as well, because I suspect very much that this is the reason for my problems with OpenCV... (on Windows as well as on Linux) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stack alignment on i386
On 22 Dec 2011, at 15:40, Sven Barth wrote: i386/Win32 should be adjusted then as well, because I suspect very much that this is the reason for my problems with OpenCV... (on Windows as well as on Linux) From what I understand from http://msdn.microsoft.com/en-us/library/aa290049(v=vs.71).aspx , a function is required to align the stack to 8 or 16 bytes itself if it needs better alignment on win32. These links also all say the required alignment for win32 is 4 bytes: * http://msdn.microsoft.com/en-us/library/k1a8ss06.aspx : Some SSE types require eight-byte stack alignment, forcing the compiler to emit dynamic stack-alignment code. * http://old.nabble.com/ATLAS-on-win32,-pthreads,-SSE-and-stack-alignment-p19828585.html : in accordance win the Win32 ABI, only guarantees a 4-byte aligned stack * http://eigen.tuxfamily.org/dox/TopicWrongStackAlignment.html : this assumption can be wrong on Windows, where the stack is only guaranteed to have 4-byte alignment You should probably add the flag -mpreferred-stack-boundary=2 when compiling OpenCV for win32 using gcc: http://sourceforge.net/tracker/index.php?func=detailaid=2170667group_id=23725atid=379483 Also keep in mind that switching to 16 byte aligned stacks for existing targets a) requires many assembler routines in the RTL to be disabled (or rewritten, but that was not done for Darwin/i386, in part because in many cases it can use faster libc equivalents anyway) b) will probably break quite a bit assembler code from existing programs, both written for FPC and for Delphi (unless nostackframe; is added, the compiler will add stack alignment code to assembler routines which may mess up hardcoded offsets or other assumptions) Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stack alignment on i386
Am 22.12.2011 15:57, schrieb Jonas Maebe: On 22 Dec 2011, at 15:40, Sven Barth wrote: i386/Win32 should be adjusted then as well, because I suspect very much that this is the reason for my problems with OpenCV... (on Windows as well as on Linux) From what I understand from http://msdn.microsoft.com/en-us/library/aa290049(v=vs.71).aspx, a function is required to align the stack to 8 or 16 bytes itself if it needs better alignment on win32. These links also all say the required alignment for win32 is 4 bytes: * http://msdn.microsoft.com/en-us/library/k1a8ss06.aspx : Some SSE types require eight-byte stack alignment, forcing the compiler to emit dynamic stack-alignment code. * http://old.nabble.com/ATLAS-on-win32,-pthreads,-SSE-and-stack-alignment-p19828585.html : in accordance win the Win32 ABI, only guarantees a 4-byte aligned stack * http://eigen.tuxfamily.org/dox/TopicWrongStackAlignment.html : this assumption can be wrong on Windows, where the stack is only guaranteed to have 4-byte alignment You should probably add the flag -mpreferred-stack-boundary=2 when compiling OpenCV for win32 using gcc: http://sourceforge.net/tracker/index.php?func=detailaid=2170667group_id=23725atid=379483 While with OpenCV this issue might be solved by recompiling it (which I'd yet need to look into, because I'm simply using the provided binaries), what should be done about closed source code? Also keep in mind that switching to 16 byte aligned stacks for existing targets a) requires many assembler routines in the RTL to be disabled (or rewritten, but that was not done for Darwin/i386, in part because in many cases it can use faster libc equivalents anyway) b) will probably break quite a bit assembler code from existing programs, both written for FPC and for Delphi (unless nostackframe; is added, the compiler will add stack alignment code to assembler routines which may mess up hardcoded offsets or other assumptions) Somehow this motivates me more to add a stackalignment modifier... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stack alignment on i386
In our previous episode, Sven Barth said: While with OpenCV this issue might be solved by recompiling it (which I'd yet need to look into, because I'm simply using the provided binaries), what should be done about closed source code? In such case, it is better to let the vendor recompile it :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stack alignment on i386
On 22 Dec 2011, at 16:42, Sven Barth wrote: While with OpenCV this issue might be solved by recompiling it (which I'd yet need to look into, because I'm simply using the provided binaries), what should be done about closed source code? Closed source code should be compiled with a compiler that respects the ABI by default. I guess most of it is compiled with Microsoft Visual Studio, which does presumably does that. I don't think that any compiler other than GCC can create code for Win32 that assumes a 16- byte aligned stack. Somehow this motivates me more to add a stackalignment modifier... Then you would have to add this to all routines that may (directly or indirectly) a routine from a broken library. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Paramstr trailing spaces, bug or not?
Hi all, With this command-line: fpmake --prefix=bla --baseistall=test paramstr(1) gives --prefix=bla . Thus with the trailing space. Is this a bug or a feature? Joost -- My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Paramstr trailing spaces, bug or not?
On Thu, 22 Dec 2011, Joost van der Sluis wrote: Hi all, With this command-line: fpmake --prefix=bla --baseistall=test paramstr(1) gives --prefix=bla . Thus with the trailing space. Is this a bug or a feature? It's what the shell has passed on. The paramstr() code doesn't do any parsing on Linux. It returns the elements in argv[] Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Paramstr trailing spaces, bug or not?
On Thu, 2011-12-22 at 17:18 +0100, michael.vancann...@wisa.be wrote: With this command-line: fpmake --prefix=bla --baseistall=test paramstr(1) gives --prefix=bla . Thus with the trailing space. Is this a bug or a feature? It's what the shell has passed on. The paramstr() code doesn't do any parsing on Linux. It returns the elements in argv[] Most of the time I'm indeed on Linux, but this case it was Windows. But I guess the same thing holds? Joost. -- My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Stack alignment on i386
On 22 Dec 2011, at 17:18, Sven Barth wrote: Am 22.12.2011 17:04, schrieb Jonas Maebe: Closed source code should be compiled with a compiler that respects the ABI by default. I guess most of it is compiled with Microsoft Visual Studio, which does presumably does that. I don't think that any compiler other than GCC can create code for Win32 that assumes a 16-byte aligned stack. My mysterious OpenCV problems are with the MSVC version of the libraries... Then the problem is probably something different. Then you would have to add this to all routines that may (directly or indirectly) *call* a routine from a broken library. Wouldn't it be sufficient to align the stack when calling a routine from such a library? (sorry for sounding naive here, but the requirements for stack alignment still puzzle me a bit) Keeping an aligned stack requires completely different code generation inside the calling routine, you can't implement that on a call-by-call basis. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Paramstr trailing spaces, bug or not?
Am 22.12.2011 17:36, schrieb Joost van der Sluis: On Thu, 2011-12-22 at 17:18 +0100, michael.vancann...@wisa.be wrote: With this command-line: fpmake --prefix=bla --baseistall=test paramstr(1) gives --prefix=bla . Thus with the trailing space. Is this a bug or a feature? It's what the shell has passed on. The paramstr() code doesn't do any parsing on Linux. It returns the elements in argv[] Most of the time I'm indeed on Linux, but this case it was Windows. But I guess the same thing holds? AFAIK it's not the same as on Windows you have a commandline string which needs to be parsed by the application. Regards, Sven. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Paramstr trailing spaces, bug or not?
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Joost van der Sluis Envoyé : jeudi 22 décembre 2011 17:36 À : FPC developers' list Objet : Re: [fpc-devel] Paramstr trailing spaces, bug or not? On Thu, 2011-12-22 at 17:18 +0100, michael.vancann...@wisa.be wrote: With this command-line: fpmake --prefix=bla --baseistall=test paramstr(1) gives --prefix=bla . Thus with the trailing space. Is this a bug or a feature? It's what the shell has passed on. The paramstr() code doesn't do any parsing on Linux. It returns the elements in argv[] Most of the time I'm indeed on Linux, but this case it was Windows. But I guess the same thing holds? Hi Jost, I am completely unable to reproduce this... on a windows machine! Futhermore this behavior would break lots of code including the compiler itself... Maybe there is some special configuration you are working on that explains this strange behavior... Which Windows OS version do you use? Is it a Virtual machine? What shell are you using? Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Paramstr trailing spaces, bug or not?
In our previous episode, Pierre Free Pascal said: parsing on Linux. It returns the elements in argv[] Most of the time I'm indeed on Linux, but this case it was Windows. But I guess the same thing holds? I am completely unable to reproduce this... on a windows machine! From the sourcecode, I would suggest something with quotes something --prefix=bla ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Paramstr trailing spaces, bug or not?
On Thu, 2011-12-22 at 19:15 +0100, Pierre Free Pascal wrote: I am completely unable to reproduce this... on a windows machine! Futhermore this behavior would break lots of code including the compiler itself... Maybe there is some special configuration you are working on that explains this strange behavior... Which Windows OS version do you use? Is it a Virtual machine? What shell are you using? What I did was this: 'make install PREFIX=c:\lazarus\fpc\2.7.1\' the trailing backslash is important... Then make runs (among others) the following command: .\fpmake.exe install --localunitdir=../.. --globalunitdir=.. --os=win32 --cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o -FuC:/svn/fpc-trunk/rtl/units/i386-win32 -o -FuC:/svn/fpc-trunk/packages/hash/units/i386-win32 -o -FuC:/svn/fpc-trunk/packages/paszlib/units/i386-win32 -o -FuC:/svn/fpc-trunk/packages/fcl-process/units/i386-win32 -o -FuC:/svn/fpc-trunk/packages/fpmkunit/units/i386-win32 -o -FE. -o -FUunits/i386-win32 -o -di386 -o -dRELEASE --compiler=C:/svn/fpc-trunk/compiler/ppc386.exe --prefix=c:\lazarus\fpc\2.7.1\ --unitinstalldir=c:\lazarus\fpc\2.7.1\/units/i386-win32/fcl-base -ie -d Note the two spaces after the prefix. Which result in the error message that the directory c:\lazarus\fpc\2.7.1 \bin coudn't be created. (Note the space) Can you reproduce that? I tried with a simple hello-world kind of application and in that case I can't reproduce it either. This is on Windows 7 in a virtual machine. (kvm) Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Paramstr trailing spaces, bug or not?
23.12.2011 1:26, Joost van der Sluis пишет: What I did was this: 'make install PREFIX=c:\lazarus\fpc\2.7.1\' the trailing backslash is important... Then make runs (among others) the following command: .\fpmake.exe install --localunitdir=../.. --globalunitdir=.. --os=win32 --cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o -FuC:/svn/fpc-trunk/rtl/units/i386-win32 -o -FuC:/svn/fpc-trunk/packages/hash/units/i386-win32 -o -FuC:/svn/fpc-trunk/packages/paszlib/units/i386-win32 -o -FuC:/svn/fpc-trunk/packages/fcl-process/units/i386-win32 -o -FuC:/svn/fpc-trunk/packages/fpmkunit/units/i386-win32 -o -FE. -o -FUunits/i386-win32 -o -di386 -o -dRELEASE --compiler=C:/svn/fpc-trunk/compiler/ppc386.exe --prefix=c:\lazarus\fpc\2.7.1\ --unitinstalldir=c:\lazarus\fpc\2.7.1\/units/i386-win32/fcl-base -ie -d Note the two spaces after the prefix. Which result in the error message that the directory c:\lazarus\fpc\2.7.1 \bin coudn't be created. (Note the space) Can you reproduce that? I tried with a simple hello-world kind of application and in that case I can't reproduce it either. This is on Windows 7 in a virtual machine. (kvm) Just some notes: - syswin.inc code looks like any number of delimiters between parameters are skipped. - this extra whitespace is added by the makefile, suggesting some buggy/incorrect processing in make.exe or makefile itself. - the extra character may be not a whitespace (#32), but something looking like one (e.g. non-breaking space with code #160) Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Limitations of static ranged integer types and succ/pred, and dynamic solution.
On Tue, 20 Dec 2011 07:41:50 +0100, Skybuck Flying skybuck2...@hotmail.com wrote: (Delphi limitation, but probably applies to free pascal as well): You have a very interesting definition of limitation, but well... Take following examples: Tvalue = smallint; or Tvalue = word or Tvalue = 0..5000; ^ All of these examples are quite bad in the following way: They become very static, which makes it pretty much impossible to change their range at runtime. I can't see any reason why you would even want to change a range during runtime. After all, there usually was a pretty good reason why you applied a range the first time, otherwise you would have used Integer directly. My recommendation for the Delphi language is to do away with these static types and instead change them to dynamic types, just like arrays where expanded with dynamic types. As if the only purpose of range types is to index dynamic arrays. Ofcourse it's nice and perhaps even required to keep these static types for backward compatibility but it would also be nice if these types can be expanded with a dynamic type, so it can be safely used with dynamic arrays which can be any size/range. In that case you just need one type: InfiniteInteger (or maybe call it UnconstrainedInteger), where it's bit size changes during runtime up to the point where the computer memory is exhausted. So, instead of getting Range-Check errors, you get memory allocation failures trying to allocate an integer requiring 2**128 bits. :- var MinValue : integer; MaxValue : integer; Tvalue = MinValue...MaxValue; then this type could also be used as follows: var DynamicArrayOfValues : array[Tvalue] of integer; Umm, and what shall happen, if I change MinValue somewhere inbetween? The array size and/or index range shall magically change with it? And why would that be better than a (more) simple var Dynamic : array[MinValue .. MaxValue] of Integer; type TValue = Low (Dynamic) .. High (Dynamic); The array and the type you're indexing it with are tied to each other either way, so there's no point in changing only one of it. Or, to express it differently: As long as you don't know the size of the array you also don't know the range of the index type - and vice versa. Well, considering that the latter is (to some extent) already available in the current compiler, your proposal is IMO quite useless. Or - may I speak freely, sir? ... Then, I think, it's bullshit. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
