I've recently gone from Lisp (back) to assembly language to do some
'fun' stuff I haven't done in a long time. I've been looking at a few
samples of Lisp object code (disassemble in sbcl) and found some pretty
cryptic code.
Is it true to say that Lisp produces more complex and/or cryptic code
than, say, C/C++ and other languages that can compile direct to ML?
It depends on your optimization settings. Remember, Lisp takes care of
types for you. So, something as simple as:
(defun add (a b)
(+ a b))
can produce lots of assembly code; it has to handle adding integers,
reals, complex numbers, .... However, now try:
(defun add-optimized (a b)
(declare (fixnum a b))
(the fixnum (+ a b)))
Now that is looking much better and there is still debugging
information in there, so you can declare even more (optimize 3),
(safety 0), (debug 0), and now you're starting to get extremely close
to C.
Jeff M.
"jonathon" <···········@bigfoot.com> writes:
> I've recently gone from Lisp (back) to assembly language to do some
> 'fun' stuff I haven't done in a long time. I've been looking at a few
> samples of Lisp object code (disassemble in sbcl) and found some pretty
> cryptic code.
>
> Is it true to say that Lisp produces more complex and/or cryptic code
> than, say, C/C++ and other languages that can compile direct to ML?
No. The Python compiler on x86 certainly does produce some cryptic
code, particularly when it's not optimizing for speed. The Allegro
compiler on SPARC produces quite readable code. Python on RISC
architectures is somewhere in between, as I assume would be Allegro's
compiler on x86.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
From: Duane Rettig
Subject: Re: Lisp object code versus that of other languages
Date:
Message-ID: <4wtm27b3x.fsf@franz.com>
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> "jonathon" <···········@bigfoot.com> writes:
>
>> I've recently gone from Lisp (back) to assembly language to do some
>> 'fun' stuff I haven't done in a long time. I've been looking at a few
>> samples of Lisp object code (disassemble in sbcl) and found some pretty
>> cryptic code.
>>
>> Is it true to say that Lisp produces more complex and/or cryptic code
>> than, say, C/C++ and other languages that can compile direct to ML?
>
> No. The Python compiler on x86 certainly does produce some cryptic
> code, particularly when it's not optimizing for speed. The Allegro
> compiler on SPARC produces quite readable code. Python on RISC
> architectures is somewhere in between, as I assume would be Allegro's
> compiler on x86.
In general, our disassemblers produce instruction formats in a format
closely compatible with the hardware manufaturer's recommended formats.
So much so that I sometimes post disassembled code to comp.arch and
the engineers there have no trouble understanding it.
As for what the compiler produces - I've spoken many years ago
about the insufficiency of standard "C calling conventions" for
efficient compiled CL code. That said, however, to the extent
practical we do follow most of those protocols, even when Lisp
is calling Lisp, and we only enhance what is necessary for
efficient Lisp calling. This is also borne out by the ease in
which non-Lispers understand the disassembled code from Allegro CL's
compiler, and can, for example, recognize a standard function entry
sequence on an x86 as well as any architecture.
jonathon wrote:
> I've recently gone from Lisp (back) to assembly language to do some
> 'fun' stuff I haven't done in a long time. I've been looking at a few
> samples of Lisp object code (disassemble in sbcl) and found some pretty
> cryptic code.
>
> Is it true to say that Lisp produces more complex and/or cryptic code
> than, say, C/C++ and other languages that can compile direct to ML?
If it's of interest to you, you can read the C output of GCL without
_too_ much difficulty.
Rob Thorpe wrote:
> jonathon wrote:
> > I've recently gone from Lisp (back) to assembly language to do some
> > 'fun' stuff I haven't done in a long time. I've been looking at a few
> > samples of Lisp object code (disassemble in sbcl) and found some pretty
> > cryptic code.
> >
> > Is it true to say that Lisp produces more complex and/or cryptic code
> > than, say, C/C++ and other languages that can compile direct to ML?
>
> If it's of interest to you, you can read the C output of GCL without
> _too_ much difficulty.
I'd consider myself an experienced C programmer, and I can honestly say
that I find GCL's output deeply confusing. You may differ, of course. :)
Nathan Baum wrote:
> Rob Thorpe wrote:
> > jonathon wrote:
> > > I've recently gone from Lisp (back) to assembly language to do some
> > > 'fun' stuff I haven't done in a long time. I've been looking at a few
> > > samples of Lisp object code (disassemble in sbcl) and found some pretty
> > > cryptic code.
> > >
> > > Is it true to say that Lisp produces more complex and/or cryptic code
> > > than, say, C/C++ and other languages that can compile direct to ML?
> >
> > If it's of interest to you, you can read the C output of GCL without
> > _too_ much difficulty.
>
> I'd consider myself an experienced C programmer, and I can honestly say
> that I find GCL's output deeply confusing. You may differ, of course. :)
Yes, I think it's confusing, it might be a bit better than assembly
from others though. I haven't seen the assembly SBCL produces so I
can't comment on whether it's worse.
<···········@bigfoot.com> wrote:
> I've recently gone from Lisp (back) to assembly language to do some
> 'fun' stuff I haven't done in a long time. I've been looking at a few
> samples of Lisp object code (disassemble in sbcl) and found some pretty
> cryptic code.
Since the SBCL code generator basically works by concatenating
assembly templates, and currently doesn't do much post-processing
(like instruction scheduling or peephole optimizing) on the result, I
usually find it more understandable than what an optimizing C compiler
produces. Your mileage may vary.
If some code seems cryptic, you might find the SBCL-specific
:TRACE-FILE keyword to COMPILE-FILE useful. For example (compile-file
"foo.lisp" :trace-file t) will produce a file "foo.trace" that
contains representations of the code in the two intermediate languages
that the compiler uses internally. There's also an annotated
disassembly that shows which intermediate language instructions are
producing the assembly instructions. Like this:
L23:
VOP ALLOCATE-FULL-CALL-FRAME {5} => t32[RBX]
MOV #<TN t32[RBX]>, #<TN t22[RSP]>
SUB #<TN t22[RSP]>, 40
VOP MOVE-ARG 'MOOSE!33[Const7]>t34[RDX] t32[RBX] => t35[RDX]
MOV #<TN t34[RDX]>, #<TN 'MOOSE!33[Const7]>
VOP MOVE-ARG t36[Const6]>t37[RDI] t32[RBX] => t38[RDI]
MOV #<TN t37[RDI]>, #<TN t36[Const6]>
--
Juho Snellman
"Premature profiling is the root of all evil."
"jonathon" <···········@bigfoot.com> writes:
> I've recently gone from Lisp (back) to assembly language to do some
> 'fun' stuff I haven't done in a long time. I've been looking at a few
> samples of Lisp object code (disassemble in sbcl) and found some pretty
> cryptic code.
Here is some information on CMUCL:
Reading disassembly output
http://www.cons.org/cmucl/doc/reading-disassembly.html
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface