Support for 61-bit SmallIntegers in 64-bit images

[LinqLover]

This is not meant to be merged at the moment but rather to document an open issue. I was confused that when opening 64-bit images in SqueakJS, arithmetic primitives are unable to work with 61-bit numbers as in the OSVM. In this PR, I attempted to fix this by making the relevant constants dynamic depending on the image, but then realized that JS numbers have a smaller value range than Squeak 64-bit SmallIntegers. We could use bigints instead but these require explicit conversions for all arithmetic operations with normal numbers, which would clutter the code base and slow things down.

Thus, the open questions are:

• How significant is the impact on readability of adding support for bigints in arithmetic primitives?
• How significant is the impact on performance of adding support for bigints in arithmetic primitives? (I think it will always be faster than the image-side fallback code path, but the question is how much the conversion/type check will slow down the 31-bit number case.)
• What consequences would there be if SqueakJS continued not to support 61-bit numbers in 64-bit images? Should images be able to deal with that or is that a violation of the contract?

If this feature is not possible or a good idea, maybe this decision should be documented somewhere (such as directly at the constants) before the next person stumbles about this again. :D

[LinqLover]

Forgot to mention another issue with not supporting 61-bit SmallIntegers in 64-bit images: IIRC this caused problems for me when running the image-side simulator in SqueakJS because there were some larger SmallIntegers in the headers of some methods that could not be accessed correctly. Sorry, can't reproduce ...

[codefrau]

SqueakJS converts 64 bit images to 32 bits on load. I don't see a point in supporting 64 bits at runtime since it would not get any faster, but a lot more complex.

We could support converting to 64 bits when saving. I haven't really had the need for that yet though.

[codefrau]

(I'm happy to be convinced otherwise if you want to explore this in your fork – but there are quite a few places where the "number" == SmallInteger is used, not the least in the JIT, so I can't imagine this being a change that does not make everything a lot more complex.)

Re BigInt – I'm not generally opposed to that. Happy to start using more modern JS features that were not around in 2013 when this project started. This could be really useful in a LargeInteger plugin for example – or by handling LargeIntegers natively (like we handle boxed floats).