I just finished reading Anti Patterns Refactoring Software
Architectures,and it hint me that i'm regularly singing gospels to
lisp being a universal hummer for every kind of problem. Once in a
while somebody ask's what is lisp bad for? I basically have only two
ideas:
1.Talking with c++ (Possible but not recommended, due to c++
idiosyncrasy )
2. Erlang/Termite like processes (i wonder how many processes could
scieener support?)
What are the other domains where lisp doesn't fit in?
bobi
fireblade wrote:
> What are ... domains where lisp doesn't fit in?
Drivers: close to the metal.
Embedding: Poor memory resources.
--
Dan
www.prairienet.org/~dsb/
Dan Bensen <··········@cyberspace.net> writes:
> fireblade wrote:
>> What are ... domains where lisp doesn't fit in?
>
> Drivers: close to the metal.
If lisp worked perfectly well as system programming language on the
lisp machines, what does that say on the ability of lisp for writting
drivers?
Common Lisp doesn't prevent an implementation to have implementation
specific extensions to be able to run on the bare metal, even on an
Intel processor. See Movitz.
> Embedding: Poor memory resources.
If lisp worked on systems of 50 years ago, what does that say on the
memory resources needed by lisp?
The Common Lisp specification is lax enough to allow a very small
implementation, not counting even the subsets of Common Lisp that are
explicitely allowed. Have a look at the various LIMIT variables!
Limit Minimal value
--------------------------- -------------
ARRAY-DIMENSION-LIMIT 1024
ARRAY-RANK-LIMIT 8
ARRAY-TOTAL-SIZE-LIMIT 1024
CALL-ARGUMENTS-LIMIT 50
CHAR-CODE-LIMIT 96
LAMBDA-PARAMETERS-LIMIT 50
MULTIPLE-VALUES-LIMIT 20
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
On Sat, 28 Apr 2007 02:16:32 +0200, Pascal Bourguignon
<···@informatimago.com> wrote:
>Dan Bensen <··········@cyberspace.net> writes:
>
>> fireblade wrote:
>>> What are ... domains where lisp doesn't fit in?
>>
>> Drivers: close to the metal.
>
>If lisp worked perfectly well as system programming language on the
>lisp machines, what does that say on the ability of lisp for writting
>drivers?
It says that the Lisp machines had special hardware and kernel support
to make it work.
>Common Lisp doesn't prevent an implementation to have implementation
>specific extensions to be able to run on the bare metal, even on an
>Intel processor. See Movitz.
True. But the need for extensions shows that standard CL cannot
support the application domain.
Movitz is a truly wonderful piece of software, but it is not quite the
showpiece for bare metal Lisp programming that you think it is. The
kernel runtime functions are not written in Lisp and their use
requires special knowledge in the compiler (which is, of course, not
dissimilar from any other implementation ... but that makes my point
for me). Additionally many of the drivers included with Muerte appear
to have been adapted from open source Linux versions rather than
written new to take advantage of Lisp.
Although new drivers written in Lisp can use the existing runtime
services, new runtime services cannot necessarily be written in Lisp.
Nor does the system as yet provide GC, it currently has only a very
rudimentary, allocate only, "mark no release" memory scheme for use in
kernel programming.
The Lisp machines, and to a lesser extent Movitz, show that CL can be
mated to and used successfully on a bare metal runtime package ... but
that has never been in dispute. In my book that's not the same as
saying CL can be used to program bare metal.
>> Embedding: Poor memory resources.
>
>If lisp worked on systems of 50 years ago, what does that say on the
>memory resources needed by lisp?
As you noted, this is mostly a straw man although I personally have
yet to see a Lisp that can operate in 4K. And the teeny
implementations I have seen were severely limited in functionality.
George
--
for email reply remove "/" from address
On Sat, 28 Apr 2007 01:11:12 -0400, <·········@comcast.net> wrote:
> On Sat, 28 Apr 2007 02:16:32 +0200, Pascal Bourguignon
><···@informatimago.com> wrote:
>
>>Dan Bensen <··········@cyberspace.net> writes:
>>
>>> fireblade wrote:
>>>> What are ... domains where lisp doesn't fit in?
>>>
>>> Drivers: close to the metal.
>>
>>If lisp worked perfectly well as system programming language on the
>>lisp machines, what does that say on the ability of lisp for writting
>>drivers?
>
> It says that the Lisp machines had special hardware and kernel support
> to make it work.
*shrug*
unless you are going to claim that Intel has not tailored it's current
generation processors to mate to their assembly language.
--
There are no average Common Lisp programmers
Reply-To: email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
George Neuner <·········@comcast.net> writes:
> On Sat, 28 Apr 2007 02:16:32 +0200, Pascal Bourguignon
> <···@informatimago.com> wrote:
>
>>Dan Bensen <··········@cyberspace.net> writes:
>>
>>> fireblade wrote:
>>>> What are ... domains where lisp doesn't fit in?
>>>
>>> Drivers: close to the metal.
>>
>>If lisp worked perfectly well as system programming language on the
>>lisp machines, what does that say on the ability of lisp for writting
>>drivers?
>
> It says that the Lisp machines had special hardware and kernel support
> to make it work.
>
>
>>Common Lisp doesn't prevent an implementation to have implementation
>>specific extensions to be able to run on the bare metal, even on an
>>Intel processor. See Movitz.
>
> True. But the need for extensions shows that standard CL cannot
> support the application domain.
>
> Movitz is a truly wonderful piece of software, but it is not quite the
> showpiece for bare metal Lisp programming that you think it is. The
> kernel runtime functions are not written in Lisp and their use
> requires special knowledge in the compiler (which is, of course, not
> dissimilar from any other implementation ... but that makes my point
> for me). Additionally many of the drivers included with Muerte appear
> to have been adapted from open source Linux versions rather than
> written new to take advantage of Lisp.
>
> Although new drivers written in Lisp can use the existing runtime
> services, new runtime services cannot necessarily be written in Lisp.
> Nor does the system as yet provide GC, it currently has only a very
> rudimentary, allocate only, "mark no release" memory scheme for use in
> kernel programming.
>
> The Lisp machines, and to a lesser extent Movitz, show that CL can be
> mated to and used successfully on a bare metal runtime package ... but
> that has never been in dispute. In my book that's not the same as
> saying CL can be used to program bare metal.
fireblade asked about lisp; you're answering about Common Lisp.
Common Lisp is a language, and it's powerful enough to describe
abstractly any kind of hardware and write an OS for it.
If you don't have any implementation specific extensions or even only
provision to run on that actual hardware, of course your CL OS speach
will stay abstract (you'll only be running an emulator). But nothing
prevents you to implement all that in CL.
Note that with C you have the same problem: the C language is defined
abstractly, and cannot be used to implement an OS. The Linux kernel
for example is implemented with a specific implementation and its
extensions, not in ANSI C.
The implementation specific runtime services you need to implement the
low-level OS stuff, you can of course implement them purely in Common
Lisp, writting in Common Lisp a compiler that generate the baremetal
binary needed.
>>> Embedding: Poor memory resources.
>>
>>If lisp worked on systems of 50 years ago, what does that say on the
>>memory resources needed by lisp?
>
> As you noted, this is mostly a straw man although I personally have
> yet to see a Lisp that can operate in 4K. And the teeny
> implementations I have seen were severely limited in functionality.
What do you need to call a program a _lisp_ implementation?
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
On Sat, 28 Apr 2007 12:57:09 +0200, Pascal Bourguignon
<···@informatimago.com> wrote:
>George Neuner <·········@comcast.net> writes:
>
>> The Lisp machines, and to a lesser extent Movitz, show that CL can be
>> mated to and used successfully on a bare metal runtime package ... but
>> that has never been in dispute. In my book that's not the same as
>> saying CL can be used to program bare metal.
>
>fireblade asked about lisp; you're answering about Common Lisp.
All right fine!
>Common Lisp is a language, and it's powerful enough to describe
>abstractly any kind of hardware and write an OS for it.
But it *isn't* powerful enough to directly program that hardware -
only to program an abstraction of the hardware. It has no support for
raw access to the hardware and no direct support for placing code or
data.
>Note that with C you have the same problem: the C language is defined
>abstractly, and cannot be used to implement an OS.
I didn't say anything about C, but if you want to drag it in - the
abstract machine which defines C is far closer to real hardware than
the abstract machine which defines Lisp ... any Lisp.
With two minor caveats that I will get to in a moment your statement
is not true. There is almost no OS code that could not be realized in
C ... however inefficiently.
[Before you start arguing, I don't see embedded software development
anywhere in your resume. I have almost 2 decades of experience in
high performance, hard real-time and general embedded software
development. I have implemented operating systems and language
support runtimes on bare metal.]
Virtually any register or flag manipulation required can be achieved
through judicious use of setjmp and longjmp[*]. A C application on
metal requires only a tiny bootstrap routine to set up a stack and
heap. Together with setjmp/longjmp, the total of absolutely required
assembler support for a bare metal C application is a few dozen
instructions at most. Whatever other low level support may truly be
needed - for port I/O, interrupt handling, mode switching, etc. - can
be assembled into memory by C code and executed, if necessary, via
setjmp/longjmp.
The amount of non-Lisp code needed to bootstrap Lisp is more than an
order of magnitude greater than the amount of non-C code needed to
bootstrap C.
[*] provided all the registers are saved/restored and identified in
the structure. This is the normal case for C compilers that target
bare metal.
>The implementation specific runtime services you need to implement the
>low-level OS stuff, you can of course implement them purely in Common
>Lisp, writting in Common Lisp a compiler that generate the baremetal
>binary needed.
You're intentionally obfuscating. The question is not whether Lisp
can be used to somehow assemble a runtime package that supports a Lisp
environment - the question is whether the support code itself can be
written *AS* Lisp.
The answer to that is a resounding "no". The corresponding answer for
C is "not quite, but you can get very close".
George
--
for email reply remove "/" from address
George Neuner <·········@comcast.net> writes:
> On Sat, 28 Apr 2007 12:57:09 +0200, Pascal Bourguignon
> <···@informatimago.com> wrote:
>
>>George Neuner <·········@comcast.net> writes:
>>
>>> The Lisp machines, and to a lesser extent Movitz, show that CL can be
>>> mated to and used successfully on a bare metal runtime package ... but
>>> that has never been in dispute. In my book that's not the same as
>>> saying CL can be used to program bare metal.
>>
>>fireblade asked about lisp; you're answering about Common Lisp.
>
> All right fine!
>
>>Common Lisp is a language, and it's powerful enough to describe
>>abstractly any kind of hardware and write an OS for it.
>
> But it *isn't* powerful enough to directly program that hardware -
> only to program an abstraction of the hardware. It has no support for
> raw access to the hardware and no direct support for placing code or
> data.
Not Common Lisp the standard, right.
But that doesn't prevent me to do things like:
(com.informatimago.clisp.raw-memory:POKE-UINT8 #\x10001234
(mod (1+ (com.informatimago.clisp.raw-memory:PEEK-UINT8 #\x10001234)) 256))
or to use these peek and poke to communicate thru shared memory
between different processes. And right, I implemetned these funtions
as external C functions, but I could have used a LAP written in lisp
instead.
> [...]
>>The implementation specific runtime services you need to implement the
>>low-level OS stuff, you can of course implement them purely in Common
>>Lisp, writting in Common Lisp a compiler that generate the baremetal
>>binary needed.
>
> You're intentionally obfuscating. The question is not whether Lisp
> can be used to somehow assemble a runtime package that supports a Lisp
> environment - the question is whether the support code itself can be
> written *AS* Lisp.
>
> The answer to that is a resounding "no". The corresponding answer for
> C is "not quite, but you can get very close".
Well, I'm influenced by squeak who is written 100% in Smalltalk, even
its bootstrap (virtual machine) code. (Only the subset of Smalltalk
used to implement it is generated to a C source instead of generating
directly the binary, you know, C is but a portable assembler). So I'm
still not too convinced of the "resounding" no.
--
__Pascal Bourguignon__ http://www.informatimago.com/
ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.
Pascal Bourguignon <···@informatimago.com> wrote:
+---------------
| George Neuner <·········@comcast.net> writes:
| > But it *isn't* powerful enough to directly program that hardware -
| > only to program an abstraction of the hardware. It has no support
| > for raw access to the hardware and no direct support for placing
| > code or data.
|
| Not Common Lisp the standard, right.
| But that doesn't prevent me to do things like:
|
| (com.informatimago.clisp.raw-memory:POKE-UINT8 #\x10001234
| (mod (1+ (com.informatimago.clisp.raw-memory:PEEK-UINT8 #\x10001234)) 256))
|
| or to use these peek and poke to communicate thru shared memory
| between different processes. And right, I implemetned these funtions
| as external C functions, but I could have used a LAP written in lisp
| instead.
+---------------
One of the reasons I really like CMUCL is that these functions are
built-in [albeit as extensions to CL]. The SYSTEM:SAP-REF-{8,16,32}
functions do "peek", and they're SETF-able for "poke". I mostly use my
inlined wrapper functions R{8,16,32} & W{8,16,32} which automatically
convert an integer address argument to a SAP (with SYSTEM:INT-SAP) so I
can write (R8 FOO) instead of (SYSTEM:SAP-REF-8 (SYSTEM:INT-SAP FOO) 0).
;;; Used for things like polling for a "done" flag.
;;; BUG: Assumes contents of ADDR will change within fixnum polls.
(defun spin-until-change (addr)
(declare (optimize (speed 3) (debug 0) (safety 0)))
(loop with v0 of-type (unsigned-byte 32) = (r32 addr)
with counts fixnum = 0
while (= v0 (r32 addr))
do (setf counts (the fixnum (1+ counts)))
finally (return counts)))
And since CMUCL's "UNIX" package also provides built-in access to
OPEN/CLOSE/IOCTL/MMAP/etc., I find that for even the lowest-level
hardware bit-banging code I almost never need external C functions.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Apr 29, 3:57 am, George Neuner <·········@comcast.net> wrote:
> The question is not whether Lisp
> can be used to somehow assemble a runtime package that supports a Lisp
> environment - the question is whether the support code itself can be
> written *AS* Lisp.
>
> The answer to that is a resounding "no".
This is news to me. If you look at
http://jrm-code-project.googlecode.com/svn/trunk/kmachine/cold/
you'll see a lot of support code for running Lisp. It sure looks as
if it
is written in Lisp, too.
On Apr 30, 6:18 pm, Madhu <·······@meer.net> wrote:
> * Joe Marshall <·······················@y80g2000hsf.XXXXXX.com> :
> | On Apr 29, 3:57 am, George Neuner <·········@comcast.net> wrote:
> |> The question is not whether Lisp can be used to somehow assemble a
> |> runtime package that supports a Lisp environment - the question is
> |> whether the support code itself can be written *AS* Lisp.
> |> The answer to that is a resounding "no".
> | This is news to me. If you look at
>
> [snipped]
>
> This runs inside some sort of emulator? or does it [currently] run on
> a real machine?
It ran on a real machine back circa 1986. There are no extant
machines
anymore (as far as I know). I don't think there is an emulator that
will
handle it, either.
From: Pierre THIERRY
Subject: Re: What are the domains that lisp doesn't fit int?
Date:
Message-ID: <f187n4$nd9$1@biggoron.nerim.net>
Le Sun, 29 Apr 2007 06:57:04 -0400, George Neuner a écrit:
> It has no support for raw access to the hardware and no direct support
> for placing code or data.
Does any language of a higher level than assembler has support for that?
I suppose it would not be hard to provide an array of bytes that gives
access to the whole memory in Lisp. Thus you only really need to add a
setfable function that gives access to that array to add that support,
don't you?
> I didn't say anything about C, but if you want to drag it in - the
> abstract machine which defines C is far closer to real hardware than
> the abstract machine which defines Lisp ... any Lisp.
How is it closer?
> Virtually any register or flag manipulation required can be achieved
> through judicious use of setjmp and longjmp[*].
Do you have references describing that?
> The amount of non-Lisp code needed to bootstrap Lisp is more than an
> order of magnitude greater than the amount of non-C code needed to
> bootstrap C.
Is that a problem? Bootstrapping has not to be done often.
> You're intentionally obfuscating. The question is not whether Lisp
> can be used to somehow assemble a runtime package that supports a Lisp
> environment - the question is whether the support code itself can be
> written *AS* Lisp.
>
> The answer to that is a resounding "no".
I don't see why. What were the LispM OSes written in, BTW?
Curiously,
Pierre
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
On May 1, 1:25 pm, Pierre THIERRY <···········@levallois.eu.org>
wrote:
>
> What were the LispM OSes written in, BTW?
Funny you should ask...
The MIT CADR was written in Lisp Machine microcode. Brad Parker has
a bunch of documentation and an emulator at
http://www.unlambda.com/cadr/
The LMI Lambda was written in the same sort of microcode. You can
see the source code here:
http://jrm-code-project.googlecode.com/svn/trunk/lambda/ulambda/
For the lazy programmer, here is what it looks like (although I expect
it will be mangled by the various news manglers):
FIND-LENGTH-OF-CDR-CODED-LIST
;Calculates length of cdr coded list pointed to by vma. Untyped
;result goes into M-B. Smashes M-TEM, VMA and MD.
;Prepare for the loop.
((m-b) (a-constant 1))
((vma) sub vma (a-constant 1))
find-length-of-cdr-coded-list-loop
;Read the next cell. Use transport-no-evcp because this is
primarily used
;for copying lexical frames which are full of evcps. Using this
funny
;transport causes them not to be snapped.
((vma-start-read) add vma (a-constant 1))
(check-page-read)
(dispatch transport-no-evcp md)
;If cdr-nil, return.
;If cdr-next, loop.
;Otherwise, error.
((m-tem) q-cdr-code md)
(popj-equal m-tem (a-constant (eval cdr-nil)))
(jump-equal-xct-next m-tem (a-constant (eval cdr-next))
find-length-of-cdr-coded-list-loop)
((m-b) add m-b (a-constant 1))
(call illop) ;if cdr-error or cdr-normal
The LMI K-Machine was programmed mostly in Lisp. Here is some:
(defun read-gc-ram (quantum)
;; Bottom 4 bits are data, next 4 are garbage.
(address-gc-ram quantum)
(hw:read-gc-ram))
(defun write-gc-ram (quantum new-value)
;; Don't make this a subst, you will break LOAD-RAM.
(trap::without-traps
#'(lambda ()
(address-gc-ram quantum)
(hw:write-gc-ram new-value)
;; Let the mmfio bus clear out.
(hw:nop)
(hw:nop)
nil)))
And there were a few hand-coded assembler routines:
(defafun trap ()
;; The hardware depends on this loaded at location 0.
;; Save the oreg, source doesn't matter because pipeline is shut
off.
(alu setl gr::*save-oreg* r0 r0 bw-32 boxed-left)
;; Oreg clock comes on, we save the left alu input
(alu setl gr::*save-left* r0 r0 bw-32 boxed-left)
;; Left clock comes on, we save the right alu input
(alu setr gr::*save-right* r0 r0 bw-32 boxed-right)
;; Right clock comes on, we save the alu status
(alu pass-status gr::*save-status* r0 r0 bw-32 unboxed)
;; Alu clock comes on, we save the jump condition
;the + 32 in the following instruction causes the bit to be read
inverted!
(alu-field extract-bit-right gr::*save-jcond* r0 processor-status
(byte 1. (+ 32. 17.)) unboxed)
;; Jump condition clock comes on, find out which trap went off.
(alu-field field-and gr::*save-trap* gr::*trap-mask* trap-register
(byte 31. 0.) unboxed)
(alu prioritize-r gr::*trap-temp1* r0 gr::*save-trap* bw-32 unboxed)
(alu-field set-bit-right gr::*trap-temp1* r0 gr::*trap-temp1* (byte
1. 5.) unboxed)
;; Save pc
(alu merge-r gr::*save-trap-pc* gr::*trap-dtp-code-5* trap-pc bw-24
boxed)
;; Save pc + 1, dispatch to trap handler
(alu merge-r gr::*save-trap-pc+* gr::*trap-dtp-code-5* trap-pc+
bw-24 boxed next-pc-dispatch)
;; Spare locations.
(nop)
(nop))
You can find more at:
http://jrm-code-project.googlecode.com/svn/trunk/kmachine/
I believe the Symbolics 3600 was somewhat in the same vein as the
CADR and Lambda, but I don't know what the Ivory was like.
On Tue, 01 May 2007 20:25:08 +0000, Pierre THIERRY wrote:
>> I didn't say anything about C, but if you want to drag it in - the
>> abstract machine which defines C is far closer to real hardware than
>> the abstract machine which defines Lisp ... any Lisp.
>
> How is it closer?
Uses the same data types as those provided by the physical machine, and
these are typically not dynamic.
--
Andrew
From: Kent M Pitman
Subject: Re: What are the domains that lisp doesn't fit int?
Date:
Message-ID: <uy7k7mfae.fsf@nhplace.com>
Andrew Reilly <···············@areilly.bpc-users.org> writes:
> On Tue, 01 May 2007 20:25:08 +0000, Pierre THIERRY wrote:
>
> >> I didn't say anything about C, but if you want to drag it in - the
> >> abstract machine which defines C is far closer to real hardware than
> >> the abstract machine which defines Lisp ... any Lisp.
> >
> > How is it closer?
>
> Uses the same data types as those provided by the physical machine, and
> these are typically not dynamic.
This argument has a bit of the surreal feel that, for example, I might
expect to come from a hypothetical provocative statement like
"Catholicism is far closer to the notion of what constitutes a real
religion than the abstract religion that is Buddhism." That is, it seems
to contain a lot of blurriness, chauvinism, etc. that needs to be teased
out.
And not because I'm saying there's something inappropriate about liking
Catholicism or the C language. But rather because I'm saying if all you want
is to USE a language, or a religion, then it requires no discussion, and
certainly none with people who might disagree with you. But if you get to
the point where you want to advocate a position to others in the form of
world-wide open debate, it would seem fair (to me) to at least define a few
terms and set a context for the debate, so that people on the other side
(the abstract, unreal side, as it's been presented here) are not left
as automatic losers because the debate has been framed in a way that is
not far removed from the line "People who like this sort of thing will find
that this is the sort of thing that they like."
So, to start, there's a bit of circularity there, since I'm sure
people are at this point building machines to support C. Suppose they
didn't. Would that change your claim?
There have been abstract machines (and I don't just mean Lisp
Machines) that Lisp ahs been closer to in the past, and I don't doubt
could be in the future. There have been real machines that C was
farther from in the past, and that could happen again in a theoretical
sense... though, as I said, since the game is presently to make
hardware that supports C, that may seem strange.
I'll leave aside Lisp Machines, here, even though there were several
and they were very real in their time. Yes, they went away. But so did
Honeywell Multics (a PL/1 machine), and there's every reason to believe
that the loss was not due to "the hardware" but rather incidental price
issues, management of advertising and supply chains, cost management, and
other incidentals that aren't vey exciting to discuss technically. In
short, the market could have taken a turn for the worse, and if so, we
could eventually see a turn for the better. But for now, let's dispense
with Lisp Machines so we don't confuse those who think that this is what
I'm defending. For this post, I'll hypothetically cede that they are
dead and never coming back. It doesn't change my interest in this issue
of what constitutes good hardware.
A hardware machine to support Java or the Microsoft CLR, for example,
is not inconceivable. Should one arise, would "Lisp... any Lisp" be
closer to or father from such an abstract machine than Lisp?
What about a Connection Machine or some more modern neural net equivalent.
Will C or Lisp be closer to that?
I'm not trying to overly defend Lisp as the answer to everything. I'm
actually all for heterogeneous environments, and using an incidentally
appropriate language at an appropriate time. But...
- I think too often people use C/C++ by default, both in places
where it works but doesn't scale, and in places where it doesn't
really work but is "familiar".
- I think people are too little familiar with other hardware and other
dialects of Lisp to be able to say that Lisp is unable to reach there.
While Common Lisp does not, out of the box, provide support for specific
hardware, its design is specifically done to not preclude hardware
changes--so it can withstand change that its designers had seen, and
expected to see more of. C, by contrast, is closer to particular
machines, but is not remarkably flexible to arbitrary machines.
Consequently, customizing a dialect of Lisp to a particular concrete
machine, while it's not done for you, is not impossible to do; it's
probably easier than customizing C to a particular new concrete machine.
I also think the notion of of "close to the machine" depends on the
machine. The DEC PDP-10 had 36-bit words, and did not use byte
instructions but word and half-word instructions. Lisp was a good
system programming language for that machine because its data model
was good for that hardware in a way that C was not--I don't even think
anyone had a running version of C for that machine.
Lisp has always been used specifically to write low-level
things. Someone with low-level knowledge of LIL technologies, for
example, should chime in here. The Lisp Machine FEP is also an
example of something programmed in Lisp; I don't know what processor
it used, but I doubt it was an Ivory chip. ISLISP was designed to
address embedded hardware; I don't know if that was pursued, but I
don't think there was anything in its design that would inhibit that.
It's very easy to use "failure of budget" as a proof that an idea
didn't work, but often the thing that kills bright ideas is not the
idea but some other issue of politics.
Evolution, capitalism, and democracy turn on the high-order bit of a
many-bit feature vector, often ruthlessly killing off anything that is
up-and-coming but not yet positioned to be the critical element. One of
the most irritating things people do when elected president by what these
days is a questionable margin is to proclaim that the implication is that
The Country supports their full agenda and rejects the other's agenda.
There just aren't that many bits of information.
And likewise, there are not enough bits of information to say that
"any Lisp" is unsuitable for arbitrary "real" hardware... without
defining a lot of terminology: Do you mean extant Lisps or Lisps
possible to construct? Are you indicting the concept of Lisp or the
pocketbook of those embracing its ideas? Are you allowing handicapping
for the pocketbooks of people who happen to be in the dominant market
position on the other side in order to set the standard?
In the end, does a market gap imply failure of an idea? Or simply
point to an opportunity to apply an idea? Markets aside, what is the
TECHNICAL barrier to Lisp being in these places?
On May 2, 8:11 am, Kent M Pitman <······@nhplace.com> wrote:
> A hardware machine to support Java or the Microsoft CLR, for example,
> is not inconceivable. Should one arise, would "Lisp... any Lisp" be
> closer to or father from such an abstract machine than Lisp?
In fact, Azul Systems constructs such a machine for Java:
http://www.azulsystems.com/products/compute_appliance.htm
>
> - I think people are too little familiar with other hardware and other
> dialects of Lisp to be able to say that Lisp is unable to reach there.
> While Common Lisp does not, out of the box, provide support for specific
> hardware, its design is specifically done to not preclude hardware
> changes--so it can withstand change that its designers had seen, and
> expected to see more of. C, by contrast, is closer to particular
> machines, but is not remarkably flexible to arbitrary machines.
> Consequently, customizing a dialect of Lisp to a particular concrete
> machine, while it's not done for you, is not impossible to do; it's
> probably easier than customizing C to a particular new concrete machine.
The fallacy is `Proof by Lack of Imagination'. Just because one
doesn't
know how to write `close to the metal' code in Lisp doesn't mean that
it is impossible or even impractical.
Joe Marshall wrote:
> On May 2, 8:11 am, Kent M Pitman <······@nhplace.com> wrote:
>
>> A hardware machine to support Java or the Microsoft CLR, for example,
>> is not inconceivable. Should one arise, would "Lisp... any Lisp" be
>> closer to or father from such an abstract machine than Lisp?
>
> In fact, Azul Systems constructs such a machine for Java:
> http://www.azulsystems.com/products/compute_appliance.htm
>
Note also that some ARM processors include a java bytecode mode
called "jazelle" in addition to the well-known (for some
value of well-known) arm and thumb modes:
http://www.arm.com/products/esd/jazelle_home.html
Joe Marshall <··········@gmail.com> wrote:
+---------------
| Kent M Pitman <······@nhplace.com> wrote:
| > Consequently, customizing a dialect of Lisp to a particular concrete
| > machine, while it's not done for you, is not impossible to do; it's
| > probably easier than customizing C to a particular new concrete machine.
|
| The fallacy is `Proof by Lack of Imagination'. Just because one
| doesn't know how to write `close to the metal' code in Lisp doesn't
| mean that it is impossible or even impractical.
+---------------
(*sigh*) I find it odd that so far none of the senior Lispers in
this thread have pointed to *THEIR OWN LISPS' COMPILERS* as being
precisely such an example of "customizing a dialect of Lisp to a
particular concrete machine"!!! Come on, guys, Lisp has been doing
this since *DAY ONE*!!! To wit, here are a couple of small snippets
from "cmucl/src/compilercmucl-19c/src/compiler/x86". The INST forms
emit bare x86 instructions, while other forms in :GENERATOR sections
are other VOPs [virtual operations] that emit sequences of INSTs --
effectively, VOPs provide a "smart" assembler with macros. I think
you'll find this is about as "close to the metal" as you're going to
get in *any* language other than raw binary!!
;;;; Type frobbing VOPs
...
(define-vop (get-type)
(:translate get-type)
(:policy :fast-safe)
(:args (object :scs (descriptor-reg)))
(:temporary (:sc unsigned-reg :offset eax-offset :to (:result 0)) eax)
(:results (result :scs (unsigned-reg)))
(:result-types positive-fixnum)
(:generator 6
(inst mov eax object)
(inst and al-tn lowtag-mask)
(inst cmp al-tn other-pointer-type)
(inst jmp :e other-ptr)
(inst cmp al-tn function-pointer-type)
(inst jmp :e function-ptr)
;; pick off structures and list pointers
(inst test al-tn 1)
(inst jmp :ne done)
;; pick off fixnums
(inst and al-tn 3)
(inst jmp :e done)
;; must be an other immediate
(inst mov eax object)
(inst jmp done)
FUNCTION-PTR
(load-type al-tn object (- vm:function-pointer-type))
(inst jmp done)
OTHER-PTR
(load-type al-tn object (- vm:other-pointer-type))
DONE
(inst movzx result al-tn)))
...
(define-vop (make-fixnum)
(:args (ptr :scs (any-reg descriptor-reg) :target res))
(:results (res :scs (any-reg descriptor-reg)))
(:generator 1
;;
;; Some code (the hash table code) depends on this returning a
;; positive number so make sure it does.
(move res ptr)
(inst shl res 3)
(inst shr res 1)))
...
;;;; Other random VOPs.
...
(defknown lisp::%scrub-control-stack () (values))
;;; Scrub the control stack.
;;;
;;; On the x86 port the stack grows downwards, and to support grow on
;;; demand stacks the stack must be decreased as it is scrubbed.
;;;
(define-vop (%scrub-control-stack)
(:policy :fast-safe)
(:translate lisp::%scrub-control-stack)
(:args)
(:results)
(:temporary (:sc unsigned-reg) count)
(:temporary (:sc any-reg) stack-save zero)
(:generator 25
(inst mov stack-save esp-tn)
(inst mov zero 0)
(inst push zero)
;; Scrub the stack.
SCRUB
(inst add esp-tn 4)
(inst mov count 2048)
SCRUB-LOOP
(inst dec count)
(inst push zero)
(inst jmp :nz SCRUB-LOOP)
;; Look for a clear stack unit.
(inst mov count 2048)
LOOK-LOOP
(inst sub esp-tn 4)
(inst cmp (make-ea :dword :base esp-tn) zero)
(inst jmp :ne SCRUB)
(inst dec count)
(inst jmp :nz LOOK-LOOP)
;; Done, restore the stack pointer.
(inst mov esp-tn stack-save)))
...
;; the RDTSC instruction (present on Pentium processors and
;; successors) allows you to access the time-stamp counter, a 64-bit
;; model-specific register that counts executed cycles. The
;; instruction returns the low cycle count in EAX and high cycle count
;; in EDX.
;;
;; In order to obtain more significant results on out-of-order
;; processors (such as the Pentium II and later), we issue a
;; serializing CPUID instruction before reading the cycle counter.
;; This instruction is used for its side effect of emptying the
;; processor pipeline, to ensure that the RDTSC instruction is
;; executed once all pending instructions have been completed.
;;
;; Note that cache effects mean that the cycle count can vary for
;; different executions of the same code (it counts cycles, not
;; retired instructions). Furthermore, the results are per-processor
;; and not per-process, so are unreliable on multiprocessor machines
;; where processes can migrate between processors.
;;
;; This method of obtaining a cycle count has the advantage of being
;; very fast (around 20 cycles), and of not requiring a system call.
;; However, you need to know your processor's clock speed to translate
;; this into real execution time.
(defknown read-cycle-counter
()
(values (unsigned-byte 32) (unsigned-byte 32))
())
(define-vop (read-cycle-counter)
(:translate read-cycle-counter)
(:guard (backend-featurep :pentium))
(:args )
(:policy :fast-safe)
(:results (lo :scs (unsigned-reg))
(hi :scs (unsigned-reg)))
(:result-types unsigned-num unsigned-num)
(:temporary (:sc unsigned-reg :offset eax-offset :target lo) eax)
(:temporary (:sc unsigned-reg :offset edx-offset :target hi) edx)
(:generator 1
(inst cpuid)
(inst rdtsc)
(move hi edx)
(move lo eax)))
#+pentium
(defun read-cycle-counter ()
(read-cycle-counter))
And it's not just CMUCL, of course. *Any* other mature Lisp compiler
will provide countless more examples of such "customizing ... Lisp to
a particular concrete machine".
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Oops! Two bloopers:
I just wrote:
+---------------
| (*sigh*) I find it odd that so far none of the senior Lispers
| in this thread have pointed to *THEIR OWN LISPS' COMPILERS* ...
+---------------
When I wrote that I hadn't yet gotten to Joe Marshall's posting
containing an example of CADR microcode.
+---------------
| To wit, here are a couple of small snippets
| from "cmucl/src/compilercmucl-19c/src/compiler/x86".
+---------------
Cut&paste typo, should have been "cmucl-19c/src/compiler/x86/system.lisp".
Apologies for any confusion caused...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On May 3, 9:50 pm, ····@rpw3.org (Rob Warnock) wrote:
> Joe Marshall <··········@gmail.com> wrote:
> +---------------
> | Kent M Pitman <······@nhplace.com> wrote:
> | > Consequently, customizing a dialect of Lisp to a particular concrete
> | > machine, while it's not done for you, is not impossible to do; it's
> | > probably easier than customizing C to a particular new concrete machine.
> |
> | The fallacy is `Proof by Lack of Imagination'. Just because one
> | doesn't know how to write `close to the metal' code in Lisp doesn't
> | mean that it is impossible or even impractical.
> +---------------
>
> (*sigh*) I find it odd that so far none of the senior Lispers in
> this thread have pointed to *THEIR OWN LISPS' COMPILERS* as being
> precisely such an example of "customizing a dialect of Lisp to a
> particular concrete machine"!!! Come on, guys, Lisp has been doing
> this since *DAY ONE*!!! To wit, here are a couple of small snippets
> from "cmucl/src/compilercmucl-19c/src/compiler/x86". The INST forms
> emit bare x86 instructions, while other forms in :GENERATOR sections
> are other VOPs [virtual operations] that emit sequences of INSTs --
> effectively, VOPs provide a "smart" assembler with macros. I think
> you'll find this is about as "close to the metal" as you're going to
> get in *any* language other than raw binary!!
I'm not too familiar with CMUCL. I'm much more familiar with Allegro
and Lispworks, but I figured Duane would cover Allegro if he felt the
need to.
Joe Marshall <··········@gmail.com> writes:
> On May 3, 9:50 pm, ····@rpw3.org (Rob Warnock) wrote:
>> Joe Marshall <··········@gmail.com> wrote:
>> +---------------
>> | Kent M Pitman <······@nhplace.com> wrote:
>> | > Consequently, customizing a dialect of Lisp to a particular concrete
>> | > machine, while it's not done for you, is not impossible to do; it's
>> | > probably easier than customizing C to a particular new concrete machine.
>> |
>> | The fallacy is `Proof by Lack of Imagination'. Just because one
>> | doesn't know how to write `close to the metal' code in Lisp doesn't
>> | mean that it is impossible or even impractical.
>> +---------------
>>
>> (*sigh*) I find it odd that so far none of the senior Lispers in
>> this thread have pointed to *THEIR OWN LISPS' COMPILERS* as being
>> precisely such an example of "customizing a dialect of Lisp to a
>> particular concrete machine"!!! Come on, guys, Lisp has been doing
>> this since *DAY ONE*!!! To wit, here are a couple of small snippets
>> from "cmucl/src/compilercmucl-19c/src/compiler/x86". The INST forms
>> emit bare x86 instructions, while other forms in :GENERATOR sections
>> are other VOPs [virtual operations] that emit sequences of INSTs --
>> effectively, VOPs provide a "smart" assembler with macros. I think
>> you'll find this is about as "close to the metal" as you're going to
>> get in *any* language other than raw binary!!
>
> I'm not too familiar with CMUCL. I'm much more familiar with Allegro
> and Lispworks, but I figured Duane would cover Allegro if he felt the
> need to.
That ended up being the case :-)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Wed, 02 May 2007 11:11:21 -0400, Kent M Pitman wrote:
> Andrew Reilly <···············@areilly.bpc-users.org> writes:
>
>> On Tue, 01 May 2007 20:25:08 +0000, Pierre THIERRY wrote:
>>
>> >> I didn't say anything about C, but if you want to drag it in - the
>> >> abstract machine which defines C is far closer to real hardware than
>> >> the abstract machine which defines Lisp ... any Lisp.
>> >
>> > How is it closer?
>>
>> Uses the same data types as those provided by the physical machine, and
>> these are typically not dynamic.
>
> This argument has a bit of the surreal feel that, for example, I might
> expect to come from a hypothetical provocative statement like
> "Catholicism is far closer to the notion of what constitutes a real
> religion than the abstract religion that is Buddhism." That is, it seems
> to contain a lot of blurriness, chauvinism, etc. that needs to be teased
> out.
Well, that's an amusing start to an amusing rant, but since it completely
(well, mostly) misses the point that I thought that I was making, I'll
have another go.
Lots and lots of processors today have flat address spaces. That is,
addresses are essentially machine integers of some particular length.
Yes, some useful classes of processors distinguish between program
addresses and data addresses, or between several different types of data
address. Those distinctions are typically not useful to C, and so have
been steadily removed from newly designed processors for some time.
The memory at each address is a certain number of bits wide, which C calls
a char (irrespective of how many bits wide it is), and some number of
these in sequence, (perhaps with alignment restrictions, and taking into
account "endian" issues, both of which complicate programs but not the
basic model) are used to store integers of various sorts or floating point
numbers of various sorts. The memory doesn't care what is in the bits,
and you can't find out what type of information is in the bits by looking
at them. The type of the data is entirely dependent on the instructions
that are used on the data when it is loaded out of memory, into the
processor.
Now, these are characteristics that it has been increasingly (and wisely)
regarded as not good to expose directly to programmers, but in C,
they mostly are. If I'm working on a 32-bit machine, and I load a 32-bit
int from a properly aligned machine address, then I can be fairly certain
that that will take no more than one machine instruction to execute, and
subsequent operations on the loaded value will not involve calls to the
multi-precision arithmetic library. If I do maths that produces a result
larger than (2^31 - 1), then it will probably wrap around. If I do maths
on it as an unsigned number, then I can rely on it wrapping around. Or I
can do bit-wise logical operations on it. I can use bit-wise logical
operations on a floating point number, if it takes my fancy. Not useful
characteristics, in general. In fact, characteristics that mostly get in
the way of the tidy expression of an algorithm, but that's the way that it
is.
> And not because I'm saying there's something inappropriate about liking
> Catholicism or the C language.
I'm not expressing a preference for C, at all.
> But if you get to the point where you want to advocate a position to
> others in the form of world-wide open debate, it would seem fair (to me)
> to at least define a few terms and set a context for the debate, so that
> people on the other side (the abstract, unreal side, as it's been
> presented here) are not left as automatic losers because the debate has
> been framed in a way that is not far removed from the line "People who
> like this sort of thing will find that this is the sort of thing that
> they like."
Well, I hope that the explanation, above, gets a bit closer to the point
that I (glibly) made in the previous post.
> So, to start, there's a bit of circularity there, since I'm sure people
> are at this point building machines to support C. Suppose they didn't.
> Would that change your claim?
People have, and do build machines without the intent or desire to support
C. Lots of them. Many of them pre-date C. C reacted to this variability
by defining the operators vaguely, in terms of the machine
characteristics. That's why C programs generally behave differently on
different machines, unless considerable care is taken. Lisp code, on the
other hand, generally does what it says, based on a largely abstract
specification.
> There have been real machines that C was farther from in
> the past, and that could happen again in a theoretical sense... though,
> as I said, since the game is presently to make hardware that supports C,
> that may seem strange.
Not strange at all. I use many such machines on a daily (or at least
yearly) basis. They generally get programmed in assembler. I suspect
that lisp would be even more difficult to target to them, and kind of
pointless.
> A hardware machine to support Java or the Microsoft CLR, for example, is
> not inconceivable. Should one arise, would "Lisp... any Lisp" be closer
> to or father from such an abstract machine than Lisp?
To the best of my knowledge, both the JVM and CLR share a machine model
that only shows behaviour approaching lisp's dynamism for objects, a
category which excludes the "basic machine types". Both of them go so far
as to insist on particular word sizes for the various primitive types, so
running Java on a 36 or 24-bit word-addressed machine would be an exercise
in futile pain, I suspect.
> What about a Connection Machine or some more modern neural net
> equivalent. Will C or Lisp be closer to that?
The CM was just a highly-connected array of simple stack machines.
Similarly, or at a larger scale, IBM's Blue Gene is a large array of
simple RISC machines. Both lisp and C probably run as well on the
nodes as any other language. Neither is particularly well suited to
expressing the multi-node parallelism of the machine in a global sense,
though. As far as I know, that is still an open research question
currently receiving significant wodges of DARPA funding.
> I'm not trying to overly defend Lisp as the answer to everything. I'm
> actually all for heterogeneous environments, and using an incidentally
> appropriate language at an appropriate time. But...
Me too.
> - I think too often people use C/C++ by default, both in places
> where it works but doesn't scale, and in places where it doesn't
> really work but is "familiar".
I think that's likely to be true. In my field (embedded DSP), assembler
and C are likely to be the only languages available on any given
processor, and even then, C isn't necessarily a given. C++ is quite rare,
but becoming more available. Availability counts for quite a lot.
> I also think the notion of of "close to the machine" depends on the
> machine. The DEC PDP-10 had 36-bit words, and did not use byte
> instructions but word and half-word instructions. Lisp was a good
> system programming language for that machine because its data model was
> good for that hardware in a way that C was not--I don't even think
> anyone had a running version of C for that machine.
I don't know the exact situation of C wrt the PDP-10. I suspect that it
exists, now, but the -10 pre-dates widespread use of C, I think. In any
case, C would fit very easily on the -10 as-is, *but* I doubt that there
is very much existing C code that would run, or run well, in that
environment without a great deal of porting effort. In particular,
anything that operated on character strings and expected each character to
occupy fewer than 18 bits of memory would need to be re-coded to use a
more abstract string library. Fortran-ish C code that operated
exclusively on integers and floating point numbers would probably have
much less of a porting problem.
> And likewise, there are not enough bits of information to say that "any
> Lisp" is unsuitable for arbitrary "real" hardware... without defining a
> lot of terminology: Do you mean extant Lisps or Lisps possible to
> construct? Are you indicting the concept of Lisp or the pocketbook of
> those embracing its ideas? Are you allowing handicapping for the
> pocketbooks of people who happen to be in the dominant market position
> on the other side in order to set the standard?
I'm not trying to argue that Lisp can't run on anything at all. Far from
it. The more stuff that Lisp can run on, the happier I'll be. The one
(and only) point that I was making is that lisp's model of a machine is
one where it can determine whether or not the FADD or ADD instructions or
some library function should be used to add two numbers at *run-time*
(unless effort is made to clarify the situation), whereas in C (just
as in the machine's native assembler) that alternative is not available.
> In the end, does a market gap imply failure of an idea? Or simply point
> to an opportunity to apply an idea? Markets aside, what is the
> TECHNICAL barrier to Lisp being in these places?
I don't believe that I was considering markets at all.
Cheers,
--
Andrew
From: Kent M Pitman
Subject: Re: What are the domains that lisp doesn't fit int?
Date:
Message-ID: <uirbamvat.fsf@nhplace.com>
Andrew Reilly <···············@areilly.bpc-users.org> writes:
> The memory at each address is a certain number of bits wide, which C
> calls a char (irrespective of how many bits wide it is), and some
> number of these in sequence, (perhaps with alignment restrictions,
> and taking into account "endian" issues, both of which complicate
> programs but not the basic model) are used to store integers of
> various sorts or floating point numbers of various sorts. The
> memory doesn't care what is in the bits, and you can't find out what
> type of information is in the bits by looking at them. The type of
> the data is entirely dependent on the instructions that are used on
> the data when it is loaded out of memory, into the processor.
>
> Now, these are characteristics that it has been increasingly (and
> wisely) regarded as not good to expose directly to programmers, but
> in C, they mostly are. If I'm working on a 32-bit machine, and I
> load a 32-bit int from a properly aligned machine address, then I
> can be fairly certain that that will take no more than one machine
> instruction to execute, and subsequent operations on the loaded
> value will not involve calls to the multi-precision arithmetic
> library. If I do maths that produces a result larger than (2^31 -
> 1), then it will probably wrap around. If I do maths on it as an
> unsigned number, then I can rely on it wrapping around. Or I can do
> bit-wise logical operations on it. I can use bit-wise logical
> operations on a floating point number, if it takes my fancy. Not
> useful characteristics, in general. In fact, characteristics that
> mostly get in the way of the tidy expression of an algorithm, but
> that's the way that it is.
I'm having trouble sorting out from this narrative what the criticism
of Lisp is. I hear a lot about what C can do, and it's as if the
negative space this leaves is "obviously" describing Lisp's inabilities.
I don't see that.
Maclisp, to take an example, had datatypes that used whole machine
words (not taking up space for tags, even though you had tagged data),
had machine-word arithmetic that did wrapping, had operators that
would force data of one tag type to be viewed as another tag type
without changing the bits of the data, etc. There was an array type
for un-marked-through pointers, and it was possible to get whole pages
of data that were yours to manage as you liked. I'm not saying that
exhausts the space of things one could do, but it points to the
versatility of the model.
No, Maclisp doesn't really run on anything useful now. But that's not
my point. One could make another. And the point is that it's easily
among the space of possible Lisps...
One could trivially create a Lisp dialect that does that
... particularly on a small address space machine, where the BiBOP
style of storage management and a mark/sweep garbage collection scheme
would be tractable. You are familiar with BiBOP (Big Bag of Pages),
right?
I might be wrong, but I have the strangest feeling that all of the
above is just a longhand way of saying you think it's antithetical to
the Lisp model to have machine-level operators. It's not. We chose
that for CL (a particular dialect among many) because it ported
well. But if your goal is not porting, it's easily possible to do
other things. If your goal is porting, and you're willing to say that
C is your virtual machine and you'll take pot luck of what C means by
things, you can also do other things. My reaction is not to saying C
does this, nor to saying that CL doesn't, but to saying that no Lisp
does or could.
> > So, to start, there's a bit of circularity there, since I'm sure
> > people are at this point building machines to support C. Suppose
> > they didn't. Would that change your claim?
>
> People have, and do build machines without the intent or desire to
> support C. Lots of them. Many of them pre-date C. C reacted to
> this variability by defining the operators vaguely, in terms of the
> machine characteristics. That's why C programs generally behave
> differently on different machines, unless considerable care is
> taken. Lisp code, on the other hand, generally does what it says,
> based on a largely abstract specification.
How many dialects of Lisp have you studied? To which specific
dialects of Lisp do you refer? The reason I ask this is that I don't
really think you are offering technical information that spans all the
variety of dialects of Lisp there have been. I think you are
overgeneralizing based on a few, and I think the proof that you are
not will be shown by enumerating the general space of dialects to
which you refer.
It's a common topic of a first Lisp course, "what is lisp?", exactly
because it's so difficult to define Lisp abstractly. There is not
even universal agreement on what its criterial features are. Some
would say automatic memory management (though there are Lisps that
have none), some would say dynamic typing (but it's possible to
construct a statically typed lisp), some would say cons, car and cdr
(though I've seen people omit that, at least for teaching), some would
say lambda (though some don't have full closures), and so on.
I feel, though, as if you're picking not an ability but an inability
as the defining characteristic of Lisp... that may not be your intent,
but it feels that way. Just how do you define Lisp, such that you can
predict the failures of dialects you've never seen, sight unseen?
> > And likewise, there are not enough bits of information to say that
> > "any Lisp" is unsuitable for arbitrary "real" hardware... without
> > defining a lot of terminology: Do you mean extant Lisps or Lisps
> > possible to construct? Are you indicting the concept of Lisp or
> > the pocketbook of those embracing its ideas? Are you allowing
> > handicapping for the pocketbooks of people who happen to be in the
> > dominant market position on the other side in order to set the
> > standard?
>
> I'm not trying to argue that Lisp can't run on anything at all. Far
> from it. The more stuff that Lisp can run on, the happier I'll be.
> The one (and only) point that I was making is that lisp's model of a
> machine is one where it can determine whether or not the FADD or ADD
> instructions or some library function should be used to add two
> numbers at *run-time* (unless effort is made to clarify the
> situation), whereas in C (just as in the machine's native assembler)
> that alternative is not available.
I'm not so sure this is so. Lisp allows you to choose between
deciding that question at compile time and at runtime. Common Lisp
happens to make the decision for you, but there is nothing in the Lisp
paradigm that requires you to make that decision at runtime. I think
Lisp as a language family is substantially more flexible in its
details than I think you are pigeon-holing it into. What you say is
true of some of its dialects, but you are mischaracterizing the
language family by assuming it's a fundamental property of the entire
language family that these other things are true. Those are all
choice points in a very large design space. (Within many CL
implementations, too, you can get the effects you want by working with
native function calling facilities and just ignoring the standard
libraries.)
On Wed, 02 May 2007 23:37:46 -0400, Kent M Pitman wrote:
> I'm not so sure this is so. Lisp allows you to choose between
> deciding that question at compile time and at runtime. Common Lisp
> happens to make the decision for you, but there is nothing in the Lisp
> paradigm that requires you to make that decision at runtime. I think
> Lisp as a language family is substantially more flexible in its
> details than I think you are pigeon-holing it into. What you say is
> true of some of its dialects, but you are mischaracterizing the
> language family by assuming it's a fundamental property of the entire
> language family that these other things are true. Those are all
> choice points in a very large design space. (Within many CL
> implementations, too, you can get the effects you want by working with
> native function calling facilities and just ignoring the standard
> libraries.)
I apologise: you are entirely correct. There is nothing about Lisp (the
family) that requires the dynamism that I've been going on about. It's
just that that's been one of the key features of the (very) few lisps that
I've used (which number four, so far: ancient Franz, CL, and two schemes,
and I don't even remember much about franz.) I can't see anything in the
syntax or basic operation that would preclude a dialect that operated
directly on native data types, with typed operators. I don't think that I was
intending to cast the "Lisp" net quite as wide as that, probably mostly
because of my own lack of knowledge of lisp. I certainly didn't intend to
imply that dynamically-typed lisp was "deficient" in comparison to C.
I'll have to think about this a bit more.
Cheers,
--
Andrew
In article <······························@areilly.bpc-users.org>,
Andrew Reilly <···············@areilly.bpc-users.org> wrote:
> On Wed, 02 May 2007 23:37:46 -0400, Kent M Pitman wrote:
>
> > I'm not so sure this is so. Lisp allows you to choose between
> > deciding that question at compile time and at runtime. Common Lisp
> > happens to make the decision for you, but there is nothing in the Lisp
> > paradigm that requires you to make that decision at runtime. I think
> > Lisp as a language family is substantially more flexible in its
> > details than I think you are pigeon-holing it into. What you say is
> > true of some of its dialects, but you are mischaracterizing the
> > language family by assuming it's a fundamental property of the entire
> > language family that these other things are true. Those are all
> > choice points in a very large design space. (Within many CL
> > implementations, too, you can get the effects you want by working with
> > native function calling facilities and just ignoring the standard
> > libraries.)
>
> I apologise: you are entirely correct. There is nothing about Lisp (the
> family) that requires the dynamism that I've been going on about. It's
> just that that's been one of the key features of the (very) few lisps that
> I've used (which number four, so far: ancient Franz, CL, and two schemes,
> and I don't even remember much about franz.) I can't see anything in the
> syntax or basic operation that would preclude a dialect that operated
> directly on native data types, with typed operators. I don't think that I was
> intending to cast the "Lisp" net quite as wide as that, probably mostly
> because of my own lack of knowledge of lisp. I certainly didn't intend to
> imply that dynamically-typed lisp was "deficient" in comparison to C.
>
> I'll have to think about this a bit more.
>
> Cheers,
While thinking of it, I suggest reading a bit
in the Lisp Machine Manual (Hypertext Edition).
http://common-lisp.net/project/bknr/static/lmman/frontpage.html
It describes an implementation of Lisp Machine Lisp,
where this implementation provided lots of low-level
features in Lisp.
--
http://lispm.dyndns.org
On Thu, 03 May 2007 16:04:31 +1000, Andrew Reilly wrote:
> On Wed, 02 May 2007 23:37:46 -0400, Kent M Pitman wrote:
>
>> I'm not so sure this is so. Lisp allows you to choose between
>> deciding that question at compile time and at runtime. Common Lisp
>> happens to make the decision for you, but there is nothing in the Lisp
>> paradigm that requires you to make that decision at runtime. I think
>> Lisp as a language family is substantially more flexible in its
>> details than I think you are pigeon-holing it into. What you say is
>> true of some of its dialects, but you are mischaracterizing the
>> language family by assuming it's a fundamental property of the entire
>> language family that these other things are true. Those are all
>> choice points in a very large design space. (Within many CL
>> implementations, too, you can get the effects you want by working with
>> native function calling facilities and just ignoring the standard
>> libraries.)
>
> I apologise: you are entirely correct. There is nothing about Lisp (the
> family) that requires the dynamism that I've been going on about. It's
> just that that's been one of the key features of the (very) few lisps that
> I've used (which number four, so far: ancient Franz, CL, and two schemes,
> and I don't even remember much about franz.) I can't see anything in the
> syntax or basic operation that would preclude a dialect that operated
> directly on native data types, with typed operators. I don't think that I was
> intending to cast the "Lisp" net quite as wide as that, probably mostly
> because of my own lack of knowledge of lisp. I certainly didn't intend to
> imply that dynamically-typed lisp was "deficient" in comparison to C.
You might want to take a closer look at Franz. It followed the same
implementation strategy as maclisp, but is written in C.
Robert Swindells
Le Wed, 02 May 2007 23:37:46 -0400, Kent M Pitman a écrit:
>> lisp's model of a machine is one where it can determine whether or
>> not the FADD or ADD instructions or some library function should be
>> used to add two numbers at *run-time* [...]
> [...] Common Lisp happens to make the decision for you, but there is
> nothing in the Lisp paradigm that requires you to make that decision
> at runtime.
I thought I had read somewhere that nothing prevents Common Lisp to be
statically typed at compile time... Quid?
Curiously,
Pierre
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
From: Lars Brinkhoff
Subject: Re: What are the domains that lisp doesn't fit int?
Date:
Message-ID: <858xc6xb24.fsf@junk.nocrew.org>
Kent M Pitman wrote:
> The DEC PDP-10 had 36-bit words, and did not use byte instructions
> but word and half-word instructions. Lisp was a good system
> programming language for that machine because its data model was
> good for that hardware in a way that C was not--I don't even think
> anyone had a running version of C for that machine.
There are several C implementations for the PDP-10. I have personally
used an older compiler called KCC, and I wrote a PDP-10 backend for
GCC some years ago.
ObLisp: I believe there was a Common Lisp implementation too, but if
so only a CLtL1 flavour.
>>>>> "Kent" == Kent M Pitman <······@nhplace.com> writes:
Kent> The Lisp Machine FEP is also an example of something programmed
Kent> in Lisp; I don't know what processor it used, but I doubt it was
Kent> an Ivory chip.
The Symbolics FEP was based on a Motorola 68000 CPU AFAIK, at least
for certain lines of Symbolics.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
From: Frode Vatvedt Fjeld
Subject: Re: What are the domains that lisp doesn't fit int?
Date:
Message-ID: <2hhcqs9xrn.fsf@vserver.cs.uit.no>
George Neuner <·········@comcast.net> writes:
> Movitz is a truly wonderful piece of software, but it is not quite
> the showpiece for bare metal Lisp programming that you think it is.
> The kernel runtime functions are not written in Lisp and their use
> requires special knowledge in the compiler (which is, of course, not
> dissimilar from any other implementation ... but that makes my point
> for me).
At some point, any higher-level language needs to be expressed in
terms of a lower-level languange. I don't understand what point that
makes about CL's abilities for hardware-near programming.
> Additionally many of the drivers included with Muerte appear to have
> been adapted from open source Linux versions rather than written new
> to take advantage of Lisp.
I think the unfortunate state of affairs here is that there are not
many drivers at all. I don't know what you have in mind in terms of
taking advantage of Lisp here, but I'd be interested to hear about it
since it's something I plan to investigate sooner or later (actually
right now the issue of how to organize graphics drivers is on the
table, see http://trac.common-lisp.net/movitz/wiki/GraphicsApi ).
> Although new drivers written in Lisp can use the existing runtime
> services, new runtime services cannot necessarily be written in
> Lisp.
This is only true for a rather narrow definition of "runtime
services", I would say.
> Nor does the system as yet provide GC, it currently has only a very
> rudimentary, allocate only, "mark no release" memory scheme for use
> in kernel programming.
Actually, there has been a quite functional GC implemented since quite
a while now (a few years). The GC as such is all Lisp, although the
memory allocation routines are mostly assembly.
> The Lisp machines, and to a lesser extent Movitz, show that CL can
> be mated to and used successfully on a bare metal runtime package
> ... but that has never been in dispute. In my book that's not the
> same as saying CL can be used to program bare metal.
I don't see why the distinction is important?
--
Frode Vatvedt Fjeld
On 04 May 2007 21:47:24 +0200, Frode Vatvedt Fjeld <······@cs.uit.no>
wrote:
>George Neuner <·········@comcast.net> writes:
>
>> Movitz is a truly wonderful piece of software, but it is not quite
>> the showpiece for bare metal Lisp programming that you think it is.
>> The kernel runtime functions are not written in Lisp and their use
>> requires special knowledge in the compiler (which is, of course, not
>> dissimilar from any other implementation ... but that makes my point
>> for me).
>
>At some point, any higher-level language needs to be expressed in
>terms of a lower-level languange. I don't understand what point that
>makes about CL's abilities for hardware-near programming.
Yes, that's true. The point is that CL (and Lisp in general) has no
way to specify that code or data be placed at a particular address.
While it is more typical that data has to be placed, there are systems
(DSP, GPU, Cell, etc.) which require the ability to place code as
well.
Any required functions can be provided by primitives, but IMO the
question of hardware programming is whether the primitives themselves
could be written in the high(er) level language. Notice I said
_could_ be written - for performance reasons it is expected that they
normally would not be.
To that end, lower level languages like C need less primitive support
than Lisp because more of the primitive behavior can be expressed
directly in the language. Note that I am discounting assembly to
memory because that can be done in any language. I am referring
instead to things such as memory mapped I/O which could be expressed
directly in C but requires primitive support in Lisp.
As I said previously, a setjmp/longjmp implementation with a complete
register dump provides the basis for expressing almost anything
directly in C. Clearly, it is _not_ desirable to do things that way -
the result is convoluted, incredibly slow, self modifying code ... but
the point is it would be possible with only that minimal primitive
support (and a few dozen bootstrap instructions) to express most
hardware access and operating system functions directly in C. The
same is not true of Lisp.
Please understand that I am not trying to disparage Lisp nor promote C
- I am only saying that targeting a runtime arbitrarily close to the
metal is not the same as targeting the metal itself.
>> Additionally many of the drivers included with Muerte appear to have
>> been adapted from open source Linux versions rather than written new
>> to take advantage of Lisp.
>
>I think the unfortunate state of affairs here is that there are not
>many drivers at all. I don't know what you have in mind in terms of
>taking advantage of Lisp here, but I'd be interested to hear about it
>since it's something I plan to investigate sooner or later (actually
>right now the issue of how to organize graphics drivers is on the
>table, see http://trac.common-lisp.net/movitz/wiki/GraphicsApi ).
I mean, for example, being able to write (certain kinds of) drivers in
the fashion of the AT&T stream model, using Lisp streams and letting
the language handle things like buffering. Some of which is already
possible but difficult for functions that need direct hardware access.
Think about, for example, being able to open a stream on an arbitrary
DMA device.
>> Although new drivers written in Lisp can use the existing runtime
>> services, new runtime services cannot necessarily be written in
>> Lisp.
>
>This is only true for a rather narrow definition of "runtime
>services", I would say.
I think it depends on where the line is drawn to separate the hardware
layer from the Lisp runtime. Admittedly, which functions belong to
which layer is debatable.
>> Nor does the system as yet provide GC, it currently has only a very
>> rudimentary, allocate only, "mark no release" memory scheme for use
>> in kernel programming.
>
>Actually, there has been a quite functional GC implemented since quite
>a while now (a few years). The GC as such is all Lisp, although the
>memory allocation routines are mostly assembly.
If I am mistaken then I apologize ... when last I looked at the
documentation, it stated that the kernel (as opposed to the Lisp image
running above the kernel) provided only very simple management. It
appeared that drivers and other kernel services could not use GC.
>> The Lisp machines, and to a lesser extent Movitz, show that CL can
>> be mated to and used successfully on a bare metal runtime package
>> ... but that has never been in dispute. In my book that's not the
>> same as saying CL can be used to program bare metal.
>
>I don't see why the distinction is important?
The distinction for me is whether the language can be used directly
express the required functionality in its own syntax and without the
programmer resorting to linking libraries written in a different
language, generating assembler code in memory, or writing a cross
compiler, runtime and linker.
As you say, no language higher than assembler is adequate to express
_all_ the needed functionality, but the question is how close you can
get. All I am claiming here is that Lisp needs a fair amount of
support that can't be expressed directly as Lisp (and only
incidentally that the amount Lisp needs is greater than what C needs).
Contrary to what some people think, I don't hate Lisp (though I prefer
Scheme to CL). But I have done quite a bit of bare metal programming
and I also have a good idea of what runtime support is required to get
a Lisp-like language running.
George
--
for email reply remove "/" from address
[I guess I must join the fray here, after all. I was fighting the
urge, but the level of misinformation/misunderstanding is much too
high now, and some reality needs to be injected]
George Neuner <·········@comcast.net> writes:
> On 04 May 2007 21:47:24 +0200, Frode Vatvedt Fjeld <······@cs.uit.no>
> wrote:
>
>>George Neuner <·········@comcast.net> writes:
>>
>>> Movitz is a truly wonderful piece of software, but it is not quite
>>> the showpiece for bare metal Lisp programming that you think it is.
>>> The kernel runtime functions are not written in Lisp and their use
>>> requires special knowledge in the compiler (which is, of course, not
>>> dissimilar from any other implementation ... but that makes my point
>>> for me).
>>
>>At some point, any higher-level language needs to be expressed in
>>terms of a lower-level languange. I don't understand what point that
>>makes about CL's abilities for hardware-near programming.
>
> Yes, that's true. The point is that CL (and Lisp in general) has no
> way to specify that code or data be placed at a particular address.
CL does indeed not specify such things, and with good reason. But
Lisp in general can most certainly specify to the address. So
specifically, in fact, that I can say "place an INT instruction at a
particular _byte_ in memory to create a breakpoint there". In Allegro
CL you can do this low-level activity using a slightly higher-level
specification, because it is more convenient to do so, but the effect
is still "directly to the metal":
CL-USER(1): :br count
; Fast loading from bundle code/lldb.fasl.
Adding #<Function COUNT>: 0
0: 55 pushl ebp
CL-USER(2): :ldb t
[LDB] CL-USER(3):
[LDB] CL-USER(3): (count #\a "abacad")
Hit breakpoint at func = #<Function COUNT>, pc=0
breakpoint-> 0: 55 pushl ebp
[LDB-STEP] CL-USER(4):
Hit breakpoint at func = #<Function COUNT>, pc=1
temp brkpt-> 1: 8b ec movl ebp,esp
[LDB-STEP] CL-USER(4):
Hit breakpoint at func = #<Function COUNT>, pc=3
temp brkpt-> 3: 56 pushl esi
[LDB-STEP] CL-USER(4):
(each press of RETURN/ENTER steps one, by default)
> Any required functions can be provided by primitives, but IMO the
> question of hardware programming is whether the primitives themselves
> could be written in the high(er) level language. Notice I said
> _could_ be written - for performance reasons it is expected that they
> normally would not be.
>
> To that end, lower level languages like C need less primitive support
> than Lisp because more of the primitive behavior can be expressed
> directly in the language. Note that I am discounting assembly to
> memory because that can be done in any language. I am referring
> instead to things such as memory mapped I/O which could be expressed
> directly in C but requires primitive support in Lisp.
Nonsense. Trivially:
CL-USER(2): (open "xxx" :mapped t)
#<MAPPED-FILE-SIMPLE-STREAM #P"xxx" mapped for input pos 0 @ #x715f772a>
CL-USER(3):
> As I said previously, a setjmp/longjmp implementation with a complete
> register dump provides the basis for expressing almost anything
> directly in C. Clearly, it is _not_ desirable to do things that way -
> the result is convoluted, incredibly slow, self modifying code ... but
> the point is it would be possible with only that minimal primitive
> support (and a few dozen bootstrap instructions) to express most
> hardware access and operating system functions directly in C. The
> same is not true of Lisp.
I'm not sure what you're getting at, here. But it doesn't matter;
Lisp can easily do the same things as C, if it wants to.
> Please understand that I am not trying to disparage Lisp nor promote C
Many people on this ng disparage Lisp without trying to. It only gets
me a little worked up when it's done using "facts" that are simply
untrue.
> - I am only saying that targeting a runtime arbitrarily close to the
> metal is not the same as targeting the metal itself.
If you're talking about lisp developers targeting the metal: that is
done all the time - consider native compilers: how much more to the
metal do you want? If you're talking about developers giving users
the tools to target the metal themselves, it is only a matter of
demand; there is very little demand for such things; it is more
important to our customers nowadays to be able to run portable
code than to have control of the metal. It's not that it can't be
done; it's that most of our customers don't _want_ it. Why would we
do such a stupid thing as to force something on customers that they
don't want?
>>> Additionally many of the drivers included with Muerte appear to have
>>> been adapted from open source Linux versions rather than written new
>>> to take advantage of Lisp.
>>
>>I think the unfortunate state of affairs here is that there are not
>>many drivers at all. I don't know what you have in mind in terms of
>>taking advantage of Lisp here, but I'd be interested to hear about it
>>since it's something I plan to investigate sooner or later (actually
>>right now the issue of how to organize graphics drivers is on the
>>table, see http://trac.common-lisp.net/movitz/wiki/GraphicsApi ).
>
> I mean, for example, being able to write (certain kinds of) drivers in
> the fashion of the AT&T stream model, using Lisp streams and letting
> the language handle things like buffering. Some of which is already
> possible but difficult for functions that need direct hardware access.
See
http://www.franz.com/support/documentation/8.0/doc/streams.htm
No hardware access necessary there.
> Think about, for example, being able to open a stream on an arbitrary
> DMA device.
Haven't done that one yet, but it shouldn't be too hard. Perhaps you
should get the Express edition of our lisp and try to figure out what
is missing?
>>> Although new drivers written in Lisp can use the existing runtime
>>> services, new runtime services cannot necessarily be written in
>>> Lisp.
Drivers generally have to fit into the language-centric view of the
hosting operating system. In unix, that would mostly be C. I haven't
tried this before (again, it's because there simply isn't any demand
for driver-level-functionality as higher priority than portability
across operating systems; most people would rather just go with a
driver that has been written by the os vendor or the hardware
manufacturer) but it most certainly can be done.
I'm sure that you'll say that NFS isn't a driver, per se, but check
out http://www.nfsforwindows.com/home - there is an example of a
service that hapens to be operating system specific (because it isn't
needed on other systems), and we got as close to the metal as we
needed to.
>>> The Lisp machines, and to a lesser extent Movitz, show that CL can
>>> be mated to and used successfully on a bare metal runtime package
>>> ... but that has never been in dispute. In my book that's not the
>>> same as saying CL can be used to program bare metal.
>>
>>I don't see why the distinction is important?
>
> The distinction for me is whether the language can be used directly
> express the required functionality in its own syntax and without the
> programmer resorting to linking libraries written in a different
> language, generating assembler code in memory, or writing a cross
> compiler, runtime and linker.
>
> As you say, no language higher than assembler is adequate to express
> _all_ the needed functionality, but the question is how close you can
> get. All I am claiming here is that Lisp needs a fair amount of
> support that can't be expressed directly as Lisp (and only
> incidentally that the amount Lisp needs is greater than what C needs).
At this year's ILC, I gave a tutorial that was Allegro CL specific.
The directory can be downloaded: ftp://ftp.franz.com/pub/duane/ilc07
In order to run the .lisp demo scripts, you have to use our emacs/lisp
interface with the contents of the dot-emacs.ilc07 file there, but
even if you don't you can still get an idea by just pasting each form
in the appropriate .lisp file into an Allegro CL listener.
If you look at the powerpoint presentation Opt-and-debug.ppt, you'll
find on slides 8-11 some references to "ll" code. This is code that
is in Lisp syntax; it is compiled by the Allegro CL compiler, and it
is meant to establish some level of portability to an assembler
facility. I know this is what you meant by targeting a runtime close
to the metal, but how much closer do you want to get than ll
instructions like "flush-windows" and "synch-instr-cache"? The
possibilities are endless, and the limits to closeness to the metal is
non-existent. See ll-doc.html for a list of current functions, some
available to the user and others only used and available to Franz
developers to build our runtime kernels.
> Contrary to what some people think, I don't hate Lisp (though I prefer
> Scheme to CL). But I have done quite a bit of bare metal programming
> and I also have a good idea of what runtime support is required to get
> a Lisp-like language running.
That experience gives you a blind spot, because it gives you the
overconfidence to assume that the way you did it is the way it has to
be done. That is not the case.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Ken Tilton
Subject: Re: What are the domains that lisp doesn't fit int?
Date:
Message-ID: <z%m%h.235$9D1.172@newsfe12.lga>
Duane Rettig wrote:
> [I guess I must join the fray here, after all. I was fighting the
> urge, but the level of misinformation/misunderstanding is much too
> high now, and some reality needs to be injected]
Damn, I was hoping you would speak to the Miscrosoft DLR and whether
anything as changed in re the years earlier determination that .NET
would not hunt for CL.
ken
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
Ken Tilton <···@theoryyalgebra.com> writes:
> Duane Rettig wrote:
>> [I guess I must join the fray here, after all. I was fighting the
>> urge, but the level of misinformation/misunderstanding is much too
>> high now, and some reality needs to be injected]
>
> Damn, I was hoping you would speak to the Miscrosoft DLR and whether
> anything as changed in re the years earlier determination that .NET
> would not hunt for CL.
Well, no; this is off-thread. And I don't know what I can add to the
other thread that hasn't already been said. Refer to Pascal's
comments there.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On 2007-05-05 05:26:51 -0400, George Neuner <·········@comcast.net> said:
> The point is that CL
true.
> (and Lisp in general) has no
> way to specify that code or data be placed at a particular address.
This is where you miss Kent's point that your definition of "lisp" is
unnecessarily restrictive. There is nothing in the semantics of lisp
that prevents a dialect from providing precisely that - the quarantee
that a particular lisp object remains at a particular memory address,
so that:
(with-pinned-objects (pinned-foo :type (:pointer :int) :address
#x15E0D1E0 :value foo) (bar :type :double :address bar-address :value
41.0d0) ...
would be perfectly acceptable lisp code. True, this is not part of the
common lisp standard, but there is nothing preventing implementations
from providing it.
On Sat, 5 May 2007 11:30:43 -0400, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
>On 2007-05-05 05:26:51 -0400, George Neuner <·········@comcast.net> said:
>
>> (and Lisp in general) has no
>> way to specify that code or data be placed at a particular address.
>
>This is where you miss Kent's point that your definition of "lisp" is
>unnecessarily restrictive. There is nothing in the semantics of lisp
>that prevents a dialect from providing precisely that - the quarantee
>that a particular lisp object remains at a particular memory address,
>so that:
I don't think my definition of Lisp is too restrictive.
>(with-pinned-objects (pinned-foo :type (:pointer :int) :address
>#x15E0D1E0 :value foo) (bar :type :double :address bar-address :value
>41.0d0) ...
>
>would be perfectly acceptable lisp code. True, this is not part of the
>common lisp standard, but there is nothing preventing implementations
>from providing it.
But the question is how do you implement with-pinned-objects in Lisp?
To say a language can be used on bare metal, I think the language must
be able directly express certain primitive operations - addressing
being one. Any language can make use of existing primitives that
supply the required functionality, but that reduces the role of the
language to scripting.
George
--
for email reply remove "/" from address
On 2007-05-06 01:26:29 -0400, George Neuner <·········@comcast.net> said:
> But the question is how do you implement with-pinned-objects in Lisp?
I think Duane Rettig's reply farther down the thread shows that Franz
is already doing it.
>
> To say a language can be used on bare metal, I think the language must
> be able directly express certain primitive operations - addressing
> being one.
Again, nothing stopping lisp from doing this.
> Any language can make use of existing primitives that
> supply the required functionality, but that reduces the role of the
> language to scripting.
If you can do something from *within* the langauge, then you are not
scripting some outside-the-language functionality. Again, see Duane's
post.
George Neuner wrote:
> To say a language can be used on bare metal, I think the language must
> be able directly express certain primitive operations - addressing
> being one. Any language can make use of existing primitives that
> supply the required functionality, but that reduces the role of the
> language to scripting.
You can express dereferencing in C by use of the * operator. You can
express it in the language accepted by SBCL's compiler using INT-SAP
and SAP-REF-32. You can't _implement_ it in either language using only
facilities provided by the language - in both cases, the compiler
recognises the tokens you type and generates machine code which has the
required effect.
CL-USER> (defun foo () (declare (optimize (speed 3))) (sb-sys:sap-ref-32
(sb-sys:int-sap #x400000) 0))
FOO
CL-USER> (disassemble 'foo)
; 02A3EA4C: B800004000 MOV EAX, 4194304 ;
no-arg-parsing entry point
; 51: 8B00 MOV EAX, [RAX]
; 53: 63D0 MOVSXD EDX, EAX
; 55: 48C1E203 SHL RDX, 3
; 59: 488D65F0 LEA RSP, [RBP-16]
; 5D: F8 CLC
; 5E: 488B6DF8 MOV RBP, [RBP-8]
; 62: C20800 RET 8
If you were under the impression that to access these facilities in Lisp
required a function call at runtime for each invocation, I could sort of
see your argument, but as you can see there, it doesn't. Just because
the SBCL way of doing it is more verbose, it doesn't follow that it's
further divorced from the hardware.
-dan
Daniel Barlow <···@coruskate.net> writes:
> George Neuner wrote:
>> To say a language can be used on bare metal, I think the language must
>> be able directly express certain primitive operations - addressing
>> being one. Any language can make use of existing primitives that
>> supply the required functionality, but that reduces the role of the
>> language to scripting.
>
> You can express dereferencing in C by use of the * operator.
True.
> You can
> express it in the language accepted by SBCL's compiler using INT-SAP
> and SAP-REF-32.
Given.
> You can't _implement_ it in either language using
> only facilities provided by the language
This doesn't follow. The CL spec allows for extensions, and does not
require language elements to be implemented within the language, so it
makes no sense to restrict extensions to be also implementable within
the language. In fact, The CL spec has very little to say on the
subject of implementation (except for some cases where an operator is
specified to behave _as_ _if_ defined a certain way), which makes it
by definition undefined, and thus extendable.
My argument follows the theory that CL (and more generally, Lisp) is
intended to be a language-implementation language, and thus at least
in theory a version of C could be "invented", written in CL, which does
not have the restriction that C has in that the results are not
guaranteed.
> - in both cases, the compiler
> recognises the tokens you type and generates machine code which has
> the required effect.
>
> CL-USER> (defun foo () (declare (optimize (speed 3)))
> (sb-sys:sap-ref-32 (sb-sys:int-sap #x400000) 0))
> FOO
> CL-USER> (disassemble 'foo)
> ; 02A3EA4C: B800004000 MOV EAX, 4194304 ;
> no-arg-parsing entry point
> ; 51: 8B00 MOV EAX, [RAX]
> ; 53: 63D0 MOVSXD EDX, EAX
> ; 55: 48C1E203 SHL RDX, 3
> ; 59: 488D65F0 LEA RSP, [RBP-16]
> ; 5D: F8 CLC
> ; 5E: 488B6DF8 MOV RBP, [RBP-8]
> ; 62: C20800 RET 8
Your case about the SBCL primitive is made.
> If you were under the impression that to access these facilities in
> Lisp required a function call at runtime for each invocation, I could
> sort of see your argument, but as you can see there, it doesn't.
I don't know how requiring a function call makes any difference.
SBCL obviously doesn't require it, and Allegro CL's memref functions,
while defined as functions, aren't required to be compiled as a
function (it generally compiles to inline code as well), but even if
you were to imagine another implementation that had functions called
foo:peek and foo:poke, with no it would be a perfectly legal
extension of CL.
> Just
> because the SBCL way of doing it is more verbose, it doesn't follow
> that it's further divorced from the hardware.
I agree here.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Daniel Barlow <···@coruskate.net> writes:
>> You can express dereferencing in C by use of the * operator.
>
> True.
>
>> You can
>> express it in the language accepted by SBCL's compiler using INT-SAP
>> and SAP-REF-32.
>
> Given.
>
>> You can't _implement_ it in either language using
>> only facilities provided by the language
>
> This doesn't follow.
Wasn't supposed to ;-) That was the third assertion, not the conclusion
from the first two. All I was trying to get across is that, contrary to
George Neuner's apparent[*] argument, being able to express an operation
in some language X does not *require* being able to implement it using
only other features of that same language.
>> If you were under the impression that to access these facilities in
>> Lisp required a function call at runtime for each invocation, I could
>> sort of see your argument, but as you can see there, it doesn't.
>
> I don't know how requiring a function call makes any difference. [...]
> even if
> you were to imagine another implementation that had functions called
> foo:peek and foo:poke, with no it would be a perfectly legal
> extension of CL.
It would be a legal extension of CL, but for the kinds of scenario that
I think George has in mind (low-level bit banging) a less useful one -
if you wanted, for example, to build a new frame on the program's own
call stack using these facilities, you would rather not have it change
while you're doing so. It'd also (I imagine) be quite a lot slower,
which might be a big deal for some kinds of system programming.
[*] I may have misunderstood George's point: "primitive" is an
ill-defined term at the best of times, and it seems to me that he's
using it in two different ways at the same time. This is not aiding my
comprehension any.
-dan
Daniel Barlow <···@coruskate.net> writes:
> Duane Rettig wrote:
>> Daniel Barlow <···@coruskate.net> writes:
>>> You can express dereferencing in C by use of the * operator.
>> True.
>>
>>> You can
>>> express it in the language accepted by SBCL's compiler using INT-SAP
>>> and SAP-REF-32.
>> Given.
>>
>>> You can't _implement_ it in either language using
>>> only facilities provided by the language
>> This doesn't follow.
>
> Wasn't supposed to ;-) That was the third assertion, not the
> conclusion from the first two.
I guess I was thinking of it differently; perhaps I should have
said "This doesn't make sense". But it looks like we at least
headed in the same direction:
> All I was trying to get across is
> that, contrary to George Neuner's apparent[*] argument, being able to
> express an operation in some language X does not *require* being able
> to implement it using only other features of that same language.
This is essentially what I was saying, which seemed to contradict your
assertion that "You can't...". I can see why you said it, but defining
such primitives _as_ _extensions_ to your implementation is in fact
completely allowed by the language - therefore you _can_ have such
primitives be a part of the language. It is partially the reason why
we implementors are not forced to use phrases like "our implementation
of Common Lisp plus FFI/Unicode/MOP/... extensions", because the
language itself defines the extents of portability and conformance in
a very careful way so as not to overly restrict extensions.
>>> If you were under the impression that to access these facilities in
>>> Lisp required a function call at runtime for each invocation, I could
>>> sort of see your argument, but as you can see there, it doesn't.
>> I don't know how requiring a function call makes any
>> difference. [...]
>> even if
>> you were to imagine another implementation that had functions called
>> foo:peek and foo:poke, with no it would be a perfectly legal
>> extension of CL.
>
> It would be a legal extension of CL, but for the kinds of scenario
> that I think George has in mind (low-level bit banging) a less useful
> one -
> if you wanted, for example, to build a new frame on the program's own
> call stack using these facilities, you would rather not have it change
> while you're doing so. It'd also (I imagine) be quite a lot slower,
> which might be a big deal for some kinds of system programming.
Yes, of course, but any imaginary foo:peek (or especially foo:poke)
implementor would want to either build those assumptions into the
promitives, or document the caveats well.
> [*] I may have misunderstood George's point: "primitive" is an
> ill-defined term at the best of times, and it seems to me that he's
> using it in two different ways at the same time. This is not aiding
> my comprehension any.
Agreed.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Frode Vatvedt Fjeld
Subject: Re: What are the domains that lisp doesn't fit int?
Date:
Message-ID: <2hbqgz9yu1.fsf@vserver.cs.uit.no>
George Neuner <·········@comcast.net> writes:
> If I am mistaken then I apologize ... when last I looked at the
> [Movitz] documentation, it stated that the kernel (as opposed to the
> Lisp image running above the kernel) provided only very simple
> management. It appeared that drivers and other kernel services
> could not use GC.
This is a misunderstanding, presumably resulting from my own
less-than-perfect writings. There is no such thing as a special
"kernel service" or "driver" mode in Movitz where the run-time
environment is restricted in any way. One design goal of Movitz is
that the run-time is to allow the programmer to do whatever he wants
in terms of using the hardware resources (memory, CPU paging, CPU
segmentation, perhipheral devices, etc) for whatever he wants (while
still programming "natural", unrestricted CL), much as he is free to
do with traditional C-based kernel programming.
To this end, for GC specifically, this is achieved partly by defining
a protocol (or plug-in API if you will) for memory allocation, and
partly by elaborate rules for GC safety which ensure that a GC can
safely happen at any time (i.e. while an interrupt handler is
running). The result, although not thoroughly proven in practice, is
that there is great freedom wrt. how memory is managed.
> As you say, no language higher than assembler is adequate to express
> _all_ the needed functionality, but the question is how close you
> can get. All I am claiming here is that Lisp needs a fair amount of
> support that can't be expressed directly as Lisp (and only
> incidentally that the amount Lisp needs is greater than what C
> needs).
I still don't see why this is important. Also, I'm not entirely sure
you are correct in your last claim here: C defines one operation which
CL lacks, namely read and write to an explicit memory address. The
accessor "memref" does this in Movitz and I think other some other CL
implementations also. Such an operator, while not standardized in ANSI
CL, I would expect allows almost all "support code" to be expressed in
Lisp.
--
Frode Vatvedt Fjeld
From: Lars Brinkhoff
Subject: Re: What are the domains that lisp doesn't fit int?
Date:
Message-ID: <85ps5fusgc.fsf@junk.nocrew.org>
George Neuner wrote:
> The point is that CL (and Lisp in general) has no way to specify
> that code or data be placed at a particular address.
There's no way to specify that in Standard C, is there?
Lars Brinkhoff wrote:
> George Neuner wrote:
>> The point is that CL (and Lisp in general) has no way to specify
>> that code or data be placed at a particular address.
>
> There's no way to specify that in Standard C, is there?
That's no problem:
int* somewhere = (int*) 0x0bad;
somewhere[0] = 42;
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Lars Brinkhoff
Subject: Re: What are the domains that lisp doesn't fit int?
Date:
Message-ID: <85k5vnujua.fsf@junk.nocrew.org>
Frank Buss wrote:
> Lars Brinkhoff wrote:
> > George Neuner wrote:
> > > The point is that CL (and Lisp in general) has no way to specify
> > > that code or data be placed at a particular address.
> > There's no way to specify that in Standard C, is there?
>
> That's no problem:
> int* somewhere = (int*) 0x0bad;
> somewhere[0] = 42;
Now specify where to place the variable somewhere. Or a function.
On Sat, 05 May 2007 21:54:53 +0200, Lars Brinkhoff
<·········@nocrew.org> wrote:
>Frank Buss wrote:
>> Lars Brinkhoff wrote:
>> > George Neuner wrote:
>> > > The point is that CL (and Lisp in general) has no way to specify
>> > > that code or data be placed at a particular address.
>> > There's no way to specify that in Standard C, is there?
>>
>> That's no problem:
>> int* somewhere = (int*) 0x0bad;
>> somewhere[0] = 42;
>
>Now specify where to place the variable somewhere. Or a function.
Obviously you can't place the variable that names (points to) the
place - C won't let you do that. What it does allow is deliberate
mapping of an arbitrary contiguous data structure at any valid data
address (subject to hardware alignment restrictions). The pointer to
the data structure need not be a named variable - the address can be
hard coded (or a C macro):
struct stupid { double d; char str[10]; int i; }
strcpy( ((struct stupid*)0xbad).str, "hello");
Normally one places functions using the linker - it may not be
possible to do it in C because the language makes no guarantees that
valid code addresses overlap valid data addresses ... the two sets may
be disjoint on any particular platform. Where it is possible (which
is to say on most CPUs - the offenders tend to be MPUs and DSPs) you
can place a function by finding its address and copying the code to a
placed byte/character array of sufficient length.
The trick is to find the extent of the code you want to copy - C lets
you get the address of a function but there is no way to get its code
length. Since you can't create new functions at run time (at least
not without doing assembly to memory) the easiest way is to look at
the linker output and then hard code the function length in the
copying function.
Another trick that sometime works is to take the difference between
the address of the function you want to copy and one that follows it.
The reason it works is that most linkers don't rearrange static
functions within a compilation unit (file), the link records are
generally in the same order as the definitions in the source.
static int f ( ... ) { ... }
static void g ( ... ) { ... }
:
char* target = (char*) 0xBAD;
// better hope target array is big enough !!!
memcpy( target, &f, (size_t) &g - &f );
:
Anyway this has nothing to do with Lisp so we should stop here.
George
--
for email reply remove "/" from address
Lars Brinkhoff wrote:
>> That's no problem:
>> int* somewhere = (int*) 0x0bad;
>> somewhere[0] = 42;
>
> Now specify where to place the variable somewhere. Or a function.
I think this is not possible with standard C, but usually you don't need it
(only while compiling and loading a program). But accessing memory
addresses is needed very often in driver development.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Lars Brinkhoff wrote:
>
>> George Neuner wrote:
>>> The point is that CL (and Lisp in general) has no way to specify
>>> that code or data be placed at a particular address.
>> There's no way to specify that in Standard C, is there?
>
> That's no problem:
>
> int* somewhere = (int*) 0x0bad;
> somewhere[0] = 42;
I haven't seen my copy of K&R in a while so can't check this, but my
recollection is that this code is essentially undefined (or
implementation-defined, or whatever): the standard only says what
happens for pointers that are (a) within an object (or one past its
highest bound), or (b) 0
Am I misremembering? Maybe someone with the spec would check
-dan
Daniel Barlow <···@coruskate.net> writes:
> Frank Buss wrote:
>> Lars Brinkhoff wrote:
>>
>>> George Neuner wrote:
>>>> The point is that CL (and Lisp in general) has no way to specify
>>>> that code or data be placed at a particular address.
>>> There's no way to specify that in Standard C, is there?
>>
>> That's no problem:
>>
>> int* somewhere = (int*) 0x0bad;
>> somewhere[0] = 42;
>
> I haven't seen my copy of K&R in a while so can't check this, but my
> recollection is that this code is essentially undefined (or
> implementation-defined, or whatever): the standard only says what
> happens for pointers that are (a) within an object (or one past its
> highest bound), or (b) 0
>
> Am I misremembering? Maybe someone with the spec would check
No you aren't. But people like to compare apples to oranges.
--
__Pascal Bourguignon__ http://www.informatimago.com/
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
On Sat, 05 May 2007 23:27:35 +0100, Daniel Barlow <···@coruskate.net>
wrote:
>Frank Buss wrote:
>
>> int* somewhere = (int*) 0x0bad;
>> somewhere[0] = 42;
>
>I haven't seen my copy of K&R in a while
K&R is hopelessly out of date. Just about every C compiler now
follows the C89 spec. A couple even follow C99.
>so can't check this, but my
>recollection is that this code is essentially undefined (or
>implementation-defined, or whatever): the standard only says what
>happens for pointers that are (a) within an object (or one past its
>highest bound), or (b) 0
>
>Am I misremembering? Maybe someone with the spec would check
It is implementation defined. The spec says that a pointer can be set
to any address which is valid for the target data type, but hard
coding any address other than zero is not portable.
George
--
for email reply remove "/" from address
Daniel Barlow wrote:
> I haven't seen my copy of K&R in a while so can't check this, but my
> recollection is that this code is essentially undefined (or
> implementation-defined, or whatever): the standard only says what
> happens for pointers that are (a) within an object (or one past its
> highest bound), or (b) 0
>
> Am I misremembering? Maybe someone with the spec would check
The code is defined, but the result is implementation-defined. 6.3.2.3 (5)
of the ISO/IEC 9899:1999 standard says:
| An integer may be converted to any pointer type. Except as previously
| specified [NULL-pointer], the result is implementation-defined, might not
| be correctly aligned, might not point to an entity of the referenced type,
| and might be a trap representation.
That's better than with Common Lisp, because with this defition of the
standard you can write code, which accesses memory addresses (e.g. for
driver development) and chances are good, that it works with other C
compilers on the same system, too, because the syntax is the same.
In Common Lisp there is no such definition for accessing memory addresses.
Of course, some implementations may provide functions for it, but chances
are good, that names and semantics are different for different
implementations.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Raymond Wiker
Subject: Re: What are the domains that lisp doesn't fit int?
Date:
Message-ID: <m2y7k2l6gi.fsf@RawMBP.local>
Frank Buss <··@frank-buss.de> writes:
> Daniel Barlow wrote:
>
>> I haven't seen my copy of K&R in a while so can't check this, but my
>> recollection is that this code is essentially undefined (or
>> implementation-defined, or whatever): the standard only says what
>> happens for pointers that are (a) within an object (or one past its
>> highest bound), or (b) 0
>>
>> Am I misremembering? Maybe someone with the spec would check
>
> The code is defined, but the result is implementation-defined. 6.3.2.3 (5)
> of the ISO/IEC 9899:1999 standard says:
>
> | An integer may be converted to any pointer type. Except as previously
> | specified [NULL-pointer], the result is implementation-defined, might not
> | be correctly aligned, might not point to an entity of the referenced type,
> | and might be a trap representation.
>
> That's better than with Common Lisp, because with this defition of the
> standard you can write code, which accesses memory addresses (e.g. for
> driver development) and chances are good, that it works with other C
> compilers on the same system, too, because the syntax is the same.
>
> In Common Lisp there is no such definition for accessing memory addresses.
In what way does this differ from C? The fact that you have a
syntax that looks like it "ought" to work, but has no guarantees of
actually working, does not make C different from Common Lisp...
> Of course, some implementations may provide functions for it, but chances
> are good, that names and semantics are different for different
> implementations.
Exactly as the case would be for C.
Raymond Wiker wrote:
> Frank Buss <··@frank-buss.de> writes:
>
>> In Common Lisp there is no such definition for accessing memory addresses.
>
> In what way does this differ from C? The fact that you have a
> syntax that looks like it "ought" to work, but has no guarantees of
> actually working, does not make C different from Common Lisp...
I hope it sounds like splitting hairs :-) The difference is, that the
ISO/IEC 9899:1999 standard defines a syntax for it, and the Common Lisp
standard doesn't.
Another point is that you are right, there is no guarantee that it works in
C, but in nearly all C implementations it does, especially when compiling
for the same OS and CPU.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> Raymond Wiker wrote:
>
>> Frank Buss <··@frank-buss.de> writes:
>>
>>> In Common Lisp there is no such definition for accessing memory addresses.
>>
>> In what way does this differ from C? The fact that you have a
>> syntax that looks like it "ought" to work, but has no guarantees of
>> actually working, does not make C different from Common Lisp...
>
> I hope it sounds like splitting hairs :-) The difference is, that the
> ISO/IEC 9899:1999 standard defines a syntax for it, and the Common Lisp
> standard doesn't.
Huh? Syntax? There are two ways you can look at this: Either Common
Lisp defines no syntax for anything, and the issue becomes the "when
did you stop beating your wife?" question, or else it defines the
syntax for everything, to wit: "(<operator> <argument> ...)".
Want an example? Most CLs define such primitives. In Allegro CL:
CL-USER(1): 'a
A
CL-USER(2): :i *
A NEW The symbol A @ #x715e55e7
which is an INTERNAL symbol in the COMMON-LISP-USER package
0 type ---------> Bit field: #x07
1 flags --------> Bit field: #x00
2 package ------> The COMMON-LISP-USER package
3 value --------> ..unbound..
4 function -----> ..funbound..
5 hash ---------> Bit field: #x6f5750
6 name ---------> A simple-string (1) "A"
7 plist --------> The symbol NIL
CL-USER(3): (sys:memref-int #x715e55e7 -7 0 :lisp)
"A"
CL-USER(4):
[Addresses and offsets are architecture and instance-specific;
your mileage will vary]
This operator is also setf-able (which is highly dangerous (hence the
lack of high levels of promotion of this operator):
CL-USER(4): (setf (sys:memref-int #x715e55e7 -7 0 :lisp) "B")
"B"
CL-USER(5): :i
A NEW The symbol CL-USER::B @ #x715e55e7
which is an NIL symbol in the COMMON-LISP-USER package
0 type ---------> Bit field: #x07
1 flags --------> Bit field: #x00
2 package ------> The COMMON-LISP-USER package
3 value --------> ..unbound..
4 function -----> ..funbound..
5 hash ---------> Bit field: #x6f5750
6 name ---------> A simple-string (1) "B"
7 plist --------> The symbol NIL
CL-USER(6):
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Huh? Syntax? There are two ways you can look at this: Either Common
> Lisp defines no syntax for anything, and the issue becomes the "when
> did you stop beating your wife?" question, or else it defines the
> syntax for everything, to wit: "(<operator> <argument> ...)".
Maybe "syntax" was the wrong word for Lisp. What I mean is that in C it is
defined, that an integer can be converted to a pointer (which implies a
specific syntax, like casting to an int poiner). This pointer can then be
used to access memory, but it might not work.
In the Common Lisp Standard, like available e.g. here:
http://www.lispworks.com/documentation/HyperSpec/Front/index.htm there is
nothing like direct memory access described.
Of course, most Lisp implementation can access memory, (with different
functions or macros for it, because there is no function for it defined in
the Standard), which are used e.g. for CFFI, so I'm just splitting hairs
:-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
> Duane Rettig wrote:
>
>> Huh? Syntax? There are two ways you can look at this: Either Common
>> Lisp defines no syntax for anything, and the issue becomes the "when
>> did you stop beating your wife?" question, or else it defines the
>> syntax for everything, to wit: "(<operator> <argument> ...)".
>
> Maybe "syntax" was the wrong word for Lisp.
Yup.
> What I mean is that in C it is
> defined, that an integer can be converted to a pointer (which implies a
> specific syntax, like casting to an int poiner). This pointer can then be
> used to access memory, but it might not work.
Yes.
> In the Common Lisp Standard, like available e.g. here:
> http://www.lispworks.com/documentation/HyperSpec/Front/index.htm
Of course - I prefer:
http://www.franz.com/support/documentation/8.0/ansicl/ansicl.htm
:-)
> there is
> nothing like direct memory access described.
Right. But there is also nothing precluding it. The spec gives ample
opportunity for an implementation to create extensions for itself as
long as these extensions don't conflict with things that are specified
in the standard. Thus, being undefined (i.e. unrestricted) is a Good
Thing, because that means there is no preclusion of such extensions by
each of the implementations.
> Of course, most Lisp implementation can access memory, (with different
> functions or macros for it, because there is no function for it defined in
> the Standard), which are used e.g. for CFFI, so I'm just splitting hairs
> :-)
I guess when we next see each other in person, I'll be easily able to
spot you (you'll be the one with all of the split-ends :-)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Raymond Wiker
Subject: Re: What are the domains that lisp doesn't fit int?
Date:
Message-ID: <m2mz0fkykt.fsf@RawMBP.local>
Frank Buss <··@frank-buss.de> writes:
> Duane Rettig wrote:
>
>> Huh? Syntax? There are two ways you can look at this: Either Common
>> Lisp defines no syntax for anything, and the issue becomes the "when
>> did you stop beating your wife?" question, or else it defines the
>> syntax for everything, to wit: "(<operator> <argument> ...)".
>
> Maybe "syntax" was the wrong word for Lisp. What I mean is that in C it is
> defined, that an integer can be converted to a pointer (which implies a
> specific syntax, like casting to an int poiner). This pointer can then be
> used to access memory, but it might not work.
This is just silly... you have a mechanism for converting
between pointers and integers that may or may not work, for any given
combination of platform, compiler and the values you try to
convert. This is neither portable or dependable. Further, even if it
did work consistently it might not do what you wanted - for example,
in the presence of a memory mapping unit.
I think you'll find that (most?) operating systems provide
low-level calls for direct access to memory that takes care of all
the details, including bypassing the MMU. In some cases, the calls may
even have been open-coded in the STANDARD compiler used with that os.
This is of course just as true for an OS written in LISP as in
C :-)
From: Kent M Pitman
Subject: Re: What are the domains that lisp doesn't fit int?
Date:
Message-ID: <ubqh8bsya.fsf@nhplace.com>
Dan Bensen <··········@cyberspace.net> writes:
> fireblade wrote:
> > What are ... domains where lisp doesn't fit in?
>
> Drivers: close to the metal.
> Embedding: Poor memory resources.
These are not problems with Lisp as a generic language paradigm. They
are issues with specific implementations and/or dialects, and while
certainly valid as issues to discuss ought to be seen as opportunities
to bring Lisp to new areas. Certainly if you're looking for
off-the-shelf solutions, that's trickier. But, for example, some work
in other dialects (e.g., ISLISP) had the intention of being useful to
things like drivers and embedding, almost in specific concern that CL
had left this area inappopriately covered. But those two dialects don't
exhaust the space of potential Lisp endeavor.
Le Fri, 27 Apr 2007 18:46:05 -0500, Dan Bensen a écrit:
>> What are ... domains where lisp doesn't fit in?
> Drivers: close to the metal.
> Embedding: Poor memory resources.
Well, maybe you should read "Program Mobile Robots in Scheme", by
Jonathan Rees and Bruce Donald.
They used Scheme (they based their work on the scheme48 implementation)
to program robots, not close to the metal but on the bare metal, AFAIK,
and with "scarce on-board resources", to cite the paper.
Fittingly,
Pierre
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
On Sun, 29 Apr 2007 08:48:55 +0000 (UTC), Pierre THIERRY
<···········@levallois.eu.org> wrote:
>Le Fri, 27 Apr 2007 18:46:05 -0500, Dan Bensen a �crit:
>>> What are ... domains where lisp doesn't fit in?
>> Drivers: close to the metal.
>> Embedding: Poor memory resources.
>
>Well, maybe you should read "Program Mobile Robots in Scheme", by
>Jonathan Rees and Bruce Donald.
>
>They used Scheme (they based their work on the scheme48 implementation)
>to program robots, not close to the metal but on the bare metal, AFAIK,
>and with "scarce on-board resources", to cite the paper.
Technically they used PreScheme which is a statically typed dialect
with dynamic allocation but no GC. Additionally it compiles into C
which requires minimal bootstrap support to get running on metal.
George
--
for email reply remove "/" from address
Le Sun, 29 Apr 2007 12:19:13 -0400, George Neuner a écrit:
> Technically they used PreScheme which is a statically typed dialect
> with dynamic allocation but no GC.
Not quite. PreScheme is a subset of Scheme, so any PreScheme program is
a valid Scheme one, AFAIK.
> Additionally it compiles into C which requires minimal bootstrap
> support to get running on metal.
That how they did it, that's not inherent to the language. Like ECL that
compiles to C and SBCL to native code.
Quickly,
Pierre
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
On Mon, 30 Apr 2007 12:21:15 +0000 (UTC), <···········@levallois.eu.org> wrote:
> Le Sun, 29 Apr 2007 12:19:13 -0400, George Neuner a �crit:
>> Technically they used PreScheme which is a statically typed dialect
>> with dynamic allocation but no GC.
>
> Not quite. PreScheme is a subset of Scheme, so any PreScheme program is
> a valid Scheme one, AFAIK.
Additionally, his statement is flat wrong. Read the article to see
that GC is not only present, but generational GC is planned. There is
a section discussing the time tradeoffs of GC.
Lisp Haters still zeros, how long can this nohitter go on? ;-)
--
There are no average Common Lisp programmers
Reply-To: email is ignored.
--
Posted via a free Usenet account from http://www.teranews.com
On Mon, 30 Apr 2007 13:44:12 -0700, GP lisper
<········@CloudDancer.com> wrote:
>On Mon, 30 Apr 2007 12:21:15 +0000 (UTC), <···········@levallois.eu.org> wrote:
>> Le Sun, 29 Apr 2007 12:19:13 -0400, George Neuner a �crit:
>>> Technically they used PreScheme which is a statically typed dialect
>>> with dynamic allocation but no GC.
>>
>> Not quite. PreScheme is a subset of Scheme, so any PreScheme program is
>> a valid Scheme one, AFAIK.
>
>Additionally, his statement is flat wrong. Read the article to see
>that GC is not only present, but generational GC is planned. There is
>a section discussing the time tradeoffs of GC.
Like you would know.
For the record: I knew Richard Kelsey during the time of the mobile
robot project, which was shortly after he had written the PreScheme
compiler and while he was working with Rees developing Scheme48. The
hardware interface code and the virtual machine level of the robot
software was written in PreScheme (see "A Tractable Scheme
Implementation"). The paper Pierre cited described higher level
software to be written in regular Scheme targeting the robot's virtual
machine.
>Lisp Haters still zeros, how long can this nohitter go on? ;-)
Also for the record: I don't hate Lisp ... I just prefer Scheme.
George
--
for email reply remove "/" from address
fireblade <·················@gmail.com> writes:
> I just finished reading Anti Patterns Refactoring Software
> Architectures,and it hint me that i'm regularly singing gospels to
> lisp being a universal hummer for every kind of problem. Once in a
> while somebody ask's what is lisp bad for? I basically have only two
> ideas:
> 1.Talking with c++ (Possible but not recommended, due to c++
> idiosyncrasy )
> 2. Erlang/Termite like processes (i wonder how many processes could
> scieener support?)
This is wrong. These things are unrelated to lisp. Its actually very
easy to talk in lisp about C++ or Erlang like processes.
Perhaps it would take some time to write a library or a lisp
implementation where it's easy and efficient to communicate with C++
or to create a log of lightweight processes, but this question is
totally unrelated to the lisp language(s).
> What are the other domains where lisp doesn't fit in?
Speaking about inexpressible things?
--
__Pascal Bourguignon__ http://www.informatimago.com/
"What is this talk of "release"? Klingons do not make software
"releases". Our software "escapes" leaving a bloody trail of
designers and quality assurance people in its wake."
On Apr 27, 7:02 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> fireblade <·················@gmail.com> writes:
> > I just finished reading Anti Patterns Refactoring Software
> > Architectures,and it hint me that i'm regularly singing gospels to
> > lisp being a universal hummer for every kind of problem. Once in a
> > while somebody ask's what is lisp bad for? I basically have only two
> > ideas:
> > 1.Talking with c++ (Possible but not recommended, due to c++
> > idiosyncrasy )
> > 2. Erlang/Termite like processes (i wonder how many processes could
> > scieener support?)
>
> This is wrong. These things are unrelated to lisp. Its actually very
> easy to talk in lisp about C++ or Erlang like processes.
>
> Perhaps it would take some time to write a library or a lisp
> implementation where it's easy and efficient to communicate with C++
> or to create a log of lightweight processes, but this question is
> totally unrelated to the lisp language(s).
Maybe you're right about processes ,I need to check thoroughly for
myself but talking to c++ is hard and more important ugly IMHO.
bobi
PS *
The Authors of the book Anti Patterns spread quite of anti lisp
propaganda.
1. In the LISP language, as in many others, certain pure−evil
programmers exist who take great
glee in leveraging the “side effects” of certain language functions to
mysteriously perform key
functionality in their systems. Analysis and understanding of such
systems is virtually
impossible, and any attempt at reuse is considered insane.
2. There is one piece of code that we suspect has been cloned
repeatedly throughout several
organizations and probably is still cloned today. This piece of code
has been observed
several hundred times across dozens of organizations. It is a code
file that implements a
linked−list class without the use of templates or macros. Instead, the
data structure stored by
the linked list is defined in a header file, so each linked list is
customized to operate only on
the specified data structure. Unfortunately, the original author of
the code (rumor has it he
was originally a LISP programmer) introduced a flaw in the linked−list
code: It failed to free
the memory of an item when it was deleted; instead, it just rearranged
the pointers.
3.
The Lambda Calculus is a relatively straightforward theory about the
mathematics of
functions and variable substitutions. It is one of the important
theories underlying the
Lisp programming language and is taught at selected universities in
undergraduate
computer science courses. People with this training often assume that
everybody
knows about Lambda Calculus. This leads to misunderstandings that may
be instances
of INTELLECTUAL VIOLENCE.
PS. **
Sorry for the confusion but when i say lisp i always mean common lisp,
when a want to speak about all the lisps i use lisp family of
languages.
On May 2, 10:37 am, fireblade <·················@gmail.com> wrote:
> On Apr 27, 7:02 pm, Pascal Bourguignon <····@informatimago.com> wrote:
>
>
>
>
>
> > fireblade <·················@gmail.com> writes:
> > > I just finished reading Anti Patterns Refactoring Software
> > > Architectures,and it hint me that i'm regularly singing gospels to
> > > lisp being a universal hummer for every kind of problem. Once in a
> > > while somebody ask's what is lisp bad for? I basically have only two
> > > ideas:
> > > 1.Talking with c++ (Possible but not recommended, due to c++
> > > idiosyncrasy )
> > > 2. Erlang/Termite like processes (i wonder how many processes could
> > > scieener support?)
>
> > This is wrong. These things are unrelated to lisp. Its actually very
> > easy to talk in lisp about C++ or Erlang like processes.
>
> > Perhaps it would take some time to write a library or a lisp
> > implementation where it's easy and efficient to communicate with C++
> > or to create a log of lightweight processes, but this question is
> > totally unrelated to the lisp language(s).
>
> Maybe you're right about processes ,I need to check thoroughly for
> myself but talking to c++ is hard and more important ugly IMHO.
> bobi
>
> PS *
> The Authors of the book Anti Patterns spread quite of anti lisp
> propaganda.
>
> 1. In the LISP language, as in many others, certain pure−evil
> programmers exist who take great
> glee in leveraging the “side effects” of certain language functions to
> mysteriously perform key
> functionality in their systems. Analysis and understanding of such
> systems is virtually
> impossible, and any attempt at reuse is considered insane.
>
> 2. There is one piece of code that we suspect has been cloned
> repeatedly throughout several
> organizations and probably is still cloned today. This piece of code
> has been observed
> several hundred times across dozens of organizations. It is a code
> file that implements a
> linked−list class without the use of templates or macros. Instead, the
> data structure stored by
> the linked list is defined in a header file, so each linked list is
> customized to operate only on
> the specified data structure. Unfortunately, the original author of
> the code (rumor has it he
> was originally a LISP programmer) introduced a flaw in the linked−list
> code: It failed to free
> the memory of an item when it was deleted; instead, it just rearranged
> the pointers.
>
What language are you talking about c++?
> 3.
> The Lambda Calculus is a relatively straightforward theory about the
> mathematics of
> functions and variable substitutions. It is one of the important
> theories underlying the
> Lisp programming language and is taught at selected universities in
> undergraduate
> computer science courses. People with this training often assume that
> everybody
> knows about Lambda Calculus. This leads to misunderstandings that may
> be instances
> of INTELLECTUAL VIOLENCE.
>
> PS. **
>
> Sorry for the confusion but when i say lisp i always mean common lisp,
> when a want to speak about all the lisps i use lisp family of
> languages.- Hide quoted text -
>
> - Show quoted text -
On May 2, 11:47 am, ·················@gmail.com wrote:
> On May 2, 10:37 am, fireblade <·················@gmail.com> wrote:
>
>
>
>
>
> > On Apr 27, 7:02 pm, Pascal Bourguignon <····@informatimago.com> wrote:
>
> > > fireblade <·················@gmail.com> writes:
> > > > I just finished reading Anti Patterns Refactoring Software
> > > > Architectures,and it hint me that i'm regularly singing gospels to
> > > > lisp being a universal hummer for every kind of problem. Once in a
> > > > while somebody ask's what is lisp bad for? I basically have only two
> > > > ideas:
> > > > 1.Talking with c++ (Possible but not recommended, due to c++
> > > > idiosyncrasy )
> > > > 2. Erlang/Termite like processes (i wonder how many processes could
> > > > scieener support?)
>
> > > This is wrong. These things are unrelated to lisp. Its actually very
> > > easy to talk in lisp about C++ or Erlang like processes.
>
> > > Perhaps it would take some time to write a library or a lisp
> > > implementation where it's easy and efficient to communicate with C++
> > > or to create a log of lightweight processes, but this question is
> > > totally unrelated to the lisp language(s).
>
> > Maybe you're right about processes ,I need to check thoroughly for
> > myself but talking to c++ is hard and more important ugly IMHO.
> > bobi
>
> > PS *
> > The Authors of the book Anti Patterns spread quite of anti lisp
> > propaganda.
>
> > 1. In the LISP language, as in many others, certain pure−evil
> > programmers exist who take great
> > glee in leveraging the “side effects” of certain language functions to
> > mysteriously perform key
> > functionality in their systems. Analysis and understanding of such
> > systems is virtually
> > impossible, and any attempt at reuse is considered insane.
>
> > 2. There is one piece of code that we suspect has been cloned
> > repeatedly throughout several
> > organizations and probably is still cloned today. This piece of code
> > has been observed
> > several hundred times across dozens of organizations. It is a code
> > file that implements a
> > linked−list class without the use of templates or macros. Instead, the
> > data structure stored by
> > the linked list is defined in a header file, so each linked list is
> > customized to operate only on
> > the specified data structure. Unfortunately, the original author of
> > the code (rumor has it he
> > was originally a LISP programmer) introduced a flaw in the linked−list
> > code: It failed to free
> > the memory of an item when it was deleted; instead, it just rearranged
> > the pointers.
>
> What language are you talking about c++?
They never mentioned the language but templates or macros, probably C+
+.
>
>
>
> > 3.
> > The Lambda Calculus is a relatively straightforward theory about the
> > mathematics of
> > functions and variable substitutions. It is one of the important
> > theories underlying the
> > Lisp programming language and is taught at selected universities in
> > undergraduate
> > computer science courses. People with this training often assume that
> > everybody
> > knows about Lambda Calculus. This leads to misunderstandings that may
> > be instances
> > of INTELLECTUAL VIOLENCE.
>
> > PS. **
>
> > Sorry for the confusion but when i say lisp i always mean common lisp,
> > when a want to speak about all the lisps i use lisp family of
> > languages.- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
On May 2, 10:37 am, fireblade <·················@gmail.com> wrote:
> The Authors of the book Anti Patterns spread quite of anti lisp
> propaganda.
>
> 1. In the LISP language, as in many others, certain pure−evil
> programmers exist who take great
> glee in leveraging the “side effects” of certain language functions to
> mysteriously perform key
> functionality in their systems. Analysis and understanding of such
> systems is virtually
> impossible, and any attempt at reuse is considered insane.
>
Crup lispers are famous for functional programming.
> 2. There is one piece of code that we suspect has been cloned
> repeatedly throughout several
> organizations and probably is still cloned today. This piece of code
> has been observed
> several hundred times across dozens of organizations. It is a code
> file that implements a
> linked−list class without the use of templates or macros. Instead, the
> data structure stored by
> the linked list is defined in a header file, so each linked list is
> customized to operate only on
> the specified data structure. Unfortunately, the original author of
> the code (rumor has it he
> was originally a LISP programmer) introduced a flaw in the linked−list
> code: It failed to free
> the memory of an item when it was deleted; instead, it just rearranged
> the pointers.
Why would someone you somebody unproven library if their language
supports
excellent implementation of common lisp.
> 3.
> The Lambda Calculus is a relatively straightforward theory about the
> mathematics of
> functions and variable substitutions. It is one of the important
> theories underlying the
> Lisp programming language and is taught at selected universities in
> undergraduate
> computer science courses. People with this training often assume that
> everybody
> knows about Lambda Calculus. This leads to misunderstandings that may
> be instances of INTELLECTUAL VIOLENCE.
Working with cruppy languages is far bigger intellectual violence.You
have to do this in php because everybody else is working in php.
It's weird that all the lispers i know are also good programmers in c/c
++/java while none of the c/c++/java programmers doesn't know writing
in lisp (top is i tried some scheme at the university but didn't
like it).The bottom point is does your bookstore offer returning your
money ?
Antoan
"fireblade" <·················@gmail.com> wrote in message
····························@r3g2000prh.googlegroups.com...
>I just finished reading Anti Patterns Refactoring Software
> Architectures,and it hint me that i'm regularly singing gospels to
> lisp being a universal hummer for every kind of problem. Once in a
> while somebody ask's what is lisp bad for? I basically have only two
> ideas:
> 1.Talking with c++ (Possible but not recommended, due to c++
> idiosyncrasy )
> 2. Erlang/Termite like processes (i wonder how many processes could
> scieener support?)
>
> What are the other domains where lisp doesn't fit in?
>
I suspect, as a new Lisper, that Lisp is the language of choice when you
don't know the degree of recursion in your data structures, but a poor
competitor when you do. If you know the full structure in advance, then an
array and indirection-type language will be simpler and faster.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
From: Don Geddis
Subject: Re: What are the domains that lisp doesn't fit int?
Date:
Message-ID: <87ps5ofmrx.fsf@geddis.org>
"Malcolm McLean" <·········@btinternet.com> wrote on Sat, 28 Apr 2007:
> I suspect, as a new Lisper, that Lisp is the language of choice when you
> don't know the degree of recursion in your data structures, but a poor
> competitor when you do.
Your suspicion is incorrect, and due purely to your lack of experience.
> If you know the full structure in advance, then an array and
> indirection-type language will be simpler and faster.
You're also confused that Lisp only supports recursion. In fact the most
popular dialect, Common Lisp, is explicitly a multi-paradigm language. EVEN
IF array access is a "simpler and faster" implementation for some algorithm,
you can program directly in that style in any standard Common Lisp. It's all
built in already.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
If I ever get real rich, I hope I'm not real mean to poor people, like I am
now. -- Deep Thoughts, by Jack Handey
From: Ken Tilton
Subject: Re: What are the domains that lisp doesn't fit int?
Date:
Message-ID: <BGLYh.13$5Z6.10@newsfe12.lga>
[WARNING: This is not a flame. My fans may want to read no further.]
Malcolm McLean wrote:
>
> "fireblade" <·················@gmail.com> wrote in message
> ····························@r3g2000prh.googlegroups.com...
>
>> I just finished reading Anti Patterns Refactoring Software
>> Architectures,and it hint me that i'm regularly singing gospels to
>> lisp being a universal hummer for every kind of problem. Once in a
>> while somebody ask's what is lisp bad for? I basically have only two
>> ideas:
>> 1.Talking with c++ (Possible but not recommended, due to c++
>> idiosyncrasy )
>> 2. Erlang/Termite like processes (i wonder how many processes could
>> scieener support?)
>>
>> What are the other domains where lisp doesn't fit in?
>>
> I suspect, as a new Lisper, that Lisp is the language of choice when you
> don't know the degree of recursion in your data structures, but a poor
> competitor when you do. If you know the full structure in advance, then
> an array and indirection-type language will be simpler and faster.
>
(a) Lisp is like New York City. I lived there for thirty years but never
called myself a New Yorker.
(b) That is pretty good, I think you described yourself instead of Lisp.
Allow me to ghostwrite: As someone still merely standing on the shores
of the vast Lisp mud pond, you only think of Lisp when looking at hairy
algorithms, otherwise it is simpler for you to use the language you know, C.
After twelve years of Lisp something I might do in C I do instead in
Lisp rather than deal with that nutty C syntax, and partly because C is
fine at data structure recursion, whatever that is.
hth, kenny
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
On Apr 27, 3:14 pm, fireblade <·················@gmail.com> wrote:
> What are the other domains where lisp doesn't fit in?
You might get better responses if you ask "What problems are other
languages better for?"
The whole point of having such powerful macros as lisp is that you can
steal any programming paradigm you like, but for some problems another
language may be a good enough fit with out the need for modification.
On Apr 27, 10:14 pm, fireblade <·················@gmail.com> wrote:
> I just finished reading Anti Patterns Refactoring Software
> Architectures,and it hint me that i'm regularly singing gospels to
> lisp being a universal hummer for every kind of problem. Once in a
> while somebody ask's what is lisp bad for? I basically have only two
> ideas:
> 1.Talking with c++ (Possible but not recommended, due to c++
> idiosyncrasy )
> 2. Erlang/Termite like processes (i wonder how many processes could
> scieener support?)
>
> What are the other domains where lisp doesn't fit in?
>
Beware of the Turing tarpit in which everything is possible but
nothing of interest is easy.
--Alan Perlis
Le Fri, 27 Apr 2007 07:14:28 -0700, fireblade a écrit:
> 1.Talking with c++ (Possible but not recommended, due to c++
> idiosyncrasy )
As I'm interested myself in interfacing Common Lisp and C++, what do you
see as the problem?
C++ uses the C/Fortran calling convention, so existing FFI to it are
usable. You need name mangling, of course, but nothing in C++ idioms
should prevent anything, AFAICT.
Curiously,
Pierre
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
On Apr 29, 10:40 am, Pierre THIERRY <···········@levallois.eu.org>
wrote:
> Le Fri, 27 Apr 2007 07:14:28 -0700, fireblade a écrit:
>
> > 1.Talking with c++ (Possible but not recommended, due to c++
> > idiosyncrasy )
>
> As I'm interested myself in interfacing Common Lisp and C++, what do you
> see as the problem?
>
> C++ uses the C/Fortran calling convention, so existing FFI to it are
> usable. You need name mangling, of course, but nothing in C++ idioms
> should prevent anything, AFAICT.
>
Possible but very hard, it takes a lot of time to write good C
wrappers and they are just wrappers, i didn't feel very lispy when i'm
using them ,especially when the c++ code uses a lot C++ specific staff
while you're calling it from c . You loose some speed (~30% from my
own humble experience) and you end up with ugly hybrid.
It's possible (my lost code for Truevision engine is a prove) but
not something i would like to build a nice app on it.
When i get back to gamesi woud either build lisp engine with OpenGl
or use some c or c# driven one, c++ is a no no.
bobi
Le Wed, 02 May 2007 00:51:26 -0700, fireblade a écrit:
> Possible but very hard, it takes a lot of time to write good C
> wrappers and they are just wrappers, i didn't feel very lispy when i'm
> using them
Why would you add C between C++ and Lisp? Why not map the C++ functions
to their Lisp equivalent? (constructor, destructor, methods, all could
find a counterpart, maybe with a specific C++ metaclass)
Curiously,
Pierre
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
On May 2, 1:54 pm, Pierre THIERRY <···········@levallois.eu.org>
wrote:
> Le Wed, 02 May 2007 00:51:26 -0700, fireblade a écrit:
>
> > Possible but very hard, it takes a lot of time to write good C
> > wrappers and they are just wrappers, i didn't feel very lispy when i'm
> > using them
>
> Why would you add C between C++ and Lisp? Why not map the C++ functions
> to their Lisp equivalent? (constructor, destructor, methods, all could
> find a counterpart, maybe with a specific C++ metaclass)
>
> Curiously,
> Pierre
> --
> ···········@levallois.eu.org
> OpenPGP 0xD9D50D8A
Pierre you either never interfaced Lisp with c++ or you know something
that i don't know. Lisp implementations I've tried have a FFI only to
c,
so if you want to interface c++ code you need c wrappers or c linkage.
http://www.lispworks.com/documentation/lw445/FLI/html/fli-54.htm
4.5.2 Using C++ DLLs
You must make the exported names match the FLI definitions. To do
this:
If you can alter the C++ code, wrap extern " C " {} around the C++
function definitions, or
Create a second DLL with C functions that wrap around each C++
function, and make those C functions accessible as described in Using
C DLLs.
Note: watch out for the calling convention of the exported function,
which must match the :calling-convention in the FLI definitions.
On Fri, 27 Apr 2007 07:14:28 -0700, fireblade wrote:
> I just finished reading Anti Patterns Refactoring Software
> Architectures,and it hint me that i'm regularly singing gospels to
> lisp being a universal hummer for every kind of problem. Once in a
> while somebody ask's what is lisp bad for? I basically have only two
> ideas:
> 1.Talking with c++ (Possible but not recommended, due to c++
> idiosyncrasy )
> 2. Erlang/Termite like processes (i wonder how many processes could
> scieener support?)
>
> What are the other domains where lisp doesn't fit in?
In the hope of being proven wrong, I'd say that if not impossible, it
would be pretty painful for hard realtime control. Anywhere where there
are good reasons for the abstraction of memory that lisp gives you to be a
bad idea. (I have done lots of work where the abstraction of memory that
C gives you is a bad idea, and the only recourse is native assembly
code.) I concede that it is probably possible to write interrupt handlers
in lisp that perform no new memory allocations, but it would probably feel
a lot like writing Fortran, rather than lisp, thus defeating the point...
Cheers,
--
Andrew
Andrew Reilly <···············@areilly.bpc-users.org> writes:
> On Fri, 27 Apr 2007 07:14:28 -0700, fireblade wrote:
>> What are the other domains where lisp doesn't fit in?
>
> In the hope of being proven wrong, I'd say that if not impossible, it
> would be pretty painful for hard realtime control. Anywhere where there
SCADALisp is a (soft) real-time Lisp for QNX.
--
Eirik Mikkelsen