3 ms·

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 o

• JoshTriplett 12y ago
  > 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.
  • xxs 12y ago
    >>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.