Amy Parent

Hi, I’m Amy Parent! By day, I study cloud evolution in brown dwarfs at Abertay University. By night, I get bruises skating with Dundee Roller Derby and make video games.

To Abertay University

A few days ago, Dr. Waiton, lecturer at Abertay University, published a vile transphobic opinion piece in The Herald Scotland. Abertay’s support was an important part of my early transition, and this goes against the university’s stance of acceptance of LGBT+ students and staff. Here’s the comments I’ve sent as a complaint to the university. If you are in any way touched by this issue, please send your comments as well to the Abertay SA, and take the time to sign the LGBT+ society’s petition asking the university to put in place a zero-tolerance policy on discriminatory speech.

To Abertay leadership: while you may think a lecturer’s personal “opinion” (hate speech) does not reflect your stance on inclusivity, this will reflect on the university, and this will impact transgender and gender non-conforming students and staff. Please do not let it pass.

warning: this contains references to transphobic comments that might upset you. Please only click through if you feel up to dealing with such language

continue reading →

Syntax Trees and C

So as I mentioned in the last entry, I’m at the stage where the parser for orbit is working – not complete, but complete enough that it parses a file properly, and that it provides a good framework to which I can add a feature or two add whenever I have a few hours available to work on Orbit. That’s pretty cool in and of itself.

So after the parser comes the semantic analyser, optimiser and code generator. In the first compiler I wrote (palc, for a the Language & Compilers class), semantic analysis and code generation calls were done inline, in each of the parser’s recognisers. I considered doing this for Orbit too, because it’s simple.

The problem with that approach is that it’s not exactly flexible. Since bytecode is generated as the parser goes down the file, you can’t exactly play with the bytecode structure, so optimisation goes out of the window. It’s also not extensible, since everything is called from the parser. So instead, I’m going to do it using an Abstract Syntax Tree (AST).

continue reading →

Orbit's VM & Parser

So between the end of fourth year, my summer job and now gearing for my PhD, I haven’t had much time to work on Orbit, even less write about it. That’s not great, since the changes I’ve made over eight months are fairly significant once you add all of them up, and I have little record of the development, save for the git history.

I thought I’d at least do a quick recap here, before I can go back to (hopefully) more regular posts about the many wonderful horrors of compiler building I’m discovering!

continue reading →

Return of the Function Call

I have discussed function invocation in Orbit before, but then it was all about resolving functions and handing control. This part is (I think) done. like I’d said last time, I’ve gone with a hybrid message/direct dispatch system. On first invocation, the function is resolved by name, in a hashmap. The bytecode is then doctored so that future invocations are just a matter of following a pointer to the function’s bytecode (code on github).

Calling Convention

Something I need to think about now is how I do parameter passing and local variables. OrbitVM is stack-based, so parameters must be passed, well, on the stack.

continue reading →

OrbitVM Execution

So I now have the beginning of a type system (need to write about this) and a garbage collector for Orbit, which means I need to start thinking about how bytecode actually runs.

I want to have system close to java’s, where the machine takes in compiled object files that contain the bytecode for a script, along with the constant pool and user-defined type. That’s step 1.

Where it gets a bit less clear to me is what happens when I want to start running the newly loaded module (let’s call it a module). Ideally, it’s a call to orbit_run(OrbitVM* vm, VMModule* module, const char* signature). So in order to have that, I have to do a few things.

continue reading →

More OrbitVM Dispatch

I’ve read a bunch, and thought more about my problem with the dispatch table I have so far for Orbit. I really don’t like having the possibility of a hash collision breaking a function call. This is one of the most basic building blocks of the language, and I can’t have that not be 100% predictable.

back to the drawing board then. I was worried about potentially comparing multiple strings every time a function is invoked, but I can avoid that. If I store both the function signature’s length, hash and string pointer, I only need to compare strings if both the lengths and hashes match (which is unlikely). So now I’m down to somewhere between one and “a few” string comparisons on for each call, even though it should be one 99.99% of the time, and it’s very unlikely to be more than two. Better.

continue reading →

OrbitVM Dispatch

I’ve made some progress on Orbit – well, I’ve setup the project directory and started playing around with tagged unions for the VMValue type system. I’ve also made the repository public, even though it’s still pretty rough.

I’m now getting to the point where I can write a simple interpreter loop, and start thinking about function dispatch. I really like full dynamic dispatch like Objective-C does – that is, message-based dispatch: each function call is done by name, followed by a dispatch table lookup before invocation.

continue reading →

Adventures in Language Design

Apparently, my brain isn’t satisfied with having to manage fourth year and my honours project, so I needed (yet another) side project. I’m making my own programming language, probably called Orbit (or OrbitVM).

The (far-away) end goal would be to use the language for scripting in the upcoming rewrite of my game engine (look ma, another side project!). For the time being though, I’ll be happy if I can run simple scripts with the basics of any language: a type system, functions, flow control, possibly some lightweight object system.

I don’t particularly fancy going all the way down to machine code, so it’ll be VM-based, very much like Java: a compiler that compiles each script file to a bytecode file, and a VM that loads those files and runs the main() function.

continue reading →