[ 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/
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
[email protected]
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.
> 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 ?
Alan Cox <[email protected]> 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
>> 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.
[email protected] 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