On Mon, 18 Oct 2004 17:31:05 -0500 (CDT), Michel Pelletier <[EMAIL PROTECTED]> wrote: > > The second PIR sequence is longer. It will take > > IMCC more time to > > compile that than the first example. As the > > words become less trivial, > > this will become more true. > > But one can't weigh the compile-time overhead > against the run-time overhead like that. What > if your inner loop runs for many days when > compilation of the NCG code takes only a couple > of milliseconds more?
Hence my statement: > > So it may be programs can fall on either side of the fence of this > > issue. Building words in terms of other words will give NCG an > > advantage. But using relatively simple words many times will give > > direct threading an advantage. But I do believe you when you say that > > NCG is fastest overall (read, for most programs). > Well that's a good question because I haven't > dont it yet. The simple hack aproach is to > pattern replace back to back PUSH/POP pairs > right out with string search and replace. I > estimate this could eliminate up to half of the > data stack traffic on average, depending on the > code of course. Right. I'm not used to thinking without regexes. `index` and `substr` can be used for this. > The whole-hog way to do it would be to have a > stack data analysis algorithm try to cache as > much of the stack in P registers as possible, > spilling when necessary. This could probably > eliminate almost all stack data traffic except > for extremely pathological cases. I'm not /that/ interested in speed. > The Python interpreter could use this method too > to really spank CPython, which has implicit > stack traffic that cannot be easily optimized > out. Here I'd be interested in it. :) But this assumes the Python implementation will be stack based. Just because CPython is doesn't mean Parrot Python will be, does it? > > Furthermore, our two models will behave > > differently when you redefine > > a word. Consider this Forth example: > > > > : inc 1 + ; > > : print+ inc . ; > > : inc 2 + ; > > > > Should print+ increment by one or by two? gforth > > increments by one. > > I"ve made a pretty big mistake so far by calling > indirect threading direct threading. The > lookup/invoke sequence is really indirect > threading. Direct threading would be if we > could somehow compile into PIR a literal > "pointer" to a sub instead of having to look it > up by name. I don't think this can be done. I think it can. (Sorry for being so argumentative. :-) The get_integer_keyed method gets the address of an Eval PMC at the moment, IIRC. (This was used for the previous Forth implementation.) GC might be a problem though. Emulation could be done too, but I doubt that's desirable. > In the case of words defined with ":" and ";" > even NCG still does indirect threading via a > lookup and invoke, NCG only inlines CORE word > definitions, words that are defned in PIR and > form the basis for all high level words, but the > high level words themselves are indirect > threaded. Ahh... okay, that makes a bit more sense (or at least it did, I'm not sure I remember why). It would actually be easier to inline all words though, as you wouldn't have to treat core words differently (and it makes it easier to redefine them). > > I'd be interesting in knowing which was the > > "correct" behavior. > > I suspect it is implementation defined, but > unfortunately taygeta.com is not working for me > right now. Gotcha. -- matt
