Overview
SolarSharp uses a register-based bytecode virtual machine inspired by LuaJIT and other modern Lua runtimes. Scripts can be compiled to bytecode, serialized (dumped) for distribution, and loaded back for execution.Compiling to Bytecode
All Lua scripts are automatically compiled to bytecode when loaded:Dumping Bytecode
You can serialize compiled functions to bytecode using theDump method:
Using string.dump
You can also dump functions from Lua code:Restrictions
Functions with upvalues (closures) other than_ENV cannot be dumped:
Loading Bytecode
Load compiled bytecode usingLoadStream:
Base64-Encoded Bytecode
SolarSharp supports loading Base64-encoded bytecode strings:Bytecode Format
File Header
Every bytecode dump begins with metadata (12+ bytes):- Magic Number (8 bytes):
0x1D4F4F4E23020D1Aidentifies SolarSharp bytecode - Version (4 bytes): Current version
0x150 - Upvalues Flag (1 byte): Whether function has upvalues
- Instruction Count (4 bytes): Number of bytecode instructions
Architecture
SolarSharp uses a register-based VM (not stack-based like standard Lua 5.x):- Each instruction is 32 bits (4 bytes)
- Supports up to 256 registers per function
- 64 opcodes available (6-bit opcode + 2-bit sub-opcode)
- Constant tables for integers, floats, strings, and upvalues
Instruction Format
Most instructions follow this structure:| Field | Bits | Description |
|---|---|---|
| A | 8 | Register/constant index |
| B | 8 | Register/constant index |
| C | 8 | Register/constant index |
| OP | 6 | Primary opcode |
| OP2 | 2 | Secondary opcode/variant |
Example Operations
Memory Operations:Performance Considerations
Register VM Benefits
- Fewer instructions for common operations
- Less stack manipulation overhead
- Better CPU cache utilization
- Optimized for JIT compilation (future enhancement)
Type Hints
Bytecode includes type hints (OP2 field) for optimization:CLI Compilation
Use the SolarSharp CLI to compile scripts:See Also
Performance
Optimize script execution
Debugging
Debug compiled scripts