Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #55952 > unrolled thread

one of the ways ANS-Forth was purposely crippled

Back to article view | Back to comp.lang.forth

Contents

  one of the ways ANS-Forth was purposely crippled hughaguilar96@gmail.com - 2017-03-19 16:46 -0700
    Re: one of the ways ANS-Forth was purposely crippled Helmar Wodtke <helmwo@gmail.com> - 2017-03-20 05:37 -0700
      Re: one of the ways ANS-Forth was purposely crippled hughaguilar96@gmail.com - 2017-03-20 18:37 -0700

#55952 — one of the ways ANS-Forth was purposely crippled

I'm writing a document describing how ANS-Forth was purposely crippled. Here is an excerpt:
----------------------------------------------------------------------------

When I wrote the MFX cross-compiler in UR/Forth (which was Forth-83) I used the built-in outer-interpreter. This makes a cross-compiler pretty simple. The problem however, was that I couldn't have literal numbers in TARG colon words. This was because the built-in outer-interpreter called LITERAL internally and LITERAL compiled the number into the HOST memory rather than the TARG memory.

I wrote a LITERAL that compiled the number into TARG memory but I had to use this explicitly:
            : test  [ 12345 ] literal ;
I was able to make an abbreviated version that did the same thing with somewhat less source-code bloat:
            : test  [ 12345 ]L ;
I have heard of some Forth cross-compilers that do this:
            : test  S# 12345 ;
            : test  D# 12345.6789 ;
            : test  F# 12345.6789e ;
None of this is Forth-83 code however. Forth-83 was not capable of supporting a cross-compiler that compiles Forth-83 code.

...

It was obvious to me at the time that LITERAL 2LITERAL and FLITERAL needed to be vectored. This way the TARG colon could revector it to the LITERAL that compiles into TARG memory, and then the TARG semicolon could restore the vector again to the built-in LITERAL that compiles into HOST memory. Anybody who has written a cross-compiler that uses the built-in outer-interpreter would agree --- this is obvious.

With great hope I looked forward to the arrival of ANS-Forth with the expectation that the problems of Forth-83, including the failure to vector LITERAL 2LITERAL and FLITERAL, would be fixed. What a disappointment! ANS-Forth also fails to vector LITERAL 2LITERAL and FLITERAL. Apparently nobody on the ANS-Forth committee had ever written a cross-compiler that used the built-in outer-interpreter --- they didn't see this glaring need that anybody with any experience in cross-compilers would be aware of --- there seems to be no other explanation than gross ignorance on the part of the ANS-Forth committee.

Well, actually there is another explanation. It is possible that ANS-Forth was purposely crippled to prevent common Forth programmers from writing a cross-compiler that use the built-in outer-interpreter. The compiler-vendors (who were on the ANS-Forth committee) can vector LITERAL 2LITERAL and FLITERAL so their own cross-compiles will support literal numbers. They don't document this though, so their customers can't write a cross-compiler that supports literal numbers. Forth Inc. and MPE both make most of their money selling cross-compilers --- they don't want ANS-Forth programmers to write cross-compilers in competition with them --- they want the Forth community to buy their cross-compilers. Ultimately, it is all about money! ANS-Forth was designed to hold back the Forth community, not empower the Forth community --- there was never any intention that the Forth community would be anything other than customers of the corporations --- the ANS-Forth committee members were looking out for their own profit, and this meant giving the common Forth programmers a crippled standard.

The Forth-200x committee also refuse to make LITERAL 2LITERAL and FLITERAL vectored --- this is despite the fact that doing so would be easy, and despite the fact that this need is well known (I have pointed out the need dozens of times on the Forth-200x mailing before I got kicked out, and on comp.lang.forth, starting in 2009 and continuing until now). The fact that they refuse to make this obvious problem-fix implies that they want to continue to have the same problem in Forth-200x that they did in ANS-Forth and in Forth-83 before that.

...

The bottom line is that ANS-Forth doesn't make LITERAL 2LITERAL and FLITERAL vectored words, and the Forth-200x committee also refuses to do so. There isn't anything that anybody can do to change their minds --- they make their money selling cross-compilers --- you can't pay them enough to make it worth their while to allow common Forth programmers to write a cross-compiler in ANS-Forth that uses the built-in outer-interpreter and supports literal numbers in TARG colon words.

To write a cross-compiler in ANS-Forth, we can't use the built-in outer-interpreter --- we have to write a custom outer-interpreter --- there are problems with doing this however (the most glaring being that FIND is ambiguous in ANS-Forth).

[toc] | [next] | [standalone]

#55963

> I wrote a LITERAL that compiled the number into TARG memory but I had to use this explicitly:
>             : test  [ 12345 ] literal ;

Mhm,

it's best to write your own outer interpreter. It's not complicated. DPANS94 is not how a system is implemented - it's only about what things have to do. In the case of writing a cross compiler, you probably even want your own interpreter.

I personally prefer interpreters like

: INTERPRET ' EXECUTE RECURSE ;

(I know, line endings etc. needed in DPANS are not in scope here...)

In this case you should have "tickable" literals... And ";" should compile jumps to last "called" word in definition...

"tickable" literals may have limited life-time for the returned xt. You can implement (pseudo code) like:

variable last-literal
: the-literal last-literal @ mode @ if postpone literal then ; immediate

The "tick" should return xt of "the-literal".

The "power" of DPANS94 is not that you get a system that fits your needs - you get a system that is more or less something that behaves as expected by the document. There is no reason why not to modify the system in a way that fits your needs.

My HelFORTH had - beside it's own very special implementation details - a very compatible DPAN94 layer... I do re-write at the moment the system with some similar ideas. Now I do more DPANS compatiblity from the beginning, but I use only some words (reduced DPANS94 word set). The implementation is again focused on implementing a JIT-compiler later again.

Regards,
-Helmar

[toc] | [prev] | [next] | [standalone]

#55986

On Monday, March 20, 2017 at 5:37:13 AM UTC-7, Helmar Wodtke wrote:
> > I wrote a LITERAL that compiled the number into TARG memory but I had to use this explicitly:
> >             : test  [ 12345 ] literal ;
> 
> Mhm,
> 
> it's best to write your own outer interpreter. It's not complicated. 

Well, my document says (shown above) that using the built-in outer-interpreter is not possible because ANS-Forth does not vector LITERAL 2LITERAL and FLITERAL, and the Forth-200x committee also refuse to do so --- because of this, it is necessary to write your own custom outer-interpreter.

This is complicated though! For a long time, I believed that this was impossible. The reason is that FIND is ambiguous. In VFX, SwiftForth and Gforth we have FIND working in a different and incompatible manner. If you think this is not complicated, then most likely you have only used one ANS-Forth system and you figured out how FIND works on it, but you didn't realize that FIND doesn't work the same way on other ANS-Forth systems. If you are going to be vendor-specific, then you might as well use VFX and use the built-in outer-interpreter --- this is possible in VFX because CLIT, that is used by LITERAL and 2LITERAL is deferred --- this is not documented in the VFX manual however, so you would have had to disassemble VFX to find out about this.

So, the next section in my document describes the disambiguifiers. With the disambiguifiers, FIND begins to work consistently between ANS-Forth systems. This was a major breakthrough for me! Only when I figured out the disambiguifiers did I believe that it was possible to write a cross-compiler in ANS-Forth. Many people claim to have written a cross-compiler in ANS-Forth (you apparently are one of them) --- I don't believe any of them are telling the truth --- I think all of them have vendor-specific implementations (if they don't know about the disambiguifiers, then they have to be relying on one specific interpretation of the ANS-Forth document in regard to how FIND works).

After you have the disambiguifiers, you still have the problem of needing a STR>NUM function. So, that is the subject of the next section in my document. I have a STR>NUM that works. Also, I got rid of the bugs in the ANS-Forth design:
1.) ANS-Forth allows a dot anywhere in a number to indicate that it is double-precision. For me, a dot indicates that the number is floating-point. I allow commas anywhere in the number, but a comma at the very beginning (left side) indicates that the number is double-precision.
2.) ANS-Forth requires an 'e' to indicate that a number is floating-point. I have a dot indicating that a number is floating-point and the 'e' or 'E' is only used when there is an exponent part.

I considered STR>NUM to be a pretty complicated function to write --- maybe you think it is trivial though.

> In the case of writing a cross compiler, you probably even want your own interpreter.

I can't think of any reason why I would want my own outer-interpreter --- my MFX used the built-in outer-interpreter and it was pretty simple and straight-forward --- the only problem was the issue with LITERAL not being vectored.

> I personally prefer interpreters like
> 
> : INTERPRET ' EXECUTE RECURSE ;
> 
> (I know, line endings etc. needed in DPANS are not in scope here...)
> 
> In this case you should have "tickable" literals... And ";" should compile jumps to last "called" word in definition...
> 
> "tickable" literals may have limited life-time for the returned xt. You can implement (pseudo code) like:
> 
> variable last-literal
> : the-literal last-literal @ mode @ if postpone literal then ; immediate
> 
> The "tick" should return xt of "the-literal".

In Straight Forth I can't have tickable literals because I want to support ITC and I don't want to allow new primitives to be made (there is no CODE definer and assembler, so the user can't write his own primitives). All the primitives have to be written by me as part of the system. To have tickable literals, it would be necessary to create a new primitive for each literal.

I don't know why you say: "a tickable literal may have a limited life-time for the returned xt." That doesn't make sense to me at all. I also don't know why you made your tickable literal an IMMEDIATE word. I would have something like this:

code 12345  
    sub rbp, 4
    mov 0 [rbp], rbx
    mov rbx, 12345
    next,
end-code

> The "power" of DPANS94 is not that you get a system that fits your needs - you get a system that is more or less something that behaves as expected by the document. There is no reason why not to modify the system in a way that fits your needs.

You can't modify an ANS-Forth system to have a vectored LITERAL --- you can't use the built-in outer-interpreter because it uses the built-in LITERAL which you can't change.

ANS-Forth doesn't fit my needs. I think that ANS-Forth was purposely crippled to prevent it from being used for writing commercial software. Elizabeth Rather has repeatedly said that the goal of ANS-Forth was not portable programs, but rather portable programmers. What she means is that Gforth would be a toy language that students could learn Forth on. Gforth would not be competitive with SwiftForth or VFX however, so it couldn't be used for writing commercial programs. The student would then be "portable" in the sense that he could get a job writing SwiftForth or VFX programs. These programs would be vendor-specific --- they would not be ANS-Forth --- but the student would have already learned the basics (what DUP and SWAP do, etc.), and wouldn't have to learn this ultra-basic Forth on the job.

> My HelFORTH had - beside it's own very special implementation details - a very compatible DPAN94 layer... I do re-write at the moment the system with some similar ideas. Now I do more DPANS compatiblity from the beginning, but I use only some words (reduced DPANS94 word set). The implementation is again focused on implementing a JIT-compiler later again.

I would be interested in looking at your HelFORTH --- can I download that? --- does it work under Windows?

> Regards,
> -Helmar

Thanks for responding politely! Normally ANS-Forth enthusiasts just respond with a lot of insults. Stephen Pelc says: "RTFM!" in regard to SYNONYM for example. And, of course, there is the 4-year-old saga of Alex McDonald telling me that I "have a serious misunderstanding of how pointers work." All of that gets tedious and depressing --- just not that amusing after the first few years...

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web