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

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

Array of Constants in Mecrisp

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

Contents

  Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-10 11:06 -0400
    Array of Constants in Mecrisp Mark Wills <markwills1970@gmail.com> - 2015-05-10 09:02 -0700
      Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-10 15:50 -0400
        Re: Array of Constants in Mecrisp Mark Wills <markwills1970@gmail.com> - 2015-05-11 00:38 -0700
        Re: Array of Constants in Mecrisp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-05-11 12:10 +0200
          Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-11 11:24 -0400
            Re: Array of Constants in Mecrisp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-05-12 13:03 +0200
          Re: Array of Constants in Mecrisp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-11 23:19 +0000
            Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-11 20:47 -0400
              Re: Array of Constants in Mecrisp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-12 17:05 +0000
            Re: Array of Constants in Mecrisp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-05-12 12:49 +0200
          Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-14 13:00 -0400
            Re: Array of Constants in Mecrisp "Alex McDonald" <blog@rivadpm.com> - 2015-05-14 18:04 +0100
              Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-14 13:20 -0400
                Re: Array of Constants in Mecrisp "Alex McDonald" <blog@rivadpm.com> - 2015-05-14 18:46 +0100
                Re: Array of Constants in Mecrisp Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-14 20:42 +0200
                  Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-15 11:25 -0400
                Re: Array of Constants in Mecrisp "Elizabeth D. Rather" <erather@forth.com> - 2015-05-14 09:11 -1000
                Re: Array of Constants in Mecrisp anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 07:26 +0000
                  Re: Array of Constants in Mecrisp "Elizabeth D. Rather" <erather@forth.com> - 2015-05-14 22:30 -1000
                    Re: Array of Constants in Mecrisp anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 10:03 +0000
                      Re: Array of Constants in Mecrisp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 11:05 +0000
                        Re: Array of Constants in Mecrisp anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-15 12:51 +0000
                          Re: Array of Constants in Mecrisp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 15:40 +0000
                            Re: Array of Constants in Mecrisp anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-16 13:40 +0000
                              Re: Array of Constants in Mecrisp "Elizabeth D. Rather" <erather@forth.com> - 2015-05-16 11:25 -1000
                      Re: Array of Constants in Mecrisp "Elizabeth D. Rather" <erather@forth.com> - 2015-05-15 09:28 -1000
                Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-15 11:31 -0400
                  Re: Array of Constants in Mecrisp "Elizabeth D. Rather" <erather@forth.com> - 2015-05-15 09:31 -1000
                    Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-16 10:00 -0400
                      Re: Array of Constants in Mecrisp anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-16 16:12 +0000
                        Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-16 13:58 -0400
                          Re: Array of Constants in Mecrisp anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-16 18:03 +0000
                            Re: Array of Constants in Mecrisp Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-18 00:36 +0200
                              Re: Array of Constants in Mecrisp Lars Brinkhoff <lars.spam@nocrew.org> - 2015-05-18 08:37 +0200
                                Re: Array of Constants in Mecrisp Coos Haak <chforth@hccnet.nl> - 2015-05-18 12:55 +0200
                                  Re: Array of Constants in Mecrisp Lars Brinkhoff <lars.spam@nocrew.org> - 2015-05-18 13:44 +0200
                                    Re: Array of Constants in Mecrisp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-19 00:17 +0000
                        Re: Array of Constants in Mecrisp "Elizabeth D. Rather" <erather@forth.com> - 2015-05-16 11:36 -1000
                      Re: Array of Constants in Mecrisp "Elizabeth D. Rather" <erather@forth.com> - 2015-05-16 11:27 -1000
              Re: Array of Constants in Mecrisp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-15 10:48 +0000
    Re: Array of Constants in Mecrisp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-05-11 12:06 +0200
      Re: Array of Constants in Mecrisp Mark Wills <markwills1970@gmail.com> - 2015-05-11 04:48 -0700
        Re: Array of Constants in Mecrisp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2015-05-12 12:39 +0200
          Re: Array of Constants in Mecrisp foxaudioresearch@gmail.com - 2015-05-12 16:29 -0700
      Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-14 13:05 -0400
        Re: Array of Constants in Mecrisp Coos Haak <chforth@hccnet.nl> - 2015-05-14 22:21 +0200
          Re: Array of Constants in Mecrisp rickman <gnuarm@gmail.com> - 2015-05-15 11:27 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#39135

"Elizabeth D. Rather" <erather@forth.com> writes:
>On 5/14/15 9:26 PM, Anton Ertl wrote:
>> And this is the problem if the code field is in flash: overwriting is
>> not easily possible.  Native-code compilers also implement this with
>> an overwritable field and have the same problem.
>
>But interactive cross-compilers have no problem, because they generate a 
>target image in host (e.g. PC) RAM, download it, and then establish the 
>interactive link to it.

A compiler that works like that cannot process the standard code

: doesa does> drop ." a" ;
: doesb does> drop ." b" ;
create foo
doesa
foo \ prints "a"
doesb
foo \ prints "b"
doesa
foo \ prints "a" again

Probably too interactive for this kind of "interactive
cross-compiler".

In any case, there are a number of systems that do not want to impose
such restrictions, and for the CREATE...DOES> design is a problem.
They tend not to support the usage above, either (changing an
already-DOES>ed word is rare anyway), but the two-step approach (first
CREATE a word, then change it with DOES>) creates headaches already.
And these headaches would be easy to avoid with a one-step interface.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39137

In article <2015May15.120345@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>
>In any case, there are a number of systems that do not want to impose
>such restrictions, and for the CREATE...DOES> design is a problem.
>They tend not to support the usage above, either (changing an
>already-DOES>ed word is rare anyway), but the two-step approach (first
>CREATE a word, then change it with DOES>) creates headaches already.
>And these headaches would be easy to avoid with a one-step interface.

A one step interface can also be had by removing the default behaviour.

Using a CREATE d word without DOES> would be an ambiguous condition.
CREATE aap 3 , 4 ,
would no longer be possible.

Instead you would have to do
CREATE-WITH-HERE aap 3 , 4 ,
and
: CREATE-WITH-HERE CREATE DOES> ;

It is an example of confounding two concepts: simple buffers and
objects with one default method. Premature optimisation.

>
>- anton

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]

#39140

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>A one step interface can also be had by removing the default behaviour.
>
>Using a CREATE d word without DOES> would be an ambiguous condition.

That would break all the code that uses CREATE without DOES>.

There are proposals to reintroduce <BUILDS such that it works the way
you suggest for CREATE (which is funny, because <BUILDS in fig-Forth
behaved like CREATE does now and CREATE behaved differently).  But
that would still be a two-step interface, and this splitting into two
steps requires an ambiguous condition that can be avoided with a
one-step interface.

>It is an example of confounding two concepts: simple buffers and
>objects with one default method. Premature optimisation.

Maybe, although I don't think Charles Moore ist interested in the
concept of "premature optimization", he's much more concerned about
premature generalization.  And it was ok from about 1979 (it was not
present in fig-Forth, but it was present in Forth-79) into sometime in
the 2000s, when Flash became integrated into microcontrolers; it was
hard to foresee in 1979 that this would happen.  And even if we had
kept <BUILDS in 1979, it would have had the same semantics as the
current CREATE, so the benefit for the flash-based systems would have
been small.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39150

In article <2015May15.145106@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>A one step interface can also be had by removing the default behaviour.
>>
>>Using a CREATE d word without DOES> would be an ambiguous condition.
>
>That would break all the code that uses CREATE without DOES>.

No it would just mean that they have an environmental dependancy
on a CREATE that provides a default behaviour, i.e. all current
systems and except future flash based systems.

<SNIP>

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

#39169

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2015May15.145106@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>A one step interface can also be had by removing the default behaviour.
>>>
>>>Using a CREATE d word without DOES> would be an ambiguous condition.
>>
>>That would break all the code that uses CREATE without DOES>.
>
>No it would just mean that they have an environmental dependancy
>on a CREATE that provides a default behaviour, i.e. all current
>systems and except future flash based systems.

Right, it would "just" destandardize lots of existing programs.
Systems would have the choice to actually break these programs or to
continue supporting them.  A bad choice for the flash-based systems,
and if they decide to break the existing programs, this would
introduce two incompatible dialects.  And programmers would have to
replace the existing CREATEs (with what?) in order for their programs
to conform to the new standard.  Overall, a terrible idea.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39183

On 5/16/15 3:40 AM, Anton Ertl wrote:
> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>> In article <2015May15.145106@mips.complang.tuwien.ac.at>,
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>> A one step interface can also be had by removing the default behaviour.
>>>>
>>>> Using a CREATE d word without DOES> would be an ambiguous condition.
>>>
>>> That would break all the code that uses CREATE without DOES>.
>>
>> No it would just mean that they have an environmental dependancy
>> on a CREATE that provides a default behaviour, i.e. all current
>> systems and except future flash based systems.
>
> Right, it would "just" destandardize lots of existing programs.
> Systems would have the choice to actually break these programs or to
> continue supporting them.  A bad choice for the flash-based systems,
> and if they decide to break the existing programs, this would
> introduce two incompatible dialects.  And programmers would have to
> replace the existing CREATEs (with what?) in order for their programs
> to conform to the new standard.  Overall, a terrible idea.

Agreed. The thing is, using CREATE as a standalone defining word isn't a 
sometime thing, it's frequent, common, standard practice. That is 
CREATE's principle purpose; using it with DOES> is an added facility. A 
standard has no business breaking that or suddenly declaring it an 
"environmental dependency."

Cheers,
Elizabeth

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

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

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

#39154

On 5/15/15 12:03 AM, Anton Ertl wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> On 5/14/15 9:26 PM, Anton Ertl wrote:
>>> And this is the problem if the code field is in flash: overwriting is
>>> not easily possible.  Native-code compilers also implement this with
>>> an overwritable field and have the same problem.
>>
>> But interactive cross-compilers have no problem, because they generate a
>> target image in host (e.g. PC) RAM, download it, and then establish the
>> interactive link to it.
>
> A compiler that works like that cannot process the standard code
>
> : doesa does> drop ." a" ;
> : doesb does> drop ." b" ;
> create foo
> doesa
> foo \ prints "a"
> doesb
> foo \ prints "b"
> doesa
> foo \ prints "a" again
>
> Probably too interactive for this kind of "interactive
> cross-compiler".

Actually, I believe it can. I don't have a full setup with target, etc., 
so I can't prove it, but it is certainly quite possible to create new 
definitions interactively, either in high level or code.

> In any case, there are a number of systems that do not want to impose
> such restrictions, and for the CREATE...DOES> design is a problem.
> They tend not to support the usage above, either (changing an
> already-DOES>ed word is rare anyway), but the two-step approach (first
> CREATE a word, then change it with DOES>) creates headaches already.
> And these headaches would be easy to avoid with a one-step interface.

Frankly, I can't think of a time when I wanted to change the behavior of 
an "already-DOES>ed word" but I have spent a lot of time working with 
targets under development, and cannot think of anything I wanted to do 
but couldn't.

Cheers,
Elizabeth

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

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

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

#39147

On 5/14/2015 1:20 PM, rickman wrote:
> On 5/14/2015 1:04 PM, Alex McDonald wrote:
>> on 14/05/2015 18:00:34, rickman wrote:
>>> On 5/11/2015 6:10 AM, Matthias Koch wrote:
>>>>> compiletoram
>>>>>
>>>>> : charconstarray <builds does> + c@ ;
>>>>>
>>>>> charconstarray arraytest
>>>>>    $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c,
>>>>> $1B c,
>>>>> In the above code, is <builds necessary?  Could it be omitted or does
>>>>> it muck with the state or something that is needed with does> ?
>>>>>
>>>>
>>>> <builds does> is necessary because the standard action of create cannot
>>>> be overwritten when compiling into flash. So create has standard
>>>> action,
>>>> <builds has no action.
>>>
>>> So what *is* the standard action of create? Does> puts the data field
>>> address on the stack, right?
>>>
>>
>> CREATE puts the data field address on the stack. DOES> adds to that
>> behaviour by executing the code that follows it.
>
> Can you explain what is meant by
>
> DOES> “does” CORE
> Run-time: ( –– ) ( R: nest-sys 1 –– )
> Replace the execution semantics of the most recent definition, referred
> to as name, with the name execution semantics given below.
>
> "Replace" seems to be what Matthais is talking about causing a problem
> in flash.  But if CREATE puts the DFA on the stack and DOES> appends to
> that, what is being replaced?

Ok, I think I am clear or at least more clear on what CREATE is doing 
that is not so compatible with flash and DOES>.  But what does <BUILDS 
do that is different from CREATE that lets it work in flash?  It is not 
part of ANS Forth so I can't look it up so easily.  I get the impression 
that it does not write any default behavior to the definition.  I guess 
then it is different from CREATE in that it can't be used without DOES> ?

-- 

Rick

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

#39155

On 5/15/15 5:31 AM, rickman wrote:
> On 5/14/2015 1:20 PM, rickman wrote:
>> On 5/14/2015 1:04 PM, Alex McDonald wrote:
>>> on 14/05/2015 18:00:34, rickman wrote:
>>>> On 5/11/2015 6:10 AM, Matthias Koch wrote:
>>>>>> compiletoram
>>>>>>
>>>>>> : charconstarray <builds does> + c@ ;
>>>>>>
>>>>>> charconstarray arraytest
>>>>>>    $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c,
>>>>>> $1B c,
>>>>>> In the above code, is <builds necessary?  Could it be omitted or does
>>>>>> it muck with the state or something that is needed with does> ?
>>>>>>
>>>>>
>>>>> <builds does> is necessary because the standard action of create
>>>>> cannot
>>>>> be overwritten when compiling into flash. So create has standard
>>>>> action,
>>>>> <builds has no action.
>>>>
>>>> So what *is* the standard action of create? Does> puts the data field
>>>> address on the stack, right?
>>>>
>>>
>>> CREATE puts the data field address on the stack. DOES> adds to that
>>> behaviour by executing the code that follows it.
>>
>> Can you explain what is meant by
>>
>> DOES> “does” CORE
>> Run-time: ( –– ) ( R: nest-sys 1 –– )
>> Replace the execution semantics of the most recent definition, referred
>> to as name, with the name execution semantics given below.
>>
>> "Replace" seems to be what Matthais is talking about causing a problem
>> in flash.  But if CREATE puts the DFA on the stack and DOES> appends to
>> that, what is being replaced?
>
> Ok, I think I am clear or at least more clear on what CREATE is doing
> that is not so compatible with flash and DOES>.  But what does <BUILDS
> do that is different from CREATE that lets it work in flash?  It is not
> part of ANS Forth so I can't look it up so easily.  I get the impression
> that it does not write any default behavior to the definition.  I guess
> then it is different from CREATE in that it can't be used without DOES> ?
>

Yes. It's like CREATE except it doesn't write a default behavior, and 
therefore *must* be followed by a DOES>.

Cheers,
Elizabeth

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

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

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

#39170

On 5/15/2015 3:31 PM, Elizabeth D. Rather wrote:
> On 5/15/15 5:31 AM, rickman wrote:
>> On 5/14/2015 1:20 PM, rickman wrote:
>>> On 5/14/2015 1:04 PM, Alex McDonald wrote:
>>>> on 14/05/2015 18:00:34, rickman wrote:
>>>>> On 5/11/2015 6:10 AM, Matthias Koch wrote:
>>>>>>> compiletoram
>>>>>>>
>>>>>>> : charconstarray <builds does> + c@ ;
>>>>>>>
>>>>>>> charconstarray arraytest
>>>>>>>    $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c,
>>>>>>> $1B c,
>>>>>>> In the above code, is <builds necessary?  Could it be omitted or
>>>>>>> does
>>>>>>> it muck with the state or something that is needed with does> ?
>>>>>>>
>>>>>>
>>>>>> <builds does> is necessary because the standard action of create
>>>>>> cannot
>>>>>> be overwritten when compiling into flash. So create has standard
>>>>>> action,
>>>>>> <builds has no action.
>>>>>
>>>>> So what *is* the standard action of create? Does> puts the data field
>>>>> address on the stack, right?
>>>>>
>>>>
>>>> CREATE puts the data field address on the stack. DOES> adds to that
>>>> behaviour by executing the code that follows it.
>>>
>>> Can you explain what is meant by
>>>
>>> DOES> “does” CORE
>>> Run-time: ( –– ) ( R: nest-sys 1 –– )
>>> Replace the execution semantics of the most recent definition, referred
>>> to as name, with the name execution semantics given below.
>>>
>>> "Replace" seems to be what Matthais is talking about causing a problem
>>> in flash.  But if CREATE puts the DFA on the stack and DOES> appends to
>>> that, what is being replaced?
>>
>> Ok, I think I am clear or at least more clear on what CREATE is doing
>> that is not so compatible with flash and DOES>.  But what does <BUILDS
>> do that is different from CREATE that lets it work in flash?  It is not
>> part of ANS Forth so I can't look it up so easily.  I get the impression
>> that it does not write any default behavior to the definition.  I guess
>> then it is different from CREATE in that it can't be used without DOES> ?
>>
>
> Yes. It's like CREATE except it doesn't write a default behavior, and
> therefore *must* be followed by a DOES>.

So why was <BUILDS removed from the language standard?  Seems like it is 
useful especially since you can't do the same things with CREATE.

-- 

Rick

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

#39177

rickman <gnuarm@gmail.com> writes:
>So why was <BUILDS removed from the language standard?  Seems like it is 
>useful especially since you can't do the same things with CREATE.

One would have to ask the Forth-79 committee why they did not include
it.  Note that <BUILDS in fig-Forth worked quite differently from what
Elizabeth Rather described: It worked like the CREATE of
Forth-79...Forth-2012, but used an extra cell.  It seems that someone
(Chuck Moore?) came up with an idea to get rid of the extra cell; one
could have done so and still call the word <BUILDS, but apparently
someone found it preferable to change CREATE to work like <BUILDS
without the extra cell, and then use CREATE instead of <BUILDS.  Saves
one word, and I am sure the word counters were already a force to be
reconned with in the Forth-79 committee.

<BUILDS did exactly what CREATE does since Forth-79, so I find it a
bad idea to introduce a new word <BUILDS that does something different
from the old <BUILDS.  Admittedly, it has been 26 years, so any old
code has either been updated or is never going to be updated; but
concepts live longer in programmer heads, so using an old name for a
different concept may cause confusion.

As for not being able to do the same things with CREATE, a programmer
can do all the same things with CREATE that he can do with the
proposed new, restricted <BUILDS; the advantage of the new, restricted
<BUILDS is not that the programmer can do new things, but that the
system implementor can implement it cheaper and/or easier.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39178

On 5/16/2015 12:12 PM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> So why was <BUILDS removed from the language standard?  Seems like it is
>> useful especially since you can't do the same things with CREATE.
>
> One would have to ask the Forth-79 committee why they did not include
> it.  Note that <BUILDS in fig-Forth worked quite differently from what
> Elizabeth Rather described: It worked like the CREATE of
> Forth-79...Forth-2012, but used an extra cell.  It seems that someone
> (Chuck Moore?) came up with an idea to get rid of the extra cell; one
> could have done so and still call the word <BUILDS, but apparently
> someone found it preferable to change CREATE to work like <BUILDS
> without the extra cell, and then use CREATE instead of <BUILDS.  Saves
> one word, and I am sure the word counters were already a force to be
> reconned with in the Forth-79 committee.
>
> <BUILDS did exactly what CREATE does since Forth-79, so I find it a
> bad idea to introduce a new word <BUILDS that does something different
> from the old <BUILDS.  Admittedly, it has been 26 years, so any old
> code has either been updated or is never going to be updated; but
> concepts live longer in programmer heads, so using an old name for a
> different concept may cause confusion.
>
> As for not being able to do the same things with CREATE, a programmer
> can do all the same things with CREATE that he can do with the
> proposed new, restricted <BUILDS; the advantage of the new, restricted
> <BUILDS is not that the programmer can do new things, but that the
> system implementor can implement it cheaper and/or easier.

Thanks for the info.  I have to say I still have gaps in my 
understanding.  When you say the old <BUILDS uses an extra cell, do you 
mean in the header structure of every word?  I can see where that would 
be an expensive price.  If you mean there is an extra word used in the 
implementation of words defined with <BUILDS, then obviously this is 
less of an issue.

Why would the implementation of <BUILDS be constrained by precedence? 
Obviously I don't understand what this extra cell implies.

-- 

Rick

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

#39179

rickman <gnuarm@gmail.com> writes:
>Thanks for the info.  I have to say I still have gaps in my 
>understanding.  When you say the old <BUILDS uses an extra cell, do you 
>mean in the header structure of every word?  I can see where that would 
>be an expensive price.  If you mean there is an extra word used in the 
>implementation of words defined with <BUILDS, then obviously this is 
>less of an issue.

It used an extra cell in every word defined with <BUILDS.

>Why would the implementation of <BUILDS be constrained by precedence? 
>Obviously I don't understand what this extra cell implies.

Not sure what you mean.  If you refer to my last paragraph, what I
mean is that you can do

: doesa does> drop ." a" ;
: doesb does> drop ." b" ;
<builds foo
doesa
foo \ prints "a"
doesb
foo \ prints "b"
doesa
foo \ prints "a" again

in fig-Forth, and the proposal is for a word that cannot do 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39193

Anton Ertl wrote:

> rickman <gnuarm@gmail.com> writes:
>>Thanks for the info.  I have to say I still have gaps in my
>>understanding.  When you say the old <BUILDS uses an extra cell, do you
>>mean in the header structure of every word?  I can see where that would
>>be an expensive price.  If you mean there is an extra word used in the
>>implementation of words defined with <BUILDS, then obviously this is
>>less of an issue.
> 
> It used an extra cell in every word defined with <BUILDS.

It was actually defined (converting fig assembler listing to Forth source):

: <builds  0 constant ;

and

: does>  r> latest pfa ! ;code
\ plattform dependent assembler code for dodoes, e.g. for 6502
DODOE	LHLD	RPP	; (HL) <- (RP)
	DCX	H
	MOV	M,B	; (R1) <- (IP) = PFA = (SUBSTITUTE CFA)
	DCX	H
	MOV	M,C
	SHLD	RPP	; (RP) <- (RP) - 2
	INX	D	; (DE) <- PFA = (SUBSTITUTE CFA)
	XCHG
	MOV	C,M	; (IP) <- (SUBSTITUTE CFA)
	INX	H
	MOV	B,M
	INX	H
	JMP	HPUSH	; (S1) <- PFA+2 = SUBSTITUTE PFA

>>Why would the implementation of <BUILDS be constrained by precedence?
>>Obviously I don't understand what this extra cell implies.
> 
> Not sure what you mean.  If you refer to my last paragraph, what I
> mean is that you can do
> 
> : doesa does> drop ." a" ;
> : doesb does> drop ." b" ;
> <builds foo
> doesa
> foo \ prints "a"
> doesb
> foo \ prints "b"
> doesa
> foo \ prints "a" again
> 
> in fig-Forth, and the proposal is for a word that cannot do this.

Well, on a RAM-based system, it can do this.  The proposal is for a word 
where this ability is not actually a requirement (which it is for CREATE).

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

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

#39197

Bernd Paysan <bernd.paysan@gmx.de> writes:
> It was actually defined (converting fig assembler listing to Forth source):
>
> : <builds  0 constant ;

Here's the original Forth source:

https://github.com/ForthHub/FIG-Forth/blob/master/fig.fth#L717

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

#39200

Op Mon, 18 May 2015 08:37:45 +0200 schreef Lars Brinkhoff:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> It was actually defined (converting fig assembler listing to Forth source):
>>
>>: <builds  0 constant ;
> 
> Here's the original Forth source:
> 
> https://github.com/ForthHub/FIG-Forth/blob/master/fig.fth#L717

Why is that more original? Both are Figforth. Paysan's is for 8080 and
yours is for 6502. I could show this for 360 1802 PDP11 etc. etc.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#39202

Coos Haak <chforth@hccnet.nl> writes:
>> Here's the original [FIG] Forth source:
>> https://github.com/ForthHub/FIG-Forth/blob/master/fig.fth#L717
>
> Why is that more original? Both are Figforth. Paysan's is for 8080 and
> yours is for 6502. I could show this for 360 1802 PDP11 etc. etc.

Paysan wrote about converting assembler listing to Forth source.  My
link is to the Forth source.  Well, with some ;CODE.

It's my understanding that Bill Ragsdale and Robert Selzer created the
FIG Forth Model for 6502, and it was metacompiled.  The assembly listing
FIG Forths were created from this first version.

I may well be wrong though.

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

#39203

In article <86twva9kjq.fsf@vps34351.public.cloudvps.com>,
Lars Brinkhoff  <lars.spam@nocrew.org> wrote:
>Coos Haak <chforth@hccnet.nl> writes:
>>> Here's the original [FIG] Forth source:
>>> https://github.com/ForthHub/FIG-Forth/blob/master/fig.fth#L717
>>
>> Why is that more original? Both are Figforth. Paysan's is for 8080 and
>> yours is for 6502. I could show this for 360 1802 PDP11 etc. etc.
>
>Paysan wrote about converting assembler listing to Forth source.  My
>link is to the Forth source.  Well, with some ;CODE.
>
>It's my understanding that Bill Ragsdale and Robert Selzer created the
>FIG Forth Model for 6502, and it was metacompiled.  The assembly listing
>FIG Forths were created from this first version.
>
>I may well be wrong though.

I've about 8 assembly listings for the fig model, for texas instruments,
pdp, 6502, 8086, 8080, z80 6809 68000.
The assembly listings e.g. for figForth CPM became a source for
further development. I remember taking a 8080 listing to work.
A colleague made a photocopy, then typed it in over the next weekend.

I adapted the source for 8080 such that it used blocks in CP/M files
not on raw floppies. This was given to the DOS user group (part of HCC)
for further distribution. It went as far as Australia.

I got the hex dump for the 68000 figForth over the phone with a 300 baud
modem from Arie Kattenberg, and then we generated a source for it in
true Motorola 68K assembler (as opposed to a Forth assembler as in the
official fig Listing), assembling it with a public domain assembler on
that OS9 of Peter Nooij, with its 16K memory (Gigantic for the time,
Peter had managed to hack an interface to magnetic core memory).
Later we used my Osborne CP/M (as far as I remember).
This was one of the first programs to run on a meeting of the
68000 user group. Most of them where hardware guys who were busy
building a 68000 system.

Other efforts were based on metacompiling. Adrie Bos did that based
on a master class given by Arie Kattenberg. That was tedious with
his cassette tape system. He made a tremendous progress over my holiday
when he borrowed my Osborne.
That source is still somewhere on my website.

Those were the days ...

It is one of the motivations for having ciforth in assembler.
The portability of assembler code within a processor is not bad.

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]

#39185

On 5/16/15 6:12 AM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> So why was <BUILDS removed from the language standard?  Seems like it is
>> useful especially since you can't do the same things with CREATE.
>
> One would have to ask the Forth-79 committee why they did not include
> it.  Note that <BUILDS in fig-Forth worked quite differently from what
> Elizabeth Rather described: It worked like the CREATE of
> Forth-79...Forth-2012, but used an extra cell.  It seems that someone
> (Chuck Moore?) came up with an idea to get rid of the extra cell; one
> could have done so and still call the word <BUILDS, but apparently
> someone found it preferable to change CREATE to work like <BUILDS
> without the extra cell, and then use CREATE instead of <BUILDS.  Saves
> one word, and I am sure the word counters were already a force to be
> reconned with in the Forth-79 committee.
>
> <BUILDS did exactly what CREATE does since Forth-79, so I find it a
> bad idea to introduce a new word <BUILDS that does something different
> from the old <BUILDS.  Admittedly, it has been 26 years, so any old
> code has either been updated or is never going to be updated; but
> concepts live longer in programmer heads, so using an old name for a
> different concept may cause confusion.
>
> As for not being able to do the same things with CREATE, a programmer
> can do all the same things with CREATE that he can do with the
> proposed new, restricted <BUILDS; the advantage of the new, restricted
> <BUILDS is not that the programmer can do new things, but that the
> system implementor can implement it cheaper and/or easier.

I believe it was actually Dean Sanderson's innovation. Otherwise, the 
above is correct.

Cheers,
Elizabeth


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

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

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

#39184

On 5/16/15 4:00 AM, rickman wrote:
> On 5/15/2015 3:31 PM, Elizabeth D. Rather wrote:
>> On 5/15/15 5:31 AM, rickman wrote:
>>> On 5/14/2015 1:20 PM, rickman wrote:
>>>> On 5/14/2015 1:04 PM, Alex McDonald wrote:
>>>>> on 14/05/2015 18:00:34, rickman wrote:
>>>>>> On 5/11/2015 6:10 AM, Matthias Koch wrote:
>>>>>>>> compiletoram
>>>>>>>>
>>>>>>>> : charconstarray <builds does> + c@ ;
>>>>>>>>
>>>>>>>> charconstarray arraytest
>>>>>>>>    $1E c, $08 c, $1D c, $19 c, $0B c, $13 c, $17 c, $18 c, $1F c,
>>>>>>>> $1B c,
>>>>>>>> In the above code, is <builds necessary?  Could it be omitted or
>>>>>>>> does
>>>>>>>> it muck with the state or something that is needed with does> ?
>>>>>>>>
>>>>>>>
>>>>>>> <builds does> is necessary because the standard action of create
>>>>>>> cannot
>>>>>>> be overwritten when compiling into flash. So create has standard
>>>>>>> action,
>>>>>>> <builds has no action.
>>>>>>
>>>>>> So what *is* the standard action of create? Does> puts the data field
>>>>>> address on the stack, right?
>>>>>>
>>>>>
>>>>> CREATE puts the data field address on the stack. DOES> adds to that
>>>>> behaviour by executing the code that follows it.
>>>>
>>>> Can you explain what is meant by
>>>>
>>>> DOES> “does” CORE
>>>> Run-time: ( –– ) ( R: nest-sys 1 –– )
>>>> Replace the execution semantics of the most recent definition, referred
>>>> to as name, with the name execution semantics given below.
>>>>
>>>> "Replace" seems to be what Matthais is talking about causing a problem
>>>> in flash.  But if CREATE puts the DFA on the stack and DOES> appends to
>>>> that, what is being replaced?
>>>
>>> Ok, I think I am clear or at least more clear on what CREATE is doing
>>> that is not so compatible with flash and DOES>.  But what does <BUILDS
>>> do that is different from CREATE that lets it work in flash?  It is not
>>> part of ANS Forth so I can't look it up so easily.  I get the impression
>>> that it does not write any default behavior to the definition.  I guess
>>> then it is different from CREATE in that it can't be used without
>>> DOES> ?
>>>
>>
>> Yes. It's like CREATE except it doesn't write a default behavior, and
>> therefore *must* be followed by a DOES>.
>
> So why was <BUILDS removed from the language standard?  Seems like it is
> useful especially since you can't do the same things with CREATE.

Because it was unnecessary, and the implementation with CREATE can be 
more efficient. That was in the time before flash; embedded systems had 
PROMs.

Cheers,
Elizabeth

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

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

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web