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

Bytecode VMs in surprising places (2024)

dubroy.com

Post reply on HN
Print view View original

61–70 of 74 posts

Re: Bytecode VMs in surprising places (2024)

#61

Post by sph »

childintime wrote: post #60

I guess all (or most) of these could be replaced by a RISC-V VM, with the necessary domain extensions. A RISC-V VM already competes with WASM for many applications.

Yes. After implementing an RV64IM simulator over a weekend, the most valuable take away is that it is a simple and well-designed enough architecture it should be the base for any register virtual machine.

Instead of reinventing the wheel, just copy RISC-V. And the bonus is that you get all the existing tooling for free. Seeing a Rust program run on my simulator I wrote in two days is pretty magical.

Right now I’m working on a RISC-V on RISC-V simulator for sandboxing programs. I’m a big fan.

Re: Bytecode VMs in surprising places (2024)

#63

Post by 0john »

jaen wrote: post #30

References for the Quake virtual machines: Quake 1 had QuakeC: [1] https://en.wikipedia.org/wiki/QuakeC [2] Hello world in QuakeC - https://www.leonrische.me/pages/quakec_bytecode_hello_world.... Quake 2 moved to native binaries. Quake 3 had a new VM that enabled compiling regular C using LCC: [1] https://fabiensanglard.net/quake3/qvm.php [2] Spec - https://www.icculus.org/~phaethon/q3mc/q3vm_specs.html

Lua became pretty popular to use in other games for the purposes of scripting, but no surprises there I guess.

Lesser known- games using Havok Physics may have used Havok's MOPP (a bytecode and interpreter for partitioning and searching the geometry).

https://github.com/niftools/nifxml/wiki/Havok-MOPP-Data-form...

Re: Bytecode VMs in surprising places (2024)

#65

Post by mastermage »

genxy wrote: post #53
ykl wrote: post #49

A medium-spicy take of mine is that a bytecode VM in a GPU kernel is not as bad of an idea as one might think, and in some cases it can actually be the most reasonable solution. Some fun examples: 1. As mentioned in the post above, the Dolphin emulator famously implements the entire Gamecube/Wii GPU pipeline in a single gigantic ubershader, and this is useful because it avoids shader compilation stalls [1]. 2. Blende…

Linux running in a shader https://blog.pimaker.at/texts/rvc1/

thats crazy

Re: Bytecode VMs in surprising places (2024)

#66

Post by aa-jv »

Being a Debian Guy, I recently found that RPM's .spec-file macro format was an unnecessarily tedious affront to my dignity, requiring immense ergs of patience to learn and understand - that is, until I discovered that underneath it all is a Lua VM - in which case I rapidly became a .spec afficionado and advocate upon loading up the REPL-like tooling to do some actual work.

It was a delightful, yet bittersweet surprise, to discover my favourite language and VM of choice was the cause of so much frustration - but yet, once I was able to wrangle my .spec files via the REPL, a certain kind of zen state was attained and I was actually able to ship the .spec properly.

I continue to be amazed at just where and when the Lua VM pops up. I've used it myself for many, many wonderful things, and shouldn't be surprised of course .. because Lua is the VM that just keeps on giving. It is out there in so many wonderful places ..

Re: Bytecode VMs in surprising places (2024)

#68

Post by account42 »

gmerc wrote: post #43
dlojudice wrote: post #25

Another World (Out of this world) game had its own bytecode [1] [1] https://github.com/fabiensanglard/Another-World-Bytecode-Int...

Many games have. Neverwinter Nights (and descendents like the Witcher), Dragon Age, Jade Enpire implemented their own byte code scripting language. Fun fact, for the console port of Dragon Age: Origins the scripts were cross compiled to cpp.

Many games have their own scripting system with or without byte code. This is however not the same as Another World where the entire game is implemented on top of a small VM.

Re: Bytecode VMs in surprising places (2024)

#69

Post by anthk »

DonHopkins wrote: post #23
anthk wrote: post #22

Earlier quoted context omitted.

I ran EForth under the Subleq from Howe R.J at https://github.com/howerj/muxleq (the subleq one) first at QuickJS (trivial tasks, almost a 1:1 map from the C code, made in a hurry) and under... jsinterp.py from the infamous yt-dlp but using arrays instead of printing functions. But... if yt-dlp's "mini-JS" implements some captcha input functions... you can add I/O with ease and run EForth with what they call (not me)…

You may need to write a WebGPU shader and run it in a Beowulf Cluster to make that run fast!

I ran EForth under Muxleq (multiplexed subleq) under an n270 Atom (32 bits Intel) and was fast enough. Much slower than GForth or even PFE (which is slow compared to GForth), but usable even to do Algebra exercises. Rendering a Mandelbrot fractal (ASCII) lasted half a minute but it's amazing that few lines of C enable you to run a Forth with input composed of numbers. I even have a backup in paper.

https://sites.google.com/view/win32forth/win32forth-readme/m...

I did some syntax changes for floats and that's it.

Re: Bytecode VMs in surprising places (2024)

#70

Post by hansvm »

twic wrote: post #57
hansvm wrote: post #39

Earlier quoted context omitted.

Pickle is definitely turing-complete. It's a super easy way to RCE your system.

Where does that come from though? I don't see any flow control or anything else compute-y in the bytecode itself. I know unpickling can run Python code, but i wouldn't say that makes the bytecode itself Turing-complete.

Among other things, a couple big culprits are STACK_GLOBAL, which converts strings on the stack into a Python object, functioning something like

  global_name = pop()
  module_name = pop()
  push(getattr(import_module(module_name), global_name))
And REDUCE, which executes code

  args = pop()
  f = pop()
  push(f(*args))
I think you're right that if you ignore the Python bits it's not a turing-complete stack machine, but I'm not sure ignoring those is fair.
Post reply on HN