The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: George Michaelson <>
To: Rob Pike <>
Cc: The Eunuchs Hysterical Society <>
Subject: [TUHS] Re: Porting the SysIII kernel: boot, config & device drivers
Date: Sun, 1 Jan 2023 11:16:16 +1000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

A counter argument which will be well understood as self-justifying if made
by a boot rom specialist:

Every machine I make winds up looking a bit different. The new bus has
different logic. The chip initialisation differs. Blobs become more
interestingly hard to handle because associated pre boot initialisation
dependency keeps rising and no amount of push back from me stops it.

If I make my boot ROM forth, I can reduce my marginal costs to writing
forth code for most variant handling and occasional uplift of new
primitives and constants into the forth for edge cases. My life gets
simpler if I implement the wheel of life.

I would imagine after the 10th sub variant, one would wind up thinking like

Of course a rational alternative is to maintain a monrepo of all the
variants and recompile all of them all the time to make all the boot ROMs
far smaller. But making the generic anything ROM and changing only some
forth would be attractive.

 Never owned this problem. I did work with two groups doing lsi-11 images
for x.25 handling on yorkbox, and they definitely thought more like you
than me on this: hand code it, code it well, they aren't general purpose
devices when doing this kind of job. (I annoyed them a lot which tends to
"probably they were right" in hindsight on my part)


[-- Attachment #2: Type: text/html, Size: 1621 bytes --]

  reply	other threads:[~2023-01-01  1:17 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-30 18:25 [TUHS] " Paul Ruizendaal
2022-12-30 18:56 ` [TUHS] " Steve Nickolas
2022-12-31 14:59 ` Dan Cross
2022-12-31 19:08   ` Clem Cole
2022-12-31 21:10     ` Dan Cross
2022-12-31 21:39       ` Clem Cole
2022-12-31 21:52         ` Dan Cross
2022-12-31 23:25         ` Dave Horsfall
2023-01-01  1:02           ` Rob Pike
2023-01-01  1:16             ` George Michaelson [this message]
2023-01-01  1:40               ` Larry McVoy
2023-01-01  2:29                 ` Warner Losh
2023-01-01  1:24             ` Larry McVoy
2022-12-31 22:38       ` Theodore Ts'o
2022-12-31 22:55         ` Marc Donner
2023-01-01  3:55         ` Dan Cross
2023-01-01 20:29         ` Paul Ruizendaal
2023-01-01 21:26           ` G. Branden Robinson
2023-01-01 21:31             ` Rob Pike
2022-12-31 21:11     ` Paul Ruizendaal
2022-12-31 20:02   ` Paul Ruizendaal
2022-12-31 21:04     ` Warner Losh
2022-12-31 21:41     ` Dan Cross
2023-01-01  3:08     ` Warner Losh
2023-01-01  4:40       ` Dan Cross
2023-01-01  8:05     ` Jonathan Gray

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:

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

  git send-email \
    --in-reply-to='' \ \ \ \

* 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).