The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Dan Cross <crossd@gmail.com>
To: Larry McVoy <lm@mcvoy.com>
Cc: The Unix Heritage Society <tuhs@tuhs.org>
Subject: [TUHS] Re: Question about BSD disklabel history
Date: Tue, 2 Jan 2024 15:48:28 -0500	[thread overview]
Message-ID: <CAEoi9W7VAsQaXGc5YCFQ8m=WcYPyNvsL0dnDdt-fjp8EgLxygw@mail.gmail.com> (raw)
In-Reply-To: <20231231230615.GE19322@mcvoy.com>

On Sun, Dec 31, 2023 at 6:25 PM Larry McVoy <lm@mcvoy.com> wrote:
>[snip]
> OpenFirmware is Mitch Bradley's baby.  I believe it ran on 68k Suns,
> there was some sort of boot prom there.  I mostly used it on SPARC.
> It was pretty powerful but my personal feeling is the choice of
> Forth didn't help.  Yeah, I get it, Forth is like some weird lisp
> and the lisp people love lisp.  What the lisp people don't get is
> there are a lot more people who don't love lisp than do love lisp.
> And trying to get everyone to love lisp isn't gonna happen.
>
> That said, what else could Mitch have used at the time?  Tcl?
> Please, another weird lisp.  Perl?  Not really something that
> wants to talk to the bare metal.
>
> It's a serious question, is there anything that Mitch could have
> used that would have had wider appeal?

The thing about FORTH isn't that it's Lisp-like (as Alec mentioned),
though its supporters do often exhibit a fervor reminiscent of
Lispers.

Rather, I think FORTH shows up in places like this because it's
possible to write _incredibly_ lean threaded-code interpreters for it
that can run in really primitive environments, so you can shove a
really small interpreter in a ROM and keep your big CPU in reset while
you run it out of a tiny SRAM on an 8-bit microcontroller or something
until you've got enough of an environment going to train DRAM and
transfer over to the real thing. E.g., something like:
https://pygmy.utoh.org/3ins4th.html

What could you have done differently? Meh; I don't really know, but see below.

> And I agree whole heartedly with the EFI crap being a giant step
> backwards.

Ironically, the UEFI people have done something _similar_ to OF in the
form of AML (ACPI Machine Language), which is a byte-code
serialization ASL (ACPI Source Language); presumably that's system
independent. The idea of a p-code representation is about where the
similarity ends, though: AML exposes a mechanism to talk to the UEFI
OS for a whole slew of stuff, which is rather unlike what OF did
(though I again have a vague memory that on SPARCstations some devices
went through the PROM monitor; the text console, for example, and
maybe the keyboard? It's been too long now to properly remember).

Anyway, an alternative to FORTH might have been a well-defined p-code
and a little VM in ROM to drive it.  Then one could compile to that
using whatever language one liked (and was willing to write a compiler
for!). Perhaps the feeling is that that is what FORTH was; for that I
guess I don't see any reason one couldn't transpile to FORTH from some
other language.

        - Dan C.

  parent reply	other threads:[~2024-01-02 20:49 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-31 17:30 [TUHS] " Grant Taylor via TUHS
2023-12-31 17:38 ` [TUHS] " arnold
2023-12-31 20:07   ` Warner Losh
2024-01-01  0:13     ` Bakul Shah
2023-12-31 20:27   ` Phil Budne
2023-12-31 21:02     ` Warner Losh
2024-01-01  0:26   ` Grant Taylor via TUHS
2024-01-01  2:22     ` Warner Losh
2024-01-01  3:24       ` Grant Taylor via TUHS
2023-12-31 21:31 ` Clem Cole
2023-12-31 22:07   ` Warner Losh
2024-01-01 16:00     ` Clem Cole
2024-01-02 18:49       ` Warner Losh
2024-01-02 19:30         ` Chet Ramey
2024-01-02 20:07           ` Clem Cole
2024-01-02 19:50         ` Dan Cross
2024-01-02 19:55           ` Jim Capp
2024-01-02 20:11             ` Dan Cross
2024-01-02 20:30           ` Dan Cross
2024-01-02 20:50             ` Clem Cole
2024-01-02 21:04               ` Dan Cross
2023-12-31 22:46   ` G. Branden Robinson
2023-12-31 23:06     ` Larry McVoy
2023-12-31 23:37       ` Al Kossow
2023-12-31 23:41       ` Alec Muffett
2024-01-02 20:48       ` Dan Cross [this message]
2024-01-02 21:17         ` John Cowan
2024-01-03  3:33         ` Theodore Ts'o
2024-01-03  3:57           ` Warner Losh
2024-01-03  4:03             ` Warner Losh
2024-01-03  4:30             ` Theodore Ts'o
2024-01-03  5:10               ` Warner Losh
2024-01-03 15:56                 ` Dan Cross
2024-01-03 16:37                   ` Theodore Ts'o
2024-01-03 16:41                     ` Dan Cross
2024-01-04  8:42                     ` arnold
2024-01-04 18:26                       ` Kevin Bowling
2024-01-03 14:39           ` Dan Cross
2023-12-31 23:08     ` Phil Budne
2023-12-31 23:37       ` G. Branden Robinson
2023-12-31 23:59         ` Warner Losh
2023-12-31 23:50     ` G. Branden Robinson
2024-01-01  0:09       ` Al Kossow
2023-12-31 21:55 Norman Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEoi9W7VAsQaXGc5YCFQ8m=WcYPyNvsL0dnDdt-fjp8EgLxygw@mail.gmail.com' \
    --to=crossd@gmail.com \
    --cc=lm@mcvoy.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).