Hello Mattias, >> Yes, I suggest a run-time optimization step "with no going back" >> where all FFdefer word calls would be reprogrammed to reach >> immediately the FFdefer destination (skip the FFdefer word call). > > I think it's not necessary to have a special (defer) runtime, the > developer can do that as well. A global runtime check would consume > all speed enhancements, I'm afraid. > > Haven't tested it, but the following code should at least > come close (and works with all kind of defer's) > > \ Edefer hi > \ ' ver is hi > \ ' hi defer:seal > > : defer:seal ( XT -- ) > dup defer@ swap > dup ['] quit @i ( get DO_COLON) swap !i > 1+ dup rot swap !i > 1+ ['] exit swap !i > ;
I'm confused, please explain how this works... Aren't we supposed to patch the Edefer caller, not its callee? Thanks, Enoch. ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
