Viua VM: parallel, register-based, bytecode virtual machine
viuavm.org
viuavm.org
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 ;-)
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?
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.
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_...
If you have any other questions, just ask!
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.
The exception is when someone wants their language to run on an existing VM, e.g. for Java or to run in a web browser, so they compile it to the VM's instruction set. Various languages are compiled onto the JVM, and the same WebAssembly code has to run on any hardware onto which the containing web page has been downloaded, and will run faster than the equivalent JavaScript.
Counterexample: the JVM, which runs quite a few languages, including some that were created without any consideration thereof (python, ruby, lisp, perl).
Example: Elixir and Erlang on BEAM VM
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...
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.
(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.
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.)
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.)
Sure, compiling a language to a VM with mismatched semantics is not a pleasant experience. Viua's execution model of many processes communicating via messages is best suited to Erlang, or other actor model languages.
Then the applications are either JITed at installation time, or the CPUs are micro-coded, JITing the applications during execution.
Burroughs (now Unisys), Xerox PARC machines, ETHZ systems, IBM mainframes.
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.
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.
That's sort of the point of the VM. Maybe not to become the new Erlang, but to become the new BEAM.