Have you intentionally gone further than the title implies for 32-bit Windows: the bytecode compiler is still intended to build, but the ability to configure it has been stripped out? dra27@c0bc292 restores the relevant parts to configure to build bytecode. dra27@e87f1b3 switches the mingw64 job to be mingw32 bytecode instead? We certainly don't need to continuously test all three Windows ports on 32-bit - it's up to you if you'd want to have 4 Inria CI Windows workers or just keep AppVeyor/GHA doing the 32-bit check?

I don't expect it's relevant to any users, but it may be worth checking: Microsoft isn't dropping 32-bit support in Windows 11, they're dropping 16-bit support. The x86 subsystem is still there, which might be relevant to anyone doing interop with 32-bit libraries (which is still the "usual" reason for ending up running 32-bit Windows apps on 64-bit Windows).

I like/support the change, btw - I've said before that I think it's good that we maintain runtime support for two different bit-widths, but I see no problem at all with i386 being a bytecode-only architecture.

Have you intentionally gone further than the title implies for 32-bit Windows: the bytecode compiler is still intended to build, but the ability to configure it has been stripped out?

You're right, my mistake.

dra27/ocaml@c0bc292 restores the relevant parts to configure to build bytecode.

Thanks! Cherry-picked in this PR

dra27/ocaml@e87f1b3 switches the mingw64 job to be mingw32 bytecode instead?

I'm less sure. It's good that the bytecode can still be built, but I don't expect this version of OCaml to be widely used: the 64-bit version is much faster because of native code and can address more memory . So, I'd rather not test it for every PR. We'll see what to do for the CI at Inria.

Microsoft isn't dropping 32-bit support in Windows 11, they're dropping 16-bit support. The x86 subsystem is still there

Right. What I meant is that (IIUC) Microsoft is dropping the 32-bit kernel from Windows 11, so that 64-bit-capable hardware is required, and 64-bit executables are supported everywhere. The ability to run 32-bit executables is still there (unlike in MacOS).

I am not against this change, but playing devil's advocate: there are a lot of embedded 32 bit x86 machines out there and still being sold, including a lot of small office firewalls. Typically these use 32 bit Atom processors or similar plus AES extensions; those are typically sufficient for doing things like running VPN software in SOHO environments. This change would mean that hypothetical future OCaml firewalls and similar tooling could not run on such machines. However, it is also the case that no such software is currently in use to my knowledge, so the worry is almost certainly unimportant.

I have a few customers using 32 bit Windows but I have no objection to this change.

(To give one example, I have a customer who builds machines for laser-cutting shapes from leather for shoes. Those machines are being shipped, even today, with 32 bit Windows on the embedded computer.)

I will continue to build for these few customers with OCaml 4.10, our current baseline. (It was 4.02 for a long time, for reasons I forget, but Filename.quote_command was too nice to ignore.)

x86_32 is the only way to compile from x86_64 to armv7 which is still widely used, while you can use the bytecode compiler it is much slower than the native one. Especially because ARM instances aren't available in a lot of CIs.

And as mentioned previously I work occasionally on having PIC x86_32 to use on Android Studio emulators as it's the only 32bits platform accessible to users to try their stuff and because OCaml 32bits and 64bits behaves wildly different you need a 32bits platform to verify if your code works nicely and due to native vs bytecode differences I'm not sure if is reliable enough to use bytecode to check that.

The number of registers make it quite hard to do some stuff as mentioned but I'm wondering what would be the deal breaker? I think it's completely okay to introduce regressions on it

x86_32 is the only way to compile from x86_64 to armv7 which is still widely used

Point well taken. I agree that it would be nice to have a better cross-compilation story before removing x86-32. This said, even the x86-32 route is getting harder to use, as macOS, Ubuntu, and perhaps other systems no longer support building x86-32 executables.

The number of registers make it quite hard to do some stuff as mentioned but I'm wondering what would be the deal breaker?

For Multicore OCaml, if I understand correctly, the backup plan is to support x86-32 but without parallelism (a single execution domain). Not sure how many #ifdef this is going to cause... At some point, old quirky architectures should be retired rather than continue causing damage.

This said, even the x86-32 route is getting harder to use, as macOS, Ubuntu, and perhaps other systems no longer support building x86-32 executables.

Agreed, that is getting harder, but Ubuntu still supports it on the current LTS which gives us 2 years at least. An example of using a native x86_32 -> armv7 compiler https://github.com/EduardoRFS/reason-mobile/runs/2679116288.

And IIRC @mseri is using it to generate binaries on his CI too.

At some point, old quirky architectures should be retired rather than continue causing damage.

Can we make a compromise and start by removing all non Linux platforms? Docker is quite popular nowadays on Windows and macOS and still allow you to easily compile to 32bits.

I am quite curious about why we can only cross-compile for 32 bit platforms from 32 bit platforms. Is there a thread somewhere one can read about this?

@pmetzger there is a couple of places where optimizations are done based on the host platform word size, I remember that there is some at cmm that does that which leads to fun errors with divisions. We could / should fix that but this takes some time.

I presume that this would be done by switching to representing constants for the target architecture using fixed precision libraries and not host integers and floats in the usual way other compilers now do?

I know that LLVM does this for example; it uses a library that lets it represent target integers and floats and does all compiler computations on constants using those libraries rather than host native operations.

I presume that this would be done by switching to representing constants for the target architecture using fixed precision libraries and not host integers and floats in the usual way other compilers now do?

This would be overkill for OCaml. All our targets use IEEE 754 FP numbers and 32- or 64-bit integers, and we definitely do not want to support any platform that would not support these. So, it's just a question of using the Targetint.t type (target-processor native integers) at all the appropriate places.

In the interest of not making OCaml cross-compilation any more painful than it is today, I'll close this PR. Still, x86 32 bits is an awful target platform and should be retired as soon as possible.

@xavierleroy thank you so much