On Mon, 14 Aug 2000, Larry Wall wrote:
> Dan Sugalski writes:
> : On Mon, 14 Aug 2000, Larry Wall wrote:
> :
> : > Dan Sugalski writes:
> : > : The big problem here is the large number of operators that need to
> : > : be supported in every vtable. On the other hand, it means we whittle
> : > : ourselves down to only one operator opcode. ;-)
> : >
> : > I don't care if the program is half vtables, as long as it runs fast.
> :
> : It shall run fast if I have to chase it with a stick. (maybe I should just
> : give up now and go with the single opcode "dwim" and be done with it...)
> :
> : How much of the current base of target ports are you willing to give up in
> : the first cut for fast? The TIL suggestion, amongst others, has the
> : potential to speed things up rather a lot, but it has the disadvantage of
> : requiring intimate knowledge of each target port. My preference is to get
> : a snappy interpreter and leave the Java JIT-equivalents to the various
> : chip/OS vendors, but I'd bet the TIL style would be faster.
>
> I *thought* I was taking TIL into account with the design of Perl 5.
> In fact, I think Ilya almost got it to work. But there were a lot of
> things that snuck in as the design evolved that made it difficult. My
> current thinking is that if we're going to seriously consider TIL then
> we'd durn well better do at least one TIL implementation in parallel or
> we'll inadvertently design ourselves out of the capability. Again.
>
> On the other hand, targeting JVM and IL.NET might keep us honest enough.
Hmmm. Looks like we need to split off several backend groups, then, or at
least yank a few in to do side implementations while the reference
interpreter's getting put together. Rather premature for that, but one for
the big timeline.
Do you, by any chance, have an off-hand list of the things that shot down
TILing perl 5?
Dan
