Jane Street packages: dropping support for 32-bit

I’m not really sure about that. Since we have a CI which checks for us our tests on 32-bits platform, we have a support about such platform for MirageOS projects. As I said into another thread and in the way to support IoT, 32-bits platform is a common platform.

About the work, I want to follow @dbuenzli and say that it’s not hard to make something which works on 32-bits platform as far as you don’t use the Obj module or implement something on top of some strict assumptions (like my int can contains, at least, 32 bits - and even such case can be fixed). We discovered some bugs due to the 32-bits platform mostly on C stubs.

On the OCaml side, and mostly because we don’t want to implement some fancy extra micro-optimizations over some obscure representations into the caml runtime and we prefer to make something portable (in the MirageOS spirit), we did not get weird bugs or some situation which imply that we need to rewrite the whole code. Most of the times, it’s because we did not have something to check for us the 32-bits support - now, we have one.

Note that such needed work was done too about big-endian support - and of course, we got some bugs too when we tried to use our libraries on this platform (s390x) but, again, the series of patches was really small if we compare to the MirageOS eco-system.

From this experience, I consider that we don’t have a huge cost to maintain libraries on 32-bits platform and, as @dbuenzli, I’m pretty happy to have the possibility try to flash a MirageOS into a RB Pico/ESP32 chipset, etc. :slight_smile:

NOTE: this is my opinion but most of the times, when we have something which can not work on many platform, it’s because we want to integrate a micro-optimization. On this question, it’s not sure that such micro-optimization which, most of the time, take the advantage of the representation of an integer has a huge impact. Don’t let me wrong, I can understand that, in some special (and very specific) cases, these micro-optimizations can have an impact but, as far as I can say, they consider systematically a specific (really constrained) context (the platform, the state of the GC, etc.) and it’s on the opposite on what we try to do in MirageOS where we are mostly aware to provide something which should work anywhere (and it was a initial reason about why we choose OCaml and its runtime to make unikernels :slight_smile:).

3 Likes