[email@example.com: Re: bootstrapping from ECHO (SPOILERS)]
Kragen Javier Sitaker
kragen at canonical.org
Thu Apr 28 18:33:49 EDT 2011
Presumably the copy of the message Greg sent got bounced.
----- Forwarded message from Greg Alt <greg.alt at gmail.com> -----
Subject: Re: bootstrapping from ECHO (SPOILERS)
From: Greg Alt <greg.alt at gmail.com>
To: Dave Long <dave.long at bluewin.ch>
Cc: Kragen Javier Sitaker <kragen at canonical.org>,
kragen-discuss at lists.canonical.org
I had similar problems that someone mentioned about entering bytes
with ALT-xxx in dosbox, so I did it in a windows command line window,
and then switched to dosbox to run it.
I really like the ascii-only code, though - I had given that some
thought but decided it looked too tricky to figure out and I was more
interested in learning about the process of progressively jumping to
more complex languages, so I purposely took the quickest route I could
Btw, there are some bugs in the highest level version of my compiler
that make it choke on compiling complex code in scheme4 (such as a
scheme4 compiler written in scheme4, which was my next goal). Mostly
the issue is that I hadn't implemented garbage collection yet and the
way I compile nested if statements ended up consing way too much.
Implementing garbage collection in scheme3, though, turned out to be
quite a slog. It works, but still seems to choke at a later point,
and I'm not sure why - and as you can imagine debugging this stuff
without a proper debugger and error messages is slow going.
My hope was to get to scheme4 where adding error messages and simple
printf-style debugging would be relatively simple, but I'm not sure
how many hours of effort are needed to get to that point. From there,
I think things would accelerate - I had an idea for simply
implementing text symbols (rather than hex bytes for symbols), and
moving to 32 bit .exe from 16-bit .com would also be relatively easy.
If anyone wants to take a stab at it, I'd be happy to check in what I
have and give some notes.
It's definitely been a fascinating project. My goal was to learn some
higher level abstract concepts about how to think about bootstrapping
in general - even apart from computers, and I think I've learned a
On Thu, Apr 28, 2011 at 10:31 AM, Dave Long <dave.long at bluewin.ch> wrote:
> Just ran across someone doing a similar exercise:
> For what it's worth, I believe Lisp started life as an abstract pseudo-code
> that was hand-assembled, but once someone realized that eval was also within
> hackable grasp, an interpreter and subsequent compiler were not far off.
> John McCarthy:
>> Steve Russell said, look, why don't I program this eval..., and I said to
>> him, ho, ho, you're confusing theory with practice, this eval is intended
>> for reading, not for computing. But he went ahead and did it. That is, he
>> compiled the eval in my paper into [IBM] 704 machine code, fixing bugs, and
>> then advertised this as a Lisp interpreter, which it certainly was. So at
>> that point Lisp had essentially the form that it has today....
> In looking through my rudimentary python-based 8086 assembler, I'd guess a
> reasonable forward path might be:
> 0. hex/octal direct (tape-like) loader
> 1. (single character) labels, references (many possible implementations
> 2. control structures (branches, loops)
> 3. full (or at least reasonable) length symbol table
> It would even be possible to pipeline these steps, but then it might be
> useful to substitute (0a) a random-access loader (like SREC or HEX) to
> mitigate the two-pass nature of resolving references.
> Many tradeoffs in early language implementation were due to the relatively
> small and slow machines; I wonder if we would depart from them now that the
> available "brute force" space has expanded significantly?
> see also:
----- End forwarded message -----
More information about the Kragen-discuss