[A86] Re: What about LISP?


[Prev][Next][Index][Thread]

[A86] Re: What about LISP?




> Van: David West <bdaddy_mit@hotmail.com>
> 
> >From: David Reiss <davidr42@optonline.net>
> >
> >On Wed, Dec 19, 2001 at 05:43:35AM +0000, David West wrote:
> >
> > > I agree with the first part. As for the "and interpreted environment
> > > ... too slow for anything usefull". Once again this statement somehow
> > > assumes that interpretation adds unmanagable overhead.
> >
> >Perhaps I was too harsh in my last message: the overhead of an on-calc
> >interpreter is not unmanagable and doesn't disqualify the project by any
> >means. But the origin of this thread, IIRC, was about a new language
> >that could produce code just about as fast as hand-written assembly. My
> >point was that no Scheme syetem (interpreter or compiled) would do that.
> >That's not to say it wouldn't be useful for things other than games,
> >like text-based programs, symbolic manipulators (as someone else
> >pointed out), etc.
>
> Intuatively I tend to agree with you, but I'm still searching for the 
> deductive reason this has to be the case?  That is I suppose I want to
> know why I can't have my cake and eat it too...  (Why we can't have a
> powerfull high-level interpreted language and at the same time do all
> the things we can do in assembly)  The answer everyone seems to
> give(myself included) is that with assembly you have access to the
> processor directly.  But why can't we come up with a language that
> has really fast assembly-like primitives but at the same time maintains
> the protection and expressive capabilities of a high-level (interpreted
> or not) language.

I think that would need to you to define exactly what goes on inside the
interpreter (or compiled code) else you won't be able to write anything in
assembly that will intergrates into the language. So not only define how
routines return values, but also what register "+" returns in, etc.

But this creates about the same problem as with compiling Ti-BASIC: "when
do we need Ans?". I mean that (without 'difficult' codeing inside the
compiler) you can't be shure when you can optimize or not. A possibility is
to just always calculate 'Ans' (return ints/pointers in HL, doubles in
DEHL, chars in A, etc.). But most of the time it's just overhead to move
(LD or EX) the answer into a certain register since the next routine will
move it into another one again.

Interpreters won't be able to make a speed advantage of these slight
optimizations. The overhead of the forward looking routine is far bigger
than the slight speed improvement. Another option would be a 'Java styled'
real-time optimizations of the interpreted language I think the Z80 is too
slow for something like that (the overhead is too big).

	Henk Poley <><