Re: Compilation Was: Is DEFCONSTANT broken?

On Jun 25, 1:28 am, p...@xxxxxxxxxxxxxxxxx (Pascal J. Bourguignon)
wrote:
Duane Rettig <du...@xxxxxxxxx> writes:
The problem here is that the whole reason for
compilation is to reduce code complexity, and having these hooks to
break these simplifications goes against the goal of compilation.  

This surprize me.

I thought that the purpose of compilation was foremost to optimize
speed.

No, although that's usually a by-product, and thus the user tends to
make that a goal.

I'm not sure that it reduces code complexity.  For a start, assembler
is harder to read than high level language.

Harder for whom or what? It's certainly easier to read for the
executing machine. And we're not talking about readability, but
complexity. And, by the way, assembler code is not compiled code; it
is also source code which must be assembled in order to execute
directly on a machine. You might consider assembler to be equivalent
to machine code, because you usually have excellent disassembling
tools, which reintroduce the complexities of mnemonic names,
connections between jump instructions and their target labels
(remember, though, that labels don't actually exist in machine code -
they are just instructions which happen to be the target of the jump).

 Then the compiler may
open code, inline, unroll loops, and implement any other kind of trick
which dilutes abstractions a lot, which I understand as rendering the
code more complex, not less.

Actually, quite the opposite. A loop is more complex than straight-
line code; it has a branch instruction within it, which is well-
understood to create pipeline stalls, unless the hardware has the
added complexity itself to duplicate effort in order to perform branch
prediction. No, the simplest code is the fully-unrolled loop which
executes no branches, but which simply performs the required
instructions. Is it necessarily optimal? No, because code size does
factor into the mix, and so the fact that loops are only unrolled
partially is due to tradeoffs between code complexity and instruction
cache size.

Perhaps you mean that the target virtual machine is usually simplier
(a single memory vector, a few registers, a few instructions to move
bits),  than the CL virtual machine (with special operators and
notions that are more sophisticated and intertwined).

Yes, of course.

But the code itself, by consequence of this difference of complexity
of the virtual machines, must be more complex on the simplier VM, at
least when generated by a compiler trying to optimize anything but
readability of the assembler code.

Readability is _not_ the antithesis of complexity. They are on two
different planes.

Duane

.

Relevant Pages

  • Compilation Was: Is DEFCONSTANT broken?
    ... break these simplifications goes against the goal of compilation. ... I'm not sure that it reduces code complexity. ... Perhaps you mean that the target virtual machine is usually simplier ...
    (comp.lang.lisp)
  • Re: Compilation Was: Is DEFCONSTANT broken?
    ... compilation is to reduce code complexity, ... break these simplifications goes against the goal of compilation. ... And, by the way, assembler code is not compiled code; ... they are just instructions which happen to be the target of the jump). ...
    (comp.lang.lisp)
  • Re: Compilation Was: Is DEFCONSTANT broken?
    ... break these simplifications goes against the goal of compilation. ... We fight complexity with abstractions. ... instructions. ... level to low level is one of increasing simplicity. ...
    (comp.lang.lisp)
  • Re: object file size is reduced after build
    ... LOC without requiring a great deal of complexity. ... pre-process the source - this saves headaches with comments ... and conditional compilation and stuff; ... and compile for pure code (i.e. no debuggery, ...
    (comp.lang.c)
  • Re: Compilation Was: Is DEFCONSTANT broken?
    ... compilation is to reduce code complexity, ... There's money in compilers? ...  And, by the way, assembler code is not compiled code; it ... they are just instructions which happen to be the target of the jump). ...
    (comp.lang.lisp)