From owner-freebsd-current Sun Nov 1 16:46:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07836 for freebsd-current-outgoing; Sun, 1 Nov 1998 16:46:20 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (castles33.castles.com [208.214.165.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07826 for ; Sun, 1 Nov 1998 16:46:18 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id QAA06857; Sun, 1 Nov 1998 16:45:47 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199811020045.QAA06857@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Mikael Karpberg cc: current@FreeBSD.ORG Subject: Re: New boot loader and alternate kernels In-reply-to: Your message of "Sun, 01 Nov 1998 15:47:20 +0100." <199811011447.PAA21479@ocean.campus.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Nov 1998 16:45:47 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > According to Mike Smith: > > I have no desire to miss it. Give me a compact Forth interpreter that > > links against libstand and you'll be seeing it everywhere Real Soon. > > Eeep! Umm... what exactly does this mean? I mean... I don't know anyone > that knows forth... lots of people know sh. And a logical special > language (whic resembles sh and the other script languages) is not > real hard to learn either. Why mess it up and get forth in there? And > to do what exactly? Forth is a candidate because it can be implemented in a very compact fashion, and bytecoded Forth is also very compact. In situations where space is an issue, this gives it an enormous advantage. eg. the current trivial interpreter is about 10k (minus command implementations); this is about the same size as the complete Forth interpreter we're looking at. Using Forth gives us two major advantages: - Because we can construct bindings between primitives economically, additional functionality can be added with a correspondingly smaller accumulation of bloat. - The behaviour of the bootloader can be extended without having to rebuild it. It becomes possible to attach extra intelligence to the boot process allowing customisation eg. on a per-product or per-module basis. This is all very experimental, and I take your point about the learning curve very seriously. If you can propose an extensible language with a "traditional" syntax which can compete on a size basis (code, runtime usage and bytecode size) then I would be happy to consider it. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message