[announce] A new embeddable and complete Ngaro VM implementation for Go programs

[db0...@gmail.com]

This is an embeddable and complete implementation of the Ngaro Virtual Machine in Go: https://github.com/db47h/ngaro

The project repository contains the embeddable virtual machine, a rudimentary symbolic assembler for easy bootstrapping of projects written in Ngaro machine language, and the a retro command line tool that can be used as a replacement for the Retro reference
implementations. The VM and command line tool support 32 or 64 bits cell sizes as well as loading and saving 32 and 64 bits retro images, regardless of the platform it's running on.

The main purpose of this implementation is to allow customization and communication between Retro programs and Go programs via custom opcodes and I/O handlers (i.e. scripting Go programs in Retro). The package examples demonstrate various use cases.

Custom opcodes are implemented by intercepting implicit calls to negative memory addresses. This limits the total addressable memory to 2GiB on 32 bits systems, but this also allows the VM to be fully backwards compatible with existing Retro images while still providing enhanced capabilities.

The project is licensed under the Apache License, Version 2.0.

Happy Retro hacking !

[yy]

On 19 August 2016 at 02:17, <db0...@gmail.com> wrote:
> This is an embeddable and complete implementation of the Ngaro Virtual
> Machine in Go: https://github.com/db47h/ngaro

Very nice.

FYI, I also wrote a ngaro implementation in Go. That was many years
ago, before Go1, so I would not expect it to work today. Both Go and
ngaro/retro were different back then, and I have not updated it in a
long time. The Go version was eventually included in ngaro and Charles
maintained it for some time, but I do not know if he has kept it
updated.

Just a curiosity, does your ngaro vm support goroutines and channels
in some way? I think there is a lot of potential there, but after a
quick look I did not find anything. I was using IO ports for that, but
I guess a custom opcode would be the way to go in your case.

Regards,


--
- yiyus || JGL .

[db0...@gmail.com]

Hi,

I saw your implementation indeed, but I had no idea it was written before Go 1.0. Anyway, it's still in the Retro distribution, still compiles and works. Kudos!

Using the I/O ports for go channel support was a good idea. I left it out however as I wanted the core package to provide a complete standard VM and let the clients implement extensions in any way they like. It's in fact really bare-bones: most Retro specific stuff is left out of the core VM stuff and implemented in the cmd/retro command line tool.

Channels could indeed be implemented with custom opcodes (and the assembler fully supports these), but it's also possible with custom I/O handlers as shown in the API docs. See https://godoc.org/github.com/db47h/ngaro/vm#example-BindOutHandler

The behavior of your implementation could also be simulated by hijacking read/writes to ports 1 and 2 with custom In/Out handlers.

Speaking of custom opcodes, a good candidate would be a "quote" opcode  it dramatically speeds up Retro code that makes heavy use of quotes!

Regards,

Denis