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.

Ben Grasset via fpc-devel schrieb am So.,
27. Sep. 2020, 07:50:

Yes, there is a reason: you can not build a i8086 or i386 cross compiler with the Win64 compiler (or any non-x86 compiler to be fair) due to missing Extended support. Thus the majority of the FPC Core team considers the Win64 compiler as inferior and also unnecessary cause the 32-bit one works just as well on that platform.

Regards,
Sven

As long as there is no generic 80 bit float support in the compiler, there is no need to discuss anything else.

Florian Klämpfl wrote

As long as there is no generic 80 bit float support in the compiler, there is no need to discuss anything else.

Yes. And unlike some other compilers, we don't exhaust our 32-bit address space during compilation or linking of very large programs, so the fact that it is a cross-compiler should be irrelevant to the user.

Regarding ease of installation, we're planning to release the Windows version of FPC 3.2.2 as a single install package, that supports both 32-bit and 64-bit Windows - it will include the 32-bit native and 32-bit to 64-bit crosscompiler, so it will be a single download for both Win32 and Win64.

The necessary changes for the that are already committed to trunk, but it will need testing during the beta and release candidate phases.

Nikolay

Just my 2 cents.

Well, one the one hand, native 64 bit is only really important if it can do something that 32 bit can not do. (faster, bigger sources, ....).

On the other hand, not everyone needs a win64 to win32 cross compiler. And if they do, a native 32bit compiler can be renamed and will happily serve as such a cross compiler. (But that is not a must be included / such workarounds may not be wanted, especially since they might cause repeated extra work)

So the question here is/are imho about the work it takes to amend the release-build process (i.e. update the scripts). And then the amount of extra time needed for each release (build and testing).

There's no known advantage of using a native win64 compiler, versus the win32 to win64 crosscompiler. There could be, if, while compiling very large programs, the 32-bit address space the compiler uses during compilation was exhausted (i.e. if the memory used by the compiler during compilation exceeds 4GB), and this happens AFAIK in C compilers, but, as far as we know, it just doesn't happen with FPC, because we don't use that much memory.

A win64 to win32 crosscompiler is crippled, because it doesn't support 80-bit extended float. That's why only a native win32 compiler is used to target win32.

Nikolay

The thing is: we would distribute a compiler (the x86_64-win64 one) which claims to be able to compile to e.g. to x86_64-linux, but it would generate programs which might behave differently than natively compiled ones as float constants are handled internally different.

And in this particular case, "different" means "less accurate", due to rounding errors, caused by compile time conversion of 80-bit extended float constants to 64-bit double precision constants. And "less accurate" is bad. :)

Nikolay

So we would need softfloat extended support. This is doable with one major obstacle: the "irrational" functions like ld, sin etc.: they need precise enough implementations for 80 bit (actually, just adding and using in the compiler 128 bit softfloat support would be even better). And this is probably something which is really hard. While I believe ;) I can solve most coding challenges, this is something I fear to touch :)

Well. Intel arch supports FMA instruction sets since 2013 (Intel) and since 2012 (AMD). See https://en.wikipedia.org/wiki/FMA_instruction_set

Based on FMA support it's quite easy to create 128 bits (almost) semi-soft floats. Julia guys have a nice library called DoubleFloats (https://github.com/JuliaMath/DoubleFloats.jl, MIT licensed) They have a lot of trigonometric and other "complex" stuff already implemented.

So, maybe it's not that frightening after all :)
See my own small port attached. Russian comments ahead so beware :)

-- Regards,
Denis Golovan

FPC supports for years (since 2014?) FMA intrinsic on CPUs having them.

Based on FMA support it's quite easy to create 128 bits (almost) semi-soft floats.

This is a half-backen solution imo. For the compiler IEEE compliant 128 bit floats are a must.

Julia guys have a nice library called DoubleFloats (https://github.com/JuliaMath/DoubleFloats.jl, MIT licensed)

We cannot use MIT licensed code in the rtl.

They have a lot of trigonometric and other "complex" stuff already implemented. So, maybe it's not that frightening after all :)

See above. It perfectly shows why it is frightening (not the basic stuff, but the transcendent functions):
- there are little libraries being really IEEE compliant for float128
- if they are IEEE compliant, their license does not allow to use the code in the FPC rtl.

Ok, the license is the problem.
However I still fail to see why full 128bit support is necessary for 80bit Extended.

-- Regards,
Denis Golovan

Not for 80 bit extended, but it would be the clean solution with float128 support being optional in some architectures (RiscV, Sparc64, PPC64). So if we change it, we should do it right as 80 Bit has the same problem: missing transcendent functions in software.

Of course, what we could do for the compiler (not the rtl!): to translate libquadmath. It is LPGL so perfectly usable with in the compiler.

What's strange though:

https://github.com/gcc-mirror/gcc/blob/master/libquadmath/math/cosq.c

It contains a sun copyright and not LGPL header ...

I see now.
However libquadmath is quite slow to be really useful. Double float is around 20x slower than native double, float128 would be around 100x slower.

-- Regards,
Denis Golovan

This doesn't matter. It is needed "only" for constant expression evaluation inside the compiler. Speed is negligible in this case.

How does one get a 64-bit version on windows.  When I try to run a 64-bit version on windows, I encounter an error, though I don't remember what that error is, since I've not tried it for a couple weeks.  I didn't even know there was a 64-bit windows version, because as mentioned below, linking to the 64-bit version on the website links to a 32-bit version.  Admittedly, I'm no fan of windows, and honestly, I hate that I'm forced to use it for my everyday work, I'd much rather use linux/macos, but at the moment, that's not an option, though I was windows free for over 10 years at one point, that sadly has changed over the past 5 years. <sigh>

But, in any case, if there's a way to get 64-bit versions on windows, I'd like to know how.

Although, it may be a bit problematic for me if it requires recompiling, since I don't (currently) have any compilers (other than freebasic, powerbasic and free pascal) installed on my win10 machine.  My win8.1 machine has them though, so that could handle the task I'd think.

Sorry for a silly question, but is it really the case that a higher precision is good (or that it doesn't matter at least)? I assume that performing compile-time calculations in higher precision than calculations performed at run-time may still result in differences and, in spite of the fact that the calculations are more precise, the differences may still lead to confusion of our users (if not something worse) - especially if it may not be always clear which part will be computed at compile-time and which my understanding correct? Or is there some solution allowing to achieve specific precision with a higher precision library?

Tomas

Op 2020-09-27 om 18:21 schreef Florian Klämpfl via fpc-devel:

Or just block forbidden combinations wrt crossbuilding in the build system, rather than the release versions.

Florian Klämpfl wrote

- there are little libraries being really IEEE compliant for float128 >> - if they are IEEE compliant, their license does not allow to use the >> code in the FPC rtl. >

I don't understand this statement.

How does having all the required functions for a certain kind of compliance restrict anything?  I was under the impression that if someone wrote those functions from scratch that there was no licensing issue.  Where's the conflict in that case?

I've read most of the gpl licenses multiple times, and I've never seen anything targeting compliance of any kind, What does this statement stem from, and how does it apply to FPC code specifically?

This would seem to indicate that no gpl license code could ever obtain compliance with certain standards, and I've seen more than once where said code does just that.  I don't get it.

Someone enlighten me please.

I don't have an exact answer, but I think higher precision is better, compared to lower. You can not expect bitwise identical result, when using floating point calculations anyway. For example AMD and Intel FPUs perform calculations with some very slight variations, so the same calculation doesn't always result in the same bitwise identical floating point number, even though, they're practically really close, so it doesn't matter. I don't know of any program that breaks e.g. on AMD FPUs, because it was designed for Intel or vice versa.

In theory this matters, if we implement 128-bit soft float support in the compiler, or if we encounter an FPU that supports 128-bit floating point. The question is whether it's safe to implement 80-bit x87 FPU floating point support on host targets with 128-bit FPU support. I think it's safe, but I'm not an expert on floating point.

But compile time calculations having a lower precision, compared to the runtime precision is definitely bad.

Nikolay

This is way we should implement it completely in software: we get the same results on all platforms though they may deviate slightly from runtime results.

It just means that all IEEE compliant libraries that Florian knows are released under a license that does not allow to include them within the FPC.

Ondrej

Travis Siegel via fpc-devel schrieb am
Mo., 28. Sep. 2020, 10:01:

But, in any case, if there's a way to get 64-bit versions on windows, I'd like to know how.

Easiest: install a 64-bit Lazarus, it contains a 64-bit FPC.

Other than that: download the source for your compiler version and do:

make all CPU_TARGET=x86_64 OS_TARGET=win64 FPMAKEOPT="-T <thds>" make install CPU_TARGET=x86_64 OS_TARGET=win64
INSTALL_PREFIX=the\path\you\want

<thds> is the number if threads you want to use during the build. I usually use the number of cores of my CPU.

You should then copy the fpc.cfg from your existing installation (it's next to the fpc binary) and adjust the paths in there.

Regards,
Sven

If you want to target Win64, using official FPC releases, you should download two packages:

fpc-3.2.0.i386-win32.exe

fpc-3.2.0.i386-win32.cross.x86_64-win64.exe

Install the first one, then the second one (it's an add-on package that adds win64 target support to the 32-bit compiler). After that you can compile to win32 via:

fpc -Pi386 hello.pas

and to win64 via:

fpc -Px86_64 hello.pas

The two install packages will be combined into one starting with FPC 3.2.2, so it will be a single download.

Lazarus provides a native win64-hosted win64-targeting FPC, but I don't use it, because of the 80-bit floating point issues. That's why I don't recommend it. I prefer to install these two:

lazarus-2.0.10-fpc-3.2.0-win32.exe

lazarus-2.0.10-fpc-3.2.0-cross-x86_64-win64-win32.exe

This allows me to target both win32 and win64. I don't know if there's any downside to using these instead of the win64 version of Lazarus. Disclaimer: I don't write GUI apps, so I don't use the LCL.

Best regards,

Nikolay

PM Nikolay Nikolov wrote

compile to win32 via: fpc -Pi386 hello.pas

AFAIK a simple fpc hello.pas will do in that setup.

and to win64 via: fpc -Px86_64 hello.pas

Doesn't that need a -TWin64 as well?

Yes, that is true. The -Pi386 is optional in this case.

It's not needed - Win64 is the default target of the windows-hosted x86_64 crosscompiler. But it doesn't hurt if you add it.

Best regards,

Nikolay

Thanks, that did the trick.  I can now produce 64-bit executables.  I appreciate the assist on that one.  I didn't look hard enough at the releases page, or I might have figured that out, though I likely wouldn't have installed the 32-bit one first. :)

I don't use the lazarius system, because I rarely create gui apps, and when I do, I generally use powerbasic, because it makes generating guis easy with it's add control syntax, and I've not figured out how to do that sort of thing with FPC anyhow.  Of course, being blind and using a screen reader makes any guis I generate problematic unless my math is perfect, because I tend to overlap gui elements because I don't get their sizes right, then when a sighted person looks at them, they are all like "Man, your gui is broken", so I generally get someone else to use a gui tool to generate the interfaces for me, then I fill in the code accordingly, it's easier than moving around gui elements in the code until things look ok by someone elses standards. :)

I generally reuse my guis once I have one working, because it means I don't have to plot layouts, I can just use one that already works. <sigh>  I'm not very good at the whole generate guis on the fly with code thing, though when using java, that's not really a concern, I just use the grid layout, and let the jvm sort it all out.

If there's something equivalent on FPC, I sure would appreciate knowing about it.

Hah!
That will save me some typing from now on.
Thanks.