My primary computer is running Ubuntu Oneiric x86-64, and as such most of Arcueid’s coding and testing is done in a 64-bit environment. As such, 32-bit support is not as well tested, and I have wound up allowing it to deteriorate to the point that 0.0.11 won’t even run properly on 32-bit platforms because of alignment issues. I got a bug report about that today, and it was related to the fact that memory blocks returned by the allocator were not aligned on 16-byte boundaries on 32-bit platforms. 16-byte alignment of all allocated memory is an absolute requirement for Arcueid to properly function, because it uses the bottom four bits to distinguish various immediate values that are represented by something other than a cell structure, such as fixnums (bit 0 is 1), true, nil, undefined/unbound, and symbols. A pointer to a boxed value must have all four low bits 0. All other even values in the low four bits, 0 – nil, 2 -true, 4 – undef, 6 – unbound, 14 – symbol, have special meaning. As such, all memory allocations must be properly aligned on 16-byte boundaries for this to be true. I tried to take care of doing this but the fact that many structures came out to multiples of 16 bytes in x86-64 masked some bugs. Specifically, the Bhdr struct that is used by the garbage collector to prefix all allocated memory is precisely 48 bytes in size on x86-64, so even if I didn’t bother doing any alignment fixes at all, my allocations would still wind up being naturally aligned on 16-byte boundaries thanks to that. Of course, none of that is true on 32-bit x86, where the size of a Bhdr is only 36 bytes. This proved to be a bit messy, but after a few false starts I managed to get alignment to work on 32-bit platforms as well.
Well, I do want to get Arcueid to run on other machines besides 64-bit GNU/Linux, and while 32-bit systems on the desktop might be going away, there are still lots of other 32-bit machines out there, such as most ARM-based tablets such as my Asus Transformer.
32-bit support is partially fixed in git head at the moment, enough that Arcueid loads and runs instead of immediately segfaulting, and most basic functionality is available, however there are a number of other places where 32-bit support seems to fail. There seem to be places where the code seems to rely on the fact that fixnums are more than 31 bits in size. Arcueid can run news.arc somewhat stably on 64-bit, but more stuff is broken on 32-bit. Looks like a lot of work ahead.