You could just use a C compiler to write the assembly code from this, and it'd be far less buggy.

Before there were LLMs, there were about 65 years of other program-writing-programs to save labor.

> I wonder if an LLM would be up to the job of writing the assembly code from this?

I could see a compiler doing that.

If it's speed you're after, much more analysis (and thus code) is needed. See V8.

A C compiler can output fairly readable code if you turn off optimizations, and it's definitely not going to take thousands of lines to do this in modern assembly. It may be only just barely a thousand lines to do this in aarch64, and the LLM can probably do it.

From what I've seen the LLM do it can definitely enhance these programs if you know what to ask, and it can explain how any piece this code works. It may even be able to add garbage collection to the evaluator since the root registers are explicit, and the evaluator only acts on static memory.

This is the path that the GNU Mes and Guix folks are taking: https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...

(sans LLMs -- I believe they have a Scheme (GNU Mes) that can be compiled from their 357 byte bootloader, and that Scheme can run a C compiler that can compile tinycc, and I think there's a path from tinycc to compiling gcc. I'm not sure how far it can get after that -- this blog post[1] implies that you still need a binary of guile to run Gash, which is a POSIX shell written in Scheme. I'm guessing the plan is to either simplify Gash or complexify Mes to be able to remove Guile as a dependency.

[1] https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...

> I wonder if an LLM would be up to the job of writing the assembly code from this

Why ask a cluster of GPU's to do something any single CPU from the last 30 years can accomplish?

If your Scheme were a native compiler rather than an interpreter (i.e. like Chez) and written in (a constrained subset of) Scheme, then you could use an itty-bitty Scheme interpreter written like this to bootstrap the core of your native Scheme compiler so that the interpreted version of it could compile itself to native binary.

Given that this was the path that one of Dr. Dybvig's post-doc acolytes, Dr. Michael Ashley, taught us in his Scheme-based compiler class, I must guess that this was also Kent's path and that that was the intent for this little interpreter. I suppose I should (finally) take the time to read his dissertation.

Thanks! Do you mean MIT Scheme's C backend? I've used MIT Scheme on and off for a long time and have never touched the C backend & have no idea how it works, so this is interesting.

(MIT Scheme also has a native code compiler for Intel CPUs, which seems to be what most users of MIT Scheme (an admittedly small community) actually use.)

I think a very rudimentary implementation (which is easy to understand) is in the SICP book

       sudo chicken-install srfi-203

       sudo chicken-install srfi-216

    (import scheme)
    (import (srfi 203))
    (import (srfi 216))

I don't see anything in the manual about MIT scheme compiling to C, just to its own native code object files and some portable bytecode...

https://www.gnu.org/software/mit-scheme/documentation/stable...

You'll still probably need the `strcmp` because the pointers won't be the same unless you check for them and make them the same.

You may be thinking about how `eq?` (reference equality) works in scheme. That's usually done by hashing the identifier string. Which is the more general solution to this equality problem.

Reading and hacking on the Chez Scheme codebase is always a treat and rather inspiring, especially compared with more mainstream compilers and code generators. As well as Kent Dybvig, Andy Keep's contribution (nanopass) is super-impressive. The whole thing is so cleanly designed and beautifully expressed.

I had the great pleasure of studying compilers, and then optimizing compilers, with Dybvig at IU in the late 2000s. He was a phenomenal professor; obviously deeply knowledgeable (that's a given), but also uncommonly gifted at imparting that knowledge.

I took his Compilers class about 30 years ago. I really wish I still had those notes.

It works but it can’t do much other than demonstrate semantics. The evaluator won’t even be able to add numbers for example.

I couldn't get it to do much. Also noticed a subtle bug here:

  next = compile(read(buffer), cons("halt", NULL));

C doesn't guarantee the order in which arguments to a function are processed. Since 'cons' relies on 'read' being called first, the result is undefined behavior. (In fact I had to fix that before it would even "run" on my system.)

This is an implementation of an interpreter from his dissertation. https://www.cs.unc.edu/xcms/wpfiles/dissertations/dybvig.pdf

If textptr is not an element of the text array, then it's undefined.