Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On 13/01/2022 01:31, Ben Grasset via fpc-devel wrote: Isn't this specifically the kind of thing that the `FPC_SOFT_FPUX80` define solves? It's indeed what it's intended to solve, but currently it still generates different values compared to an actual x87 fpu. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On 1/13/22 02:31, Ben Grasset via fpc-devel wrote: On Wed, Jan 12, 2022 at 7:38 AM Martin Frb via fpc-devel wrote: The downloads provided by Lazarus are also NOT a "pure, native 64-bit download". Only the "fpc.exe" and the non-cross "ppc64.exe" are native 64 bit. As I said, I do not know, what is currently provided by the Fpc "combined 32-/64-bit download". No Idea, if any of the fpc/ppc executable in this download are already 64-bit. Every single executable that actually originates from the FPC toolchain (so like `fpc.exe`, `ppcx64.exe`, `ppudump.exe`, `pas2js.exe`, `h2pas.exe`, and so on) contained in the current "lazarus-2.2.0-fpc-3.2.2-win64.exe" installer that the Lazarus website directs to when you click "Download Now" on a system running 64-bit Windows *IS* currently 64-bit. I just verified this myself. That particular installer does not include any cross compilers at all, also (the ones to target 32-bit Windows from 64-bit come in the smaller "lazarus-2.2.0-fpc-3.2.2-cross-i386-win32-win64.exe" installer. On Wed, Jan 12, 2022 at 7:55 AM Tomas Hajny via fpc-devel wrote: Wrong - applies only to the Win64 target, whereas e.g. 64-bit Linux (supported by the same compiler targetting 64-bit code) supports extended. This means that compiling source code with this compiler may result in a different binary as soon as there's e.g. an extended contstant included in the source code, or any compile-time calculations in this precision need to be performed. Isn't this specifically the kind of thing that the `FPC_SOFT_FPUX80` define solves? FPC does not even let you go from 64-bit Windows to 32-bit targets if that define isn't active IIRC, so presumably the same thing could be made the case in other scenarios if it's something people are widely concerned about. In any case, people who want native 64-bit Windows toolchains want them pretty much exclusively for use /on /64-bit Windows to /target/ 64-bit Windows, and will install any cross-compilers secondarily /if /they have a use for them. The 32-bit-to-64-bit Windows FPC toolchain is /not /a perfect drop-in replacement. Based on testing I did locally previously, it's not as fast as the native 64-bit one, Really? Are you sure, because I just tested make cycle on Linux and the results are: i386: real 1m1.032s user 0m53.194s sys 0m5.572s x86_64: real 1m32.651s user 1m21.486s sys 0m9.414s So, the 64-bit compiler is 50% slower. This is on an AMD Ryzen 9 5900X 12-core processor, 128 GB RAM and an SSD. I haven't tested in Windows, but it would be very strange and suspicious if the results are very different. I would double check if that's really the case and also try some things, like disabling any antivirus programs that might be slowing down your computer by scanning every exe file, produced by the compiler. and additionally there are other things to keep in mind like the 4GB RAM limit on 32-bit (which I have in fact seen more than one user on the Lazarus forums run into with larger projects, none of whom were using the 32-bit executables "on purpose"). A bug report with steps to reproduce would probably be nice. Nikolay ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On 1/13/22 07:44, Ben Grasset via fpc-devel wrote: It does work on 64-bit Windows, it's just technically deprecated. Beyond that, the 80-bit Extended type dates back to the mid 1980s, The year 1980, not the mid 1980s. But the x86 family dates back to 1978. Most x86_64 instructions are the same as the ones, introduced in 1978, but with an added prefix to indicate they're 64-bit. and ran on a particular part of the processor (the FPU, or Floating Point Unit), Ran on an optional separate coprocessor chip, called Intel 8087. It was succeeded by 80187, 80287, 80387 and 80487. It was actually integrated into the CPU with the 486DX CPU, but the 486SX had no FPU (in fact, it was disabled). And the 487 was actually a 486DX in a different socket, that took full control of the system as soon as it was installed, while the 486SX on the motherboard was switched off. The Pentium was the first CPU that always had the FPU integrated. in such a way that it was able to provide a somewhat higher amount of precision than the 64-bit "Double" type that's most commonly used today. That said, the operations involved generally weren't / aren't nearly as efficient as the vector based SSE2+ ones used for 32-bit and 64-bit floats. So it fell out of favor for most use cases, outside of certain things like scientific code that actually needs the highest amount of precision possible even at the detriment of efficiency. We do care about scientific code as well as fast code, that's why we support both the FPU and SSE2+ (as well as AVX, etc.). I'd personally argue that anyone writing code today that actually needs true 80-bit extended already certainly is likely to know what they're doing as far as tooling, thus meaning the majority of users are fairly unlikely to ever encounter any problems that directly relate to it. Floating point precision bugs, caused by loss of precision are evil, because the code works most of the time during testing, but they can still cause intermittent faults, which can be catastrophic. Ariane 5 is a notable example. On Wed, Jan 12, 2022 at 11:08 PM Travis Siegel via fpc-devel wrote: On 1/12/2022 5:20 PM, Sven Barth via fpc-devel wrote: When compiling from a target supporting Extended to one only supporting Double there isn't a loss of precision when calculating values at compile time. The other way around however, there *is* and that is the more crucial problem. Regards, Sven /I understand only part of this issue. 64-bit windows doesn't have extended support, is there a reason for this? If it's simply processors, and it works on linux, why does it not work on windows?/ /Also, since it's 64-bit, wouldn't a double on a 64-bit system match or exceed the numeric range on an extended range for a 32-bit system?/ /I'm no expert on compiler numeric ranges, and 32/64 ranges aren't something I've studied a whole lot of, other than to note that 64-bit processors can handle *much* larger numbers, so I don't understand why this problem exists./ /Is there a summary of why this is a problem anywhere I can refer to so I can understand why this happens, and what (if anything) can be done to solve it?/ /I've always been fascinated by compilers, though I've never actually written anything except an assembler for dos several years ago, I was never able to extend that to other languages, because of lack of knowledge of how the cpu does things, but this is still an interesting topic for me, and I honestly can't figure out why there would be an issue at all./ /I'm not doubting there is one, I'm just missing a piece or two to understand it./ /Any help would be appreciated. / ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist -fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On 1/13/22 05:59, Travis Siegel via fpc-devel wrote: On 1/12/2022 5:20 PM, Sven Barth via fpc-devel wrote: When compiling from a target supporting Extended to one only supporting Double there isn't a loss of precision when calculating values at compile time. The other way around however, there *is* and that is the more crucial problem. Regards, Sven /I understand only part of this issue. 64-bit windows doesn't have extended support, is there a reason for this? If it's simply processors, and it works on linux, why does it not work on windows?/ /Also, since it's 64-bit, wouldn't a double on a 64-bit system match or exceed the numeric range on an extended range for a 32-bit system?/ /I'm no expert on compiler numeric ranges, and 32/64 ranges aren't something I've studied a whole lot of, other than to note that 64-bit processors can handle *much* larger numbers, so I don't understand why this problem exists./ /Is there a summary of why this is a problem anywhere I can refer to so I can understand why this happens, and what (if anything) can be done to solve it?/ /I've always been fascinated by compilers, though I've never actually written anything except an assembler for dos several years ago, I was never able to extend that to other languages, because of lack of knowledge of how the cpu does things, but this is still an interesting topic for me, and I honestly can't figure out why there would be an issue at all./ /I'm not doubting there is one, I'm just missing a piece or two to understand it./ /Any help would be appreciated. / The i386 compiler uses the x87 FPU for floating point. The x87 supports the 32-bit single precision floating point type, the 64-bit double precision floating point type and the 80-bit extended precision extended floating point type. So, the best precision you get is 80-bit. The x86_64 compiler uses SSE2 instructions for floating point. However, the SSE2 instructions only support 32-bit and 64-bit float types. X86_64 processors still have the FPU, and it still functions in 64-bit mode, so the x86_64 compiler can still use the FPU for the 80-bit extended type. In fact, this is why the linux x86_64 compiler works without limitations. However, Windows doesn't guarantee future compatibility if the FPU is used. https://docs.microsoft.com/en-us/windows/win32/dxtecharts/sixty-four-bit-programming-for-game-developers?redirectedfrom=MSDN#Porting_to_64bit Quote: "The x87, MMX, and 3DNow! instruction sets are deprecated in 64-bit modes. The instructions sets are still present for backward compatibility for 32-bit mode; however, to avoid compatibility issues in the future, their use in current and future projects is discouraged." A logical question that follows is how can they break it in future Windows versions, if it's supported by the CPU. The answer is, since Windows is a multitasking operating system, they might stop saving the FPU registers when switching between 64-bit tasks. So, the only guarantee that x87 FPU code will continue to work in future Windows versions is if it's in a 32-bit process. It kinda sucks, but it is what it is. Microsoft have decided that the FPU is considered "legacy" and "deprecated". However, the replacement (SSE2) doesn't have all the capabilities that the FPU has, namely it doesn't have 80-bit extended precision. I guess, you can complain to Microsoft about that and not to Free Pascal developers, but I doubt that they will care. :) Nikolay ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
It does work on 64-bit Windows, it's just technically deprecated. Beyond that, the 80-bit Extended type dates back to the mid 1980s, and ran on a particular part of the processor (the FPU, or Floating Point Unit), in such a way that it was able to provide a somewhat higher amount of precision than the 64-bit "Double" type that's most commonly used today. That said, the operations involved generally weren't / aren't nearly as efficient as the vector based SSE2+ ones used for 32-bit and 64-bit floats. So it fell out of favor for most use cases, outside of certain things like scientific code that actually needs the highest amount of precision possible even at the detriment of efficiency. I'd personally argue that anyone writing code today that actually needs true 80-bit extended already certainly is likely to know what they're doing as far as tooling, thus meaning the majority of users are fairly unlikely to ever encounter any problems that directly relate to it. On Wed, Jan 12, 2022 at 11:08 PM Travis Siegel via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > > On 1/12/2022 5:20 PM, Sven Barth via fpc-devel wrote: > > When compiling from a target supporting Extended to one only supporting > Double there isn't a loss of precision when calculating values at compile > time. The other way around however, there *is* and that is the more crucial > problem. > > Regards, > Sven > > *I understand only part of this issue. 64-bit windows doesn't have > extended support, is there a reason for this? If it's simply processors, > and it works on linux, why does it not work on windows?* > > *Also, since it's 64-bit, wouldn't a double on a 64-bit system match or > exceed the numeric range on an extended range for a 32-bit system?* > > *I'm no expert on compiler numeric ranges, and 32/64 ranges aren't > something I've studied a whole lot of, other than to note that 64-bit > processors can handle *much* larger numbers, so I don't understand why this > problem exists.* > > *Is there a summary of why this is a problem anywhere I can refer to so I > can understand why this happens, and what (if anything) can be done to > solve it?* > > *I've always been fascinated by compilers, though I've never actually > written anything except an assembler for dos several years ago, I was never > able to extend that to other languages, because of lack of knowledge of how > the cpu does things, but this is still an interesting topic for me, and I > honestly can't figure out why there would be an issue at all.* > > *I'm not doubting there is one, I'm just missing a piece or two to > understand it.* > > > *Any help would be appreciated. * > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On 1/12/2022 5:20 PM, Sven Barth via fpc-devel wrote: When compiling from a target supporting Extended to one only supporting Double there isn't a loss of precision when calculating values at compile time. The other way around however, there *is* and that is the more crucial problem. Regards, Sven /I understand only part of this issue. 64-bit windows doesn't have extended support, is there a reason for this? If it's simply processors, and it works on linux, why does it not work on windows?/ /Also, since it's 64-bit, wouldn't a double on a 64-bit system match or exceed the numeric range on an extended range for a 32-bit system?/ /I'm no expert on compiler numeric ranges, and 32/64 ranges aren't something I've studied a whole lot of, other than to note that 64-bit processors can handle *much* larger numbers, so I don't understand why this problem exists./ /Is there a summary of why this is a problem anywhere I can refer to so I can understand why this happens, and what (if anything) can be done to solve it?/ /I've always been fascinated by compilers, though I've never actually written anything except an assembler for dos several years ago, I was never able to extend that to other languages, because of lack of knowledge of how the cpu does things, but this is still an interesting topic for me, and I honestly can't figure out why there would be an issue at all./ /I'm not doubting there is one, I'm just missing a piece or two to understand it./ /Any help would be appreciated. / ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On Wed, Jan 12, 2022 at 8:08 AM Bart via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > It provides 32-bit fpc (so it builds for 32-bit windows by default) > and the win32->win64 crosscompiler in a single installer. > In Lazarus that means that you can target Win32 (default) and Win64 > without any problem. > The archives that are actually provided *by* the Lazarus team solve that problem in an IMO more sensible way already, though. That is, rather than having to use strictly 32-bit executables even when running on and targeting 64-bit, you can just add the 32-bit optional cross binaries seen below to an otherwise entirely 64-bit installation: [image: 32BitExecutables.png] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On Wed, Jan 12, 2022 at 7:38 AM Martin Frb via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > > The downloads provided by Lazarus are also NOT a "pure, native 64-bit > download". Only the "fpc.exe" and the non-cross "ppc64.exe" are native > 64 bit. > > As I said, I do not know, what is currently provided by the Fpc > "combined 32-/64-bit download". > No Idea, if any of the fpc/ppc executable in this download are already > 64-bit. > Every single executable that actually originates from the FPC toolchain (so like `fpc.exe`, `ppcx64.exe`, `ppudump.exe`, `pas2js.exe`, `h2pas.exe`, and so on) contained in the current "lazarus-2.2.0-fpc-3.2.2-win64.exe" installer that the Lazarus website directs to when you click "Download Now" on a system running 64-bit Windows *IS* currently 64-bit. I just verified this myself. That particular installer does not include any cross compilers at all, also (the ones to target 32-bit Windows from 64-bit come in the smaller "lazarus-2.2.0-fpc-3.2.2-cross-i386-win32-win64.exe" installer. On Wed, Jan 12, 2022 at 7:55 AM Tomas Hajny via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Wrong - applies only to the Win64 target, whereas e.g. 64-bit Linux > (supported by the same compiler targetting 64-bit code) supports > extended. This means that compiling source code with this compiler may > result in a different binary as soon as there's e.g. an extended > contstant included in the source code, or any compile-time calculations > in this precision need to be performed. Isn't this specifically the kind of thing that the `FPC_SOFT_FPUX80` define solves? FPC does not even let you go from 64-bit Windows to 32-bit targets if that define isn't active IIRC, so presumably the same thing could be made the case in other scenarios if it's something people are widely concerned about. In any case, people who want native 64-bit Windows toolchains want them pretty much exclusively for use *on *64-bit Windows to *target* 64-bit Windows, and will install any cross-compilers secondarily *if *they have a use for them. The 32-bit-to-64-bit Windows FPC toolchain is *not *a perfect drop-in replacement. Based on testing I did locally previously, it's not as fast as the native 64-bit one, and additionally there are other things to keep in mind like the 4GB RAM limit on 32-bit (which I have in fact seen more than one user on the Lazarus forums run into with larger projects, none of whom were using the 32-bit executables "on purpose"). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On Wed, 12 Jan 2022, Mattias Gaertner via fpc-devel wrote: On Wed, 12 Jan 2022 23:20:34 +0100 Sven Barth via fpc-devel wrote: [..] When compiling from a target supporting Extended to one only supporting Double there isn't a loss of precision when calculating values at compile time. The other way around however, there *is* and that is the more crucial problem. I'm curious, do other cross compilers like gcc have similar problems? How do they solve it? Does C have an extended type ? I thought they had only single and double ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On Wed, 12 Jan 2022 23:20:34 +0100 Sven Barth via fpc-devel wrote: >[..] > When compiling from a target supporting Extended to one only > supporting Double there isn't a loss of precision when calculating > values at compile time. The other way around however, there *is* and > that is the more crucial problem. I'm curious, do other cross compilers like gcc have similar problems? How do they solve it? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
Am 12.01.2022 um 19:26 schrieb Martin Frb via fpc-devel: On 12/01/2022 18:48, Sven Barth via fpc-devel wrote: [2] From the users view "random", in that the user can not predict all the factors that will affect the selection. Currently the user must be prepared for the latter. No, it is deterministic, it's simply different from a native x86_64-linux compilation or one from Win32 as mentioned above and that is bad. You completely missed the point. I was NOT comparing Win vs Linux I wrote And this is not comparing the behaviour between the Linux and Windows exe (both 64 bit). I agree that different behaviour must be expected. This is the behaviour between compiling the same code, with the same compiler, several times for the same target win-64. Note the 2nd line. - The exact same pascal code - The exact same 32-bit ppcx64.exe - the exact same target: Only compiling to 64-bit Windows exe Changing only compiler options (e.g. optimizations), could possible trigger a behavioural change in the resulting exe. Because some calculation changed between being compiled to run-time or compile-time. No, at least not in the general case if the optimizations are bug free. The only optimizations that might lead to behavior difference with the above mentioned points are those of -O4 (cause those might make use of undefined behavior) or $FASTMATH and both are true for any platform. => ok, I have not deep enough insight into the optimizer, maybe constant-propagation is 100% independent of any option passed to the compiler. Maybe constant-propagation will be the same at a levels of optimization But, also none functional changes such as const c = extended(1.234567997807) var a, b: extended; begin a := c; ... b := c + a; changed to b:= c+c; This is still the same code. There is no reason for a user to assume the result should change. But, depending on the code in between, I have seen cases were "c+a" was done run-time. While "c+c" should be compile time. So, maybe it's not byte by byte the same pascal code. But from a functional point of view, it is the same code. When compiling from a target supporting Extended to one only supporting Double there isn't a loss of precision when calculating values at compile time. The other way around however, there *is* and that is the more crucial problem. Regards, Sven___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On 12/01/2022 18:48, Sven Barth via fpc-devel wrote: [2] From the users view "random", in that the user can not predict all the factors that will affect the selection. Currently the user must be prepared for the latter. No, it is deterministic, it's simply different from a native x86_64-linux compilation or one from Win32 as mentioned above and that is bad. You completely missed the point. I was NOT comparing Win vs Linux I wrote And this is not comparing the behaviour between the Linux and Windows exe (both 64 bit). I agree that different behaviour must be expected. This is the behaviour between compiling the same code, with the same compiler, several times for the same target win-64. Note the 2nd line. - The exact same pascal code - The exact same 32-bit ppcx64.exe - the exact same target: Only compiling to 64-bit Windows exe Changing only compiler options (e.g. optimizations), could possible trigger a behavioural change in the resulting exe. Because some calculation changed between being compiled to run-time or compile-time. => ok, I have not deep enough insight into the optimizer, maybe constant-propagation is 100% independent of any option passed to the compiler. Maybe constant-propagation will be the same at a levels of optimization But, also none functional changes such as const c = extended(1.234567997807) var a, b: extended; begin a := c; ... b := c + a; changed to b:= c+c; This is still the same code. There is no reason for a user to assume the result should change. But, depending on the code in between, I have seen cases were "c+a" was done run-time. While "c+c" should be compile time. So, maybe it's not byte by byte the same pascal code. But from a functional point of view, it is the same code. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
Martin Frb via fpc-devel schrieb am Mi., 12. Jan. 2022, 18:06: > On 12/01/2022 17:31, Tomas Hajny via fpc-devel wrote: > > On 2022-01-12 16:03, Martin Frb via fpc-devel wrote: > >> > >> > >> But, if any change to the code (not even necessarily a functional > >> change) would allow the compiler to do those calculations at compile > >> time, then the value changes. And the entire behaviour of the app may > >> change. > >> Possible, this could even be a change just in optimization settings > >> (or upgrading FPC), allowing the compiler to to propagate constants... > >> > >> So does that mean, any code (that is to be compiled for Win-64bit) is > >> considered "unstable" if it contains "extended" ? > > > > Not necessarily - when targetting Win64, the user needs to be prepared > > for the lower precision. However, imagine that that the user compiles > > his source code for target x86_64-linux. The resulting binary and its > > output will be exactly the same if the source code is compiled (with > > the same options, etc.) on Linux or if it is compiled on Windows using > > a Win32 hosted compiler, but it will differ if using a Win64 hosted > > compiler. From compiler support point of view, this is an issue. > > Ok. So a question of priority. (E.g., reducing maintenance on tests?) > No, it's a question of unnecessary support we want. We already had users that complained that their code compiled from Win64 to x86_64-linux behaved differently than if compiled from Win32 or from x86_64-linux. We don't want to promote (and support) a compiler that doesn't produce the same code as the other two variants. > >> when targetting Win64, the user needs to be prepared for the lower > precision > Yes, but It is one thing to be prepared for: > - One (exactly one) "lower precision", and all behaviour (on that > platform [1]) to be always according to that specific precision. > > [1] on that platform, with that exact revision of the compiler. > But with any compile options, and independent of none functional > changes to the users code. > > It is another thing to be prepared for > - A random[2] "precision" that will change depending on compiler options > and/or seemingly unrelated changes in the user's code > > [2] From the users view "random", in that the user can not predict all > the factors that will affect the selection. > > > Currently the user must be prepared for the latter. > No, it is deterministic, it's simply different from a native x86_64-linux compilation or one from Win32 as mentioned above and that is bad. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On 12/01/2022 17:31, Tomas Hajny via fpc-devel wrote: On 2022-01-12 16:03, Martin Frb via fpc-devel wrote: But, if any change to the code (not even necessarily a functional change) would allow the compiler to do those calculations at compile time, then the value changes. And the entire behaviour of the app may change. Possible, this could even be a change just in optimization settings (or upgrading FPC), allowing the compiler to to propagate constants... So does that mean, any code (that is to be compiled for Win-64bit) is considered "unstable" if it contains "extended" ? Not necessarily - when targetting Win64, the user needs to be prepared for the lower precision. However, imagine that that the user compiles his source code for target x86_64-linux. The resulting binary and its output will be exactly the same if the source code is compiled (with the same options, etc.) on Linux or if it is compiled on Windows using a Win32 hosted compiler, but it will differ if using a Win64 hosted compiler. From compiler support point of view, this is an issue. Ok. So a question of priority. (E.g., reducing maintenance on tests?) Not to say, that due to ABI different registers may be used. Triggering different subsequent optimizations. And yes, I can see your point. That exact problem, that a bug in the optimizer manifested on windows, but not linux has cost me several weeks. (Because I could not get it with valgrind). So, I do get, that trying to minimize such things, is very appealing. - >> when targetting Win64, the user needs to be prepared for the lower precision Yes, but It is one thing to be prepared for: - One (exactly one) "lower precision", and all behaviour (on that platform [1]) to be always according to that specific precision. [1] on that platform, with that exact revision of the compiler. But with any compile options, and independent of none functional changes to the users code. It is another thing to be prepared for - A random[2] "precision" that will change depending on compiler options and/or seemingly unrelated changes in the user's code [2] From the users view "random", in that the user can not predict all the factors that will affect the selection. Currently the user must be prepared for the latter. Because if for example anything changes that affects constant propagation, calculation may move from run to compile time, or vice versa. And with that the used "precision" for an individual calculation will change. The user may not be able to predict under which conditions that happens. So for the user there are random changes to the behaviour of his program. And this is not comparing the behaviour between the Linux and Windows exe (both 64 bit). I agree that different behaviour must be expected. This is the behaviour between compiling the same code, with the same compiler, several times for the same target win-64. Changing a compiler option, will/can change the behaviour of the resulting exe. Such "optimization" depend changes normally happen, if - the code has (hidden) bugs - the code uses undocumented behaviour But I believe "extended" is documented. - Just to say, I am not saying it has to be changed. Really does not matter to me. Just trying to fully understand the matter, the possible side effects (of either path that can be taken), and so on. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On 2022-01-12 16:03, Martin Frb via fpc-devel wrote: On 12/01/2022 13:55, Tomas Hajny via fpc-devel wrote: - The problem is *NOT* a native 64 bit "ppcx64.exe" ? => 64 bit compiled targets don't require "extended" from the ppc, as they themself wont have support for it? Wrong - applies only to the Win64 target, whereas e.g. 64-bit Linux (supported by the same compiler targetting 64-bit code) supports extended. This means that compiling source code with this compiler may result in a different binary as soon as there's e.g. an extended contstant included in the source code, or any compile-time calculations in this precision need to be performed. Ok, I was too unspecific, I indeed just meant a 64-bit Window ppcx64.exe to compile a 64 bit target Windows app. But indeed, I did not think about compile-time evaluations. Those will indeed differ. Leaving the question if it is in that case actually desired that they are done in "extended" precision. Imagine some code (targeted at Win-64) that uses "extended" (which will at runtime become "double"? Or at least be less precise than "extended"). Now if that code, does some calculations with those values, and the code is written so the calculations happen at runtime => then the calculations are done at lower precision. This would potentially affect the result. I guess that would be expected behaviour. But, if any change to the code (not even necessarily a functional change) would allow the compiler to do those calculations at compile time, then the value changes. And the entire behaviour of the app may change. Possible, this could even be a change just in optimization settings (or upgrading FPC), allowing the compiler to to propagate constants... So does that mean, any code (that is to be compiled for Win-64bit) is considered "unstable" if it contains "extended" ? Not necessarily - when targetting Win64, the user needs to be prepared for the lower precision. However, imagine that that the user compiles his source code for target x86_64-linux. The resulting binary and its output will be exactly the same if the source code is compiled (with the same options, etc.) on Linux or if it is compiled on Windows using a Win32 hosted compiler, but it will differ if using a Win64 hosted compiler. From compiler support point of view, this is an issue. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On 12/01/2022 13:55, Tomas Hajny via fpc-devel wrote: - The problem is *NOT* a native 64 bit "ppcx64.exe" ? => 64 bit compiled targets don't require "extended" from the ppc, as they themself wont have support for it? Wrong - applies only to the Win64 target, whereas e.g. 64-bit Linux (supported by the same compiler targetting 64-bit code) supports extended. This means that compiling source code with this compiler may result in a different binary as soon as there's e.g. an extended contstant included in the source code, or any compile-time calculations in this precision need to be performed. Ok, I was too unspecific, I indeed just meant a 64-bit Window ppcx64.exe to compile a 64 bit target Windows app. But indeed, I did not think about compile-time evaluations. Those will indeed differ. Leaving the question if it is in that case actually desired that they are done in "extended" precision. Imagine some code (targeted at Win-64) that uses "extended" (which will at runtime become "double"? Or at least be less precise than "extended"). Now if that code, does some calculations with those values, and the code is written so the calculations happen at runtime => then the calculations are done at lower precision. This would potentially affect the result. I guess that would be expected behaviour. But, if any change to the code (not even necessarily a functional change) would allow the compiler to do those calculations at compile time, then the value changes. And the entire behaviour of the app may change. Possible, this could even be a change just in optimization settings (or upgrading FPC), allowing the compiler to to propagate constants... So does that mean, any code (that is to be compiled for Win-64bit) is considered "unstable" if it contains "extended" ? Of course if the above conclusions are correct, the choice for such code is - sometimes (depending on various hard to predict factors) differ from 32 bit version i.e. compiling to 64 bit: ending up, at different times, with either one of two (or more) different behaviours - always differ from the 32bit version i.e. compiling to 64 bit: ending up, with one and only one behaviours (although diff from 32 bit) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On Wed, Jan 12, 2022 at 1:38 PM Martin Frb via fpc-devel wrote: > As I said, I do not know, what is currently provided by the Fpc > "combined 32-/64-bit download". > No Idea, if any of the fpc/ppc executable in this download are already > 64-bit. It provides 32-bit fpc (so it builds for 32-bit windows by default) and the win32->win64 crosscompiler in a single installer. In Lazarus that means that you can target Win32 (default) and Win64 without any problem. Previously you had to install the win32->win64 crosscompiler as a separate download. So, presonally I really welcome this "combined" installer. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On 2022-01-12 13:38, Martin Frb via fpc-devel wrote: On 12/01/2022 11:51, Marco van de Voort via fpc-devel wrote: On 12-1-2022 11:38, Ben Grasset via fpc-devel wrote: If it's actually now somehow the case that an offer to provide Win64 builds would be refused though, I guess maybe I'll look into hosting them myself somewhere else? Although again I don't get why it would be fine for Linux to have a zillion archives for different configurations here: https://sourceforge.net/projects/freepascal/files/Linux/3.2.2/ As said, Windows 64-bit is a special case because it doesn't support/recommend extended. This makes cross compiling to targets that do difficult till we have softfloat support. Ok, let me throw in my 2 cents here . . - The problem is *NOT* a native 64 bit "ppcx64.exe" ? => 64 bit compiled targets don't require "extended" from the ppc, as they themself wont have support for it? Wrong - applies only to the Win64 target, whereas e.g. 64-bit Linux (supported by the same compiler targetting 64-bit code) supports extended. This means that compiling source code with this compiler may result in a different binary as soon as there's e.g. an extended contstant included in the source code, or any compile-time calculations in this precision need to be performed. So up to this point, afaik there would be no problem, having those executables as 64-bit exe? . . There would, see above. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On 12/01/2022 11:51, Marco van de Voort via fpc-devel wrote: On 12-1-2022 11:38, Ben Grasset via fpc-devel wrote: If it's actually now somehow the case that an offer to provide Win64 builds would be refused though, I guess maybe I'll look into hosting them myself somewhere else? Although again I don't get why it would be fine for Linux to have a zillion archives for different configurations here: https://sourceforge.net/projects/freepascal/files/Linux/3.2.2/ As said, Windows 64-bit is a special case because it doesn't support/recommend extended. This makes cross compiling to targets that do difficult till we have softfloat support. Ok, let me throw in my 2 cents here Before I start: - I have my own builds (so I do not depend on the outcome if this discussion) - I am the one building the before-mentioned 64bit builds included in the Laz installer. ==> There may be some misunderstanding/oversight about those builds (see 2nd section of this mail) - I have *not* downloaded the FPC from the link in the "Windows 64 bit section" (or quoting Sven: "combined 32-/64-bit download") https://www.freepascal.org/down/x86_64/win64.html ===> https://sourceforge.net/projects/freepascal/files/Win32/3.2.2/ I have no idea, what bitness the provided ppcx64.exe has. (i.e., the non-cross-compile ppc). --- Afaik (ignoring any effort for extra builds required): - The problem is *NOT* a native 64 bit "fpc.exe" ? => this only calls a ppc*.exe - The problem is *NOT* a native 64 bit "ppcx64.exe" ? => 64 bit compiled targets don't require "extended" from the ppc, as they themself wont have support for it? So up to this point, afaik there would be no problem, having those executables as 64-bit exe? --- So the problem is about cross-compiling. Because such a cross compiler, needs to support "extended". And here is what no-one has ever mentioned, when they refer to the "64bit fpc" included in Lazarus. The cross compiler for compiling a "32bit exe" on a "64bit-development-system": => lazarus-2.2.0- fpc-3.2.2-cross-i386-win32 -win64.exe < == *** This contains a 32-bit "ppc386.exe" compiler *** The "ppc386.exe" can do "extended", because it is a 32 bit exe. Even though it is part of a 64bit download, and indented to run on a 64bit system. About the name "ppc386.exe" versus "ppccross386.exe": For some reason this is the name that "fpc.exe" is looking for, when called with "-Twin32 -Pi386". (At least it works in Lazarus) --- On 19/12/2021 09:45, Sven Barth via fpc-devel wrote: There is already a combined 32-/64-bit download available since 3.2.2. We *won't* provide a pure, native 64-bit download for Win64, because the x86_64-win64 is not suitable for other x86_64 targets or for compiling a i386 or i8064 cross compiler due to the missing Extended support. The downloads provided by Lazarus are also NOT a "pure, native 64-bit download". Only the "fpc.exe" and the non-cross "ppc64.exe" are native 64 bit. As I said, I do not know, what is currently provided by the Fpc "combined 32-/64-bit download". No Idea, if any of the fpc/ppc executable in this download are already 64-bit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On 12-1-2022 11:38, Ben Grasset via fpc-devel wrote: If it's actually now somehow the case that an offer to provide Win64 builds would be refused though, I guess maybe I'll look into hosting them myself somewhere else? Although again I don't get why it would be fine for Linux to have a zillion archives for different configurations here: https://sourceforge.net/projects/freepascal/files/Linux/3.2.2/ As said, Windows 64-bit is a special case because it doesn't support/recommend extended. This makes cross compiling to targets that do difficult till we have softfloat support. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
If it's actually now somehow the case that an offer to provide Win64 builds would be refused though, I guess maybe I'll look into hosting them myself somewhere else? Although again I don't get why it would be fine for Linux to have a zillion archives for different configurations here: https://sourceforge.net/projects/freepascal/files/Linux/3.2.2/ but in some way bad to add one more to the windows files directory on the Sourceforge page. On Wed, Jan 12, 2022 at 5:32 AM Ben Grasset wrote: > On Sun, Dec 19, 2021 at 3:46 AM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Ben Grasset via fpc-devel schrieb am >> So., 19. Dez. 2021, 08:33: >> >>> To be very clear, to me, this is absolutely nothing more than just a >>> matter of building the compiler completely normally. It takes like two >>> minutes all-in. I don't really get why the person who uploads the 32-bit >>> Windows builds currently doesn't just also upload 64-bit ones. They could >>> even just use the native 64-bit builds Lazarus already includes. Anyways, >>> yeah. I'd like to actually make this happen, next time around. >>> >> >> There is already a combined 32-/64-bit download available since 3.2.2. We >> *won't* provide a pure, native 64-bit download for Win64, because the >> x86_64-win64 is not suitable for other x86_64 targets or for compiling a >> i386 or i8064 cross compiler due to the missing Extended support. Until FPC >> provides the necessary code to emulate 80-bit floating point we simply >> avoid this potential headache by not providing it. >> As this has been discussed ad nauseam already, this decision is not up >> for discussion. >> >> Regards, >> Sven >> >>> ___ >> fpc-devel maillist - fpc-devel@lists.freepascal.org >> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > > > Explicitly *not *wanting to provide a native x86_64 bit build was not > ever mentioned by anyone previously in any discussion I was involved in > actually. Quite the opposite IIRC. I also fail to see how that makes any > sense, personally. It just means continuing to tell everyone who wants > native Win64 (which is very many people) "either download Lazarus or use > FPCUpDeluxe". > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On Sun, Dec 19, 2021 at 3:46 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Ben Grasset via fpc-devel schrieb am > So., 19. Dez. 2021, 08:33: > >> To be very clear, to me, this is absolutely nothing more than just a >> matter of building the compiler completely normally. It takes like two >> minutes all-in. I don't really get why the person who uploads the 32-bit >> Windows builds currently doesn't just also upload 64-bit ones. They could >> even just use the native 64-bit builds Lazarus already includes. Anyways, >> yeah. I'd like to actually make this happen, next time around. >> > > There is already a combined 32-/64-bit download available since 3.2.2. We > *won't* provide a pure, native 64-bit download for Win64, because the > x86_64-win64 is not suitable for other x86_64 targets or for compiling a > i386 or i8064 cross compiler due to the missing Extended support. Until FPC > provides the necessary code to emulate 80-bit floating point we simply > avoid this potential headache by not providing it. > As this has been discussed ad nauseam already, this decision is not up for > discussion. > > Regards, > Sven > >> ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel Explicitly *not *wanting to provide a native x86_64 bit build was not ever mentioned by anyone previously in any discussion I was involved in actually. Quite the opposite IIRC. I also fail to see how that makes any sense, personally. It just means continuing to tell everyone who wants native Win64 (which is very many people) "either download Lazarus or use FPCUpDeluxe". ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
