Home

Welcome to the Tagha Virtual Machine wiki! the Wiki is always being updated to account for iterative changes.

Purpose:

The purpose for Tagha's existence is to utilize C as an embeddable scripting language or, for better words, Tagha is an embeddable runtime environment meant to execute C code that's been compiled to Tagha bytecode via compiler. Tagha was designed to be used as a viable alternative to a C plugin architecture via dynamically loaded dll's, especially with the advantage of being able to run C code without having to recompile the dll's for different operating systems and ABIs at the cost of native machine code performance.

Rationale:

• 1. give C (and by extension C++) binary portability.
• 2. be fast.
• 3. be open-source.
• 4. have a runtime environment without having dependencies (beyond libc of course)
• 5. be portable and embeddable for any program and platform.
• 6. be small and minimal.
• 7. be memory safe.

Requirements:

• C99 compliant C compiler.

Features

• Self-contained, meaning that everything the code base needs is packaged together and there's no dependencies except for C standard lib obviously.
• Has its own, open source implementation of libc.
• Register-based virtual machine that handles immediate values, register, and memory operations.
• floats and doubles are supported on the same floating point opcodes through addressing modes.
• uses computed goto dispatches (the ones that use a void*) which is 20%-25% faster than a switch {citation}.
• Tagha is "64-bit" as the registers and memory addresses are 64-bit. (may run slower on 32-bit systems/OSes)
• Embeddable into host applications.
• scripts can call host-defined functions (Native Interface).
• host can give arguments and call script functions and retrieve return values, thus you can set up function event handling to scripts.
• host can bind its own global variables to script-side global variables by name (the script-side global variable must be a pointer).
• integer and float arithmetic, (un)conditional jumps, comparison operations, and stack and memory manipulations.
• function call and return opcodes automatically execute function prologues and epilogues.
• VM is little-endian format architecture.
• very small. The tagha runtime environment static library is typically under 50kb in size.
• Tagha is not natively threaded, this is by design, this is so any developer can thread Tagha in anyway you wish whether by having a single VM instance run multiple scripts in a multi-threaded, managed way OR have an array of Tagha VM instances each running their own scripts in a threaded manner.
• Speed, tagha is very fast for a virtual machine that does not use a JIT.
• Memory safety. Tagha is memory safe by bounds checking memory to make sure memory isn't from outside a script's data. Memory safety does have the cost of some speed and prevents script's from directly using memory that doesn't belong to it.

FAQ

• Q: why not just pick a scripting language?
• A: You're right. Any developer could simply choose an existing scripting language and its implementation, but not all developers want to use a scripting language and they could have various reasons like performance, syntax, maybe the runtime is too bloated. Secondly, not all developers might know the language or are comfortable with it. Perhaps for the sake of consistency with the code base, they want the entire code to be in one language. After all, to be able to utilize the scripting language, you'd need to learn it as well as learning the API.
• Q: Why implement TaghaVM in C and not C++?
• A: The design choices I gave to TaghaVM was to be minimal, fast, and with little-to-no dependencies except for a few C standard library functions. To achieve this, I needed to use C which allowed me to manipulate memory as fast and seamless as possible. I'm aware C++ allows me to manipulate memory but it's not without trouble. Secondly, TaghaVM should be no bother to C++ programmers since a C++ interface is available from tagha.h.
• Q: Can TaghaVM be used to implement any language?
• A: Yes but not perfectly. If we take Lua's example, Lua values are entirely pointers to a tagged union type in which the types are either a float value, string, or table/hashmap. Since most of TaghaVMs registers are general-purpose (can hold/use memory locations), they can hold/use the Lua values themselves but Lua's high level opcodes would have to be broken up into lower level operations since Tagha is a low-level VM that operates upon the byte sizes of the data, regardless of their actual types. This could possibly result in worse performance than just running Lua's code on its respective VM.