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.
I've started a new section, Cola notes, to track some of the things I'm putting into Cola. They should get documented in the cola distribution itself, but this is as good a spot as any to make notes on what's going on.
Things were always designed with multiple languages in mind, but one of the things we never really did deal with was how to actually get an executable of the appropriate name to act as the language in question, rather than as parrot. Kind of an important omission, but since parrot was so far from being production it didn't much matter. Given that I've decided that it was a mistake to not have parrot actively hosting a HLL for real and quickly (that's a matter for the post-mortem) I want to rectify it with cola.
Ultimately we'd like to be able to do:
foo
where foo is some language, and have cola invoke the foo compiler and do whatever it is that language does when invoked.
In this case, I'd like cola to treat this the same as if it were invoked as:
cola -L foo
that is, invoke the foo language compiler. This is something that's also not currently in cola, but is going to be added. Like all the other languages we care about, there's going to be a defined on-disk layout of the library, including a defined spot for language compilers.
Basically whenever cola gets invoked it checks the name under which it was invoked and, if it isn't cola, it'll assume it's been invoked as a language and go load up that language's compiler module and Do The Right Thing. (For carefully and well-defined values of "right thing", of course, but that's a metadata issue for later, and another post)
I'm kind of hoping something like this can be ready for qarte reasonably soon. While it isn't anywhere near the language that Parrot was originally designed for, it'll be good to have a working language to futz with.