I have just discovered lisp and find it fasinating. I work as an embedded
software engineer would like see how I could apply lisp to my work.
I was wondering how a lisp program could be executed on an embedded
processor without an OS. Would a lisp interpreter have to be executing on the
processor? or can the lisp program be compiled to run natively? If a lisp
program can be compiled as such, what kind of environment would be required to
run the lisp program?
I'm not concerned about the efficiency nor size of the binary, only the
feasibility and work required to accomplish this task.
Thanks in advance for any constructive input,
Dan
In article <····························@posting.google.com>,
···@dan-and-kim.com (Q-less) wrote:
> I have just discovered lisp and find it fasinating. I work as an embedded
> software engineer would like see how I could apply lisp to my work.
> I was wondering how a lisp program could be executed on an embedded
> processor without an OS. Would a lisp interpreter have to be executing on the
> processor? or can the lisp program be compiled to run natively?
Lisp can definitely be compiled to run natively. If there isn't a back
end available for your target machine, you can use one of the lisps that
compiles to C or one that compiles to byte codes and requires a small
interpreter to implement the byte-code VM. Some performance penalty,
which may or may not be important for your application, but less
cross-compilation hassle.
> If a lisp
> program can be compiled as such, what kind of environment would be required to
> run the lisp program?
That will depend on exactly which lisp or subset thereof you intend to
run. Common Lisp assumes the existence of things like file systems,
which could be a problem for an embedded processor with no OS, but that
kind of thing is a problem in almost any language. You should be able to
take advantage of the things lisp is good for (both for development and
in running code) while still generating perfectly reasonable executables
for your target.
> I'm not concerned about the efficiency nor size of the binary, only the
> feasibility and work required to accomplish this task.
> Thanks in advance for any constructive input,
>
> Dan
Q-less wrote:
> I have just discovered lisp and find it fasinating. I work as an embedded
> software engineer would like see how I could apply lisp to my work.
...
> Thanks in advance for any constructive input,
Well, given this wildcard, here at least is a pointer to a bunch of Lisp
implementations which might be of interest:
http://www.cliki.net/Common%20Lisp%20implementation
Not sure about the OS-free angle, tho.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Oops! ···@dan-and-kim.com (Q-less) was seen spray-painting on a wall:
> I have just discovered lisp and find it fasinating. I work as an
> embedded software engineer would like see how I could apply lisp to
> my work. I was wondering how a lisp program could be executed on an
> embedded processor without an OS. Would a lisp interpreter have to
> be executing on the processor? or can the lisp program be compiled
> to run natively? If a lisp program can be compiled as such, what
> kind of environment would be required to run the lisp program? I'm
> not concerned about the efficiency nor size of the binary, only the
> feasibility and work required to accomplish this task.
>
> Thanks in advance for any constructive input,
At the bottom level, you need to have code to manage access to five
main things:
1. Memory
2. Secondary storage (disk and such)
3. CPU (tasking, threading, and such)
4. Graphics hardware
5. Networking
In effect, you need something of a "layer below Lisp," implementing
all of these, to the degree required, to support the hardware you want
to run on.
Each of these pieces is pretty sizable, in terms of effort. Forget
size and efficiency; it is quite likely that a good implementation
could be quite efficient in all these areas.
The /problem/ is that it's a lot of effort. And unless you do it
/really/ carefully, you'll get drawn into supporting a limited set of
hardware that won't be available two years down the road, thus making
your system a mere curiosity.
Consider: Can you guarantee that the graphics card you write code for
will still be available on store shelves in 18 months?
The net result is that it seems more convenient to program a Lisp to
run atop (Linux|(Free|Net|Open)BSD) + XFree86, thereby taking
advantage of the fairly lavish efforts going into
Network/CPU/Graphics/Disk hardware drivers. They may not be as
elegant, but, as a Lisp implementor, you can use them so you can
concentrate on Lisp, as opposed to spending your time working with
some sort of "assembler in Lisp" to get limited support for some tiny
set of hardware.
I'm assuming here that you do something resembling the following:
-> You build some quasi-portable Lisp bootstrap perhaps runnable
on a CL system on Unix;
-> That bootstrap implements a set of macros/functions that
are a sort of "Lisp Macro Assembler," to assortedly
implement hardware drivers, memory management, and
some set of Lisp primitives;
-> Then you build, atop that, higher level functions to compile
code...
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://www.ntlug.org/~cbbrowne/lisposes.html
"What this list needs is a good five-dollar plasma weapon."
--paraphrased from `/usr/bin/fortune`
Christopher Browne <········@acm.org> wrote:
+---------------
| Oops! ···@dan-and-kim.com (Q-less) was seen spray-painting on a wall:
| > I was wondering how a lisp program could be executed on an
| > embedded processor without an OS. ...
|
| At the bottom level, you need to have code to manage access to five
| main things:
|
| 1. Memory
| 2. Secondary storage (disk and such)
| 3. CPU (tasking, threading, and such)
| 4. Graphics hardware
| 5. Networking
|
| In effect, you need something of a "layer below Lisp," implementing
| all of these, to the degree required, to support the hardware you want
| to run on.
|
| Each of these pieces is pretty sizable, in terms of effort. Forget
| size and efficiency; it is quite likely that a good implementation
| could be quite efficient in all these areas.
|
| The /problem/ is that it's a lot of effort. And unless you do it
| /really/ carefully, you'll get drawn into supporting a limited set of
| hardware that won't be available two years down the road, thus making
| your system a mere curiosity.
+---------------
Fortunately, all that work has been done for people, at least for
the x86 CPU architecture:
<URL:http://www.cs.utah.edu/flux/oskit/>
The OSKit is a framework and a set of 34 component libraries
oriented to operating systems, together with extensive documentation.
By providing in a modular way not only most of the infrastructure
"grunge" needed by an OS, but also many higher-level components,
the OSKit's goal is to lower the barrier to entry to OS R&D and
to lower its costs. The OSKit makes it vastly easier to create a
new OS, port an existing OS to the x86 (or in the future, to other
architectures supported by the OSkit), or enhance an OS to support
a wider range of devices, file system formats, executable formats,
or network services. The OSKit also works well for constructing
OS-related programs, such as boot loaders or OS-level servers atop
a microkernel.
For language researchers and enthusiasts, the OSKit lets them
concentrate on the real issues raised by using advanced languages
inside operating systems, such as Java, Lisp, Scheme, or ML---
instead of spending six months or years groveling inside ugly code
and hardware. With the recent addition of extensive multithreading
and sophisticated scheduling support, the OSKit also provides a
modular platform for embedded applications, as well as a novel
component-based approach to constructing entire operating systems.
The PLT Scheme guys used this to get MzScheme to run on "bare" iron:
<URL:http://www.plt-scheme.org/software/mzscheme/>
MzScheme is available in kernel form for x86 machines,
which allows MzScheme to boot without the aid of a separate
operating system. The MzScheme kernel is based on the OSKit...
Their reorg'd web site makes it a little hard to find, but this link
should still work:
<URL:http://www.cs.rice.edu/CS/PLT/packages/download/
103p1/mzscheme/mzscheme.i386-kernel.tar.gz>
I would suggest looking to see what they did and how you might make use
of their experience to do the same for Common Lisp.
+---------------
| The net result is that it seems more convenient to program a Lisp to
| run atop (Linux|(Free|Net|Open)BSD) + XFree86, thereby taking
| advantage of the fairly lavish efforts going into
| Network/CPU/Graphics/Disk hardware drivers.
+---------------
Or for bare-bones embedded stuff (on x86), OSKit.
If you need more than OSKit provides, then, yes, of course consider
one of Linux or {Free,Net,Open}BSD. While I personally prefer FreeBSD,
NetBSD in particular supports "weird" (non-x86 clone) hardware well.
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
* Christopher Browne wrote:
> At the bottom level, you need to have code to manage access to five
> main things:
> 1. Memory
> 2. Secondary storage (disk and such)
> 3. CPU (tasking, threading, and such)
> 4. Graphics hardware
> 5. Networking
Well, the original poster described themselves as an `embedded
software engineer' so, it's likely that they actually have to manage
some subset of these, probably 1,3 and maybe 5. I don't think this is
a `I need an OS written in Lisp' question it's a `how can I run Lisp
in my toaster' question.
--tim
···@dan-and-kim.com (Q-less) writes:
> I have just discovered lisp and find it fasinating. I work as an embedded
> software engineer would like see how I could apply lisp to my work.
> I was wondering how a lisp program could be executed on an embedded
> processor without an OS. Would a lisp interpreter have to be executing on the
> processor? or can the lisp program be compiled to run natively? If a lisp
> program can be compiled as such, what kind of environment would be required to
> run the lisp program?
> I'm not concerned about the efficiency nor size of the binary, only the
> feasibility and work required to accomplish this task.
>
> Thanks in advance for any constructive input,
While its not a Common Lisp, Xlisp is readily portable to most any
architecture. As I recall its straightforward C with #ifdefs to
manage different operating systems. I got it to run pretty easily
with RTEMS on a 12mhz MIPS board. Its almost OS-less as it runs as 1
task and doesn't use any OS features beyond a conventional C library.
It ships with some graphics extensions- and xlispstat ships with
additional stuff too, but you can #ifdef it out to start with.
ECLS is much more CL compliant than Xlisp, and I think much more
useful. I've not yet coaxed the numeric library to support our
ancient MIPS, though ECLS itself is pretty easy to cross compile. I
think I also don't understand the subtlties of GNU math lib enough, so
it may be that I'm making it more difficult than it is. ECLS is
rigged to target the local OS so you'll need to apply
automake/autoconf judo. Even so, all it needs is reasonably complete
C environent to run.
As others have pointed out CLISP is also good, but it will likely
prove troublesome to embed as it wants to be an executable and not a
bunch of stuff that gets linked into something else. I've worked on a
job moving ntpd into a library for an embedded system, so it can be
done.
In all 3 cases, having a file system available on the target (volatile
or not) will be helpful.
The above will all be Lisp interpreters on your target. Making Lisp
compilers is a subtle art, so that be a better phase 2 project... ;)
Gregm
"Q-less" <···@dan-and-kim.com> wrote
> I have just discovered lisp and find it fasinating. I work as an
embedded
> software engineer would like see how I could apply lisp to my work.
> I was wondering how a lisp program could be executed on an
embedded
> processor without an OS. Would a lisp interpreter have to be executing on
the
> processor? or can the lisp program be compiled to run natively? If a
lisp
> program can be compiled as such, what kind of environment would be
required to
> run the lisp program?
> I'm not concerned about the efficiency nor size of the binary, only
the
> feasibility and work required to accomplish this task.
What kind of embedded system do you want to use?
There is a huge difference between a small microcontroller like a MSP430 [1]
and a Virtex II Pro FPGA [2]
Except on the very small microcontrollers, Lisp should be usable. Not the
full Common Lisp of course, but a very usable subset.
I learned Lisp with LeLisp on a 48Kbytes TRS80 (0.877MHz 8 bit processor).
So I don't see any reason for not having a more modern Lisp on a more modern
microprocessor. (Z80 are now at 50MHz/16Mb RAM and with an IP stack).
Now every phone terminal has some kind of JVM inside so why not a LVM
instead ?
You should probably look at CLISP for a start.
If I had some time I would probably try to do this on a MicroBlaze processor
in an FPGA for robotics applications.
Marc
[1] I've just finished a design with one of these. It works 10 years on one
watch battery but has only 256 bytes of RAM and 8Kbytes of program.
[2] A single chip with millions of programmable gates, 4 PowerPC processors
and 24 x 3.125 Gb/s links
On Thu, 27 Feb 2003 09:14:50 +0100, "Marc Battyani"
<·············@fractalconcept.com> wrote:
> Except on the very small microcontrollers, Lisp should be usable. Not the
> full Common Lisp of course, but a very usable subset.
Maybe ThinLisp:
http://www.thinlisp.org/
Paolo
--
Paolo Amoroso <·······@mclink.it>
> Maybe ThinLisp:
>
> http://www.thinlisp.org/
>
Is this for real? It seems somewhat interesting, but most of the
links on the website are useless:
Examples link leads to "There ought to be some examples, but at this
point, there aren't any. This web site generator could be one but it
isn't since GL(CMULisp) chokes on it attempt to open files in lisp."
Mailing lists link leads to "Describe mailing lists here."
The download link appears to point to a tgz file, but the link itself
is broken.
I'm not sure why this would be recommended to anyone.
rif
rif <···@mit.edu> writes:
> > http://www.thinlisp.org/
> Is this for real? It seems somewhat interesting, but most of the
> links on the website are useless:
Look at SourceForge. Not much happening, but some files are there.
Not very much documentation, except for implementation strategies,
but it seems to be working. (I had to patch tlt/lisp/boot.lisp and
tlt/lisp/system.lisp to get it to work with the current CMU CL in
Debian/unstable, changing five instances of "lucid" to "(or lucid
cmu)" in compile-load-tlt-module and system-lisp-relative-binary-
file.)
Regards,
'mr
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
On 27 Feb 2003 10:32:56 -0500, rif <···@mit.edu> wrote:
> > http://www.thinlisp.org/
> >
>
> Is this for real? It seems somewhat interesting, but most of the
> links on the website are useless:
Try:
http://sourceforge.net/projects/thinlisp
Paolo
--
Paolo Amoroso <·······@mclink.it>
In article <····························@posting.google.com>,
···@dan-and-kim.com (Q-less) wrote:
> I was wondering how a lisp program could be executed on an embedded
>processor without an OS. Would a lisp interpreter have to be executing on the
>processor? or can the lisp program be compiled to run natively? If a lisp
>program can be compiled as such, what kind of environment would be required to
>run the lisp program?
Here's a Lisp/Scheme that runs on the Palm:
http://www.lispme.de/lispme/
Also, Rodney Brooks' bug-like robots run Lisp in their guts. Google
is your friend here. For example:
http://citeseer.nj.nec.com/32508.html
There are also periodic requests for a Lisp-based OS and ensuing
discussions, e.g.:
http://lists.tunes.org/archives/lispvm/1997-May/000091.html
Good luck!
···@dan-and-kim.com (Q-less) writes:
> I have just discovered lisp and find it fasinating. I work as an embedded
> software engineer would like see how I could apply lisp to my work.
> I was wondering how a lisp program could be executed on an embedded
> processor without an OS. Would a lisp interpreter have to be executing on the
> processor?
That's one approach.
> or can the lisp program be compiled to run natively?
That's another approach.
> If a lisp program can be compiled as such, what kind of environment
> would be required to run the lisp program?
A `runtime environment' that provided memory management, I/O, and the
necessary primitive forms.
Q-less wrote:
>I have just discovered lisp and find it fasinating. I work as an embedded
>software engineer would like see how I could apply lisp to my work.
>
I build embedded systems too. IMHO, Lisp's big advantages in embedded
systems would be automatic memory management and a built in monitor for
debugging. It would be great to change/fix parts of the sytem on the fly
and really speed up development.
> I was wondering how a lisp program could be executed on an embedded
>processor without an OS. Would a lisp interpreter have to be executing on the
>processor? or can the lisp program be compiled to run natively? If a lisp
>program can be compiled as such, what kind of environment would be required to
>run the lisp program?
>
Routines to allocate and free memory, then routines for transput which
ofcourse depend on the application.
Lisp reflects it's innards to the programmer so some functions would
require an on-target interpreter or compiler.
> I'm not concerned about the efficiency nor size of the binary, only the
>feasibility and work required to accomplish this task.
>
Then why rule out Lisp ontop of an OS? If you already have a kernel then
you could easily take a small lisp interpreter and graft it in.