Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Meg-4, the Open Source PICO-8 alternative

bztsrc.gitlab.io

Post reply on HN
Print view View original

11–13 of 13 posts

Re: Show HN: Meg-4, the Open Source PICO-8 alternative

#11

Post by bzt »

schemescape wrote: post #10
bzt wrote: post #9

Earlier quoted context omitted.

> I assumed you were relying on an existing compiler. Fair assumption, actually I was. Originally I wanted to port Bellard's TCC, but run into roadblocks: no real architecture abstraction layer as it generates machine code directly, so hard to port to a new CPU. Also it would be nearly impossible to add new languages like BASIC to that compiler. > Very impressive! Thank you very much, but I'm not so sure. C89 is a ve…

That’s funny, I almost asked about TCC, but decided not to because I wasn’t sure it could be easily adapted to your custom VM :) For Lua and file system access, is that only with the standard library? If not, that would be very surprising!

> For Lua and file system access, is that only with the standard library? If not, that would be very surprising!

If by standard library you mean Lua's io package in baselib, then the answer is yes. For example, "dofile" or "loadfile" functions will work no matter baselib is removed or not.

Here's a full list if you're interested: https://gitlab.com/bztsrc/meg4/-/blob/main/src/lua/hardened....

In a nutshell, I've removed package, coroutine, io, os modules from baselib and all functions calling fopen or fread/fwrite (like "loadfile") and replaced these with the MEG-4 API. This way you have the same functions in Lua as in C. All the rest left untouched; eg. table, string, utf8, math, etc. modules are still available as usual.

Re: Show HN: Meg-4, the Open Source PICO-8 alternative

#13

Post by bzt »

snvzz wrote: post #12

Why not RISC-V?

As I wrote, I created a bytecode which fits the compiler's code generator the most. This keeps the entire code base small, the bytecode VM simple and compilation fast. This is a self-contained solution, the compiler as well as the execution environment is part of the emulator; therefore it has to be compatible with itself only, which opens up solutions for simplicity and effectiveness.

Using real world RISC-V instructions would have introduced a lot of complexity without any real benefit. It's not that you can run the MEG-4 scripts without the API library and emulation environment anyway, so at the end of the day the actual instruction encoding doesn't matter.

BTW, if I were to use an existing instruction encoding, I probably would have chosen WebAssembly instead, because it is a lot easier to generate and lot easier to process than a real CPU's instruction set. There are many wasm VM libraries with nice licensing and easy to integrate interface and virtually no dependencies like https://github.com/kanaka/wac for example. But again, implementing wasm's poorly engineered container format and one of its incompatible ABI would just add complexity and have no real benefit.

All that being said, one could implement a new bytecode format in MEG-4 easily if they really want to. It already supports multiple instruction sets (Lua being a working PoC).

Post reply on HN