Contributing to the project

[Maaarcocr]

I'm opening this issue because I would love to have the opportunity to contribute to this project. I haven't seen any particular mention in the README, so I don't know if contributions are welcome at this point of the project. I'm not even sure if opening an issue on GitHub is the right thing to do, but I would be very happy to contribute in any way, from writing documentation, creating a sample language on my own, to actually working on the vm itself (which, honestly, I would actually love).

[maximecb]

Hi Marco,

Thank you for pointing this out. I will add more information to the README.

I would be happy to get more contributions. In the meantime, I did add some basic information about implementing languages on ZetaVM in this issue: https://github.com/maximecb/zetavm/issues/2

As far as working on the VM itself, there are a number of things you could help with:

• I would like to add some instructions and facilities for float32 support.
• I have plans to implement an audio output API using SDL2. This will require float32 support so we can use float values for PCM samples.
• Would like to sketch out a low-level MIDI input/output API
• Garbage collector implementation, there is currently none
• Image serialization. The VM currently loads zim files, but it should be able to write them too.
• Need more VM tests and benchmarks
• I'm also working on a package manager. Development for this will take place in a separate repository, but I could give you access if you are interested.

Suggestions are also welcome, if there are features you would like to work on that I haven't mentioned.

[Maaarcocr]

Thanks for the response! One more thing: I was thinking of creating a toy language using ZetaVM and I was thinking of approaching it using the first approach described in the issue you referenced. So I would just emit IR and not pass it in memory. Do you have any guidance about what instructions the IR contains now? I'm sorry to bother you, but I really want to use this as it seems really promising! Thank you for your work :)

[maximecb]

You're not bothering me at all. I'm happy to answer any questions you might have.

At the moment, the only guidance would be to look at the implementation of the interpreter. There is a listing of the opcodes here: https://github.com/maximecb/zetavm/blob/master/vm/interp.cpp#L10

And the big switch case implementing the ops is here: https://github.com/maximecb/zetavm/blob/master/vm/interp.cpp#L846

There aren't very many instructions and they're a bit similar to what you might find in the JVM. With the important difference that the values Zeta manipulates have an associated type tag (ie: string, int64, object, etc). The HAS_TAG opcode serves to determine the type of a value.

You can try playing with the cplush compiler, generating code and seeing what comes out. Since the IR is in textual format, you can manually inspect it. The IR that comes out might seem bloated because it contains not only the code you write, but also the compilation of what is in plush/runtime.pls. The runtime functions serve to implement the plush operators, which have dynamic typing, in function of primitives in ZetaVM. For example, ZetaVM has ADD_I64 to add integers together, but plush has an addition operator which can add integers, but also concatenate strings. This is implemented in the rt_add function of runtime.pls.

[Maaarcocr]

Thank you for the response! I will inspect the files and learn from them. I already have a bit of experience with JVM bytecode due to a coursework that we had to do at Uni, so it shouldn't be extremely difficult!

[Maaarcocr]

About float support: What is the plan? Would it be something similar to i64? So, using the floating point type in cpp and using its operations? If so, I could give it a try in the next days :)

EDIT: And add the parsing for floats.

[maximecb]

Sure, you can work on float support. Excited to have support for that, because it will make it easier to do sound and graphics. For now, I'm planning to support only float32 for now, and to make that the default float type. My reasoning is that it will be easier to implement GPU support if we default to this format. Sidenote: I'm actually wondering if we should do the same with integers. Right now the default (and only) integer format of the VM is int64, but I think int32 might make more sense.

Will need operations for arithmetic: add_f32, sub_f32, mul_f32, div_f32 A few other primitives: sin_f32, cos, sqrt_f32 Conversion to/from integers: i64_to_f32 and f32_to_i64

For the conversion instructions, I would go with the same semantics as C casts. I'm thinking we probably want to provide some parsing and printing support as part of the VM as well, because this is fairly difficult to implement correctly by hand.

f32_to_str, which would produce a string representation of a float in the long XXX.YYYY format.

str_to_f32, which would parse floats from strings. This should be intentionally guarded by a regex which accepts either the XXX.YYY format, or the 1.23e45 format, because we don't necessarily want to accept everything the C library can possibly parse with the atof function.

As you hinted, we should support float32 parsing in the textual Zeta image (bytecode) files. I think the format for this should be as in C. Either 123.456f or 1.23e45f. We will want to insist on the trailing f character because we might add support for float64/doubles later.

Beyond that, some tests will be needed to make sure that everything works properly. Probably, the simplest thing for you to do would be to start by adding float parsing support to the image files, and then implement simple arithmetic operations and add a few tests.

[maximecb]

Closing for now. Will be writing a guide on how to contribute to the project.