Forcing 64 bit “words” on a 32 bit machine should be relatively straightforward to implement, but I question the utility of this (factor of 2 space usage). Better would be to change the object representation so that the header of objects would be always 64 bits (or better, split into a 32 bit length and 32 bit type and GC flags). The implementation complexity of both is about the same (roughly 2 days of work). However, too much work for me right now given the low need for this feature.
Aren’t 32 bit architectures pretty much a thing of the past? These days, even embedded systems are 64 bit architectures.
Marc
On Aug 3, 2016, at 3:49 AM, Adam adam.mlmb@gmail.com wrote:
Dear Marc,
Gambit on 32bit architectures suffer badly of the limitations on maximum string, vector and also fixnum sizes.
For some uses, this is more than enough as reason to disqualify 32bit architecture use altogether.
A thought struck me the other day - the reason for those low limits on 32bit architectures, is that Gambit delivers the native integer/pointer size of the underlying architecture, and that leads to those limitations because of how Gambit's type system is built. You could say that the overarching reason is speed.
My thought is, if a given user would like to take the speed argument out of the equation,
Would it be possible for you to easily provide a "forced 64bit word" compilation mode for Gambit, hence lifting the string, vector and fixnum size limits far beyond their current ones of 4M-chars, 16MB u8vector, and is it 2^29 as max fixnum value.
(The string and u8vector limits are the central concerns really.
The effect on fixnum would be higher speed of computation in the 2^29..2^61 interval at the cost of slightly lower speed in the 0..2^29 interval.)
This would only be relevant to run on some fairly standard architecture and platform.
If the tweak would be possible, would Gambit's total live objects be able to amount to 2GB or 4GB, or how much?
Thanks!