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

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

Distinguishing DOES>

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

Contents

  Distinguishing DOES> JennyB <jennybrien@googlemail.com> - 2012-05-03 08:59 -0700
    Re: Distinguishing DOES> Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-03 17:23 -0700
      Re: Distinguishing DOES> Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-05-04 10:47 +0100
        Re: Distinguishing DOES> Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-04 05:12 -0500
          Re: Distinguishing DOES> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-04 11:33 +0000
            Re: Distinguishing DOES> Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-04 08:11 -0500
              Re: Distinguishing DOES> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-04 16:18 +0000
                Re: Distinguishing DOES> Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-05 02:02 -0500
                  Re: Distinguishing DOES> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-05 14:16 +0000
                    Re: Distinguishing DOES> Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-06 02:53 -0500
                  Re: Distinguishing DOES> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-05 14:25 +0000
                    Re: Distinguishing DOES> BruceMcF <agila61@netscape.net> - 2012-05-05 08:07 -0700
                      Re: Distinguishing DOES> Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-08 06:23 -0700
                        Re: Distinguishing DOES> Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-09 00:25 +0200
                          Re: Distinguishing DOES> Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-09 01:26 -0700
                          Re: Distinguishing DOES> Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-09 03:18 -0700
                            Re: Distinguishing DOES> Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-09 05:29 -0500
                            Re: Distinguishing DOES> "Elizabeth D. Rather" <erather@forth.com> - 2012-05-09 07:11 -1000
                          Re: Distinguishing DOES> Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-05-09 22:48 +0100
                            Re: Distinguishing DOES> Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-09 23:22 +0200
                              Re: Distinguishing DOES> Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-05-09 23:43 +0100
                                Re: Distinguishing DOES> Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-10 00:49 +0200
                                  Re: Distinguishing DOES> Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-05-10 11:33 +0100
                              Re: Distinguishing DOES> Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-10 10:02 +0000
                                Re: Distinguishing DOES> Bernd Paysan <bernd.paysan@gmx.de> - 2012-05-10 15:13 +0200
                              Re: Distinguishing DOES> Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-10 05:07 -0700
                                Re: Distinguishing DOES> Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-05-10 22:57 -0700
    Re: Distinguishing DOES> Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-04 12:37 +0000
    Re: Distinguishing DOES> Doug Hoffman <glidedog@gmail.com> - 2012-05-04 10:14 -0400
      Re: Distinguishing DOES> humptydumpty <ouatubi@gmail.com> - 2012-05-04 20:27 +0000
        Re: Distinguishing DOES> Doug Hoffman <glidedog@gmail.com> - 2012-05-05 06:16 -0400
          Re: Distinguishing DOES> JennyB <jennybrien@googlemail.com> - 2012-05-05 07:19 -0700
            Re: Distinguishing DOES> anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-05-05 14:55 +0000
              Re: Distinguishing DOES> JennyB <jennybrien@googlemail.com> - 2012-05-07 07:24 -0700
            Re: Distinguishing DOES> Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-06 11:04 +0000
            Re: Distinguishing DOES> Doug Hoffman <glidedog@gmail.com> - 2012-05-06 07:47 -0400
          Re: Distinguishing DOES> ward@megawolf.com - 2012-05-08 04:39 -0700
            Re: Distinguishing DOES> Doug Hoffman <glidedog@gmail.com> - 2012-05-08 07:50 -0400
    Re: Distinguishing DOES> Hans Bezemer <the.beez.speaks@gmail.com> - 2012-05-05 14:24 +0200
      Re: Distinguishing DOES> Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-06 11:09 +0000

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

#12049

In comp.lang.forth, Bernd Paysan wrote:

> [..] x86 is pretty clean and straight-forward, even considering the time
> it was designed (height of the CISC age), and that it came from Intel. 
> And the two modes added later (386 mode and amd64 mode) are cleanups,
> which make the ISA more orthogonal and useful.  Additions like MMX and
> 3DNow! are phased out and declared obsolesent (and AMD stopps to implement
> 3DNow!).  It's not that awful.  The worst things from Intel all died.

But say: wouldn't it be even more "orthogonal and useful", if they dropped
16-bit legacy, and if the instruction set were restricted to - say - about
100 of carefully chosen commands?

> The ARM ISA is designed by one person, and even then it is one of the 
> more byzantine RISC ISAs, with lots of things cobbled together in one 
> instruction - shifts, conditional execution, normal operations.

Well, maybe; still it seems to be most successful RISC anyway, and I'm very
curious about "project Denver" gear, announced for this year by NVidia.
-- 
Forth is a preserver of health (Hippocrates)

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

#12050

Zbiggy wrote:
> But say: wouldn't it be even more "orthogonal and useful", if they
> dropped 16-bit legacy, and if the instruction set were restricted to -
> say - about 100 of carefully chosen commands?

Intel actually had a 386 version that did drop the 16-bit legacy and 
some other stuff:

http://en.wikipedia.org/wiki/Intel_80376

It was a commercial failure.  The 386EX, which did not drop 16-bit 
legacy, was much more successful.  You can't say they haven't tried.

>> The ARM ISA is designed by one person, and even then it is one of the
>> more byzantine RISC ISAs, with lots of things cobbled together in one
>> instruction - shifts, conditional execution, normal operations.
> 
> Well, maybe; still it seems to be most successful RISC anyway, and I'm
> very curious about "project Denver" gear, announced for this year by
> NVidia.

Well, they were the first to get the business model right: sell cores to 
everybody, while all the other RISC cores were only available as chips.  
First movers have incredible advantages in these winner-takes-it-all 
markets.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#12056

In comp.lang.forth, Bernd Paysan wrote:

>> But say: wouldn't it be even more "orthogonal and useful", if they
>> dropped 16-bit legacy, and if the instruction set were restricted to -
>> say - about 100 of carefully chosen commands?
>
> Intel actually had a 386 version that did drop the 16-bit legacy and 
> some other stuff:
>
> http://en.wikipedia.org/wiki/Intel_80376
>
> It was a commercial failure.  The 386EX, which did not drop 16-bit 
> legacy, was much more successful.  You can't say they haven't tried.

They haven't: "The Intel 80376, introduced January 16, 1989, was a variant
of the Intel 80386SX intended for embedded systems".

I meant "general purpose" processor, for PCs.
-- 
Forth is a preserver of health (Hippocrates)

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

#12058

In article <joen7a$a3m$1@online.de>, Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>Zbiggy wrote:
>> There's nothing wrong with dropping "backward compatibility", if this
>> is reasonable.
>
>This comment was clearly tongue-in-check ;-).
>
>But I disagree that the x86 ISA is so long because of backward
>compatibility.  Intel had a chance to demonstrate how a new ISA,
>developed from scratch, would look like, and they came up with IA64.

That is patently incorrect. Intel never wanted to move on from 32
to 64 bits in a compatible way. They had the Itanium. (Same situation
as the 432. )
Then AMD made them to, by inventing a devilishly clever and
obscure way to move to 64 bits. The best proof is that Intel had to
license the instruction set from AMD.

>Intel instruction sets are so lengthy, because they are designed by
>committees.  x86 is actually good look for all of us, because the main

Again. The 8086 was designed by one man Stephen Morse. It was
a clever extension of the 8080 and a reasonable cisc processor,
but without a shred of thought about future enhancements.
(I have his book "8086 architecture". It is adamant about a few
errors and convincing regards design decisions.)
This processor had three characteristics that where in hindsight
responsible for the mess we're in. Too CISCy, segmentation, and
no regards for sufficiently address extensability.
The pressure to stay compatible was what did it.
The "real mode" (a real kludge) was absent in 80286 then reinstated
in the 80386, pressured by mostly Microsoft.

>ISA design team at that time designed i432, and only a few people were
>left to create the x86 ISA (two, IIRC).  Therefore, x86 is pretty clean
>and straight-forward, even considering the time it was designed (height
>of the CISC age), and that it came from Intel.  And the two modes added
>later (386 mode and amd64 mode) are cleanups, which make the ISA more
>orthogonal and useful.  Additions like MMX and 3DNow! are phased out and
>declared obsolesent (and AMD stopps to implement 3DNow!).  It's not that
>awful.  The worst things from Intel all died.
>
>The ARM ISA is designed by one person, and even then it is one of the
>more byzantine RISC ISAs, with lots of things cobbled together in one
>instruction - shifts, conditional execution, normal operations.

Remember the Novix? It has also those bit-fields. They just go
directly to parts of the processor that do e.g. shifting.
That is RISC in my book, direct relation to the hardware without
much regard to the assembler programmer.
Conditional execution in one instruction is a very powerful speed
up mechanism. At the time Intel's alternative (complicated multiple
instruction analysis) was not viable.


>
>--
>Bernd Paysan

Groetjes Albert

(One of the rare occasions that I don't agree with you...)

--
-- 
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]

#12064

Albert van der Horst wrote:
> That is patently incorrect. Intel never wanted to move on from 32
> to 64 bits in a compatible way. They had the Itanium. (Same situation
> as the 432. )

Yes, if they hadn't messed up Itanium so badly, AMD would never have 
succeeded.

> Again. The 8086 was designed by one man Stephen Morse. It was
> a clever extension of the 8080 and a reasonable cisc processor,
> but without a shred of thought about future enhancements.
> (I have his book "8086 architecture". It is adamant about a few
> errors and convincing regards design decisions.)
> This processor had three characteristics that where in hindsight
> responsible for the mess we're in. Too CISCy, segmentation, and
> no regards for sufficiently address extensability.
> The pressure to stay compatible was what did it.
> The "real mode" (a real kludge) was absent in 80286 then reinstated
> in the 80386, pressured by mostly Microsoft.

80286 had real mode and protected mode, but to go back from protected 
mode to real mode, you needed to reset the processor, either by telling 
the keyboard controller to do so or by causing a triple fault (which is 
faster, but Microsoft first used the keybord controller hack).  80386 
had the VM mode, which is much more useful than going back to real mode.

>>The ARM ISA is designed by one person, and even then it is one of the
>>more byzantine RISC ISAs, with lots of things cobbled together in one
>>instruction - shifts, conditional execution, normal operations.
> 
> Remember the Novix? It has also those bit-fields. They just go
> directly to parts of the processor that do e.g. shifting.
> That is RISC in my book, direct relation to the hardware without
> much regard to the assembler programmer.

I'm not convinced. ARM's critical path contains shifter+ALU, which means 
the achievable clock rate is significantly slower than competing RISC 
processors (of that time). The newer ARM cores get higher clock rates by 
dividing the execution stage into two stages, if necessary.

> Conditional execution in one instruction is a very powerful speed
> up mechanism. At the time Intel's alternative (complicated multiple
> instruction analysis) was not viable.

Conditional execution looks nice, but having every instruction 
conditional makes out-of-order execution difficult.

ARM64 drops both the integrated shift field and the omnipresent 
conditional execution - there is still conditional execution, but only 
for instructions where it makes sense (branch, select).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#12131

On May 9, 10:22 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Zbiggy wrote:
> > There's nothing wrong with dropping "backward compatibility", if this
> > is reasonable.
>
> This comment was clearly tongue-in-check ;-).
>
> But I disagree that the x86 ISA is so long because of backward
> compatibility.  Intel had a chance to demonstrate how a new ISA,
> developed from scratch, would look like, and they came up with IA64.
> Intel instruction sets are so lengthy, because they are designed by
> committees.  x86 is actually good look for all of us, because the main
> ISA design team at that time designed i432, and only a few people were
> left to create the x86 ISA (two, IIRC).  Therefore, x86 is pretty clean
> and straight-forward, even considering the time it was designed (height
> of the CISC age), and that it came from Intel.  And the two modes added
> later (386 mode and amd64 mode) are cleanups, which make the ISA more
> orthogonal and useful.  Additions like MMX and 3DNow! are phased out and
> declared obsolesent (and AMD stopps to implement 3DNow!).  It's not that
> awful.  The worst things from Intel all died.
>
> The ARM ISA is designed by one person, and even then it is one of the
> more byzantine RISC ISAs, with lots of things cobbled together in one
> instruction - shifts, conditional execution, normal operations.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://bernd-paysan.de/

The point is, a *new* standard (as opposed to a revision of an
existing standard) affords opportunities to modernise, or even
revolutionise a language. Some could/would argue that there are some
historical legacies, inherited long ago, that are holding the language
back (that could apply to other languages too, not just Forth).
"Radical" changes, especially where it can break existing
functionality or code are resisted. That's okay. It's not an un-
reasonable desire to want to maintain compatibility where possible.
However, where a particular feature or quirk of a language is seen to
be a restriction (with the benefit of hindsight) I say go ahead and
change it! Don't be afraid! If it breaks functionality, well, that's a
shame, but, if the right decisions were made for the right reasons
then programmers will soon come to appreciate the "new way" once they
get comfortable with it. To me, the argument "No! We can't do that, it
will break all my code" is an invalid, and unreasonable argument. The
previous standard is still there. It hasn't gone away. The previous
standard compliant compilers are still there. If they decide to
upgrade software to be compatible with the new standard, great. If
not, no problem they can continue to use the previous standard. It's
not illegal!

Reading the ANS-94 standard, it seems that many concessions were made
to pre-exisiting compilers and/or vendors. One gets the feeling that
the standard was held back by politics. That's probably inevitable. It
probably isn't a very nice job sitting on a standards committee - it's
probably a rather thankless task. I believe the standard could be
improved just by removing references to 'ambiguous conditions' and
mandating that an error be produced. A valid argument in 1980 might
have been that it takes extra code (and cycles) to detect these
ambiguous conditions. It's not such a relevant argument any more
(that's just one example).

Another example: Improvements can also be made to the handling of
execution tokens. Specifically, a new standard could introduce the
concept of different *types* of execution tokens, to be used at
different times, and in different contexts. We've all seen and
participated in the discussions of obtaining XTs to compile only/
interpret only words etc. This is a good example of where current
Forth compiler technology has begun to out-grow the current standard.
A new standard could enshrine this new paradigm, and crucially,
*mandate* it. Don't make it optional. Remove the word "may". That just
gives implementors an easy way out. It is a political concession to
pre-existing systems. This should not be entertained. "May" just leads
to software that "may" work on a "compliant" system, or "may" not.
What's the point of that?

One area of focus (that would require the input of people far more
experienced than I) would be to look at the types of things that
cannot currently be implemented in a standard-compliant manner. To
revert to carnal knowledge in order to implement something in an
otherwise "compliant" system is to expose an area of the standard that
could be strengthened. Where these shortcomings are indentified, the
ratified solutions should be *mandated* in order to remove the
requirement for carnal knowledge, and improve the chances of user code
running correctly across a broad range of systems. One positive
example of this is the word CELL+ that was introduced in ANS94. It was
introduced as a core word too, which is very good.

I don't really have the "Forth stripes" to be saying all of this -
you'll appreciate that these comments are very much "shouted from the
touchlines", to use a footballing expression.

Mark

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

#12136

On May 10, 5:07 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> The point is, a *new* standard (as opposed to a revision of an
> existing standard) affords opportunities to modernise, or even
> revolutionise a language. Some could/would argue that there are some
> historical legacies, inherited long ago, that are holding the language
> back (that could apply to other languages too, not just Forth).
> "Radical" changes, especially where it can break existing
> functionality or code are resisted. That's okay. It's not an un-
> reasonable desire to want to maintain compatibility where possible.
> However, where a particular feature or quirk of a language is seen to
> be a restriction (with the benefit of hindsight) I say go ahead and
> change it! Don't be afraid! If it breaks functionality, well, that's a
> shame, but, if the right decisions were made for the right reasons
> then programmers will soon come to appreciate the "new way" once they
> get comfortable with it. To me, the argument "No! We can't do that, it
> will break all my code" is an invalid, and unreasonable argument. The
> previous standard is still there. It hasn't gone away. The previous
> standard compliant compilers are still there. If they decide to
> upgrade software to be compatible with the new standard, great. If
> not, no problem they can continue to use the previous standard. It's
> not illegal!

When I was arguing my <BUILDS RfD, I introduced what I call the "Asok
Principle." The idea is that if Asok the Intern (from the Dilbert
cartoon) is capable of upgrading an old-standard compliant program to
the new standard, then the changes that the new standard has
introduced are acceptable. In this case, even the dullest Forther
should be able to go through the source-code of any program and change
CREATE into <BUILDS for the cases when there is a DOES>, but leave
CREATE alone when it is used alone. Also, if any mistakes are made,
the compiler will catch the mistake during compilation (a DOES>
following a CREATE is a fatal error, as is a <BUILDS without a DOES>).
This kind of work is what interns are for! Of course, the Forth-200x
committee would have none of it; my RfD was described as a "non-
starter."

> Reading the ANS-94 standard, it seems that many concessions were made
> to pre-exisiting compilers and/or vendors. One gets the feeling that
> the standard was held back by politics. That's probably inevitable. It
> probably isn't a very nice job sitting on a standards committee - it's
> probably a rather thankless task. I believe the standard could be
> improved just by removing references to 'ambiguous conditions' and
> mandating that an error be produced. A valid argument in 1980 might
> have been that it takes extra code (and cycles) to detect these
> ambiguous conditions. It's not such a relevant argument any more
> (that's just one example).
>
> Another example: Improvements can also be made to the handling of
> execution tokens. Specifically, a new standard could introduce the
> concept of different *types* of execution tokens, to be used at
> different times, and in different contexts. We've all seen and
> participated in the discussions of obtaining XTs to compile only/
> interpret only words etc. This is a good example of where current
> Forth compiler technology has begun to out-grow the current standard.
> A new standard could enshrine this new paradigm, and crucially,
> *mandate* it. Don't make it optional. Remove the word "may". That just
> gives implementors an easy way out. It is a political concession to
> pre-existing systems. This should not be entertained. "May" just leads
> to software that "may" work on a "compliant" system, or "may" not.
> What's the point of that?

What indeed?

> One area of focus (that would require the input of people far more
> experienced than I) would be to look at the types of things that
> cannot currently be implemented in a standard-compliant manner. To
> revert to carnal knowledge in order to implement something in an
> otherwise "compliant" system is to expose an area of the standard that
> could be strengthened. Where these shortcomings are indentified, the
> ratified solutions should be *mandated* in order to remove the
> requirement for carnal knowledge, and improve the chances of user code
> running correctly across a broad range of systems. One positive
> example of this is the word CELL+ that was introduced in ANS94. It was
> introduced as a core word too, which is very good.
>
> I don't really have the "Forth stripes" to be saying all of this -
> you'll appreciate that these comments are very much "shouted from the
> touchlines", to use a footballing expression.
>
> Mark

Your TurboForth has more users than Gforth does --- that counts as
"Forth stripes" to me.

You're the only person on comp.lang.forth that ever makes any sense!
Everything that you said here is just common sense, but that is what
the Forth-200x committee fears the most!

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

#11915

In article <3614770.3.1336060788880.JavaMail.geo-discussion-forums@yngr14>,
JennyB  <jennybrien@googlemail.com> wrote:
>I have often seen implementation-dependent code to test if a given xt belon=
>gs to the child of a particular defining work. It seems to me that, given s=
>ufficient carnal knowledge, this should be possible in any Forth. The most =
>usual technique is to define a prototype and then compare the contents of t=
>he xts.
>
>So in any Forth it should be possible to write:
>
>: HUMAN CREATE  ... DOES> ... ;
>
>Human ALICE
>' Bob ' Alice like?  \ true if Bob is HUMAN
>
>Is it?
>Is it possible (and worthwhile) to remove the need for a prototype by redef=
>ining the defining word?

I have such a technique in my assembler where I have an immediate
word REMEMBER that remembers the compilation address at DOES>

: <assembler-consitutent> .. CREATE .. DOES> REMEMBER  .... ;
..
    <data> OPCODE MOV,

and later
  ' MOV, IS-OPCODE

I like
        ' MOV, ' OPCODE child-of
better than my solution (where I have a comparison word for
each defining word.)

A standardised child-of would be better.

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

#11923

On 5/3/12 11:59 AM, JennyB wrote:
> I have often seen implementation-dependent code to test if a given xt belongs to the child of a particular defining work. It seems to me that, given sufficient carnal knowledge, this should be possible in any Forth. The most usual technique is to define a prototype and then compare the contents of the xts.
>
> So in any Forth it should be possible to write:
>
> : HUMAN CREATE  ... DOES>  ... ;
>
> Human ALICE
> ' Bob ' Alice like?  \ true if Bob is HUMAN
>
> Is it?

Yes.

here constant human-type
: human (  "<spaces>name"-- )
    \ name Execution: ( -- addr)
   create human-type , does> ;
: like? ( xt1 xt2 -- flag)
   >body @  swap >body @ = ;

human bob
human alice
' bob ' alice like? . -1 ok

> Is it possible (and worthwhile) to remove the need for a prototype by redefining the defining word?

Do you mean something like the following?

: human? ( xt -- flag)
   >body @ human-type = ;

' bob human? . -1 ok

create xyz
' xyz human? . 0 ok

-Doug

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

#11925

On Fri, 04 May 2012 10:14:35 -0400, Doug Hoffman wrote:

> On 5/3/12 11:59 AM, JennyB wrote:
>> I have often seen implementation-dependent code to test if a given xt
>> belongs to the child of a particular defining work. It seems to me
>> that, given sufficient carnal knowledge, this should be possible in any
>> Forth. The most usual technique is to define a prototype and then
>> compare the contents of the xts.
>>
>> So in any Forth it should be possible to write:
>>
>> : HUMAN CREATE  ... DOES>  ... ;
>>
>> Human ALICE
>> ' Bob ' Alice like?  \ true if Bob is HUMAN
>>
>> Is it?
> 
> Yes.
> 
> here constant human-type
> : human (  "<spaces>name"-- )
>     \ name Execution: ( -- addr)
>    create human-type , does> ;
> : like? ( xt1 xt2 -- flag)
>    >body @  swap >body @ = ;
> 
> human bob
> human alice
> ' bob ' alice like? . -1 ok
> 
>> Is it possible (and worthwhile) to remove the need for a prototype by
>> redefining the defining word?
> 
> Do you mean something like the following?
> 
> : human? ( xt -- flag)
>    >body @ human-type = ;
> 
> ' bob human? . -1 ok
> 
> create xyz
> ' xyz human? . 0 ok
> 
> -Doug

Hi!

A particular solution (not a general one) could be:

8<---
: like? >body @ swap >body @ = ;
: creatype  postpone create here postpone literal postpone , ; immediate
: type> postpone does> postpone cell+ ; immediate                   
--->8

Testing (under gforth):

: human creatype , type> @ ;
1 human bob 2 human alice  ok
bob . alice . 1 2  ok
' bob ' alice like? . -1  ok
: animal creatype , type> @ ;  ok
101 animal donkey  ok
donkey . 101  ok
' bob ' donkey like? . 0  ok

Have a nice day,
humptydumpty

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

#11934

On 5/4/12 4:27 PM, humptydumpty wrote:
> On Fri, 04 May 2012 10:14:35 -0400, Doug Hoffman wrote:
>
>> On 5/3/12 11:59 AM, JennyB wrote:
>>> I have often seen implementation-dependent code to test if a given xt
>>> belongs to the child of a particular defining work. It seems to me
>>> that, given sufficient carnal knowledge, this should be possible in any
>>> Forth. The most usual technique is to define a prototype and then
>>> compare the contents of the xts.
>>>
>>> So in any Forth it should be possible to write:
>>>
>>> : HUMAN CREATE  ... DOES>   ... ;
>>>
>>> Human ALICE
>>> ' Bob ' Alice like?  \ true if Bob is HUMAN
>>>
>>> Is it?
>>
>> Yes.
>>
>> here constant human-type
>> : human (  "<spaces>name"-- )
>>      \ name Execution: ( -- addr)
>>     create human-type , does>  ;
>> : like? ( xt1 xt2 -- flag)
>>     >body @  swap>body @ = ;
>>
>> human bob
>> human alice
>> ' bob ' alice like? . -1 ok
>>
>>> Is it possible (and worthwhile) to remove the need for a prototype by
>>> redefining the defining word?
>>
>> Do you mean something like the following?
>>
>> : human? ( xt -- flag)
>>     >body @ human-type = ;
>>
>> ' bob human? . -1 ok
>>
>> create xyz
>> ' xyz human? . 0 ok
>>
>> -Doug
>
> Hi!
>
> A particular solution (not a general one) could be:
>
> 8<---
> : like?>body @ swap>body @ = ;
> : creatype  postpone create here postpone literal postpone , ; immediate
> : type>  postpone does>  postpone cell+ ; immediate
> --->8
>
> Testing (under gforth):
>
> : human creatype , type>  @ ;
> 1 human bob 2 human alice  ok
> bob . alice . 1 2  ok
> ' bob ' alice like? . -1  ok
> : animal creatype , type>  @ ;  ok
> 101 animal donkey  ok
> donkey . 101  ok
> ' bob ' donkey like? . 0  ok
>
> Have a nice day,
> humptydumpty

That nicely addresses the first issue of the op in an ANS compatible 
way.  But it does not address the second issue of not needing a 
prototype for comparison.

Actually, I notice the following when using SEE in Carbon MacForth, 
suggesting that only implementation-specific information is needed and 
that a prototype for comparison is not needed to determine the defining 
word.  Not sure if all Forths can do this:

: human create does> ;
human bob

see bob

Name                 Token  Type  Flags     ^Code   Size     ^Data
BOB                  9B7FC  Does>  -N-      4067FC    10    101DC0C
   DOES> word,  Created by HUMAN
   vocabulary: FORTH   source file: 'untitled'
004067FC: 95AEFFFC       stwu      r13/TOS, $-4(r14/DSP)
00406800: 39B3DC0C       addi      r13/TOS, r19/DBP, -9204      BOB
00406804: 3DAD0002       addis     r13/TOS, r13/TOS, 2
00406808: 4E800020       blr

-Doug

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

#11937

On Saturday, 5 May 2012 11:16:51 UTC+1, Doug Hoffman  wrote:

> Actually, I notice the following when using SEE in Carbon MacForth, 
> suggesting that only implementation-specific information is needed and 
> that a prototype for comparison is not needed to determine the defining 
> word.  Not sure if all Forths can do this:
> 
> : human create does> ;
> human bob
> 
> see bob
> 
> Name                 Token  Type  Flags     ^Code   Size     ^Data
> BOB                  9B7FC  Does>  -N-      4067FC    10    101DC0C
>    DOES> word,  Created by HUMAN
>    vocabulary: FORTH   source file: 'untitled'
> 004067FC: 95AEFFFC       stwu      r13/TOS, $-4(r14/DSP)
> 00406800: 39B3DC0C       addi      r13/TOS, r19/DBP, -9204      BOB
> 00406804: 3DAD0002       addis     r13/TOS, r13/TOS, 2
> 00406808: 4E800020       blr
> 
I suspect that the decompiler simply searches back from the code address referenced by DOES> to find the closest definition. What does it do with:

  : Foo DOES> ;
  : Human CREATE Foo ;
  Human Bob

?

What started me thinking about this was Gforth's INTERPRET/COMPILE , where ' POSTPONE and friends are then redefined to return the appropriate behaviour for interpret/compile words. In that case (where any imaginable word may be tested) there is no 100% portable solution, because you are limited to comparing data space and you can conceivably come across a definition with the same data.

LIKE? seems fairly simple for any particular Forth, but this is the best I have managed for CHILD?

: ACTOR  \ 'does ++
  CREATE ,   DOES> DUP CELL+ SWAP @ EXECUTE ;

: DEFINER \ 'builds 'does ++
  CREATE 2,  DOES> 2@ CHILD EXECUTE ;

' nop ' nop DEFINER urdefiner
' nop ACTOR uractor

: CHILD?   \ xt1 xt2 -- true if xt1 defined by xt2
  2DUP ['] urdefiner like? 
  SWAP ['] uractor like? AND 
  0= IF FALSE EXIT THEN

  >BODY @ SWAP >BODY @ = ;
 
 

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

#11940

JennyB <jennybrien@googlemail.com> writes:
>What started me thinking about this was Gforth's INTERPRET/COMPILE , where =
>' POSTPONE and friends are then redefined to return the appropriate behavio=
>ur for interpret/compile words. In that case (where any imaginable word may=
> be tested) there is no 100% portable solution, because you are limited to =
>comparing data space and you can conceivably come across a definition with =
>the same data.

Are you thinking of implementing INTERPRET/COMPILE: portably.  One way
to do this would be to record the xts of all words defined with
INTERPRET/COMPILE:.  ' and POSTPONE then check if the word they are
dealing with has one of these xts, and if so, do the appropriate
thing.

Unfortunatley this hinges on the ability to get the xt of every word
(which ' is not guaranteed to do) and get a predictable result (which
FIND is not guaranteed to do), so I don't think one can write a
program that is clearly standard-compliant to does this.

- 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/

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

#11955

On Saturday, 5 May 2012 15:55:58 UTC+1, Anton Ertl  wrote:

> JennyB <jennybrien@googlemail.com> writes:
> >What started me thinking about this was Gforth's INTERPRET/COMPILE , where =
> >' POSTPONE and friends are then redefined to return the appropriate behavio=
> >ur for interpret/compile words. In that case (where any imaginable word may=
> > be tested) there is no 100% portable solution, because you are limited to =
> >comparing data space and you can conceivably come across a definition with =
> >the same data.
> 
> Are you thinking of implementing INTERPRET/COMPILE: portably.  One way
> to do this would be to record the xts of all words defined with
> INTERPRET/COMPILE:.  ' and POSTPONE then check if the word they are
> dealing with has one of these xts, and if so, do the appropriate
> thing.
> 
> Unfortunatley this hinges on the ability to get the xt of every word
> (which ' is not guaranteed to do) and get a predictable result (which
> FIND is not guaranteed to do), so I don't think one can write a
> program that is clearly standard-compliant to does this.
> 

Yes, I think the best we can do is leave LIKE? as implementation-dependent.

I was thinking of a variant of INTERPRET/COMPILE: that returned the compiling action as two cell, the lower of which is the interpretation xt, which the compilation xt may use or drop. That may seem wasteful in the latter case, but it allows me to find or specify the complete interpretation and compilation behaviour of any word, whether it be default, immediate or other.


   : CLONE  ( xt cxt ++ ) 
     CREATE  2, IMMEDIATE 
       DOES> 2@ STATE @ 0= IF DROP THEN EXECUTE ;

   ' DUP  ' COMPILE, clone URCLONE  
   \ a prototype clone of DUP 
    
   : 'COMP  \ ++ xt cxt  ; compiling behaviour of any word
       FIND ?DUP 0= IF 
       COUNT TYPE [CHAR] ? EMIT ABORT THEN 
         -1 = IF 
         ['] COMPILE, ELSE 
       DUP ['] urclone like? IF 
       >BODY 2@ ELSE 
       ['] EXECUTE THEN ; 

  : '   'COMP DROP ; 
  : ['] ' POSTPONE LITERAL ; IMMEDIATE 

  : POSTPONE 'COMP DUP ['] EXECUTE = IF 
                 DROP ELSE 
                 SWAP POSTPONE LITERAL THEN 
               COMPILE, ; IMMEDIATE 

  : & \ ++ create a clone of the following word in the current wordlist
     >IN @ >R 'COMP   
           R> >IN !  CLONE ; 

  : SYNONYM \ ++ newname oldname
              >IN @ >R BL WORD DROP \ skip newname for now 
             'COMP                  \ compiling behaviour of oldname
                 >IN @ R> SWAP >R >IN ! CLONE  \ using newname
             R> >IN !  ;                       \ and skip oldname

 \ Gforth Style Combined Words 

: ct>xtc ( ct -- cxt ) >R :NONAME POSTPONE DROP R> COMPILE, POSTPONE ; ; 

: INTERPRET/COMPILE: ct>cxt CLONE ; 
 

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

#11945

In article <8512970.374.1336227597535.JavaMail.geo-discussion-forums@vbez20>,
JennyB  <jennybrien@googlemail.com> wrote:
>On Saturday, 5 May 2012 11:16:51 UTC+1, Doug Hoffman  wrote:
>
>> Actually, I notice the following when using SEE in Carbon MacForth,=20
>> suggesting that only implementation-specific information is needed and=20
>> that a prototype for comparison is not needed to determine the defining=
>=20
>> word.  Not sure if all Forths can do this:
>>=20
>> : human create does> ;
>> human bob
>>=20
>> see bob
>>=20
>> Name                 Token  Type  Flags     ^Code   Size     ^Data
>> BOB                  9B7FC  Does>  -N-      4067FC    10    101DC0C
>>    DOES> word,  Created by HUMAN
>>    vocabulary: FORTH   source file: 'untitled'
>> 004067FC: 95AEFFFC       stwu      r13/TOS, $-4(r14/DSP)
>> 00406800: 39B3DC0C       addi      r13/TOS, r19/DBP, -9204      BOB
>> 00406804: 3DAD0002       addis     r13/TOS, r13/TOS, 2
>> 00406808: 4E800020       blr
>>=20
>I suspect that the decompiler simply searches back from the code address re=
>ferenced by DOES> to find the closest definition. What does it do with:
>
>  : Foo DOES> ;
>  : Human CREATE Foo ;
>  Human Bob
>
>?
>
>What started me thinking about this was Gforth's INTERPRET/COMPILE , where =
>' POSTPONE and friends are then redefined to return the appropriate behavio=
>ur for interpret/compile words. In that case (where any imaginable word may=
> be tested) there is no 100% portable solution, because you are limited to =
>comparing data space and you can conceivably come across a definition with =
>the same data.
>
>LIKE? seems fairly simple for any particular Forth, but this is the best I =
>have managed for CHILD?
>
>: ACTOR  \ 'does ++
>  CREATE ,   DOES> DUP CELL+ SWAP @ EXECUTE ;
>
>: DEFINER \ 'builds 'does ++
>  CREATE 2,  DOES> 2@ CHILD EXECUTE ;
>
>' nop ' nop DEFINER urdefiner
>' nop ACTOR uractor
>
>: CHILD?   \ xt1 xt2 -- true if xt1 defined by xt2
>  2DUP ['] urdefiner like?=20
>  SWAP ['] uractor like? AND=20
>  0=3D IF FALSE EXIT THEN
>
>  >BODY @ SWAP >BODY @ =3D ;

Adding type information to a structure is a trivial exercise.

The question raised here is whether we can somehow define a
portable way to use the content of the pointer that is filled
in by DOES> . After all words that are CREATEd equal have
a same pointer. Tucking the same information in the first
field is just cumbersome and error prone.

Alternatively we can ask whether the information that ANSI
demands from a standard system to store, would allow a
language extension that finds out similarity based on this
already existing information.


>=20
>=20
>
>
>


--
-- 
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]

#11948

On 5/5/12 10:19 AM, JennyB wrote:
> On Saturday, 5 May 2012 11:16:51 UTC+1, Doug Hoffman  wrote:
>
>> Actually, I notice the following when using SEE in Carbon MacForth,
>> suggesting that only implementation-specific information is needed and
>> that a prototype for comparison is not needed to determine the defining
>> word.  Not sure if all Forths can do this:
>>
>> : human create does>  ;
>> human bob
>>
>> see bob
>>
>> Name                 Token  Type  Flags     ^Code   Size     ^Data
>> BOB                  9B7FC  Does>   -N-      4067FC    10    101DC0C
>>     DOES>  word,  Created by HUMAN
>>     vocabulary: FORTH   source file: 'untitled'
>> 004067FC: 95AEFFFC       stwu      r13/TOS, $-4(r14/DSP)
>> 00406800: 39B3DC0C       addi      r13/TOS, r19/DBP, -9204      BOB
>> 00406804: 3DAD0002       addis     r13/TOS, r13/TOS, 2
>> 00406808: 4E800020       blr
>>
> I suspect that the decompiler simply searches back from the code address referenced by DOES>  to find the closest definition. What does it do with:
>
>    : Foo DOES>  ;
>    : Human CREATE Foo ;
>    Human Bob
>
> ?

Carbon MacForth:

: Foo DOES> ;
: Human CREATE Foo ;
Human Bob

see Bob

Name                 Token  Type  Flags     ^Code   Size     ^Data
BOB                  9B83C  Does>  -N-      40683C    10    101DC0C
   DOES> word,  Created by FOO
   vocabulary: FORTH   source file: 'untitled'
0040683C: 95AEFFFC       stwu      r13/TOS, $-4(r14/DSP)
00406840: 39B3DC0C       addi      r13/TOS, r19/DBP, -9204      BOB
00406844: 3DAD0002       addis     r13/TOS, r13/TOS, 2
00406848: 4E800020       blr

-Doug


> What started me thinking about this was Gforth's INTERPRET/COMPILE , where ' POSTPONE and friends are then redefined to return the appropriate behaviour for interpret/compile words. In that case (where any imaginable word may be tested) there is no 100% portable solution, because you are limited to comparing data space and you can conceivably come across a definition with the same data.
>
> LIKE? seems fairly simple for any particular Forth, but this is the best I have managed for CHILD?
>
> : ACTOR  \ 'does ++
>    CREATE ,   DOES>  DUP CELL+ SWAP @ EXECUTE ;
>
> : DEFINER \ 'builds 'does ++
>    CREATE 2,  DOES>  2@ CHILD EXECUTE ;
>
> ' nop ' nop DEFINER urdefiner
> ' nop ACTOR uractor
>
> : CHILD?   \ xt1 xt2 -- true if xt1 defined by xt2
>    2DUP ['] urdefiner like?
>    SWAP ['] uractor like? AND
>    0= IF FALSE EXIT THEN
>
>    >BODY @ SWAP>BODY @ = ;
>
>
>
>
>

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

#11978

On May 5, 6:16 am, Doug Hoffman <glide...@gmail.com> wrote:
> On 5/4/12 4:27 PM, humptydumpty wrote:
>
>
>
>
>
>
>
>
>
> > On Fri, 04 May 2012 10:14:35 -0400, Doug Hoffman wrote:
>
> >> On 5/3/12 11:59 AM, JennyB wrote:
> >>> I have often seen implementation-dependent code to test if a given xt
> >>> belongs to the child of a particular defining work. It seems to me
> >>> that, given sufficient carnal knowledge, this should be possible in any
> >>> Forth. The most usual technique is to define a prototype and then
> >>> compare the contents of the xts.
>
> >>> So in any Forth it should be possible to write:
>
> >>> : HUMAN CREATE  ... DOES>   ... ;
>
> >>> Human ALICE
> >>> ' Bob ' Alice like?  \ true if Bob is HUMAN
>
> >>> Is it?
>
> >> Yes.
>
> >> here constant human-type
> >> : human (  "<spaces>name"-- )
> >>      \ name Execution: ( -- addr)
> >>     create human-type , does>  ;
> >> : like? ( xt1 xt2 -- flag)
> >>     >body @  swap>body @ = ;
>
> >> human bob
> >> human alice
> >> ' bob ' alice like? . -1 ok
>
> >>> Is it possible (and worthwhile) to remove the need for a prototype by
> >>> redefining the defining word?
>
> >> Do you mean something like the following?
>
> >> : human? ( xt -- flag)
> >>     >body @ human-type = ;
>
> >> ' bob human? . -1 ok
>
> >> create xyz
> >> ' xyz human? . 0 ok
>
> >> -Doug
>
> > Hi!
>
> > A particular solution (not a general one) could be:
>
> > 8<---
> > : like?>body @ swap>body @ = ;
> > : creatype  postpone create here postpone literal postpone , ; immediate
> > : type>  postpone does>  postpone cell+ ; immediate
> > --->8
>
> > Testing (under gforth):
>
> > : human creatype , type>  @ ;
> > 1 human bob 2 human alice  ok
> > bob . alice . 1 2  ok
> > ' bob ' alice like? . -1  ok
> > : animal creatype , type>  @ ;  ok
> > 101 animal donkey  ok
> > donkey . 101  ok
> > ' bob ' donkey like? . 0  ok
>
> > Have a nice day,
> > humptydumpty
>
> That nicely addresses the first issue of the op in an ANS compatible
> way.  But it does not address the second issue of not needing a
> prototype for comparison.
>
> Actually, I notice the following when using SEE in Carbon MacForth,
> suggesting that only implementation-specific information is needed and
> that a prototype for comparison is not needed to determine the defining
> word.  Not sure if all Forths can do this:
>
> : human create does> ;
> human bob
>
> see bob
>
> Name                 Token  Type  Flags     ^Code   Size     ^Data
> BOB                  9B7FC  Does>  -N-      4067FC    10    101DC0C
>    DOES> word,  Created by HUMAN
>    vocabulary: FORTH   source file: 'untitled'
> 004067FC: 95AEFFFC       stwu      r13/TOS, $-4(r14/DSP)
> 00406800: 39B3DC0C       addi      r13/TOS, r19/DBP, -9204      BOB
> 00406804: 3DAD0002       addis     r13/TOS, r13/TOS, 2
> 00406808: 4E800020       blr
>
> -Doug

but we "cheat" - we keep a separate "info" field on each word in a
different memory space from the code, that can be deleted when rolling
a stand-alone turnkey without compiler.

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

#11979

On 5/8/12 7:39 AM, ward@megawolf.com wrote:
> On May 5, 6:16 am, Doug Hoffman<glide...@gmail.com>  wrote:

>> Actually, I notice the following when using SEE in Carbon MacForth,
>> suggesting that only implementation-specific information is needed and
>> that a prototype for comparison is not needed to determine the defining
>> word.  Not sure if all Forths can do this:
>>
>> : human create does>  ;
>> human bob
>>
>> see bob
>>
>> Name                 Token  Type  Flags     ^Code   Size     ^Data
>> BOB                  9B7FC  Does>    -N-      4067FC    10    101DC0C
>>     DOES>  word,  Created by HUMAN
>>     vocabulary: FORTH   source file: 'untitled'
>> 004067FC: 95AEFFFC       stwu      r13/TOS, $-4(r14/DSP)
>> 00406800: 39B3DC0C       addi      r13/TOS, r19/DBP, -9204      BOB
>> 00406804: 3DAD0002       addis     r13/TOS, r13/TOS, 2
>> 00406808: 4E800020       blr

> but we "cheat" - we keep a separate "info" field on each word in a
> different memory space from the code, that can be deleted when rolling
> a stand-alone turnkey without compiler.

Sometimes cheating can be a good thing.

-Doug

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

#11936

JennyB wrote:

> I have often seen implementation-dependent code to test if a given xt
> belongs to the child of a particular defining work. It seems to me that,
> given sufficient carnal knowledge, this should be possible in any Forth.
> The most usual technique is to define a prototype and then compare the
> contents of the xts.
> 
> So in any Forth it should be possible to write:
> 
> : HUMAN CREATE  ... DOES> ... ;
> 
> Human ALICE
> ' Bob ' Alice like?  \ true if Bob is HUMAN
> 
> Is it?
> Is it possible (and worthwhile) to remove the need for a prototype by
> redefining the defining word?
What baffles me is why do you want to know that. If I embed a datastructure
into a DOES> definition I'm quite sure I never want to know anything about
it again. I want to to calculate the correct offset, search itself when
presented or punch up some value in a certain format.

By embedding it in a DOES> definition I reject all carnal knowledge of the
data itself. Coming back to that decision seems like bad programming to me.
It reminds me of the typeof() operator in some OO languages where a
programmer obviously "forgot" what type it is and what properties it has
and has to go back to the nitty gritty details and CASE..OF operators he
wanted to eradicate in the first place. I can do CASE..OF in imperative
languages, don't need OO for that..

I may understand that it may have SOME value on the prompt, but again: WHY?
And what the heck is a "prototype" in Forth lingo?

Hans Bezemer

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

#11946

In article <4fa51bc1$0$6940$e4fe514c@news2.news.xs4all.nl>,
Hans Bezemer  <the.beez.speaks@gmail.com> wrote:
>JennyB wrote:
>
>> I have often seen implementation-dependent code to test if a given xt
>> belongs to the child of a particular defining work. It seems to me that,
>> given sufficient carnal knowledge, this should be possible in any Forth.
>> The most usual technique is to define a prototype and then compare the
>> contents of the xts.
>>
>> So in any Forth it should be possible to write:
>>
>> : HUMAN CREATE  ... DOES> ... ;
>>
>> Human ALICE
>> ' Bob ' Alice like?  \ true if Bob is HUMAN
>>
>> Is it?
>> Is it possible (and worthwhile) to remove the need for a prototype by
>> redefining the defining word?
>What baffles me is why do you want to know that. If I embed a datastructure
>into a DOES> definition I'm quite sure I never want to know anything about
>it again. I want to to calculate the correct offset, search itself when
>presented or punch up some value in a certain format.
>
>By embedding it in a DOES> definition I reject all carnal knowledge of the
>data itself. Coming back to that decision seems like bad programming to me.
>It reminds me of the typeof() operator in some OO languages where a
>programmer obviously "forgot" what type it is and what properties it has
>and has to go back to the nitty gritty details and CASE..OF operators he
>wanted to eradicate in the first place. I can do CASE..OF in imperative
>languages, don't need OO for that..
>
>I may understand that it may have SOME value on the prompt, but again: WHY?
>And what the heck is a "prototype" in Forth lingo?

Look at the example I gave earlier. I have a wordlist that contains
assembler words. The actual opcodes and fixups are to be inspected
during disassembly whether they fit, auxiliary words are not.
opcodes and fixups are to be used differently.

>
>Hans Bezemer

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 2 of 2 — ← Prev page 1 [2]

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

csiph-web