This does, incidentally, also help OpenBSD since the current i386 native code generation is incompatible with the new mimmutable(2) feature, so that was going to go bytecode only anyway.

Ah the joys of deleting code I envy you @nojb. That likely warrants a changes entry though :-)

One question, does 32-bit support via bytecode remain viable (the diff seems to indicate so) or do the multicore runtime system changes make that non workable as well ?

That likely warrants a changes entry though :-)

Indeed, one has been added. Thanks.

One question, does 32-bit support via bytecode remain viable (the diff seems to indicate so) or do the multicore runtime system changes make that non workable as well ?

Yes, bytecode is already working in 32-bit (except for MSVC if memory serves).

Just noting that there were some objections in #10540 regarding cross-compilation

The point raised in #10540 was that the i386 port is useful to cross-compile to arm (and other 32-bit native-code platforms). Here we're getting rid of i386 and arm at the same time, and there are no 32-bit native-code platforms left to support.

There's a couple of simplifications from #10540 that you could include:

• i386-specific code in runtime/caml/stacks.h
• removal of Proc.regs_are_volatile and its uses (good riddance!)

Fixed, thanks!

While you're at it, there's some tricky code in Cmmgen / Cmm_helpers to implement 64-bit arithmetic on 32-bit backends that can also be deleted. (Delete simplif_primitive_32bits from cmm_helpers.ml, and replace all occurrences of size_int = 4 and size_int = 8 with false and true respectively in cmmgen.ml and cmm_helpers.ml)

While you're at it, there's some tricky code in Cmmgen / Cmm_helpers to implement 64-bit arithmetic on 32-bit backends that can also be deleted. (Delete simplif_primitive_32bits from cmm_helpers.ml, and replace all occurrences of size_int = 4 and size_int = 8 with false and true respectively in cmmgen.ml and cmm_helpers.ml)

Thanks for the pointer, I pushed a commit with these simplifications.

There's also the FUNCTION_SECTIONS check for i386 in configure.ac that can be trimmed.

There's also the FUNCTION_SECTIONS check for i386 in configure.ac that can be trimmed.

Thanks, fixed.

In Feb last year, we’d agreed in principle to keep ocamlopt word-size independent - do we have to be doing the word size simplifications at this point?

As it happens, a few of us were planning on hacking on single-domain arm32 next week (with the intention of the backend possibly existing out-of-tree)

Should the mention of ppc32 be removed from the README at this point, if we’re committing to excising all 32bit platforms (for native code)?

I think it's really important to be clear that we are not removing support for 32-bit code entirely from OCaml, and that it will continue to be supported in the bytecode backend. This is necessary as libraries will still need to check for a 32-bit wordsize, e.g. optint. And for operating system packagers, that it is supported to bundle the bytecode compilers for i386/arm32 with the expectation that they will work in a single-domain mode so that existing OCaml applications that they have already packaged (like Unison) will continue to function (albeit more slowly).

This is the kind of PR that cannot wait for too long. It seems we're blocked on @dra27's comment:

In Feb last year, we’d agreed in principle to keep ocamlopt word-size independent - do we have to be doing the > word size simplifications at this point?

I remember agreeing to keep the runtime system, the bytecode compiler and the standard library word-size independent, so that the bytecode implementation of OCaml keeps working on 32-bit platforms.

For the native-code compiler, I don't really see the point of keeping vestigial support for 32-bit platforms.

As it happens, a few of us were planning on hacking on single-domain arm32 next week (with the intention of the backend possibly existing out-of-tree)

You're on your own here. Have fun and base it on trunk before this PR is merged.