From 4f400d7aabcd649088575a3b4743192b1914b68a Mon Sep 17 00:00:00 2001 From: nocturn9x Date: Sat, 13 Nov 2021 19:47:22 +0100 Subject: [PATCH] Changed all references of NimVM to JAPL's --- docs/bytecode.md | 10 +++++----- docs/grammar.md | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/bytecode.md b/docs/bytecode.md index 576ebc5..7062996 100644 --- a/docs/bytecode.md +++ b/docs/bytecode.md @@ -1,8 +1,8 @@ -# NimVM - Bytecode Serialization Standard +# JAPL - Bytecode Serialization Standard ## Rationale This document aims to lay down a simple, extensible and linear format for serializing and deserializing -compiled NimVM's code to a buffer (be it an actual OS file or an in-memory stream). +compiled JAPL's code to a buffer (be it an actual OS file or an in-memory stream). ## Disclaimer ---------------------------------------------- @@ -77,7 +77,7 @@ An object file starts with the headers, namely: ### Constant section -This section of the file follows the headers and is meant to store all constants needed upon startup by the JAPL virtual machine. For example, the code `var x = 1;` would have the number one as a constant. +This section of the file follows the headers and is meant to store all constants needed upon startup by the JAPL virtual machine. For example, the code `var x = 1;` would have the number one as a constant. Constants are just an ordered sequence of compile-time types as described in the sections above. ## Behavior @@ -86,8 +86,8 @@ The main reason to serialize bytecode to a file is for porting JAPL code to othe When JAPL finds an existing object file whose name matches the one of the source file that has to be ran, it will skip processing the source file and use the existing object file only if: -- The object file has been produced by the same JAPL version as the running interpreter: the 3-byte version header, the branch name and the commit hash must be the same -- The object file is not older than an hour (this delay can be customized) +- The object file has been produced by the same JAPL version as the running interpreter: the 3-byte version header, the branch name and the commit hash must be the same for this check to succeed +- The object file is not older than an hour (this delay can be customized with the `--cache-delay` option) - The SHA256 checksum of the source file matches the SHA256 checksum contained in the object file If any of those checks fail, the object file is discarded and subsequently replaced by an updated one after the compiler is done processing the source file again. Since none of those checks are absolutely bulletproof, a `--nocache` option can be provided to the JAPL executable to instruct it to not load nor produce any object files. diff --git a/docs/grammar.md b/docs/grammar.md index 90819ce..6e79289 100644 --- a/docs/grammar.md +++ b/docs/grammar.md @@ -1,7 +1,7 @@ -# NimVM - Formal Grammar Specification +# JAPL - Formal Grammar Specification ## Rationale -The purpose of this document is to provide an unambiguous formal specification of NimVM's syntax for use in automated +The purpose of this document is to provide an unambiguous formal specification of JAPL's syntax for use in automated compiler generators (known as "compiler compilers") and parsers. Our grammar is inspired by (and extended from) the Lox language as described in Bob Nystrom's book "Crafting Interpreters",