zackoverflow
Joined 5 years ago
Karma
1,410
Submissions
70
Member since
Sep 16
Recent submissions
Comment · 5 months ago
Comment · 11 months ago
I recently came across this style of interpreter which V8 and HotSpot use. It works by actually writing the bytecode op handlers in assembly (or some other low-level language) and generating them to machine code, and having a dispatch table mapping bytecode_opcode -> machine code to execute it
I was pretty intrigued. How does it compare to techniques which require way less engineering cost like switch+loop, direct-threaded, and only using tail-calls (https://blog.reverberate.org/2021/04/21/musttail-efficient-i...)?
The main reason seemed to be that both V8 and HotSpot have an optimizing JIT compiler, and having low-level control over the machine code of the interpreter means it can be designed to efficiently hop in and out of JIT'ed code (aka on-stack replacement). For example, V8's template interpreter intentionally shares the same ABI as it's JIT'ed code, meaning hopping into JIT'ed code is a single jmp instruction.
Anyway, I go into more implementation details and I also built a template interpreter based on HotSpot's design and benchmarked it against other techniques.
Comment · 2 years ago
> Note that the context pointer came after the “standard” arguments. All things being equal, “extra” arguments should go after standard ones. But don’t sweat it! In the most common calling conventions this allows stub implementations to be merely an unconditional jump.
I didn't know this. Does this optimization have a name? Where can I read more about it?
Comment · 3 years ago
Does anyone have any insight on why the PikeVM implementation is slower (it's based on the VM approach described here https://swtch.com/~rsc/regexp/regexp2.html)
I feel like compiling regex to bytecode and executing it should be faster than dealing with big graph like structures with NFAs/DFAs
Also, V8's regex engines are very fast because they get JIT compiled to machine code, so wouldn't bytecode just be one step higher in abstraction, and have worse but similar performance?
Comment · 3 years ago
Most of the time you don't need to do this, usually its the solution for when creating a graph structure with cyclic references.
But when you do, and your data is mutable, generational indices are a legit and very useful strategy that is used in C/C++ too.
See this: https://floooh.github.io/2018/06/17/handles-vs-pointers.html
Comment · 3 years ago
Hey HN, I got inspired by a recent hack someone did of creating flappy bird in MacOS Finder, so I tried to do the same with type-level Typescript.
If you don't know, Typescript's type annotations are Turing complete, allowing you to compute anything with some clever type trickery.
In order to render graphics from Typescript's types, I ended up creating a compiler that compiles Typescript's types into bytecode, and a custom VM that can execute that bytecode.
Each frame, the VM takes draw commands from type-level Typescript, and renders it using the configured graphics backend. It can run in the browser by compiling the VM to Wasm and using the web's Canvas API.
If rendering is not aligned then it's possible for the terminal emulator to read the framebuffer while the application is writing to it, causing visual artifacts.
[1] https://x.com/zack_overflow/status/2035921425341763756?s=20