ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/09/90)
Category 18, Topic 67 Message 3 Tue Aug 07, 1990 D.RUFFER [Dennis] at 23:03 EDT Re: boris@prodigal.psych.rochester.edu (Boris "cull" Goldowsky) > I've got an application where the definitions of words may be > changed many times, and I'd like the new definition to actually > replace the old one rather than simply being tacked on for future > use. Although, as Mitch mentioned, Forth does not contain any "standard" way to recover space from selected definitions, you can simulate the feature in just about any Forth. Define a "buffer" for each definition that you want to be able to redefine. Something like this: 256 CONSTANT MAX-BUFFER ( -- n P: Largest definition ) : FOO ; MAX-BUFFER ALLOT Note that I do not include the definition header in the FOO buffer. This is to prevent a looping link structure that I can't think of any other way to solve right now. Then you need a way to redefine the word. You could redefine : if you want, but I'll choose a name like this: : REDEFINE HERE ' >BODY DUP H ! ] MAX-BUFFER + HERE < ABORT" Exceeded buffer" H ! ; Of course, this may not work with all Forths, especially those who do already have memory recovery schemes. Also, if you do get the error message, it is likely that you will not be able to recover since the next definition's header has been corrupted. However, if you are just looking for something simple and you don't have a large set of definitions that need to be redefined, this might just suite your needs. I should also warn you that I just typed this in off the top of my head. If you have trouble with it, IT DOES NOT WORK! So don't hold me liable for any damages resulting from its use. :-) DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ir230@sdcc6.ucsd.edu (john wavrik) (08/25/90)
Re vectored execution, I asked: >> II. Deferred Execution >> Will the proposed ANSI standard have a portable mechanism for >> deferred execution (like the F83 words DEFER and IS) Mitch Bradley replied: > : DEFER CREATE 0 , DOES> @ EXECUTE ; > : SET-DEFER ( cfa cfa -- ) >BODY ! ; I assume that this means that the ANSI Standard does not provide a mechanism for vectored execution and that Mitch is showing how one can be defined. (Such a mechanism was not in the last BASIS document I have and has apparently not been provided since.) Mitch's approach is essentially a dressing up of the fig-Forth approach: store the cfa of a word in a variable, and later execute the contents of the variable. ---- Vectored execution is one of the areas mentioned in the TC document posted by Jack Brown. There is a good reason for wanting words (like DEFER and IS) for vectored execution to be part of the language standard rather than user defined. Here are some timings for 100,000 executions of a NOOP -- both directly and using various approaches to vectored execution: BARE NOOP 2.25 seconds FIG APPROACH 3.79 seconds BRADLEY APPROACH 4.89 seconds F83 APPROACH 2.69 seconds In F83 the mechanism for vectored execution is coded in assembly language -- and the overhead for executing a word indirectly is surprisingly small. ---- I asked whether a simple non-exotic Forth application written to answer a question of Wil Baden could be written in the proposed ANSI Standard. Specifically: 1. Can the return stack be extended to make recursion viable? 2. Is there a Standard mechanism for deferred execution? 3. Can the user control compilation enough to define a simple control-flow structure? I would like to thank for Mitch Bradley for replying. As he has shown, the answer is a discouraging NO on all points. Now that the ANSI Team perceives itself to be near completion, it would be a good time to test the proposed Standard to find out whether or not it is missing essential ingredients. I don't share the view of those who think that an ANSI Standard is "window dressing" and is not supposed to support real programming. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093
andrew@idacom.uucp (Andrew Scott) (08/28/90)
John Wavrik writes: > There is a good reason for wanting words (like > DEFER and IS) for vectored execution to be part of the language > standard rather than user defined. Here are some timings for 100,000 > executions of a NOOP -- both directly and using various approaches to > vectored execution: [ timing figures deleted ] > In F83 the mechanism for vectored execution is coded in assembly > language -- and the overhead for executing a word indirectly is > surprisingly small. I don't think execution speed of a word in a certain implementation is a compelling reason to include it in the standard. I think that optimization is a job best left for the compiler and not the language designer. For the same reason, I think words like 1+ and 1- should at least be moved from CORE to EXT CORE. They unnecessarily clutter the language. I realize they have existed for many years and are noticably faster in *some* Forth implementations. I think it's a wart to make addition or subtraction by 1 a special case. It's another wrinkle a newcomer to Forth has to learn. Anyway, the EXT CORE word PERFORM is useful for vectored execution: VARIABLE ACTION ( our execution vector ) ' SOMETHING ACTION ! ( assign something to the vector ) ACTION PERFORM ( execute the vector ) I prefer this to the DEFER and IS solution because of the prefix-postfix reasons we've been discussing for a while. -- Andrew Scott | mail: andrew@idacom.uucp | - or - .!uunet!ubc-cs!alberta!idacom!andrew
UNBCIC@BRFAPESP.BITNET (03/29/91)
> One merit of forth is, indeed, it's ability to define ANYTHING to > do something else (and with vectored execution, you can even, in > some cases, redefine it after the system is loaded and get > all the words that were defined with the original definition > to use the new one. Do that with C!) If I rememeber well: int ( *nome ) (); nome = puts(); nome("hello/n"); nome = printf(); nome("hello/n); (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET