
Viua VM: parallel, register-based, bytecode virtual machine - ingve
https://viuavm.org/
======
maelkum
Hello everyone, the Viua VM's developer here! If you have any questions, just
ask, I will try to answer them.

Mind you, I am _not_ the one who posted the VM here. I was specifically trying
to maintain a low profile (and giving only a few presentations about it) until
I polished the VM to some acceptable state. But here we are, so just ask me
anything ;-)

~~~
exebook
Hi, very interesting stuff!

I am trying to choose a new backend, for the programming language I create,
currently I use C, so my interest is rather practical here.

Where Viua stands in terms of performance for both generated code speed and
compilation speed? What kind of optimisations it does or will do? What library
you use for register allocation? Is JIT in plans?

What are the long term plans/goals?

~~~
maelkum
> Where Viua stands in terms of performance for both generated code speed and
> compilation speed?

The performance is, frankly, abysmal. At this time you shouldn't use Viua if
what you need is execution speed, as I haven't spent much time optimising the
VM. Compilation speed is a different matter. I only provide an assembler so
the "compilation" process is simple and straightforward, and shouldn't take
long. Separate compilation is available, although a bit awkward, which should
help.

The assembler supplied with Viua does not perform any optimisations on source
code.

I don't use any library for register allocation. The bytecode is not compiled
to native code so I can just supply whatever number of register a function
needs.

I haven't planned building a JIT compiler for the code, but I thought about
it. Don't expect it any time soon as I don't have the chops to do it _right_
;-)

The long term plans and goals... Ah, these deserve a separate post.

The shortest possible summary: I do not plan to take the part in speed arms
race; what I want for the VM is to provide best-in-class correctness and
reliability. That wasn't always the case (and it shows if you know where to
look), but now every feature and change is evaluated in the light of "How can
X help with writing correct programs?". The same for VM's source code. I
compiles warning-free, it doesn't leak memory. It does not contain UB. I am
not able to provide you with the greatest performance out there, but I can
give _some_ correctness guarantees - this is where I focus with the
development of the VM.

------
kodablah
Can I get some background on who is behind this project and if there is an
initial target/goal that led to its creation? Found a bit of detail at [0],
now just curious its background and maybe even why the choice of licensing.

0 - [https://github.com/marekjm/viuavm](https://github.com/marekjm/viuavm)

~~~
maelkum
Hi, Viua VM's developer here - I am behind this project.

The initial target/goal for me was to create a programming language, but I
found it hard to dig into GCC (didn't know about LLVM then), so I decided to
create my own runtime VM. Thus, the VM was born.

Why I chose GNU GPL v3? Simply because I am a strong proponent of Free
Software (you may have also found that Viua has a page on GNU Savannah).

A piece of trivia: why name it "Viua"? "Viua" is pronounced a bit like "wiła"
in Polish. Wiła is a female daemon in Slavic mythology
[https://en.wikipedia.org/wiki/Supernatural_beings_in_Slavic_...](https://en.wikipedia.org/wiki/Supernatural_beings_in_Slavic_religion#Vila)

If you have any other questions, just ask!

------
chubot
Does building a VM without a language make sense? I don't know of any
successful instances of this approach.

There are lot of hairy corner cases in languages, and VMs reflect that. If you
build the VM first, those design decisions may not be obvious, or might come
to light a lot later.

I tried compiling Python code to the Lua VM and found that it is extremely
coupled to Lua's semantics. That's even more the case with Python's VM. (for
example scope rules, module systems, etc.)

I mean, I think you can target one language to the VM for sure. If you manage
to fit two languages, then you're essentially writing the same language in two
different syntaxes.

~~~
earenndil
> If you manage to fit two languages, then you're essentially writing the same
> language in two different syntaxes.

Counterexample: the JVM, which runs quite a few languages, including some that
were created without any consideration thereof (python, ruby, lisp, perl).

~~~
chubot
Yeah I think the JVM is a special because of Hotspot -- a state-of-the-art JIT
compiler.

I'm pretty sure that without a JIT you will not get decent performance on
compiling one language to a VM designed for another language.

Also, I think the JVM "required" at least one modification for dynamic
languages? I recall something about JRuby and invokedynamic bytecode, but I
don't know the details:

[https://www.infoq.com/articles/Invokedynamic-Javas-secret-
we...](https://www.infoq.com/articles/Invokedynamic-Javas-secret-weapon)

As another counterexample, I've heard that VB.NET is just C# in a different
syntax, more than it is VB6. That is, when it moved to the CLR, the language
changed.

~~~
WorldMaker
VB.NET is more like VB6 than C#. The problems with the vocal minority in the
VB6 community not moving to VB.NET had mostly nothing directly to do with the
CLR.

(The break in backwards compatibility, and inability to just "upgrade" old
code, in a language that hadn't a major break since VB3 was more impactful, I
think. That was more due to the VB team trying to clean house and remove anti-
patterns than the CLR's fault.)

The CLR has just as many languages, including dynamic languages, supported as
the JVM.

~~~
meredydd
VB.NET is shaped like the CLR, just like C#. (Similarly, Java is shaped like
the JVM.) It is possible to mechanically transform VB.NET code into C# code.
Heck, I'd bet they both parse to the same AST. They are very, very similar
languages, with the exception of syntax.

The upshot is that writing VB.NET involves understanding everything you need
to understand to write C#. All the syntax is VB6-flavoured, sure, but it still
involves making people learn about classes, this year's flavour of Windows UI
components, and so on.

What's more, you have to do it all in an industrial-strength IDE, with all the
complexity that brings. (Don't get me wrong - Visual Studio is more or less my
gold standard for a usable industrial-strength IDE. But if you stand it next
to VB6, you'll see how much more you need to understand _just to get to
editing code_ is noticeably larger. It can be invisible to people like you or
me, who have already absorbed these concepts, but it's real.)

~~~
WorldMaker
VB1-6 encouraged classes. The fact that OO was not more popular in VB was a
failure to communicate. VB.NET didn't add classes, it removed the anti-pattern
that was grab-bag modules. Again, that's much more of a backwards
compatibility problem than a CLR problem. The VB team _could_ have kept
modules and still targeted the CLR, they just chose not to in the hopes of
cleaning up some of the worst patterns in VB.

Just because you can "mechanically transform" code between two languages
doesn't make them the same language. Compilation is a mechanical
transformation to machine code, but you don't see anyone arguing C++ is the
same language as Assembly.

(Did you ever look at the output of such mechanical transformations? The
results were always weird, lacking proper idioms in the target language. Just
like machine translations of spoken languages, I wouldn't rely on them without
a lot of work to clean them up and verify them.)

Yes, VB.NET and C# share many (but not all!) components of the same AST, but
so too now does F# as it is being brought over to the Roslyn compiler
platform. Shared AST components also do not make a language "the same",
because of that fun word "abstract" in AST. Just as most languages can be
described in a BNF variant, fall into some variation of the category Context-
Free Grammar, represent similar Pushdown Automata, etc. The underlying tools
are very much the same across the vast spectrum of languages, but that doesn't
mean all languages are the same/interchangeable.

Also, Visual Studio is a direct successor to the VB6 IDE. Visual Studio .NET
shared a lot of code with that IDE. I'd be surprised if VS today didn't have
at least some code inherited down the many years from that predecessor
(certainly plenty of ghosts of it in source control). The VB6 IDE was
considered "industrial-strength" in its time, too.

Given there's a free Community Edition of Visual Studio, and VB6 was never
cheap, arguably the barriers to new developers to "just get to editing code"
are at the lowest they've ever been, complexity or not. (Nostalgia is a weird
fuzzy thing.)

------
chrisaycock
The documentation describes a Viua program as a set of communicating
processes. However, instead of using channels like in Go, the messages are
sent directly to another process.

I was hoping the "parallel" in the name would mean vector operations were
builtin. I see instructions to create a vector, but I don't see anything to
actually add or multiply vectors together, for example.

~~~
maelkum
Hi, Viua VM's developer here.

Yeah, the naming of "vector" is unfortunate, I'll give you that. In Viua, a
vector is simply a data structure with push, pop, insert, etc. operations - a
collection of values.

If I ever include vector instructions of the sort you expected then I'll base
the design on what RISC-V did.

------
Vosporos
Who want to write the new Erlang on that VM? :-D

~~~
maelkum
Viua VM's developer here.

That's sort of the point of the VM. Maybe not to become the new Erlang, but to
become the new BEAM.

