Live data from Hacker News

My Most Important Project Was a Bytecode Interpreter

gpfault.net

61–70 of 154 posts

Re: My Most Important Project Was a Bytecode Interpreter

#61
post #9

Also: a software rasterizer. Most people refuse to write one because it's so easy not to. Why bother? It will make you a better coder for the rest of your life. Let's make a list of "power projects" like this. A bytecode interpreter, a software rasterizer... What else?

I really recommend a raytracer, especially to anyone interested in graphics. It's straightforward, powerful, infinitely expandable with optional features, and opens up a ton of discussion about performance, code complexity, and general organization. Plus it's fun, in an instant gratification kind of way.

having written one as a slightly larger python thingy, i can fully attest to that.

now that it is kind of done, i want to make it faster :) for example, having a home-grown vector_3d class kind of sucks (performance wise). it might be better to have vector_3d be actually based on, say, numpy.array ? once that is done, and i start seeing some real improvement, it might be possible to go the other route as well i.e. write the hot-spots in c++/c, and interface that with python.

or go with lua all the way ? or maybe try a hybrid approach (which would allow you to see how embeddable the language really is)

possibilities are endless, and as you so rightly said, gratification is instantaneous :)

Re: My Most Important Project Was a Bytecode Interpreter

#62
Soulmate of yours here: https://clementbera.wordpress.com

Lots of optimizations going on for OpenVM.

https://github.com/OpenSmalltalk/opensmalltalk-vm

Interesting bit: VM is written in Slang and transformed into C then compiled.

So you can livecode your VM. In the VM simulator.

Re: My Most Important Project Was a Bytecode Interpreter

#64

Also: a software rasterizer. Most people refuse to write one because it's so easy not to. Why bother? It will make you a better coder for the rest of your life. Let's make a list of "power projects" like this. A bytecode interpreter, a software rasterizer... What else?

* A database (transaction, lock managers, buffer/IO management, etc).

* An MVC web framework.

* A GUI validation library.

* A JavaScript UI library.

* An iteratee implementation.

* An Erlang-style actors library in another language.

* Implementing for-yield, async-await, etc on top of delimited continuations.

* Interpreters, typecheckers, code generators.

* Some of an ECMAScript implementation.

* Concurrent data structures: futures/promises, queues, etc.

* A simple roguelike game.

Re: My Most Important Project Was a Bytecode Interpreter

#65
post #38

Earlier quoted context omitted.

I mean, the whole point of regexes (not to be confused with PCREs) is that any given regex is isomorphic to some canonical finite state machine. It is, specifically speaking, a tiny description of an FSM over the alphabet of ASCII characters (or whatever charset you're using). Interestingly, regexes/FSMs are (IIRC) the most powerful class of machines for which equivalence is decidable. So if you give me any two regex…

While it is true for Regular Languages (FSM) strict RegExs, it's hardly true for any contemporary implementation of RegExs. They have back references and other constructs that make them more powerful than a Regular Language, and thereby make it impossible to decide equivalence in the general case.

Hence "not to be confused with PCREs", which most pseudo-regex implementations are based off of.

Re: My Most Important Project Was a Bytecode Interpreter

#66

Earlier quoted context omitted.

You can write raw pixels to the screen with a HTML canvas and JS - no need to do it with low level code and making your own OS.

I bet you could go from main() to displayBufferOnScreen(unsigned char *buffer) in a couple dozen lines of C using SDL.

This is a good idea, as is the Javascript one above.

Re: My Most Important Project Was a Bytecode Interpreter

#67
post #65

Earlier quoted context omitted.

While it is true for Regular Languages (FSM) strict RegExs, it's hardly true for any contemporary implementation of RegExs. They have back references and other constructs that make them more powerful than a Regular Language, and thereby make it impossible to decide equivalence in the general case.

Hence "not to be confused with PCREs", which most pseudo-regex implementations are based off of.

I'll ask the "dumb question" then: What is a PCRE? How is it different than a "true" regex?

Re: My Most Important Project Was a Bytecode Interpreter

#68
post #38

One of the moments where I really started to feel like I was starting to 'see the matrix' was when I was working on a regex engine to try to make my compiler faster (it didn't, but that's another story). The asymptotically fast way to approach regex processing actually involves writing a parser to process the regex, so in order to write a fast compiler, you need to write another fast compiler to process the regexes t…

I mean, the whole point of regexes (not to be confused with PCREs) is that any given regex is isomorphic to some canonical finite state machine. It is, specifically speaking, a tiny description of an FSM over the alphabet of ASCII characters (or whatever charset you're using). Interestingly, regexes/FSMs are (IIRC) the most powerful class of machines for which equivalence is decidable. So if you give me any two regex…

Isn't it possible to decide the equivalence of deterministic pushdown automata? Wouldn't DPDAs be considered more powerful than FSMs due to the addition of a stack?

Wikipedia [1] shows there's a paper called "The equivalence problem for deterministic pushdown automata is decidable" that won the Gödel Prize is 2002. I haven't read the paper nor do I currently have access to it though.

[1] https://en.wikipedia.org/wiki/Deterministic_pushdown_automat...

Re: My Most Important Project Was a Bytecode Interpreter

#69
post #21

Also: a software rasterizer. Most people refuse to write one because it's so easy not to. Why bother? It will make you a better coder for the rest of your life. Let's make a list of "power projects" like this. A bytecode interpreter, a software rasterizer... What else?

Tracks I've done and suggested to friends and colleagues as learning experiences: * Compression (lossless, lossy, image, audio, texture, video) * Languages (bytecode interpreter, AST interpreter, parser/lexer for a simple language, simple JIT, understanding instruction scheduling) * DSP programming (writing programs for fast, branchless math) * Comfort with binary and binary formats (start with packfiles .zip/.tar, m…

This is an awesome list. Thanks!

Re: My Most Important Project Was a Bytecode Interpreter

#70
I've done something similar 21 years ago: a C interpreter targeting a virtual machine. The runtime had a dynamic equivalent of libffi to call into native code and use existing native libraries. I added extensions to run code blocks in threads so that the dinning philosopher problem solution was very elegant. Back in the days, not having libffi meant generating assembly on the fly for Sparc, MIPS, PA-Risc, i386. Fun times. That C interpreter was used to extend a CAD package.
Post reply on HN