forth interpreter as kernel module

forth interpreter as kernel module

[David N. Welton]

[ please CC replies to me ]

Hello,

Once upon a time, I had a rather random idea, and, acting on it, I
wedged a forth interpreter into the Linux kernel.  I've always wanted
to clean it up and do things nicely, but have never really found the
time or the motivation.

So, I am posting here, in the hope that someone might find the idea
interesting and take it up, or, better yet, think of something that it
might actually be used for (this was besides the point when I did it).

I doubt the code itself is of much interest.  Actually, I'm pretty
embarassed about it, but decided to make it available despite that.

It does run, on my system (2.4.18):

@grantspass [/home/davidw/workshop/pforth-21] # insmod kpforth.o 
Warning: loading kpforth.o will taint the kernel: no license

@grantspass [/proc] # echo 3 . > kpforth
@grantspass [/proc] # cat kpforth-out 
pfLoadDictionary - Filename ignored! Loading from static data.
Static data copied to newly allocated dictionaries.
Begin AUTO.INIT ------
3    ok
Stack<10> 

Although from what I recall when experimenting with it, there are some
definite 'issues'.  See aforementioned disclaimer about the code.  It
doesn't interface with the kernel in any interesting ways, either.

Anyway, for the interested/bored/adventerous, the code may be found
at:

http://www.dedasys.com/freesoftware/files/kpforth-21.tgz

The original forth system that I based it on - pforth - which is much
better code then mine, is by Phil Burk.

I would be interested in comments on what should be fixed in the code,
although I may not have time to act on them.

Anyway, hope this is of interest to someone, and thank you for your
time,
-- 
David N. Welton
   Consulting: http://www.dedasys.com/
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/

Re: forth interpreter as kernel module

[M. Edward (Ed) Borasky]

On 5 Apr 2002, David N. Welton wrote:

>
> [ please CC replies to me ]
>
> Once upon a time, I had a rather random idea, and, acting on it, I
> wedged a forth interpreter into the Linux kernel.  I've always wanted
> to clean it up and do things nicely, but have never really found the
> time or the motivation.

We had another similar post a few weeks ago. *Two* Linux kernel Forth
interpreters in one year -- what are the odds? :)

Seriously, though, a Forth that could be accessed inside the kernel has
profound (in)security implications. I'm not sure I like the thought of
something as powerful as Forth available with kernel privileges. It
would make an interesting debugging / diagnostic tool if "kgdb", etc.
didn't exist, but given that there *are* some debug tools already, I'm
not sure what I'd do with it.

Now a *user-space* full-featured Forth -- something like Tom Zimmer's
Windows32 Forth or Forth, Inc.'s SwiftForth -- with GUIs and all the
other goodies -- now *that* I'd love to have. But a tiny Forth in the
kernel? Nope.
-- 
M. Edward Borasky
znmeb@borasky-research.net

The COUGAR Project
http://www.borasky-research.com/Cougar.htm

Q. How do you tell when a pineapple is ready to eat?
A. It picks up its knife and fork.

Re: forth interpreter as kernel module

[Alan Cox]

> I would be interested in comments on what should be fixed in the code,
> although I may not have time to act on them.

Strange. The one area forth does have sort of relevance may be outside the
x86 world. The portable boot rom standards (the one everyone ignored for
x86) is all about forth stuff. I don't know if anyone has use for a forth
engine that can speak that ?

Re: forth interpreter as kernel module

[Eric W. Biederman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > I would be interested in comments on what should be fixed in the code,
> > although I may not have time to act on them.
> 
> Strange. The one area forth does have sort of relevance may be outside the
> x86 world. The portable boot rom standards (the one everyone ignored for
> x86) is all about forth stuff. I don't know if anyone has use for a forth
> engine that can speak that ?

The openbios guys are working on it.  I haven't played with it but they
seem to be makeing some progress.

Eric

Re: forth interpreter as kernel module

[benh]

>> I would be interested in comments on what should be fixed in the code,
>> although I may not have time to act on them.
>
>Strange. The one area forth does have sort of relevance may be outside the
>x86 world. The portable boot rom standards (the one everyone ignored for
>x86) is all about forth stuff. I don't know if anyone has use for a forth
>engine that can speak that ?

Yes, an OpenFirmware emulator would be interesting. It would allow to
softboot OF PCI cards on non-OF machines, and would allow to implement
properly resume from sleep on some desktop G4s that will power off the
PCI bus during sleep (some cards need to be re-softbooted, like video 
ones, and in some case, you really want the vendor firmware to run).

Ben.

Forth interpreter as kernel module

[Rick A. Hohensee]

Two Forths in Linuxspace now? That's 3 stack machines. Heheheheh,




        MAKE YOUR TIME. ALL YOUR BASE ARE BELONG TO KSPAMD.





Does the pforth version run as a kernel daemon like H3rL does?

Phil Burk is I believe still affiliated with Mills College. He'd love to
hear about this. Mike Haas too, probably. Mike Haas wrote the kernel of
Amiga JForth and Phil wrote all the music stuff. I added all the Linux
syscalls to the PForth in cLIeNUX mostly out of nostalgia for JForth, a
"...once in a paradigm thing." Jack "jax" Woehr (sp?). Phil was quite
pleased to hear there's a PForth out there with 160 Linux syscalls as
primitives.

That PForth is in ftp://linux01.gwdg.de/pub/cLIeNUX/interim along with
H3rL, Hohensee's 3-ring Linux, which is a Linux kernel with a 3-stack
machine in 0wnerland. Read ./ABOUT .

Alan,
 an Open Firmware IN kernelspace has the potential to have the
functionality of Open Firmware, AND serve as something like an Open Driver
Initiative, with a performance hit perhaps, depending on how the Forth is
implemented. There are native compiling Forths, but they're not nice tiny
little things.

Ed,
 As far as security is concerned, a Forth on say vt1 (it's on vt1 here,
er, it's H3sm, a 3-stack machine, but anyway...) is no worse really than
root. As far as how a Forth compares to a kdb, it doesn't. Forth is a
debugger, a compiler, an interpreter, AND a desert topping. A forth won't
have the niceties of an evolved unix tool, but you can write them
interactively. And write things you can't imagine until the problem pops
up, like that thing Torvalds did recently for sniffing at some
Torvaldsianly obscure cache tree buffer tree page cache buffer thing. You
can write stuff like that with the same interactivity you associate with
shell scripting.

More to the point, Forth can be a great personalizer of unix/Linux. Sure,
you don't want a Forth in your DNS box. (I do, but...) You do want a Forth
in your multimedia box. Bigtime. Which is why the "forth" command in
cLIeNUX is upforth, PForth with a unix Jones.

If Forth in Linux is going to go somewhere, Mitch Bradley might want to
comment. He's the author of OpenBoot, and I find that some of my best
Forth-on-unix ideas, he had 15 years ago. He left Sun and does Bradley
Forthworks or Forthware, last I heard. Post to comp.lang.forth too.

Rick Hohensee

Birth Of Kspamd reenactment...
imagine each space as *exactly* one second elapsed between string
outputs...

SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM SPAM
SPAM SPAM SPAM SPAM SPAM SPAM SPAM<cursor>

RE: Forth interpreter as kernel module

[M. Edward Borasky]

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Rick A. Hohensee
> Sent: Friday, April 05, 2002 5:22 PM
> To: linux-kernel@vger.kernel.org
> Subject: Forth interpreter as kernel module

> Phil Burk is I believe still affiliated with Mills College. He'd love to
> hear about this. Mike Haas too, probably. Mike Haas wrote the kernel of
> Amiga JForth and Phil wrote all the music stuff. I added all the Linux
> syscalls to the PForth in cLIeNUX mostly out of nostalgia for JForth, a
> "...once in a paradigm thing." Jack "jax" Woehr (sp?). Phil was quite
> pleased to hear there's a PForth out there with 160 Linux syscalls as
> primitives.

Yes, Phil Burk is still doing music ... no, he's not doing it in Forth, but
in Java. Hunt up "jmsl" and "jsyn" for the details. I haven't heard much
from Jack recently; I have his book which had an ANS-ish 16-bit DOS Forth on
a floppy. At one time, I was doing some absolutely *amazing* things with
16-bit Forths on my HP100LX Palmtop PC. Still, I must confess I haven't been
to the Taygeta Scientific Forth archive in over a year.

> More to the point, Forth can be a great personalizer of unix/Linux. Sure,
> you don't want a Forth in your DNS box. (I do, but...) You do want a Forth
> in your multimedia box. Bigtime. Which is why the "forth" command in
> cLIeNUX is upforth, PForth with a unix Jones.

Well, I want a full-strength Forth in my Linux box -- I've got SwiftForth
Pro on my Windows system and I'm holding out for something of that
comprehensive nature on Linux. I have to admit I haven't played with the
gForth that I think comes with my Red Hat distro, so I don't know what it's
like. I've heard hard-core Forthers gag profusely at the mere mention of
gForth.

So, enough "old Forthers home week" on the Linux kernel mailing list, eh?

: TOOT FORTH LOVE IF HONK THEN ;
--
M. Edward (Ed) Borasky, Chief Scientist, Borasky Research
http://www.borasky-research.net  http://www.aracnet.com/~znmeb
mailto:znmeb@borasky-research.net  mailto:znmeb@aracnet.com

Q. Who invented the non-Von Neumann computer architecture?
A. John non-Von Neumann.

forth interpreter as kernel module

[Rick A. Hohensee]

Interesting. That 1998 file for making a /proc scripting thing,
what else has it been used for? 

Sometime around June 2001 I released a 3-stack Forthlike language 
embedded in a Linux kernel. The implementation is quite different 
than yours. In H3rL, Hohensee's 3-ring Linux, H3sm, Hohensee's 3-stack
machine, runs as a kernel daemon with regular user interaction via
a vt. I use vt1 on this box. 

I would also call your attention to upforth. H3rL, H3sm and upforth
are in ftp://linux01.gwdg.de/pub/cLIeNUX/interim

Rick Hohensee

Re: forth interpreter as kernel module

[Segher Boessenkool]

benh@kernel.crashing.org wrote:

> Yes, an OpenFirmware emulator would be interesting. It would allow to
> softboot OF PCI cards on non-OF machines, and would allow to implement
> properly resume from sleep on some desktop G4s that will power off the
> PCI bus during sleep (some cards need to be re-softbooted, like video
> ones, and in some case, you really want the vendor firmware to run).

I'm writing a full OF implementation for OpenBios.  It will also be
able to run in user space, which might be a better solution for things
like softboot (and besides, it makes development a lot easier).

It is supposed to be fully portable across all architectures that
run Linux.

Check out module Paflof from OpenBios CVS.

http://www.freiburg.linux.de/OpenBIOS/

Nothing very mature yet, so don't get too excited now.


Cheers,

Segher

Forth interpreter as kernel module

[Rick A. Hohensee]

>Segher Boessenkool
 >  I'm writing a full OF implementation for OpenBios. It will also be
  > able to run in user space, which might be a better solution for things
   >like softboot (and besides, it makes development a lot easier).

For in-kernel User Mode Linux might help. Jeff Dike suggested that to me
at H3rL announce time. Valid suggestion, just not the tendency of a guy
that writes an in-kernel 3-stack Forth in pure assembly and doesn't put
Perl in his distro.

Rick Hohensee