CVML (Cat Virtual Machine Language) Specification

[Christopher Diggins]

Some may remember that the CVML is my attempt at creating a byte-code
based on the ideas behind Cat and Joy.
I have recently posted the beginning of a specification online at
http://docs.google.com/View?id=dgjz7z25_12489q88hk2
I also have posted a list of opcodes at
http://spreadsheets.google.com/pub?key=r5YMEzSIaHD61fEK9FLErsQ&output=html
This is not a final list, but it is approaching something that I think
could be usable in practice.
I'd appreciate some suggestions, on how to improve it.

- Christopher

[Joakim Ahnfelt-Rønne]

I think it looks very good so far (especially the native support for
higher order functions and continuations). One thing that I'd like to
see is an arbitrary length integer type; this way an implementation of
the VM could represent small arbitrary length integers unboxed, and
only box them as they overflow the native integer size (or some other
convenient size for the VM). I think a lot of languages would benefit
from the default integer type being arbitrary precision, and I can
only think of efficiency as being the reason they're not.

Best,
Joakim Ahnfelt-Rønne

2009/7/5 Christopher Diggins <cdig...@gmail.com>:

[Christopher Diggins]

On Sun, Jul 5, 2009 at 6:01 AM, Joakim
Ahnfelt-Rønne<joakim....@gmail.com> wrote:
>
> I think it looks very good so far (especially the native support for
> higher order functions and continuations).

Thanks a lot!

> One thing that I'd like to
> see is an arbitrary length integer type; this way an implementation of
> the VM could represent small arbitrary length integers unboxed, and
> only box them as they overflow the native integer size (or some other
> convenient size for the VM).

This is a good idea. I was thinking of maybe leaving the arbitrary
precision arithmetic as something which could be defined in a library.
I am not sure that there are significant advantages to having
arbitrary precision at the VM level.

Of course, I am not doing a great job of fully specifying how integer
arithmetic should behave yet. For example how does CVML handle integer
underflow and overflow. Assumedly this may vary depending on the
high-level language. Maybe language A wants overflow to be handled by
default by just throwing away bits, while language B, wants to promote
to arbitrary precision integers.

So now that I am thinking about it, perhaps I need some special
opcodes for checking overflow/underflow status after integer
operations?

> I think a lot of languages would benefit
> from the default integer type being arbitrary precision,

I agree. The CVML however I would like to accommodate a range of
languages, so I have to give as many options as possible.

For example, I wonder if it would be possible to make CVML a possible
target of the C language, without messing up the semantics?

> and I can
> only think of efficiency as being the reason they're not.

That is a major reason. One other reason is that bit operations on
fixed precision integers, have different behavior than on arbitrary
precision, which can be useful when doing certain kinds of bit
manipulation algorithms.

> Best,
> Joakim Ahnfelt-Rønne

Thanks for your contribution,
Christopher

[Joakim Ahnfelt-Rønne]

>> I think a lot of languages would benefit
>> from the default integer type being arbitrary precision,
>
> I agree. The CVML however I would like to accommodate a range of
> languages, so I have to give as many options as possible.

Oh, I meant that the default integer type in the source language being
arbitrary precision, not that CVML should only have one type of
integer.

> I am not sure that there are significant advantages to having
> arbitrary precision at the VM level.
>

> So now that I am thinking about it, perhaps I need some special
> opcodes for checking overflow/underflow status after integer
> operations?

That might be a good alternative, if it allows one to implement
arbitrary precision integers without the overhead of invocation etc.
On the other hand, how does the source language compiler know which
one of the intNN's would be more efficient to use? This will probably
vary depending on the platform the bytecode is run on.

That reminds me - how are you going to distinguish between values of
type int32 and int64 and object etc? I suppose you can't use a tag
since the integers use the full native precision.

How will languages call each other's libraries? If each language has
it's own representation of integers, strings, objects, it might be
hard to achieve this.