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

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

A short history of the stages of development and status of RP's Forth interpreter.

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

Contents

  A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-22 19:16 -0400
    Re: A short history of the stages of development and status of RP's Forth interpreter. jacko <jackokring@gmail.com> - 2012-03-23 00:38 -0700
      Re: A short history of the stages of development and status of RP's Forth interpreter. jacko <jackokring@gmail.com> - 2012-03-23 00:56 -0700
    Re: A short history of the stages of development and status of RP's For  interpreter. Nomen Nescio <nobody@dizum.com> - 2012-03-23 12:53 +0100
      Re: A short history of the stages of development and status of RP's For  interpreter. "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-23 20:44 -0400
        Re: A short history of the stages of development and status of RP's For  interpreter. Nomen Nescio <nobody@dizum.com> - 2012-03-25 10:30 +0200
          Re: A short history of the stages of development and status of RP's For  interpreter. "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-25 06:05 -0400
            Re: A short history of the stages of development and status of RP's Nomen Nescio <nobody@dizum.com> - 2012-03-27 03:03 +0200
              Re: A short history of the stages of development and status of RP's "Elizabeth D. Rather" <erather@forth.com> - 2012-03-26 15:39 -1000
                Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201203.rodent.frell.theremailer.net> - 2012-03-28 11:18 +0200
                  Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-30 07:04 -0400
                    Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201203.rodent.frell.theremailer.net> - 2012-03-30 19:24 +0200
                      Re: A short history of the stages of development and status of RP's Paul Rubin <no.email@nospam.invalid> - 2012-03-30 13:00 -0700
                        Re: A short history of the stages of development and status of RP's Nomen Nescio <nobody@dizum.com> - 2012-04-04 16:09 +0200
                      Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-30 18:06 -0400
                        Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-02 16:39 +0200
                          Re: A short history of the stages of development and status of RP's Paul Rubin <no.email@nospam.invalid> - 2012-04-02 15:37 -0700
                            Re: A short history of the stages of development and status of RP's BruceMcF <agila61@netscape.net> - 2012-04-02 16:59 -0700
                            Re: A short history of the stages of development and status of RP's kenney@cix.compulink.co.uk - 2012-04-03 17:15 -0500
                              Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-04 05:23 -0400
                                Re: A short history of the stages of development and status of RP's Nomen Nescio <nobody@dizum.com> - 2012-04-04 15:58 +0200
                                  Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-05 09:57 -0400
                                    Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-11 21:23 +0200
                                      Re: A short history of the stages of development and status of RP's "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-11 19:13 -0400
                                        Re: A short history of the stages of development and status of RP's jacko <jackokring@gmail.com> - 2012-04-11 18:22 -0700
                                      Re: A short history of the stages of development and status of RP's hwfwguy@gmail.com - 2012-04-13 09:37 -0700
                            Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-05 11:21 +0200
            Re: A short history of the stages of development and status of RP's Fritz Wuehler <fritz@spamexpire-201203.rodent.frell.theremailer.net> - 2012-03-27 13:08 +0200
        Re: A short history of the stages of development and status of RP's For  interpreter. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-26 08:58 +0000
    Re: A short history of the stages of development and status of RP's Forth interpreter. Fanzo <cristianof6@gmail.com> - 2012-03-25 15:32 +0200
    Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-30 18:05 -0400
      Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-02 05:08 -0400
        Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-10 11:07 -0400
          Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-11 19:00 -0400
            Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-11 19:24 -0700
              Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-12 14:03 -0400
                Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-12 08:19 -1000
                  Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-14 17:21 -0400
                    Re: A short history of the stages of development and status of RP's Forth interpreter. Coos Haak <chforth@hccnet.nl> - 2012-04-15 00:11 +0200
                    Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-14 13:48 -1000
                      Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-15 13:09 -0400
                        Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-15 08:06 -1000
                          Re: A short history of the stages of development and status of RP's Forth interpreter. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-16 09:45 +0000
                            Re: A short history of the stages of development and status of RP's Forth interpreter. jacko <jackokring@gmail.com> - 2012-04-16 05:26 -0700
                        Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-15 11:10 -0700
                          Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-15 17:57 -0400
                            Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-15 12:22 -1000
                            Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-15 19:35 -0700
                              Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-15 16:58 -1000
                              Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-16 15:50 -0400
                                Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-16 13:24 -0700
                                Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-16 11:17 -1000
                    Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-14 17:07 -0700
                      Re: A short history of the stages of development and status of RP's Forth interpreter. Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-14 22:37 -0700
                        Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-14 20:54 -1000
                          Re: A short history of the stages of development and status of RP's Forth interpreter. Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-15 00:22 -0700
                        Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-15 07:00 -0700
                Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-12 12:45 -0700
                  Re: A short history of the stages of development and status of RP's Forth interpreter. Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-12 13:29 -0700
                    Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-12 13:56 -0700
                    Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-13 10:25 -0400
                      Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-13 08:12 -0700
                        Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-14 17:22 -0400
                          Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-14 16:10 -0700
                            Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-15 12:53 -0400
                              Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-15 11:01 -0700
                      Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-13 08:23 -0700
            Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-11 17:27 -1000
            Re: A short history of the stages of development and status of RP's Forth interpreter. Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-12 00:19 -0700
              Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-12 13:54 -0400
                Re: A short history of the stages of development and status of RP's Forth interpreter. Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-12 13:43 -0700
            Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-12 06:45 -0700
              Re: A short history of the stages of development and status of RP's  Forth interpreter. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-12 15:01 +0000
                Re: A short history of the stages of development and status of RP's  Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-12 13:54 -0400
                Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-12 10:49 -0700
                  Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-12 08:40 -1000
                    Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-12 12:38 -0700
                      Re: A short history of the stages of development and status of RP's Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-12 13:58 -1000
                  Re: A short history of the stages of development and status of RP's  Forth interpreter. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-13 10:42 +0000
                    Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-13 08:34 -0700
                      Re: A short history of the stages of development and status of RP's  Forth interpreter. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-13 15:48 +0000
                        Re: A short history of the stages of development and status of RP's  Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-13 08:25 -1000
                        Re: A short history of the stages of development and status of RP's  Forth interpreter. stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-13 22:08 +0000
                          Re: A short history of the stages of development and status of RP's  Forth interpreter. "Elizabeth D. Rather" <erather@forth.com> - 2012-04-13 12:26 -1000
                            Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-13 16:14 -0700
                              Re: A short history of the stages of development and status of RP's Forth interpreter. jacko <jackokring@gmail.com> - 2012-04-14 09:04 -0700
                                Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-14 15:59 -0700
                                  Re: A short history of the stages of development and status of RP's Forth interpreter. Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-15 10:50 +0000
                                    Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-15 07:06 -0700
                            XT only or XT+NT (was: A short history ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-14 14:06 +0000
                              Re: XT only or XT+NT (was: A short history ...) Alex McDonald <blog@rivadpm.com> - 2012-04-16 02:39 -0700
                    Re: A short history of the stages of development and status of RP's Forth interpreter. BruceMcF <agila61@netscape.net> - 2012-04-13 08:46 -0700
              Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-12 13:53 -0400
            Re: A short history of the stages of development and status of RP's Forth interpreter. "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-19 17:06 -0400

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#11251

"Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
news:ec146850-bf98-45c9-8fa7-58883ddbc03b@l18g2000vbx.googlegroups.com...
> > SET         n addr  --
> >     A defining word used in the form:
> >          n  addr  SET  <name>
> >     Defines a word <name> which, when executed, will cause the
> >     value  n  to be stored at address.
> > "
>
> Oh my goodness! That's just gratuitous code-snobbery!
>
> So:
>
> 100 $A000 SET FRED
>

Yes.  That's how I took SET's syntax to be.

> Creates a word called FRED that writes 100 to 0xB000
>

Well, that'd create a word FRED that writes 100 to 0xA000, not 0xB000 ...

;-)

> What, you mean like:
>
> : FRED 100 $B000 ! ;
>
> LOL!

Yes.  That's *exactly* what I took SET to do.

Although, I was thinking about implementing it in terms of COMPILE
or LITERAL instead of using DOES> ...

Writing specific values and to specific memory locations probably isn't as
useful as it once was.

Bruce seems to have concocted a definition that splits the operation's two
arguments (as humor I guess ...), but fits better with Forth's definitions.


Rod Pemberton

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

#11255

On Apr 13, 10:25 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
> "Mark Wills" <markrobertwi...@yahoo.co.uk> wrote in message
>
> news:ec146850-bf98-45c9-8fa7-58883ddbc03b@l18g2000vbx.googlegroups.com...
>
> > > SET         n addr  --
> > >     A defining word used in the form:
> > >          n  addr  SET  <name>
> > >     Defines a word <name> which, when executed, will cause the
> > >     value  n  to be stored at address.
> > > "
>
> > Oh my goodness! That's just gratuitous code-snobbery!
>
> > So:
>
> > 100 $A000 SET FRED
>
> Yes.  That's how I took SET's syntax to be.
>
> > Creates a word called FRED that writes 100 to 0xB000
>
> Well, that'd create a word FRED that writes 100 to 0xA000, not 0xB000 ...
>
> ;-)
>
> > What, you mean like:
>
> > : FRED 100 $B000 ! ;
>
> > LOL!
>
> Yes.  That's *exactly* what I took SET to do.
>
> Although, I was thinking about implementing it in terms of COMPILE
> or LITERAL instead of using DOES> ...
>
> Writing specific values and to specific memory locations probably isn't as
> useful as it once was.
>
> Bruce seems to have concocted a definition that splits the operation's two
> arguments (as humor I guess ...), but fits better with Forth's definitions.

No, not at humor at all. In the specification, "writes x to an addr"
means writes the number it was defined with to ANY address that is
handed to it.

If you have any experience with scaled integer fixed point arithmatic
using */ you know that the appropriate factor for something like 2x
and 0.75x depends on what scaling denominator you use, so in that
situation, it could indeed be handy to work out the correctly scaled
factors in one place and then use those words to set variables that
hold scaling factor.

So scaled to hundredths:

200 SET 2x
100 SET 1x
50 SET 0.5x
25 SET 0.25x

... and if you change and scale to minutes of a degree (21,600ths),
then instead its:

43200 SET 2x
21600 SET 1x
10800 SET 0.5x
5400 SET 0.25x

However, if the setting you normally do is TRUE and FALSE, then
defining a word to define ON and OFF is obviously overkill, since its
easier to just do:

: ON ( addr -- ) TRUE SWAP ! ;
: OFF ( addr -- ) 0 SWAP ! ;

Used the same way as the words defined by SET:
   ... QDUPSTATE ON ...
   ... QDUPSTATE OFF ...

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

#11292

"BruceMcF" <agila61@netscape.net> wrote in message
news:c3b5476f-e0b4-454b-ab11-53831f266156@h9g2000yqe.googlegroups.com...
> On Apr 13, 10:25 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:
...

> > Bruce seems to have concocted a definition [for SET] that splits [the]
> > operation's two arguments (as humor I guess ...), but fits better with
> > Forth's definitions.
>
> No, not at humor at all. In the specification, "writes x to an addr"
> means writes the number it was defined with to ANY address that is
> handed to it.
>

Oh, ok.  Well, ISTM that you basically (re)created ANS' TO functionality
but not SET as I read the syntax ...

While I really "see" SET being used to program ports primarily, it could be
used in the context of VARIABLEs for clearing and setting, or to clamp
values to a specific range, e.g.:

: SET CREATE SWAP , , DOES> DUP @ SWAP CELL+ @ ! ;

VARIABLE APPLE
1 APPLE !
0 APPLE SET MINAPPLE
15 APPLE SET MAXAPPLE

MINAPPLE ( zeroed APPLE )

APPLE 15 > IF MAXAPPLE THEN


Rod Pemberton

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

#11296

On Apr 14, 5:22 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
> "BruceMcF" <agil...@netscape.net> wrote in message
>
> news:c3b5476f-e0b4-454b-ab11-53831f266156@h9g2000yqe.googlegroups.com...> On Apr 13, 10:25 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> > wrote:
>
> ...
>
> > > Bruce seems to have concocted a definition [for SET] that splits [the]
> > > operation's two arguments (as humor I guess ...), but fits better with
> > > Forth's definitions.
>
> > No, not at humor at all. In the specification, "writes x to an addr"
> > means writes the number it was defined with to ANY address that is
> > handed to it.
>
> Oh, ok.  Well, ISTM that you basically (re)created ANS' TO functionality
> but not SET as I read the syntax ...
>
> While I really "see" SET being used to program ports primarily, it could be
> used in the context of VARIABLEs for clearing and setting, or to clamp
> values to a specific range, e.g.:
>
> : SET CREATE SWAP , , DOES> DUP @ SWAP CELL+ @ ! ;
>
> VARIABLE APPLE
> 1 APPLE !
> 0 APPLE SET MINAPPLE
> 15 APPLE SET MAXAPPLE

That's why I figure the jokes on those who got handed that version of
set:

: MINAPPLE ( -- ) 0 APPLE ! ;
: MAXAPPLE ( -- ) 15 APPLE ! ;

... and of course, no "CSET" needed if its a bytewide port:

IOBASE 16 FF* + CONSTANT PADDLE1
PADDLE1 1+ CONSTANT PADDLE1-DIRECTION

: PADDLE1-IN ( -- ) 0 PADDLE1-DIRECTION C! ;
: PADDLE1-OUT ( -- ) TRUE PADDLE1-DIRECTION C! ;

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

#11322

"BruceMcF" <agila61@netscape.net> wrote in message
news:08a15fb8-be7c-4aac-8c0f-da5fb4038306@x17g2000yqj.googlegroups.com...
> On Apr 14, 5:22 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:
> > "BruceMcF" <agil...@netscape.net> wrote in message
> news:c3b5476f-e0b4-454b-ab11-53831f266156@h9g2000yqe.googlegroups.com...
> > > On Apr 13, 10:25 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
...

> > > > Bruce seems to have concocted a definition [for SET] that splits
> > > > [the] operation's two arguments (as humor I guess ...), but fits
> > > > better with Forth's definitions.
>
> > > No, not at humor at all. In the specification, "writes x to an addr"
> > > means writes the number it was defined with to ANY address that is
> > > handed to it.
>
> > Oh, ok. Well, ISTM that you basically (re)created ANS' TO functionality
> > but not SET as I read the syntax ...
> >
> > While I really "see" SET being used to program ports primarily, it could
> > be used in the context of VARIABLEs for clearing and setting, or to
> > clamp values to a specific range, e.g.:
> >
> > : SET CREATE SWAP , , DOES> DUP @ SWAP CELL+ @ ! ;
> >
> > VARIABLE APPLE
> > 1 APPLE !
> > 0 APPLE SET MINAPPLE
> > 15 APPLE SET MAXAPPLE
>
> That's why I figure the jokes on those who got handed that version of
> set:
>
> : MINAPPLE ( -- ) 0 APPLE ! ;
> : MAXAPPLE ( -- ) 15 APPLE ! ;

Well, those definitions are do-able even for a SET with only one fixed
argument - as you suggested ...  So, the jokes also on those who got handed
the other version of set too?  That's what you're saying, yes?  No ... ?
;-)

BTW, thanks for the 2@ use.


Rod Pemberton

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

#11325

On Apr 15, 12:53 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
> Well, those definitions are do-able even for a SET with only one fixed
> argument - as you suggested ...  So, the jokes also on those who got handed
> the other version of set too?  That's what you're saying, yes?  No ... ?
> ;-)

Don't forget the actual *factor* part of factoring, as in
factor*factor=product. Say you have 24 ports, all of the same basic
type, and each one has 8 possible standard settings.

24 SET-address words + 8 setting constants = 32 words.
24 port constants + 8 Set-value words = 32 words.
24 port address * 8 setting levels = 192 SET-address-and-value words.

In the old school roll your own assembler primitives to speed up inner
loops, all three SETs can have a runtime primitive DO_SET that would
be reasonably quick even on a 6502 system, or at least quick as far as
that processor could go, but the set-address version would have the
edge, eg:

DO_SET ; set-address, data stack on hardware stack
        LDY #2
        LDA (W),Y
        STA W+2
        INY
        LDA (W),Y
        STA W+3
        PLA
        LDY #0
        STA (W+2),Y
        INY
        PLA
        STA (W+2),Y
        JMP NEXT

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

#11256

On Apr 13, 10:25 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
> Bruce seems to have concocted a definition that splits the operation's two
> arguments (as humor I guess ...), but fits better with Forth's definitions.

I rather believe that there was some person who originally implemented
a broken version of SET and the joke was on everyone who inherited the
broken version of SET from them.

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

#11182

On 4/11/12 1:00 PM, Rod Pemberton wrote:
...
>> I also found a variety of bugs, mostly un-dropped stack values with
>> IF-ELSE-THENs around DO-LOOPs.

A good habit to cultivate is always checking your stack after compiling 
some Forth. Very easy way to catch such things, as well as omitted THENs 
and similar sins.

>> ...  I need to get to PICK and ROLL.

No, you don't.  Honest.  You can write excellent Forth for 30 years 
without using these words.

>> I should be able to do LSHIFT and RSHIFT now.  Also, FIND as Forth
>> text is still waiting for my attention ...  That leaves about 50 ANS core
>> and core extension words to do, by name at least.  Although, some of those
>> are obsolete.  Most of these seem to be related to doubles, "numeric
>> conversion", or "mass storage I/O".

The words beginning with 2 are for pairs of things, not necessarily 
doubles. They're very useful.

>> Although, many of my definitions
>> are not ANS compliant.  Some have different parameters, e.g., COMPARE,
>> while others used reduced definitions, e.g., SOURCE.

It's up to you, but they are what they are for a reason.

>> Since my interpreter is in C, I'm also thinking about implementing a Forth
>> word to load entire files of Forth source text via name.  This behavior is
>> already present to load the initial dictionary, but is not accessible from
>> Forth.  I'm thinking about calling it FLOAD if that's not in use ...
>>
>
> Apparently, FLOAD as I was imagining it would end up being nearly identical
> to ANS' INCLUDE , but with a slightly different syntax.  So, there may be no
> need for FLOAD ...

Yes, go with INCLUDE.

>> I also have a word that I named 'LAST which returns the CFA of the LAST
>> (or LATEST) word, i.e., ' of LAST, instead of the NFA (fig-Forth LATEST)
>> or the start of dictionary entry (Forth-83 LAST).  Is there another name
>> for this?  I've found I'm using it a bit for debugging, so I wondered if
>> there was a standard name.  I don't see any mention of LAST or LATEST
>> in Forth-79 or ANS-94 or related words.
>>
>
> Ok, it seems no one knows, or no one cares about 'LAST.

Well, most every system has a LAST, but exactly what it points to, 
returns, etc., varies from one implementation to another.

> And, I implemented a few more words ...  Oh, I seem to be on a tear now!
>
> SP! DP! RP! SP@ DEPTH ABS<=>= 2+ 2-
> 2ROT -2ROT NAND NOR .( LSHIFT RSHIFT
>
> I'm not sure how I missed .(  Also, implementing SEE may be an issue since I
> have some words without dictionary headers ...

No reason you can't SEE the words that do have headers.

> So, maybe 2VARIABLE 2CONSTANT 2LITERAL PICK and ROLL are up next.
> I need to look at :NONAME .  And, I need to find out if Forth-79 and
> Forth-83 word SET is still used.

Don't know SET. And I'm less than enthusiastic about PICK, ROLL and :NONAME.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#11187

On Apr 12, 12:00 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
> "Rod Pemberton" <do_not_h...@notemailnot.cmm> wrote in message
>
> news:jm1ic9$ktk$1@speranza.aioe.org...
>
>
>
>
>
>
>
>
>
> > "Rod Pemberton" <do_not_h...@notemailnot.cmm> wrote in message
> >news:jlbqb2$3a6$1@speranza.aioe.org...
> > > "Rod Pemberton" <do_not_h...@noavailemail.cmm> wrote in message
> > >news:jl5anb$p3i$1@speranza.aioe.org...
> > > > "Rod Pemberton" <do_not_h...@noavailemail.cmm> wrote in message
> > > >news:jkgbte$3f7$1@speranza.aioe.org...
> > > > ...
>
> > > > > unimplemented such as (?DO) and ?DO etc
>
> > > > Ok, DO and ?DO and related words (DO) and (?DO) are complete and work
> > > > with LOOP and +LOOP.
>
> > > Actually they had a couple of errors ...
>
> > > > Now, it's on to LEAVE, and testing POSTPONE, etc.
>
> > > POSTPONE works.  COMPILE, works.  RECURSE works.  DO ?DO LOOP
> > > +LOOP seem to be working correctly now ...  LEAVE is unimplemented.
> > > CELLS and CHARS still need * multiply which is simple and be a primitive
> > > or low-level word.  I just haven't gotten to it yet.
>
> > Well, I implemented some more words:
>
> > .S #TIB * / MOD /MOD 2* 2/ AHEAD DEPTH DUMP
> > ERASE MAX MIN MOVE SOURCE
>
> > So, the similar words FILL MOVE CMOVE ERASE are all completed.
>
> > In the process, I eliminated a few primitives and added others.  I only
> > need about four words to run a couple of Forth tests.  I also added Forth
> > text versions of CMOVE and LIT . LIT is still available internally as a
> > primitive and won't be eliminated due to dependence of the interpreter
> > upon it.  CMOVE is used only once internally as pre-compiled Forth.
> > So, it may be replaced by the Forth text version in the future.
>
> > I also found a variety of bugs, mostly un-dropped stack values with
> > IF-ELSE-THENs around DO-LOOPs.  LEAVE is still not implemented.
> > I might look at implenting SEE next.  I need to get to PICK and ROLL.
> > I should be able to do LSHIFT and RSHIFT now.  Also, FIND as Forth
> > text is still waiting for my attention ...  That leaves about 50 ANS core
> > and core extension words to do, by name at least.  Although, some of those
> > are obsolete.  Most of these seem to be related to doubles, "numeric
> > conversion", or "mass storage I/O".  Although, many of my definitions
> > are not ANS compliant.  Some have different parameters, e.g., COMPARE,
> > while others used reduced definitions, e.g., SOURCE.
>
> > Since my interpreter is in C, I'm also thinking about implementing a Forth
> > word to load entire files of Forth source text via name.  This behavior is
> > already present to load the initial dictionary, but is not accessible from
> > Forth.  I'm thinking about calling it FLOAD if that's not in use ...
>
> Apparently, FLOAD as I was imagining it would end up being nearly identical
> to ANS' INCLUDE , but with a slightly different syntax.  So, there may be no
> need for FLOAD ...
>
> > I also have a word that I named 'LAST which returns the CFA of the LAST
> > (or LATEST) word, i.e., ' of LAST, instead of the NFA (fig-Forth LATEST)
> > or the start of dictionary entry (Forth-83 LAST).  Is there another name
> > for this?  I've found I'm using it a bit for debugging, so I wondered if
> > there was a standard name.  I don't see any mention of LAST or LATEST
> > in Forth-79 or ANS-94 or related words.
>
> Ok, it seems no one knows, or no one cares about 'LAST.
>
> And, I implemented a few more words ...  Oh, I seem to be on a tear now!
>
> SP! DP! RP! SP@ DEPTH ABS <= >= 2+ 2-
> 2ROT -2ROT NAND NOR .( LSHIFT RSHIFT
>
> I'm not sure how I missed .(  Also, implementing SEE may be an issue since I
> have some words without dictionary headers ...
>
> So, maybe 2VARIABLE 2CONSTANT 2LITERAL PICK and ROLL are up next.
> I need to look at :NONAME .  And, I need to find out if Forth-79 and
> Forth-83 word SET is still used.
>
> Rod Pemberton

My version of SEE just displays a question mark when it comes across
headless words.

In case you're interested, and in the interests of giving, here's my
SEE.

Some words need to be treated as special cases, for example words with
in-line parameters, such as LIT (S") BRANCH 0BRANCH etc, so they have
to be trapped and dealt with according to their own special needs. For
example, my strings are compiled as (S") <length_byte> <string_data>
with a 0 padding byte on the end if necessary. SEE needs to know this
so that it can display the string in a friendly manner.

You're making great progress!

Mark

\ SEE - a Forth decompiler for TurboForth V1.1 by Mark Wills

        0 VALUE addr
    $8320 CONSTANT 'DOCOL
    $832E CONSTANT 'EXIT
    ' LIT CONSTANT 'LIT
 ' BRANCH CONSTANT 'BRANCH
' 0BRANCH CONSTANT '0BRANCH
   ' (S") CONSTANT '(S")
   CHAR " CONSTANT ""
        0 VALUE saddr

: addr+2   ( --) 2 +TO addr ; \ point to next word (16 bit)

\ if the word name won't fit on the current line then new line
: wrap ( word_len --)
  DUP XY? DROP + XMAX >= IF CR THEN ;

\ display the name of the word
: .name ( --)
  >LINK ?DUP IF
    2+ DUP @ 15 AND SWAP 2+ SWAP wrap TYPE 2 SPACES
  ELSE
    ." ?  "
  THEN ;

: .lit ( --)
  addr+2 addr @ ." $" $. ; \ display a literal value

: .addr ( --)
  addr+2 addr @ . ; \ display a relative address

\ display a string, adjust address pointer accordingly
: .str ( --)
  addr+2 addr DUP C@ DUP . SWAP 1+ SWAP "" EMIT TYPE
  "" EMIT 2 SPACES addr C@ +TO addr addr 2+ $FFFE AND TO addr ;

\ process special cases eg. literals, relative addresses etc
: specials ( --)   addr @ CASE
    'LIT     OF .lit  ENDOF
    'BRANCH  OF .addr ENDOF
    '0BRANCH OF .addr ENDOF
    '(S")    OF .str  ENDOF
  ENDCASE ;


: SEE ( "word" --)
  CR ' DUP TO addr  DUP >LINK TO saddr
  IF CR
    \ word is in the dictionary
    addr @ 'DOCOL = IF
        \ word is a colon definition...
        \ check if the word is immediate...
        saddr 2+ @ $8000 AND IF ." *IMMEDIATE* " CR THEN
        \ report dictionary and code start addresses...
        ." Starts:$" saddr $. ."  Code starts:$" addr $.
        \ show name of word (e.g. : FRED)...
        CR  ." : " addr .name CR addr+2
        \ run in a loop until we hit the EXIT opcode...
        BEGIN addr @ 'EXIT <> WHILE
            \ opcode is not EXIT, so look it up and display it
            addr @ .name  specials  addr+2
            BEGIN KEY? -1 = UNTIL
        REPEAT  ." ;"
        \ report the size of the word...
        addr+2 CR ." Size:" addr saddr - . ." bytes"
    ELSE
        ." Assembly language word or data @ $" addr $.
    THEN
  ELSE
    ." not found"
  THEN CR
;

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

#11204

"Mark Wills" <markrobertwills@yahoo.co.uk> wrote in message
news:0ef2ce80-860e-49c6-be24-1f70d82f7818@w5g2000vbp.googlegroups.com...
> On Apr 12, 12:00 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:
...

> > Also, implementing SEE may be an issue since I
> > have some words without dictionary headers ...
>
> My version of SEE just displays a question mark when it
> comes across headless words.

Actually, I'm not sure yet how I'm going to detect the end of a definition.
AFAICT, the value for my low-level NEXT/EXIT primitive can't be reliably
detected since someone could store the same value as data within a word or
even compile EXIT into the word as part of the definition ...  I.e., if you
have a string which is null terminated and it has embedded null's how do you
detect the end of string?  As I've currently implemented things, detecting
the end of the address list will have the same issue.

Detecting primitives may also be a slight problem.  I.e., SEE, if coded for
high-level words, would expect a body of addresses, but the primitive won't
have a body.  I don't have bit in the dictionary indicating that they are
primitives.  I'll probably have to check for the CFA field being ENTER or
not.

> In case you're interested, and in the interests of giving,
> here's my SEE.

Ok.  Thanks.  I try to remember to post mine, if it's not too specialized to
my Forth.  I was thinking about using a variation of my WORDS word as the
initial basis for mine ...  That would probably only work for very "clean"
high-level words, no inlined data, with dictionary header, no primitives in
the definition, etc.  That'd probably blow-up on DOES> code too ...

Yeah, SEE is beginning to sound more complicated ...

> Some words need to be treated as special cases, for example words
> with in-line parameters, such as LIT (S") BRANCH 0BRANCH etc,
> so they have to be trapped and dealt with according to their own special
> needs. For example, my strings are compiled as (S") <length_byte>
> <string_data> with a 0 padding byte on the end if necessary. SEE needs
> to know this so that it can display the string in a friendly manner.

True.  Any inlined data in compiled words will be another implementation
issue for SEE.

> You're making great progress!

Congrats on finishing yours!


Rod Pemberton

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

#11219

On Apr 12, 6:54 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
> "Mark Wills" <markrobertwi...@yahoo.co.uk> wrote in message
>
> news:0ef2ce80-860e-49c6-be24-1f70d82f7818@w5g2000vbp.googlegroups.com...> On Apr 12, 12:00 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> > wrote:
>
> ...
>
> > > Also, implementing SEE may be an issue since I
> > > have some words without dictionary headers ...
>
> > My version of SEE just displays a question mark when it
> > comes across headless words.
>
> Actually, I'm not sure yet how I'm going to detect the end of a definition.
> AFAICT, the value for my low-level NEXT/EXIT primitive can't be reliably
> detected since someone could store the same value as data within a word or
> even compile EXIT into the word as part of the definition ...  I.e., if you
> have a string which is null terminated and it has embedded null's how do you
> detect the end of string?  As I've currently implemented things, detecting
> the end of the address list will have the same issue.
>
> Detecting primitives may also be a slight problem.  I.e., SEE, if coded for
> high-level words, would expect a body of addresses, but the primitive won't
> have a body.  I don't have bit in the dictionary indicating that they are
> primitives.  I'll probably have to check for the CFA field being ENTER or
> not.
>
> > In case you're interested, and in the interests of giving,
> > here's my SEE.
>
> Ok.  Thanks.  I try to remember to post mine, if it's not too specialized to
> my Forth.  I was thinking about using a variation of my WORDS word as the
> initial basis for mine ...  That would probably only work for very "clean"
> high-level words, no inlined data, with dictionary header, no primitives in
> the definition, etc.  That'd probably blow-up on DOES> code too ...
>
> Yeah, SEE is beginning to sound more complicated ...
>
> > Some words need to be treated as special cases, for example words
> > with in-line parameters, such as LIT (S") BRANCH 0BRANCH etc,
> > so they have to be trapped and dealt with according to their own special
> > needs. For example, my strings are compiled as (S") <length_byte>
> > <string_data> with a 0 padding byte on the end if necessary. SEE needs
> > to know this so that it can display the string in a friendly manner.
>
> True.  Any inlined data in compiled words will be another implementation
> issue for SEE.
>
> > You're making great progress!
>
> Congrats on finishing yours!
>
> Rod Pemberton

Detecting native words is of course implementation specific. I'm not
sure how you have implemented your system, IIRC it's ITC code. In that
case, don't bother detecting code words, rather concentrate on
detecting colon definitions. If it's a colon definition, then it's
*not* a code definition, if you see what I mean! ;-)

In my system, this code:

: FRED 1 2 3 ;

Produces the following:

<plink> 4 F R E D  DOCOL  LIT 1  LIT 2  LIT 3  EXIT

<plink> is the address of the previous entry in the dictionary (it
points to the plink field of the previous entry). Next comes the
length of the name of the word (4) (some bits are also used for
immediate, hidden etc) - a cell wide.

Then comes the name of the word - four ascii characters.

Then the key to it: DOCOL (sometimes called NEST). DOCOL is compiled
at the start of all colon definitions. So, my SEE looks up the plink
address of a word (>LINK in my code) then reads the length to work out
where the CFA is going to be. It then reads it and sees if the value
in that cell represents the DOCOL opcode. If it does, it's a colon
definition, we're good to go. If not, it's something else, and you're
on your own! It then walks along the definition cell to cell, doing
dictionary lookups to get the name of the word. It stops when it hits
an EXIT opcode (UN-NEST).

Hopefully your structure is something similar; you'll have something
at the start of all colon defs to trigger a push to the return stack,
and something at the end to do a pop.

I've no idea how this stuff works on native compiling systems, or if
it's even possible!

Mark

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

#11195

On Apr 11, 7:00 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
>> I also have a word that I named 'LAST which returns the CFA of the LAST
>> (or LATEST) word, i.e., ' of LAST, instead of the NFA (fig-Forth LATEST)
>> or the start of dictionary entry (Forth-83 LAST).  Is there another name
>> for this?  I've found I'm using it a bit for debugging, so I wondered if
>> there was a standard name.  I don't see any mention of LAST or LATEST
>> in Forth-79 or ANS-94 or related words.

> Ok, it seems no one knows, or no one cares about 'LAST.

They are not standardized because they are implementation specific:
Forth94 is compatible with a wide variety of dictionary implementation
models. Forth93 specified a lot of implementation details that then
became obsolete within the following decade, and the Forth94 TC did
not try for an implementation specification, but rather a
specification of what a source could expect from a variety of
implementations. There's a lot of areas where its a matter of
objectives and preferences of the implementer, so long as the behavior
of the standardized word fits what a portable source is promised.

Whether or not your general name token is the address of the beginning
of the dictionary entry or an address somewhere within, the
implementation has to be able to somehow resolve the xt for a name
token. So if that action is generically called NAME>XT and if you are
holding the name token of the most recently defined word in LAST then:
   : LAST>XT ( -- xt ) LAST @ NAME>XT ;

... would be an obvious factor if you use the phrase "LAST @ NT>XT" in
a few different places. If you want to call it 'LAST that is, of
course, fine.

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

#11199 — Re: A short history of the stages of development and status of RP's Forth interpreter.

BruceMcF <agila61@netscape.net> writes:
>>> =A0I don't see any mention of LAST or LATEST
>>> in Forth-79 or ANS-94 or related words.
>
>> Ok, it seems no one knows, or no one cares about 'LAST.
>
>They are not standardized because they are implementation specific:

Actually, they are implementation specific because they are not
standardized.

>Forth94 is compatible with a wide variety of dictionary implementation
>models.

And LAST/LATEST, and 'LAST are, too.

My guess is that LAST/LATEST was not standardized because their result
(NFA, name token, whatever) and what one can do with it was not
standardized (i.e., one would have to standardize a number of
additional words).  For 'LAST, my guess is that there was not enough
existing practice; this thread is the first time I read about 'LAST.

>   : LAST>XT ( -- xt ) LAST @ NAME>XT ;
>
>... would be an obvious factor if you use the phrase "LAST @ NT>XT" in
>a few different places. If you want to call it 'LAST that is, of
>course, fine.

In Gforth, we have LASTXT ( -- xt ), which produces the xt of the last
word.  It works even for unnamed words, for which LAST @ produces 0,
and for which LAST @ NAME>INT therefore does not work:

: bla ;   ok
last @ hex. $7FFFF6A442D0  ok
:noname ;  ok
hex. $7FFFF6A44300  ok
lastxt hex. $7FFFF6A44300  ok
last @ hex. $0  ok

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2011: http://www.euroforth.org/ef11/

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

#11203 — Re: A short history of the stages of development and status of RP's Forth interpreter.

"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2012Apr12.170151@mips.complang.tuwien.ac.at...
...

> [...] this thread is the first time I read about 'LAST.
>

I implemented it for my Forth for testing.  Apparently, I created it too or
just the name ...

My LAST returns address of the LFA.  LINK> does LFA to CFA.

: 'LAST ( -- CFA ) LAST @ LINK> ;

I use it for in testing with EXECUTE , DUMP , XDUMP , and ID. .  ID. prints
the name of a definition.  I recently noticed .name .  I'll have to check
which standards use that, if any.  XDUMP is an enhanced DUMP which expands
the dictionary header and body and is not coded in Forth, i.e., in C ...  It
should also be able to be used with COMPILE , [COMPILE] , COMPILE, or
POSTPONE , since my CFA field is or is basically the equivalent of an "xt".

: T 1 . ;

If T is the most recent definition, then ' (tick) T is the same as 'LAST .

1)
  'LAST EXECUTE
  1

2)
  'LAST ID.
  T

3)
  'LAST 10 DUMP

  ( starting at CFA )
  blah blah blah blah ...


4)
  'LAST XDUMP

LFA blah blah
NFA "T"
CFA blah blah
PFA blab blah ... body ...
etc.


Rod Pemberton

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

#11206

I take it that you disagree with direction of cause and effect, and
are saying that the reason that the implementation-specific difference
exist is because this was not standardized ... but I don't see how
this supports that argument:

On Apr 12, 11:01 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> My guess is that LAST/LATEST was not standardized because their result
> (NFA, name token, whatever) and what one can do with it was not
> standardized (i.e., one would have to standardize a number of
> additional words).

The implementation specific differences already existed in the 1980's,
so the standardization in the 90's causing them seems a bit
implausible.

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

#11213

On 4/12/12 7:49 AM, BruceMcF wrote:
> I take it that you disagree with direction of cause and effect, and
> are saying that the reason that the implementation-specific difference
> exist is because this was not standardized ... but I don't see how
> this supports that argument:
>
> On Apr 12, 11:01 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> wrote:
>> My guess is that LAST/LATEST was not standardized because their result
>> (NFA, name token, whatever) and what one can do with it was not
>> standardized (i.e., one would have to standardize a number of
>> additional words).
>
> The implementation specific differences already existed in the 1980's,
> so the standardization in the 90's causing them seems a bit
> implausible.

Not to mention that standardizing LAST would have implied some things 
about implementation that the Forth94 TC was trying very hard not to do. 
The purpose of a standard should be to define the interface between a 
system and an application. Applications have little use for LAST or 
other peculiarities of dictionary navigation.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#11216

On Apr 12, 2:40 pm, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> Not to mention that standardizing LAST would have implied some things
> about implementation that the Forth94 TC was trying very hard not to do.

A better path, I think, to get at what I was trying to say ~ its not
implementation-specific because the Forth94 TC just didn't happen to
get around to standardizing it, but rather it was a deliberate choice
that it was the kind of thing to leave as implementation-specific.

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

#11228

On 4/12/12 9:38 AM, BruceMcF wrote:
> On Apr 12, 2:40 pm, "Elizabeth D. Rather"<erat...@forth.com>  wrote:
>> Not to mention that standardizing LAST would have implied some things
>> about implementation that the Forth94 TC was trying very hard not to do.
>
> A better path, I think, to get at what I was trying to say ~ its not
> implementation-specific because the Forth94 TC just didn't happen to
> get around to standardizing it, but rather it was a deliberate choice
> that it was the kind of thing to leave as implementation-specific.

Correct. Well put.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#11240 — Re: A short history of the stages of development and status of RP's Forth interpreter.

BruceMcF <agila61@netscape.net> writes:
>I take it that you disagree with direction of cause and effect

No, I actually wanted to point out that "is implementation-specific"
is synonymous with "is not standardized".

>On Apr 12, 11:01=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> My guess is that LAST/LATEST was not standardized because their result
>> (NFA, name token, whatever) and what one can do with it was not
>> standardized (i.e., one would have to standardize a number of
>> additional words).
>
>The implementation specific differences already existed in the 1980's,

What implementation-specific differences?  The names (LAST
vs. LATEST)?  The stack effect (whether it returns the actual token or
the address of a cell containing that value)?  How a dictionary is
represented?  Sure, they exist, but are not insurmountable obstacles,
just like differences in existing file handling words and the
underlying file data structures did not prevent the TC from
standardizing the FILE wordset.

Any Forth system that implements IMMEDIATE implements the
functionality of LAST/LATEST in some way.  Any Forth system that
implements RECURSE implements the functionality of LASTXT/'LAST in
some way.  Since both are CORE words, any Forth-94 and Forth-200x
system implements this functionality.  Giving standardized access to
that functionality would be in in the spirit of not burying your
tools.

In the Forth-200x process there were certainly no technical reasons
for not standardizing this functionality.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2011: http://www.euroforth.org/ef11/

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

#11257

On Apr 13, 6:42 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

> What implementation-specific differences?  The names (LAST
> vs. LATEST)?  The stack effect (whether it returns the actual token or
> the address of a cell containing that value)?  How a dictionary is
> represented?  Sure, they exist, but are not insurmountable obstacles,
> just like differences in existing file handling words and the
> underlying file data structures did not prevent the TC from
> standardizing the FILE wordset.

Yes. None of which reverses the direction of cause and effect, but it
does warn against an overly simplistic picture of the process at work.

One has to first frame the existing implementation-specific
differences as a source of problems for portable application code
before those implementation-specific differences take on the status of
obstacles to standardization. And how an industry standardization
working committee frames the standardization challenges facing it is
not likely to be a simple mechanistic process.

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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

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

csiph-web