Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Redesigning Forth's word headers
86 views
Skip to first unread message
Bernd Paysan
May 7, 2012, 9:28:33 PM5/7/12
to
There have been some header ideas for Gforth from Anton around for
years, featuring an intelligent COMPILE, and some sort of quite-unified
token, but not-quite-so, as this unified token was the nt, and would not
directly EXECUTE. The discussion over mono-tokenizm has proceeded in
the meantime, and during a long e-mail discussion over the last week,
another new header design idea emerged.
The main idea I have about this header design is, that the actions you
want to do with a word - apart from the trivial EXECUTE - should be
methods in a mini-oof style (because that's small enough to implement
even on a Gforth EC target - the only deviation I'm going to make is
that the VT will be one cell before the "object pointer" - our object is
an xt). The virtual table approach also saves space, as most words will
have the same virtual method table (vt). All selectors take the xt from
the top of stack, and pass it on to the method.
As this should be the only token a word has (no separate NT), it should
also reliably give the name of the word. This is a bit tricky.
The header structure looks like this and the pointer points to the code
field (in threaded code, this is an address, in native code, this is the
code).
the xt points here
|
v
name-string | count | link | vt | code field (doer) | body
The vt itself contains the following methods, all with the stack effect
( x*i xt -- x*j )
COMPILE, this compiles the execution semantics ("intelligent
compile,")
INTERPRET-XT this is the interpretation semantics
COMPILE-XT this is the compilation semantics
TICK-XT tick action, to implement true aliases and compile-
only words which can't be '-ed
RUN-PRELUDE this is the parse-time action for Manfred Mahlow's
prelude concept
DODOES This points to the code executed by the dodoes doer
we need this in Gforth
The link field also may point to the xt, so there may be changes to
WORDS (>LINK for each traversal? - there will be changes anyways, as
TRAVERSE-WORDLIST is worth to implement). The reason why the name part
is reversed - count last - (the string itself is still in normal order)
is that this way, it is reliable to get the name of a word from its XT.
:NONAME words will have a zero count element, clearly indicating that
there's no name there.
To save space for the vt, identical vts are shared. The sharing is done
as follows: The vt of the currently constructed word (LASTXT) is in a
buffer for vt construction. When the next word header is started, the
system looks if that vt has already been used, and in that case, reuses
the found vt (e.g. the default vt or the vt of immediate words). If
it's unique, new space for a vt is allocated on the dictionary, and the
buffered vt is copied there.
There are no flags, everything currently done with flags in the count
field are done by modifying the vt:
: immediate ['] execute lastxt [defines] compile-xt ;
: compile-only
['] compile-only-error lastxt [defines] interpret-xt
['] ticking-compile-only-error lastxt [defines] tick-xt ;
An alias or synonym is essentially a proxy using DODEFER as doer, and
passing all messages to the xt in the body (which also means that
ticking such a word returns the original xt, unless that's prevented by
a ticking-compile-only-error there, whereas FIND-XT returns a unique
xt).
This design feels quite right, it allows to implement all the backwards
compatibility needed for Gforth's name token (which then is identical to
the xt, but NAME>INT and NAME>COMP can be implemented), it allows to
implement Stephen Pelc's INT-COMP, and COMP-COMP,, and the stuff
necessary for a OOP extension with local contexts but without parsing
words - inspired by Manfred Mahlow - is also feasible. The replacement
for FIND is FIND-XT ( addr u -- xt / 0 ). Just an xt, nothing else.
It will remove some ugly code in Gforth, especially the heuristics to go
from the xt to the name, and all the special-casing for different
headers like aliases and interpret/compile: we have now.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
years, featuring an intelligent COMPILE, and some sort of quite-unified
token, but not-quite-so, as this unified token was the nt, and would not
directly EXECUTE. The discussion over mono-tokenizm has proceeded in
the meantime, and during a long e-mail discussion over the last week,
another new header design idea emerged.
The main idea I have about this header design is, that the actions you
want to do with a word - apart from the trivial EXECUTE - should be
methods in a mini-oof style (because that's small enough to implement
even on a Gforth EC target - the only deviation I'm going to make is
that the VT will be one cell before the "object pointer" - our object is
an xt). The virtual table approach also saves space, as most words will
have the same virtual method table (vt). All selectors take the xt from
the top of stack, and pass it on to the method.
As this should be the only token a word has (no separate NT), it should
also reliably give the name of the word. This is a bit tricky.
The header structure looks like this and the pointer points to the code
field (in threaded code, this is an address, in native code, this is the
code).
the xt points here
|
v
name-string | count | link | vt | code field (doer) | body
The vt itself contains the following methods, all with the stack effect
( x*i xt -- x*j )
COMPILE, this compiles the execution semantics ("intelligent
compile,")
INTERPRET-XT this is the interpretation semantics
COMPILE-XT this is the compilation semantics
TICK-XT tick action, to implement true aliases and compile-
only words which can't be '-ed
RUN-PRELUDE this is the parse-time action for Manfred Mahlow's
prelude concept
DODOES This points to the code executed by the dodoes doer
we need this in Gforth
The link field also may point to the xt, so there may be changes to
WORDS (>LINK for each traversal? - there will be changes anyways, as
TRAVERSE-WORDLIST is worth to implement). The reason why the name part
is reversed - count last - (the string itself is still in normal order)
is that this way, it is reliable to get the name of a word from its XT.
:NONAME words will have a zero count element, clearly indicating that
there's no name there.
To save space for the vt, identical vts are shared. The sharing is done
as follows: The vt of the currently constructed word (LASTXT) is in a
buffer for vt construction. When the next word header is started, the
system looks if that vt has already been used, and in that case, reuses
the found vt (e.g. the default vt or the vt of immediate words). If
it's unique, new space for a vt is allocated on the dictionary, and the
buffered vt is copied there.
There are no flags, everything currently done with flags in the count
field are done by modifying the vt:
: immediate ['] execute lastxt [defines] compile-xt ;
: compile-only
['] compile-only-error lastxt [defines] interpret-xt
['] ticking-compile-only-error lastxt [defines] tick-xt ;
An alias or synonym is essentially a proxy using DODEFER as doer, and
passing all messages to the xt in the body (which also means that
ticking such a word returns the original xt, unless that's prevented by
a ticking-compile-only-error there, whereas FIND-XT returns a unique
xt).
This design feels quite right, it allows to implement all the backwards
compatibility needed for Gforth's name token (which then is identical to
the xt, but NAME>INT and NAME>COMP can be implemented), it allows to
implement Stephen Pelc's INT-COMP, and COMP-COMP,, and the stuff
necessary for a OOP extension with local contexts but without parsing
words - inspired by Manfred Mahlow - is also feasible. The replacement
for FIND is FIND-XT ( addr u -- xt / 0 ). Just an xt, nothing else.
It will remove some ugly code in Gforth, especially the heuristics to go
from the xt to the name, and all the special-casing for different
headers like aliases and interpret/compile: we have now.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
hwf...@gmail.com
May 8, 2012, 12:38:52 AM5/8/12
to
On Monday, May 7, 2012 6:28:33 PM UTC-7, Bernd Paysan wrote:
> This design feels quite right, it allows to implement all the backwards
> compatibility needed for Gforth's name token (which then is identical to
> the xt, but NAME>INT and NAME>COMP can be implemented), it allows to
> implement Stephen Pelc's INT-COMP, and COMP-COMP,, and the stuff
> necessary for a OOP extension with local contexts but without parsing
> words - inspired by Manfred Mahlow - is also feasible. The replacement
> for FIND is FIND-XT ( addr u -- xt / 0 ).
How does Mahlow's OOP compare to Mini OOF?
> This design feels quite right, it allows to implement all the backwards
> compatibility needed for Gforth's name token (which then is identical to
> the xt, but NAME>INT and NAME>COMP can be implemented), it allows to
> implement Stephen Pelc's INT-COMP, and COMP-COMP,, and the stuff
> necessary for a OOP extension with local contexts but without parsing
> words - inspired by Manfred Mahlow - is also feasible. The replacement
> for FIND is FIND-XT ( addr u -- xt / 0 ).
-Brad
Alex McDonald
May 8, 2012, 2:13:26 AM5/8/12
to
tick of compile-only words that can't be ticked. I'd need to see an
example of that.
Gerry Jackson
May 8, 2012, 4:42:34 AM5/8/12
to
On 08/05/2012 02:28, Bernd Paysan wrote:
> The header structure looks like this and the pointer points to the code
> field (in threaded code, this is an address, in native code, this is the
> code).
>
> the xt points here
> |
> v
> name-string | count | link | vt | code field (doer) | body
>
> The vt itself contains the following methods, all with the stack effect
> ( x*i xt -- x*j )
>
> COMPILE, this compiles the execution semantics ("intelligent
> compile,")
> INTERPRET-XT this is the interpretation semantics
> COMPILE-XT this is the compilation semantics
> TICK-XT tick action, to implement true aliases and compile-
> only words which can't be '-ed
> RUN-PRELUDE this is the parse-time action for Manfred Mahlow's
> prelude concept
> DODOES This points to the code executed by the dodoes doer
> we need this in Gforth
>
I've a similar but much simpler system built into my Forth where the
> The header structure looks like this and the pointer points to the code
> field (in threaded code, this is an address, in native code, this is the
> code).
>
> the xt points here
> |
> v
> name-string | count | link | vt | code field (doer) | body
>
> The vt itself contains the following methods, all with the stack effect
> ( x*i xt -- x*j )
>
> COMPILE, this compiles the execution semantics ("intelligent
> compile,")
> INTERPRET-XT this is the interpretation semantics
> COMPILE-XT this is the compilation semantics
> TICK-XT tick action, to implement true aliases and compile-
> only words which can't be '-ed
> RUN-PRELUDE this is the parse-time action for Manfred Mahlow's
> prelude concept
> DODOES This points to the code executed by the dodoes doer
> we need this in Gforth
>
body of a word looks like
the xt points here
|
v
and the vt points to methods (using your names)
INTERPRET-XT
COMPILE-XT
run-time token
where the run-time token is not a method but the equivalent of your
"code field (doer)". To avoid a vt for each primitive the vt for
primitives omits the run-time token. I still use flags for immediacy and
other things and the header is separated from the body.
Please could you explain your need for "intelligent compile," and give
more detail on the need for TICK-XT and RUN-PRELUDE.
points to the vt of the original word.
>
> This design feels quite right, it allows to implement all the backwards
> compatibility needed for Gforth's name token (which then is identical to
> the xt, but NAME>INT and NAME>COMP can be implemented), it allows to
> implement Stephen Pelc's INT-COMP, and COMP-COMP,, and the stuff
> necessary for a OOP extension with local contexts but without parsing
> words - inspired by Manfred Mahlow - is also feasible.
--
Gerry
BruceMcF
May 8, 2012, 7:19:19 AM5/8/12
to
['] ticking-compile-only-error lastxt [defines] tick-xt
... so when you tick rather than FIND-XT a COMPILE-ONLY word, you
trigger the compile-only error rather than being handed the xt of the
word.
Anton Ertl
May 8, 2012, 10:06:35 AM5/8/12
to
Alex McDonald <bl...@rivadpm.com> writes:
>Can you elaborate on the TICK-XT? Particularly the reference to the
>tick of compile-only words that can't be ticked. I'd need to see an
>example of that.
: foo ." foo" ; immediate compile-only
>Can you elaborate on the TICK-XT? Particularly the reference to the
>tick of compile-only words that can't be ticked. I'd need to see an
>example of that.
' foo
gives an error
:2: Cannot tick compile-only word (try COMP' ... DROP)
' >>>foo<<<
on 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 2011: http://www.euroforth.org/ef11/
Anton Ertl
May 8, 2012, 10:08:47 AM5/8/12
to
Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>Please could you explain your need for "intelligent compile,"
In the old times, you just used "," to compile a word. With
>Please could you explain your need for "intelligent compile,"
native-code compilers as well as with a primitive-centric design such
as Gforth, you want to perform different actions depending on the word
you "compile,". That's the "intelligent COMPILE,".
An example:
create foo
: bar ;
: bla foo bar ;
simple-see bla
shows:
$7FFFF6829688 lit
$7FFFF6829690 <foo>
$7FFFF6829698 call
$7FFFF68296A0 <bar>
$7FFFF68296A8 ;s ok
Note that the two words are compiled to two different primitives
followed by the body address of the respective word. To achive this,
you need a little more intelligence in COMPILE, than "," provides.
Gerry Jackson
May 8, 2012, 11:15:06 AM5/8/12
to
On 08/05/2012 15:08, Anton Ertl wrote:
> Gerry Jackson<ge...@jackson9000.fsnet.co.uk> writes:
>> Please could you explain your need for "intelligent compile,"
>
> In the old times, you just used "," to compile a word. With
> native-code compilers as well as with a primitive-centric design such
> as Gforth, you want to perform different actions depending on the word
> you "compile,". That's the "intelligent COMPILE,".
>
> An example:
>
> create foo
> : bar ;
> : bla foo bar ;
> simple-see bla
>
> shows:
>
> $7FFFF6829688 lit
> $7FFFF6829690<foo>
> $7FFFF6829698 call
> $7FFFF68296A0<bar>
> $7FFFF68296A8 ;s ok
>
> Note that the two words are compiled to two different primitives
> followed by the body address of the respective word. To achive this,
> you need a little more intelligence in COMPILE, than "," provides.
>
I thought it must mean something a bit more involved than that. My
> Gerry Jackson<ge...@jackson9000.fsnet.co.uk> writes:
>> Please could you explain your need for "intelligent compile,"
>
> In the old times, you just used "," to compile a word. With
> native-code compilers as well as with a primitive-centric design such
> as Gforth, you want to perform different actions depending on the word
> you "compile,". That's the "intelligent COMPILE,".
>
> An example:
>
> create foo
> : bar ;
> : bla foo bar ;
> simple-see bla
>
> shows:
>
> $7FFFF6829688 lit
> $7FFFF6829690<foo>
> $7FFFF6829698 call
> $7FFFF68296A0<bar>
> $7FFFF68296A8 ;s ok
>
> Note that the two words are compiled to two different primitives
> followed by the body address of the respective word. To achive this,
> you need a little more intelligence in COMPILE, than "," provides.
>
system also compiles a similar sequence to that above, but it does it
without the need for a separate COMPILE, method in the vt (using Bernd's
terminology and names). My system does that by the Forth word COMPILE,
executing the method COMPILE-XT in the vt for CREATE.
--
Gerry
Gerry Jackson
May 8, 2012, 12:06:21 PM5/8/12
to
My system does that by the text interpreter executing the method
COMPILE-XT in the vt for CREATE at compile time.
--
Gerry
Albert van der Horst
May 8, 2012, 2:29:32 PM5/8/12
to
In article <2012May...@mips.complang.tuwien.ac.at>,
$7FFFF6829688 lit
$7FFFF6829690 BODY of <foo>
created.
(I have the notion of data field in my Forth, but it is not identical
to the body. )
>
>- 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/
--
--
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
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>>Please could you explain your need for "intelligent compile,"
>
>In the old times, you just used "," to compile a word. With
>native-code compilers as well as with a primitive-centric design such
>as Gforth, you want to perform different actions depending on the word
>you "compile,". That's the "intelligent COMPILE,".
>
>An example:
>
>create foo
>: bar ;
>: bla foo bar ;
>simple-see bla
>
>shows:
>
>$7FFFF6829688 lit
>$7FFFF6829690 <foo>
>$7FFFF6829698 call
>$7FFFF68296A0 <bar>
>$7FFFF68296A8 ;s ok
Shouldn't that be
>Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>>Please could you explain your need for "intelligent compile,"
>
>In the old times, you just used "," to compile a word. With
>native-code compilers as well as with a primitive-centric design such
>as Gforth, you want to perform different actions depending on the word
>you "compile,". That's the "intelligent COMPILE,".
>
>An example:
>
>create foo
>: bar ;
>: bla foo bar ;
>simple-see bla
>
>shows:
>
>$7FFFF6829688 lit
>$7FFFF6829690 <foo>
>$7FFFF6829698 call
>$7FFFF68296A0 <bar>
>$7FFFF68296A8 ;s ok
$7FFFF6829688 lit
$7FFFF6829690 BODY of <foo>
$7FFFF6829698 call
$7FFFF68296A0 <bar>
$7FFFF68296A8 ;s ok
>
>Note that the two words are compiled to two different primitives
>followed by the body address of the respective word. To achive this,
>you need a little more intelligence in COMPILE, than "," provides.
call followed by " body of <bar>" ? It has no body because it is not
$7FFFF68296A0 <bar>
$7FFFF68296A8 ;s ok
>
>Note that the two words are compiled to two different primitives
>followed by the body address of the respective word. To achive this,
>you need a little more intelligence in COMPILE, than "," provides.
created.
(I have the notion of data field in my Forth, but it is not identical
to the body. )
>
>- 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/
--
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
BruceMcF
May 8, 2012, 3:22:23 PM5/8/12
to
On May 8, 11:15 am, Gerry Jackson <ge...@jackson9000.fsnet.co.uk>
wrote:
But how would it know what to compile without any flags in the header
for the different cases? In this approach, I'd expect the Forth word
COMPILE, would simply execute the COMPILE, method in the vt associated
with the xt, so COMPILE, would inherit whatever special compilation
was specified for that word.
wrote:
for the different cases? In this approach, I'd expect the Forth word
COMPILE, would simply execute the COMPILE, method in the vt associated
with the xt, so COMPILE, would inherit whatever special compilation
was specified for that word.
Mark Wills
May 8, 2012, 3:52:49 PM5/8/12
to
shared by other words) containing a list of addresses to execute for
the desired action? (COMPILE, INTERPRET-XT etc.)
Mark
Bernd Paysan
May 8, 2012, 5:46:50 PM5/8/12
to
instance variables of a class into a private wordlist. The predule of
an object or class (the "parse-time action") pushes this wordlist on top
of the search order, and the predule of the next word (a message) pops
it again. AFAIK, Mahlow's OOP only supports encapsulation, but not late
binding (no vt). So to speak, it has an almost orthogonal feature set
to Mini OOF, which supports late binding through a vt, but no
encapsulation at all.
The point of RUN-PRELUDE is to define parse-time actions that only
affect the parser (the INTERPRET loop), and don't go into the
dictionary. Using this concept, objects and methods don't need to be
immediate - or worse - parsing words.
Bernd Paysan
May 8, 2012, 5:47:27 PM5/8/12
to
Mark Wills wrote:
> Is vt essentially a pointer to a structure (that can potentially be
> shared by other words) containing a list of addresses to execute for
> the desired action? (COMPILE, INTERPRET-XT etc.)
Yes, you got it.
> Is vt essentially a pointer to a structure (that can potentially be
> shared by other words) containing a list of addresses to execute for
> the desired action? (COMPILE, INTERPRET-XT etc.)
Bernd Paysan
May 8, 2012, 6:09:55 PM5/8/12
to
Gerry Jackson wrote:
> I've a similar but much simpler system built into my Forth where the
> body of a word looks like
>
> the xt points here
> |
> v
> vt | body
>
> and the vt points to methods (using your names)
>
> INTERPRET-XT
> COMPILE-XT
> run-time token
>
> where the run-time token is not a method but the equivalent of your
> "code field (doer)". To avoid a vt for each primitive the vt for
> primitives omits the run-time token. I still use flags for immediacy
> and other things and the header is separated from the body.
Is the run time token actual code (a jump to the doer), so that you can
> I've a similar but much simpler system built into my Forth where the
> body of a word looks like
>
> the xt points here
> |
> v
> vt | body
>
> and the vt points to methods (using your names)
>
> INTERPRET-XT
> COMPILE-XT
> run-time token
>
> where the run-time token is not a method but the equivalent of your
> "code field (doer)". To avoid a vt for each primitive the vt for
> primitives omits the run-time token. I still use flags for immediacy
> and other things and the header is separated from the body.
really leave it away for primitives? Yes, this can be done if you have
that much control over your platform. In Gforth, we don't.
> Please could you explain your need for "intelligent compile," and give
> more detail on the need for TICK-XT and RUN-PRELUDE.
exact semantics of COMPILE,, you can implement this in your system,
using COMPILE-XT - which then would be identical to COMPILE,. However,
the Forth-94 standard specifies COMPILE, to compile the execution
semantics, which can be different from the compilation semantics (for
immediate words, e.g.). This is a corner case of the standard, and you
probably won't see many problems by just ignoring that fact.
RUN-PRELUDE is a parse-time action, and handles a class of problems
well, which otherwise require parsing words, state-smart words (or let's
say, words with special compilation semantics) and other nasty things.
The sequence of compilation/interpretation with RUN-PRELUDE is something
like
PARSE-NAME FIND-XT DUP >R RUN-PRELUDE R> COMPILE-XT/INTERPRET-XT
Error handling left aside.
TICK-XT is there to produce a throw code when you tick a word which you
aren't allowed to tick. The main difference from INTERPRET-XT (which
will produce a throw code when you interpret a word you aren't allowed
to interpret) is that TICK-XT just returns the xt of the word in the
other case. Also, for synonyms, TICK-XT converts the synonym xt to the
original xt.
NAME>COMP in Gforth is equivalent to fetching the XT for COMPILE-XT, and
NAME?INT is equivalent to running TICK-XT (I just don't like the name
NAME?INT for this purpose). NAME>INT, which returns either xt or error
code thrower will be more ugly, something like
: name>int ( nt -- xt ) ['] tick-xt catch
-2048 = IF drop ['] compile-only-error THEN ;
In most cases where it's used now it actually better becomes a NOOP.
> Separated headers make a synonym simple, the synonym's header just
> points to the vt of the original word.
the xt. Different tradeoff.
>> This design feels quite right, it allows to implement all the
>> backwards compatibility needed for Gforth's name token (which then is
>> identical to the xt, but NAME>INT and NAME>COMP can be implemented),
>> it allows to implement Stephen Pelc's INT-COMP, and COMP-COMP,, and
>> the stuff necessary for a OOP extension with local contexts but
>> without parsing words - inspired by Manfred Mahlow - is also
>> feasible.
>
> Is there a reference for this?
Pelc's concept, as discussed on the last EuroForth (was there a paper?
I remember a usenet posting, but damn'd Google doesn't like searches for
words like "INT-COMP,", because Google thinks - and , are not
meaningful).
Manfred Mahlow's OOP and prelude concept has been discussed on various
EuroForths and Forth Tagung, but I have to dig up actual papers on it.
Alex McDonald
May 8, 2012, 8:03:33 PM5/8/12
to
On May 8, 3:09 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
7 hits. I didn't see anything from Stephen.
> Gerry Jackson wrote:
>
> > Is there a reference for this?
>
> What "this"? There are at least two things to be referenced - Stephen
> Pelc's concept, as discussed on the last EuroForth (was there a paper?
> I remember a usenet posting, but damn'd Google doesn't like searches for
> words like "INT-COMP,", because Google thinks - and , are not
> meaningful).
Try this http://groups.google.com/group/comp.lang.forth/search?group=comp.lang.forth&q=%22int-comp%2C%22&qt_g=Search+this+group
>
> > Is there a reference for this?
>
> What "this"? There are at least two things to be referenced - Stephen
> Pelc's concept, as discussed on the last EuroForth (was there a paper?
> I remember a usenet posting, but damn'd Google doesn't like searches for
> words like "INT-COMP,", because Google thinks - and , are not
> meaningful).
7 hits. I didn't see anything from Stephen.
Anton Ertl
May 9, 2012, 5:47:06 AM5/9/12
to
Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>I thought it must mean something a bit more involved than that. My
>system also compiles a similar sequence to that above, but it does it
>without the need for a separate COMPILE, method in the vt (using Bernd's
>terminology and names). My system does that by the Forth word COMPILE,
>executing the method COMPILE-XT in the vt for CREATE.
The COMPILE-XT represents a part of the compilation semantics; it
>I thought it must mean something a bit more involved than that. My
>system also compiles a similar sequence to that above, but it does it
>without the need for a separate COMPILE, method in the vt (using Bernd's
>terminology and names). My system does that by the Forth word COMPILE,
>executing the method COMPILE-XT in the vt for CREATE.
typically calls COMPILE, (for words with default compilation
semantics) or EXECUTE (for immediate words). So for words with
non-default compilation semantics COMPILE,ing the xt (which represents
the execution/interpretation semantics) is different from performing
the compilation semantics:
: foo ." foo" ; immediate
: flip ['] foo compile, ;
: flop foo ;
does this on a standard system:
: foo ." foo" ; immediate ok
: flip ['] foo compile, ; ok
: flop foo ; foo ok
Anton Ertl
May 9, 2012, 6:10:57 AM5/9/12
to
word-type-specific sequence when compiling with the text interpreter,
but something else (what?) when compiling with "COMPILE,".
Rod Pemberton
May 9, 2012, 6:23:31 AM5/9/12
to
"Bernd Paysan" <bernd....@gmx.de> wrote in message
news:jo9ss1$3vm$1...@online.de...
below? (yes) So, you're talking about a structure with multiple CFAs or
pointers to "action routines", but one for each of the standard compiler
operations. I'm not sure why anyone would want the name-string
and count first ... except for historical reasons.
> The vt itself contains the following methods, all with the stack effect
> ( x*i xt -- x*j )
>
> COMPILE, this compiles the execution semantics ("intelligent
> compile,")
> INTERPRET-XT this is the interpretation semantics
> COMPILE-XT this is the compilation semantics
> TICK-XT tick action, to implement true aliases and compile-
> only words which can't be '-ed
> RUN-PRELUDE this is the parse-time action for Manfred Mahlow's
> prelude concept
> DODOES This points to the code executed by the dodoes doer
> we need this in Gforth
>
...
> To save space for the vt, identical vts are shared. The sharing is done
> as follows: The vt of the currently constructed word (LASTXT) is in a
> buffer for vt construction. When the next word header is started, the
> system looks if that vt has already been used, and in that case, reuses
> the found vt (e.g. the default vt or the vt of immediate words). If
> it's unique, new space for a vt is allocated on the dictionary, and the
> buffered vt is copied there.
So, once a vt is defined for a word, are you saying it can't be modified?
...
Doesn't Forth need to change semantics for enhanced words from some of the
Forth extension wordsets?
Since the vt is most likely shared with another word for most words, you'd
also need a method to unshare the vt prior to modifying it's semantics.
Rod Pemberton
news:jo9ss1$3vm$1...@online.de...
> There have been some header ideas for Gforth from Anton around for
> years, featuring an intelligent COMPILE, and some sort of quite-unified
> token, but not-quite-so, as this unified token was the nt, and would not
> directly EXECUTE. The discussion over mono-tokenizm has proceeded in
> the meantime, and during a long e-mail discussion over the last week,
> another new header design idea emerged.
>
> The main idea I have about this header design is, that the actions you
> want to do with a word - apart from the trivial EXECUTE - should be
> methods in a mini-oof style (because that's small enough to implement
> even on a Gforth EC target - the only deviation I'm going to make is
> that the VT will be one cell before the "object pointer" - our object is
> an xt). The virtual table approach also saves space, as most words will
> have the same virtual method table (vt). All selectors take the xt from
> the top of stack, and pass it on to the method.
>
> As this should be the only token a word has (no separate NT), it should
> also reliably give the name of the word. This is a bit tricky.
>
> The header structure looks like this and the pointer points to the code
> field (in threaded code, this is an address, in native code, this is the
> code).
>
> the xt points here
> |
> v
> name-string | count | link | vt | code field (doer) | body
>
vt is the diagram above is a pointer to the structure of actions listed
> years, featuring an intelligent COMPILE, and some sort of quite-unified
> token, but not-quite-so, as this unified token was the nt, and would not
> directly EXECUTE. The discussion over mono-tokenizm has proceeded in
> the meantime, and during a long e-mail discussion over the last week,
> another new header design idea emerged.
>
> The main idea I have about this header design is, that the actions you
> want to do with a word - apart from the trivial EXECUTE - should be
> methods in a mini-oof style (because that's small enough to implement
> even on a Gforth EC target - the only deviation I'm going to make is
> that the VT will be one cell before the "object pointer" - our object is
> an xt). The virtual table approach also saves space, as most words will
> have the same virtual method table (vt). All selectors take the xt from
> the top of stack, and pass it on to the method.
>
> As this should be the only token a word has (no separate NT), it should
> also reliably give the name of the word. This is a bit tricky.
>
> The header structure looks like this and the pointer points to the code
> field (in threaded code, this is an address, in native code, this is the
> code).
>
> the xt points here
> |
> v
> name-string | count | link | vt | code field (doer) | body
>
below? (yes) So, you're talking about a structure with multiple CFAs or
pointers to "action routines", but one for each of the standard compiler
operations. I'm not sure why anyone would want the name-string
and count first ... except for historical reasons.
> The vt itself contains the following methods, all with the stack effect
> ( x*i xt -- x*j )
>
> COMPILE, this compiles the execution semantics ("intelligent
> compile,")
> INTERPRET-XT this is the interpretation semantics
> COMPILE-XT this is the compilation semantics
> TICK-XT tick action, to implement true aliases and compile-
> only words which can't be '-ed
> RUN-PRELUDE this is the parse-time action for Manfred Mahlow's
> prelude concept
> DODOES This points to the code executed by the dodoes doer
> we need this in Gforth
>
> To save space for the vt, identical vts are shared. The sharing is done
> as follows: The vt of the currently constructed word (LASTXT) is in a
> buffer for vt construction. When the next word header is started, the
> system looks if that vt has already been used, and in that case, reuses
> the found vt (e.g. the default vt or the vt of immediate words). If
> it's unique, new space for a vt is allocated on the dictionary, and the
> buffered vt is copied there.
...
Doesn't Forth need to change semantics for enhanced words from some of the
Forth extension wordsets?
Since the vt is most likely shared with another word for most words, you'd
also need a method to unshare the vt prior to modifying it's semantics.
Rod Pemberton
Gerry Jackson
May 9, 2012, 6:42:42 AM5/9/12
to
On 08/05/2012 23:09, Bernd Paysan wrote:
primitives it is held in the body of the primitive, after the vt pointer.
> Yes, this can be done if you have
> that much control over your platform. In Gforth, we don't.
>
>> Please could you explain your need for "intelligent compile," and give
>> more detail on the need for TICK-XT and RUN-PRELUDE.
>
> Anton has already explained, but actually, if you don't care about the
> exact semantics of COMPILE,, you can implement this in your system,
> using COMPILE-XT - which then would be identical to COMPILE,.
Yes, as I replied to Anton, that is what I do. I thought there may have
been more to it.
> However,
> the Forth-94 standard specifies COMPILE, to compile the execution
> semantics, which can be different from the compilation semantics (for
> immediate words, e.g.).
For immediate words that's not a problem as I use a flag to indicate
those so that immediate words are handled during compilation by the text
interpreter. There aren't many words that have different execution and
compilation semantics - the xt of TO and compile only words cannot be
portably obtained by ' etc. It can for S" and indeed COMPILE, doesn't
work correctly with the xt of S", but wasn't there talk a few months ago
that postponing S" and getting the xt of S" was likely an oversight in
ANS Forth? Anyway I'll fix that.
> This is a corner case of the standard, and you
> probably won't see many problems by just ignoring that fact.
>
[...]
Thanks for the explanation of TICK-XT etc.
>
>> Separated headers make a synonym simple, the synonym's header just
>> points to the vt of the original word.
>
> On the other hand, united headers makes it simple to find the name from
> the xt. Different tradeoff.
Certainly, but I can't remember a case where I really wished I could
recent item i.e. the Manfred Mahlow stuff.
- Stephen
> Pelc's concept, as discussed on the last EuroForth (was there a paper?
> I remember a usenet posting, but damn'd Google doesn't like searches for
> words like "INT-COMP,", because Google thinks - and , are not
> meaningful).
Yes, I hate Google at the moment because, when I was searching the c.l.f
archives in Google Groups yesterday, it barred me for several hours
because their stupid software detected my activity as suspicious as if I
was trying to guess at a capcha image.
>
> Manfred Mahlow's OOP and prelude concept has been discussed on various
> EuroForths and Forth Tagung, but I have to dig up actual papers on it.
>
Thanks, I'll have a look in the EuroForth papers.
--
Gerry
> Gerry Jackson wrote:
>> and the vt points to methods (using your names)
>>
>> INTERPRET-XT
>> COMPILE-XT
>> run-time token
>>
>> where the run-time token is not a method but the equivalent of your
>> "code field (doer)". To avoid a vt for each primitive the vt for
>> primitives omits the run-time token. I still use flags for immediacy
>> and other things and the header is separated from the body.
>
> Is the run time token actual code (a jump to the doer), so that you can
> really leave it away for primitives?
The run time token is the address of the code for the primitive. For
>> and the vt points to methods (using your names)
>>
>> INTERPRET-XT
>> COMPILE-XT
>> run-time token
>>
>> where the run-time token is not a method but the equivalent of your
>> "code field (doer)". To avoid a vt for each primitive the vt for
>> primitives omits the run-time token. I still use flags for immediacy
>> and other things and the header is separated from the body.
>
> Is the run time token actual code (a jump to the doer), so that you can
> really leave it away for primitives?
primitives it is held in the body of the primitive, after the vt pointer.
> Yes, this can be done if you have
> that much control over your platform. In Gforth, we don't.
>
>> Please could you explain your need for "intelligent compile," and give
>> more detail on the need for TICK-XT and RUN-PRELUDE.
>
> Anton has already explained, but actually, if you don't care about the
> exact semantics of COMPILE,, you can implement this in your system,
> using COMPILE-XT - which then would be identical to COMPILE,.
been more to it.
> However,
> the Forth-94 standard specifies COMPILE, to compile the execution
> semantics, which can be different from the compilation semantics (for
> immediate words, e.g.).
those so that immediate words are handled during compilation by the text
interpreter. There aren't many words that have different execution and
compilation semantics - the xt of TO and compile only words cannot be
portably obtained by ' etc. It can for S" and indeed COMPILE, doesn't
work correctly with the xt of S", but wasn't there talk a few months ago
that postponing S" and getting the xt of S" was likely an oversight in
ANS Forth? Anyway I'll fix that.
> This is a corner case of the standard, and you
> probably won't see many problems by just ignoring that fact.
>
Thanks for the explanation of TICK-XT etc.
>
>> Separated headers make a synonym simple, the synonym's header just
>> points to the vt of the original word.
>
> On the other hand, united headers makes it simple to find the name from
> the xt. Different tradeoff.
find the name from the xt.
>
>
>>> This design feels quite right, it allows to implement all the
>>> backwards compatibility needed for Gforth's name token (which then is
>>> identical to the xt, but NAME>INT and NAME>COMP can be implemented),
>>> it allows to implement Stephen Pelc's INT-COMP, and COMP-COMP,, and
>>> the stuff necessary for a OOP extension with local contexts but
>>> without parsing words - inspired by Manfred Mahlow - is also
>>> feasible.
>>
>> Is there a reference for this?
>
> What "this"? There are at least two things to be referenced
Sorry, use of "this" in that context to me, at least, means the most
>>> backwards compatibility needed for Gforth's name token (which then is
>>> identical to the xt, but NAME>INT and NAME>COMP can be implemented),
>>> it allows to implement Stephen Pelc's INT-COMP, and COMP-COMP,, and
>>> the stuff necessary for a OOP extension with local contexts but
>>> without parsing words - inspired by Manfred Mahlow - is also
>>> feasible.
>>
>> Is there a reference for this?
>
> What "this"? There are at least two things to be referenced
recent item i.e. the Manfred Mahlow stuff.
- Stephen
> Pelc's concept, as discussed on the last EuroForth (was there a paper?
> I remember a usenet posting, but damn'd Google doesn't like searches for
> words like "INT-COMP,", because Google thinks - and , are not
> meaningful).
archives in Google Groups yesterday, it barred me for several hours
because their stupid software detected my activity as suspicious as if I
was trying to guess at a capcha image.
>
> Manfred Mahlow's OOP and prelude concept has been discussed on various
> EuroForths and Forth Tagung, but I have to dig up actual papers on it.
>
--
Gerry
Gerry Jackson
May 9, 2012, 6:49:20 AM5/9/12
to
you ask about are handled by different vt's. I do have a flag for
immediacy so that COMPILE, works with immediate words, but, as I stated
in my reply to Bernd it doesn't for S" and so is incorrect. What other
words/cases are you referring to in your question?
--
Gerry
Anton Ertl
May 9, 2012, 7:35:48 AM5/9/12
to
Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>In article <2012May...@mips.complang.tuwien.ac.at>,
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>create foo
>>: bar ;
>>: bla foo bar ;
>>simple-see bla
>>
>>shows:
>>
>>$7FFFF6829688 lit
>>$7FFFF6829690 <foo>
>>$7FFFF6829698 call
>>$7FFFF68296A0 <bar>
>>$7FFFF68296A8 ;s ok
>
>Shouldn't that be
>
>$7FFFF6829688 lit
>$7FFFF6829690 BODY of <foo>
>$7FFFF6829698 call
>$7FFFF68296A0 <bar>
>$7FFFF68296A8 ;s ok
"<foo>" means "body of foo"
>In article <2012May...@mips.complang.tuwien.ac.at>,
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>create foo
>>: bar ;
>>: bla foo bar ;
>>simple-see bla
>>
>>shows:
>>
>>$7FFFF6829688 lit
>>$7FFFF6829690 <foo>
>>$7FFFF6829698 call
>>$7FFFF68296A0 <bar>
>>$7FFFF68296A8 ;s ok
>
>Shouldn't that be
>
>$7FFFF6829688 lit
>$7FFFF6829690 BODY of <foo>
>$7FFFF6829698 call
>$7FFFF68296A0 <bar>
>$7FFFF68296A8 ;s ok
>call followed by " body of <bar>" ? It has no body because it is not
>created.
the body contains the threaded code for the colon definition.
Gerry Jackson
May 9, 2012, 8:14:16 AM5/9/12
to
On 09/05/2012 10:47, Anton Ertl wrote:
> Gerry Jackson<ge...@jackson9000.fsnet.co.uk> writes:
>> I thought it must mean something a bit more involved than that. My
>> system also compiles a similar sequence to that above, but it does it
>> without the need for a separate COMPILE, method in the vt (using Bernd's
>> terminology and names). My system does that by the Forth word COMPILE,
>> executing the method COMPILE-XT in the vt for CREATE.
>
> The COMPILE-XT represents a part of the compilation semantics; it
> typically calls COMPILE, (for words with default compilation
> semantics) or EXECUTE (for immediate words). So for words with
> non-default compilation semantics COMPILE,ing the xt (which represents
> the execution/interpretation semantics) is different from performing
> the compilation semantics:
>
> : foo ." foo" ; immediate
> : flip ['] foo compile, ;
> : flop foo ;
>
> does this on a standard system:
>
> : foo ." foo" ; immediate ok
> : flip ['] foo compile, ; ok
> : flop foo ; foo ok
>
Yes, and on my system too.
> Gerry Jackson<ge...@jackson9000.fsnet.co.uk> writes:
>> I thought it must mean something a bit more involved than that. My
>> system also compiles a similar sequence to that above, but it does it
>> without the need for a separate COMPILE, method in the vt (using Bernd's
>> terminology and names). My system does that by the Forth word COMPILE,
>> executing the method COMPILE-XT in the vt for CREATE.
>
> The COMPILE-XT represents a part of the compilation semantics; it
> typically calls COMPILE, (for words with default compilation
> semantics) or EXECUTE (for immediate words). So for words with
> non-default compilation semantics COMPILE,ing the xt (which represents
> the execution/interpretation semantics) is different from performing
> the compilation semantics:
>
> : foo ." foo" ; immediate
> : flip ['] foo compile, ;
> : flop foo ;
>
> does this on a standard system:
>
> : foo ." foo" ; immediate ok
> : flip ['] foo compile, ; ok
> : flop foo ; foo ok
>
And also:
: foo ." foo" ; immediate ok
: flop flip ; ok
flop foo ok
However as I stated in my response to Bernd, it fails with S"
--
Gerry
Bernd Paysan
May 9, 2012, 1:58:45 PM5/9/12
to
Rod Pemberton wrote:
>> The header structure looks like this and the pointer points to the
>> code field (in threaded code, this is an address, in native code,
>> this is the code).
>>
>> the xt points here
>> |
>> v
>> name-string | count | link | vt | code field (doer) | body
>>
>
> vt is the diagram above is a pointer to the structure of actions
> listed
> below? (yes) So, you're talking about a structure with multiple CFAs
> or pointers to "action routines", but one for each of the standard
> compiler operations.
Yes.
>> The header structure looks like this and the pointer points to the
>> code field (in threaded code, this is an address, in native code,
>> this is the code).
>>
>> the xt points here
>> |
>> v
>> name-string | count | link | vt | code field (doer) | body
>>
>
> vt is the diagram above is a pointer to the structure of actions
> listed
> below? (yes) So, you're talking about a structure with multiple CFAs
> or pointers to "action routines", but one for each of the standard
> compiler operations.
> I'm not sure why anyone would want the name-string
> and count first ... except for historical reasons.
>> To save space for the vt, identical vts are shared. The sharing is
>> done as follows: The vt of the currently constructed word (LASTXT) is
>> in a
>> buffer for vt construction. When the next word header is started,
>> the system looks if that vt has already been used, and in that case,
>> reuses
>> the found vt (e.g. the default vt or the vt of immediate words). If
>> it's unique, new space for a vt is allocated on the dictionary, and
>> the buffered vt is copied there.
>
> So, once a vt is defined for a word, are you saying it can't be
> modified?
previously defined word "current" with respect to immediate and friends,
by copying the VT back to the construction buffer. Then, the next
definition (or the next >LASTXT) will perform the compression.
In Forth, as we have it now, you can't change any behavior apart from
the latest definition.
> Doesn't Forth need to change semantics for enhanced words from some of
> the Forth extension wordsets?
you can load the file wordset to a smaller kernel - for start, how would
you do that without files? ;-).
> Since the vt is most likely shared with another word for most words,
> you'd also need a method to unshare the vt prior to modifying it's
> semantics.
BruceMcF
May 9, 2012, 2:54:10 PM5/9/12
to
On May 9, 6:49 am, Gerry Jackson <ge...@jackson9000.fsnet.co.uk>
wrote:
implementation and so varies by implementation approach and technique,
including flagging for dual / single xt, flagging for code that is
suitable for embedding, flagging for code that has a standard entry
and an alternate entry to replace a preceding DROP or DUP and etc.
wrote:
> I do have a flag for immediacy so that COMPILE, works with immediate words,
> but, as I stated in my reply to Bernd it doesn't for S" and so is incorrect.
> What other words/cases are you referring to in your question?
IMMEDIATE is the cross-platform case, the others depend upon the
> but, as I stated in my reply to Bernd it doesn't for S" and so is incorrect.
> What other words/cases are you referring to in your question?
implementation and so varies by implementation approach and technique,
including flagging for dual / single xt, flagging for code that is
suitable for embedding, flagging for code that has a standard entry
and an alternate entry to replace a preceding DROP or DUP and etc.
BruceMcF
May 9, 2012, 3:00:29 PM5/9/12
to
On May 9, 1:58 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Well, S" in the file wordset does so. But it is not very common that
> you can load the file wordset to a smaller kernel - for start, how would
> you do that without files? ;-).
By a pipe redirecting KEY and EMIT in the instance I've seen where the
> Well, S" in the file wordset does so. But it is not very common that
> you can load the file wordset to a smaller kernel - for start, how would
> you do that without files? ;-).
FILEs wordset is loaded. But AFAIR it already had a FILEs compatible
S" so how to define S" didn't arise.
Albert van der Horst
May 10, 2012, 6:14:51 AM5/10/12
to
careful distinction between a data field (containing e.g. the threaded
code) and a body in the sense of the standard.
The data field of a created word contains the body, but it also
must accomodate a DOES> pointer. So in ciforth
: >BODY >DFA @ CELL+ ;
: DOES> R> LATEST >DFA @ ! ;
Colon interpretation just starts at `` DFA @ ''
This was the first thing I did to make headers as consistent as
possible.
>
>- anton
>--
Mark Wills
May 10, 2012, 6:59:36 AM5/10/12
to
On May 10, 11:14 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <2012May9.133...@mips.complang.tuwien.ac.at>,
> albert@spe&ar&c.xs4all.nl &=nhttp://home.hccnet.nl/a.w.m.van.der.horst- Hide quoted text -
>
> - Show quoted text -
My understanding is that colon definitions don't have a body as such.
They are a string of XT/CFAs.
CREATEd words have a body (variables, constants, etc).
At least, that's my understanding!
wrote:
> In article <2012May9.133...@mips.complang.tuwien.ac.at>,
>
>
>
>
>
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
> >>In article <2012May8.160...@mips.complang.tuwien.ac.at>,
>
>
>
>
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>
> - Show quoted text -
My understanding is that colon definitions don't have a body as such.
They are a string of XT/CFAs.
CREATEd words have a body (variables, constants, etc).
At least, that's my understanding!
Anton Ertl
May 10, 2012, 7:47:09 AM5/10/12
to
Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>In article <2012May...@mips.complang.tuwien.ac.at>,
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>In Gforth, every word has a body. In the case of colon definitions,
>>the body contains the threaded code for the colon definition.
>
>I would say that that can get you in trouble.
What trouble? We have not noticed any.
>In article <2012May...@mips.complang.tuwien.ac.at>,
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>In Gforth, every word has a body. In the case of colon definitions,
>>the body contains the threaded code for the colon definition.
>
>I would say that that can get you in trouble.
0 new messages