At 2:41 PM -0700 on 5/2/99, Alain Farmer wrote:
>DeRobertis : Due to the vast number of cross-TOC calls, memory
>accesses, and instruction-cache reloads, it actually runs slower than
>the interpreter. Yes, the cross-TOC calls, memory accesses, and cache
>reloads could be eliminated, in which case it would beat the
>interpreter.
>
>Alain : There is hope then ?
There is hope for four months of work.
>
>DeRobertis : And finding the evaluation bug would be nice, too. But
>this would require: (1) some serious MacsBug work to find the bug; (2)
>a register allocator; (3) a complete analysis of the HT code, keeping
>track of variable types & usage; (4) and more.
>
>Alain : I don't presume to understand everything you are saying above,
>but I nevertheless appreciate your detailed analysis, and the
>consequent presentation of what needs to be done to solve it.
Basicly, it'd need to more efficiently make use of the on-chip memory on the PPC and
figure out the types of variables in OpenTalk. That is, it'd need to know (to a
reasonable extent) if x is an integer, a real, or text at any given line of code. Or
at least at most of them.
>DeRobertis : We don't have 4 months to wait around while I try to get
>together a nice compiler.
>
>Alain : We could use the MetaCard engin and/or its compiler, couldn't
>we ?
Depending on what that licence with MetaCard Corp. says.
>DeRobertis : Besides, the JITC is such a mess that it'd probably get
>Uli to hire an assassin for me.
>
>Alain : Messy code is definitely a no-no.
Unfortunately, I don't think there is much that can be done to make a JITC look good.
Other than perhaps a bison-like tool for making compiler backends.
>Alain : What "archive" folder do you speak of ?
There is a folder called "archive" in the interpreter snapshots.
