Sujet : Re: Implementing DOES>: How not to do it (and why not) and how to do it
De : oh2aun (at) *nospam* gmail.com (FFmike)
Groupes : comp.lang.forthDate : 04. Aug 2024, 16:07:12
Autres entêtes
Organisation : novaBBS
Message-ID : <aa8e94c07b9a2eb06b634c8d642a76fc@www.novabbs.com>
References : 1 2 3 4
User-Agent : Rocksolid Light
On Sun, 4 Aug 2024 14:52:47 +0000, FFmike wrote:
On Sun, 4 Aug 2024 11:24:42 +0000, albert@spenarnc.xs4all.nl wrote:
>
In article <c2588b8c811fd3ae75d3976c3a927fc3@www.novabbs.com>,
FFmike <oh2aun@gmail.com> wrote:
This post inspired me to remove all the DOLIT DODOES DOCREATE and DOUSER
stuff and to instead
compile a inline code literal and a jump to the common class code.
>
CREATE was modified to compile one inline literal, a RETURN and a NOP,
the literal points to the data area. Later the RETURN and NOP are
replaced by a JUMP to code after DOES> or in USER.
>
Afterwards a second DOES> is required to change the behaviour.
Is that possible with this setup.
>
I do not understand. I have only one DOES>
>
: value: create , does> @ ; ok
see value:
2ce2 ec8f call create
2ce6 ec17 call ,
2cea ecff call (does>)
2cee efa5 goto @
>
here u. c1ec ok
>
1234 value: a-value ok
see a-value
2cfc 0ec1 pushl c1
2cfe 0eec pushl ec
2d00 ef77 goto 2cee
>
a-value . 1234 ok
>
What is the second DOES> needed for ?
Maybe you meant (DOES>) which is compiled by executing DOES> ?
Implementing DOES>: How not to do it (and why not) and how to do it
Re: Implementing DOES>: How not to do it (and why not) and how to do it