What ANS Forth misses /was: Fix Forth, please 
Author Message
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 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  
 
 [ 24 post ]  Go to page: [1] [2]

 Relevant Pages 

1. ANS Forth in ANS Forth?

2. Q: What is missing in ANS Forth?

3. Am I missing something in forth!

4. ans forth link broken at forth.org

5. comp.lang.forth FAQ: ANS Forth (7 of 7)

6. Implementing ANS Forth Wordlist(s) in Forth-83

7. Forth books (was "ANS Forth")

8. ANS Forth & Compatable Forth

9. comp.lang.forth FAQ: ANS Forth (7 of 7)

10. Fix Forth, please

11. Help Please Fig Forth question from Forth beginner

12. Getting Forth related files (was: Forth primer/teaching Forth)

 

 
Powered by phpBB® Forum Software