ChubakPDP11

Hey now, I am just a yokel from Mazar-Sharif, New York who sells dingbat carcasses for infant consumption, but does Android even use JVM? I was under the consumption it uses Dalvik? Let me consume a dingbat -- ok, so who cares what "java" gets compiled to, JIT, AOT even tree-walked, we're talking about JVM here. Here: https://sourceforge.net/projects/jasmin/ An ancient JVM bytecode assembler.

Cool, will do.

I think by 'GADTs' you mean an AST (could be mistaken). In that case, it would not be a bytecode interpreter, it would be a tree walker. In most languages, an AST is translated down to bytecode, and passed to a VM execution engine. How this engine deals with closures is highly compliant on the architecture of the AST.

First, keep this in mind: A closure is just a closure at the higher-level. Job of the AST is to translate it down to ta more abstract form, thus, a closure would most probably be inlined. Otherwise, it will be a global subroutine defined somewhere on the stack. It never makes sense not to inline closures, unless that closure is a 'hotzone', e.g. frequently used, in whcih case you should most obviously define as a subroutine, and if possible, JIT.

A VM lke NekoVM has a higher-order, terse IR with which you can handle closures like you do in JS.

Don't conflate higher-order constructs with intermediate representations. If you are interested to see a VM development in progress, star my RuppVM. Still early though. But i tend to work on it actively.

Thanks.

Are you specifying everything beforehand? If not, I'd recommend locking in on an ISA with stack effect pre-determined. Also, minimize as much as you can.

First off: Read Xia-Feng Li's excellent book if you have not.

Then.

Here are some minimization tips I am doing for my RuppVM. I just began working on it less that 24 hours ago. But the tips are based on over 6 months of off-and-on trying to make a VM, and failing. I am sure this one will take, because of these minimization efforts:

• Everything is a word: When you are reading the bytecode stream, read word-by-word, and by word I mean machine word. Don't waste your time on floats, you can implement IEEE-745 floats as a module, it will be good for practice. There's a good book for it here.
• No complex datatypes, BLESS!: So I said everything is a word, what about arrays? Structs? Basically, you need to 'bless' chunks. Blessing means taking a routine and turning it into a structure, see: Perl.
• No OS-level threads, BIND!: Just make 'green' threads, as I am doing in RuppVM. You can use the FFI to bind them to OS threads.
• Stop the World GC + Arena Allocation: Don't waste time on intricate GC, Just do stop-the-world mark and sweep, on arena-allocated memory (see my code).
• Super Basic FFI: Take a look at my ISA.txt file, look at what I am doing for FFI. You don't need intricate type mappings for the FFI. Just register a 'hook' to an address in memory (or ELF).
• Avoid JiT/AoT for now: Don't focus on it at the beginning.

These variables are not exactly portable, but you can use them, abuse them, etc:

• extern etext -> First address past the text segment;
• extern edata -> First address past the initialized data segment;
• extern end -> end of bss

I think there are portable libraries for handling ELFs and PEs. You could also write your own Assembly code for it. For loading functions from files, for the FFI, these help a lot.

Another aspect you should implement is a 'signal trampoline'. This trampoline will help handle signals from the OS, and hook it to your green threads.

Now, don't take these as gospel. I am sure you know most of these already. But in case there's new info, feel free to adapt it.

Star RuppVM, I will be adding a lot of stuff to it soon.

EDIT: I looked, there does not seem to be any 'portable' libraries for handling PE and ELF with the same interface. I guess ther can't be, two different beasts.

EDIT 2: The FFI could prove to be much more complex than I thought? There's libffi though.

This is egregious. standards(7) says Linux is both SuS and POSIX. Either mkdev.h is neither and I am wrong, or there's some shit going on because LXRs list it in older versions of the kernel. In fact if you, I mean me, with my Google recommender system cache, search for 'mkdev.h', an LXR comes up! Just stupid and egregious. I was looking forward to running them. But see, time's moving on from POSIX. People are writing cool supersets of these utilities in Rust. Like: fish, ripgrep, fd, exa and oh so many more! Also, Core Utils is entirely useless now. I just got introduced to the 'Miller' utility, an AWK-like string processor that, instead of doing line-based, does key-value. There's jq too. I think I am the 'new generation' of terminal users. I am not very young, 31, but when I started using a PC at 10, it was a Windows XP machine

I did not even get to experience the 'clunky' days of graphical shells. But it's been a while now that I am just constantly using Kitty to interface with my system. Barely use the WM. That's why I have decided to make my own WM that fuses in a terminal but let's more on or now.

So yeah Heirloom Toolchest is useless. But at any case, you wanna try the original AWK, someone has pushed it to most of the repositories for Debian-based systems. sudo apt install oawk. It's good if you suck Kernighan's dick whilst fondling Aho's balls like I do. But besides historical reasons why use it. AWK was made useless in fucking 1985 when Perl came lol.

Those are Linux headers my man. mkdev.h is a POSIX header.

Just a joke my man.

I actually started work on a tool similar to Forth's VMGEN. It will generate Stack VM's in several languages leveraging m4, just like Bison. The difference between it, and VMGEN would be that it actually adds GC and threading. Based on Xiao-Feng Li's book.

Ironically, I just made a thread on Gamedev instance about something like WASM, but for vidya. Except instead of WASM's S-Expression I recommend a PostScript-like syntax. I gotta learn WASM.

Thanks.

• Noko

I just remember about Noko! Also, there's the one which Perl 6 uses. Forgot its name. Noko seems better imho. Need to look into BEAM.

Thanks!

Thanks. I actually have a parse-related question which I will post somewhere soon (as in 2-3 minute).

I will download it all and mirror it on my server and Github pages. Hate to see it go. What happened to this dude? Was he old or young?