GForth problem or my problem? 
Author Message
 GForth problem or my problem?

To GForth mavens:

I have ported ftran to GForth "successfully", in a manner of
speaking. The word f." works ok, in the sense that if you say

        f." a=b*c-3.17e-5/cosh(w)"

it will respond


If you define the fvariables a, b, c, and w and say

        : test   f" a=b*c-3.17e-5/cosh(w)"  ;

it will say ok. If you "see" test, you will see the same
code as above. The problem is that when you stuff some
numbers into the fvariables b,c and w to evaluate the
expression, GForth crashes.

On the other hand, when I compile a test word by hand with
that code in it, it seems to work ok. Hmmm.

I am running version 0.3.0 under Win95 in a DOS box. If anyone
would care to try the GForth port of Ftran (on other platforms) and
tell me what happens, I would be most grateful.

--
Julian V. Noble



Sun, 19 Mar 2000 03:00:00 GMT  
 GForth problem or my problem?


Quote:
> If you "see" test, you will see the same
>code as above. The problem is that when you stuff some
>numbers into the fvariables b,c and w to evaluate the
>expression, GForth crashes.

>On the other hand, when I compile a test word by hand with
>that code in it, it seems to work ok. Hmmm.

Check the definitions with a hex dump word. You'll probably see a
difference that doesn't show when using see.

        Bart.



Sun, 19 Mar 2000 03:00:00 GMT  
 GForth problem or my problem?

Quote:

> To GForth mavens:

> I have ported ftran to GForth "successfully", in a manner of
> speaking. The word f." works ok, in the sense that if you say

>         f." a=b*c-3.17e-5/cosh(w)"

> it will respond


> If you define the fvariables a, b, c, and w and say

>         : test   f" a=b*c-3.17e-5/cosh(w)"  ;

> it will say ok. If you "see" test, you will see the same
> code as above. The problem is that when you stuff some
> numbers into the fvariables b,c and w to evaluate the
> expression, GForth crashes.

> On the other hand, when I compile a test word by hand with
> that code in it, it seems to work ok. Hmmm.

> I am running version 0.3.0 under Win95 in a DOS box. If anyone
> would care to try the GForth port of Ftran (on other platforms) and
> tell me what happens, I would be most grateful.

Can you send me your working version?!


Sun, 19 Mar 2000 03:00:00 GMT  
 GForth problem or my problem?


Quote:
> To GForth mavens:

> I have ported ftran to GForth "successfully", in a manner of
> speaking. The word f." works ok, in the sense that if you say

I got your code (ftp://ftp.taygeta.com/pub/Forth/Applications/ftran1.f) to work
with iForth without too much trouble. ASCII is called CHAR nowadays, NOT is
undefined :-)

Quote:

>        f." a=b*c-3.17e-5/cosh(w)"

> it will respond



For this code the word .NAME is used. There is normally no relation
between an arbitrary execution token and the name of a colon definition
(not in iForth, that is). However, in this special case the following
definition works:

  : .NAME ( xt -- ) >HEAD .ID SPACE ;

Quote:
> If you define the fvariables a, b, c, and w and say

>        : test   f" a=b*c-3.17e-5/cosh(w)"  ;

> it will say ok. If you "see" test, you will see the same
> code as above. The problem is that when you stuff some
> numbers into the fvariables b,c and w to evaluate the
> expression, GForth crashes.


FORTH> cd numeric
Directory: c:\dfwforth\examples\numeric ok
FORTH> in ftran1
Redefining v:
Redefining $"
Redefining buffer ok
flib> cr f." a=b*c-3.17e-5/tanh(w)+abs(x)"

flib> testing on  ok
flib> fvariable a  fvariable b  fvariable c  fvariable x  fvariable w  ok
flib> : test f" a=b*c-3.17e-5/tanh(w)+abs(x)" ;
Caught exception 0xc0000005
ACCESS VIOLATION
instruction pointer = 0x4261a1

flib>

This bug (if it is not caused by my porting!) indicates that a vector is
not properly initialized ( 0?). It is possible that with Win32For the
vector points to some harmless code (Win32For has a relocatable kernel
so I think it adds a constant to all addresses.) This could be caused by
e.g, a problem with words being unexpectedly immediate.

It's strange that it doesn't work. When the correct words can be printed it
should be straightforward to simply EVALUATE instead of TYPE them. That
strategy also produces good code in case of optimizing compilers (COMPILE,
will be much, much worse). I think this is a valid use of EVALUATE (if not,
Anton will surely tell me :-)

-marcel



Sun, 19 Mar 2000 03:00:00 GMT  
 GForth problem or my problem?

[...]

Jens Wilke reports that the problem is caused by the incorrect
behaviour of ONLY in Gforth (it sets the current wordlist). This will
be fixed.

Quote:
> It's strange that it doesn't work. When the correct words can be printed it
> should be straightforward to simply EVALUATE instead of TYPE them. That
> strategy also produces good code in case of optimizing compilers (COMPILE,
> will be much, much worse).

If your optimizer does not work well with "COMPILE,", that is a
problem of your optimizer, not of "COMPILE,". E.g., RAFTS does not
have this problem, and AFAIK bigForth does not have it, either.

Quote:
> I think this is a valid use of EVALUATE (if not,
> Anton will surely tell me :-)

You mean, constructing the string





probably not much of a problem, but, e.g., FABS could very well be
some variable name (Altavista reports 5569 matches on "fabs").  And if
it's in a separate wordlist, you won't even get a warning about
redefinition (at least not from Gforth).

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed

http://www.complang.tuwien.ac.at/anton/home.html



Wed, 22 Mar 2000 03:00:00 GMT  
 GForth problem or my problem?


I said:

Quote:
>> It's strange that it doesn't work. When the correct words can be printed it
>> should be straightforward to simply EVALUATE instead of TYPE them. That
>> strategy also produces good code in case of optimizing compilers (COMPILE,
>> will be much, much worse).

> If your optimizer does not work well with "COMPILE,", that is a
> problem of your optimizer, not of "COMPILE,". E.g., RAFTS does not
> have this problem, and AFAIK bigForth does not have it, either.

I was not thinking of i/t/mForth here. E.g. my LMI F83 Forth for the RTX2000
seems to be based on a rigid text recognition algorithm (it is not
documented and a nuisance).

Quote:
>> I think this is a valid use of EVALUATE (if not,
>> Anton will surely tell me :-)

> You mean, constructing the string


> and EVALUATEing it instead of using POSTPONE or COMPILE, for compiling



I see your point for a macro-like construct. Here that doesn't really
matter because the string is not stored for future reference but compiled
immediately. The method implies that you "know" that the fortran style
formula is going to be rewritten into standard Forth FLOAT and EXTENDED
FLOAT words (and that therefore these F-words should be treated carefully,
and all "redefining" messages for F-words must be examined).

One could even argue that with POSTPONE the output of ftran would be "wrong",

compiled formulas (however without EVALUATE it won't).

Quote:

> probably not much of a problem, but, e.g., FABS could very well be
> some variable name (Altavista reports 5569 matches on "fabs").  And if
> it's in a separate wordlist, you won't even get a warning about
> redefinition (at least not from Gforth).

All Forth code has this problem, not just ftran. You don't know (for sure)
what will be printed when this line executes:

( I may have done "variable base 3 base !" or "here value base" on the
previous line )

-marcel



Wed, 29 Mar 2000 03:00:00 GMT  
 GForth problem or my problem?

Quote:


> > You mean, constructing the string


> > and EVALUATEing it instead of using POSTPONE or COMPILE, for compiling


> I see your point for a macro-like construct. Here that doesn't really
> matter because the string is not stored for future reference but compiled
> immediately.

The strings "x", "w", "b", "c" and "a" are compiled immediately, and
it would be safe to use EVALUATE for them. The rest was stored for
future reference when your EVALUATE-version of FTRAN was loaded, and
it using EVALUATE on them is not safe.

Quote:
> The method implies that you "know" that the Fortran style
> formula is going to be rewritten into standard Forth FLOAT and EXTENDED
> FLOAT words (and that therefore these F-words should be treated carefully,

If the user uses FTRAN, he possibly does not know all the standard
FLOAT words; why should he? And the danger does not only come from
redefining, but also from setting the search order differently.

Quote:
> and all "redefining" messages for F-words must be examined).

My Forth system does not generate a warning about redefined names if
the word has been defined in a different wordlist. Does yours? Even
when the wordlist with the word being redefined is not in the search
order?

Quote:
> One could even argue that with POSTPONE the output of ftran would be "wrong",

> compiled formulas (however without EVALUATE it won't).

I don't know about your intuitions, but I learned long ago that in
Forth a redefinition affects only code that is defined later, so if I
redefine it after loading Ftran, Ftran should not be affected. The



before loading Ftran.

Quote:

> > probably not much of a problem, but, e.g., FABS could very well be
> > some variable name (Altavista reports 5569 matches on "fabs").  And if
> > it's in a separate wordlist, you won't even get a warning about
> > redefinition (at least not from Gforth).

> All Forth code has this problem, not just ftran. You don't know (for sure)
> what will be printed when this line executes:

> ( I may have done "variable base 3 base !" or "here value base" on the
> previous line )

AFAIK Ftran does not have this problem(*), because it uses POSTPONE and
COMPILE,, not EVALUATE.

The difference between your example and the problem I am talking about
is that in your example the user knows that he is using a word "base",
whereas with Ftran he does not know that he uses FABS; for all the user
knows, the program could be translated directly into machine code, or
compiled with a Fortran compiler and linked in.

(*)This problem is:

needs ftran.fs
...
variable fabs
...
f" x=abs(y)"

will do something different than the user expected.

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed

http://www.complang.tuwien.ac.at/anton/home.html



Mon, 10 Apr 2000 03:00:00 GMT  
 GForth problem or my problem?


Quote:


>> > You mean, constructing the string


>> > and EVALUATEing it instead of using POSTPONE or COMPILE, for compiling


>> I see your point for a macro-like construct. Here that doesn't really
>> matter because the string is not stored for future reference but compiled
>> immediately.

> The strings "x", "w", "b", "c" and "a" are compiled immediately, and
> it would be safe to use EVALUATE for them. The rest was stored for
> future reference when your EVALUATE-version of FTRAN was loaded, and
> it using EVALUATE on them is not safe.

Is it possible to write "safe" Forth _tools_? I don't think so. It is
necessary to understand a tool at almost the implementation level. This
certainly holds for Forth itself.

Quote:
>> The method implies that you "know" that the Fortran style
>> formula is going to be rewritten into standard Forth FLOAT and EXTENDED
>> FLOAT words (and that therefore these F-words should be treated carefully,

> If the user uses FTRAN, he possibly does not know all the standard
> FLOAT words; why should he? And the danger does not only come from
> redefining, but also from setting the search order differently.

An FTRAN user not knowing about _all_ the facilities in Forth itself?
Unlikely, unwise.

Quote:
> and all "redefining" messages for F-words must be examined).
> My Forth system does not generate a warning about redefined names if
> the word has been defined in a different wordlist. Does yours? Even

No, iForth warns only for redefined words in the list accessed by
GET-CURRENT (which is not necessarily in the search order). Actually all
words defined in the standard are in a single iForth wordlist ( FORTH ).

Quote:
> when the wordlist with the word being redefined is not in the search
> order?

Sorry, I don't understand.

Quote:
>> One could even argue that with POSTPONE the output of ftran would be "wrong",

>> compiled formulas (however without EVALUATE it won't).

> I don't know about your intuitions, but I learned long ago that in
> Forth a redefinition affects only code that is defined later, so if I
> redefine it after loading Ftran, Ftran should not be affected. The



Well, I learned that everything is possible in Forth. What actually happens
depends on the creativity of the programmer. I don't think it is bad when
ftran uses EVALUATE , as long as it is documented.

Quote:

> before loading Ftran.

And reload it all after each try?

[..]

Quote:
> You don't know (for sure)
> what will be printed when this line executes:

> ( I may have done "variable base 3 base !" or "here value base" on the
> previous line )
> AFAIK Ftran does not have this problem(*), because it uses POSTPONE and
> COMPILE,, not EVALUATE.
> The difference between your example and the problem I am talking about
> is that in your example the user knows that he is using a word "base",
> whereas with Ftran he does not know that he uses FABS; for all the user
> knows, the program could be translated directly into machine code, or
> compiled with a Fortran compiler and linked in.

The difference is that your user is not a Forth programmer using a tool.
A foolproof ftran would not allow its users to do much.

-marcel



Thu, 13 Apr 2000 02:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Problem with info for gforth

2. gforth problem

3. BASE problem in GForth?

4. Problem Building gforth 0.4.0

5. Problems with gforth / linux tar

6. gforth 0.3.0 problem..

7. Problems, problems, problems

8. Eiffel Problems, Problems, Problems

9. Finn Idiom problems and Re: {rho} problem

10. Combinatorial Problem [ & a new Combinatorial Problem ]

11. Database problem/Memory problem??

12. CW 2003 - Focus problem & a select problem

 

 
Powered by phpBB® Forum Software