??Log 4: How I created my own programming language?

Disclaimer: If you haven't read the previous article, you may not fully understand this one. Click here to read!

Saksham Rapid Object Notation (SRON) is a high-level, procedural, dynamically typed, and compiled + interpreted programming language that provides an easy and expressive syntax along with exceptional speed, surpassing Java, Python, C#, JavaScript, and even C in many cases.        

In the previous article, I revealed many of my personal experiences, including "what type of approach I used to implement the compiler" and "why I created SRON, a compiled + interpreted programming language". In this article, I will explain everything about SRON's bytecode and its implementation.

After deciding to make SRON both compiled and interpreted, it was time to decide on the format of the bytecode. Bytecode is a type of code that cannot be directly executed by the operating system like '.exe' or '.bin' files (which are executable files) but can be executed using software we call "Interpreters".

Before anything else, I had to split the codebase into two parts: compiler and interpreter. So, I created two folders: 'sron_compiler' and 'sron_interpreter'. Then, some header files were moved to the 'sron_compiler' folder and some to the 'sron_interpreter' folder.

I felt confident after doing this because I knew that my goal of creating a fast and efficient language was going to be accomplished. I started focusing on writing the compiler and constantly brainstormed about how I could create the bytecode.

I don't know why, but a thought kept hitting my mind: using backticks (`), which are used to create multiline strings in JavaScript. This idea was great, and I started working on it. I created many bytecode flags using this technique, which are used to map flags to functions in the interpreter.

Here is a sample code and its bytecode:

Source code-
{
    name: MAIN
    println("Hello, World")
}

Bytecode-
`F
`(
`Sv
Hello, World
')        

?This format of bytecode makes it easier to implement the interpreter without affecting the speed of code execution while achieving platform independence and reducing machine instructions, memory usage, and power consumption.

??The only problem with this approach is that it can be decompiled easily, but I am currently experimenting with some techniques to solve this issue. Every different type of value like Int, Double, Char, String, List, keyword, etc., has its own distinct flag, which is synced perfectly between the compiler and interpreter, resulting in accurate output.

The speed of the interpreter depends on the structure of the bytecode. To provide faster execution, SRON's compiler optimizes the bytecode by generating closing indices while writing the bytecode to the file, allowing the interpreter to execute long, complex programs at incredible speeds.

Being a vector-based compiler, the interpreter also needs to be implemented using vectorization, but the interpreter is built differently. You will learn the secrets behind the interpreter in the next article, coming on July 21, 2024.

Thanks for reading this article and be awesome enough to subscribe to this newsletter for such insights and knowledge.