Skip to content

A small experiment into building a bytecode compiled language with a time-traveling step debugger (step forward/backward)

License

Notifications You must be signed in to change notification settings

hadydotai/opdlang

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

37 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Opd Lang

Naming is hard okay. Anyway, Opd language is a bytecode compiled toy language that's not currently meant to be useful. In fact, about the only thing it does is print strings and do basic math.

The gist of it though is the debugger. Opd is bytecode compiled and bytecode interpreted, I wanted to implement a step, time-travelling debugger. The goal was to quickly get from point A to point B so I can start prototyping the debugger. The purpose is not to build or design a language, implement a good compiler or AST to bytecode translation.

Inspect the Bytecode

Here's an example of a bytecode dump for simple.dl

go run . compile samples/simple.dl -o simple.bc -r -lnone -d

simple.dl bytecode dump

Running go run . compile -h will give you all the details you need to know about the flags but for a quick reference regarding the above command:

  • -o sets the output file for the compiled bytecode
  • -r will run the compiled bytecode
  • -l will set the logging level to none, we're only interested in the program's output
  • -d will dump the bytecode in the format you see above for inspection

Debug the Bytecode

Here's an example of a debugging session for simple.dl

go run . compile samples/simple.dl -o simple.bc -r -lnone -d -s

simple.dl bytecode dump

  • -s will start execution in the step debugger with a breakpoint on line 1 of the source code

During debugging you can always inspect the source visually to see where you are in the execution line wise and where your breakpoints are at using source

> source

You can move the program counter forward or backwards using n or b.

Current bytecode limitiations

There's one glaring limitation in the current implementation of the compiler which I alluded to in run.go is that we don't store enough of the metadata with the bytecode needed for the VM and the debugger to run straight from the bytecode.

And the things we do store we don't read back from the bytecode file. The result of that is we need to go from AST->Bytecode->VM/Debugger. Hopefully will have time to fix it in the near future, for now it serves the original purpose.

License

Copyright (C) 2025 hadydotai

This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License along with this program. If not, see http://www.gnu.org/licenses/.

About

A small experiment into building a bytecode compiled language with a time-traveling step debugger (step forward/backward)

Topics

Resources

License

Stars

Watchers

Forks

Languages