David Hanley <·····@nospan.netright.com> wrote:
> > No immediate values in polymorphic data
> > (most importantly, tagged pointers and fixnums),
>
> True, but most CPU's don't have that either.
What I mean is the ability to use pointers such that some bit patterns can
be recognized and used by the system as immediate values. On most system,
you can easily allocate objects on 4-byte (or even better 8-byte) boundaries,
and thus use the lower bits of pointers as type tags for immedates (and
possibly also for the object referenced by the pointer, though that's not as
important as immediate fixnums).
> > no reliable tail calling
> > across compilation units (merely allowed for some cases),
>
> Is this important, however?
As far as I'm concerned, yes. If you want to conform to R4R-Scheme, you
need tail calls (though you could get away without separate compilation,
but even if your users would tolerate that, compiling everything as one big
procedure isn't possible in the JVM due to some size limitations, and you'll
lose anyway).
> > no overflow
> > detection on primitive types,
>
> This is an issue, but not an imposible one.
I'm not talking about "impossible", but about poor performance in a JVM
implementation (unlikely to be optimized beyond typical Java usage). All
integer operations where the compiler cannot statically prove that the
operands _and_ the result will be fixnum does need this. It must be cheap
in the non-overflow case and still reasonably efficient for bignums (and
preferably not cause much code bloat).
> > no call by value,
>
> What do you mean, in this context? The java VM is always call by
> value.
Only for pointers and primitive types, not for composite objects (records
or whatever you'd like to call them). Many cases with a variable number of
arguments and/or return values shouldn't need heap allocation.
> > no multiple inheritance
> > (interfaces just won't do it),
>
> How is this important for lisp compilation?
It would help with implementing CLOS efficiently.
> > no dispatch on multiple arguments.
>
> Again, I don't know of any chip which supports this in hardware. You
> have to simulate it in any case.
Yes, but typical processors provide much better support for this than the
limitations of the JVM with required static checking for Java's type system,
and without much facilities for address manipulation, clever code layout, and
storing data in the code.
> The right ay is to perform optimizations on lisp code
> which make it fit well in the VM.
This will work to a degree for complete programs of limited complexity,
but beyond that, you simply need to do some thing efficiently at run time.
Being able to do so is part of what makes Lisp so expressive. Have you
ever looked at sophisticated code using the power of CLOS? If you can
optimize this statically (and with decent compilation times), fine, but
in many cases, I doubt it. (In case my doubts are wrong, I'd like to
read something about your optimizer, and I'm sure many researchers will
be interested, too ;-)
-- Marc Wachowitz <··@ipx2.rz.uni-mannheim.de>