Now that I'm back poking around inside cola, some things that've been idly kicking around are coming back to the foreground. And yeah, it means more ops, which I'm sure people would whine about except that the people who'd whine don't care about cola. Yay for marginal projects!
Anyway, the kicking around things. In this case, arithmetic.
If you've looked you've seen, I'm sure, that there are provisions for basic math built into the interpreter, which is just fine. What isn't there, though, are size-limited and checked math operations. That is, there's no way to say "add I1 and I2, but assume they're 8 bit integers" or "multiply I4 by I6 and throw an exception on over/underflow". This is something that both the JVM and .NET have, and is useful to have -- I know I've been annoyed on more than one occasion writing C code and having over/underflow problems that caused subtle bugs. You don't always want that semantic, of course, but sometimes you do.
This is the sort of thing that could potentially be library code, of course, but it's pretty darned low-level, and making a function call to do it adds an order of magnitude or more to the cost, which is really counterproductive for something like this. It's also worthwhile enough that the JVM and .NET folks were willing to sacrifice their very limited set of basic opcodes to implement at least some of it.
This could also be left to compilers to implement -- it isn't too tough to emit checking code, and that's certainly a possibility, but checked and size-limited arithmetic is usually supported at the hardware level (size-limited certainly, and on some architectures you can get exceptions for over/underflow) so it'd be kind of stupid to not potentially take advantage of it where it exists. Means some probing at the configure level and macros (Yeah, I know. Still...) to support it reasonably easily.
So... in go 8/16/32 bit math variants, _checked variants, and the combination of the two.
As yet there are no 64 bit variants. That's something that's sort of problematic to do portably, so it's still being punted on.
> There's no way to say ... "multiply I4 by I6 and
> throw an exception on over/underflow". This is
> something that both the JVM and .NET have
JVM? I don't think so. The JVM spec, AFAIK, says that integers wrap around on overflow, and there are no separate overflow-sensitive instructions.
The whole overflow thing can be annoying. I did a pure perl implementation of SHA-1 and when I upgraded perl, it broke because I went to 64 bit ints instead of 32 bit ints, so had to throw in code to do it "properly."
If more ops means better speed, then more ops.
Posted by: Joshua Isom at October 30, 2005 02:40 PM