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

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

:NONAME

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

Contents

  :NONAME Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-12 13:48 -0700
    Re: :NONAME Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-12 23:08 +0100
    Re: :NONAME Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-12 16:53 -0500
      Re: :NONAME The Beez <the.beez.speaks@gmail.com> - 2012-04-12 23:50 -0700
      Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-04-13 05:34 -0700
        Re: :NONAME Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-13 08:02 -0500
          Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-04-13 07:26 -0700
    Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-04-12 14:54 -0700
      Re: :NONAME Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-12 23:58 -0700
        Re: :NONAME "Elizabeth D. Rather" <erather@forth.com> - 2012-04-12 21:11 -1000
          Re: :NONAME Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-04-22 23:13 -0700
        Re: :NONAME Ian Osgood <iano@quirkster.com> - 2012-04-13 04:31 -0700
          Re: :NONAME Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-13 19:40 +0000
        Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-04-13 05:15 -0700
        Re: :NONAME Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-13 08:00 -0500
          Re: :NONAME Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-13 06:19 -0700
            Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-04-13 07:33 -0700
    Re: :NONAME "Elizabeth D. Rather" <erather@forth.com> - 2012-04-12 13:54 -1000
      Re: :NONAME "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-13 11:54 -0400
        Re: :NONAME Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-13 10:23 -0700
        Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-04-13 13:02 -0700
        Re: :NONAME Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-13 13:06 -0700
          Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-04-13 15:57 -0700
          Re: :NONAME Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-14 01:05 +0000
          Re: :NONAME "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-14 17:23 -0400
            Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-04-14 16:22 -0700
              Re: :NONAME "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-15 12:50 -0400
                Re: :NONAME "Elizabeth D. Rather" <erather@forth.com> - 2012-04-15 08:12 -1000
                Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-04-15 11:17 -0700
          Re: :NONAME Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-04-17 16:21 -0700
        Re: :NONAME "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-06-01 20:13 -0400
          Re: :NONAME "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-06-01 21:09 -0400
            Re: :NONAME "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-06-01 21:41 -0400
              Re: :NONAME Coos Haak <chforth@hccnet.nl> - 2012-06-02 15:06 +0200
                Re: :NONAME "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-06-11 05:42 -0400
                  Re: :NONAME Coos Haak <chforth@hccnet.nl> - 2012-06-11 19:08 +0200
          Re: :NONAME "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-06-11 05:46 -0400
            Re: :NONAME Alex McDonald <blog@rivadpm.com> - 2012-06-11 03:46 -0700
            Re: :NONAME Josh Grams <josh@qualdan.com> - 2012-06-11 12:17 +0000
              Re: :NONAME Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-12 01:09 +0000
                Re: :NONAME "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-06-11 21:39 -0400
                  Re: :NONAME Alex McDonald <blog@rivadpm.com> - 2012-06-12 02:08 -0700
                    Re: :NONAME "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-06-12 23:20 -0400
                      Re: :NONAME Alex McDonald <blog@rivadpm.com> - 2012-06-13 00:32 -0700
                      Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-06-13 10:25 -0700
                        Re: :NONAME Coos Haak <chforth@hccnet.nl> - 2012-06-14 19:24 +0200
                          Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-06-15 07:05 -0700
                            Re: :NONAME Coos Haak <chforth@hccnet.nl> - 2012-06-15 20:40 +0200
                              Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-06-15 11:56 -0700
                                Re: :NONAME Coos Haak <chforth@hccnet.nl> - 2012-06-15 21:15 +0200
                                  Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-06-15 12:43 -0700
                        Re: :NONAME "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-06-14 20:31 -0400
                          Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-06-15 07:03 -0700
                            Re: :NONAME "Rod Pemberton" <do_not_have@notemailntt.cmm> - 2012-06-19 21:10 -0400
                          Re: :NONAME Coos Haak <chforth@hccnet.nl> - 2012-06-15 20:45 +0200
                Re: :NONAME BruceMcF <agila61@netscape.net> - 2012-06-12 16:00 -0700
                  Re: :NONAME Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-13 08:49 +0000

Page 3 of 3 — ← Prev page 1 2 [3]

#12914

"Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in message
news:m5hckc.1ee@spenarnc.xs4all.nl...
...

> For indirect threaded code the code address
> is docol (the inner interpreter) and there needs
> to be some pointer to the threaded code too.
>
> The best solution for Rod is just make dummy headers for
> his indirect threaded Forth.

The dual variable method they suggested should work, but I'd rather not
create another system variable ...

System variables have some C dependence, whereas the dictionary header
doesn't.  Not needing a header will save space in the dictionary, but
otherwise it doesn't seem that much is gained by not having a header.  Any
code that updates both last xt variables, e.g., the code for : (colon) or
CREATE, also becomes longer, slower.  I don't like wasting space for an
unneeded header or even DOES> link, but I've got plenty of space available
and my header is compact...

Just how many times is :NONAME going to be used in a typical program
anyway? My guess is not very many times.  Who bothers to use it instead of
: (colon)?  E.g., seems to be special case usage to me...

Also, making sure SMUDGE and IMMEDIATE don't accidentally or even
temporarily corrupt another definition seems like a good thing to me.  Since
my SMUDGE is XOR based, I considered letting it corrupt and uncorrupt data
in the prior definition.  However, that word was IMMEDIATE and used in the
current definition... boom!

> I'm very content with my 100% percent consistent headers
> and the careful names such that the most essential fields come first
> alphabetically:
>
>  CFA
>  DFA
>  FFA
>  LFA
>  NFA
>  SFA
>  XFA
>
> Yes they cost 56 bytes plus the name itself.
>

Originally, I had the NFA and bits first, then switched to LFA first, then
had to switch back temporarily due to implementation issues.

Currently, I'm using 48 bytes for the header, including the name (fixed
size).  However, I've placed a few fields into the body:

\ header
LFA  (link field pointer)
BIT    (name field bits)
NFA  (name field)
PTR  (address of CFA)

\ body
DSL  (for DOES>)
CFA  (Forth action - C function)
PFA  (variable size, Forth address list)

The header and body are mostly adjacent, but can be located separately.  PTR
points to or holds the address of the CFA, not the body.  This allows the C
compiler to control the organization of internal, pre-compiled Forth words
coded in C.   E.g., the C compiler can place the body above the header.
Primitives, or low-level words, use a different format for the body, just a
CFA field, but they could be setup to use the same...

Having the link field also be the starting address of the dictionary header
simplifies locating the other fields, IMO.  No searching for set bits on
name and just offsets.  Of course, if you only have the CFA you can't easily
find the header via Forth code, e.g., to get the name.  You have to search
the entire list via LFA checking that PTR matches CFA.  I decided a second
link from body to header wasn't really needed for this, i.e., low-use...


Rod Pemberton

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

#12923

On Jun 12, 2:39 am, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "Albert van der Horst" <alb...@spenarnc.xs4all.nl> wrote in messagenews:m5hckc.1ee@spenarnc.xs4all.nl...
> ...
>
> > For indirect threaded code the code address
> > is docol (the inner interpreter) and there needs
> > to be some pointer to the threaded code too.
>
> > The best solution for Rod is just make dummy headers for
> > his indirect threaded Forth.
>
> The dual variable method they suggested should work, but I'd rather not
> create another system variable ...

Then make it a 2variable.

>
> System variables have some C dependence, whereas the dictionary header
> doesn't.  Not needing a header will save space in the dictionary, but
> otherwise it doesn't seem that much is gained by not having a header.  Any
> code that updates both last xt variables, e.g., the code for : (colon) or
> CREATE, also becomes longer, slower.  I don't like wasting space for an
> unneeded header or even DOES> link, but I've got plenty of space available
> and my header is compact...

I don't think you'll be able to measure it; how much compile time vs
run time do you expect? Will having headers for :NONAME be more
expensive in terms of space that an extra variable?

>
> Just how many times is :NONAME going to be used in a typical program
> anyway? My guess is not very many times.  Who bothers to use it instead of
> : (colon)?  E.g., seems to be special case usage to me...
>
> Also, making sure SMUDGE and IMMEDIATE don't accidentally or even
> temporarily corrupt another definition seems like a good thing to me.  Since
> my SMUDGE is XOR based, I considered letting it corrupt and uncorrupt data
> in the prior definition.  However, that word was IMMEDIATE and used in the
> current definition... boom!

That sounds like an implementation error or weakness in the internal
structure of the compiler.

>
> > I'm very content with my 100% percent consistent headers
> > and the careful names such that the most essential fields come first
> > alphabetically:
>
> >  CFA
> >  DFA
> >  FFA
> >  LFA
> >  NFA
> >  SFA
> >  XFA
>
> > Yes they cost 56 bytes plus the name itself.
>
> Originally, I had the NFA and bits first, then switched to LFA first, then
> had to switch back temporarily due to implementation issues.
>
> Currently, I'm using 48 bytes for the header, including the name (fixed
> size).  However, I've placed a few fields into the body:
>
> \ header
> LFA  (link field pointer)
> BIT    (name field bits)

What does this contain?

> NFA  (name field)
> PTR  (address of CFA)
>
> \ body
> DSL  (for DOES>)

What is this for?

> CFA  (Forth action - C function)
> PFA  (variable size, Forth address list)

What does this point to?

>
> The header and body are mostly adjacent, but can be located separately.  PTR
> points to or holds the address of the CFA, not the body.  This allows the C
> compiler to control the organization of internal, pre-compiled Forth words
> coded in C.   E.g., the C compiler can place the body above the header.
> Primitives, or low-level words, use a different format for the body, just a
> CFA field, but they could be setup to use the same...
>
> Having the link field also be the starting address of the dictionary header
> simplifies locating the other fields, IMO.  No searching for set bits on
> name and just offsets.  Of course, if you only have the CFA you can't easily
> find the header via Forth code, e.g., to get the name.  You have to search
> the entire list via LFA checking that PTR matches CFA.  I decided a second
> link from body to header wasn't really needed for this, i.e., low-use...
>

Headers are all different, but both of these seem to be in the
heavyweight category. My Forth header is 23 bytes plus name, and that
is with a link, a dual XT to support smart COMPILE, sufficient space
to record stack effects, and the line and file that the word came
from.

> Rod Pemberton

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

#12951

"Alex McDonald" <blog@rivadpm.com> wrote in message
news:fc93f094-74d9-42f0-9b26-9f4e090a619a@l32g2000yqc.googlegroups.com...
> On Jun 12, 2:39 am, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> wrote:
> > "Albert van der Horst" <alb...@spenarnc.xs4all.nl> wrote in
> > messagenews:m5hckc.1ee@spenarnc.xs4all.nl...

> > > [snip]
> >
> > Just how many times is :NONAME going to be used in a typical program
> > anyway? My guess is not very many times. Who bothers to use it instead
> > of : (colon)? E.g., seems to be special case usage to me...
> >
> > Also, making sure SMUDGE and IMMEDIATE don't accidentally or even
> > temporarily corrupt another definition seems like a good thing to me.
> > Since my SMUDGE is XOR based, I considered letting it corrupt and
> > uncorrupt data in the prior definition. However, that word was IMMEDIATE
> > and used in the current definition... boom!
>
> That sounds like an implementation error or weakness in the internal
> structure of the compiler.

It's fixed now.  I created a mostly blank header for :NONAME words.

But, that was in the context that I have a single LAST, which you replied
about a "LATEST-XT" and "LAST-NAMED-XT".  I thought you replied
appropriately, but stated again:

If LAST works like "LAST-NAMED-XT" (which it did) and :NONAME doesn't have a
header, then SMUDGE corrupting data is not an issue.  SMUDGE works on a
valid header.  But, then my RECURSE which used LAST didn't work on the
correct word.

If LAST works like "LATEST-XT" (which it does now) and :NONAME doesn't have
a header, then SMUDGE corrupting data is an issue.  SMUDGE is offset based
and works where the header would be if present, but :NONAME doesn't have
header.  So, it corrupts data, although if XOR based it undoes it, i.e.,
temporary.

If LAST works like "LATEST-XT" (which it does now) and :NONAME does have a
header, then SMUDGE corrupting data is not an issue and RECURSE using LAST
works too.

> > Currently, I'm using 48 bytes for the header, including the name (fixed

> > size). However, I've placed a few fields into the body:
> >
> > \ header
> > LFA (link field pointer)
> > BIT (name field bits)
>
> What does this contain?

You're not interested in Albert's header?  :-)  I can guess at some of his
abbreviations, but I don't know what they're for.

It's classic fig-Forth usage...  I just didn't know what to name it.

BIT contains 8-bits of which 3 are currently used.  Bit7 (the MSB) is set
but not used anywhere, currently.  Bit6 is the precedence bit used by
IMMEDIATE.  Bit 5 is the SMUDGE bit.

Bit7 was originally used to find the start of a dictionary entry name field.
I use the LFA instead.  I plan on using the classic fig-Forth interpreter
loop, or something closer to it than what I've got now.  fig-Forth used the
Bit7 for a comparison.  So, it maybe used eventually.

The other bits might be used for compile-only or no-execute or created-word.
I think I've eliminated the need for marking created words for >BODY.  I.e.,
layouts the same whethere CREATEd or not.

> > NFA (name field)
> > PTR (address of CFA)
> >
> > \ body
> > DSL (for DOES>)
>
> What is this for?

This is a field for the address of where the DOES> code is located for
a word created by CREATE ... DOES> .

BruceMcF (Bruce McFarland) discussed this with me in "dot-quote
implementation question" thread.

FYI, I had already implemented the separation of the header and body before
inserting that field...

> > CFA (Forth action - C function)
> > PFA (variable size, Forth address list)
>
> What does this point to?

Nothing.

Technically, I guess it's the "PF area" and not PFA, or perhaps a bunch of
PFAs...  Ms. ER mentions that too.  It's just the area of compiled addresses
for a compiled high-level word.  I'm assuming one of Albert's is an "area"
too.

> > > Yes the [header] cost [is] 56 bytes plus the name itself.
> > >
> > Currently, I'm using 48 bytes for the header [...]

Sorry, that's 48 bytes for header and the DSL and CFA...  They are both
non-body data, but not part of my header, officially.  So, without them,
it's 40 bytes, or 8 bytes without the name and bit-fields.

> Headers are all different, but both of these seem to
> be in the heavyweight category.

Well, neither of us stated the size of integers or pointers.  Mine are 4
bytes (32-bits).

Perhaps, it's better to state the fields size independently.  So, my header
is two pointers, a name field, and a byte for control bits.  If I include
the CFA and DSL fields, that's four pointers, a name field, and a byte, for
all the non-body data.

> My Forth header is 23 bytes plus name, and that
> is with a link, a dual XT to support smart COMPILE,
> sufficient space to record stack effects, and the line
> and file that the word came from.

Just to be clear, is "plus" inclusive or exclusive?  By "plus", you mean to
"add" the name length, not "plus" as in already "includes" the name length,
yes?  That goes for Albert too...


Rod Pemberton

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

#12958

On Jun 13, 4:20 am, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "Alex McDonald" <b...@rivadpm.com> wrote in message
>
> news:fc93f094-74d9-42f0-9b26-9f4e090a619a@l32g2000yqc.googlegroups.com...
>
>
>
>
>
>
>
>
>
> > On Jun 12, 2:39 am, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> > wrote:
> > > "Albert van der Horst" <alb...@spenarnc.xs4all.nl> wrote in
> > > messagenews:m5hckc.1ee@spenarnc.xs4all.nl...
> > > > [snip]
>
> > > Just how many times is :NONAME going to be used in a typical program
> > > anyway? My guess is not very many times. Who bothers to use it instead
> > > of : (colon)? E.g., seems to be special case usage to me...
>
> > > Also, making sure SMUDGE and IMMEDIATE don't accidentally or even
> > > temporarily corrupt another definition seems like a good thing to me.
> > > Since my SMUDGE is XOR based, I considered letting it corrupt and
> > > uncorrupt data in the prior definition. However, that word was IMMEDIATE
> > > and used in the current definition... boom!
>
> > That sounds like an implementation error or weakness in the internal
> > structure of the compiler.
>
> It's fixed now.  I created a mostly blank header for :NONAME words.
>
> But, that was in the context that I have a single LAST, which you replied
> about a "LATEST-XT" and "LAST-NAMED-XT".  I thought you replied
> appropriately, but stated again:
>
> If LAST works like "LAST-NAMED-XT" (which it did) and :NONAME doesn't have a
> header, then SMUDGE corrupting data is not an issue.  SMUDGE works on a
> valid header.  But, then my RECURSE which used LAST didn't work on the
> correct word.
>
> If LAST works like "LATEST-XT" (which it does now) and :NONAME doesn't have
> a header, then SMUDGE corrupting data is an issue.  SMUDGE is offset based
> and works where the header would be if present, but :NONAME doesn't have
> header.  So, it corrupts data, although if XOR based it undoes it, i.e.,
> temporary.
>
> If LAST works like "LATEST-XT" (which it does now) and :NONAME does have a
> header, then SMUDGE corrupting data is not an issue and RECURSE using LAST
> works too.
>
> > > Currently, I'm using 48 bytes for the header, including the name (fixed
> > > size). However, I've placed a few fields into the body:
>
> > > \ header
> > > LFA (link field pointer)
> > > BIT (name field bits)
>
> > What does this contain?
>
> You're not interested in Albert's header?  :-)  I can guess at some of his
> abbreviations, but I don't know what they're for.
>
> It's classic fig-Forth usage...  I just didn't know what to name it.
>
> BIT contains 8-bits of which 3 are currently used.  Bit7 (the MSB) is set
> but not used anywhere, currently.  Bit6 is the precedence bit used by
> IMMEDIATE.  Bit 5 is the SMUDGE bit.
>
> Bit7 was originally used to find the start of a dictionary entry name field.
> I use the LFA instead.  I plan on using the classic fig-Forth interpreter
> loop, or something closer to it than what I've got now.  fig-Forth used the
> Bit7 for a comparison.  So, it maybe used eventually.
>
> The other bits might be used for compile-only or no-execute or created-word.
> I think I've eliminated the need for marking created words for >BODY.  I.e.,
> layouts the same whethere CREATEd or not.
>
> > > NFA (name field)
> > > PTR (address of CFA)
>
> > > \ body
> > > DSL (for DOES>)
>
> > What is this for?

Does this work in your Forth?

: doubledoes create , does> @ 1+ . does> @ 1- . ;  ok
20 doubledoes x  ok
x 21  ok
x 19  ok
x 19  ok


>
> This is a field for the address of where the DOES> code is located for
> a word created by CREATE ... DOES> .
>
> BruceMcF (Bruce McFarland) discussed this with me in "dot-quote
> implementation question" thread.
>
> FYI, I had already implemented the separation of the header and body before
> inserting that field...
>
> > > CFA (Forth action - C function)
> > > PFA (variable size, Forth address list)
>
> > What does this point to?
>
> Nothing.
>
> Technically, I guess it's the "PF area" and not PFA, or perhaps a bunch of
> PFAs...  Ms. ER mentions that too.  It's just the area of compiled addresses
> for a compiled high-level word.  I'm assuming one of Albert's is an "area"
> too.
>
> > > > Yes the [header] cost [is] 56 bytes plus the name itself.
>
> > > Currently, I'm using 48 bytes for the header [...]
>
> Sorry, that's 48 bytes for header and the DSL and CFA...  They are both
> non-body data, but not part of my header, officially.  So, without them,
> it's 40 bytes, or 8 bytes without the name and bit-fields.
>
> > Headers are all different, but both of these seem to
> > be in the heavyweight category.
>
> Well, neither of us stated the size of integers or pointers.  Mine are 4
> bytes (32-bits).
>
> Perhaps, it's better to state the fields size independently.  So, my header
> is two pointers, a name field, and a byte for control bits.  If I include
> the CFA and DSL fields, that's four pointers, a name field, and a byte, for
> all the non-body data.
>
> > My Forth header is 23 bytes plus name, and that
> > is with a link, a dual XT to support smart COMPILE,
> > sufficient space to record stack effects, and the line
> > and file that the word came from.
>
> Just to be clear, is "plus" inclusive or exclusive?  By "plus", you mean to
> "add" the name length, not "plus" as in already "includes" the name length,
> yes?  That goes for Albert too...

23 bytes exclusive of the name with a 32bit ptrs.

begin-structure head%
  6 cells - 1+         \ most words return head.nfa
  lfield: head.link    \        [ link field       ]     lfa
  lfield: head.comp    \        [ ' xt-call,       ]     comp token;
normally xt-call,
  lfield: head.ct      \        [ ' (compile)      ]     ct: compile
token action
  lfield: head.xtptr   \  +---- [ xt ptr field     ]     xt-ptr
  wfield: head.vfa     \  |     [ view field       ]     vfa (line#)
  wfield: head.ofa     \  |     [ optimize field   ]     ofa (length
of code for inline)
  wfield: head.ste     \  |     [ stack effects    ]     ste
  cfield: head.tfa     \  |     [ type flag        ]     tfa
  cfield: head.nfa     \  |     [ the name letters ]
  6 cells + 1-         \  |
end-structure          \  |
                       \  |
                       \  |     [ ct-off           ]     rel offset to
head.ct
                       \  +---> [ xt field         ]     code (the xt)


>
> Rod Pemberton

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

#12967

On Jun 12, 11:20 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "Alex McDonald" <b...@rivadpm.com> wrote in message

> If LAST works like "LAST-NAMED-XT" (which it did) and :NONAME doesn't have a
> header, then SMUDGE corrupting data is not an issue.  SMUDGE works on a
> valid header.  But, then my RECURSE which used LAST didn't work on the
> correct word.

Quite. A factor that makes the bare header ... aka HEADER ... and a
factor that starts a definition ... aka DEFINE, ... would
independently fill HEAD and LASTXT with CREATE calling HEADER and so
filling HEAD while : calls both HEADER and DEFINE, and so fills HEAD
and LASTXT both and :NONAME calls DEFINE, and so fills LASTXT.

RECURSE would use LASTXT and ignore HEAD. DOES> and IMMEDIATE would
use HEAD and ignore LASTXT.

> > > Currently, I'm using 48 bytes for the header, including the name (fixed
> > > size). However, I've placed a few fields into the body:

> > > \ header
> > > LFA (link field pointer)
> > > BIT (name field bits)

> > > NFA (name field)
> > > PTR (address of CFA)

> > > \ body
> > > DSL (for DOES>)
>
> > What is this for?
>
> This is a field for the address of where the DOES> code is located for
> a word created by CREATE ... DOES> .
>
> BruceMcF (Bruce McFarling) discussed this with me in "dot-quote
> implementation question" thread.

Though with PTR it seems that DSL could be omitted, since the c-
function pointer for {DOES} could be portably embedded in the word
containing DOES>, following the EXIT, and the location of the DOES>-
sub-parameter-field inferred as the cell following the one pointed to
by PTR.

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

#12977

Op Wed, 13 Jun 2012 10:25:16 -0700 (PDT) schreef BruceMcF:

> On Jun 12, 11:20 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> wrote:
>> "Alex McDonald" <b...@rivadpm.com> wrote in message
> 
>> If LAST works like "LAST-NAMED-XT" (which it did) and :NONAME doesn't have a
>> header, then SMUDGE corrupting data is not an issue.  SMUDGE works on a
>> valid header.  But, then my RECURSE which used LAST didn't work on the
>> correct word.
> 
> Quite. A factor that makes the bare header ... aka HEADER ... and a
> factor that starts a definition ... aka DEFINE, ... would
> independently fill HEAD and LASTXT with CREATE calling HEADER and so
> filling HEAD while : calls both HEADER and DEFINE, and so fills HEAD
> and LASTXT both and :NONAME calls DEFINE, and so fills LASTXT.
> 
> RECURSE would use LASTXT and ignore HEAD. DOES> and IMMEDIATE would
> use HEAD and ignore LASTXT.
> 

Yes, IMMEDIATE needs to know what part of the header is to modified and can
not reliably use LASTXT for that.
Yes, RECURSE uses LASTXT.
No, DOES> (or the runtime of it) can modify the code pointed to by LASTXT
without needing to know about a present or missing header.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#12996

On Jun 14, 1:24 pm, Coos Haak <chfo...@hccnet.nl> wrote:
> No, DOES> (or the runtime of it) can modify the code pointed to by LASTXT
> without needing to know about a present or missing header.

The DOES> compile time has no need of the xt of the word in which it
is contained, and no need to worry about a missing header, since it
applies to the last CREATEd word.

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

#13009

Op Fri, 15 Jun 2012 07:05:53 -0700 (PDT) schreef BruceMcF:

> On Jun 14, 1:24 pm, Coos Haak <chfo...@hccnet.nl> wrote:
>> No, DOES> (or the runtime of it) can modify the code pointed to by LASTXT
>> without needing to know about a present or missing header.
> 
> The DOES> compile time has no need of the xt of the word in which it
> is contained, and no need to worry about a missing header, since it
> applies to the last CREATEd word.

But the word compiled by DOES>, call it (DOES>) or (;CODE) must calculate
the position of the xt from the header address. LASTXT has it right away.
This is how Gforth and my current implementation do it.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#13011

On Jun 15, 2:40 pm, Coos Haak <chfo...@hccnet.nl> wrote:

> But the word compiled by DOES>, call it (DOES>) or (;CODE) must calculate
> the position of the xt from the header address. LASTXT has it right away.

It may, depending on implementation. It might not. If it does,
skipping:
   ... nt>code-address ....

... would indeed save an entire word in the definition. If it doesn't,
its:
   ... xt>code-address ...

... anyway, whatever that process is (in a direct threaded
implementation, xt>code-address may be 1+ or 2+ or CELL+).

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

#13015

Op Fri, 15 Jun 2012 11:56:05 -0700 (PDT) schreef BruceMcF:

> On Jun 15, 2:40 pm, Coos Haak <chfo...@hccnet.nl> wrote:
> 
>> But the word compiled by DOES>, call it (DOES>) or (;CODE) must calculate
>> the position of the xt from the header address. LASTXT has it right away.
> 
> It may, depending on implementation. It might not. If it does,
> skipping:
>    ... nt>code-address ....
> 
> ... would indeed save an entire word in the definition. If it doesn't,
> its:
>    ... xt>code-address ...
> 
> ... anyway, whatever that process is (in a direct threaded
> implementation, xt>code-address may be 1+ or 2+ or CELL+).

O, I was talking the address that must be patched during the execution of 
the word that contains DOES>. Never mind.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#13016

On Jun 15, 3:15 pm, Coos Haak <chfo...@hccnet.nl> wrote:
> O, I was talking the address that must be patched during the execution of
> the word that contains DOES>. Never mind.

LASTXT wouldn't serve for that, if CREATE does not set it. And so long
as that address can be inferred from the name token in HEAD there is
no pressing need to re-arrange CREATE to have it fill LASTXT

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

#12983

"BruceMcF" <agila61@netscape.net> wrote in message
news:460e8200-c21f-4e2f-ae83-023dd7e2974b@k5g2000vbf.googlegroups.com...

> A factor that makes the bare header ... aka HEADER ... and a
> factor that starts a definition ... aka DEFINE, ... would [...]
> CREATE calling HEADER [...]

Yes, I considered a HEADER word, maybe not by that name.  Someone else here
(Andrew?) mentioned it a few times, and I saw it in a Unix forth.  But, I
have (CREATE) and it ALLOTs or , (comma) as the header is filled.  So, it's
much like HEADER.  I didn't see the point of just a blank header word, e.g.,
ALLOT would do.  So, much of :NONAME ends up being a modified (CREATE),
i.e., without the extra stuff, and no nice factoring like you did...  :-)

I currently consider :NONAME to be low use, so am not too concerned.  I can
factor it later for size ... or leave it for speed.

> BruceMcF (Bruce McFarling)

Um, is that Bruce McFarland ... ?  I saw him in the c.l.f. archives.  Excuse
me, if I asked that previously...

> Though with PTR it seems that DSL could be omitted, since the c-
> function pointer for {DOES} could be portably embedded in the word
> containing DOES>, following the EXIT, and the location of the DOES>-
> sub-parameter-field inferred as the cell following the one pointed to
> by PTR.

By {DOES} do you mean DODOES or (DOES) or (DOES>) ?  Or, do you
mean the address of the DOES> code?

Won't doing what you've just suggested lead to the same issue I was having
problems with in the "dot-quote implementation question" thread?  I think it
will.

AIR, placing something in the PFA was causing data to shift or be in
unexpected locations.  I.e., I see omitting DSL working most of the time,
but not all the time.  Since CREATE ... DOES> is always high-level code
(now) in my Forth, the header and body will always be together.  So, I can
locate PTR from CFA or PFA, in that situation.

AISI, this should work with your suggestion:

: ZZZ  CREATE  <prep>  DOES>  <action> ;

ZZZ  XYZ  \ nothing else stored into XYZ

AISI, this might not work with your suggestion:

: ZZZ  CREATE  <prep>  DOES>  <action which needs data> ;

ZZZ XYZ <data> , <data> , <data> , \ data stored afterwards

In the second case, the DSL valued will be stored in the PFA.  So, the coded
<action> may expect the data in a certain location, but it'll be in a
different location.

I haven't had a chance to check, but was thinking that the 2nd case might
affect usage of string words or creating tables etc ...

If I omit the DSL, the CFA is still DODOES.  DODOES is the C-function, or
XT.  It must fetch the address of the DOES> code in the CREATE ... DOES>
sequence, and transfer interpretation to there.  The address of the DOES>
code should be at a fixed location relative to the start of the header.
That's an interpretable address.  It needs and ENTER or R> and ; (semis) to
transfer interpretation there.  I'm not sure where or how I'd insert that
into my code.  Most PTR fields will be valid XTs and then a few will be
non-XTs, the DOES> code address.  I.e., I'm also not sure how to detect
that.

Currently, my DOES> and DODOES do just a couple of things.

DOES>
1) writes DODOES into the CFA (overwriting DOVAR)
2) writes the DOES> address into DSL

DODOES
1) pushes PFA onto the data stack, i.e., DOVAR
2) saves the current IP on the return stack, begins interpreting at the
DOES> address, i.e., a modified ENTER (which normally transfers to W)

I.e., it looks like your earlier suggestion, or the way I implemented, works
for all situations, but does consume a cell.  So, I'm not sure why the
suggestion to change back to what I was doing previously or something
similar.


Rod Pemberton

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

#12993

On Jun 14, 8:31 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
wrote:
> "BruceMcF" <agil...@netscape.net> wrote:

> Yes, I considered a HEADER word, maybe not by that name.  Someone else here
> (Andrew?) mentioned it a few times, and I saw it in a Unix forth.  But, I
> have (CREATE) and it ALLOTs or , (comma) as the header is filled.  So, it's
> much like HEADER.

It sounds very much like it *is* HEADER

> I didn't see the point of just a blank header word

I don't either. If you were going a null header approach because of
not factoring out HEAD and LASTXT, you'd just create a null header by
passing it a nul-length string. HEAD (by whatever name) wouldn't be
standardizable, as some would pass an STR string, some a cell counted
string, some a counted string, some in a fixed buffer, and some would
parse the string in the place where the name would end up.

I can't see why you'd want a fixed length header, but if you do, all
the more reason to factor out the HEAD and LASTXT functionality.

>> BruceMcF (Bruce McFarling)

> Um, is that Bruce McFarland ... ?  I saw him in the c.l.f. archives.
That would likely be Bruce McFarling then. I've been chatting on and
on on clf since I was teaching in Newcastle, Australia.

> By {DOES} do you mean DODOES or (DOES) or (DOES>) ?

... or doDOES> or _DOES> etc.

> Won't doing what you've just suggested lead to the same issue I was having
> problems with in the "dot-quote implementation question" thread?
> I think it will.

> AIR, placing something in the PFA was causing data to shift or be in
> unexpected locations.

Which PFA? The PFA of the created word, or the sub-PFA following DOES>

If from your header, you can *infer* the PFA of the created word from
information available when the CREATEd word is executed (and after
all, this only has to work for headers built by CREATE not for any
generic header) which you should have in your interpreter process,
then the DOES> runtime can use that to place the PFA address on the
stack when it executes. That eliminates the need to store the PFA of
the created word.

That depends on how the Forth VM is defined. Sometimes that can be
inferred, and sometimes it cannot. Brad Rodriguez goes in more detail
in his DOES> article in his Moving Forth series.

> : ZZZ  CREATE  <prep>  DOES>  <action which needs data> ;

> ZZZ XYZ <data> , <data> , <data> , \ data stored afterwards

> In the second case, the DSL valued will be stored in the PFA.

No, it works when {DOES} can avoid requiring a stored CREATE-PFA at
all, because the address of the PTR through which the {DOES} runtime
was called can still be recovered. This may of course require a static
declaration in C.

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

#13089

"BruceMcF" <agila61@netscape.net> wrote in message
news:074e4320-111b-4352-ad96-5dab14e99b9d@z4g2000pbz.googlegroups.com...
> On Jun 14, 8:31 pm, "Rod Pemberton" <do_not_h...@notemailntt.cmm>
> wrote:
...

> > [snip]
> >
> I can't see why you'd want a fixed length header, [...]
>

Originally, it was a result of the C backend.  It's also needed to provide
fixed offsets to access the header's fields in Forth.  I.e., CFA is always a
fixed offset from the start of the header, ... for high-level Forth words.
DOES> (CREATE) RECURSE >BODY :NONAME WORDS all use
CFA's offset, etc.

Simplified slightly, I declare a fixed element struct for the header
(pointer to typedef'd struct).  The offsets to the struct's elements are
passed to the Forth side as initial values of Forth constants (pre-compiled
dictionary entries) or LITs in other Forth words (ditto ...).  The header
struct could be rewritten as variable length.  Then, I'd need some data
which is sometimes present, sometimes not.  Perhaps, I could move DSL
there...

> > AIR, placing something in the PFA was causing data to shift
> > or be in unexpected locations.
>
> Which PFA? The PFA of the created word, or the sub-PFA
> following DOES>

Either...

I thought you said "sub-PFA following DOES>" was the word with
the EXIT and address afterwards.  But, that's the same as the earlier
problem, or so I thought.  So, I took it to mean "PFA of the created
word" instead.  I think that too leads to the same result, but just in a
different word...

> If from your header, you can *infer* the PFA of the created
> word from information available when the CREATEd word
> is executed [...] which you should have in your interpreter
> process, then the DOES> runtime can use that to place the
> PFA address on the stack when it executes. That eliminates
> the need to store the PFA of the created word.

Either you've lost me, or I've lost you.

The PFA of the created word *is* placed onto the stack.  That's
the DOVAR like portion of DODOES routine.

My DSL field is the address needed by the interpreter for the
"sub-PFA following DOES>".  DSL is the replacement for W
needed by the ENTER like portion of the DODOES routine.


Can we go to "pictures"?

: XXX  CREATE 2 , DOES> @ ;


I've ignored the BIT field which has the MSB and IMMEDIATE
bit, a.k.a. precedence bit, set for both XXX and ZZZ below.

XXX is:

\ header
<LFA= address of last dictionary header >
<NFA= XXX >
<PTR= address of CFA of XXX >
\ body
<DSL= unused >
<CFA= ENTER -> pointer to C function >
<PFA 1= address of CREATE >
<PFA 2= address of LIT >
<PFA 3= value 2 >
<PFA 4= address of , (comma) >
<PFA 5= address of DOES> >
<PFA 6= address of @ >
<PFA 7= address of EXIT >


XXX ZZZ


ZZZ is:

\ header
<LFA= address of last dict. header, i.e., XXX >
<NFA= ZZZ >
<PTR= address of CFA of ZZZ >
\ body
<DSL= address of DOES> code in XXX >
<CFA= DODOES -> pointer to C function >
<PFA 1= value 2 >
<PFA 2= not allocated or used yet >

When ZZZ is executed, the ZZZ's CFA field is retrieved by the ITC inner
interpreter.  It has the pointer to the C function DODOES.  DODOES, places
the address for the start of the PFA of ZZZ onto the stack, i.e., address of
PFA 1 in the pictogram, then retrieves the address in DSL which is the
address for the DOES> code in XXX, i.e., @, and transfers interpreter
"execution" to the DOES> code in XXX.

FYI, DOES> is high-level Forth, but DODOES is low-level, i.e., C code.


You're saying the DSL can be removed.  In which case, DSL can be removed
from either XXX (defining) or ZZZ (CREATEd).


A) If I remove DSL in ZZZ (CREATEd), how do I find the (your words) "sub-PFA
following DOES>" or (my words) "address of DOES> code" in XXX?  I can't put
ZZZ's DSL into the ZZZ's CFA since it's not a pointer to a C function (more
below).  ZZZ's DSL value is an interpretable address, i.e., needs ENTER.

Except via ZZZ's DSL, ZZZ doesn't "know" where XXX is (or any part thereof).
If ZZZ's DSL can't be stored into ZZZ's CFA and ZZZ's DSL is removed, then
the address that was in ZZZ's DSL must be stored elsewhere within ZZZ, yes?
I.e., there is no other way to find it.  E.g., an attempt can be made to
store it afterwards, but number of consumed fields in the body is unknown.
That depends on what is between CREATE ...  DOES> in the defining word.
How do you find the end of the CREATEd definition?

The problem here is that my CFA fields must contain a pointer to a C
function, declared a certain way.  The DSL value is an interpretable
address.  An interpretable address needs an ENTER or >R and ; (semis) to
begin interpretation.  I don't know how to get ENTER to be executed if the
CFA was an interpretable address, except by making all CFAs interpretable
addresses.  I.e., mixing types of CFAs (two different) causes an issue.  If
there are executable CFAs and interpretable CFAs, how do I determine which
needs an ENTER and which doesn't?


B) If I remove DSL in XXX (defining), that saves a field.  But, that has at
least two issues:

1) The relationship between the header and body isn't fixed for high-level
Forth words.  For high-level Forth words, the header and body are
contiguous, with header first.  (Pre-compiled Forth in C is reversed: body
first.)  So, if XXX's DSL is removed, the constants for the field offsets
for CFA, PFA, DSL, etc for high-level Forth words aren't fixed.  These
offsets are passed from C to Forth via Forth constants.  E.g.,
CREATE >BODY etc use those offsets.  I.e., the words using the constants
would work for high-level Forth words without DSL or vice-versa,
but not both, unless I had "intelligent" "adapting" constants ...

2) If the "sub-PFA following DOES>" address is stored in ZZZ at PFA 2 and a
Forth sequence stores to PFA 3, PFA 4, etc... after ZZZ is created, then
there'll be confusion when coding the "sub-PFA following DOES>" about where
to expect that data.  I.e., the code for the "sub-PFA following DOES>" might
expect the data to start at PFA 2, but it'll start at PFA 3 if the address
for the "sub-PFA following DOES>" is stored at PFA 2.  As mentioned
previously, I was thinking about strings or tables being stored after
a word was CREATEd.


Reiterating, currently, my DOES> and DODOES do just a couple of things:

DOES>
1) writes DODOES into the CFA (overwriting DOVAR)
2) writes the DOES> address into DSL

DODOES
1) pushes PFA onto the data stack, i.e., DOVAR
2) saves the current IP on the return stack, begins interpreting at the
DOES> address, i.e., a modified ENTER (which normally transfers to W)


E.g., DOES> is the following, but parts of the sequence are
customized to my Forth:

: DOES>
  LIT DODOES ( address of CFA of CREATEd word ) !
  R> ( address of DSL of CREATEd word ) !
;

R> points to the DOES> code when the defining word with the
CREATE ... DOES> sequence is executed, i.e., "sub-PFA following DOES>".


DODOES could be written in high-level Forth, if IP and W are Forth
variables:

: DODOES
\ this is DOVAR
  W
\ this is ENTER modified for DSL instead of W
  IP >R
  ( address of DSL of current word ) @ IP !
;

That assumes the independence from other intracacies, e.g., off-by-one,
ability to set the correct IP within an interpreting word (delayed until
EXIT ... ?), etc.


Rod Pemberton

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

#13010

Op Thu, 14 Jun 2012 20:31:39 -0400 schreef Rod Pemberton:

<snip>
> 
> By {DOES} do you mean DODOES or (DOES) or (DOES>) ?  Or, do you
> mean the address of the DOES> code?
> 
> Won't doing what you've just suggested lead to the same issue I was having
> problems with in the "dot-quote implementation question" thread?  I think it
> will.
> 
> AIR, placing something in the PFA was causing data to shift or be in
> unexpected locations.  I.e., I see omitting DSL working most of the time,
> but not all the time.  Since CREATE ... DOES> is always high-level code
> (now) in my Forth, the header and body will always be together.  So, I can
> locate PTR from CFA or PFA, in that situation.
> 
> AISI, this should work with your suggestion:
> 
>: ZZZ  CREATE  <prep>  DOES>  <action> ;
> 
> ZZZ  XYZ  \ nothing else stored into XYZ
> 
> AISI, this might not work with your suggestion:
> 
>: ZZZ  CREATE  <prep>  DOES>  <action which needs data> ;
> 
> ZZZ XYZ <data> , <data> , <data> , \ data stored afterwards
> 
> In the second case, the DSL valued will be stored in the PFA.  So, the coded
> <action> may expect the data in a certain location, but it'll be in a
> different location.

: CONST1 CREATE , DOES> @ ;
10 CONST1 TEN      TEN . will print 10
: CONST2 CREATE DOES> @ ;
CONST2 TWENTY 20 ,    TWENTY . will print 20

You see, the parameter field may be filled while createing (CONST1) or
after creating (CONST2). Both parameter fields start at the same location,
taking in account the different defining words.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#12946

On Jun 11, 9:09 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <4fd5e1f0$0$6615$882e7...@usenet-news.net>,
> Josh Grams  <j...@qualdan.com> wrote:

>> RECURSE just needs the address of the code, so if you separate that from
>> LAST then you can get away without a dummy header.

> This is not generally true. For indirect threaded code the code address
> is docol (the inner interpreter) and there needs to be some pointer to
> the threaded code too.

this is reading "address of the code" overly literally ~ you need the
address of the Forth code, whether that is pointing to machine
language code, to a "code field" followed by the linked list, or etc.
is obviously implementation dependent, but the general point stands.
If you have HEAD and LASTXT then RECURSE can use LASTXT. CREATE or a
factor of CREATE (eg HEADER) fills HEAD while a common factor of :
and :NONAME (eg DEFINE,) fills LASTXT.

Indeed, :NONAME can then be, if DEFINE, is ( ct: -- x=colon-sys ):

: :NONAME ( ct: -- xt colon-sys ) DEFINE, LASTXT @ SWAP POSTPONE [ ;

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

#12960

In article <97b9afa0-0873-4b69-90ce-7b57fb1336cc@p27g2000vbl.googlegroups.com>,
BruceMcF  <agila61@netscape.net> wrote:
>On Jun 11, 9:09=A0pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
>wrote:
>> In article <4fd5e1f0$0$6615$882e7...@usenet-news.net>,
>> Josh Grams =A0<j...@qualdan.com> wrote:
>
>>> RECURSE just needs the address of the code, so if you separate that from
>>> LAST then you can get away without a dummy header.
>
>> This is not generally true. For indirect threaded code the code address
>> is docol (the inner interpreter) and there needs to be some pointer to
>> the threaded code too.
>
>this is reading "address of the code" overly literally ~ you need the
>address of the Forth code, whether that is pointing to machine
>language code, to a "code field" followed by the linked list, or etc.
>is obviously implementation dependent, but the general point stands.
>If you have HEAD and LASTXT then RECURSE can use LASTXT. CREATE or a
>factor of CREATE (eg HEADER) fills HEAD while a common factor of :
>and :NONAME (eg DEFINE,) fills LASTXT.
>
>Indeed, :NONAME can then be, if DEFINE, is ( ct: -- x=3Dcolon-sys ):
>
>: :NONAME ( ct: -- xt colon-sys ) DEFINE, LASTXT @ SWAP POSTPONE [ ;

You're right of course. :NONAME centres on the abstraction of
execution token. If you have an xt, that is the only thing you
ever need to EXECUTE. An xt represents the "address of code".

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web