Distinguishing DOES>

[JennyB]

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?

[Hugh Aguilar]

When I was programming for Testra, I still used CREATE DOES> --- I
would just always comma a signature cell in after the CREATE. The
signatures came from a global variable that would get incremented with
every use of CREATE so each defining word had a unique signature. In
my MFX compiler, I had <BUILDS that was distinct from CREATE (CREATE
was just HERE CONSTANT) so I could do stuff like this in <BUILDS
because I knew that this was a defining word. I am very opposed to the
ANS-Forth overloading of CREATE to be used both in defining words (in
conjunction with DOES>) as for defining simple variables (that don't
get a DOES>). I tried to talk the Forth-200x committee into
reintroducing <BUILDS but that worked as well as talking sense into
the Forth-200x committee usually does. In my Straight Forth I will
certainly have <BUILDS for defining words and CREATE for HERE
CONSTANT.

With signatures, you don't need a prototype --- just store the current
signature value into a constant after defining the defining word, and
that constant can then be compared to the signature-cell in the object
to determine if the object is of that type. Of course, you can also
compare the signature-cells of two object as you did in your example
above.

Signatures could be used with structs like I have in the novice
package, although I usually just assume that they are all different
sizes and the size identifies the type (this works when all of the
data types in the program are in a single parent-child chain, which is
pretty common). All of this is pretty crude because it doesn't take
into account inheritance --- the IS-A function in most OOP languages
would return true if the object is a child of the target type. I could
upgrade the novice package to use signatures and to allow for an IS-A
function that took inheritance into account --- maybe I will in the
next release.

I don't use CREATE DOES> (or <BUILDS DOES>) very much anymore --- I
generally use :NAME now.

[Zbiggy]

In comp.lang.forth, Hugh Aguilar wrote:

> [..] I had <BUILDS that was distinct from CREATE (CREATE

> was just HERE CONSTANT) so I could do stuff like this in <BUILDS
> because I knew that this was a defining word. I am very opposed to the
> ANS-Forth overloading of CREATE to be used both in defining words (in
> conjunction with DOES>) as for defining simple variables (that don't
> get a DOES>).

Why? What's so special about <BUILDS ?

In an old handbook I've found, that <BUILDS can be defined just as:

: <BUILDS 0 CONSTANT ;

What were/are its supposed advantages(?) over CREATE ? Does it make any
significant difference, whether somewhere will be 0 or HERE inserted, when
it shall be replaced during DOES> phase anyway?
--
Forth is a preserver of health (Hippocrates)

[Andrew Haley]

Assuming a fairly conventional threaded implementation, <BUILDS wastes
a cell, CREATE doesn't. CREATE replaced <BUILDS in DOES> words for
that reason: it's a superior implementation technique.

Andrew.

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>Assuming a fairly conventional threaded implementation, <BUILDS wastes
>a cell, CREATE doesn't.

You are comparing two different implementation techniques for DOES>
(or, in colloquial English, you are comparing apples and oranges).
For context, consider this example:

: constant <builds , does> ( handler ) @ ;
5 constant foo

The two implementation techniques are:

1) The header of FOO looks as follows:

Name field, link field
dodoes (code field)
handler (points where HANDLER is in the code above)
5 (data)

Here we have DODOES to know how to treat the word on the machine code
level and HANDLER to find the high-level code.

2) The header of FOO looks as follows:

Name field, link field
handler-5 (or so)
5

and at HANDLER-5 we have

jsr dodoes (or somesuch)

Here the JSR pushes HANDLER on the return stack and DODOES finds it
there.


Using the first technique with CREATE would mean that every CREATEd
word would need cell containing the handler, just in case a DOES>
comes along. Therefore, people introduced BUILDS> so that they would
not have this overhead for other CREATEd words. So, if you use that
technique, letting DOES> work with CREATE (instead of just with
<BUILDS) costs an extra cell for every DOES>-less created word.

With the second technique <BUILDS is just the same as CREATE, so
<BUILDS was left away in systems employing this technique.

>CREATE replaced <BUILDS in DOES> words for
>that reason: it's a superior implementation technique.

You mean that the second technique above is superior. For some
settings that is the case, for others it isn't (e.g., Gforth uses
technique 1, and there are good reasons for that; and every code field
has an extra cell). In any case, the second implementation technique
is completely compatible with <BUILDS, just define

: <BUILDS CREATE ;

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

In article <3614770.3.1336060788880.JavaMail.geo-discussion-forums@yngr14>,
JennyB <jenny...@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

[Andrew Haley]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:

>> Assuming a fairly conventional threaded implementation, <BUILDS
>> wastes a cell, CREATE doesn't.
>
> You are comparing two different implementation techniques for DOES>
> (or, in colloquial English, you are comparing apples and oranges).

Not at all: the older techniqure required <BUILDS, the newer didn't.

Indeed it does.

> With the second technique <BUILDS is just the same as CREATE, so
> <BUILDS was left away in systems employing this technique.

That's exactly right: there no longer was any need for CREATE and
<BUILDS to be different, so BUILDS> was dropped. There certainly was
no need to keep BUILDS> as an alias for CREATE because BUILDS> only
existed because the older implementation technique forced it to be
different from CREATE.

Andrew.

[Doug Hoffman]

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

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>
>>> Assuming a fairly conventional threaded implementation, <BUILDS
>>> wastes a cell, CREATE doesn't.
>>
>> You are comparing two different implementation techniques for DOES>
>> (or, in colloquial English, you are comparing apples and oranges).
>
>Not at all: the older techniqure required <BUILDS

It doesn't, as is demonstrated by Gforth, which uses the older
technique without <BUILDS.

> the newer didn't.

But it doesn't prohibit <BUILDS, either. So, either technique can be
used with or without <BUILDS, and your statement about <BUILDS wasting
a cell is just wrong.

>> With the second technique <BUILDS is just the same as CREATE, so
>> <BUILDS was left away in systems employing this technique.
>
>That's exactly right: there no longer was any need for CREATE and
><BUILDS to be different, so BUILDS> was dropped. There certainly was
>no need to keep BUILDS> as an alias for CREATE because BUILDS> only
>existed because the older implementation technique forced it to be
>different from CREATE.

It didn't. And removing <BUILDS removed the implementation option of
using that technique without using the extra cell for all CREATEd
words, so if allowing different implementation options is good, that
removal was bad. But of course CREATE...DOES> was standardized in
Forth-79, while implementation options was a principle for Forth-94.

[humptydumpty]

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

[Andrew Haley]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>
>>>> Assuming a fairly conventional threaded implementation, <BUILDS
>>>> wastes a cell, CREATE doesn't.
>>>
>>> You are comparing two different implementation techniques for DOES>
>>> (or, in colloquial English, you are comparing apples and oranges).
>>
>>Not at all: the older techniqure required <BUILDS
>
> It doesn't, as is demonstrated by Gforth, which uses the older
> technique without <BUILDS.

That only changes the name of the word, not what it does. <BUILDS
DOES> is the older technique, CREATE DOES> the newer one; this is a
matter of historical fact. Of course you can redefine a word to do
anything. Of course you can rename CREATE to perform the function
historically performed by <BUILDS, in which case CREATE wastes a cell
too.

>> the newer didn't.
>
> But it doesn't prohibit <BUILDS, either. So, either technique can be
> used with or without <BUILDS, and your statement about <BUILDS wasting
> a cell is just wrong.

Historically, <BUILDS was used with the extra cell. It would have
been possible to use the name CREATE to indicate the function of
<BUILDS, but only at the cost of wasting a cell for every child of
CREATE . Back then, no reasonable person would have wanted to do such
a thing; today, people don't worry so much.

>>> With the second technique <BUILDS is just the same as CREATE, so
>>> <BUILDS was left away in systems employing this technique.
>>
>>That's exactly right: there no longer was any need for CREATE and
>><BUILDS to be different, so BUILDS> was dropped. There certainly was
>>no need to keep BUILDS> as an alias for CREATE because BUILDS> only
>>existed because the older implementation technique forced it to be
>>different from CREATE.
>
> It didn't.

I'm surprised that you can argue with this, since it's a matter of
fact: it is the only reason that <BUILDS existed.

> And removing <BUILDS removed the implementation option of using that
> technique without using the extra cell for all CREATEd words, so if
> allowing different implementation options is good,

I don't think that anyone maintains that allowing different
implementation options is always good. For example, see the
discussion about the floating-point stack, where one such option was
deleted in order to improve the language.

> that removal was bad.

Andrew.

[Doug Hoffman]

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

[Hans Bezemer]

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

[JennyB]

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 @ = ;

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> It doesn't, as is demonstrated by Gforth, which uses the older
>> technique without <BUILDS.
>
>That only changes the name of the word, not what it does.

CREATE in Gforth does what the standard says CREATE should do.

><BUILDS
>DOES> is the older technique, CREATE DOES> the newer one; this is a
>matter of historical fact. Of course you can redefine a word to do
>anything.

Yes, and you have redefined CREATE and <BUILDS to be implementation
techniques, not word names. Humpty Dumpty would be proud of you:-).

>I don't think that anyone maintains that allowing different
>implementation options is always good.

Often the "this allows different implementation options" argument
is used as if it justified everything.

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>>That's exactly right: there no longer was any need for CREATE and
>>><BUILDS to be different, so BUILDS> was dropped. There certainly was
>>>no need to keep BUILDS> as an alias for CREATE because BUILDS> only
>>>existed because the older implementation technique forced it to be
>>>different from CREATE.
>>
>> It didn't.
>
>I'm surprised that you can argue with this, since it's a matter of
>fact: it is the only reason that <BUILDS existed.

It is probably the reason that <BUILDS existed, but the technique does
not force CREATE to be different from <BUILDS (Gforth demonstrates
that). There is a difference between allowing something and forcing
something. <BUILDS existed, because it allowed CREATE to be different
and consume less space.

[Anton Ertl]

JennyB <jenny...@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.

[BruceMcF]

On May 5, 10:25 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

> <BUILDS existed, because it allowed CREATE to be different
> and consume less space.

And in that *system* "CREATE ... DOES>" did not work, because "DOES>"
assumed a preceding "<BUILD".

Having a single defining word that works as CREATE and also works as
<BUILDS is a different system than having one defining word that works
as CREATE and a different word that is paired with DOES> ... call that
different word paired with DOES> what you will, <CREATE if you wish.

"CREATE ... DOES>" code from a system in which there is one such
defining word and DOES> works on the most recently created word does
not work on a system in which DOES> is paired with <BUILDS and CREATE
is not.

As was nearly hashed out recently, in some instances the
implementation technique that allowed the more compact CREATE to also
be paired with DOES> rendering the original implementation of <BUILDS
incompatible with DOES> is not always feasible, in which case to it is
necessary to use the original <BUILDS implementation technique. But it
remains the single defining word system, not the system with two
distinct defining words.

[Andrew Haley]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>> It doesn't, as is demonstrated by Gforth, which uses the older
>>> technique without <BUILDS.
>>
>>That only changes the name of the word, not what it does.
>
> CREATE in Gforth does what the standard says CREATE should do.
>
>><BUILDS DOES> is the older technique, CREATE DOES> the newer one;
>>this is a matter of historical fact. Of course you can redefine a
>>word to do anything.
>
> Yes, and you have redefined CREATE and <BUILDS to be implementation
> techniques, not word names. Humpty Dumpty would be proud of you:-).

I haven't redefined them, though: I have been using them correctly in
their historical context. We have never had names for the two
techniques, so the names that the words had at the time have to
suffice.

>> I don't think that anyone maintains that allowing different
>> implementation options is always good.
>
> Often the "this allows different implementation options" argument is
> used as if it justified everything.

It's a pretty powerful argument, but it doesn't trump everything.

Andrew.

[Albert van der Horst]

In article <8512970.374.1336227597535.JavaMail.geo-discussion-forums@vbez20>,

JennyB <jenny...@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]

In article <4fa51bc1$0$6940$e4fe...@news2.news.xs4all.nl>,

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

[Doug Hoffman]

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

[JennyB]

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

> JennyB <jenny...@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 ;

[wa...@megawolf.com]

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.

[Doug Hoffman]

> 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

[Hugh Aguilar]

You must have read my RfD, or at least, were the only one to
understand it.

My point is that in ANS-Forth, CREATE is overloaded --- CREATE by
itself and CREATE with a DOES> are two entirely different concepts.
The Forth-way is that each word should do only one thing. It makes
sense to have CREATE and <BUILDS as distinct words, because they are
distinct concepts --- it is a philosophical issue.

If <BUILDS is used, and it does not get fixed-up with a DOES> prior to
the next definition, then that is an error. If CREATE is used, and it
does get a DOES> after it, then that is also an error. In either case,
compilation aborts with an error message.

If you assume that headers are not mixed in with data (and this is
assumed in Straight Forth), then CREATE can be defined like this:
: CREATE HERE CONSTANT ;
In most implementations, the value of the constant does not take up
memory on the target platform. There is no place that you can find it
in target memory. Constants just compile as literals wherever they are
referenced.

Defining <BUILDS is more complicated. I won't go into that here. I
will say however, that this is somewhat simplified by the fact that
you know ahead of time that there is going to be a DOES> --- you don't
have to allow for both possibilities, that there is a DOES>
(references will be a CALL to the DOES> code) or that there is no
DOES> (references will be a compilation of a literal).

Implementation is always simplified when each word does only one
thing. Remember the "universal processor" (word, data, food) in the
"Thinking Forth" book? We want to avoid that. Right now, CREATE is
used for both both simple variables that just return an address and
complex variables that execute the attached DOES> code. The situation
could be worse though! Imagine if CREATE were used instead of colon to
define functions, and the semi-colon had to fix-up the CREATE for this
case (similar to the way that DOES> fixes-up CREATE for its case).
That would be similar to what we already have with CREATE defining two
kinds of words, but worse, as CREATE would define three kinds of
words. That would be taking the current line of thinking to its
extreme!

[Bernd Paysan]

Hugh Aguilar wrote:
> Implementation is always simplified when each word does only one
> thing. Remember the "universal processor" (word, data, food) in the
> "Thinking Forth" book? We want to avoid that.

To be honest, sometimes I even have to agree with you. I want my words
uniform - see the header discussion - so it is not complicated to change
a CREATE to a <BUILDS word (replace the COMPILE,-action, fill in the
DODOES field), but the concept indeed feels like the word/data/food
processor.

The rationale to throw out <BUILDS was that an implementation technique
existed where CREATE and <BUILDS do the same thing. This would be the
rationale to throw out COMPILE, - because there is an implementation
technique where , does the same thing. The reason why Forth-83 felt
inclined to do so is that Forth-83 actually mandated an implementation
technique. That was its biggest mistake.

Forth-83 made a number of incompatible decisions, and though some
decisions by themselves are good ideas (like -1 as TRUE or to have a
one's complement called NOT), but they broke code. Maybe the idea was
that Forth programs are not maintainable (or intented to be maintained),
anyways, and will be quickly rewritten to the then-current standard.
Chuck Moore is even more radical with breaking code, when designing his
next system.

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

[Hugh Aguilar]

On May 8, 4:25 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> The rationale to throw out <BUILDS was that an implementation technique
> existed where CREATE and <BUILDS do the same thing.  This would be the
> rationale to throw out COMPILE, - because there is an implementation
> technique where , does the same thing.  The reason why Forth-83 felt
> inclined to do so is that Forth-83 actually mandated an implementation
> technique.  That was its biggest mistake.

To a large extent, the purpose of a standard is to abstractify
implementation.

On the other hand, being wishy-washy isn't the same thing as
abstractification. For example, I've pointed out that the ANS-Forth
standard says that locals may or may not be held on the return stack.
This doesn't help! In a case like this, it really is necessary to
specify where the locals are, and to put them somewhere that makes
sense (not on the return stack!). When the standard is wishy-washy
like this, then the user has to assume the worst-case scenario (that
they are on the return stack) so that his code will work on any
standard-compliant system --- this is really no better than if the
standard specified the worst-case scenario --- he can't really use >R
R> R@ etc. in conjunction with locals, because this may not work on
some compliant compilers.

Abstractification is a good thing. For example, COMPILE, was a huge
step up from using comma, as this abstractified compilation and
allowed any kind of threading scheme to be used (including the
generation of machine code, which is what everybody wants to do with
the modern processors). Being wishy-washy is a bad thing. For example,
the standard should say that locals are on their own stack, as this
allows >R R> R@ etc. to be used in a function whether locals are being
used in that function or not.

Note that in Straight Forth I'm not going to support >R R> R@ etc. at
all (because they are ugly and error-prone), so it makes no difference
to me where the locals are.

Straight Forth will specify that the locals get destroyed when the
function exits. This means that they can be on the return stack (as
opposed to the heap), although they might have their own stack
(because some processors don't provided indexed addressing of the
return stack). This is abstractification --- so long as the locals
behave in the expected way, then they can be implemented in any way
that is convenient for the compiler-writer.

> Forth-83 made a number of incompatible decisions, and though some
> decisions by themselves are good ideas (like -1 as TRUE or to have a
> one's complement called NOT), but they broke code.  Maybe the idea was
> that Forth programs are not maintainable (or intented to be maintained),
> anyways, and will be quickly rewritten to the then-current standard.
> Chuck Moore is even more radical with breaking code, when designing his
> next system.

The point of Straight Forth is that it makes sense. Breaking legacy
code is not a problem for me.

Some companies seem to have a high turnover in programmers (usually
because the boss is a non-programmer). These companies are the ones
that primarily care about not breaking legacy code. They often have a
lot of code that was written by a programmer who has since been fired.
They have no idea how that code works, but they want it to continue
working (because they don't have confidence that any of their current
programmers are capable of rewriting the program from scratch) --- so
they become highly focused on the idea that no new compiler should
ever break legacy code. Companies like this deserve to go out of
business --- I don't care about them --- the name "Straight" means,
among other things, that whiners are not tolerated.

[Mark Wills]

On May 8, 11:25 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Forth-83 made a number of incompatible decisions, and though some
> decisions by themselves are good ideas (like -1 as TRUE or to have a
> one's complement called NOT), but they broke code.

I don't really agree with this. Forth-83 is Forth-83, and Forth-79 is
Forth-79. Did all the Forth-79 code (and compilers) evaporate into
thin air when the Forth-83 standard was released? Of course not. Did
all the Forth-79 code suddenly cease to function? Of course not.

I just don't see the problem! With each new standard is the
opportunity to take the language in new directions, add new features,
and correct short-comings identified in the previous standard.
However, it doesn't have to be an incremental change. It's a new
standard!

We had ANS-94 and we're working towards 200x. Should we not simply
rename 200x as "ANS-94 Rev 1, 2012" - because *that's* what it really
is.

I think it would have been much more exciting, and more beneficial if
the 200x standard was a 'rip it up and start again' rather than an
update to the previous standard. A new standard doesn't invalidate a
previous standard. ANS-94 will still be there if people don't want to
move to the new standard. They run in parallel.

But, what I do know?! Enough ranting!

[Andrew Haley]

Mark Wills <markrob...@yahoo.co.uk> wrote:

> We had ANS-94 and we're working towards 200x. Should we not simply
> rename 200x as "ANS-94 Rev 1, 2012" - because *that's* what it
> really is.
>
> I think it would have been much more exciting, and more beneficial
> if the 200x standard was a 'rip it up and start again' rather than
> an update to the previous standard.

It would certainly have been much more exciting.

There's a problem with this: languages designed by committees aren't
usually very good. So, it makes more sense for someone with a vision
to design their new language, campaign for its adoption, and get that
standardized when it's stable enough.

Andrew.

[Elizabeth D. Rather]

With most standards bodies (ANSI, ISO, IEEE, etc.) the convention is
that new standards *do* invalidate old ones, after a transition period.
And the new standard seeks to minimize that transition period and
minimize the cost of transitioning, by doing such things as respecting
existing practice wherever practical. In the case of programming
languages, including Forth, there are users maintaining programs with
thousands of lines of code and thousands of systems in the field. They
can (and will) be updated to some extent, but radical changes are out of
the question.

It might be fun to 'rip it up and start again,' but the result should
get a new name.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Zbiggy]

In comp.lang.forth, Bernd Paysan wrote:

> [..] but they broke code. Maybe the idea was

> that Forth programs are not maintainable (or intented to be maintained),
> anyways, and will be quickly rewritten to the then-current standard.
> Chuck Moore is even more radical with breaking code, when designing his
> next system.

There's nothing wrong with dropping "backward compatibility", if this is
reasonable. For example: keeping the x86-line of processors still backward
compatible made their instructions list more than 1000 positions long:

http://www.agner.org/optimize/blog/read.php?i=25

It costs programming time. It costs efficiency. It costs energy.
Let's compare this to about 100 (or maybe less?) instructions of ARM...

Yes, Microsoft grew up exactly by assuring backward compatibility of their
software, but it was different situation "back in the day": when the computers
were expensive, of course everyone preferred to keep both the old and new
versions of software running on the same machine. Today the gear is so
cheap - and powerful at the same time - that it isn't a problem to keep old
machine for old programs (in fact, there could be a problem to sell such old
machine... nobody wants it), or - if anyone will see it as inconvenience - to
use software emulator, until new version of some software will be released.

My guess is, that it wasn't "Forth programs are not maintainable" approach -
but rather an expectation, that for that older programs the older version of
interpreters can be still used, and even the newer versions of such programs
can be still developed according to older standard (why not?), if someone is
afraid of messing the well-tested code. But quite new - "fresh" - programs
can use new standard.
--
Forth is a preserver of health (Hippocrates)

[Bernd Paysan]

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.

[Zbiggy]

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.

[Bernd Paysan]

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.

[Zbiggy]

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.

[Albert van der Horst]

In article <joen7a$a3m$1...@online.de>, Bernd Paysan <bernd....@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...)

[Mark Wills]

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

[Bernd Paysan]

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).

[Hugh Aguilar]

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!