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 Fri, Jan 14, 2022 at 5:49 AM Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > No, it's not, because in linux I tested "make -j24 all" in the compiler > directory > That isn't what you said in your original comment about benchmarking on Linux. You specified "make cycle", which is what I was going off of. ___ 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 Fri, Jan 14, 2022 at 11:09 AM Ben Grasset wrote: > It was the SEH MinGW-w64 based GCC 11.2 that MSYS2 provides through their > Windows version of pacman. > Also, more accurately, I should have said before that the *precision *of "long double" is 80-bit and equivalent to FPC's "extended" with GCC and Clang on Windows x64. The data type storage size is actually larger though (128 bits). ___ 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 Fri, Jan 14, 2022 at 10:46 AM Marco van de Voort via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Did you test a windows gcc (win64 SEH) or a SJLJ "posix" (basically > unported Unix) gcc ? > It was the SEH MinGW-w64 based GCC 11.2 that MSYS2 provides through their Windows version of pacman. ___ 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 Fri, Jan 14, 2022 at 1:33 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > So Delphi went the same way as we did. > I'd say Delphi imitating MSVC is sort of to be expected though, whereas *usually *FPC makes similar choices to GCC. ___ 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 Fri, Jan 14, 2022 at 1:27 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > (though to be fair it does the same on 32-bit as well) > Yeah, MSVC (for some reason) universally defines "long double" as exactly an alias for regular 64-bit double, whereas GCC and Clang (more correctly IMO) define it as an 80-bit type equivalent to FPC's traditional "extended". So even on 32-bit with MSVC you have to hand-write assembly to make use of x87 FPU instructions. ___ 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 Thu, Jan 13, 2022 at 11:38 PM Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > For the record, I did try make cycle for ppc386 and ppcx64 on my Windows > 10 (with Windows Defender turned on) and both finished in exactly 42 > seconds :) > Not surprising that you closed the gap a bit with your 5900X IMO, although that's still a decent improvement over both of your Linux results. I do think probably linking with GNU LD isn't as fast in most cases as linking internally, as I mentioned before. Though using LLD or mold instead of LD might be a different story. ___ 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 Thu, Jan 13, 2022 at 9:20 AM Travis Siegel via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > I wasn't aware of the whole MS not supporting the FPU thing, that was > the missing puzzle piece. > It's not a realistic concern in actuality. There's a reason almost every other compiler just continues to generate x87 FPU instructions on x64 Windows when appropriate the same way they do for whatever other platforms are supported. ___ 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 Thu, Jan 13, 2022 at 10:18 PM Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Just for the record, is this with antivirus off or on and which antivirus > program? > I have no anti-virus actively installed or enabled on an ongoing basis at all. I just occasionally do manual scans with Malwarebytes and such. Beyond that, Windows is installed on a SATA SSD (Samsung 860 Pro), and my RAM is 16GB DDR3-2400 CL10. ___ 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 Thu, Jan 13, 2022 at 9:48 AM Nikolay Nikolov via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
> What do other win64 compilers do? Do they generate x87 FPU code for 64-bit
> Windows?
>
Yes. Given the following:
#include
long double do_three(long double x, long double y, long double z) {
return (((x * x) / y) + z);
}
int main () {
printf("%d\n", sizeof(long double));
printf("%.19Lf\n", do_three(9.4567575785454772685L,
2.1211991522332311497L, 16.1216453784376343456L));
}
GCC 11.2 produces this assembly with "gcc -O3 -march=native -S test.c" on
64-bit Windows 10:
do_three:
.seh_endprologue
fldt (%rdx)
fldt (%r8)
fldt (%r9)
fxch %st(2)
movq %rcx, %rax
fmul %st(0), %st
fdivp %st, %st(1)
faddp %st, %st(1)
fstpt (%rcx)
ret
.seh_endproc
and Clang 13.0 produces this with the same command line arguments passed:
do_three: # @do_three
# %bb.0:
movq %rcx, %rax
fldt (%rdx)
fldt (%r8)
fldt (%r9)
fxch %st(2)
fmul %st, %st(0)
fdivp %st, %st(1)
faddp %st, %st(1)
fstpt (%rcx)
retq
Running the program prints this with both compilers:
16
58.2818846964779790909
So the answer to Mattias's question about C compilers from before is "they
just directly support it on Windows".
___
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 Thu, Jan 13, 2022 at 11:28 AM Nikolay Nikolov via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:
> So, instead of giving actual benchmark data on the Windows performance,
> you speculate by claiming that having faster exception handling matters,
> and then you immediately debunk your own argument by admitting it probably
> doesn't matter for the compilation speed.
>
I went ahead and tested "make cycle" for both ppcx64.exe and ppc386.exe,
using PowerShell's "Measure Command" for timing as it's the most accurate
method I'm aware of on Windows. Both results came in under one minute, and
the 64-bit compiler *was *faster, though not by a large amount for that
relatively short workload (I might test a full repo build later to see what
the differences are like between longer compilations). This also would seem
to show that what CPU you have basically stops mattering after a certain
point as far as FPC's performance goes, as mine is MUCH slower than yours
(i7-4790K clocked at 4.6GHz currently).
64-bit:
PS D:\fpclaz\FPCSource\compiler> Measure-Command {Start-Process make
-ArgumentList "cycle PP=D:\fpclaz\fpc\bin\x86_64-win64\ppcx64.exe" -Wait}
Days : 0
Hours : 0
Minutes : 0
Seconds : 52
Milliseconds : 815
Ticks : 528157597
TotalDays : 0.000611293515046296
TotalHours: 0.014671044361
TotalMinutes : 0.88026266167
TotalSeconds : 52.8157597
TotalMilliseconds : 52815.7597
32-bit:
PS D:\fpclaz\fpcsource\compiler> Measure-Command {Start-Process make
-ArgumentList "cycle PP=D:\fpclaz\fpc\bin\x86_64-win64\ppc386.exe" -Wait}
Days : 0
Hours : 0
Minutes : 0
Seconds : 56
Milliseconds : 873
Ticks : 568733659
TotalDays : 0.000658256549768519
TotalHours: 0.015798157194
TotalMinutes : 0.94788943167
TotalSeconds : 56.8733659
TotalMilliseconds : 56873.3659
___
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 Thu, Jan 13, 2022 at 3:28 AM Alexander Grotewohl via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > 32bit on Windows 64-bit uses Wow64.. which has a bit of overhead as an > emulation layer. I believe it's the same one they use for ARM64 too. > It should be kept in mind also that neither 32-bit or 64-bit FPC use GNU LD for linking on Windows by default, but rather FPC's internal one, and it's not hard to imagine why that might perform better on 64-bit as well. ___ 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 Thu, Jan 13, 2022 at 1:58 AM Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > I haven't tested in Windows, but it would be very strange and suspicious > if the results are very different. > It would be neither of those things. The exception handling on x64 Windows is the fastest provided by FPC, for example (though the compiler AFAIK avoids doing anything that would generate exception handling code within its own codebase as much as possible). On Thu, Jan 13, 2022 at 1:58 AM Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > A bug report with steps to reproduce would probably be nice. > That limit is a fundamental hardware limitation, not a bug. Not at all hard to imagine someone encountering it on 32-bit particularly if they're using Lazbuild for multi-threaded compilation. ___ 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 Thu, Jan 13, 2022 at 1:25 AM Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > 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.). > FPC *chooses *not to generate x87 FPU instructions on 64-bit Windows solely because "it's deprecated". There's no actual technical limitation in play for user-mode code as far as the OS support for it goes. On Thu, Jan 13, 2022 at 1:25 AM Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > 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. > I don't disagree with you, but you're missing my point, which is that there's trivial solutions for this other than mandating the use of an entirely 32-bit bit toolchain even for the common user who just wants to use a 64-bit toolchain to generate 64-bit applications on their own 64-bit operating system. Simply dropping a 32-bit copy of ppc386.exe into the bin folder of an otherwise all-64-bit FPC installation is all that's needed be able to build the 32-bit RTL and packages, and then start building 32-bit programs, for example. ___ 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 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
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
[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 web
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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on
Was browsing on the FPC wiki (that is, the actual wikipedia.com entry for FPC) today, and came across an edit someone had made in the "3.2.0" section that said the following: "FreePascal cannot be installed on macOS Catalina, and no known workaround exists." It then linked to an open issue on the FPCUpDeluxe github repository, suggesting that perhaps whoever made that edit literally thought FPCUpDeluxe was the *only* reasonable way to get FPC. They're partially right, and partially wrong, IMO. FPCUpDeluxe is an excellent tool that as far I'm concerned should be linked front-page on both the FPC and Lazarus official websites, because it frankly blows the "download archives from sourceforge" method of obtaining FPC out of the water, in general. With that said, there's also the elephant in the room that is the fact that Lazarus happily provides builds of FPC with it's releases that typically are "exactly what you want" for the platform in questions, which in many cases are *not* also provided as standalone FPC installer / archive downloads. For example, to this day there is *still* no natively-64-bit Windows download for FPC, for absolutely no reason. You instead either get silently linked to the 32-to-64-bit cross compiler on Sourceforge, or linked to pages that *explicitly* provide straight-up misinformation in saying "There is no native compiler available for x86_64 Win64. You have to use a cross compiler". That last quote is absolute BS, to be very frank. There is no reason whatsoever not to use a natively-64-bit copy of FPC if running a natively-64-bit copy of Windows, and there hasn't been for well over half a decade at this point. I've brought this up on this exact mailing list before, and was met with attitudes that seemed to suggest people for some unknown reason think "Linux x64 good and normal, Windows x64 bad, not normal, and unstable!". Is there a specific person I need to convince that 64-bit releases on ALL relevant platforms (Windows, Mac OSX, etc) are in fact incredibly essential? I've got a long, long, long list of "here's why you're wrong" talking points to provide to anyone who actually thinks I should be using the 32-to-64-bit cross compiler on Windows 10 x64. Lastly, it isn't even like this amounts to more work for anyone: Lazarus provides a native Win64 build of FPC along with the native Win64 build of it. I don't understand why that same build is not also provided as a standalone FPC release. Further, the FPC releases for Mac are still listed as being explicitly "Intel x86/i386" on the download page on the FPC website, despite the fact that AFAIK the image is for both 32-bit and 64-bit OSX. That platform specifically is where it REALLY needs to be made clear that FPC fully supports 64-bit applications on the latest version of the OS, considering that 32-bit applications are actively deprecated as far as Apple is concerned. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] What exactly are the differences in what each of the "-Cp", "-Cf", and "-Op" command line flags enable as far as optimizations?
Thanks a lot for the explanation, that's very helpful! On Mon, Sep 7, 2020 at 9:02 PM J. Gareth Moreton via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > The gist of it is that you're specifying the earliest CPU that your > program will run on (if it runs on an older CPU, it might crash with > SIGILL). -Cp dictates the instruction set version used overall, while -Cf > specifies the family of floating-point instructions that will be used. > Later versions of SSE have better rounding functions, for example, although > I think it's more applicable to i386 where the older floating-point stack > is used by default. > > Generally you'd set -Cp and -Op to the same value, and I think -Op is set > to match -Cp if it's omitted. I might need Florian to confirm though. I > have programmed one or two optimisations that depend on the value of -Op - > the one that springs to mind is where a group of MOV instructions are > morphed into an XCHG instruction - XCHG is slower than the 3 MOV > instructions until relatively recently, so it won't perform this > optimisation by default unless optimising for size or if -Op is set to a > particular value (I think at least "CoreI"). > > When vectorisation starts making a proper appearance in the compiler, I'll > be very likely developing optimisations for fused multiply-add (FMA), which > only came about after AVX. > > Gareth aka. Kit > On 08/09/2020 00:03, Ben Grasset via fpc-devel wrote: > > For example, a valid FPC command line would be: > > fpc -O3 -CfAVX2 -CpCOREAVX2 -OpCOREAVX2 file.pas > > To what extent is each of those flags enabling the generation of AVX2 > instructions? Are they all necessary, or does their functionality overlap > to some degree? Which is most important? > > ___ > fpc-devel maillist - > fpc-devel@lists.freepascal.orghttps://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > > > > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> > Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> > <#m_-4071735898273218845_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > ___ > 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] What exactly are the differences in what each of the "-Cp", "-Cf", and "-Op" command line flags enable as far as optimizations?
For example, a valid FPC command line would be: fpc -O3 -CfAVX2 -CpCOREAVX2 -OpCOREAVX2 file.pas To what extent is each of those flags enabling the generation of AVX2 instructions? Are they all necessary, or does their functionality overlap to some degree? Which is most important? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature announcement: constant parameters for generics
On Sun, Apr 26, 2020 at 4:08 AM Anthony Walter via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Thank you Ryan and Sven. Your work is much appreciated as usual. > > However, Michael beat me to it in asking how this feature is useful. I am > sure there might be use cases, but for right now I am coming up without any > real advantages. Could anyone with better insight than me please explain? > A simple, but IMO exciting use case is just that it can provide impossible-to-achieve-otherwise optimizations via const propagation. For example, some functions and procedures that used to have to take numerical values as regular parameters can now instead take them as generic constant parameters, which allows the compiler to "carry them farther" than it ever would have previously. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature announcement: constant parameters for generics
On Sat, Apr 25, 2020 at 6:14 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > The Free Pascal team is happy to announce the addition of a new language > feature: constant parameters for generics. > YES! This is fantastic news. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Looking for insight on the current status (or rather, non-status) of the {$CLASSESINLINE} define
It's not clear to me how many people are specifically aware of this, but as it stands currently, each and every instance of the "inline" modifier in the Classes unit is hidden behind a CLASSESINLINE define. Unlike the SYSTEMINLINE and MATHINLINE defines (which are always set automatically in-source when building FPC), the CLASSESINLINE define is not set anywhere, at any time. What this means of course is that currently, literally nothing in the entire Classes unit is inlined, at all, ever. IMO this is a Very Bad Thing for reasons that I feel like are probably obvious to most people. So my question is, do any of the people currently reading this mailing list know *why* this is the case? (Note, I'm aware it's possible that there is no real reason and it's simply just an accidental oversight.) If there *is* (or at least was in the past) a specific reason though, what exactly is / was it, and more importantly is it known to be still relevant on any particular platform? At least on x86-64 Windows, for example, building FPC with this define manually set by me causes no issues, and results in the functions marked as such being inlined properly as expected. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Thank you!
On Sat, Nov 23, 2019 at 6:44 AM J. Gareth Moreton wrote: > So once > again, thank you everyone, and I hope to continue contributing for a > while yet! > Us users would say the same in reverse for your various improvements! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] inline... and philosophy
On Fri, Nov 8, 2019 at 10:02 AM J. Gareth Moreton wrote: > I guess that's the consequence of Microsoft Visual C++ having such a large > market share. > I mean, GCC is far more widely used than MSVC (and actually generates rather smaller binaries usually.) Also the Clang version of the MS compiler (clang-cl) is objectively better, honestly. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] inline... and philosophy
On Fri, Nov 8, 2019 at 8:28 AM J. Gareth Moreton wrote: > The large binary sizes feel like an elephant > in the room that no-one talks about. > Relatively speaking, FPC actually does very well as far as binary size for a language that specifically aims to have robust RTTI functionality. C++ binaries are often small simply because because it's quite normal in C++ to build with both exception handling and RTTI disabled entirely, for example. Against basically anything else FPC generally comes out significantly smaller, though. Ever seen the size of a Go binary? Or a Rust binary? Even their Helllo Worlds are non-trivially larger than FPC's. So I think no one talks about it essentially because FPC binaries are already exactly the size they logically should be, given the general goals of the language / compiler. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
