Date: Wed, 30 Apr 1997 03:53:31 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: bde@zeta.org.au, config@freebsd.org Subject: Re: Startup userconfig parsing Message-ID: <26868.862397611@time.cdrom.com> In-Reply-To: Your message of "Wed, 30 Apr 1997 19:39:13 %2B0930." <199704301009.TAA28293@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> I was actually looking at a couple of slightly smaller interpreters, > based purely on the issue that tcl wants too many system services. I Yes, that it most unfortunately does. :( Last time Poul-Henning was making semi-serious noises about this, I looked into it quickly and then looked away again just as quickly. The entire file I/O system would need to be hacked off with a knife and reimplimented in a much more kernel-centric context, for one thing, and we don't even want to talk about the process control. :) > You were tinkering with a Forth interpreter a while back Jordan; what > happened to it? How about the Forth spoken by the OpenBoot PROMs? OK, forth is actually a really good candidate for this given its size, highly stand-alone nature and the extremely trivial I/O demands of KEY, ?TERMINAL and EMIT. :) [or would we add classic forth block disk I/O too? :-)] The problem likes not with forth, but with its available public implementations: They all suck, in one crucial way or another. :-( In the x86 forth arena you have a highly confusing array of options, most very DOS specific and what you'd wind up with would still be a non-portable kernel bootstrap mechanism (swell - just what I wanted to do, write an ALPHA forth next. NOT. :-), so we can probably write them off for right now, despite some compelling speed advantages (but hey - this ain't for racing, right? It's for getting to the race track :-). In the C forth arena, you have: pfe forth Alan Pratt's C-forth. Mitch Bradley's C-forth. TILE forth. ATLAST pfe forth I don't really have an opinion on yet, having played with it very little (it's in ports/lang/forth). My initial impression is that it's a little on the chunky side. Perhaps to be avoided for kernel embeding. Alan Pratt's original forth is a mess. To be avoided, period. Mitch Bradley's C forth is actually pretty good, but it's also a commercial product and I don't know what his feelings towards it are. He gave me redistribution permission once when I wanted to port it to the pc532, turning it into something ROMable, and it didn't seem like he was that worried about it (and that was *years* ago - he probably cares even less, now :). Oh yeah, I didn't actually end up using it for the forth ROM either - a friend and I got carried away over a weekend and simply wrote a FIG implementation from scratch in NS32K assembly. God, what an instruction set - it was actually FUN to write assembly for that machine. :-) Anyway, moving right along... TILE forth is definitely too huge (and kind of, well, "strange" about some things :). I don't think it would be good for a boot forth. And finally, the one I was actually playing with recently, is "atlast" Atlast (by John Walker of AutoCAD fame) is actually very small, very easy to embed into C (in fact, that was its purpose) and very easy to add new words (in C) to. The bad news is that it's not like any other "forth" you've ever used and can probably be more correctly called a "mini forth", almost enough to bootstrap in all the fancy words you're used to from FIG forth or Forth83 but not quite in all respects. I finally gave up on atlast as not a "real enough" implementation of forth for a complete sysinstall type solution, but perhaps it's enough for bootstrap purposes. I dropped a copy of atlast 1.0 into my home directory on freefall. Otherwise, we could ask Mitch for his forth. I think that'd be the best "full forth" solution, if we even want to go that route. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?26868.862397611>