Category:Sparkling: Difference between revisions
Content added Content deleted
(improved English; clarifications, corrections) |
No edit summary |
||
Line 42: | Line 42: | ||
<pre> |
<pre> |
||
$ spn |
$ spn hello.spn |
||
Hello, world! |
Hello, world! |
||
14 characters written |
14 characters written |
||
Line 59: | Line 59: | ||
* String manipulation |
* String manipulation |
||
* Array and associative array manipulation |
* Array and associative array manipulation |
||
* Floating-point and |
* Floating-point, integral and complex mathematical functions |
||
* |
* Shell and environment access (including system date and time) |
||
* Shell and environment access |
|||
== Implementation == |
== Implementation == |
||
Sparkling is an interpreted language, featuring a simple two-pass compiler and a register-based virtual machine. The compiler consists of a purely recursive descent parser and an almost naive (overwhelmingly non-optimizing) code generator, which directly generates bytecode for the VM. The compiler and the parser communicate using a right-leaning, binary abstract syntax tree (AST). The |
Sparkling is an interpreted language, featuring a simple two-pass compiler and a register-based virtual machine. The compiler consists of a purely recursive descent parser and an almost naive (overwhelmingly non-optimizing) code generator, which directly generates bytecode for the VM. The compiler and the parser communicate using a right-leaning, binary abstract syntax tree (AST). The REPL also contains a disassembler which can convert bytecode into an assembly-like, human-readable textual representation. |
||
Despite the fact that the reference implementation imposes an interpreted nature on the language, there are plans aiming to create a just-in-time (JIT) compiler back-end that produces native executable code (rather than bytecode targeting the VM). The implementation of the REPL also features a "compiler", which converts Sparkling source files into bytecode files. The format of the bytecode is not portable, so such an "object file" runs only on the platform/architecture it has been compiled on. This is done like so for simplicity and performance reasons: for example, floating-point and integer constants are stored in the bytecode as they are represented in memory, so that there needn't be any - potentially expensive and/or inconvenient to implement - runtime conversions. |
Despite the fact that the reference implementation imposes an interpreted nature on the language, there are plans aiming to create a just-in-time (JIT) compiler back-end that produces native executable code (rather than bytecode targeting the VM). The implementation of the REPL also features a "compiler" option (-c), which converts Sparkling source files into bytecode files. The format of the bytecode is not portable, so such an "object file" runs only on the platform/architecture it has been compiled on. This is done like so for simplicity and performance reasons: for example, floating-point and integer constants are stored in the bytecode as they are represented in memory, so that there needn't be any - potentially expensive and/or inconvenient to implement - runtime conversions. |
||
Although the primary goal of Sparkling is to be used as an extension language, there is a separate, stand-alone program that comes with the source as well. It contains an interactive interpreter (REPL, read-eval-print loop), a compiler and a disassembler. |
Although the primary goal of Sparkling is to be used as an extension language, there is a separate, stand-alone program that comes with the source as well. It contains an interactive interpreter (REPL, read-eval-print loop), a compiler and a disassembler. |
||
Line 81: | Line 80: | ||
== Debugging == |
== Debugging == |
||
Apart from the already mentioned disassembler, the virtual machine provides a basic stack tracing feature, which can be accessed using the C API. |
Apart from the already mentioned disassembler, the virtual machine provides a basic stack tracing feature, which can be accessed using the C API. Efforts are being made for extending the bytecode format with basic debug |
||
information (filename and line numbers). |