>PFA and >BODY

[Mark Wills]

In my system, the PFA of a word is in the cell immediately following
the CFA, as one would expect.

However, for words built with DOES> the PFA is at CFA + 2 cells:

: THING CREATE DOES> @ ;
THING FRED

FRED will look like this:

FRED GOTO xxx yyy

Where xxx is the address of the word following DOES> in the parent.
The *address* of yyy will be pushed to the stack at runtime.

As you can see, this effectively means the PFA of DOES> words is at
'CFA+2 cells.

Is this an issue? Or, can I do:

: >PFA >CFA 1 CELLS + ;
: >BODY >CFA 2 CELLS + ;

Thanks

Mark

[Anton Ertl]

Post by Mark Wills
In my system, the PFA of a word is in the cell immediately following
the CFA, as one would expect.
THING FRED
FRED GOTO xxx yyy
Where xxx is the address of the word following DOES> in the parent.
The *address* of yyy will be pushed to the stack at runtime.
As you can see, this effectively means the PFA of DOES> words is at
'CFA+2 cells.
: >PFA >CFA 1 CELLS + ;
: >BODY >CFA 2 CELLS + ;

You can define >PFA however you like. A standard >BODY must work on
all CREATEd words (even those without DOES>); it's not clear why you
would want a >CFA in >BODY and what it does.

- anton

[Mark Wills]

Post by Mark Wills
In my system, the PFA of a word is in the cell immediately following
the CFA, as one would expect.
THING FRED
FRED GOTO xxx yyy
Where xxx is the address of the word following DOES> in the parent.
The *address* of yyy will be pushed to the stack at runtime.
As you can see, this effectively means the PFA of DOES> words is at
'CFA+2 cells.
: >PFA  >CFA 1 CELLS + ;
: >BODY >CFA 2 CELLS + ;

You can define >PFA however you like.  A standard >BODY must work on
all CREATEd words (even those without DOES>); it's not clear why you
would want a >CFA in >BODY and what it does.
- 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 2010:http://www.euroforth.org/ef10/

It's possible that I am confused over the meaning if body and pfa. It
seems to me that PFA only applies to words with a parameter, like
variables and constants. Problem is, my DOES implementation modifies
words built with create, such that you can't use BODY on them.

I'll try and explain.

CREATEd words yield the following:

DOVAR xxx

Where DOVAR is the CFA, and xxx is the PFA. I would argue that it
doesn't have a body at all.

If you subsequently apply DOES to that word it gets rebuilt, like
this:

DODOES <address> xxx

Here, DODOES is a bit of machine code to change the forth ip to
address <address> and the PFA (the address of which is pushed for the
words following DOES in the parent) has moved forward one cell. Or is
this not a "pfa" at all? Maybe I've got my nomenclature all mixed
up.

This means the offset to the PFA is not the same for created or does>
words. This looks to be a problem to me.

Mark

[Anton Ertl]

Post by Mark Wills
It's possible that I am confused over the meaning if body and pfa. It
seems to me that PFA only applies to words with a parameter, like
variables and constants.

Yes, that's the traditional meaning of PFA.

Post by Mark Wills
Problem is, my DOES implementation modifies
words built with create, such that you can't use BODY on them.

If you cannot use >BODY on them, your system will not be standard.

Post by Mark Wills
DOVAR xxx
Where DOVAR is the CFA, and xxx is the PFA. I would argue that it
doesn't have a body at all.

If you do

CREATE x 5 ,

and then do

' x >body @ .

it should print 5. So, in that sense, every CREATEd word has a body.

Post by Mark Wills
If you subsequently apply DOES to that word it gets rebuilt, like
DODOES <address> xxx
Here, DODOES is a bit of machine code to change the forth ip to
address <address> and the PFA (the address of which is pushed for the
words following DOES in the parent) has moved forward one cell.

This has two problems:

1) As you noticed, you cannot use a simple implementation of >BODY if
you change the address of the body.

2) Data may be allocated in the body and the address of that data
taken before applying the DOES> part (or afterwards). Most likely
that code won't behave on your system as it should.

There are two solutions:

1) Use a single-cell code field even in the presence of DOES>. It has
been discussed here several times how to do this.

2) Use a two-cell code field for CREATEd words even in the absence of
DOES>. Gforth takes this course; indeed, all words have two-cell code
fields in Gforth.

- anton

[Mark Wills]

Post by Anton Ertl

Post by Mark Wills
It's possible that I am confused over the meaning if body and pfa. It
seems to me that PFA only applies to words with a parameter, like
variables and constants.

Yes, that's the traditional meaning of PFA.

Post by Mark Wills
Problem is, my DOES implementation modifies
words built with create, such that you can't use BODY on them.

If you cannot use >BODY on them, your system will not be standard.

Post by Mark Wills
DOVAR xxx
Where DOVAR is the CFA, and xxx is the PFA. I would argue that it
doesn't have a body at all.

If you do
CREATE x 5 ,
and then do
it should print 5.  So, in that sense, every CREATEd word has a body.

Post by Mark Wills
If you subsequently apply DOES to that word it gets rebuilt, like
DODOES <address> xxx
Here, DODOES is a bit of machine code to change the forth ip to
address <address> and the PFA (the address of which is pushed for the
words following DOES in the parent)  has moved forward one cell.

1) As you noticed, you cannot use a simple implementation of >BODY if
you change the address of the body.
2) Data may be allocated in the body and the address of that data
taken before applying the DOES> part (or afterwards).  Most likely
that code won't behave on your system as it should.
1) Use a single-cell code field even in the presence of DOES>.  It has
been discussed here several times how to do this.
2) Use a two-cell code field for CREATEd words even in the absence of
DOES>.  Gforth takes this course; indeed, all words have two-cell code
fields in Gforth.
- 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 2010:http://www.euroforth.org/ef10/

I'm also thinking of option 2. It wastes a cell but it does make
things simpler, and more importantly, standard.

I'm still not sure of the difference between a BODY and a PFA though.
In what circumstances would you use body?

This has come up due to some code in Mastering Forth. DEFER IS.

: WARNING ." UNINITIALISED" ;
: DEFER CREATE ['] WARNING , DOES> @ EXECUTE ;
: IS ' >BODY ! ;

DEFER FRED
FRED
UNINITIALSED ok
: HELLO ." I'M HERE!" ;
' HELLO IS FRED ok
FRED
I'M HERE! ok

This doesn't work on my system for the reasons given above.

: >BODY 2 CELLS + ;

That fixes it.

Damn it!

Mark

[Bruce.McFarling]

Post by Mark Wills
I'm also thinking of option 2. It wastes a cell but it does make
things simpler, and more importantly, standard.

The other way also makes things standard, which is to put:
... EXIT DODOES ...
in the word when executing DOES> and putting the address of that
DODOES in the CFA.

[Anton Ertl]

The other way [1 cell for the code field) also makes things standard,
... EXIT DODOES ...
in the word when executing DOES> and putting the address of that
DODOES in the CFA.

In an indirect-threaded system, the DODOES code then starts with a
jump or call to a routine usually called dodoes.

- anton

[Mark Wills]

Thanks all.

In the end, I modified VARIABLE, CONSTANT and VALUE so that the offset
to their 'payload' (body) lines up with words that utilise DOES>.

I removed the word PFA, and added the word >BODY in line with the F83
standard. So far seems to be working fine.

Unless I misunderstand the OP, I think this is what he is describing.

Indeed, Doc. The problem was that words built with CREATE had their
body immediately following the xt. However, if DOES> is subsequently
applied to the CREATEd word, the body shifts forward one cell, since
the sequence becomes:

GOTO <address> <body>

I guess my "goto" is analogous to DODOES.

The PDP-11 has a very similar instruction set to the chip I'm using:
The good old TMS9900 :-)

Mark

[BruceMcF]

Post by Anton Ertl

The other way [1 cell for the code field) also makes things standard,
... EXIT DODOES ...
in the word when executing DOES> and putting the address of that
DODOES in the CFA.

In an indirect-threaded system, the DODOES code then starts with a
jump or call to a routine usually called dodoes.

And in a direct threaded system with address in W, so "JMP doVAR"
rather than "JSR doVAR", it could well be:

JMP doVAR [...body...] becoming: JMP addr1 [...body...]

... EXIT
addr1: JSR doDOES [...doDOES code...]

... seeding the IP from the return address left by the embedded call.

Multiple ways to get'r'done. Indeed, building CREATE as an explicit
NOP:

[doDOES] [address_with_EXIT_in_it] [...body...]

and then DOES> just inserts the target of the start of the DOES> code
works too.

[Anton Ertl]

Post by Mark Wills
I'm still not sure of the difference between a BODY and a PFA though.

It's up to you if you want to talk about PFAs at all, and if there are
differences between them and the body. That being said, if you make a
system with 2 cells for the code field, and you want to implement
: >PFA ( cfa -- pfa ) 2 cells + ;

Post by Mark Wills
In what circumstances would you use body?

You use >BODY when you have the xt of a CREATEd word and want to
access the cortresponding data.

- anton

[Mark Wills]

Post by Anton Ertl
If you do
CREATE x 5 ,
and then do
it should print 5.  So, in that sense, every CREATEd word has a body.

And indeed, it now does. Thanks for the help.

Mark

[Elizabeth D Rather]

...

Post by Mark Wills

You can define>PFA however you like. A standard>BODY must work on
all CREATEd words (even those without DOES>); it's not clear why you
would want a>CFA in>BODY and what it does.

...

Post by Mark Wills
It's possible that I am confused over the meaning if body and pfa. It
seems to me that PFA only applies to words with a parameter, like
variables and constants. Problem is, my DOES implementation modifies
words built with create, such that you can't use BODY on them.

Historically, the term PFA (Parameter Field Address) meant the address
of the "payload" of *any* kind of definition. In colon definitions, the
Parameter Field contained the addresses of the words that made up the
behavior; in data objects it contained the data itself. Early standards
such as Forth83 prescribed the content of the Parameter Field of various
kinds of definitions.

Forth94 sought to liberate implementers, and restricted standard access
to "data space" (as opposed to code space, dictionary heads, and other
spaces controlled by the system). Therefore, >BODY takes an xt and
returns the location of the *data space* associated with the word:

"a-addr is the data-field address corresponding to xt. An ambiguous
condition exists if xt is not for a word defined via CREATE."

That is the only part of a definition that a standard program can
access. As a result, it doesn't matter at all how you structure the
rest of the definition, regardless of how it was constructed. As Anton
says, you can define >BODY however you wish, providing it returns the
address of the actual data space associated with a word defined by
CREATE (regardless of whether that definition was modified by DOES>).

Post by Mark Wills
PFA is not a standard word, so if you provide it, you can define it

any way you like.

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."
==================================================

[Albert van der Horst]

In article <451da0b0-bfe8-4c82-a690-***@35g2000prp.googlegroups.com>,
Mark Wills <***@yahoo.co.uk> wrote:
<SNIP>

Post by Mark Wills
It's possible that I am confused over the meaning if body and pfa. It
seems to me that PFA only applies to words with a parameter, like
variables and constants. Problem is, my DOES implementation modifies
words built with create, such that you can't use BODY on them.

If you are operating in the context of the ANSI standard, you can
define and use PFA however you like, because it is not defined there.
My best advise is to only use PFA if you think the association with
the PFA as used in the FIG model is advantageous. Then you must
very carefully define what *you* want to mean it.

The matter with DOES> words is that they contain data that can be
changed : the does pointer besides the payload found by >BODY.
In my book it means that the data of such a word has two fields: that
pointer, and the payload. Now find a way to name that in your
Forth with the least of confusion.

Post by Mark Wills
Mark

Groetjes Albert


--

[doc]

One of my DTC implementations - for a PDP-11 (don't laugh) is similar.
Since it's DTC, the xt (old terminology CFA) always contains a machine
instruction. A word built by CREATE (which is the only type of word
that
the ANS94 Standard requires >BODY to work with correctly) has a
structure
similar to
xt+0: jsr i,@#
xt+2: <address of runtime portion of created word>
xt+4: <parameter>

So, the xt is in the same location regardless of what was used to
construct
the word. But the 'payload' (in old terminology pfa) is either 1 word
away or 2 words away from the xt depending on whether or not the
word was CREATEd. Unless I misunderstand the OP, I think this is
what he is describing.

My particular solution was to use a bit somewhere in the name field
to indicate that the word was constructed by CREATE. That is, CREATE
sets a bit in the name field. >BODY looks for that bit and adjusts
the returned address depending on it being set or clear.

Inelegant kludge? Perhaps. But >BODY works as the standard requires.

OT?: you probably ought to figure out some way of recording that the
last definition constructed did or did not contain a name field
(eg: :NONAME) and make >BODY smart enough to understand there is
no nfa to check for a set or clear CREATE bit. In my case, a
user var LASTXT contains the last constructed xt for a user.
Since execution addresses on a PDP-11 must be word aligned (even)
:NONAME sets the lsb in LASTXT - making it odd - which other
words can examine to determine the presence or absence of
a name field. The lsb as a flag is easily stripped off for
words like RECURSE .

FWIW,
doc

[doc]

Blah,

Kindly ignore my faux pas on trying to use >BODY after :NONAME
Detection of a :NONAME xt and use by RECURSE is okay, but
relating it to the operation of >BODY was misleading and wrong.

Apologies,
doc

[Elizabeth D Rather]

Post by doc
One of my DTC implementations - for a PDP-11 (don't laugh) is similar.
Since it's DTC, the xt (old terminology CFA) always contains a machine
instruction. A word built by CREATE (which is the only type of word
that
the ANS94 Standard requires>BODY to work with correctly) has a
structure
similar to
xt+2:<address of runtime portion of created word>
xt+4:<parameter>
So, the xt is in the same location regardless of what was used to
construct
the word. But the 'payload' (in old terminology pfa) is either 1 word
away or 2 words away from the xt depending on whether or not the
word was CREATEd. Unless I misunderstand the OP, I think this is
what he is describing.

Actually, the whole point of >BODY is to make the actual structure
completely irrelevant. The body/parameter field/payload (whatever you
want to call it) can be in a separate memory space, or even a different
computer! Consider the case of a cross-compiler with an umbilical link
to a target: The head of the definition (which ' would find) would be
in the host; the address of the runtime code (as well as the code
itself) might be in ROM or flash on the target; and the actual parameter
might be in RAM on the target. This is completely transparent providing
you use standard words to reference or execute the word, or to access
its data.

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."
==================================================