That's not easy either as it'd require very heavy inlining by the compiler. Functions that accept just 'integer' have to check if the value is a native number or actual reference and process differently.
C/C++,Java* ,C# have it easier there - when you pass 'int'/'long' the receiver knows it's a native number.
* Fixnums support (headless objects) needed for non-Java lanaguages on JVM is still unimplemented to my knowledge[0]
> That's not easy either as it'd require very heavy inlining by the compiler.
Right, bignums need to be a language feature, not a library feature. Compilers with native bignum support often have ways of handling native unboxed single-register numbers, and then branching to full bignum routines when needed. Haskell can do that, for instance.
Also, you can use the standard trick of decreasing the maximum single-register size and using the extra bits to identify indirect objects.
>>Also, you can use the standard trick of decreasing the maximum single-register size and using the extra bits to identify indirect objects.
That's given, you still pay the price (like mask/shift), though. That was the part the "languages like C/C#/Java have it easier" about. The point is mostly that even if built-in support (interrupts) exist in the hardware, bignums still need quite a lot of extra code in-place, plus a good optimizing/inilining compiler.
Personally I am happy with constrained integer types - else the entire stack (incl. storage) must support bignums and often (like almost always) going out of range would be a bug actually.
So don't do either of those things until your arithmetic overflows the size of a word; until then, you can keep numbers in a register.