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

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

NT versus XT

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

Contents

  NT versus XT JennyB <jennybrien@googlemail.com> - 2015-05-16 04:26 -0700
    Re: NT versus XT Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-16 08:29 -0700
      Re: NT versus XT Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-18 00:38 +0200
        Re: NT versus XT Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-17 22:30 -0700
          Re: NT versus XT "Elizabeth D. Rather" <erather@forth.com> - 2015-05-17 21:19 -1000
            Re: NT versus XT Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-18 03:56 -0700
            Re: NT versus XT JennyB <jennybrien@googlemail.com> - 2015-05-20 14:58 -0700
        Re: NT versus XT albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-18 11:30 +0000
          Re: NT versus XT rickman <gnuarm@gmail.com> - 2015-05-20 18:48 -0400
            Re: NT versus XT Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-23 23:19 -0700
              Re: NT versus XT "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-24 20:18 -0400
                Re: NT versus XT "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-29 05:42 -0400

#39167 — NT versus XT

On Thursday, 14 May 2015 19:41:27 UTC+1, Alex McDonald  wrote:
> on 14/05/2015 19:31:09, Matthias Trute wrote:

> > I think a major part of the problem is that FIND and Co need a new
> > design but nobody did so yet. Recognizers are IMHO the wrong place to
> > discuss the various semantics and states etc. Until that is done, we
> > may use recognizers to play with the variants, but cannot achieve a
> > satisfacting solution.
> 
> Yes, and it's my opinion that this needs discussed first. Here are some;
> NTs vs XTs, a better understanding of interpret vs compilation semantics,
> a resolution of what ' <name> COMPILE, does with immediate words, whether
> IMMEDIATE is dead & what replaces it, the standardisation of FIND-NAME;
> all would all be helpful.
> 
As I currently understand it:

NAME TOKENs
A Name token is a reference to the header of a definition, therefore only 
named definitions have them. When you know a definition's name token 
you can get:

via NAME>INTERPRET  nt -- xt
   An xt representing its interpretation behaviour (if it has one)

via NAME>COMPILE    nt -- x xt
   The xt when executed performs the definition's 
   compilation behaviour, consuming x

   For default words x is the xt returned by NAME>INTERPRET and
   the xt on top is that of COMPILE,

   For immediate words x is the xt returned by NAME>INTERPRET and
   the xt on top is that of EXECUTE

via NAME>STRING   nt -- c-addr u
    The name of the definition.

Currently name tokens are only used internally by TRAVERSE-WORDLIST and the 
words it executes, but the proposal is that FIND-NAME should return the name 
token of the most recent definition in the search order of that name, or 
FALSE if it is not found.  FIND might be written as:

   : FIND  COUNT FIND-NAME DUP 0= IF EXIT THEN
           NAME>COMPILE ['] EXECUTE = IF  1 ELSE -1 THEN ;
           

    but that's not very useful except by way of illustration.

EXECUTION TOKENS
A definition's execution token represents what the definition does when it is EXECUTED. In the days of threaded code it was a machine code address, or a pointer to one, and a colon definition was mainly composed of xts.  In the 83 Standard the xt was also the entry point for accessing the header, so you could do things like:

   : .NAME ( xt -- ) >NAME TYPE ;

To do that now you would need another word XT>NAME, which would be very 
useful, for example, to check the current action of a deferred word.  

SHOULD THE TWO TOKENS BE THE SAME?

At present they may or they may not.  It's trivial for them to be the same, 
in which case XT>NAME would not be needed.  The best case for them to differ 
is where code space and header space are not the same, in which case a 
name/execution token would have to be either an address in header space that 
points to code space, or vice versa.

If they are the same then obviously each named definition would have a different xt, and 
     
       SYNONYM  FOO BAR IMMEDIATE 

       would create an immediate synonym of foo called BAR. 
 
XT>NAME and NAME>INTERPRET  would not be needed, and 

       : .NAME NAME>STRING TYPE ;

       would work just fine.

[toc] | [next] | [standalone]

#39174

> SHOULD THE TWO TOKENS BE THE SAME?

No, of course not.

> 
> At present they may or they may not.  It's trivial for them to be the same, 

No it's not trivial.

> in which case XT>NAME would not be needed.  The best case for them to differ 
> is where code space and header space are not the same, in which case a 
> name/execution token would have to be either an address in header space that 
> points to code space, or vice versa.

Not necessarily the case. For example, I have in my system the code space and header space unified (the same memory area), but the real code and the dictionary headers are interlaced and totally decoupled. Even the name string is not directly in the header. In other words, my header contains only pointers, pointer to code (or data), pointer to the name string content, pointer to filename where the definition reside, etc.

My internal dictionary searching function returns the address of the dictionary header (the so called name token). With this pointer you can find anything you want. In my system this function is internal, I didn't think of making it a "word".  But it's vital.

IMO this "name token" - I would call it dictionary pointer however - should be the core of a modern forth. All other stuff like FIND, tick and co. should be based on this, and that only to make the system "standard". I'm just thinking, forth language needs a fresh (re)start.

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

#39194

Raimond Dragomir wrote:
>> At present they may or they may not.  It's trivial for them to be the
>> same,
> 
> No it's not trivial.

Of course it's trivial. Just reverse the order of the header fields:

Traditional (fig-Forth, F83, etc.):

link (nt points here) | count+flags | name | code field (xt points here) | 
body ...

xt=nt:

name | count+flags | link | code field (xt points here) | body ...

Now you can comfortably reach all fields of the header (through negative 
offsets) and the body from the xt without problems.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#39196

luni, 18 mai 2015, 01:38:24 UTC+3, Bernd Paysan a scris:
> Raimond Dragomir wrote:
> >> At present they may or they may not.  It's trivial for them to be the
> >> same,
> > 
> > No it's not trivial.
> 
> Of course it's trivial. Just reverse the order of the header fields:
> 
> Traditional (fig-Forth, F83, etc.):
> 
> link (nt points here) | count+flags | name | code field (xt points here) | 
> body ...
> 
> xt=nt:
> 
> name | count+flags | link | code field (xt points here) | body ...
> 
> Now you can comfortably reach all fields of the header (through negative 
> offsets) and the body from the xt without problems.
> 
> -- 
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
> net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
> http://bernd-paysan.de/

Your assumption is overly simplistic. My code "body" is before the dictionary header. Given the address of the code (executable xt) how can you reach the header in order to get all the other info about it? The body is always variable length...

I didn't say FIND or ' are not usefull. They are. Most of the time you need the executable xt given the name of the word. What Forth lacks is a standard way to obtain other info about the word. The simplest way is obtaining the nt. Then you can get all you want with words like >CFA, >NAME, >WID, >FILENAME, >LINENO, >FLAGS, etc. 

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

#39198

On 5/17/15 7:30 PM, Raimond Dragomir wrote:
> luni, 18 mai 2015, 01:38:24 UTC+3, Bernd Paysan a scris:
>> Raimond Dragomir wrote:
>>>> At present they may or they may not.  It's trivial for them to be the
>>>> same,
>>>
>>> No it's not trivial.
>>
>> Of course it's trivial. Just reverse the order of the header fields:
>>
>> Traditional (fig-Forth, F83, etc.):
>>
>> link (nt points here) | count+flags | name | code field (xt points here) |
>> body ...
>>
>> xt=nt:
>>
>> name | count+flags | link | code field (xt points here) | body ...
>>
>> Now you can comfortably reach all fields of the header (through negative
>> offsets) and the body from the xt without problems.
>>
>> --
>> Bernd Paysan
>> "If you want it done right, you have to do it yourself"
>> net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
>> http://bernd-paysan.de/
>
> Your assumption is overly simplistic. My code "body" is before the
 > dictionary header. Given the address of the code (executable xt)
> how can you reach the header in order to get all the other info about
> it? The body is always variable length...
>
> I didn't say FIND or ' are not usefull. They are. Most of the time
> you need the executable xt given the name of the word. What Forth
> lacks is a standard way to obtain other info about the word. The
> simplest way is obtaining the nt. Then you can get all you want
> with words like >CFA, >NAME, >WID, >FILENAME, >LINENO, >FLAGS, etc.

The reason definition structures have never been standardized is that 
"common practice" has always deviated drastically, given the very 
different constraints implementers face and what they're trying to 
optimize. Performance depends on starting execution ASAP; therefore, 
what constitutes an 'xt' is generally whatever will get the code 
executing with the fewest steps. Exactly what that constitutes varies, 
depending on processor architecture and many other factors.

You give a list of utility words above, but in some implementations 
there is no Filename; Flags are not addressable (in the middle of some 
cell, for example). Etc. And the fact is, many, many, many applications 
now running have no need for any of this, so it's just not a priority.

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]

#39199

luni, 18 mai 2015, 10:19:17 UTC+3, Elizabeth D. Rather a scris:
> On 5/17/15 7:30 PM, Raimond Dragomir wrote:
> > luni, 18 mai 2015, 01:38:24 UTC+3, Bernd Paysan a scris:
> >> Raimond Dragomir wrote:
> >>>> At present they may or they may not.  It's trivial for them to be the
> >>>> same,
> >>>
> >>> No it's not trivial.
> >>
> >> Of course it's trivial. Just reverse the order of the header fields:
> >>
> >> Traditional (fig-Forth, F83, etc.):
> >>
> >> link (nt points here) | count+flags | name | code field (xt points here) |
> >> body ...
> >>
> >> xt=nt:
> >>
> >> name | count+flags | link | code field (xt points here) | body ...
> >>
> >> Now you can comfortably reach all fields of the header (through negative
> >> offsets) and the body from the xt without problems.
> >>
> >> --
> >> Bernd Paysan
> >> "If you want it done right, you have to do it yourself"
> >> net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
> >> http://bernd-paysan.de/
> >
> > Your assumption is overly simplistic. My code "body" is before the
>  > dictionary header. Given the address of the code (executable xt)
> > how can you reach the header in order to get all the other info about
> > it? The body is always variable length...
> >
> > I didn't say FIND or ' are not usefull. They are. Most of the time
> > you need the executable xt given the name of the word. What Forth
> > lacks is a standard way to obtain other info about the word. The
> > simplest way is obtaining the nt. Then you can get all you want
> > with words like >CFA, >NAME, >WID, >FILENAME, >LINENO, >FLAGS, etc.
> 
> The reason definition structures have never been standardized is that 
> "common practice" has always deviated drastically, given the very 
> different constraints implementers face and what they're trying to 
> optimize. Performance depends on starting execution ASAP; therefore, 
> what constitutes an 'xt' is generally whatever will get the code 
> executing with the fewest steps. Exactly what that constitutes varies, 
> depending on processor architecture and many other factors.
> 
> You give a list of utility words above, but in some implementations 
> there is no Filename; Flags are not addressable (in the middle of some 
> cell, for example). Etc. And the fact is, many, many, many applications 
> now running have no need for any of this, so it's just not a priority.
> 
> 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."
> ==================================================

The reality is that the nt is always obtained, but this is internal working. You cannot get anything if you don't get the nt first. The discussion here is whether the nt should be made "public" or not. And this is probably in the view of future complicating the language with prefixes, recognizers and whatever else.

All I'm saying is that you cannot always obtain the nt if you know the xt. This is obvious when the ditionary area and code area are different, but can be the case even if they are intermixed.

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

#39219

On Monday, 18 May 2015 08:19:17 UTC+1, Elizabeth D. Rather  wrote:

> The reason definition structures have never been standardized is that 
> "common practice" has always deviated drastically, given the very 
> different constraints implementers face and what they're trying to 
> optimize. Performance depends on starting execution ASAP; therefore, 
> what constitutes an 'xt' is generally whatever will get the code 
> executing with the fewest steps. Exactly what that constitutes varies, 
> depending on processor architecture and many other factors.
> 
> You give a list of utility words above, but in some implementations 
> there is no Filename; Flags are not addressable (in the middle of some 
> cell, for example). Etc. And the fact is, many, many, many applications 
> now running have no need for any of this, so it's just not a priority.
> 
Good point.  We'll never be able to specify the whole system in terms of itself, so might as well leave the backstage stuff as open as possible,  For most applications you can remove the dictionary, the immediate words and a lot more, and the application should be unaffected.  

All we really need for the dictionary is that, having defined a word, we can retrieve its xt by name, and together with information on how to compile it.  In other words, what is returned by NAME>COMPILE. For that, or from the name string, given TRAVERSE-WORDLIST and friends, you can get the contents of the other dictionary fields, but that is not primary, and teh name token is just something that is used internally for that purpose.  It may actually be the xt, but we need never know.  If code space and name space are disjoint then it makes sense to have the xt as an address in code space, and it might be a poor choice for a name token.

The potential successor to FIND (let's call it FIND* for now) should therefore take an addr u pair and return the same xt (irrespective of STATE) and an xt that tells how to compile it (or FALSE if the word is not found).

The compiling action can be set by SET-COMPILER, but there is no requirement that it can be found again from the xt alone.  Therefore, COMPILE, retains its classic meaning of 'compile a call, no matter what.'

That's probably incompatible with all three major systems, but at least it has the virtue of consistency.

For user-defined words, the base xt represents the definition,and the compiler action is either COMPILE, , EXECUTE (for immediate words), or something set by SET-COMPILER,  If SET-COMPILER has not been used, a classic interpreter will still compile correctly (it will still interpret correctly in any case).

There are two ways to enable checking for compile-only, niether of which require extra dictionary flags:

  1.  Set the compile action to another word that does EXECUTE, and check for that when ticking.

  2.  Define the word to abort with an error message (or whatever else you want) and use SET-COMPILER to define the compiling action.

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

#39201

In article <mjb56r$juq$2@dont-email.me>,
Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>Raimond Dragomir wrote:
>>> At present they may or they may not.  It's trivial for them to be the
>>> same,
>>
>> No it's not trivial.
>
>Of course it's trivial. Just reverse the order of the header fields:
>
>Traditional (fig-Forth, F83, etc.):
>
>link (nt points here) | count+flags | name | code field (xt points here) |
>body ...
>
>xt=nt:
>
>name | count+flags | link | code field (xt points here) | body ...
>
>Now you can comfortably reach all fields of the header (through negative
>offsets) and the body from the xt without problems.

ciforth follows the implementation model of fig-Forth.

It has the fields defined at the thop of the assembler source:

C_HOFFSET EQU     0       ;   Offsets of code field in cells, w.r.t. dea}
D_HOFFSET EQU     1       ;   Same for data field}
F_HOFFSET EQU     2       ;   Same for flag field}
L_HOFFSET EQU     3       ;   Same for link field}
N_HOFFSET EQU     4       ;   Same for name field}

It must be possible to rearrange the fields to non-alphabetic order
by manipulating these defines and the Forth should pass all test.
Moreover  application code using documented features
properly using the >CFA >DFA etc. words should keep working too.
Admittedly this is a test I've not done for a long time.

Bottom line:
I can't see that the order of the fields has any substantial impact.

>
>--
>Bernd Paysan
-- 
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] | [next] | [standalone]

#39220

On 5/18/2015 7:30 AM, Albert van der Horst wrote:
> In article <mjb56r$juq$2@dont-email.me>,
> Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>> Raimond Dragomir wrote:
>>>> At present they may or they may not.  It's trivial for them to be the
>>>> same,
>>>
>>> No it's not trivial.
>>
>> Of course it's trivial. Just reverse the order of the header fields:
>>
>> Traditional (fig-Forth, F83, etc.):
>>
>> link (nt points here) | count+flags | name | code field (xt points here) |
>> body ...
>>
>> xt=nt:
>>
>> name | count+flags | link | code field (xt points here) | body ...
>>
>> Now you can comfortably reach all fields of the header (through negative
>> offsets) and the body from the xt without problems.
>
> ciforth follows the implementation model of fig-Forth.
>
> It has the fields defined at the thop of the assembler source:
>
> C_HOFFSET EQU     0       ;   Offsets of code field in cells, w.r.t. dea}

What is DEA?

> D_HOFFSET EQU     1       ;   Same for data field}
> F_HOFFSET EQU     2       ;   Same for flag field}
> L_HOFFSET EQU     3       ;   Same for link field}
> N_HOFFSET EQU     4       ;   Same for name field}
>
> It must be possible to rearrange the fields to non-alphabetic order
> by manipulating these defines and the Forth should pass all test.
> Moreover  application code using documented features
> properly using the >CFA >DFA etc. words should keep working too.
> Admittedly this is a test I've not done for a long time.
>
> Bottom line:
> I can't see that the order of the fields has any substantial impact.
>
>>
>> --
>> Bernd Paysan


-- 

Rick

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

#39241

> What is DEA?

Maybe Dictionary Effective Address ?

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

#39261

On Sun, 24 May 2015 02:19:57 -0400, Raimond Dragomir  
<raimond.dragomir@gmail.com> wrote:

>> What is DEA?
>
> Maybe Dictionary Effective Address ?

I assumed it was just a misspelling for DFA,
but maybe it's "dictionary entry address"?


Rod Pemberton
-- 
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?

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

#39405

On Sun, 24 May 2015 20:18:46 -0400, Rod Pemberton <fork@lllljunkqwer.cpm>  
wrote:
> On Sun, 24 May 2015 02:19:57 -0400, Raimond Dragomir  
> <raimond.dragomir@gmail.com> wrote:

>>> What is DEA?
>>
>> Maybe Dictionary Effective Address ?
>
> I assumed it was just a misspelling for DFA,
> but maybe it's "dictionary entry address"?
>

Albert clarified this slightly in "How to intepret (sic) ' '" thread:

AvdH> "... could mean "get me the dea (xt) of tick"


Rod Pemberton

-- 
If fewer guns reduced murders, how does one explain
Moscow, Chicago, New York, and South Africa?

[toc] | [prev] | [standalone]

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

csiph-web