What ANS Forth misses /was: Fix Forth, please
Author |
Message |
M.L.Gassanenk #1 / 24
|
What ANS Forth misses /was: Fix Forth, please
I have started an ordinary follow-up, but it turned to a new channel. ==== Quote:
> C compiliers are written in C. It is perfectly possible > for a C programmer to change the compiler, just harder to do. > But isn't any program harder to write in C than it is in Forth? > I don't think this is the problem. C programmers are not > interesting in changing the compiler, they are interested in > following K&R or ANS C. This is a very clear difference > between C programmers and Forth programmers. Why should that > be?
Because extending the compiler is the normal way of programming in Forth. Forth is almost useless without that (its program elements can reflect problem notions, and there are many techniques to reach this effect). Many ways to extend the compiler will work on any Forth, others will not. The ANSI standard imposes severe restrictions on the ways one could use to have his program elements match the problem notions. Only in Forth and Assembler (I mean Koopman's TIGRE) tricks may lead to something useful. In other languages hacking does not lead to so much impressing results. Quote: > The ANS Forth standard has lots of options. If you want > to write something as big as Kermit in Forth and have it > run on all the possible ANS Forth systems, you are going > to have the same problem Kermit has with all the different > C compilers and operating calls. The solution is to have > tighter standards with no options. This is something Forth > programmers are unwilling to accept.
There are options for programmers and options for implementors. More for these, less for those, and vice versa. ANS Forth leaves more options for implementors and restricts programmers. Some optimization techniques for Forth are really incorrect optimizations (such as fool inlining): the correct optimizations should either do nothing when return stack is affected or cope with these cases correctly. But I've heard about implementations where this bug is documented (your code cannot affect the return stack) and therefore is a feature. =========== There are some tricks that produce so impressing results that we must seriously consider their inclusion into the future standard. They are: 1. Manipulations with return addresses. --------------------------------------- Some Lisp-derivatives specially introduce the notion of "continuation" to work with them (Scheme). They enable one to implement backtracking and such things for which there is no name yet. If some ugly architectures have to be standard, they can support words >RR and RR> that work like >R and R> but with the return addresses (RTX, it seems, requires 2* before >R). Another chioce for them is not to support the "Interpreter Structures Access Wordset" (or to redefine : R> POSTPONE R> POSTPONE 2/ ; IMMEDIATE ) 2. Compatibility with threaded code systems. -------------------------------------------- It is ***EASY*** to turn the optimisation off and generate some kind of threaded code (STC) even on optimizing native code Forths. There are some promising data-driven approach derivations that require knowledge of the code structure and even do self-modifying code. An optional word [THREADED] (threaded code compatibility mode) would allow that and improve program readabulity. E.g. [THREADED] : Compile"IF"AsIWant COMPILE [COMPILE] IF ; IMMEDIATE [OPTIMIZED] or : Compile"IF"AsIWant [THREADED] COMPILE [COMPILE] IF [OPTIMIZED] ; IMMEDIATE or : BRANCH R> \ the residue of the code fragment we are called from
>R \ this is where we gonna exit to; ; \ EXIT performs a control transfer : AHEAD [COMPILE] [THREADED] COMPILE BRANCH >MARK [COMPILE] [OPTIMIZED] ; IMMEDIATE might be even standard! And this ABSOLUTELY will not affect most vendors who will define it as : [THREADED] ; IMMEDIATE (Again, these words must not necessarily be in CORE) --- M.L.Gassanenko
|
Fri, 11 Dec 1998 03:00:00 GMT |
|
|
Bruce R. McFarlin #2 / 24
|
What ANS Forth misses /was: Fix Forth, please
Quote:
>There are some tricks that produce so impressing results that we must >seriously consider their inclusion into the future standard. >They are: >1. Manipulations with return addresses. >--------------------------------------- >Some Lisp-derivatives specially introduce the notion of >"continuation" to work with them (Scheme). They enable one to >implement backtracking and such things for which there is no >name yet. If some ugly architectures have to be standard, they >can support words >RR and RR> that work like >R and R> but with >the return addresses (RTX, it seems, requires 2* before >R). >Another chioce for them is not to support the "Interpreter >Structures Access Wordset" >(or to redefine : R> POSTPONE R> POSTPONE 2/ ; IMMEDIATE )
I'm not entirely clear on the language here, but too the extent that I understand what is being said, (1) I think the reasons for making R-stack games not standard were good reasons, but (2) the games wouldn't have been played if someone didn't find them useful. So the question really is, what is being done, in operational and not implemententation terms, with the R-stack games? Can the same be done with user defined stacks, XT's, and judicious use of vectored code? *If* not, then, what *operational* primitives are necessary to accomplish the task? Implement *those* (they might be return stack games on some systems, and something entirely different on other) on a variety of systems, and you're making headway. I dunno about [THREADED] ... first, the name is misleading, because subroutine threaded is still threaded, and second, because again it seems that question is what *operational* capabilities are required: certainly a subroutine threaded compiler with inlining could include an indirect threaded interpreter ... but if there is a capability defined in operational terms, perhaps it can be provided without slamming on the brakes. Virtually, Bruce R. McFarling, Newcastle, NSW
|
Fri, 11 Dec 1998 03:00:00 GMT |
|
|
Brad Rodrigue #3 / 24
|
What ANS Forth misses /was: Fix Forth, please
Quote:
> There are some tricks that produce so impressing results that we must > seriously consider their inclusion into the future standard. > They are: > 1. Manipulations with return addresses.
Hear, hear. Given the recent thread on pattern matching, I think it worthwhile to note that almost* every Forth pattern-matching package has used some kind of return stack manipulation. (*Possibly _every_ package; I haven't read them all.) This was one of my four big grumbles with the ANS Forth standard. I believe that by the time this issue was raised, the committee was too tired to argue out a portable (or semi-portable) way to implement this, so it was simply declared beyond the pale. It's now time to reopen the issue. --
This brain for rent -- inquire within. Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj Director, Forth Interest Group........... http://www.forth.org/fig.html
|
Sun, 13 Dec 1998 03:00:00 GMT |
|
|
M.L.Gassanenk #4 / 24
|
What ANS Forth misses /was: Fix Forth, please
Quote:
> >There are some tricks that produce so impressing results that we must > >seriously consider their inclusion into the future standard. > >They are: > >1. Manipulations with return addresses. > >--------------------------------------- <snip> > I'm not entirely clear on the language here,
Sorry. 1. The Scheme language manipulates with "continuations" to implement backtracking. In Forth terms, the continuations are return addresses, and it is easier to manipulate return addresses in Forth than to deal with continuations in other languages. 2. I have managed to implement backtracking. I have managed to implement things that are more complex than backtracking, there is still no name for them (I mean, in common use). I even have managed to find a problem where they are useful (and even more, they really match the complexity of the problem--it is analysis of sentences in Russian, which is *inflective*). 3. To play R-stack Games we need a) a notion of "return address" b) >RR ( ra -- ) ( R: -- ra ) RR> ( -- ra ) ( R: ra -- ) RRDROP ( -- ) ( R: ra -- ) EXIT ( -- ) ( R: ra -- ; IP:=ra ) although I would prefer them to be >R R> RDROP and EXIT . I do not think that encoding return addresses in a form incompatible with data addresses is a progress. It looks more like spoiling a feature which one has not learned to use. Example: >> (RTX, it seems, requires 2* before >R). Quote: > but too > the extent that I understand what is being said, (1) I think > the reasons for making R-stack games not standard were good > reasons,
Good intentions, I would say. Indeed, the R-stack games in languages other than Forth (and, probably, a few more) are too complex to be useful. Quote: > but (2) the games wouldn't have been played if > someone didn't find them useful. yes. > So the question really is, what is being done, > in operational and not implemententation terms, with > the R-stack games? Can the same be done with user > defined stacks, XT's, and judicious use of vectored > code?
When we switch to backtracking, we change the execution mechanism. In other languages they write an interpreter for backtracking code. The latter can be done in Forth, too, but it would be cumbersome. People prefer to change existing execution mechanism than to write a new code interpreter and code generator. Quote: > *If* not, then, what *operational* primitives > are necessary to accomplish the task? Implement *those* > (they might be return stack games on some systems, and > something entirely different on other) on a variety of > systems, and you're making headway.
This approach is wrong, IMO. The set of backtracking words includes words that support success and failure, and some control structures. Let us imagine that these backtracking words are included into standard. We get the same situation: games with interpretation stacks are considered harmful with the best intentions. These games _have been useful to implement backtracking, but it have been an exception, and nobody will never more find use in them. MLG's {*filter*} control structures are useful only in some linguistic applications and cannot be considered as common practice. You see, this is the same situation. (Well, there is some difference: in this situation we posess backtracking wordset; but we have not acquired possibility to create something else of the same sort). [Do you see the idea? We extend the language, but still restrict its power.] The reasons why Forth should enable programmer to access the code interpreter internals are: 1. There are several examples that show that R-stack games are useful. 2. Nobody can guarantee that all useful techniques are already found. 3. It is one of possible directions for Forth evolution (the language that does not evolute gets forgotten). 4. A formalism exists that describes R-stack games. 5. Optimizations are less important than the expressive power of the language. A purist reason: 6. In Forth a) words are what they do b) you know what they do ANS Forth tries to ignore the 2nd. V.A.Tuzov & P.Koopman used Forth interpreter to implement a variation of data-driven approach. They presented data as Forth code and executed it. B.J.Rodriguez used a technique that resembled both that and backtracking to traverse a tree of expert system rules. Doing so, people find out that they need some means to control the code execution, and R> >R EXIT are the most natural candidates for that role. Quote: > I dunno about [THREADED] ... first, the name is > misleading,
well, what about [CLASSIC-MODE] or [CLASSICAL] ? Quote: > again it seems that question is > what *operational* capabilities are required: ... > ... but if there is a > capability defined in operational terms, perhaps it can > be provided without slamming on the brakes.
What do you mean under "operational"? Is the description: EXIT ( R&IP: ra1 ra2 -- ra2 ) Remove ra1 from the interpretation stack, i.e. load IP with the return address ra2 taken off the return stack, which results in a control transfer to ra2. enough operational? And about "slamming on the brakes"... what about "the morass of ambiguity" where the current approach leads? PS. I'm going to try to implement an "ANS Forth Threaded Code Simulator" that would allow to run Classical Forth approaches on an ANS system. The bad news is that that the interpretation overhead will eat the effect of all implementor's optimizations and, probably, even more. This is where I'm going to use words like [CLASSICAL-MODE] and [ANS-MODE] . WBR, --- M.L.Gassanenko
|
Mon, 14 Dec 1998 03:00:00 GMT |
|
|
Chris Jakema #5 / 24
|
What ANS Forth misses /was: Fix Forth, please
Quote:
> > There are some tricks that produce so impressing results that we must > > seriously consider their inclusion into the future standard. > > They are: > > 1. Manipulations with return addresses. > Hear, hear. Given the recent thread on pattern matching, I think it > worthwhile to note that almost* every Forth pattern-matching package has > used some kind of return stack manipulation. (*Possibly _every_ > package; I haven't read them all.)
I am making some progress in bringing Gordon Charlton's FOrth String Matcher (FOSM) closer to ANS and more portable. The key portability issues I've found so far are: - : SkipCaller ( A word to remove the parent word from the Return Stack. ) ( Often equivalent to below, though not on F-PC ) POSTPONE R> POSTPONE DROP ; IMMEDIATE - : GoTo ( x -- ) ( A word to force execution to another point in the Caller word ) ( Often equivalent to below, even works on F-PC ) POSTPONE R> POSTPONE DROP POSTPONE >R ; IMMEDIATE There may be others still to find .. watch this space. Presumably subroutine-threaded Forths keep return addresses on a stack. Can this be the same as the Forth Return Stack? Bye for now _ _______________________| |_____ Chris Jakeman / _Forth_Interest_Group_| |____/ / /_ __ ______ _ _ | | __ at Peterborough / __/ / / / __ / | | | | | |/ / (a cathedral city / / / / / /_/ / | \_| | | < 80 miles north of London) /_/ /_/ /___ / \____| |_|\_\ Where do you come from? / / ______________/ / United Kingdom Voice +44 (0)1733 346477 /_______________/ Chapter
|
Mon, 14 Dec 1998 03:00:00 GMT |
|
|
Ewald Pf #6 / 24
|
What ANS Forth misses /was: Fix Forth, please
[..] MLG> 3. To play R-stack Games we need MLG> a) a notion of "return address" MLG> b) >RR ( ra -- ) ( R: -- ra ) MLG> RR> ( -- ra ) ( R: ra -- ) MLG> RRDROP ( -- ) ( R: ra -- ) MLG> EXIT ( -- ) ( R: ra -- ; IP:=ra ) MLG> although I would prefer them to be >R R> RDROP and EXIT . [..] Some time ago I found and used then >I and I>. For the data handled herewith, I think, the logic as for execution tokens should apply. So it is only one cell on stack (whatever it is on returnstack). By this, no special implementation-defined stack-width for return-data would be introduced. Had this for an 68000 running 16-bit with 32-bit absolute-addressing return data, which was being converted by I> to relative-addressing 16-bit data. (but I see this logic has one weakness, as to think of a 16-bit system using Intel's segment addresses for execution tokens, thus an information with too high a granularity as to express positions inside of execution lists). Ewald
|
Tue, 15 Dec 1998 03:00:00 GMT |
|
|
Ewald Pf #7 / 24
|
What ANS Forth misses /was: Fix Forth, please
Quote:
> There are some tricks that produce so impressing results that we must > seriously consider their inclusion into the future standard. > They are: > 1. Manipulations with return addresses.
BR> Hear, hear. Given the recent thread on pattern matching, I think it BR> worthwhile to note that almost* every Forth pattern-matching package BR> has used some kind of return stack manipulation. (*Possibly BR> _every_ package; I haven't read them all.) What is lost with good reason, is arithmetics on return addresses. Thus, your example with pattern matching (you mean cases queries, don't you?) were solved better now with indexed execution tokens in data memory, I think. But: BR> This was one of my four big grumbles with the ANS Forth standard. I BR> believe that by the time this issue was raised, the committee was BR> too tired to argue out a portable (or semi-portable) way to BR> implement this, so it was simply declared beyond the pale. It's BR> now time to reopen the issue. I never changed from comprehending _any_ Forth runtime as a sample of execution lists. The entry points to such lists may have become vague in some instances. But if code is _called_, so there _is_ a known entry point back into an execution list. Would be quite natural to deal with this. I see this as well related to code memory addresses. For now, the effort is reflected, to have the best conditions for implementors to make the best code out of source texts. To re-open this issue would mean, to demand from implementors to hand back some of those conditions, as I understand it. It would mean handing back some more impact to high level expressions. Just to ask for known entry points into 'calling' execution lists, for sure is a trivial aspect regarding the "private to the implementation"-issue. One trade-off would be, say, to strip off optimizations of chains of EXIT. This is asking again for the balance: if 'good' low level coding will compensate in any case for the loss in high-level capabilities (whereby high level capabilities in Forth may include direct manipulation of machine resources). Asking for code memory addresses and for the definition of the relation of those to return addresses were not quite that trivial, I'm afraid. Ewald
|
Tue, 15 Dec 1998 03:00:00 GMT |
|
|
Bruce R. McFarlin #8 / 24
|
What ANS Forth misses /was: Fix Forth, please
..[obviously this could descend to horrible quote depths, so just a selective response]... Quote: >3. To play R-stack Games we need > a) a notion of "return address" > b) >RR ( ra -- ) ( R: -- ra ) > RR> ( -- ra ) ( R: ra -- ) > RRDROP ( -- ) ( R: ra -- ) > EXIT ( -- ) ( R: ra -- ; IP:=ra ) > although I would prefer them to be >R R> RDROP and EXIT .
.. Quote: > I do not think that encoding return addresses in a form incompatible > with data addresses is a progress. It looks more like spoiling > a feature which one has not learned to use.
It is progress in terms of standardization. The whole point of which is to extend the range of implementations that can successfully execute code from the same source ( or binary or whatever is being standardized). And specifying that xt's are *not* necessarily addresses in data memory is a big improvement. However, I see where it might be useful to know that the R-stack *is* a stack of return addresses, as opposed to merely an auxilliar stack. As to the overhead of doing an xt threaded interpertor *in* ANS Forth: what are the bottlenecks? Are there primitive operations in terms of xt's that would improve the efficiency of the implementation? Virtually, Bruce R. McFarling, Newcastle, NSW
|
Tue, 15 Dec 1998 03:00:00 GMT |
|
|
Jonah Thom #9 / 24
|
What ANS Forth misses /was: Fix Forth, please
Quote: >3. To play R-stack Games we need > a) a notion of "return address" > b) >RR ( ra -- ) ( R: -- ra ) > RR> ( -- ra ) ( R: ra -- ) > RRDROP ( -- ) ( R: ra -- ) > EXIT ( -- ) ( R: ra -- ; IP:=ra ) > although I would prefer them to be >R R> RDROP and EXIT . > I do not think that encoding return addresses in a form incompatible > with data addresses is a progress. It looks more like spoiling > a feature which one has not learned to use.
I think your special words might reasonably go into, say, the Toolkit Extension wordset. Particularly if some other people get busy and start using them. I have a sort of vague feeling that one of the intentions of some of the Standards Committee members was to encourage Forth programmers to write simple code that's easy to debug and easy to maintain and easy to understand. Note that there's no explicit mention of execution vectors. No return stack manipulation. Extremely limited access to the interpreter. No state-smart words except probably a couple by accident. You have said that your return stack things start to seem natural and easy with experience. But note that very few people have that experience yet, and if you wrote code on a large project it would probably get maintained by someone who wouldn't (at first) understand your methods. I think if your words went into an optional wordset, it would tend to popularize them, and it would tend to standardize them -- others would tend to use the same names instead of making up their own. But systems wouldn't be required to use them, and so they wouldn't be guaranteed to work on all standard systems -- yet. I think that level of acceptance might be a good one to try for, in the next round. Quote: >> *If* not, then, what *operational* primitives >> are necessary to accomplish the task? Implement *those* >> (they might be return stack games on some systems, and >> something entirely different on other) on a variety of >> systems, and you're making headway. >This approach is wrong, IMO.
I think it's a 2nd-best way. It might be the best we can do in the short run. Quote: >The reasons why Forth should enable programmer to access the code interpreter >internals are: >1. There are several examples that show that R-stack games are useful. yes. >2. Nobody can guarantee that all useful techniques are already found. Yes. >3. It is one of possible directions for Forth evolution (the language > that does not evolute gets forgotten).
Yes, but the standards have to trail the evolution. Quote: >4. A formalism exists that describes R-stack games.
Good. Quote: >And about "slamming on the brakes"... what about "the morass of ambiguity" >where the current approach leads?
Yes. What we have is a standard interface. Follow all the rules correctly, and your code will run on all the systems that also follow the rules correctly for their standard interface. Every time you break the rules you increase the chance that your code will fail on some system. I think there's a place for standard code -- particularly in prototyping. We can build up a body of standard routines that you can just plug in whenever you need them, and expect them to work. When you get the results you wanted, then you can spend as much time as you want to and can afford to optimise it. I'm not _certain_ that such things will be useful that way. Maybe it's better to take a little longer and do it right from the start. It might be harder to get a good design when you have a sloppy Frankenstein design that mostly works. But it might be worth having, and portable code might be valuable for other reasons, too. Still, portability isn't everything. Especially when it's so easy to get into swamps where it's hard to think out what's supposed to be portable and what isn't. You can do whatever you want on your own system, and if other people like the power they get when they try it, they'll do it too. Quote: >PS. I'm going to try to implement an "ANS Forth Threaded Code Simulator" >that would allow to run Classical Forth approaches on an ANS system. >The bad news is that that the interpretation overhead will eat the >effect of all implementor's optimizations and, probably, even more. >This is where I'm going to use words like [CLASSICAL-MODE] and [ANS-MODE]
That's a good approach, if you can do it. (I think you can.) Your code will run fast on systems that give you the tools, and it can stilll run (slowly) on standard systems that don't. People can load your code and try it out, and see how valuable it is. Then they'll want it to run fast and maybe revise their compilers to match. It's a possibility, and you do get to say your code is portable, and it still runs fast on all the systems it ran on before.
|
Tue, 15 Dec 1998 03:00:00 GMT |
|
|
Jonah Thom #10 / 24
|
What ANS Forth misses /was: Fix Forth, please
Quote:
>I am making some progress in bringing Gordon Charlton's FOrth String Matcher >(FOSM) closer to ANS and more portable. The key portability issues I've >found so far are: > - : SkipCaller > ( A word to remove the parent word from the Return Stack. ) > ( Often equivalent to below, though not on F-PC ) > POSTPONE R> POSTPONE DROP ; IMMEDIATE
A clumsy way that works is something like: : ?EXIT POSTPONE IF POSTPONE EXIT POSTPONE THEN ; IMMEDIATE : FOO .... .... -1 EXIT ( to skip ) THEN ... ... 0 ; \ called word that skips calling word ... ... FOO ?EXIT ... ... This lets you bail out of one level of nesting. But it takes another ?EXIT and another flag at each place you might want to do it. It's possible but, well, clumsy. Quote: > - : GoTo ( x -- ) > ( A word to force execution to another point in the Caller word ) > ( Often equivalent to below, even works on F-PC ) > POSTPONE R> POSTPONE DROP POSTPONE >R ; IMMEDIATE
This one looks just plain hard. : GOTO ( xt -- ) POSTPONE EXECUTE POSTPONE -1 POSTPONE EXIT ; IMMEDIATE You can execute the new routine, and get out of the current one afterward, and provide a flag to tell the calling one to quit. Again, clumsy. Quote: >Presumably subroutine-threaded Forths keep return addresses on a stack. >Can this be the same as the Forth Return Stack?
It can be -- the trouble is, it doesn't have to be.
|
Tue, 15 Dec 1998 03:00:00 GMT |
|
|
M.L.Gassanenk #11 / 24
|
What ANS Forth misses /was: Fix Forth, please
Quote:
>[..] >MLG> 3. To play R-stack Games we need >MLG> a) a notion of "return address" >MLG> b) >RR ( ra -- ) ( R: -- ra ) >MLG> RR> ( -- ra ) ( R: ra -- ) >MLG> RRDROP ( -- ) ( R: ra -- ) >MLG> EXIT ( -- ) ( R: ra -- ; IP:=ra ) >MLG> although I would prefer them to be >R R> RDROP and EXIT .
^^^^^^^^^^^^^^^^^^^^^ (again I underline this) Quote: >[..] >Some time ago I found and used then >I and I>. For the data handled herewith, >I think, the logic as for execution tokens should apply. So it is only one cell >on stack (whatever it is on returnstack). By this, no special >implementation-defined stack-width for return-data would be introduced.
I> and >I imply, I think, "interpretation". I use to explain return stack manipulations in the following way: Forth has a return stack which contains return addresses and an interpretation pointer IP. Together R-stack and IP form an interpretation stack, IP being its top, ant the rest being the return stack. When a procedure is called, one more element is placed onto the interpretation stack. The top of I-stack, IP, permanently changes while the program executes, therefore reading it does not look too much meaningful. Writing to IP will result in an immediate control transfer, which also can cause problems. This is why Forth procedures access the return stack elements instead of that. When an auxiliary procedure is called, the IP value gets pushed onto the return stack (and IP loads with a new one). The auxiliary procedure can change the return stack, and the changes take effect only when it performs EXIT, which loads IP from the return stack, i.e. removes the top interpretation stack element. Quote: >Had this for an 68000 running 16-bit with 32-bit absolute-addressing return >data, which was being converted by I> to relative-addressing 16-bit data.
Could you describe this in more details, please? How could you pack 32 bits in 16? Quote: >(but I see this logic has one weakness, as to think of a 16-bit system using >Intel's segment addresses for execution tokens, thus an information with too >high a granularity as to express positions inside of execution lists).
IMHO, the seg:offset return addresses are a mistake, probably a fatal one. They should have implemented a 32-bit Forth. I did this, and my F32/16 supports both segment:offset and linear address representations (the seg.lo byte plays the role of a tag: if it is 0 (which is true for all addresses generated by the system), it may be considered as a seg:off pair of words; otherwise, a conversion is needed (which happens rarely). Why crippled implementations for an ugly architecture should be standard? (I even let them exist). -- M.L.Gassanenko
|
Tue, 15 Dec 1998 03:00:00 GMT |
|
|
M.L.Gassanenk #12 / 24
|
What ANS Forth misses /was: Fix Forth, please
I wrote : Quote:
> > again it seems that question is > > what *operational* capabilities are required: > What do you mean under "operational"?
Probably, you meant "expressed in terms of the standard/common/usual execution model that allows (1) sequential execution, (2) control structures as exceptions to (1), (3) procedure calls which do not transgress the bounds of (1). The intention of R-stack Games is to change the execution model. The way to achieve it is to subdivide procedure calls into more elementary operations: >R R> EXIT etc. --- M.L.Gassanenko
|
Tue, 15 Dec 1998 03:00:00 GMT |
|
|
M.L.Gassanenk #13 / 24
|
What ANS Forth misses /was: Fix Forth, please
This message contains replies to authors of several messages. =========== Quote:
>I am making some progress in bringing Gordon Charlton's FOrth String Matcher >(FOSM) closer to ANS and more portable. The key portability issues I've >found so far are:
I think the best way would be to wait for Forth in ANS Forth (what I am going to create) and use it for FOSM. Quote: > - : SkipCaller > - : GoTo ( x -- ) >There may be others still to find ..
Gordon used *elementary* operations, because they may be used in any combinations. I do not think we could achieve the same functionality using words of higer level. Or it will look like a Prolog where programmer uses alternatives and cut statements to implement if's. Another example is money system with the coins of only 5p and 3p. It is possible to pay 1p., but it is not convenient. Quote: >Presumably subroutine-threaded Forths keep return addresses on a stack. >Can this be the same as the Forth Return Stack?
If I implemented it, it would be so. You can use a phrase like "STC that keeps return addresses on the Forth Return Stack." ==============
Quote: > As to the overhead of doing an xt threaded interpertor >*in* ANS Forth: what are the bottlenecks?
So far the definitions like
, that is, high-level definitions for primitives, look most terribly. There will also be something like: 0 value IP old: : create ] does> IP >R TO IP old; Quote: >Are there primitive >operations in terms of xt's that would improve the efficiency >of the implementation?
I have not written it yet. About xt's I can say only that there will be some games with them and :NONAME in DOES> . Code fragment addresses are more convenient than xt's. A code fragment may be a part for another code fragment; we do not have to declare that the current position in code may be used as a code fragment address (e.g. the residue of caller's code is a code fragment). On the contrary, xt's are generated from explicit declarations. In addition, there is no means to patch a code fragment (without explicit declarations of auxiliary names) in the standard. We cannot stick two :NONAME definitions together and get one definition. ============ Quote:
>You have said that your return stack things start to seem natural and easy with >experience. But note that very few people have that experience yet, and if you >wrote code on a large project it would probably get maintained by someone who >wouldn't (at first) understand your methods.
This is the problem of documentation and comments. Of course, if somebody uses methods that are not yet in common practice, there are reasons to document them. Best regards to all, --- M.L.Gassanenko
|
Tue, 15 Dec 1998 03:00:00 GMT |
|
|
Andrew McKewa #14 / 24
|
What ANS Forth misses /was: Fix Forth, please
Quote:
> I am making some progress in bringing Gordon Charlton's FOrth String Matcher > (FOSM) closer to ANS and more portable. The key portability issues I've > found so far are: > - : SkipCaller > ( A word to remove the parent word from the Return Stack. ) > ( Often equivalent to below, though not on F-PC ) > POSTPONE R> POSTPONE DROP ; IMMEDIATE > - : GoTo ( x -- ) > ( A word to force execution to another point in the Caller word ) > ( Often equivalent to below, even works on F-PC ) > POSTPONE R> POSTPONE DROP POSTPONE >R ; IMMEDIATE
Unfortunately, these are just the tricks that make code hard to read and debug. You could use CATCH and THROW for a non-local exit, but GoTo is much more tricky. ----------------------------------------------------------------------
Finnigan Corporation 2215 Grand Avenue Parkway Tel: (512) 251-1574 Austin, TX 78728-3812 Fax: (512) 251-1547
|
Tue, 15 Dec 1998 03:00:00 GMT |
|
|
Chris Jakema #15 / 24
|
What ANS Forth misses /was: Fix Forth, please
[snip] Quote: > PS. I'm going to try to implement an "ANS Forth Threaded Code Simulator" > that would allow to run Classical Forth approaches on an ANS system. > The bad news is that that the interpretation overhead will eat the > effect of all implementor's optimizations and, probably, even more. > This is where I'm going to use words like [CLASSICAL-MODE] and [ANS-MODE] .
You could start with Minimal ANS Forth (MAF). MAF comes in 2 layers, the high-level portable layer and a kernel which contains all the implementation details. The partition is so clear that the kernel can be written in Assembler, C, or Forth with no change to the portable layer. The current version has the kernel written in ANS Forth, making it an "ANS Forth Threaded Code Simulator". Bye for now _ _______________________| |_____ Chris Jakeman / _Forth_Interest_Group_| |____/ / /_ __ ______ _ _ | | __ at Peterborough / __/ / / / __ / | | | | | |/ / (a cathedral city / / / / / /_/ / | \_| | | < 80 miles north of London) /_/ /_/ /___ / \____| |_|\_\ Where do you come from? / / ______________/ / United Kingdom Voice +44 (0)1733 346477 /_______________/ Chapter
|
Tue, 15 Dec 1998 03:00:00 GMT |
|
|
Page 1 of 2
|
[ 24 post ] |
|
Go to page:
[1]
[2] |
|