Add libgccjit note.HEADmaster

2 files changed, 54 insertions, 0 deletions

diff --git a/html/index.md b/html/index.md
index 94620f2..c8c5024 100644
--- a/html/index.md
+++ b/html/index.md
@@ -34,3 +34,4 @@ because writing the code often gives you yet another perspective.
 * [Does the decoder implement macros?](notes/macros.html)
 * [Better syntax-rules?](notes/sr.html)
 * [Cons cell optimization?](notes/fastcons.html)
+* [Using libgccjit?](notes/libgccjit.html)
diff --git a/notes/libgccjit.md b/notes/libgccjit.md
new file mode 100644
index 0000000..8ecf4f2
--- /dev/null
+++ b/notes/libgccjit.md
@@ -0,0 +1,53 @@
+# Using libgccjit?
+
+The installed size of libgccjit varies from 18 MB (armhf) to 53 MB
+(riscv64), with 37 MB for amd64.
+
+That's quite large.  I wonder how much it could be stripped down if
+you linked to it statically and didn't use all parts of it?
+
+If I did use it to implement Zisp, I suppose I could offer the choice
+of generating binaries that don't actually link to the full Zisp
+runtime.
+
+So, the final situation could be as follows, for example:
+
+- The "meat" of Zisp would be a .so whose size is in the order of tens
+  of MBs.
+
+- A tiny wrapper executable linked to this .so would be the entry
+  point to both an AOT compiler and a REPL for Zisp.
+
+- Fully dynamic "lisp machine" applications (in the spirit of Emacs)
+  that are both written in Zisp and support dynamic Zisp evaluation
+  would have this .so as a runtime dependency, or need pretty much all
+  of it to be compiled in.
+
+- However, the Zisp AOT compiler could also output binaries (dynlibs
+  and executables) that don't actually have zisp.so as a runtime
+  dependency.
+
+What if someone just wants to use a tiny script written in Zisp?  If
+you want to use a tiny script written in Perl, Python, etc. you still
+need the entire thing, so maybe it'd be acceptable for such scripts to
+have full Zisp package as a runtime dependency.
+
+Alternatively, Zisp could be split into a number of dynlibs that
+implement different parts of it: zisp-gc.so, zisp-parser.so,
+zisp-intrpr.so, zisp-comp.so, and so on, where zisp-comp.so would
+probably be the largest.  There could be a "Zisp interpreter" package
+that doesn't depend on that one.
+
+Alternatively #2, there could be a ZispScript language that consists
+of a strict subset of Zisp (e.g. no static typing, no eval) and an
+interpreter for this language could simply be a program that happens
+to be written in Zisp but doesn't depend on the full Zisp .so since it
+doesn't use the native compiler.  However, what if someone wants to
+write a program that *includes* a Zisp interpreter...
+
+I think a combination of the two above ideas would be best: ZispScript
+would be implemented by a library written in Zisp, zispscript.so,
+which can be linked to if you want to write a program that can execute
+ZispScript at runtime, and also the ZispScript package would come with
+a little wrapper executable that invokes zispscript.so to interpret
+scripts with a #!/usr/bin/zispscript shebang or such.