f



PICK changed from 1-based to 0-based?

Someone on Stack Overflow pointed to page 27 of the Forth-79 standard,

  https://mywebspace.wisc.edu/lnmaurer/web/forth/Forth-79.pdf

It indicates that PICK is 1-based, e.g. it says "2 PICK is equivalent to
OVER".

These days, PICK is 0-based, i.e. OVER is equivalent to 1 PICK.

I realize PICK is frowned on regardless, but did the Forth world really
accept a breaking change like this?  Or is the document wrong compared
to actual practice at the time?
0
Paul
12/29/2013 7:39:38 AM
comp.lang.forth 7148 articles. 0 followers. markrobertwills (871) is leader. Post Follow

331 Replies
1314 Views

Similar Articles

[PageSpeed] 36

On 12/28/2013 9:39 PM, Paul Rubin wrote:
> Someone on Stack Overflow pointed to page 27 of the Forth-79 standard,
>
>    https://mywebspace.wisc.edu/lnmaurer/web/forth/Forth-79.pdf
>
> It indicates that PICK is 1-based, e.g. it says "2 PICK is equivalent to
> OVER".
>
> These days, PICK is 0-based, i.e. OVER is equivalent to 1 PICK.
>
> I realize PICK is frowned on regardless, but did the Forth world really
> accept a breaking change like this?  Or is the document wrong compared
> to actual practice at the time?
>

It happened in Forth83. The predominant philosophy of that committee 
was, "current usage be damned, we'll make things work RIGHT!". PICK was 
one of the less-traumatic changes. From the Forth94 description of 
changes from prior standards:

"Forth 83 was similar to Forth 79 in most respects. However, Forth 83 
changed the definition of several well-defined features of Forth 79. For 
example, the rounding behavior of integer division, the base value of 
the operands of PICK and ROLL, the meaning of the address returned by ', 
the compilation behavior of ', the value of a �true� flag, the meaning 
of NOT, and the �chaining� behavior of words defined by VOCABULARY were 
all changed. Forth 83 relaxed the implementation restrictions of Forth 
79 to allow any kind of threaded code, but it did not fully allow 
compilation to native machine code (this was not specifically 
prohibited, but rather was an indirect consequence of another provision)."

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."
==================================================
0
Elizabeth
12/29/2013 7:52:23 AM
Elizabeth D Rather wrote:
> "Forth 83 was similar to Forth 79 in most respects. However, Forth 83
> changed the definition of several well-defined features of Forth 79. For
> example, the rounding behavior of integer division, the base value of
> the operands of PICK and ROLL, the meaning of the address returned by ',
> the compilation behavior of ', the value of a “true” flag, the meaning
> of NOT, and the “chaining” behavior of words defined by VOCABULARY were
> all changed. Forth 83 relaxed the implementation restrictions of Forth
> 79 to allow any kind of threaded code, but it did not fully allow
> compilation to native machine code (this was not specifically
> prohibited, but rather was an indirect consequence of another provision)."
Forth-83 is where Forth IMHO went wrong. In every high level programming
language there are concepts and abstractions. E.g. when you write in C:

  argv[1][1]

There is no twodimensional matrix somewhere in memory space, but the
abstraction allows you to think that way. Some abstractions are very
elaborate, like OO - or did you really think there was an object floating
somewhere in memory with all its methods attached like a swiss army knife?

What people essentially did in Forth-83 was to strip most/some/all intuitive
concepts of Forth and turn it into a somewhat glorified assembler. "falling
through" in a loop concept like DO..LOOP. Turning "true" into an "all bits
set" value - just because you could do some obfuscated binary tricks with
it. I can forgive them for PICK and ROLL because no Forther in his right
mind would use these.

Unfortunately, although ANS-94 fixed some of these, a lot of 'em are still
there. Add to that some C-type "bolt on" constructs and you got the mess we
are in now. Current developments? One step ahead, two steps back.

Hans Bezemer
0
Hans
12/29/2013 10:28:59 AM
Hans Bezemer wrote:
> ...
> I can forgive them for PICK and ROLL because no Forther in his right
> mind would use these.

I needed and defined -ROLL.  SwiftForth has them too :)



0
Ed
12/29/2013 12:12:49 PM
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
> Forth-83 is where Forth IMHO went wrong. [ ... ]
> 
> What people essentially did in Forth-83 was to strip most/some/all
> intuitive concepts of Forth and turn it into a somewhat glorified
> assembler. "falling through" in a loop concept like
> DO..LOOP. Turning "true" into an "all bits set" value - just because
> you could do some obfuscated binary tricks with it. I can forgive
> them for PICK and ROLL because no Forther in his right mind would
> use these.

Some of the big changes were essential, though: we couldn't live with
16-bit threaded code forever.  The 83-standard DO..LOOP was
undoubtedly a mistake, but what possible damage did "all bits set" do?
How is it unintuitive?  PICK and ROLL don't matter.

Andrew.
0
Andrew
12/29/2013 1:45:41 PM
Andrew Haley wrote:

> <snip> but what possible damage did "all bits set" do?
> How is it unintuitive?
Because it feels like a feeble attempt to (a) eradicate the difference
between "logical" and "binary" values and (b) to abuse a logical value as a
mask for some fancy binary tricks.

It's the same kind of attitude that makes people abuse COUNT as C@+ and
attributes to Forths reputation as an "unmaintainable" and "write-only"
language.

In ANS-Forth the 'TRUE' has the value "-1", which means all bits are set.
Which is very clever. You can 'XOR', 'OR', 'AND' and 'INVERT' it with any
other value and it will behave as logical value. But "the all bits set"
flag has its drawbacks too. Let's see what the ANS-Forth standard says
about flags:

"A FALSE flag is a single-cell datum with all bits unset, and a TRUE flag is
a single-cell datum with all bits set. While Forth words which test flags
accept any non-null bit pattern as true, there exists the concept of the
well-formed flag. If an operation whose result is to be used as a flag may
produce any bit-mask other than TRUE or FALSE, the recommended discipline
is to convert the result to a well-formed flag by means of the Forth word
0<> so that the result of any subsequent logical operations on the flag
will be predictable. In addition to the words which move, fetch and store
single-cell items, the following words are valid for operations on one or
more flag data residing on the data stack: AND OR XOR INVERT"

I highly recommend the discipline of converting a non-zero value to a
well-formed flag. But I don't understand why 'INVERT' is a valid way to
manipulate a flag. I'll try to explain you why.

Forth traditionally has no specific logical operators. Instead, binary
operators were used. This put 'INVERT' (or 'NOT' as it was called in
Forth-79) in a difficult position. 'INVERT'ing any non-zero value will
result in a non-zero value, except when all bits are set.

That is why '0=' was introduced, a full-fledged logical operator. So why
use 'INVERT' when you want to perform a logical operation? Another quote:

"Since a "char" can store small positive numbers and since the character
data type is a sub-range of the unsigned integer data type, C! must store
the n least-significant bits of a cell (8 <= n <= bits/cell). Given the
enumeration of allowed number representations and their known
encodings, "TRUE xx C! xx C@" must leave a stack item with some number of
bits set, which will thus will be accepted as non-zero by IF."

This is another problem of using "all bits set" as a true flag: you store a
well formed flag in an address unit that should easily be able to handle it
and you'll never get it back. A flag is a boolean and can have two values:
either true or false. The smallest unit that can hold a boolean is a bit. 

But why are some Forth programmers so keen on their "all bits set" flag?
Well, you can do neat things with it.

: >CHAR DUP 9 > 7 AND + ASCII 0 + ;

This will convert a digit to its ASCII representation. True, it is a clever
piece of programming, but in my opinion it is bad style. Why? Because you
are using a flag as a bitmask, which is a completely different datatype.
Although there is no such thing as "data typing" in Forth, this way of
programming makes it difficult to understand and maintain a program, which
the ANS-Forth standard acknowledges:

"The discipline of circumscribing meaning which a program may assign to
various combinations of bit patterns is sometimes called data typing. Many
computer languages impose explicit data typing and have compilers that
prevent ill-defined operations. Forth rarely explicitly imposes data-type
restrictions. Still, data types implicitly do exist, and discipline is
required, particularly if portability of programs is a goal. In Forth, it
is incumbent upon the programmer (rather than the compiler) to determine
that data are accurately typed."

I would applaud it if Forth would feature some true logical operators,
because the return values of AND, OR and INVERT are not guaranteed to be
well-formed flags UNLESS their input were BOTH well-formed flags. Simple
maintenance can easily introduce subtle bugs which are hard to track. Not
to mention it obfuscates the intentions of the programmer - like using
COUNT for C@+.

I *never ever* use INVERT for inverting a flag - that's what 0= is for.

Hans Bezemer
0
Hans
12/29/2013 5:33:45 PM
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
> Andrew Haley wrote:
> 
>> <snip> but what possible damage did "all bits set" do?
>> How is it unintuitive?
> Because it feels like a feeble attempt to (a) eradicate the difference
> between "logical" and "binary" values and (b) to abuse a logical value as a
> mask for some fancy binary tricks.
> 
> It's the same kind of attitude that makes people abuse COUNT as C@+ and
> attributes to Forths reputation as an "unmaintainable" and "write-only"
> language.
> 
> In ANS-Forth the 'TRUE' has the value "-1", which means all bits are set.

No, it doesn't, except by accident.  It has the value 11111111... or
FFFF....  

> That is why '0=' was introduced, a full-fledged logical operator. So
> why use 'INVERT' when you want to perform a logical operation?

Because NOT, which IMO is the correct name for this purpose, could not
be standardized.

> But why are some Forth programmers so keen on their "all bits set"
> flag?  Well, you can do neat things with it.
> 
> : >CHAR DUP 9 > 7 AND + ASCII 0 + ;
> 
> This will convert a digit to its ASCII representation. True, it is a
> clever piece of programming, but in my opinion it is bad style. Why?
> Because you are using a flag as a bitmask, which is a completely
> different datatype. 

But it's not a different datatype in Standard Forth: it's a
well-formed flag, which is defined to be all ones or all zeroes.  It
maye be a different datatype in other languages.

> Although there is no such thing as "data typing" in Forth, this way
> of programming makes it difficult to understand and maintain a
> program, which the ANS-Forth standard acknowledges:
> 
> "The discipline of circumscribing meaning which a program may assign
> to various combinations of bit patterns is sometimes called data
> typing. Many computer languages impose explicit data typing and have
> compilers that prevent ill-defined operations. Forth rarely
> explicitly imposes data-type restrictions. Still, data types
> implicitly do exist, and discipline is required, particularly if
> portability of programs is a goal. In Forth, it is incumbent upon
> the programmer (rather than the compiler) to determine that data are
> accurately typed."

Indeed.  So, it all depends on what you think the datatype of a well-
formed flag is.  The type of the result of a comparison in Forth is
not a boolean -- it's a well-formed flag, which is a cell.

> I would applaud it if Forth would feature some true logical
> operators, because the return values of AND, OR and INVERT are not
> guaranteed to be well-formed flags UNLESS their input were BOTH
> well-formed flags.

Following the logic of this argument, it seems to me you are saying
that you *do not care* what the value for TRUE is because none of your
programs will assume anything about it, other than that you want it to
fit in a byte.

Andrew.
0
Andrew
12/29/2013 10:57:48 PM
Andrew Haley wrote:
> Following the logic of this argument, it seems to me you are saying
> that you *do not care* what the value for TRUE is because none of your
> programs will assume anything about it, other than that you want it to
> fit in a byte.
Yes and no. No, none of my programs assume ANY value of TRUE, since they all
work with "well-formed flags". Consequently, I have no trouble "porting"
them to Forth. However, the other way around I find many Forth programs who
DO assume that TRUE has a certain value (examples given) - which makes my
life a lot harder. Like the people who abuse COUNT. Fortunately, I have to
clean it up only once.

I think this despicable attitude towards programming holds back Forth in
several ways. Not the least the people why cry out when someone comes with
a proposal to clean up the mess - because they have a lot of badly written
legacy code to maintain.

Hans Bezemer

0
Hans
12/29/2013 11:25:06 PM
On Sun, 29 Dec 2013 08:45:41 -0500, Andrew Haley  
<andrew29@littlepinkcloud.invalid> wrote:
> Hans Bezemer <the.beez.speaks@gmail.com> wrote:
>> Forth-83 is where Forth IMHO went wrong. [ ... ]

>> Turning "true" into an "all bits set" value [...]
>
> [...] but what possible damage did "all bits set" do?
>

It doesn't do any damage.  In fact, it helps.

Using "all bits set" for a TRUE flag allows a high-level language
to have both logical and binary operations, while only needing the
processor to support simple binary operations, such as AND OR XOR.
This, of course, is in the context of zero being logical false and
non-zero being logical true.


Rod Pemberton
0
Rod
12/30/2013 3:32:42 AM
On Sun, 29 Dec 2013 02:39:38 -0500, Paul Rubin <no.email@nospam.invalid>  
wrote:

> These days, PICK is 0-based, i.e. OVER is equivalent to 1 PICK.
>

I believe zero-based is a good change.


Rod Pemberton
0
Rod
12/30/2013 3:34:55 AM
On 12/29/13 5:34 PM, Rod Pemberton wrote:
> On Sun, 29 Dec 2013 02:39:38 -0500, Paul Rubin <no.email@nospam.invalid>
> wrote:
>
>> These days, PICK is 0-based, i.e. OVER is equivalent to 1 PICK.
>>
>
> I believe zero-based is a good change.

Both this one and the truth value were reasonable, it's just that they 
broke a lot of code and made a lot of people mad.

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."
==================================================
0
Elizabeth
12/30/2013 5:30:32 AM
"Elizabeth D. Rather" <erather@forth.com> writes:
> Both this one and the truth value were reasonable, it's just that they
> broke a lot of code and made a lot of people mad.

Yes, this background explains some things.  I had the impression that
Forth standardization efforts generally try to stick with documenting
existing stuff, rather than introducing new stuff or breaking anything.
That's why the change from 1 to 0 surprised me.  It now sounds like they
went the "break stuff" route back in 1983 and are still dealing with the
repercussions, so they now stay away from that approach.
0
Paul
12/30/2013 6:49:35 AM
Am 30.12.2013 07:49, schrieb Paul Rubin:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> Both this one and the truth value were reasonable, it's just that they
>> broke a lot of code and made a lot of people mad.
>
> Yes, this background explains some things.  I had the impression that
> Forth standardization efforts generally try to stick with documenting
> existing stuff, rather than introducing new stuff or breaking anything.
> That's why the change from 1 to 0 surprised me.  It now sounds like they
> went the "break stuff" route back in 1983 and are still dealing with the
> repercussions, so they now stay away from that approach.
>

Well, people back then were young and revolutionary.  ;-)
Now all Forthers are old and conservative.

IMO Forth's evolution is blocked because of some wanting it to stay the 
ultimate compact embedded systems development tool, whereas others 
wanting it to be a powerful computer language. BTW the Lisp world once 
solved that dilemma by forking to the Scheme and CommonLisp paths.

0
AKK
12/30/2013 7:48:09 AM
On 30/12/2013 07:49, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> Both this one and the truth value were reasonable, it's just that they
>> broke a lot of code and made a lot of people mad.
>
> Yes, this background explains some things.  I had the impression that
> Forth standardization efforts generally try to stick with documenting
> existing stuff, rather than introducing new stuff or breaking anything.
> That's why the change from 1 to 0 surprised me.  It now sounds like they
> went the "break stuff" route back in 1983 and are still dealing with the
> repercussions, so they now stay away from that approach.
>

I wonder. Earlier in another thread, you asked about culture 
differences. Possibly this is the case here.
They did not take the 'break stuff' route, but a fix route...
Quite a different way of interpretation! Negative vs positive 
connotation. Mr. Moore and others continued on that route, rigorously 
(and in general stay away from here)!
I think in retrospect, those using Forth and involved with 
standardization in those days, were different from the current crop.
Both in culture and mentality. Obviously depends whether you see this as 
negative or positive.

As for breaking, they dealt with that ages ago. There's the colon, lest 
you forget. What repercussions? ;-)

0
Roelf
12/30/2013 8:14:34 AM
Paul Rubin <no.email@nospam.invalid> wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> Both this one and the truth value were reasonable, it's just that they
>> broke a lot of code and made a lot of people mad.
> 
> Yes, this background explains some things.  I had the impression that
> Forth standardization efforts generally try to stick with documenting
> existing stuff, rather than introducing new stuff or breaking anything.
> That's why the change from 1 to 0 surprised me.  It now sounds like they
> went the "break stuff" route back in 1983 and are still dealing with the
> repercussions, so they now stay away from that approach.

That's not the reason, IMO.  If things were just as broken now as they
were before 1983, similar radical change would be needed.

Andrew.
0
Andrew
12/30/2013 9:35:14 AM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>That's not the reason, IMO.  If things were just as broken now as they
>were before 1983, similar radical change would be needed.

What breakage in Forth-79 made the change from 0-or-1 to
0-or-all-bits-set necessary?

What breakage in Forth-79 made the changes to PICK and ROLL necessary.

And what breakage in Forth-79 made it necessary to implement these
changes as incompatible changes of existing words instead of
introducing new names?

Concerning the brokenness of "before 1983", what was broken how?  IIRC
Elizabeth Rather once claimed that Forth-79 was contradictory, but she
did not point to any concrete problems and neither do you.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
12/30/2013 4:06:26 PM
AKK <akk@nospam.org> writes:
>IMO Forth's evolution is blocked because of some wanting it to stay the 
>ultimate compact embedded systems development tool, whereas others 
>wanting it to be a powerful computer language.

That's certainly one area of conflict.  The funny thing is that there
is really no point in the standard catering to small embedded systems,
because people writing for really tight environments care more about
compactness and speed than portability and standards-compliance.  And
there is always some compactness and speed to be had by foregoing
portability and standards-compliance.  And conversely, they won't be
using general portable libraries, because they are much bigger than
some code specialized for their special case.

> BTW the Lisp world once 
>solved that dilemma by forking to the Scheme and CommonLisp paths.

Scheme is by no means compact or an embedded systems development tool.
It's a Lisp with static scoping.  Later static scoping was integrated
with ideas from other strands of Lisp into Common Lisp, which is a
huge standard, trying to be all things to all people, while Scheme
went more for purity.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
12/30/2013 4:24:31 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>That's not the reason, IMO.  If things were just as broken now as they
>>were before 1983, similar radical change would be needed.
> 
> What breakage in Forth-79 made the change from 0-or-1 to
> 0-or-all-bits-set necessary?

None at all, but I didn't state (or even imply) that it did.  What I
did say is that Forth-79 was so broken that there was no need for
Forth-83 to be compatible with it.

> What breakage in Forth-79 made the changes to PICK and ROLL necessary.
> 
> And what breakage in Forth-79 made it necessary to implement these
> changes as incompatible changes of existing words instead of
> introducing new names?
> 
> Concerning the brokenness of "before 1983", what was broken how?  IIRC
> Elizabeth Rather once claimed that Forth-79 was contradictory, but she
> did not point to any concrete problems and neither do you.

IIRC, Forth-79 didn't succeed in capturing the consensus of the Forth
vendors and implementors.  It was, at best, a stopgap affair, and it
mandated some things (i.e. 16-bit addresses) that were obviously wrong
by 1983.  Some Forth vendors had already looked at changing the form
of a well-formed flag from 1 to all 1s, and weren't going to let
Forth-79 stop them.  Given that breaking changes were inevitable,
there was no point inventing new names for zero-based PICK and ROLL .

Andrew.
0
Andrew
12/30/2013 4:41:26 PM
"Rod Pemberton" <dont_use_email@xnohavenotit.cnm> writes:
>Using "all bits set" for a TRUE flag allows a high-level language
>to have both logical and binary operations, while only needing the
>processor to support simple binary operations, such as AND OR XOR.

AND OR XOR also work for 0-or-1 flags.  Only INVERT (which did not
exist in Forth-79) does not work as a NOT for 0-or-1 flags; but we
have 0= in Forth-79, Forth-83, Forth-94, and Forth-2012.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
12/30/2013 4:46:28 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> AKK <akk@nospam.org> writes:
>>IMO Forth's evolution is blocked because of some wanting it to stay the 
>>ultimate compact embedded systems development tool, whereas others 
>>wanting it to be a powerful computer language.
> 
> That's certainly one area of conflict.  The funny thing is that there
> is really no point in the standard catering to small embedded systems,
> because people writing for really tight environments care more about
> compactness and speed than portability and standards-compliance.

Ah, but even in the small-system embedded world there's a lot to be
said for standard languages, even if only as a point of departure.
You can always say "CORE except X, Y, and Z."  It's still useful.
Standardization is not an all-or-nothing.

Andrew.
0
Andrew
12/30/2013 5:18:08 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Hans Bezemer <the.beez.speaks@gmail.com> wrote:
>> Forth-83 is where Forth IMHO went wrong. [ ... ]
>> 
>> What people essentially did in Forth-83 was to strip most/some/all
>> intuitive concepts of Forth and turn it into a somewhat glorified
>> assembler. "falling through" in a loop concept like
>> DO..LOOP. Turning "true" into an "all bits set" value - just because
>> you could do some obfuscated binary tricks with it. I can forgive
>> them for PICK and ROLL because no Forther in his right mind would
>> use these.
>
>Some of the big changes were essential, though: we couldn't live with
>16-bit threaded code forever.

But according to the Forth-94 document Forth-83 did require threaded
code, so this essential change was not in Forth-83.  And Forth-83
certainly assumed 16 bits and did not provide CELLS and CELL+ for
writing code that is portable between cell sizes.  These are all
Forth-94 innovations, and Forth-94 achieved them without breaking
existing code.

>  The 83-standard DO..LOOP was
>undoubtedly a mistake,

In which way?

> but what possible damage did "all bits set" do?

It broke existing code.

What benefit did it have?  A pretty minor one IMO.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
12/30/2013 5:21:07 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> The funny thing is that there
>> is really no point in the standard catering to small embedded systems,
>> because people writing for really tight environments care more about
>> compactness and speed than portability and standards-compliance.
>
>Ah, but even in the small-system embedded world there's a lot to be
>said for standard languages, even if only as a point of departure.
>You can always say "CORE except X, Y, and Z."  It's still useful.

Sure, but you don't need a small standard for doing that.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
12/30/2013 5:32:17 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>That's not the reason, IMO.  If things were just as broken now as they
>>>were before 1983, similar radical change would be needed.
>> 
>> What breakage in Forth-79 made the change from 0-or-1 to
>> 0-or-all-bits-set necessary?
>
>None at all, but I didn't state (or even imply) that it did.  What I
>did say is that Forth-79 was so broken that there was no need for
>Forth-83 to be compatible with it.
....
>IIRC, Forth-79 didn't succeed in capturing the consensus of the Forth
>vendors and implementors.

Maybe not, but neither did Forth-83:  Many vendors and implementors
stayed with Forth-79.  The amount of damage that the incompatibilities
of Forth-83 did to the popularity of Forth probably is huge.

> It was, at best, a stopgap affair, and it
>mandated some things (i.e. 16-bit addresses) that were obviously wrong
>by 1983.

And yet Forth-83 also mandated 16-bit addresses.  Don't claim
Forth-94's merits on Forth-83.

>Some Forth vendors had already looked at changing the form
>of a well-formed flag from 1 to all 1s, and weren't going to let
>Forth-79 stop them.

So what?  There are always non-standard implementations.  A well-known
implementor names exclusive or OR and does not let any standard (all
of which define OR as bitwise (inclusive) or) stop him.  That's no
good reason to make incompatible changes in a standard.

>  Given that breaking changes were inevitable,

What breaking changes that Forth-83 introduced were inevitable?
Remember: not mandating 16-bit cells was not one of them.  And not
mandating 16-bit cells in Forth-94 did not break existing code.

>there was no point inventing new names for zero-based PICK and ROLL .

There was no point in zero-based PICK and ROLL.  But if you want them,
by all means give them a new name, and all the other incompatible
words as well.  That's the approach Forth-94 took, and that approach
worked well.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
12/30/2013 5:50:08 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Hans Bezemer <the.beez.speaks@gmail.com> wrote:
>>> Forth-83 is where Forth IMHO went wrong. [ ... ]
>>> 
>>> What people essentially did in Forth-83 was to strip most/some/all
>>> intuitive concepts of Forth and turn it into a somewhat glorified
>>> assembler. "falling through" in a loop concept like
>>> DO..LOOP. Turning "true" into an "all bits set" value - just because
>>> you could do some obfuscated binary tricks with it. I can forgive
>>> them for PICK and ROLL because no Forther in his right mind would
>>> use these.
>>
>>Some of the big changes were essential, though: we couldn't live with
>>16-bit threaded code forever.
> 
> But according to the Forth-94 document Forth-83 did require threaded
> code, so this essential change was not in Forth-83. 
> And Forth-83 certainly assumed 16 bits and did not provide CELLS and
> CELL+ for writing code that is portable between cell sizes.  These
> are all Forth-94 innovations, and Forth-94 achieved them without
> breaking existing code.

It did not.  Any existing code which assumed that CELLS = 2* was
broken, and there was lots and lots of such code.

>>The 83-standard DO..LOOP was undoubtedly a mistake,
> 
> In which way?

Surely we've been over this many times before.  The 83-standard
DO..LOOP is hard to describe and hard to understand, and has hideously
bad behaviour with 0 0 DO.  It was only accepted because at the time
it was easily implemented with a neat trick involving the overflow
flag, and it worked equally well for signed and unsigned loops.  That
neat trick often doesn't help make things faster if a loop uses I
once, and if it uses I more than once it's actually a disadvantage.
The DO..LOOP used by Forth, Inc was much cleaner, and there were two
versions, one for signed and one for unsigned loops.  It didn't have
the pathological behaviour of the 83-standard loop.

>> but what possible damage did "all bits set" do?
> 
> It broke existing code.

Sure, but I don't think that matters now.  The consensus at the time
was that the important thing was to get things right, even if doing so
broke code.  That was irrelevant anyway because the vendors had
incompatible dialects.

Andrew.
0
Andrew
12/30/2013 6:03:39 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> The funny thing is that there
>>> is really no point in the standard catering to small embedded systems,
>>> because people writing for really tight environments care more about
>>> compactness and speed than portability and standards-compliance.
>>
>>Ah, but even in the small-system embedded world there's a lot to be
>>said for standard languages, even if only as a point of departure.
>>You can always say "CORE except X, Y, and Z."  It's still useful.
> 
> Sure, but you don't need a small standard for doing that.

You need a reasonably small CORE for that really to be useful.  All
the other packages matter not at all, unless you intend to print it
out.

Andrew.
0
Andrew
12/30/2013 6:05:11 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Hans Bezemer <the.beez.speaks@gmail.com> wrote:
>>>> Forth-83 is where Forth IMHO went wrong. [ ... ]
>>>> 
>>>> What people essentially did in Forth-83 was to strip most/some/all
>>>> intuitive concepts of Forth and turn it into a somewhat glorified
>>>> assembler. "falling through" in a loop concept like
>>>> DO..LOOP. Turning "true" into an "all bits set" value - just because
>>>> you could do some obfuscated binary tricks with it. I can forgive
>>>> them for PICK and ROLL because no Forther in his right mind would
>>>> use these.
>>>
>>>Some of the big changes were essential, though: we couldn't live with
>>>16-bit threaded code forever.
>> 
>> But according to the Forth-94 document Forth-83 did require threaded
>> code, so this essential change was not in Forth-83. 
>> And Forth-83 certainly assumed 16 bits and did not provide CELLS and
>> CELL+ for writing code that is portable between cell sizes.  These
>> are all Forth-94 innovations, and Forth-94 achieved them without
>> breaking existing code.
>
>It did not.  Any existing code which assumed that CELLS = 2* was
>broken, and there was lots and lots of such code.

It was not broken, just not compliant.  Such code still worked on
Forth-94 systems with 16-bit cells.

In contrast, the changes from Forth-79 to Forth-83 broke existing
code.  Code that used, e.g., C@ NOT that worked on Forth-79 did not
work on any Forth-83 compliant system, and no Forth-83 compliant
system can be written to make such Forth-79 compliant code work.

>>> but what possible damage did "all bits set" do?
>> 
>> It broke existing code.
>
>Sure, but I don't think that matters now.

It matters for answering the question what damage it did do.  And it
matters now because it is an example of how not to standarize, not
then and not now.

>The consensus at the time
>was that the important thing was to get things right, even if doing so
>broke code.

That may have been the consensus among the Forth-83 committee, but it
obviously was not the consensus of the wider community.

>That was irrelevant anyway because the vendors had
>incompatible dialects.

That was also the case in Forth-94 and the Forth-200x effort, and
Forth-94 managed to avoid the mistakes that Forth-83 made, and
Forth-200x followed Forth-94's excellent example.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
12/30/2013 6:09:56 PM
On 12/30/13 6:41 AM, Andrew Haley wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> That's not the reason, IMO.  If things were just as broken now as they
>>> were before 1983, similar radical change would be needed.
>>
>> What breakage in Forth-79 made the change from 0-or-1 to
>> 0-or-all-bits-set necessary?
>
> None at all, but I didn't state (or even imply) that it did.  What I
> did say is that Forth-79 was so broken that there was no need for
> Forth-83 to be compatible with it.
>
>> What breakage in Forth-79 made the changes to PICK and ROLL necessary.
>>
>> And what breakage in Forth-79 made it necessary to implement these
>> changes as incompatible changes of existing words instead of
>> introducing new names?
>>
>> Concerning the brokenness of "before 1983", what was broken how?  IIRC
>> Elizabeth Rather once claimed that Forth-79 was contradictory, but she
>> did not point to any concrete problems and neither do you.
>
> IIRC, Forth-79 didn't succeed in capturing the consensus of the Forth
> vendors and implementors.  It was, at best, a stopgap affair, and it
> mandated some things (i.e. 16-bit addresses) that were obviously wrong
> by 1983.  Some Forth vendors had already looked at changing the form
> of a well-formed flag from 1 to all 1s, and weren't going to let
> Forth-79 stop them.  Given that breaking changes were inevitable,
> there was no point inventing new names for zero-based PICK and ROLL .

As Anton pointed out earlier, FORTH83 still mandated 16-bit, 
threaded-code implementation, even though 32-bit processors were coming 
out. It relaxed the implementation restrictions of Forth 79 to allow any 
kind of threaded code, but it did not fully allow compilation to native 
machine code (this was not specifically prohibited, but rather was an 
indirect consequence of another provision).

The main difficulty with Forth79 was that it was very brief and 
incomplete, and didn't address a lot of issues, although I'd have to 
find a copy (not easy!) and read it to dig out what the particular 
issues were.

One of the very first things that the ANS Forth TC did was to attack the 
problem of specifying cell size. I am proud to say I wrote the proposals 
that did this, including using the term "cell" (the standard industry 
term for this was "word" but that had obvious problems in Forth).

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."
==================================================
0
Elizabeth
12/30/2013 6:14:24 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>That's not the reason, IMO.  If things were just as broken now as they
>>>>were before 1983, similar radical change would be needed.
>>> 
>>> What breakage in Forth-79 made the change from 0-or-1 to
>>> 0-or-all-bits-set necessary?
>>
>>None at all, but I didn't state (or even imply) that it did.  What I
>>did say is that Forth-79 was so broken that there was no need for
>>Forth-83 to be compatible with it.
> ...
>>IIRC, Forth-79 didn't succeed in capturing the consensus of the Forth
>>vendors and implementors.
> 
> Maybe not, but neither did Forth-83:  Many vendors and implementors
> stayed with Forth-79.  The amount of damage that the incompatibilities
> of Forth-83 did to the popularity of Forth probably is huge.

I doubt that very much, but we'll never know.

>>It was, at best, a stopgap affair, and it mandated some things
>>(i.e. 16-bit addresses) that were obviously wrong by 1983.
> 
> And yet Forth-83 also mandated 16-bit addresses.  Don't claim
> Forth-94's merits on Forth-83.

Fair enough.  I'm not really trying to do that, just pointing out the
deficiences that were there.

>>Some Forth vendors had already looked at changing the form
>>of a well-formed flag from 1 to all 1s, and weren't going to let
>>Forth-79 stop them.
> 
> So what?  There are always non-standard implementations.

Sure, but the idea was to find a consensus, and it made sense at the
time to try to discover what that might be.

> A well-known implementor names exclusive or OR and does not let any
> standard (all of which define OR as bitwise (inclusive) or) stop
> him.  That's no good reason to make incompatible changes in a
> standard.

I would have said that if there is a reasonable expectation that
implementors are going in that direction, it's an excellent reason.
In fact, it's the *best possible* reason.

>>  Given that breaking changes were inevitable,
> 
> What breaking changes that Forth-83 introduced were inevitable?

Some changes were inevitable because Forth-79 handn't been widely
accepted and therefore everyone's code was going to be, to some
extent, broken by something in the standard.

> Remember: not mandating 16-bit cells was not one of them.  And not
> mandating 16-bit cells in Forth-94 did not break existing code.
> 
>>there was no point inventing new names for zero-based PICK and ROLL .
> 
> There was no point in zero-based PICK and ROLL.  But if you want them,
> by all means give them a new name,

Err, we are talking about 1983!  PICK and ROLL hadn't been around for
very long, and 1-based was just stupid (IMVHO, YMMV, &c): Forth is
almost entirely a zero-based language, and it makes no sense for PICK
and ROLL to be an exception.

> and all the other incompatible words as well.  That's the approach
> Forth-94 took, and that approach worked well.

Would that approach have worked in 1983?  There doesn't seem to have
been much appetatit for that at the time, and in any case we'll never
know.

Andrew.
0
Andrew
12/30/2013 6:21:52 PM
Anton Ertl wrote:
> What breakage in Forth-79 made the change from 0-or-1 to
> 0-or-all-bits-set necessary?

> What breakage in Forth-79 made the changes to PICK and ROLL necessary.

> And what breakage in Forth-79 made it necessary to implement these
> changes as incompatible changes of existing words instead of
> introducing new names?

If every new standard was designed solely to be the best langauge you
could come up with, ignoring the past ones (except for when it comes time
to assign word names), would you use inverted 0 or 1 for true? Would you
have PICK and ROLL or PICK and ROLL and PLUCK and TUMBLE?

Would you prefer to write in a better language or a compatible language?

At some point you probably decided the former, unless your first
programming language was Forth. It's probably a question of how much
better does a programming language need to be to overcome the pain of
incompatibility. (Status quo bias?)

At the moment I don't have much written in Forth to be incompatible with,
and so it's a choice between taking advantage of everyone else's work in
the current standard and finding something better but less developed.

Roelf Toxopeus wrote:
> Mr. Moore and others continued on that route, rigorously (and in
> general stay away from here)!

Admittedly, colorForth was my first Forth... and it's the best so far.

Tristan

0
Tristan
12/30/2013 6:29:43 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Hans Bezemer <the.beez.speaks@gmail.com> wrote:
>>>>> Forth-83 is where Forth IMHO went wrong. [ ... ]
>>>>> 
>>>>> What people essentially did in Forth-83 was to strip most/some/all
>>>>> intuitive concepts of Forth and turn it into a somewhat glorified
>>>>> assembler. "falling through" in a loop concept like
>>>>> DO..LOOP. Turning "true" into an "all bits set" value - just because
>>>>> you could do some obfuscated binary tricks with it. I can forgive
>>>>> them for PICK and ROLL because no Forther in his right mind would
>>>>> use these.
>>>>
>>>>Some of the big changes were essential, though: we couldn't live with
>>>>16-bit threaded code forever.
>>> 
>>> But according to the Forth-94 document Forth-83 did require threaded
>>> code, so this essential change was not in Forth-83. 
>>> And Forth-83 certainly assumed 16 bits and did not provide CELLS and
>>> CELL+ for writing code that is portable between cell sizes.  These
>>> are all Forth-94 innovations, and Forth-94 achieved them without
>>> breaking existing code.
>>
>>It did not.  Any existing code which assumed that CELLS = 2* was
>>broken, and there was lots and lots of such code.
> 
> It was not broken, just not compliant.  Such code still worked on
> Forth-94 systems with 16-bit cells.
> 
> In contrast, the changes from Forth-79 to Forth-83 broke existing
> code.  Code that used, e.g., C@ NOT that worked on Forth-79 did not
> work on any Forth-83 compliant system, and no Forth-83 compliant
> system can be written to make such Forth-79 compliant code work.

Sure, but as I have already explained, Forth code at the time was so
vendor-specific that it was going to have to be changed anyway, and
people didn't much port code between Forths, so it didn't really
matter.

>>>> but what possible damage did "all bits set" do?
>>> 
>>> It broke existing code.
>>
>>Sure, but I don't think that matters now.
> 
> It matters for answering the question what damage it did do.

Not really, no.  There's no real evidence that it did any damage.
Simply saying "it broke code!" doesn't really prove anything.

>>The consensus at the time was that the important thing was to get
>>things right, even if doing so broke code.
> 
> That may have been the consensus among the Forth-83 committee, but it
> obviously was not the consensus of the wider community.

"Obviously?"  IIRC Forth-83 was widely used, although there remained a
vocal minority who didn't accept it.  There still is for every Forth
standard.

>>That was irrelevant anyway because the vendors had incompatible
>>dialects.
> 
> That was also the case in Forth-94 and the Forth-200x effort,

Not to the same extent, IIRC.  Forth-83 was good enough, and widely
accepted enough, to be a reasonable basis for Forth-94.

> and Forth-94 managed to avoid the mistakes that Forth-83 made, and
> Forth-200x followed Forth-94's excellent example.

No disagreement there.  However, the situation was entirely different.
I don't think it has any relevance whatsoever to the current
standardization effort.

Andrew.
0
Andrew
12/30/2013 6:43:52 PM
Elizabeth D. Rather <erather@forth.com> wrote:

> The main difficulty with Forth79 was that it was very brief and 
> incomplete, and didn't address a lot of issues, although I'd have to 
> find a copy (not easy!) and read it to dig out what the particular 
> issues were.

I'm looking at it here (I still have my 30-year-old paper copy!) and
it is, as you say, very thin.

Andrew.
0
Andrew
12/30/2013 6:54:39 PM
On Mon, 30 Dec 2013 11:46:28 -0500, Anton Ertl  
<anton@mips.complang.tuwien.ac.at> wrote:

> "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> writes:
>> Using "all bits set" for a TRUE flag allows a high-level language
>> to have both logical and binary operations, while only needing the
>> processor to support simple binary operations, such as AND OR XOR.
>
> AND OR XOR also work for 0-or-1 flags.

Yes, for flags, but not for logical true, when true is defined as
non-zero.  I.e., OR of 2 and 4 will be logical true if true is
defined as non-zero, but OR or 2 and 4 will be 0 for 0-or-1 flags
instead of logical true.


Rod Pemberton
0
Rod
12/30/2013 11:37:35 PM
AKK wrote:
> Am 30.12.2013 07:49, schrieb Paul Rubin:
> > "Elizabeth D. Rather" <erather@forth.com> writes:
> >> Both this one and the truth value were reasonable, it's just that they
> >> broke a lot of code and made a lot of people mad.
> >
> > Yes, this background explains some things.  I had the impression that
> > Forth standardization efforts generally try to stick with documenting
> > existing stuff, rather than introducing new stuff or breaking anything.
> > That's why the change from 1 to 0 surprised me.  It now sounds like they
> > went the "break stuff" route back in 1983 and are still dealing with the
> > repercussions, so they now stay away from that approach.
> >
>
> Well, people back then were young and revolutionary.  ;-)
> Now all Forthers are old and conservative.
>
> IMO Forth's evolution is blocked because of some wanting it to stay the
> ultimate compact embedded systems development tool, whereas others
> wanting it to be a powerful computer language. BTW the Lisp world once
> solved that dilemma by forking to the Scheme and CommonLisp paths.

I think it's wishful thinking to imagine a language based on a stack and RPN
is ever going to compete with languages that operate at a higher level of
abstraction.  Forth places demands on programmers that other languages don't
(and won't) entertain.  The ones you call "young and revolutionary" believed
in Forth - including the propaganda.  As they matured they saw Forth for what
it was - a specialized language which works very well for certain applications.
Most of them moved on.  Evolution works through countless mistakes.  We
don't have the time.  Forth requires intelligent design - which we also lack.



0
Ed
12/31/2013 10:42:03 AM
Rod Pemberton wrote:
> Yes, for flags, but not for logical true, when true is defined as
> non-zero.  I.e., OR of 2 and 4 will be logical true if true is
> defined as non-zero, but OR or 2 and 4 will be 0 for 0-or-1 flags
> instead of logical true.
There is no such concept as "logical true" in ANS AFAIK. Your assumption
concerning all-bits-set ONLY works if at least ONE value is a fully
qualified flag. And there is the pitfall - you have to keep that in mind
all the time. Therefore, I often define those:

: ANY OR 0<> ;
: BOTH 0<> * 0<> ;

These are fully qualified logical operators and return a fully qualified
flag. BTW, they work for either -1 (all-bits-set) and 1. I can't remember
when I had to use a logical XOR.

Hans Bezemer

0
Hans
12/31/2013 10:53:23 AM
Elizabeth D. Rather wrote:
> ...
> The main difficulty with Forth79 was that it was very brief and
> incomplete, and didn't address a lot of issues, although I'd have to
> find a copy (not easy!) and read it to dig out what the particular
> issues were.

ftp://ftp.forth.org/pub/Forth/Literature/fth79std.zip
ftp://ftp.forth.org/pub/Forth/Archive/docs/FTH83STD.ZIP


The following is Ray Duncan's take on Forth-79/83 from "Converting Fig-Forth
to Forth-83" (unexpurgated version, pub. Dr. Dobbs Journal, May 1984).

"Forth has a colorful history compared to most modem  computer languages.
It evolved into its current form within a few years as the result of the
work of one man (Charles Moore), was jealously guarded  as a proprietary
product for quite a few more  years, and came into widespread use only
after a group of volunteer systems programmers created a set of public domain
implementations in 1978. The same programmers founded the Forth Interest Group
(FIG) shortly thereafter.

Flushed by the  success of the FIG implementations, our heroes formed the
Forth Standards Team.  The team was charged with creating a clear specification
for the Forth language that could be used as a reference by both users and systems
vendors. Ignoring the  old engineering adage, "If it works, don't fix it," they
produced the document known as the Forth-79 Standard, which was widely criticized
and then almost as widely ignored.

Back to the drawing boards for the Forth Standards Team. Reconvening in late 1982,
they began the traditionally grueling process of creating a new Standard, which
involves much lobbying, arguing, and infighting. In August 1983, they took a final
vote and approved the Forth-83 Standard document.

Even before Forth-83 hit the streets, it drew hostile comments from many vendors
because it ignored or bypassed a number of important issues (such as reading device
status and 32-bit implementations), was exceedingly vague about vocabularies
(considered a vital feature of the language), and actually redefined the action of
certain keywords and control structures that had been in common use for years - in
essence creating a new language incompatible  with all existing Forth programs.

The reader may well ask how such a Standards document could be created and
approved.  The politics of Forth would make a fascinating subject for a
sociologist's dissertation, but I'm not sure I understand them well enough
to explain them. For the purposes of this article, let us just note that
both the board of directors of FIG and the members of the Forth Standards Team
are self-elected.  Nearly all have been in office since the beginning of FIG,
and their responsiveness and accountability to the membership of FIG (let
alone the general community of Forth vendors and users) is minimal.

With all of its peculiarities, the Forth-83 Standard seems likely to come into
widespread use fairly quickly. The alternative is to stick with Forth-79, which
has major deficiencies, or with fig-FORTH (Forth-78), which has become very dated."




0
Ed
12/31/2013 12:15:32 PM
Ed <invalid@invalid.com> wrote:
> 
> The following is Ray Duncan's take on Forth-79/83 from "Converting Fig-Forth
> to Forth-83" (unexpurgated version, pub. Dr. Dobbs Journal, May 1984).
> 
> Flushed by the success of the FIG implementations, our heroes formed
> the Forth Standards Team.  The team was charged with creating a
> clear specification for the Forth language that could be used as a
> reference by both users and systems vendors. Ignoring the old
> engineering adage, "If it works, don't fix it," they produced the
> document known as the Forth-79 Standard, which was widely criticized
> and then almost as widely ignored.
> 
....
> 
> Even before Forth-83 hit the streets, it drew hostile comments from
> many vendors because it ignored or bypassed a number of important
> issues (such as reading device status and 32-bit implementations),
> was exceedingly vague about vocabularies (considered a vital feature
> of the language), and actually redefined the action of certain
> keywords and control structures that had been in common use for
> years - in essence creating a new language incompatible with all
> existing Forth programs.
> 
> The reader may well ask how such a Standards document could be
> created and approved.  The politics of Forth would make a
> fascinating subject for a sociologist's dissertation, but I'm not
> sure I understand them well enough to explain them. For the purposes
> of this article, let us just note that both the board of directors
> of FIG and the members of the Forth Standards Team are self-elected.
> Nearly all have been in office since the beginning of FIG, and their
> responsiveness and accountability to the membership of FIG (let
> alone the general community of Forth vendors and users) is minimal.
> 
> With all of its peculiarities, the Forth-83 Standard seems likely to
> come into widespread use fairly quickly. The alternative is to stick
> with Forth-79, which has major deficiencies, or with fig-FORTH
> (Forth-78), which has become very dated."

It's hard for me to find much to argue with here, and it matches my
memory well.  However, "the members of the Forth Standards Team are
self-elected" is rather precious.  How else did he think they'd get
the job?

Andrew.
0
Andrew
12/31/2013 1:05:37 PM
On 12/31/13 3:05 AM, Andrew Haley wrote:
> Ed <invalid@invalid.com> wrote:
>>
>> The following is Ray Duncan's take on Forth-79/83 from "Converting Fig-Forth
>> to Forth-83" (unexpurgated version, pub. Dr. Dobbs Journal, May 1984).
>>
>> Flushed by the success of the FIG implementations, our heroes formed
>> the Forth Standards Team.  The team was charged with creating a
>> clear specification for the Forth language that could be used as a
>> reference by both users and systems vendors. Ignoring the old
>> engineering adage, "If it works, don't fix it," they produced the
>> document known as the Forth-79 Standard, which was widely criticized
>> and then almost as widely ignored.
>>
> ...
>>
>> Even before Forth-83 hit the streets, it drew hostile comments from
>> many vendors because it ignored or bypassed a number of important
>> issues (such as reading device status and 32-bit implementations),
>> was exceedingly vague about vocabularies (considered a vital feature
>> of the language), and actually redefined the action of certain
>> keywords and control structures that had been in common use for
>> years - in essence creating a new language incompatible with all
>> existing Forth programs.
>>
>> The reader may well ask how such a Standards document could be
>> created and approved.  The politics of Forth would make a
>> fascinating subject for a sociologist's dissertation, but I'm not
>> sure I understand them well enough to explain them. For the purposes
>> of this article, let us just note that both the board of directors
>> of FIG and the members of the Forth Standards Team are self-elected.
>> Nearly all have been in office since the beginning of FIG, and their
>> responsiveness and accountability to the membership of FIG (let
>> alone the general community of Forth vendors and users) is minimal.
>>
>> With all of its peculiarities, the Forth-83 Standard seems likely to
>> come into widespread use fairly quickly. The alternative is to stick
>> with Forth-79, which has major deficiencies, or with fig-FORTH
>> (Forth-78), which has become very dated."
>
> It's hard for me to find much to argue with here, and it matches my
> memory well.  However, "the members of the Forth Standards Team are
> self-elected" is rather precious.  How else did he think they'd get
> the job?

I agree that Ray's description is spot on.

As for how Standards Team members are chosen, I will comment that the 
Forth83 group, as well as the Forth79 group, were basically composed of 
whoever showed up, and everyone got a vote regardless of background or 
affiliation. Forth79 was developed in one long weekend on Catalina 
Island, and Forth83 was the result of two meetings about 6 months apart, 
both in California. The last draft was subject to a single up-or-down 
vote, with no opportunity for further consideration or revision.

In addition to the issues we've discussed, I'll give one more example of 
the way that group worked: At the first meeting, it was agreed that we 
should standardize what ' returned and EXECUTE used. It was agreed that 
this should be the address of the Parameter Field of the definition. 
FORTH, Inc. promptly implemented this in our new product line, 
polyFORTH, which attempted to track the standard as much as possible. 
But the next meeting decided, no, it should be the address of the Code 
Field. By this time, it was not really feasible for FORTH, Inc. to make 
so profound a change, so we didn't (although we did adopt as many 
less-profound changes as we could). Some other widely-used systems went 
one way, some another. The attempt to standardize this failed. Forth 94 
correctly decided not to specify implementation at that level of detail, 
and introduced the notion of an xt, which is an opaque object with rules 
of usage.

The ANS Forth effort, in contrast, was developed over 6 years of 4 
multi-day meetings/year, each in a different part of the US (and two in 
Canada), with strict rules from ANSI governing membership and 
representation as well as operation. An organization (such as Forth 
vendors, user organizations, or groups like FIG) could have one member 
and one alternate, but only one vote. Prospective members had to attend 
two consecutive meeting before achieving voting status. Typically, we 
had 12-14 current voting members. Towards the end, Release Candidate 
drafts had to be published and subjected to a 4-month public review 
process. All comments had to be responded to by the TC, and if there 
were *any* technical changes as a result of comments another 4-month 
review was required.

Meetings operated in a two-level process: there was a Technical 
Subcommittee (called the TSC), chaired by Greg Bailey, which thrashed 
out all the technical details of proposals. This group was composed of 
both official TC members and anyone else who chose to attend. As we met 
in diverse geographical areas, we always publicized our meetings and 
welcomed all Forth users. We typically ended up with 6-10 non-TC members 
in addition to the official members. In this way, we got technical input 
from very diverse sources. When the TSC achieved consensus on an issue, 
they brought it to the formal TC, which I chaired, with a recommendation 
for passage or rejection. This group could pass a proposal (in which 
case it went into the next draft), reject it, or refer it back to the 
TSC for further work. All decisions with more than 3 dissenting votes 
were referred back to the TSC.

As a result of this lengthy process, ANS Forth was thoroughly vetted 
both by the TC members and the rest of the Forth community. There were 
no casual decisions that were made at the last minute without review, 
new technology (e.g. CATCH/THROW) was tested thoroughly by multiple 
implementers and users, and all points of view were represented.

Quite a different process. And the result, though far from perfect, was 
much sounder.

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."
==================================================
0
Elizabeth
12/31/2013 7:26:55 PM
Elizabeth D. Rather wrote:
> ...
> As a result of this lengthy process, ANS Forth was thoroughly vetted
> both by the TC members and the rest of the Forth community. There were
> no casual decisions that were made at the last minute without review,
> new technology (e.g. CATCH/THROW) was tested thoroughly by multiple
> implementers and users, and all points of view were represented.

According to M.Bradley's own comments CATCH/THROW was conceived
in a bath tub on the morning of an ANS meeting at which time he floated the
idea.  He was given the nod and told to go away and produce a spec.  That it
all worked out without too many issues may have had more to do with good
luck and Bradley's skills, than anything the TC did.

An example of the blind leading the blind has to be f/p output.  It's plain the
TC had no idea.  Had they stuck with the FVG recommendations it wouldn't
have been so bad.  But that too presented problems since not even the vendors
behind FVG knew how to implement the functions properly.  The "solution"
was a primitive, which no-one had tested except perhaps trivially, and dished
out to forthers along with the near-useless F. FS. FE.

> Quite a different process. And the result, though far from perfect, was
> much sounder.

Certainly ANS was a big effort which required "managing".  The document
itself being an order of magnitude greater than '83.  That said, ANS owed
much to '83.  Whether ANS achieved its goal of putting Forth back on the
map is debatable.  If nothing else, it has provided an endless topic of
conversation :)



0
Ed
1/1/2014 2:27:07 AM
Hans Bezemer wrote:
> ...
> I highly recommend the discipline of converting a non-zero value to a
> well-formed flag.

But surely only if it's necessary.

Consider the situation in which two flags must be tested before continuing.
Under 83/94 there is a high probability one of them will be "fully-formed"
in which case they can simply be ANDed.  One couldn't do that if 'true' was 1.

When I encounter the above situation (which occurs not infrequently), I give
thanks 'true' is all bits set - otherwise I'd have to apply 0<> which would waste
processor time.

Thinking Forth says: 'don't decide, calculate'.  It's acknowledgment that
everything on the stack, including flags, are just numbers to be exploited.







0
Ed
1/1/2014 2:29:41 AM
On 12/31/13 4:27 PM, Ed wrote:
> Elizabeth D. Rather wrote:
>> ...
>> As a result of this lengthy process, ANS Forth was thoroughly vetted
>> both by the TC members and the rest of the Forth community. There were
>> no casual decisions that were made at the last minute without review,
>> new technology (e.g. CATCH/THROW) was tested thoroughly by multiple
>> implementers and users, and all points of view were represented.
>
> According to M.Bradley's own comments CATCH/THROW was conceived
> in a bath tub on the morning of an ANS meeting at which time he floated the
> idea.  He was given the nod and told to go away and produce a spec.  That it
> all worked out without too many issues may have had more to do with good
> luck and Bradley's skills, than anything the TC did.

I'm happy to report that a number of people implemented and used 
CATCH/THROW for over a year before it was finally adopted.

> An example of the blind leading the blind has to be f/p output.  It's plain the
> TC had no idea.  Had they stuck with the FVG recommendations it wouldn't
> have been so bad.  But that too presented problems since not even the vendors
> behind FVG knew how to implement the functions properly.  The "solution"
> was a primitive, which no-one had tested except perhaps trivially, and dished
> out to forthers along with the near-useless F. FS. FE.
>
>> Quite a different process. And the result, though far from perfect, was
>> much sounder.
>
> Certainly ANS was a big effort which required "managing".  The document
> itself being an order of magnitude greater than '83.  That said, ANS owed
> much to '83.  Whether ANS achieved its goal of putting Forth back on the
> map is debatable.  If nothing else, it has provided an endless topic of
> conversation :)

I'm not sure the goal was solely to "put Forth back on the map." The 
primary motivation was to get some amount of portability, not just for 
programs, but most importantly for programmers, by reducing the gulf 
between "dialects". That was very successful. And, certainly, a number 
of very major projects have been able to use Forth because its advocates 
could point to an ANSI standard, to minimize the fears of management.

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."
==================================================
0
Elizabeth
1/1/2014 4:21:52 AM
On Wed, 1 Jan 2014 13:27:07 +1100, "Ed" <invalid@invalid.com> wrote:

>According to M.Bradley's own comments CATCH/THROW was conceived
>in a bath tub on the morning of an ANS meeting at which time he floated the
>idea.  He was given the nod and told to go away and produce a spec.  That it
>all worked out without too many issues may have had more to do with good
>luck and Bradley's skills, than anything the TC did.

The idea for CATCH and THROW came from LISP and other languages, where
CATCH/THROW had been present for many years. No, it wasn't a new idea,
just new to Forth.

>An example of the blind leading the blind has to be f/p output.  It's plain the
>TC had no idea.  Had they stuck with the FVG recommendations it wouldn't
>have been so bad.  But that too presented problems since not even the vendors
>behind FVG knew how to implement the functions properly.

Somebody (preferably with FP skills and knowledge) just has to step
forward.

>Certainly ANS was a big effort which required "managing".

Elizabeth is a very strong manager. Weak management of a standards
body is a problem.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
0
stephenXXX
1/1/2014 12:12:28 PM
In article <l9vuvc$ova$1@speranza.aioe.org>, Ed <invalid@invalid.com> wrote:
>Hans Bezemer wrote:
>> ...
>> I highly recommend the discipline of converting a non-zero value to a
>> well-formed flag.
>
>But surely only if it's necessary.
>
>Consider the situation in which two flags must be tested before continuing.
>Under 83/94 there is a high probability one of them will be "fully-formed"
>in which case they can simply be ANDed.  One couldn't do that if 'true' was 1.

That is the situation where this practice is most dangerous. I don't bother
using IF on the result of a link field, but if you AND while one of the flags
is not proper you may be lulled into believing the result is a well-formed flag.

On the other hand    `` (flag) DUP a OR SWAP INVERT b OR  '' is fast and
idiomatic in my book, whatever Hans says.

>When I encounter the above situation (which occurs not infrequently), I give
>thanks 'true' is all bits set - otherwise I'd have to apply 0<> which
>would waste
>processor time.
>
>Thinking Forth says: 'don't decide, calculate'.  It's acknowledgment that
>everything on the stack, including flags, are just numbers to be exploited.

Agreed with that!

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

0
albert
1/1/2014 2:18:40 PM
Ed wrote:

> But surely only if it's necessary.
I usually DON'T before a test (IF, WHILE). There is a difference between
being "thorough and solid" and "pedantic" ;-) When dealing with the AND and
OR abominations, I very rarely do not.
 
> Consider the situation in which two flags must be tested before
> continuing. Under 83/94 there is a high probability one of them will be
> "fully-formed"
> in which case they can simply be ANDed.  One couldn't do that if 'true'
> was 1.
> 
> When I encounter the above situation (which occurs not infrequently), I
> give thanks 'true' is all bits set - otherwise I'd have to apply 0<> which
> would waste processor time.
I could easily give you situations where 1 has the advantage (as a matter of
fact, I started such an example). However, the basis of my case is not
whether a majority of cases favor one or the other solution - it's how
solid its conceptual foundation is.

> Thinking Forth says: 'don't decide, calculate'.  It's acknowledgment that
> everything on the stack, including flags, are just numbers to be
> exploited.
Very true and a solid principle in itself, I consider this the party trick
department. 

Hans Bezemer

0
Hans
1/1/2014 2:26:05 PM
Albert van der Horst wrote:

> On the other hand    `` (flag) DUP a OR SWAP INVERT b OR  '' is fast and
> idiomatic in my book, whatever Hans says.
I couldn't find a single occurrence of "OR SWAP INVERT" in the entire c.l.f.
Either you haven't posted that much code or it isn't that idiomatic. ;-)

Hans Bezemer
0
Hans
1/1/2014 2:46:30 PM
Andrew Haley wrote:
> Surely we've been over this many times before.  The 83-standard
> DO..LOOP is hard to describe and hard to understand, and has hideously
> bad behaviour with 0 0 DO.  It was only accepted because at the time
> it was easily implemented with a neat trick involving the overflow
> flag, and it worked equally well for signed and unsigned loops.  That
> neat trick often doesn't help make things faster if a loop uses I
> once, and if it uses I more than once it's actually a disadvantage.
> The DO..LOOP used by Forth, Inc was much cleaner, and there were two
> versions, one for signed and one for unsigned loops.  It didn't have
> the pathological behaviour of the 83-standard loop.

Several things in the '83 standard apparently were "trick"-driven. E.g. 
replacing <BUILDS with CREATE: previously, it was considered too difficult 
to implement DOES> with a code-doers header, which is why <BUILDS is there.

Now the trick which was suggested during the Forth-83 discussions is not 
possible everywhere, so the two-cells header returned rather quickly.  To be 
compatible with all Forths from '83 on, you then either need a wasted spare 
second cell in the header (Gforth) or you need to implement that trick (many 
others), even if it is difficult to do.

Or, as some people did it, just go back to <BUILDS and be incompatible.

'83 made some particular ("new") choices for implementation, which aren't 
trick-related but useful.  Using floored division is such an example; though 
actually dividing by a negative number rarely happens - floored by unsigned 
would IMHO have been the better choice.

The -1 true flag also is quite useful.  I remember Andy Glew writing that he 
proposed such a setcc instruction at Intel, and in SSE it finally got in.  
It is more useful than the 1 true flag.

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

0
Bernd
1/1/2014 10:57:12 PM
On 1/1/14 12:57 PM, Bernd Paysan wrote:
....
> Several things in the '83 standard apparently were "trick"-driven. E.g.
> replacing <BUILDS with CREATE: previously, it was considered too difficult
> to implement DOES> with a code-doers header, which is why <BUILDS is there.
>
> Now the trick which was suggested during the Forth-83 discussions is not
> possible everywhere, so the two-cells header returned rather quickly.  To be
> compatible with all Forths from '83 on, you then either need a wasted spare
> second cell in the header (Gforth) or you need to implement that trick (many
> others), even if it is difficult to do.
....

What's the difference between a "trick" and a technique? And when is it 
impossible? We haven't found it to be so, on an incredibly wide number 
of platforms.

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."
==================================================
0
Elizabeth
1/1/2014 11:19:57 PM
Tristan Plumb <firth@trstn.net> writes:
>If every new standard was designed solely to be the best langauge you
>could come up with, ignoring the past ones (except for when it comes time
>to assign word names), would you use inverted 0 or 1 for true?

It seems to me that the true=all-bits-set variant offers some tiny
advantages over the true=1 variant, but that maybe because we have
worked with it for 30 years and have worked out more idioms (OTOH, we
have true=1 in C, so we should have seen the alternative idioms
there).  Probably the most common idiom is stuff like

( flag ) -14 and throw

That could be replaced (at a little cost in performance or compiler
complexity) with

( flag ) -14 * throw

on a 0-or-1 system.

One idiom where true=1 has an advantage is when storing a flag in a
byte.  With true=1 we can just use c! and c@, but with true=-1, we
have to use c@ 0<> to get a well-formed flag again.

Another take on your question: I recently sketched the Forth variant
PAF (for Portable Assembly Forth) where standards compliance is not a
primary concern; for that I decided to go for true=1, because that's
what some architectures offer, whereas none (that I know of) offers
true=-1.  Here's the whole section on that:

| 3.8 Comparison
|
| The words =? <? u<? f=? f<? etc. compare two stack items and return
| 0 for false and 1 for true.  They correspond to the Forth words = <
| u< f= f< etc., with the difference that the Forth words return -1
| (all-bits-set) for true. A number of machines have instructions that
| produce 0 or 1 (MIPS, Alpha, IA-32, AMD64), while for others it is
| as easy to produce 0 or 1 as to produce 0 or -1, so "0 or 1" is more
| in line with the goal of the direct relation to the machine
| feature. An implementation of a 0- or--1 language like Forth would
| use a sequence like <? negate for which good code can be generated
| easily.(5)
|
| (5) Conversely, one might also decide to have < etc. instead of <?
| in PAF, and let the compiler handle the mismatch to some machines,
| but that would be somewhat against the spirit of a portable assembly
| language.

You can read the whole paper on PAF at
<http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-paf.pdf>

Note that I use the name =? instead of = exactly to avoid the Forth-83
mistake.

> Would you
>have PICK and ROLL or PICK and ROLL and PLUCK and TUMBLE?

I don't see any advantages or disadvantages of Forth-79 PICK and ROLL
over the Forth-83 variant, so the decision could go either way.  The
typical use is 2 PICK (or in Forth-79 3 PICK), and I don't see any
advantage of one over the other.

>Would you prefer to write in a better language or a compatible language?

That's a false dichotomy.  By choosing non-conflicting names for the
better features, we can use a better language while staying compatible
with legacy programs.  That's what the Forth-94 committee did and that
is a very successful approach.  That's certainly possible for stuff
like the results of comparisons, and for PICK and ROLL.

For more encompassing features, e.g., type checking, total
compatibility is not possible, but it's still a good idea to avoid
gratuitious incompatibilities.  E.g., for specifying nonprintable
characters in literal strings we decided on a C-like syntax, even
though C is otherwise incompatible with Forth; it simply helps to only
have to learn one set of escape codes if you use both Forth and C (or
any of the other languages that adopted these codes from C).  Of
course the C-haters here hate it.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/2/2014 9:34:23 AM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>> Surely we've been over this many times before.  The 83-standard
>> DO..LOOP is hard to describe and hard to understand, and has hideously
>> bad behaviour with 0 0 DO.  It was only accepted because at the time
>> it was easily implemented with a neat trick involving the overflow
>> flag, and it worked equally well for signed and unsigned loops.  That
>> neat trick often doesn't help make things faster if a loop uses I
>> once, and if it uses I more than once it's actually a disadvantage.
>> The DO..LOOP used by Forth, Inc was much cleaner, and there were two
>> versions, one for signed and one for unsigned loops.  It didn't have
>> the pathological behaviour of the 83-standard loop.
> 
> Several things in the '83 standard apparently were "trick"-driven. E.g. 
> replacing <BUILDS with CREATE: previously, it was considered too difficult 
> to implement DOES> with a code-doers header, which is why <BUILDS is there.

AFAIK that was a Forth, Inc thing: once they was pointed out that
<BUILDS is unnecessary, everyone was happy that a word could be
deleted.

> Now the trick which was suggested during the Forth-83 discussions is
> not possible everywhere, so the two-cells header returned rather
> quickly.  To be compatible with all Forths from '83 on, you then
> either need a wasted spare second cell in the header (Gforth) or you
> need to implement that trick (many others), even if it is difficult
> to do.

Is this a problem for Forth in C, or something like that?

> '83 made some particular ("new") choices for implementation, which
> aren't trick-related but useful.  Using floored division is such an
> example; though actually dividing by a negative number rarely
> happens - floored by unsigned would IMHO have been the better
> choice.

What is "floored by unsigned?"

Andrew.
0
Andrew
1/2/2014 9:41:19 AM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> The funny thing is that there
>>>> is really no point in the standard catering to small embedded systems,
>>>> because people writing for really tight environments care more about
>>>> compactness and speed than portability and standards-compliance.
>>>
>>>Ah, but even in the small-system embedded world there's a lot to be
>>>said for standard languages, even if only as a point of departure.
>>>You can always say "CORE except X, Y, and Z."  It's still useful.
>> 
>> Sure, but you don't need a small standard for doing that.
>
>You need a reasonably small CORE for that really to be useful.

No.  Such a CORE wordset might be a good guidance, but is by no means
necessary; and AFAIK implementors of embedded systems Forth systems
pick and choose among CORE words as well as among others.  E.g.,
>NUMBER, # and friends is not necessarily useful on some embedded
systems, whereas AGAIN might be present.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/2/2014 11:02:52 AM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>It was, at best, a stopgap affair, and it mandated some things
>>>(i.e. 16-bit addresses) that were obviously wrong by 1983.
>> 
>> And yet Forth-83 also mandated 16-bit addresses.  Don't claim
>> Forth-94's merits on Forth-83.
>
>Fair enough.  I'm not really trying to do that, just pointing out the
>deficiences that were there.

So Forth-83 "was, at best, a stopgap affair, and it mandated some
things (i.e. 16-bit addresses) that were obviously wrong by 1983."
And while doing that, it introduced gratuitious incompatibilities.
It's hard to imagine that anything worse could have happened to
standard Forth.

>>>Some Forth vendors had already looked at changing the form
>>>of a well-formed flag from 1 to all 1s, and weren't going to let
>>>Forth-79 stop them.
>> 
>> So what?  There are always non-standard implementations.
>
>Sure, but the idea was to find a consensus, and it made sense at the
>time to try to discover what that might be.

And Forth-83 failed in finding a consensus, at least among the wider
community.

>> A well-known implementor names exclusive or OR and does not let any
>> standard (all of which define OR as bitwise (inclusive) or) stop
>> him.  That's no good reason to make incompatible changes in a
>> standard.
>
>I would have said that if there is a reasonable expectation that
>implementors are going in that direction, it's an excellent reason.
>In fact, it's the *best possible* reason.

So we should have standardized "{" in Forth-200x instead of "{:"?  I
don't think so, and in this case there was not just "reasonable
expectation", but "{" was widely implemented and used; and "{" was not
standardized differently before.

>>>  Given that breaking changes were inevitable,
>> 
>> What breaking changes that Forth-83 introduced were inevitable?
>
>Some changes were inevitable because Forth-79 handn't been widely
>accepted and therefore everyone's code was going to be, to some
>extent, broken by something in the standard.

I cannot follow your reasoning (if there is one).

E.g., Forth-94 LOCALS| has not been widely accepted, either, so
Forth-2012 introduces {: as a better replacement, but that does not
break any programs that use LOCALS|.  It would not even break them if
LOCALS| was de-standardized in Forth-2012: iForth could still have
implemented LOCALS| while being compliant with Forth-2012, and Marcel
Hendrix' programs would still continue to work on iForth.  The
Forth-83 approach would have been to reverse the order of locals in
LOCALS|, and that would really have broken all existing programs that
use LOCALS|.

So no, breaking changes are not in any way inevitable or necessary.

>> Remember: not mandating 16-bit cells was not one of them.  And not
>> mandating 16-bit cells in Forth-94 did not break existing code.
>> 
>>>there was no point inventing new names for zero-based PICK and ROLL .
>> 
>> There was no point in zero-based PICK and ROLL.  But if you want them,
>> by all means give them a new name,
>
>Err, we are talking about 1983!  PICK and ROLL hadn't been around for
>very long, and 1-based was just stupid (IMVHO, YMMV, &c): Forth is
>almost entirely a zero-based language, and it makes no sense for PICK
>and ROLL to be an exception.

PICK and ROLL had been in Forth-79.  Even for things that have not
been standardized like Forth, Inc.'s usage of "{" and the various uses
of PARSE-WORD, we avoided breakage by using new names ("{:" and
PARSE-NAME) in Forth-2012; Forth-83 certainly should have done so for
words that were already standardized and widely implemented and used.

Where is Forth 0-based?  DO has no implied base and there are no array
definition/access words with an implied base, and no other examples
come to my mind at the moment.  Even if you want 0-based, you could
simply define the Forth-79 PICK as (zero-based)

|PICK           n1 -- n2                      240
|     Return the contents of the n1+1-th stack value,  counting n1
|     itself.  An error condition results for n less than one.
|     2 PICK  is equivalent to OVER.  {1..n}

instead of (actual definition)

|PICK           n1 -- n2                      240
|     Return the contents of the n1-th stack value,  not counting n1
|     itself.  An error condition results for n less than one.
|     2 PICK  is equivalent to OVER.  {1..n}


>> and all the other incompatible words as well.  That's the approach
>> Forth-94 took, and that approach worked well.
>
>Would that approach have worked in 1983?

Why not?  Of course it would have been even better to avoid changes
with zero benefit like the one for PICK and ROLL, and changes with
minimal benefit like the true=-1 change in the first place.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/2/2014 11:21:56 AM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> The funny thing is that there is really no point in the standard
>>>>> catering to small embedded systems, because people writing for
>>>>> really tight environments care more about compactness and speed
>>>>> than portability and standards-compliance.
>>>>
>>>>Ah, but even in the small-system embedded world there's a lot to be
>>>>said for standard languages, even if only as a point of departure.
>>>>You can always say "CORE except X, Y, and Z."  It's still useful.
>>> 
>>> Sure, but you don't need a small standard for doing that.
>>
>>You need a reasonably small CORE for that really to be useful.
> 
> No.  Such a CORE wordset might be a good guidance, but is by no means
> necessary; and AFAIK implementors of embedded systems Forth systems
> pick and choose among CORE words as well as among others.  E.g.,
>>NUMBER, # and friends is not necessarily useful on some embedded
> systems, whereas AGAIN might be present.

Understood, but I don't think it removes the need for a reasonably
small CORE.  You might argue that the current notion of CORE is not
ideal for smaller embedded systems, but then we'd have to decide what
we really mean by that.  A system without an interpreter might not
need NUMBER etc, but that's a very different matter.  Small embedded
systems that can run an interative Forth system are still small, and
still relevant.

Andrew.
0
Andrew
1/2/2014 11:48:49 AM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>It was, at best, a stopgap affair, and it mandated some things
>>>>(i.e. 16-bit addresses) that were obviously wrong by 1983.
>>> 
>>> And yet Forth-83 also mandated 16-bit addresses.  Don't claim
>>> Forth-94's merits on Forth-83.
>>
>>Fair enough.  I'm not really trying to do that, just pointing out the
>>deficiences that were there.
> 
> So Forth-83 "was, at best, a stopgap affair, and it mandated some
> things (i.e. 16-bit addresses) that were obviously wrong by 1983."
> And while doing that, it introduced gratuitious incompatibilities.
> It's hard to imagine that anything worse could have happened to
> standard Forth.

You are making a completely ahistorical argument.  At the time, there
were fig-FORTH programs, polyFORTH programs, and so on.  When you
started to write a Forth program, you wrote it for the system you were
using.  Standardization was, at most a tick-box item.  I knew that I
was writing polyFORTH, and if I wanted Forth-83 compatibility I could
load the compatibility words, but I never heard of anyone doing that,
even though I was supporting a fairly large base of users.

>>>>Some Forth vendors had already looked at changing the form
>>>>of a well-formed flag from 1 to all 1s, and weren't going to let
>>>>Forth-79 stop them.
>>> 
>>> So what?  There are always non-standard implementations.
>>
>>Sure, but the idea was to find a consensus, and it made sense at the
>>time to try to discover what that might be.
> 
> And Forth-83 failed in finding a consensus, at least among the wider
> community.

Indeed it did; that's what ANS achieved later.  AFAIK there wasn't any
appetite for perpetuating Forth-79, and trying to apply the reasoning
of the ANS standardization effort to a very different time is
pointless.

>>I would have said that if there is a reasonable expectation that
>>implementors are going in that direction, it's an excellent reason.
>>In fact, it's the *best possible* reason.
> 
> So we should have standardized "{" in Forth-200x instead of "{:"?  I
> don't think so,

And neither do I.

> and in this case there was not just "reasonable expectation", but
> "{" was widely implemented and used; and "{" was not standardized
> differently before.
> 
>>>>  Given that breaking changes were inevitable,
>>> 
>>> What breaking changes that Forth-83 introduced were inevitable?
>>
>>Some changes were inevitable because Forth-79 handn't been widely
>>accepted and therefore everyone's code was going to be, to some
>>extent, broken by something in the standard.
> 
> I cannot follow your reasoning (if there is one).
> 
> E.g., Forth-94 LOCALS| has not been widely accepted, either,

The situation is completely different.  Reasoning that applied to
Forth-79 is irrelevant to Forth-94.  Forth-94 was reasonably
successful, and we have to respect that.

>>Err, we are talking about 1983!  PICK and ROLL hadn't been around for
>>very long, and 1-based was just stupid (IMVHO, YMMV, &c): Forth is
>>almost entirely a zero-based language, and it makes no sense for PICK
>>and ROLL to be an exception.
> 
> PICK and ROLL had been in Forth-79. 

So?

> Where is Forth 0-based?

Pretty much everywhere, as can be seen from a few seconds' reading of
a Forth program.  It's not mandated, but tends to be so.

>>> and all the other incompatible words as well.  That's the approach
>>> Forth-94 took, and that approach worked well.
>>
>>Would that approach have worked in 1983?
> 
> Why not?  Of course it would have been even better to avoid changes
> with zero benefit like the one for PICK and ROLL, and changes with
> minimal benefit like the true=-1 change in the first place.

Well, I note your opinion, but I do not agree.

Andrew.
0
Andrew
1/2/2014 1:08:27 PM
Anton Ertl wrote:
> PICK and ROLL had been in Forth-79.  Even for things that have not
> been standardized like Forth, Inc.'s usage of "{" and the various uses
> of PARSE-WORD, we avoided breakage by using new names ("{:" and
> PARSE-NAME) in Forth-2012; Forth-83 certainly should have done so for
> words that were already standardized and widely implemented and used.

Actually, I don't think we succeeded.  Everybody who used { seems to 
continue to use { instead of {:, it's the de facto standard (and Gforth 
still doesn't implement {:).  Sometimes you have to break someone's code, to 
punish him for not looking out what the majority does with that syntax 
element.  It's non-standard, which not only means you can't rely on it on 
other systems, it also means it might conflict with future standards.

The diversity of Forth systems in the early 1980s was largely due to not 
invented here syndrome, which also made standardization efforts very 
difficult.  We still have that to quite some extent, and it often takes 
years to get implementors to accept useful things (even if simple like the 
relative-to-load-path stuff).  Portability is a discipline which requires 
less ego, and that's particularly a message to those who say that writing 
portable programs requires less ego:  The main ego problem IMHO is the one 
of system implementors.

If you want your system to be ideosyncratic backward compatible by default 
(which MPE obviously wants to, for reasons I won't question: customer 
satisfaction and customer lock-in are worth it), then they should offer a 
compatibility layer that makes the system standard conformant.  E.g. 
switching the decimal points to the standard ones, or loading the preferred 
floating point library.

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

0
Bernd
1/2/2014 3:58:11 PM
On Thu, 02 Jan 2014 16:58:11 +0100, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

>If you want your system to be ideosyncratic backward compatible by default 
>(which MPE obviously wants to, for reasons I won't question: customer 
>satisfaction and customer lock-in are worth it), then they should offer a 
>compatibility layer that makes the system standard conformant.  E.g. 
>switching the decimal points to the standard ones, or loading the preferred 
>floating point library.

I don't know what triggered this rant, but Happy New Year to you too.

We certainly try not to irritate clients. Backward compatibility may
not be important to people with small applications, but it is 
really important to people with big applications.

I have fought the good fight to make floating point input usable
in applications as well as standard Forth source code. Similarly
I tried to make double number entry usable in application code.
In both cases we (MPE) can cope with internationalisation.
With some reluctance, a while back we switched the defaults to
be standards compliant.

As to the defaults floating point pack, the only people who
complain are you and Anton. You are both system implementors
yourselves.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
0
stephenXXX
1/2/2014 4:41:20 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> In contrast, the changes from Forth-79 to Forth-83 broke existing
>> code.  Code that used, e.g., C@ NOT that worked on Forth-79 did not
>> work on any Forth-83 compliant system, and no Forth-83 compliant
>> system can be written to make such Forth-79 compliant code work.
>
>Sure, but as I have already explained, Forth code at the time was so
>vendor-specific that it was going to have to be changed anyway, and
>people didn't much port code between Forths, so it didn't really
>matter.

If they did not port code, why have a standard?  And why would the
code have to be changed anyway?

When you introduce a standard (for the whole language, or for one
particular feature set, like locals in Forth-94), you always have the
situation that the code is vendor-specific.  And a lot of people don't
port their code between language implementations most of the time, so
for them standardization does not matter most of the time.  It's only
when they want to or have to change implementations that they notice.

>Not really, no.  There's no real evidence that it did any damage.

Knowing you, whatever evidence I present, you will always claim it's
not real, so I won't invest any time in this futile exercise.

>> That may have been the consensus among the Forth-83 committee, but it
>> obviously was not the consensus of the wider community.
>
>"Obviously?"  IIRC Forth-83 was widely used, although there remained a
>vocal minority who didn't accept it.  There still is for every Forth
>standard.

There was a vocal minority who did not accept Forth-94 and stuck with
Forth-83?  Who?  I don't remember anyone.

>>>That was irrelevant anyway because the vendors had incompatible
>>>dialects.
>> 
>> That was also the case in Forth-94 and the Forth-200x effort,
>
>Not to the same extent, IIRC.  Forth-83 was good enough, and widely
>accepted enough, to be a reasonable basis for Forth-94.

Going back from Forth-83: PICK ROLL 0< 0= 0> < = > in Forth-79 were
good enough, and widely accepted enough to be a reasonable basis for
these words in Forth-83, but the Forth-83 committee chose to not just
ignore this, but also to use these names for words that behave
differently.

Going forward, vendors had incompatible dialects for locals by the
time the Forth-94 comittee was at work.  Following your argument, they
would have been allowed to change all parts of the language
incompatibly.  Fortunately, they saw the evidence that you deny, and
wisely refrained from repeating this mistake.

The Forth-200x committee found that the LOCALS| syntax introduced by
Forth-94 was not widely accepted.  Following your argument, we would
have been allowed to change all parts of the language incompatibly.
Fortunately, at least some of us saw the evidence that you deny, and
wisely refrained from repeating this mistake.

>> and Forth-94 managed to avoid the mistakes that Forth-83 made, and
>> Forth-200x followed Forth-94's excellent example.
>
>No disagreement there.  However, the situation was entirely different.

The only differences I see are not in the starting situation, but what
the committee made from it: Forth-94 and Forth-200x did not change
already-standardized words incompatibly.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/2/2014 4:52:42 PM
In article <52c594e4.795253800@news.demon.co.uk>,
Stephen Pelc <stephenXXX@mpeforth.com> wrote:
>On Thu, 02 Jan 2014 16:58:11 +0100, Bernd Paysan <bernd.paysan@gmx.de>
>wrote:
>
>>If you want your system to be ideosyncratic backward compatible by default
>>(which MPE obviously wants to, for reasons I won't question: customer
>>satisfaction and customer lock-in are worth it), then they should offer a
>>compatibility layer that makes the system standard conformant.  E.g.
>>switching the decimal points to the standard ones, or loading the preferred
>>floating point library.
>
>I don't know what triggered this rant, but Happy New Year to you too.
>
>We certainly try not to irritate clients. Backward compatibility may
>not be important to people with small applications, but it is
>really important to people with big applications.
>
>I have fought the good fight to make floating point input usable
>in applications as well as standard Forth source code. Similarly
>I tried to make double number entry usable in application code.
>In both cases we (MPE) can cope with internationalisation.
>With some reluctance, a while back we switched the defaults to
>be standards compliant.
>
>As to the defaults floating point pack, the only people who
>complain are you and Anton. You are both system implementors
>yourselves.

I don't follow. What are the complaints about the floating point pack?
Is that the set F+ F- F. .... FSWAP .... FCOS
I never heard anyone complain about that !?

>
>Stephen
>

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

0
albert
1/2/2014 4:54:04 PM
In article <52c05cfd$0$2919$e4fe514c@news2.news.xs4all.nl>,
Hans Bezemer  <the.beez.speaks@gmail.com> wrote:
>
>I would applaud it if Forth would feature some true logical operators,
>because the return values of AND, OR and INVERT are not guaranteed to be
>well-formed flags UNLESS their input were BOTH well-formed flags. Simple
>maintenance can easily introduce subtle bugs which are hard to track. Not
>to mention it obfuscates the intentions of the programmer - like using
>COUNT for C@+.


This can be fixed by trivial preambules:

'COUNT ALIAS C@+

\ In this source module we're going to make a c-like distinction between
\ flags and masks.
'AND ALIAS &
'OR  ALIAS |
: &&  0<> AND 0<> ;
: ||  0<> OR 0<> ;
'AND HIDDEN
'OR HIDDEN

Isn't Forth nice?

>
>I *never ever* use INVERT for inverting a flag - that's what 0= is for.

Actually that is what NOT is for. It is a defect in Forth that we can't
use that name for historic reasons.

>
>Hans Bezemer

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

0
albert
1/2/2014 5:06:28 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Several things in the '83 standard apparently were "trick"-driven. E.g. 
>> replacing <BUILDS with CREATE:

That had already happened in Forth-79.  Forth-79 described <BUILDS in
its reference wordset (i.e., words outside Forth-79), but in it's main
wordset DOES> is described as working with CREATE.

>AFAIK that was a Forth, Inc thing: once they was pointed out that
><BUILDS is unnecessary, everyone was happy that a word could be
>deleted.

Not everybody was happy.  Even relatively recently, somebody
complained about the switch from <BUILDS to CREATE.

>> Now the trick which was suggested during the Forth-83 discussions is
>> not possible everywhere, so the two-cells header returned rather
>> quickly.  To be compatible with all Forths from '83 on, you then
>> either need a wasted spare second cell in the header (Gforth) or you
>> need to implement that trick (many others), even if it is difficult
>> to do.
>
>Is this a problem for Forth in C, or something like that?

Well, how would you implement CREATE...DOES> with ITC and single-cell
code fields portably in C (with labels-as-values)?

>> '83 made some particular ("new") choices for implementation, which
>> aren't trick-related but useful.  Using floored division is such an
>> example; though actually dividing by a negative number rarely
>> happens - floored by unsigned would IMHO have been the better
>> choice.
>
>What is "floored by unsigned?"

My guess is that he means signed-by-unsigned division with floored
result.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/2/2014 6:09:05 PM
On 1/2/14 7:06 AM, Albert van der Horst wrote:
....
>> I *never ever* use INVERT for inverting a flag - that's what 0= is for.
>
> Actually that is what NOT is for. It is a defect in Forth that we can't
> use that name for historic reasons.

Exactly the opposite: NOT was omitted from Forth94 etc. because there 
had been historically two incompatible definitions of it. By not 
standardizing it, we left users free to define NOT for their 
applications in whichever way they prefer. Many applications have a 
"preamble" including generic definitions they'll need; your NOT can be 
included in yours.

The hope of the Forth94 TC was that after some passage of time the air 
would be sufficiently cleared that a new standard could add NOT with 
whatever emerged as the predominant usage.

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."
==================================================
0
Elizabeth
1/2/2014 6:13:56 PM
On 1/2/14 6:52 AM, Anton Ertl wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> In contrast, the changes from Forth-79 to Forth-83 broke existing
>>> code.  Code that used, e.g., C@ NOT that worked on Forth-79 did not
>>> work on any Forth-83 compliant system, and no Forth-83 compliant
>>> system can be written to make such Forth-79 compliant code work.
>>
>> Sure, but as I have already explained, Forth code at the time was so
>> vendor-specific that it was going to have to be changed anyway, and
>> people didn't much port code between Forths, so it didn't really
>> matter.
>
> If they did not port code, why have a standard?  And why would the
> code have to be changed anyway?

In order to make it possible.

> When you introduce a standard (for the whole language, or for one
> particular feature set, like locals in Forth-94), you always have the
> situation that the code is vendor-specific.  And a lot of people don't
> port their code between language implementations most of the time, so
> for them standardization does not matter most of the time.  It's only
> when they want to or have to change implementations that they notice.

That effort was successful. By the late 90's we saw a number of people 
porting whole applications from one Forth to another. Ray Duncan retired 
from Forth to pursue his career in medicine, and turned over his 
customer list to FORTH, Inc.. Many of his customers converted their 
applications, fairly painlessly.

>> Not really, no.  There's no real evidence that it did any damage.
>
> Knowing you, whatever evidence I present, you will always claim it's
> not real, so I won't invest any time in this futile exercise.
>
>>> That may have been the consensus among the Forth-83 committee, but it
>>> obviously was not the consensus of the wider community.
>>
>> "Obviously?"  IIRC Forth-83 was widely used, although there remained a
>> vocal minority who didn't accept it.  There still is for every Forth
>> standard.
>
> There was a vocal minority who did not accept Forth-94 and stuck with
> Forth-83?  Who?  I don't remember anyone.

The ANS Forth TC did a study in the late 80's. The overwhelming majority 
of Forths in use at the time were at least close to Forth83. There were 
a few Forth79 holdouts, and a few ideosyncratic systems that followed no 
particular standard. By staying as close as possible to Forth83 and 
presenting compromises for the most contentious issues, Forth94 achieved 
a very broad consensus. The folks who didn't go with Forth94 were 
typically Forth79 holdouts, FIGforth advocates, and variants like 
JonesForth.

>>>> That was irrelevant anyway because the vendors had incompatible
>>>> dialects.
>>>
>>> That was also the case in Forth-94 and the Forth-200x effort,
>>
>> Not to the same extent, IIRC.  Forth-83 was good enough, and widely
>> accepted enough, to be a reasonable basis for Forth-94.
>
> Going back from Forth-83: PICK ROLL 0< 0= 0> < = > in Forth-79 were
> good enough, and widely accepted enough to be a reasonable basis for
> these words in Forth-83, but the Forth-83 committee chose to not just
> ignore this, but also to use these names for words that behave
> differently.

Yes.

> Going forward, vendors had incompatible dialects for locals by the
> time the Forth-94 comittee was at work.  Following your argument, they
> would have been allowed to change all parts of the language
> incompatibly.  Fortunately, they saw the evidence that you deny, and
> wisely refrained from repeating this mistake.

Actually, the only existing implementation of locals we could find was 
the one in MacForth. That is why its model was adopted, even though a 
lot of people wanted a different order of arguments.

> The Forth-200x committee found that the LOCALS| syntax introduced by
> Forth-94 was not widely accepted.  Following your argument, we would
> have been allowed to change all parts of the language incompatibly.
> Fortunately, at least some of us saw the evidence that you deny, and
> wisely refrained from repeating this mistake.

We felt that designing a whole new locals syntax that was incompatible 
with the only one in fairly widespread use would have been a mistake.

>>> and Forth-94 managed to avoid the mistakes that Forth-83 made, and
>>> Forth-200x followed Forth-94's excellent example.
>>
>> No disagreement there.  However, the situation was entirely different.
>
> The only differences I see are not in the starting situation, but what
> the committee made from it: Forth-94 and Forth-200x did not change
> already-standardized words incompatibly.

And that has been wise.

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."
==================================================
0
Elizabeth
1/2/2014 6:32:37 PM
Elizabeth D. Rather wrote:
> What's the difference between a "trick" and a technique? And when is it
> impossible? We haven't found it to be so, on an incredibly wide number
> of platforms.

The DOES> implementation requires to have a jump into code at the start of 
the DOES> half of the code.  This means that this part must be executable 
code; while the rest of the stuff there is traditionally threaded code, 
which is actually data for the processor.  This is not possible on 
processors which have a very strict separation of code and data (which 
otherwise are 100% fine for indirect threaded code, as code and data are 
otherwise completely separable).  And this is also not possible if you want 
to have a 100% portable implementation which just can't create that 
assembler jump.  Furthermore, there's a third problem: You can't do that 
jump if the code and data is too far away, e.g. on amd64, jumps can only 
cross 32 bits, and data is typically very far away, see this example:

hex  ok
' noop . 7F3E194DB0D8  ok
' noop @ . 405048  ok

You simply can't jump from the data (image) into the code on amd64, so the 
Forth-83 trick is only achievable if you force the data image to be close to 
the code (which is sometimes possible, sometimes not, depending on operating 
system).  Of course, there's the option of going native code... but 
requiring a particular implementation style is no good.  Therefore, we 
actually use the fig-Forth <BUILDS header structure, and waste a cell per 
header that isn't a <BUILDS header.  This workaround is only wasting memory.

The other problem with the CREATE DOES> approach is programming into flash: 
The usual rule is that you can write every flash cell *once*.  So if you do 
<BUILDS you get a header that waits for one DOES> to patch it up.  This is 
fine, as <BUILDS without DOES> doesn't need to be meaningful.  CREATE 
without DOES> however needs to be meaningful, so patching up the code field 
of CREATE is necessary, but (on this class of systems) impossible.

In summary: This was a not-so-well thought through idea, one word less just 
because it works 90% of the time.  A critical language feature must work 
everywhere, without having to resort to ugly workarounds.  IMHO using CREATE 
for <BUILDS is a spec bug.

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

0
Bernd
1/2/2014 6:48:19 PM
In article <SKCdnS7qwtv6MVjPnZ2dnUVZ_sidnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 1/2/14 7:06 AM, Albert van der Horst wrote:
>...
>>> I *never ever* use INVERT for inverting a flag - that's what 0= is for.
>>
>> Actually that is what NOT is for. It is a defect in Forth that we can't
>> use that name for historic reasons.
>
>Exactly the opposite: NOT was omitted from Forth94 etc. because there
>had been historically two incompatible definitions of it. By not
>standardizing it, we left users free to define NOT for their
>applications in whichever way they prefer. Many applications have a
>"preamble" including generic definitions they'll need; your NOT can be
>included in yours.

I stand corrected, we *can* use that name.

I always felt a bit uncomfortable adding
: NOT 0= ;
to the top of my program, but apparently that is okay.
I thought it was frowned upon, because of the possibility of
confusion.

>
>The hope of the Forth94 TC was that after some passage of time the air
>would be sufficiently cleared that a new standard could add NOT with
>whatever emerged as the predominant usage.
>
>Cheers,
>Elizabeth

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

0
albert
1/2/2014 6:59:25 PM
In article <la4c9j$2hk$1@online.de>, Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>Elizabeth D. Rather wrote:
>> What's the difference between a "trick" and a technique? And when is it
>> impossible? We haven't found it to be so, on an incredibly wide number
>> of platforms.
>
>The DOES> implementation requires to have a jump into code at the start of
>the DOES> half of the code.  This means that this part must be executable

That is one view of it. Looking at the standard unburdened with implementation
worries, we see that CREATE builds an object with data and one method, so it is a
data structure with as the first field a pointer that has a default value that
can be overwritten. So it is a kind of methods table with one element.

I can't see why there is a problem there, in this world of methods tables
that can inherited and polymorphed an what not.


>--
>Bernd Paysan
>"If you want it done right, you have to do it yourself"
>http://bernd-paysan.de/
>
-- 
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

0
albert
1/2/2014 7:13:32 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> In contrast, the changes from Forth-79 to Forth-83 broke existing
>>> code.  Code that used, e.g., C@ NOT that worked on Forth-79 did not
>>> work on any Forth-83 compliant system, and no Forth-83 compliant
>>> system can be written to make such Forth-79 compliant code work.
>>
>>Sure, but as I have already explained, Forth code at the time was so
>>vendor-specific that it was going to have to be changed anyway, and
>>people didn't much port code between Forths, so it didn't really
>>matter.
> 
> If they did not port code, why have a standard?

Because it was thought that portability, both of programmers and
programs, might be useful.

> And why would the code have to be changed anyway?
>
> When you introduce a standard (for the whole language, or for one
> particular feature set, like locals in Forth-94), you always have
> the situation that the code is vendor-specific.  And a lot of people
> don't port their code between language implementations most of the
> time, so for them standardization does not matter most of the time.
> It's only when they want to or have to change implementations that
> they notice.

If their vendor doesn't make incompatrible changes to their Forth,
they'll be fine, but in the end, if the standard succeeds, everyone
will move to it, and everyone will have to make changes to their code.
There's nothing special about Forth in this regard; it happend with
many other langauges, in particular the change from K&R C.

>>Not really, no.  There's no real evidence that it did any damage.
> 
> Knowing you, whatever evidence I present, you will always claim it's
> not real, so I won't invest any time in this futile exercise.

Oh dear, this is my punishment for failing to agree with you.  I'm not
at all sure that it's even possible to show such a thing, let alone
real evidence.  You'd have to run history again.  I do not believe
that anyone cared enough about Forth-79 for it really to matter.

>>> That may have been the consensus among the Forth-83 committee, but it
>>> obviously was not the consensus of the wider community.
>>
>>"Obviously?"  IIRC Forth-83 was widely used, although there remained a
>>vocal minority who didn't accept it.  There still is for every Forth
>>standard.
> 
> There was a vocal minority who did not accept Forth-94 and stuck with
> Forth-83?  Who?

No-one AFAIAA.  However, there is a vocal minority who didn't accept
ANS.

> I don't remember anyone.
> 
>>>>That was irrelevant anyway because the vendors had incompatible
>>>>dialects.
>>> 
>>> That was also the case in Forth-94 and the Forth-200x effort,
>>
>>Not to the same extent, IIRC.  Forth-83 was good enough, and widely
>>accepted enough, to be a reasonable basis for Forth-94.
> 
> Going back from Forth-83: PICK ROLL 0< 0= 0> < = > in Forth-79 were
> good enough, and widely accepted enough to be a reasonable basis for
> these words in Forth-83, but the Forth-83 committee chose to not just
> ignore this, but also to use these names for words that behave
> differently.

That's unquestionably true.

> Going forward, vendors had incompatible dialects for locals by the
> time the Forth-94 comittee was at work.  Following your argument, they
> would have been allowed to change all parts of the language
> incompatibly.

No, because post-ANS, everything changed.  There was now a standard
worth having, and was worth keeping compatibility with.  It was not so
in 1983.

Andrew.
0
Andrew
1/2/2014 7:45:13 PM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Of course, there's the option of going native code...

Yes.

> The other problem with the CREATE DOES> approach is programming into
> flash: The usual rule is that you can write every flash cell *once*.

Err, surely you buffer when generating code for flash, don't you?  Is
this an interactive system where you can only write each flash cell
once or it will catch fire?

> In summary: This was a not-so-well thought through idea, one word
> less just because it works 90% of the time.

Surely that's just what you want.

In the case of the x86_64 large model with separated code and data
spaces and the Harvard architecture, I don't think it's such a big
deal.  Two ways spring to mind:

Implementing DOES> by generating a small stub in the near code
segement, and pointing the code field at it.

Alternatively, the two cell approach can be used, but there's only a
need for the second cell if DOES> is actually used.  If code and data
are separate there's no need for that second cell to be emitted until
DOES> is called.

OK, you might need a spare cell because you're trying to write Forth
in C -- in which case an extra cell is the least of your problems.
But there's no need in general for <BUILDS, and certainly no reason to
burden the majority of systems with it.

Andrew.
0
Andrew
1/2/2014 9:44:01 PM
Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> 
>> Several things in the '83 standard apparently were "trick"-driven. E.g.
>> replacing <BUILDS with CREATE: previously, it was considered too
>> difficult to implement DOES> with a code-doers header, which is why
>> <BUILDS is there.
> 
> AFAIK that was a Forth, Inc thing: once they was pointed out that
> <BUILDS is unnecessary, everyone was happy that a word could be
> deleted.
> 
>> Now the trick which was suggested during the Forth-83 discussions is
>> not possible everywhere, so the two-cells header returned rather
>> quickly.  To be compatible with all Forths from '83 on, you then
>> either need a wasted spare second cell in the header (Gforth) or you
>> need to implement that trick (many others), even if it is difficult
>> to do.
> 
> Is this a problem for Forth in C, or something like that?

There are several reasons not to do it:

1. data and code spaced too far apart to have a jump from data to code (e.g. 
64 bit systems, where the branch instructions all can't branch the entire 
memory space).  Of course, it's always possible to write several 
instructions which are then capable of branching everywhere... first 
concatenating a 64 bit literal, and then jumping to that location...

2. Portable systems (i.e. Forth in C) which don't want to add on-the-fly 
jump generators for each platform

3. Write-once flash programmed systems, because for CREATE DOES> you need to 
write the code field twice.

I have found workarounds against all of those problems, but it's ugly and 
usually at least wastes space.

>> '83 made some particular ("new") choices for implementation, which
>> aren't trick-related but useful.  Using floored division is such an
>> example; though actually dividing by a negative number rarely
>> happens - floored by unsigned would IMHO have been the better
>> choice.
> 
> What is "floored by unsigned?"

Signed double divided by unsigned single cell, round mode: floored.  That's 
what Forth Inc. proposed, and they lost.  This is particularly easy to 
implement if you have an unsigned double/unsigned single division, and it is 
faster than doing the hardware signed division e.g. on Intel (it is faster, 
because all it needs is a conditional add - if you divide d/u, and d is 
negative, just add u to the upper part of d, and then divide unsigned).

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

0
Bernd
1/2/2014 9:58:15 PM
Stephen Pelc wrote:

> On Thu, 02 Jan 2014 16:58:11 +0100, Bernd Paysan <bernd.paysan@gmx.de>
> wrote:
> 
>>If you want your system to be ideosyncratic backward compatible by default
>>(which MPE obviously wants to, for reasons I won't question: customer
>>satisfaction and customer lock-in are worth it), then they should offer a
>>compatibility layer that makes the system standard conformant.  E.g.
>>switching the decimal points to the standard ones, or loading the
>>preferred floating point library.
> 
> I don't know what triggered this rant, but Happy New Year to you too.
> 
> We certainly try not to irritate clients. Backward compatibility may
> not be important to people with small applications, but it is
> really important to people with big applications.

I don't want to irritate my "customers" either (even though they are non-
paying customers), so I keep some things backwards compatible even if I 
consider that no longer a good idea.

> I have fought the good fight to make floating point input usable
> in applications as well as standard Forth source code. Similarly
> I tried to make double number entry usable in application code.
> In both cases we (MPE) can cope with internationalisation.
> With some reluctance, a while back we switched the defaults to
> be standards compliant.

Indeed.  Nearly 20 years after they became standard ;-).

> As to the defaults floating point pack, the only people who
> complain are you and Anton. You are both system implementors
> yourselves.

Ah, come on Stephen, you know what the feedback ratio is, it's not even an 
80/20 rule.  I said to you that you gave me the most valueable feedback for 
Minos, and I'm quite sure that was because you are a system implementor and 
you don't put up with idiocy I implemented, so you complained.  So do we.  
Just listen to every complaint you get, and with every complaint you fix, 
you will improve the satisfaction of another 20 costumers who didn't dare to 
complain.

bigForth didn't load the floating point library by default, either.  The 
only complaint I got was from Anton.  I fixed it, and I'm sure more people 
than Anton were happy with the result.  That's how feedback works.  "Nobody 
complained" is wrong once the first person complains, so it's not an 
argument.

At least 10 years ago we had programmed Lego RCX bricks on a Forth Tagung, 
and we asked Martin Bitter how his students tolerated the bugs in the RCX 
Forth.  He said "they don't know better".  That's the reason why many people 
don't complain.

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

0
Bernd
1/2/2014 10:20:06 PM
Albert van der Horst wrote:

> In article <52c594e4.795253800@news.demon.co.uk>,
>>As to the defaults floating point pack, the only people who
>>complain are you and Anton. You are both system implementors
>>yourselves.
> 
> I don't follow. What are the complaints about the floating point pack?
> Is that the set F+ F- F. .... FSWAP .... FCOS
> I never heard anyone complain about that !?

The complaint is that it isn't loaded by default, that there are three of 
them under names that are nontrivial to guess (it's not just "include 
float.fth" or such), and therefore porting even a very trivial floating 
point program requires system-specific knowledge.

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

0
Bernd
1/2/2014 10:22:48 PM
Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Of course, there's the option of going native code...
> 
> Yes.
> 
>> The other problem with the CREATE DOES> approach is programming into
>> flash: The usual rule is that you can write every flash cell *once*.
> 
> Err, surely you buffer when generating code for flash, don't you?  Is
> this an interactive system where you can only write each flash cell
> once or it will catch fire?

No, buffering is not feasible on a system with just a few hundred bytes of 
RAM available.  You can either erase a flash sector (all FFFF) or you can 
write a flash cell once (flipping 1 bits to 0).  You may be able to flip 
even more bits from 1 to 0 by writing another time, but then it is not 
guaranteed that all 1 bits really stay 1, or stay 1 for as long as they 
would if only written once.

: make-2constant does> 2@ ;
Create foo   3 , foo , make-2constant

is completely legit, so you really have to modify an already working CREATE 
header.  How to modify with a write-once memory?  The solution I found for 
Gforth R8C is to put the dovar doer on an address which has nearly all bits 
1, so it is possible to write them a second time to change it to dodoes.  
And the R8C says you actually can write a flash cell twice without losing 
too much (that's meant for byte-writes; the flash is actually organized in 
words, but Renesas thought it would be good to allow people to write one 
byte after the other).

>> In summary: This was a not-so-well thought through idea, one word
>> less just because it works 90% of the time.
> 
> Surely that's just what you want.
> 
> In the case of the x86_64 large model with separated code and data
> spaces and the Harvard architecture, I don't think it's such a big
> deal.  Two ways spring to mind:
> 
> Implementing DOES> by generating a small stub in the near code
> segement, and pointing the code field at it.
> 
> Alternatively, the two cell approach can be used, but there's only a
> need for the second cell if DOES> is actually used.  If code and data
> are separate there's no need for that second cell to be emitted until
> DOES> is called.

Huh?  The problem is that this cell needs to be *allocated*, for every 
single word (relaxation could be to allocate only for every child of CREATE, 
but that includes VARIABLE).  You need to allocate the second cell and you 
don't know yet if DOES> is called.

> OK, you might need a spare cell because you're trying to write Forth
> in C -- in which case an extra cell is the least of your problems.
> But there's no need in general for <BUILDS, and certainly no reason to
> burden the majority of systems with it.

Defining : <BUILDS CREATE ; is a very small burden for a system, but jumping 
through hoops to get CREATE DOES> implemented on systems that have problems 
is a much bigger burden.

In essence, what you do is to require a particular implementation strategy.  
This is something we don't do, and we agreed not to do.  There are real 
world systems out there that have difficulties or at least considerably 
negative tradeoffs to implement CREATE DOES> and some implementers 
considered it too difficult to do and went back to <BUILDS quite recently.  
Of course, flash memory properties weren't even on the radar 30 years ago, 
and I think they'll fade away when ReRAM is a mass-produced reliable adder 
to many silicon processes.

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

0
Bernd
1/2/2014 10:56:24 PM
Bernd Paysan <bernd.paysan@gmx.de> writes:
> No, buffering is not feasible on a system with just a few hundred bytes of 
> RAM available. 

Is it enough to just buffer a single address in ram at the time of
CREATE, which you'd write to flash if the next definition is seen 
before DOES> or else modified before flashing if DOES> is seen?

Also, for 64-bit systems, why is this even an issue?  Those systems
usually have gigabytes of ram.  A few thousand extra cells allocated to
colon words won't be noticed.
0
Paul
1/2/2014 11:43:43 PM
On Thu, 02 Jan 2014 04:34:23 -0500, Anton Ertl  
<anton@mips.complang.tuwien.ac.at> wrote:

> (OTOH, we have true=1 in C,

No, we don't.

In C, logical "true" is "not false", where "false" is zero.
That applies for all versions of C.

You're referring to the "new" boolean bit-field type: _Bool,
which can be zero or one.  Macro's for 'true' and 'false' as
_Bool are defined in <stdbool.h>.  These were added to C99.
So, use of _Bool types applies to only to C99 C code and later,
when or where used.

_Bool does NOT apply and is NOT used for normal logical
conditions in C.


Rod Pemberton
0
Rod
1/3/2014 1:06:28 AM
On Thu, 02 Jan 2014 14:45:13 -0500, Andrew Haley  
<andrew29@littlepinkcloud.invalid> wrote:

> No, because post-ANS, everything changed.  There was now a
> standard worth having, and was worth keeping compatibility with.

Where's Hugh when you need him?  He hates ANS, yes?


RP
0
Rod
1/3/2014 1:17:55 AM
On 1/2/14 12:56 PM, Bernd Paysan wrote:
> Andrew Haley wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> Of course, there's the option of going native code...
>>
>> Yes.
>>
>>> The other problem with the CREATE DOES> approach is programming into
>>> flash: The usual rule is that you can write every flash cell *once*.
>>
>> Err, surely you buffer when generating code for flash, don't you?  Is
>> this an interactive system where you can only write each flash cell
>> once or it will catch fire?
>
> No, buffering is not feasible on a system with just a few hundred bytes of
> RAM available.  You can either erase a flash sector (all FFFF) or you can
> write a flash cell once (flipping 1 bits to 0).  You may be able to flip
> even more bits from 1 to 0 by writing another time, but then it is not
> guaranteed that all 1 bits really stay 1, or stay 1 for as long as they
> would if only written once.
>
> : make-2constant does> 2@ ;
> Create foo   3 , foo , make-2constant
>
> is completely legit, so you really have to modify an already working CREATE
> header.  How to modify with a write-once memory?  The solution I found for
> Gforth R8C is to put the dovar doer on an address which has nearly all bits
> 1, so it is possible to write them a second time to change it to dodoes.
> And the R8C says you actually can write a flash cell twice without losing
> too much (that's meant for byte-writes; the flash is actually organized in
> words, but Renesas thought it would be good to allow people to write one
> byte after the other).

This is why cross-compilers are so popular for embedded systems.

....

>> OK, you might need a spare cell because you're trying to write Forth
>> in C -- in which case an extra cell is the least of your problems.
>> But there's no need in general for <BUILDS, and certainly no reason to
>> burden the majority of systems with it.
>
> Defining : <BUILDS CREATE ; is a very small burden for a system, but jumping
> through hoops to get CREATE DOES> implemented on systems that have problems
> is a much bigger burden.
>
> In essence, what you do is to require a particular implementation strategy.
> This is something we don't do, and we agreed not to do.  There are real
> world systems out there that have difficulties or at least considerably
> negative tradeoffs to implement CREATE DOES> and some implementers
> considered it too difficult to do and went back to <BUILDS quite recently.
> Of course, flash memory properties weren't even on the radar 30 years ago,
> and I think they'll fade away when ReRAM is a mass-produced reliable adder
> to many silicon processes.

Somehow, the Forth community has managed with CREATE for 20 years. Since 
definition layouts are not mandated (or even described generally) those 
who have to have 2 cells to make CREATE work can, and the rest of us are 
quite happy with one.

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."
==================================================
0
Elizabeth
1/3/2014 1:34:20 AM
Hans Bezemer wrote:
> Ed wrote:
>
> > But surely only if it's necessary.
> I usually DON'T before a test (IF, WHILE). There is a difference between
> being "thorough and solid" and "pedantic" ;-) When dealing with the AND and
> OR abominations, I very rarely do not.
>
> > Consider the situation in which two flags must be tested before
> > continuing. Under 83/94 there is a high probability one of them will be
> > "fully-formed"
> > in which case they can simply be ANDed.  One couldn't do that if 'true'
> > was 1.
> >
> > When I encounter the above situation (which occurs not infrequently), I
> > give thanks 'true' is all bits set - otherwise I'd have to apply 0<> which
> > would waste processor time.
> I could easily give you situations where 1 has the advantage (as a matter of
> fact, I started such an example). However, the basis of my case is not
> whether a majority of cases favor one or the other solution - it's how
> solid its conceptual foundation is.

Forth is empirically based.  It matters whether a majority of cases favour a
particular solution.  It was this that drove the decision to make PICK and
ROLL zero-based - even at the expense of breaking code.  Short-term
pain for long-term gain.  Floored integer division favoured the majority of
cases but completely ignored the reality of hardware division which was
symmetric.  The result - long-term pain.

> > Thinking Forth says: 'don't decide, calculate'.  It's acknowledgment that
> > everything on the stack, including flags, are just numbers to be
> > exploited.
> Very true and a solid principle in itself, I consider this the party trick
> department.

ISTM it can't be both.  Either it's a party trick or an efficient practice,
albeit one wherein only certain languages derive gain.



0
Ed
1/3/2014 2:22:01 AM
Stephen Pelc wrote:
> On Wed, 1 Jan 2014 13:27:07 +1100, "Ed" <invalid@invalid.com> wrote:
>
> >According to M.Bradley's own comments CATCH/THROW was conceived
> >in a bath tub on the morning of an ANS meeting at which time he floated the
> >idea.  He was given the nod and told to go away and produce a spec.  That it
> >all worked out without too many issues may have had more to do with good
> >luck and Bradley's skills, than anything the TC did.
>
> The idea for CATCH and THROW came from LISP and other languages, where
> CATCH/THROW had been present for many years. No, it wasn't a new idea,
> just new to Forth.

The names/concept may have come from LISP but the mechanism and
implementation was Bradley's.  He had to create a spec for ANS where none
previously existed with no experience to speak of.  IMO it was somewhat
over-specified, but that's with hindsight.  I'm happy with just the codes -1, -2
and no-one bothers to save the input source AFAIK.

> >An example of the blind leading the blind has to be f/p output.  It's plain the
> >TC had no idea.  Had they stuck with the FVG recommendations it wouldn't
> >have been so bad.  But that too presented problems since not even the vendors
> >behind FVG knew how to implement the functions properly.
>
> Somebody (preferably with FP skills and knowledge) just has to step
> forward.

That particular problem was eventually solved (to my satisfaction at least).
I mention the case as an example of experts being thrown together at a meeting
and told to come up with a solution.  It began well enough with string versions
of the FVG functions ...

From BASIS 17 (June 1991) :

    12.1.0082    (E.)    "Paren-e-dot-paren"
    ( -- c-addr u )( F: r -- ) or ( r -- c-addr u )

    Convert the top number on the floating-point stack to its character
    string representation using scientific notation;

    <significand><exponent>
    where:
    <significand> := [-]<digit>.<digits0>
    <exponent> := E[-]<digits>

    The exact number of digits to the right of the decimal point in the
    significand is determined by PLACES.

    ...

    12.1.0084    (F.)    "Paren-f-dot-paren"
    ( -- c-addr u )( F: r -- ) or ( r -- c-addr u )

    Convert the top number on the floating-point stack to its character
    string representation using fixed point notation:

    [-] <digit>.<digits0>

    The number of digits after the decimal point is determined by PLACES.

These are essentially what one wants and what most languages since 1950's
Fortran have provided.  For reasons I don't know the TC threw them out,
replacing them with a primitive which even C has since abandoned.

Was REPRESENT ever needed?  IMO it wasn't necessary and the above
functions would have sufficed.  That said, it has made implementing those
functions easier and provided opportunity for niceties.  So while I contend
ANS didn't know what it was doing, by twists and turns it has worked out
for the best.  Weird or what.



0
Ed
1/3/2014 4:59:01 AM
On Friday, January 3, 2014 5:59:01 AM UTC+1, Ed wrote:
[..]
> Was REPRESENT ever needed?  IMO it wasn't necessary and the above
> functions would have sufficed.  That said, it has made implementing those
> functions easier and provided opportunity for niceties.  So while I contend
> ANS didn't know what it was doing, by twists and turns it has worked out
> for the best.  Weird or what.

Checking the iForth distribution for REPRESENT ...

Searching for: REPRESENT
floatest.frt(435): -- Compiler/interpreter: FCONSTANT FVARIABLE FLITERAL REPRESENT
floatest.frt(442): DUP I  FDUP REPRESENT CR
floatest.frt(459): OR  IF ." REPRESENT FAILED" EXIT ENDIF
fpio-test.frt(54): and REPRESENT.
miscutil.frt(1236): target MyPad PRECISION 3 + REPRESENT
miscutil.frt(1260): MyPad 1 REPRESENT 
Found 6 occurrence(s) in 1063 files

Searching for: REPRESENT
C:\dfwforth\examples\ansi\ansify.frt(434): Capitalize: REPRESENT
C:\dfwforth\examples\grayo\gray16.frt(147): \ BITS THAT REPRESENT NO ELEMENTS, MUST BE 0 )
C:\dfwforth\examples\misc\color.frt(1020): std REPRESENT           NONE    fp_ws           dpans12.htm     12.6.1.2143
C:\dfwforth\examples\misc\dispfloats.frt(14): \   Does not catch errors from REPRESENT
C:\dfwforth\examples\misc\dispfloats.frt(25): FBUF PRECISION  REPRESENT DROP SWAP 1-
C:\dfwforth\examples\misc\dztest-float.frt(119): testing REPRESENT
C:\dfwforth\examples\misc\dztest-float.frt(124): significand string produced by REPRESENT for the input len and
C:\dfwforth\examples\misc\dztest-float.frt(127): by REPRESENT, and leave compare?, the significand agreement
C:\dfwforth\examples\misc\dztest-float.frt(132): pad r@ + c@ ABORT" ***REPRESENT writes too many characters." 
C:\dfwforth\examples\misc\dztest-float.frt(135): \ meaning of TEST-REPRESENT neg? output
C:\dfwforth\examples\misc\floatemu.frt(305): \ >FLOAT FLITERAL REPRESENT  F** F. FACOS FACOSH FALOG FASIN FASINH FATAN FATAN2
C:\dfwforth\examples\misc\fpout4.frt(31): \    needed e.g. if REPRESENT always returns flag2=true or
C:\dfwforth\examples\misc\fpout4.frt(34): \ 4. If your REPRESENT does not return an exponent of +1
C:\dfwforth\examples\misc\fpout4.frt(40): \ 5. If your REPRESENT does not blank fill the remainder
C:\dfwforth\examples\misc\fpout4.frt(43): \    displayed.  Again, this is a bug** in your REPRESENT.
C:\dfwforth\examples\misc\fpout4.frt(62): CREATE FBUF             \ REPRESENT buffer
C:\dfwforth\examples\misc\fpout4.frt(71): 0.E0 FBUF 6 REPRESENT 2DROP  \ test REPRESENT
C:\dfwforth\examples\misc\fpout4.frt(77): PL# !  FBUF PRECISION REPRESENT  >R SN# !  1- EX# !
C:\dfwforth\examples\misc\fpout4.frt(84): CR .( Your REPRESENT is buggy and does not return an  )
C:\dfwforth\examples\misc\fpout4.frt(92): \ use this definition if you have a buggy REPRESENT
C:\dfwforth\examples\misc\fpout4.frt(96): FILL  1 0 TRUE  ELSE  FBUF PRECISION  REPRESENT  THEN
C:\dfwforth\examples\simulati\vitl\condense.frt(41): PAD 4 REPRESENT
C:\dfwforth\examples\simulati\vitl\hftl.frt(537): PAD 4 REPRESENT
Found 23 occurrence(s) in 11,213 files 

In about 12,000 files there are only 3 significant occurrences (the rest are
tests). On the other hand, without REPRESENT it would not have been possible 
to build the word F.N1, which I use all of the time.  It should be said
that iForth has (F.) and (E.), driving down use of the cumbersome REPRESENT.
Number formatting is a significant part of most programs I write. 

-marcel
0
mhx
1/3/2014 8:19:02 AM
Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote:
> On Thu, 02 Jan 2014 14:45:13 -0500, Andrew Haley  
> <andrew29@littlepinkcloud.invalid> wrote:
> 
>> No, because post-ANS, everything changed.  There was now a
>> standard worth having, and was worth keeping compatibility with.
> 
> Where's Hugh when you need him?  He hates ANS, yes?

I suppose so, in which case he's one of the vocal minority.

Andrew.
0
Andrew
1/3/2014 10:03:55 AM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
> 
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> Of course, there's the option of going native code...
>> 
>> Yes.
>> 
>>> The other problem with the CREATE DOES> approach is programming into
>>> flash: The usual rule is that you can write every flash cell *once*.
>> 
>> Err, surely you buffer when generating code for flash, don't you?  Is
>> this an interactive system where you can only write each flash cell
>> once or it will catch fire?
> 
> No, buffering is not feasible on a system with just a few hundred bytes of 
> RAM available.  You can either erase a flash sector (all FFFF) or you can 
> write a flash cell once (flipping 1 bits to 0).  You may be able to flip 
> even more bits from 1 to 0 by writing another time, but then it is not 
> guaranteed that all 1 bits really stay 1, or stay 1 for as long as they 
> would if only written once.

So you cross-compile into a buffer, surely.  That's perfectly usual on
such a small system, for all sorts of reasons.
 
>>> In summary: This was a not-so-well thought through idea, one word
>>> less just because it works 90% of the time.
>> 
>> Surely that's just what you want.
>> 
>> In the case of the x86_64 large model with separated code and data
>> spaces and the Harvard architecture, I don't think it's such a big
>> deal.  Two ways spring to mind:
>> 
>> Implementing DOES> by generating a small stub in the near code
>> segement, and pointing the code field at it.
>> 
>> Alternatively, the two cell approach can be used, but there's only a
>> need for the second cell if DOES> is actually used.  If code and data
>> are separate there's no need for that second cell to be emitted until
>> DOES> is called.
> 
> Huh?  The problem is that this cell needs to be *allocated*, for every 
> single word (relaxation could be to allocate only for every child of CREATE, 
> but that includes VARIABLE).  You need to allocate the second cell and you 
> don't know yet if DOES> is called.

You are allocating in two spaces, one code and one data.  You need two
pointers from code space, one pointing into to the code after DOES>
and one to the data.  One a pure Harvard architecture you're going to
need two pointers for CREATE too, I would have thought.

>> OK, you might need a spare cell because you're trying to write Forth
>> in C -- in which case an extra cell is the least of your problems.
>> But there's no need in general for <BUILDS, and certainly no reason to
>> burden the majority of systems with it.
> 
> Defining : <BUILDS CREATE ; is a very small burden for a system, but
> jumping through hoops to get CREATE DOES> implemented on systems
> that have problems is a much bigger burden.

But it's only a burden *to them*.  Let the people with the odd systems
shoulder that burden; it's not a great burden, and is a direct
consequence of the weird architecture.

Andrew.
0
Andrew
1/3/2014 10:14:22 AM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> Several things in the '83 standard apparently were "trick"-driven. E.g. 
>>> replacing <BUILDS with CREATE:
> 
> That had already happened in Forth-79.  Forth-79 described <BUILDS in
> its reference wordset (i.e., words outside Forth-79), but in it's main
> wordset DOES> is described as working with CREATE.
> 
>>AFAIK that was a Forth, Inc thing: once they was pointed out that
>><BUILDS is unnecessary, everyone was happy that a word could be
>>deleted.
> 
> Not everybody was happy.  Even relatively recently, somebody
> complained about the switch from <BUILDS to CREATE.

There's always somebody.  OK, "to a first-order approximation,
everybody".

>>> Now the trick which was suggested during the Forth-83 discussions is
>>> not possible everywhere, so the two-cells header returned rather
>>> quickly.  To be compatible with all Forths from '83 on, you then
>>> either need a wasted spare second cell in the header (Gforth) or you
>>> need to implement that trick (many others), even if it is difficult
>>> to do.
>>
>>Is this a problem for Forth in C, or something like that?
> 
> Well, how would you implement CREATE...DOES> with ITC and single-cell
> code fields portably in C (with labels-as-values)?

I'll take that as "yes".

Andrew.
0
Andrew
1/3/2014 10:16:43 AM
Rod Pemberton wrote:

> In C, logical "true" is "not false", where "false" is zero.
> That applies for all versions of C.
As usual, you forget to mention that C has (I repeat it again) full logical
STANDARDIZED operators like && and ||, so it doesn't care what value "true"
has.

Furthermore, what do you think this renders?

#include <stdio.h>
void main (void)
{
  printf ("%d\n", 2 == 2);
}

Right: 1.

Hans Bezemer


0
Hans
1/3/2014 10:34:53 AM
Ed wrote:

> Forth is empirically based.  It matters whether a majority of cases favour
> a particular solution.  It was this that drove the decision to make PICK
> and ROLL zero-based - even at the expense of breaking code.  Short-term
> pain for long-term gain.  Floored integer division favoured the majority
> of cases but completely ignored the reality of hardware division which was
> symmetric.  The result - long-term pain.
I'd say it is opportunistically based. "Hey, every major system has 16 bits.
Let's make all cells 16 bits." Worst decision EVER! Completely pragmatic
and visionless. "Hey, we can't reach our entire address range with LOOP.
Let's violate sane design so we can." "Hey, we need to work with ordinary
files. Let's completely ignore proper design and glue an entire C library
on top of it." "Hey, we need to define a CORE system. Let's simply see what
we use on an average day and mix our special brew of unsigned, mixed,
double and single words together and call it CORE". And so on, and on and
on. Long term pain - like ordinary program design - is avoided by vision,
architecture and a proper design - not "what feels good at the moment to
the majority". 

> ISTM it can't be both.  Either it's a party trick or an efficient
> practice, albeit one wherein only certain languages derive gain.
An efficient practice has its proper roots in mathematics and architecture.
A party trick is coincidental specific behavior resulting from the
inappropriate use of a datatype or algorithm.

Hans Bezemer

0
Hans
1/3/2014 10:54:02 AM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> No.  Such a CORE wordset might be a good guidance, but is by no means
>> necessary; and AFAIK implementors of embedded systems Forth systems
>> pick and choose among CORE words as well as among others.  E.g.,
>>>NUMBER, # and friends is not necessarily useful on some embedded
>> systems, whereas AGAIN might be present.
>
>Understood, but I don't think it removes the need for a reasonably
>small CORE.  You might argue that the current notion of CORE is not
>ideal for smaller embedded systems, but then we'd have to decide what
>we really mean by that.  A system without an interpreter might not
>need NUMBER etc, but that's a very different matter.  Small embedded
>systems that can run an interative Forth system are still small, and
>still relevant.

I think the problem is that the needs of small embedded systems are
too diverse to be covered by a single CORE (at least if the core has
any size at all).

At EuroForth 2004 there was a workshop on CoreForth, a standard for
small embedded Forth systems (smaller than CORE).  I was asked to
announce this and the mailing list, and I did that
<2004Dec26.163223@mips.complang.tuwien.ac.at>, and that's the last
that I heard of it.  It seems to me that per-system (or
per-application) subsetting of standard Forth is good enough for most
embedded system developers, and most don't see a need for a standard
in this area.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/3/2014 11:00:49 AM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>It was, at best, a stopgap affair, and it mandated some things
>>>>>(i.e. 16-bit addresses) that were obviously wrong by 1983.
>>>> 
>>>> And yet Forth-83 also mandated 16-bit addresses.  Don't claim
>>>> Forth-94's merits on Forth-83.
>>>
>>>Fair enough.  I'm not really trying to do that, just pointing out the
>>>deficiences that were there.
>> 
>> So Forth-83 "was, at best, a stopgap affair, and it mandated some
>> things (i.e. 16-bit addresses) that were obviously wrong by 1983."
>> And while doing that, it introduced gratuitious incompatibilities.
>> It's hard to imagine that anything worse could have happened to
>> standard Forth.
>
>You are making a completely ahistorical argument.  At the time, there
>were fig-FORTH programs, polyFORTH programs, and so on.  When you
>started to write a Forth program, you wrote it for the system you were
>using.  Standardization was, at most a tick-box item.  I knew that I
>was writing polyFORTH, and if I wanted Forth-83 compatibility I could
>load the compatibility words, but I never heard of anyone doing that,
>even though I was supporting a fairly large base of users.

Well that may have been the case for you, which at best undermines
your claim about the success of Forth-83.

I started programming in Forth on a Forth-79 system based on
fig-Forth; there were two books I started with that I bought in 1983:
Winfield's "The complete Forth", which used Forth-79, and Zech's book,
which covered fig-Forth with an Appendix about Forth-79.  From my POV
Forth-79 was widely accepted; maybe Forth, Inc. and their followers
are the vocal minority for Forth-79.

>AFAIK there wasn't any
>appetite for perpetuating Forth-79, and trying to apply the reasoning
>of the ANS standardization effort to a very different time is
>pointless.

Sure, your corner of the Forth world had no interest in Forth-79, but
that was not true for everyone, and there were even people who the
stuck with Forh-79 long after Forth-83 had come out (Elizabeth Rather
called them Forth-79 holdouts).  And the reasoning used in Forth-94
was just as valid in 1983: if Forth-83 had not introduced incompatible
changes, there would have been a smooth transition possible from
Forth-79 to Forth-83, just as there was for Forth-94, and more people
would have made the transition, and there would have been less, if any
Forth-79 holdouts.

>> E.g., Forth-94 LOCALS| has not been widely accepted, either,
>
>The situation is completely different.  Reasoning that applied to
>Forth-79 is irrelevant to Forth-94.  Forth-94 was reasonably
>successful, and we have to respect that.

Forth-79 was reasonably successful, even if not in your corner of the
Forth world.  Forth-94 LOCALS| was less successful IMO than Forth-79.

>>>Err, we are talking about 1983!  PICK and ROLL hadn't been around for
>>>very long, and 1-based was just stupid (IMVHO, YMMV, &c): Forth is
>>>almost entirely a zero-based language, and it makes no sense for PICK
>>>and ROLL to be an exception.
>> 
>> PICK and ROLL had been in Forth-79. 
>
>So?

So Forth-83 should not have defined these names with an incompatible
meaning.  And 4 years was a long time at this stage in Forth
development.

>> Where is Forth 0-based?
>
>Pretty much everywhere, as can be seen from a few seconds' reading of
>a Forth program.  It's not mandated, but tends to be so.

Ok, so Forth is not 0-based.

In any case, however much of a zero fetish someone may have, I really
cannot follow why 2 ROLL should be more fitting for ROT than 3 ROLL.

I have programmed much longer in Forth-83/94 than in Forth-79, and not
used PICK and ROLL much in either standard, yet I still find the
Forth-83 PICK and ROLL strange and the Forth-79 variant more
intuitive.  So I revert my earlier evaluation of PICK and ROLL: there
is a little advantage in intuitiveness for Forth-79's PICK and ROLL
over Forth-83's.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/3/2014 11:13:50 AM
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> PICK and ROLL had been in Forth-79.  Even for things that have not
>> been standardized like Forth, Inc.'s usage of "{" and the various uses
>> of PARSE-WORD, we avoided breakage by using new names ("{:" and
>> PARSE-NAME) in Forth-2012; Forth-83 certainly should have done so for
>> words that were already standardized and widely implemented and used.
>
>Actually, I don't think we succeeded.  Everybody who used { seems to 
>continue to use { instead of {:, it's the de facto standard

Sure, that's a consequence of supporting a smooth transition: There is
not much pressure to make the switch, so the transition is slow.  But
over time it will happen, and then the programs will be portable to
SwiftForth without needing to load extra files, and can be combined
with programs written for SwiftForth.

>(and Gforth still doesn't implement {:).

It would if the transition from CVS to git was as smooth as the
transition from Forth-94 to Forth-2012.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/3/2014 11:56:12 AM
"Elizabeth D. Rather" <erather@forth.com> writes:
>The hope of the Forth94 TC was that after some passage of time the air 
>would be sufficiently cleared that a new standard could add NOT with 
>whatever emerged as the predominant usage.

Nobody has made a proposal on that, and discussions here in the last
few years indicate that we probably won't be able to reach a consensus
on NOT.  One may see that as a problem of the Forth-94 approach, but I
have happily used 0= and (rarely) INVERT for two decades, so not
standardizing NOT is not a real problem.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/3/2014 12:54:48 PM
On Fri, 03 Jan 2014 05:34:53 -0500, Hans Bezemer  
<the.beez.speaks@gmail.com> wrote:
> Rod Pemberton wrote:

>> In C, logical "true" is "not false", where "false" is
>> zero.  That applies for all versions of C.
>
> As usual,

As usual ... ?

Anton said "true=1" in C.  That's simply not true.  (pun intended)

> you forget to mention that C has (I repeat it again) full logical  
> STANDARDIZED operators like && and ||

This has no bearing on the issue.  What I stated above
is true for && and || as well.  The INPUTS to && and ||
are false (0) or true (not false).  The OUTPUTS are
false (0) or true (1).  true (1) is still not false.

> so it doesn't care what value "true"

Exactly, only "false" (zero) is of concern to C.
That is what I stated which you took objection to.

> Furthermore, what do you think this renders?
>
> #include <stdio.h>
> void main (void)
> {
>   printf ("%d\n", 2 == 2);
> }
>
> Right: 1.
>

That doesn't prove true in C is one.  That only proves
that '==' generates a well qualified flag in C for true,
using 1 for true.

#include <stdio.h>

int main(void)
{
   int i;
   for(i=0;i<256;i++)
   {
     if(i)
       printf("true %d\n",i);
     else
       printf("false %d\n",i);
   }

return(0);
}

See, 1, 2, 3, ... etc are all true too.
So, how is "true=1" ... ?


Rod Pemberton
0
Rod
1/3/2014 1:04:03 PM
Ed wrote:
> Forth is empirically based.  It matters whether a majority of cases favour
> a particular solution.  It was this that drove the decision to make PICK
> and ROLL zero-based - even at the expense of breaking code.  Short-term
> pain for long-term gain.  Floored integer division favoured the majority
> of cases but completely ignored the reality of hardware division which was
> symmetric.  The result - long-term pain.

Actually, the pain you pay here is not existing.  Symmetric hardware 
division is actually generated code by the decoder, which uses the internal 
unsigned division algorithm and some conditional code to fix the sign.  If 
you write this down for floored division, it is about as fast as the 
hardware symmetric division.  If you use Forth Inc's floored division 
(divide by unsigned), you are even faster than the symmetric hardware 
division.

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

0
Bernd
1/3/2014 1:07:54 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>>The hope of the Forth94 TC was that after some passage of time the air 
>>would be sufficiently cleared that a new standard could add NOT with 
>>whatever emerged as the predominant usage.
> 
> Nobody has made a proposal on that, and discussions here in the last
> few years indicate that we probably won't be able to reach a consensus
> on NOT.

This is true.  I last raised the issue a year or so ago in the hope
that we could have NOT IF and NOT WHILE back, but no luck.

Andrew.
0
Andrew
1/3/2014 1:19:16 PM
Bernd Paysan <bernd.paysan@gmx.de> writes:
>The other problem with the CREATE DOES> approach is programming into flash: 
>The usual rule is that you can write every flash cell *once*.  So if you do 
><BUILDS you get a header that waits for one DOES> to patch it up.  This is 
>fine, as <BUILDS without DOES> doesn't need to be meaningful.  CREATE 
>without DOES> however needs to be meaningful, so patching up the code field 
>of CREATE is necessary, but (on this class of systems) impossible.

But in standard Forth several DOES> can be used on a CREATEd word; so
DOES>-once is not enough.  Adding an environmental restriction on
DOES>-once probably does not break that many programs, however.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/3/2014 1:28:32 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>It was, at best, a stopgap affair, and it mandated some things
>>>>>>(i.e. 16-bit addresses) that were obviously wrong by 1983.
>>>>> 
>>>>> And yet Forth-83 also mandated 16-bit addresses.  Don't claim
>>>>> Forth-94's merits on Forth-83.
>>>>
>>>>Fair enough.  I'm not really trying to do that, just pointing out the
>>>>deficiences that were there.
>>> 
>>> So Forth-83 "was, at best, a stopgap affair, and it mandated some
>>> things (i.e. 16-bit addresses) that were obviously wrong by 1983."
>>> And while doing that, it introduced gratuitious incompatibilities.
>>> It's hard to imagine that anything worse could have happened to
>>> standard Forth.
>>
>>You are making a completely ahistorical argument.  At the time, there
>>were fig-FORTH programs, polyFORTH programs, and so on.  When you
>>started to write a Forth program, you wrote it for the system you were
>>using.  Standardization was, at most a tick-box item.  I knew that I
>>was writing polyFORTH, and if I wanted Forth-83 compatibility I could
>>load the compatibility words, but I never heard of anyone doing that,
>>even though I was supporting a fairly large base of users.
> 
> Well that may have been the case for you, which at best undermines
> your claim about the success of Forth-83.

I'm not sure about what claim you are referring to.  All think I said
was that it was widely used.

> I started programming in Forth on a Forth-79 system based on
> fig-Forth; there were two books I started with that I bought in
> 1983: Winfield's "The complete Forth", which used Forth-79, and
> Zech's book, which covered fig-Forth with an Appendix about
> Forth-79.  From my POV Forth-79 was widely accepted; maybe Forth,
> Inc. and their followers are the vocal minority for Forth-79.

Maybe, but I don't think so.  At the time, I guess 90% of the Forth
world used fig-FORTH, but in the absence of a survey all we have to go
on is our memories of our own corners.

>>AFAIK there wasn't any appetite for perpetuating Forth-79, and
>>trying to apply the reasoning of the ANS standardization effort to a
>>very different time is pointless.
> 
> Sure, your corner of the Forth world had no interest in Forth-79,
> but that was not true for everyone, and there were even people who
> the stuck with Forh-79 long after Forth-83 had come out (Elizabeth
> Rather called them Forth-79 holdouts).  And the reasoning used in
> Forth-94 was just as valid in 1983: if Forth-83 had not introduced
> incompatible changes, there would have been a smooth transition
> possible from Forth-79 to Forth-83, just as there was for Forth-94,
> and more people would have made the transition, and there would have
> been less, if any Forth-79 holdouts.

There's no way to know.

You can't talk about this without actually considering the documents
themselves.  Forth-79 was a first draft.  (I'm ignoring Forth-78.)
Forth-83 was a decent basis for a real standardization effort but not
ready to be a standard worthy of the name.  The difference between ANS
and Forth-83 is one of night and day.  (All IMO, YMMV, &c.)

> I really cannot follow why 2 ROLL should be more fitting for ROT
> than 3 ROLL.
> 
> I have programmed much longer in Forth-83/94 than in Forth-79, and not
> used PICK and ROLL much in either standard, yet I still find the
> Forth-83 PICK and ROLL strange and the Forth-79 variant more
> intuitive.

OK.  I certainly think that we are into Angels Dancing On The Head Of
A Pin territory by now.

Andrew.
0
Andrew
1/3/2014 1:36:45 PM
Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote:
> On Fri, 03 Jan 2014 05:34:53 -0500, Hans Bezemer  
> <the.beez.speaks@gmail.com> wrote:
>> Rod Pemberton wrote:
> 
>>> In C, logical "true" is "not false", where "false" is
>>> zero.  That applies for all versions of C.
>>
>> As usual,
> 
> As usual ... ?
> 
> Anton said "true=1" in C. 

It is exactly as true as the claim that "true=-1" in Forth. 

Andrew.
0
Andrew
1/3/2014 1:38:58 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>> In contrast, the changes from Forth-79 to Forth-83 broke existing
>>>> code.  Code that used, e.g., C@ NOT that worked on Forth-79 did not
>>>> work on any Forth-83 compliant system, and no Forth-83 compliant
>>>> system can be written to make such Forth-79 compliant code work.
>>>
>>>Sure, but as I have already explained, Forth code at the time was so
>>>vendor-specific that it was going to have to be changed anyway, and
>>>people didn't much port code between Forths, so it didn't really
>>>matter.
>> 
>> If they did not port code, why have a standard?
>
>Because it was thought that portability, both of programmers and
>programs, might be useful.

So it did matter.

>> When you introduce a standard (for the whole language, or for one
>> particular feature set, like locals in Forth-94), you always have
>> the situation that the code is vendor-specific.  And a lot of people
>> don't port their code between language implementations most of the
>> time, so for them standardization does not matter most of the time.
>> It's only when they want to or have to change implementations that
>> they notice.
>
>If their vendor doesn't make incompatrible changes to their Forth,
>they'll be fine, but in the end, if the standard succeeds, everyone
>will move to it, and everyone will have to make changes to their code.

Sure, but a well-designed standard like Forth-94 makes it possible to
have a smooth transition, whereas in a botched standard like Forth-83
the transition was so disruptive that a significant number of systems
and programs did not make it and stuck with Forth-79.

>>>Not really, no.  There's no real evidence that it did any damage.
>> 
>> Knowing you, whatever evidence I present, you will always claim it's
>> not real, so I won't invest any time in this futile exercise.
>
>Oh dear, this is my punishment for failing to agree with you.  I'm not
>at all sure that it's even possible to show such a thing, let alone
>real evidence.

So my expectations are right.  And that's not a punishment, it's just
experience with the way you argue.

>You'd have to run history again.  I do not believe
>that anyone cared enough about Forth-79 for it really to matter.

A number of people cared enough about Forth-79 to stick with it, so it
did matter.

>>>"Obviously?"  IIRC Forth-83 was widely used, although there remained a
>>>vocal minority who didn't accept it.  There still is for every Forth
>>>standard.
>> 
>> There was a vocal minority who did not accept Forth-94 and stuck with
>> Forth-83?  Who?
>
>No-one AFAIAA.  However, there is a vocal minority who didn't accept
>ANS.

Sure, there are people who don't like any standard.

But the Forth-79 implementors and users are not among those.  And yet
a number of them chose to stick with Forth-79 instead of transitioning
to Forth-83, producing the Forth-79 holdouts that Elizabeth Rather
mentioned.  In contrast, the smoother transition that Forth-94 offered
did not produce any Forth-83 holdouts.

>> Going forward, vendors had incompatible dialects for locals by the
>> time the Forth-94 comittee was at work.  Following your argument, they
>> would have been allowed to change all parts of the language
>> incompatibly.
>
>No, because post-ANS, everything changed.  There was now a standard
>worth having, and was worth keeping compatibility with.  It was not so
>in 1983.

Forth-79 was a standard worth keeping compatibility with, certainly
for PICK, ROLL, and the comparison words.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/3/2014 1:43:54 PM
Anton Ertl wrote:
> But in standard Forth several DOES> can be used on a CREATEd word; so
> DOES>-once is not enough.  Adding an environmental restriction on
> DOES>-once probably does not break that many programs, however.

Having such environmental restrictions is fine on embedded systems.  The 
entire dictionary is write-once, so you already have a severe environmental 
restriction.  The resulting program is nonetheless a standard program, i.e. 
you can reuse it on other Forth systems.

Non-harward embedded Forths often have a compile-to-ram and compile-to-rom 
(really flash) switch, and the problem with RAM mode is just the limited 
amount of memory and that it's not persistent.  So maybe the right way to 
propose this into a standard would be to add three words (informal 
description):

RAM ( -- )  CORE EXT
set the dictionary to RAM space (write many, not persistent)

ROM ( -- )  CORE EXT
set the dictionary to ROM/flash space (write once, persistent)

<BUILDS ( "name" -- )  CORE EXT
Create a word header that can be modified with DOES> once.

"name" execution: is undefined until DOES> sets the execution semantics of 
"name".

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

0
Bernd
1/3/2014 2:09:21 PM
"Rod Pemberton" <dont_use_email@xnohavenotit.cnm> writes:
>On Thu, 02 Jan 2014 04:34:23 -0500, Anton Ertl  
><anton@mips.complang.tuwien.ac.at> wrote:
>
>> (OTOH, we have true=1 in C,
>
>No, we don't.
>
>In C, logical "true" is "not false", where "false" is zero.
>That applies for all versions of C.
>
>You're referring to the "new" boolean bit-field type: _Bool,
>which can be zero or one.

No, I am referring to the results of operators that produce flags
(just like the discussion about Forth refers to words that produce
flags; words that consume flags only distinguish between 0 and non-0),
and they produce 0 or 1.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/3/2014 2:17:15 PM
"Ed" <invalid@invalid.com> writes:
>Forth is empirically based.  It matters whether a majority of cases favour a
>particular solution.  It was this that drove the decision to make PICK and
>ROLL zero-based - even at the expense of breaking code.

Please enlighten me about the empirical basis of "zero-based" PICK and
ROLL.

>Short-term
>pain for long-term gain.

Long-term pain for no gain.

>Floored integer division favoured the majority of
>cases but completely ignored the reality of hardware division which was
>symmetric.  The result - long-term pain.

What pain?  Gforth changed division from platform-specific (but
probably symmetric everywhere) to floored (symmetric could be chosen
as a build option), and nobody complained.  The performanc impact was
small even for pure division microbenchmarks:

From <2007Jan26.165751@mips.complang.tuwien.ac.at>

|           development     0.6.2
|        floored symmetric symmetric
|/        194 ms   181 ms    175 ms
|mod      197 ms   181 ms    175 ms
|/mod     193 ms   183 ms    175 ms
|*/       252 ms   250 ms    908 ms
|*/mod    258 ms   259 ms    885 ms
|fm/mod   278 ms   277 ms   1283 ms
|sm/rem   196 ms   196 ms   1215 ms
|um/mod   235 ms   235 ms    693 ms
|m*/     2018 ms  1764 ms   2373 ms

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/3/2014 2:22:13 PM
"Ed" <invalid@invalid.com> writes:
>The names/concept may have come from LISP but the mechanism and
>implementation was Bradley's.  He had to create a spec for ANS where none
>previously existed with no experience to speak of.  IMO it was somewhat
>over-specified, but that's with hindsight.  I'm happy with just the codes -1, -2
>and no-one bothers to save the input source AFAIK.

The saving and restoring of the input source happens elsewhere (and
there is a slight problem in Forth-94 with that), and everybody does
it there.

Concerning the codes, I never use -1 and -2, but I THROW some of the
other standardized codes occassionally.

>From BASIS 17 (June 1991) :
>
>    12.1.0082    (E.)    "Paren-e-dot-paren"
>    ( -- c-addr u )( F: r -- ) or ( r -- c-addr u )
>
>    Convert the top number on the floating-point stack to its character
>    string representation using scientific notation;
>
>    <significand><exponent>
>    where:
>    <significand> := [-]<digit>.<digits0>
>    <exponent> := E[-]<digits>
>
>    The exact number of digits to the right of the decimal point in the
>    significand is determined by PLACES.
>
>    ...
>
>    12.1.0084    (F.)    "Paren-f-dot-paren"
>    ( -- c-addr u )( F: r -- ) or ( r -- c-addr u )
>
>    Convert the top number on the floating-point stack to its character
>    string representation using fixed point notation:
>
>    [-] <digit>.<digits0>
>
>    The number of digits after the decimal point is determined by PLACES.
>
>These are essentially what one wants and what most languages since 1950's
>Fortran have provided.  For reasons I don't know the TC threw them out,
>replacing them with a primitive which even C has since abandoned.
>
>Was REPRESENT ever needed?  IMO it wasn't necessary and the above
>functions would have sufficed.

I have used REPRESENT for implementing F.RDP.  One problem is that
REPRESENT is the Forth variant of the Unix function ecvt(), and there
is no Forth variant of fcvt(), which would also have been useful.  I
managed to work around that, but it's not pretty.

These days ecvt() is not loved much in the Unix community, and
POSIX.1-2008 removed it and recommends using sprintf() instead.  What
is our conclusion from 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 2013: http://www.euroforth.org/ef13/
0
anton
1/3/2014 2:30:21 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Note that I use the name =? instead of = exactly to avoid the Forth-83
> mistake.

I think I understand now. You object to the use of the same words for
differing functionality? I can agree to that, but I would guess people
just didn't think of it. Keeping the old words around in a compatibility
wordset or (better) preface is better than just mixing the improved
features in though.

>>Would you prefer to write in a better language or a compatible language?
> That's a false dichotomy.  By choosing non-conflicting names for the
> better features, we can use a better language while staying compatible
> with legacy programs. ...

> For more encompassing features, e.g., type checking, total
> compatibility is not possible, but it's still a good idea to avoid
> gratuitious incompatibilities.

That is my point. And I would hope that when one creates a better
language, one avoids anything gratuitious.

tristan

0
Tristan
1/3/2014 2:52:51 PM
Rod Pemberton wrote:

> That doesn't prove true in C is one.  That only proves
> that '==' generates a well qualified flag in C for true,
> using 1 for true.
It proves that a well qualified flag in C is 1. And if that is true, the
following must be true as well:

        (1==1) | (1==0) => TRUE
        (1==1) & (1==1) => TRUE
        (1==1) & (1==0) => FALSE

Still, C found it logical to add logical operators. And NOBODY ever said
that conditional flow control in Forth required a well qualified flag. So,
where are you going?

Hans Bezemer

0
Hans
1/3/2014 2:57:54 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>You are making a completely ahistorical argument.  At the time, there
>>>were fig-FORTH programs, polyFORTH programs, and so on.  When you
>>>started to write a Forth program, you wrote it for the system you were
>>>using.  Standardization was, at most a tick-box item.  I knew that I
>>>was writing polyFORTH, and if I wanted Forth-83 compatibility I could
>>>load the compatibility words, but I never heard of anyone doing that,
>>>even though I was supporting a fairly large base of users.
>> 
>> Well that may have been the case for you, which at best undermines
>> your claim about the success of Forth-83.
>
>I'm not sure about what claim you are referring to.  All think I said
>was that it was widely used.

That claim for example.

>> I started programming in Forth on a Forth-79 system based on
>> fig-Forth; there were two books I started with that I bought in
>> 1983: Winfield's "The complete Forth", which used Forth-79, and
>> Zech's book, which covered fig-Forth with an Appendix about
>> Forth-79.  From my POV Forth-79 was widely accepted; maybe Forth,
>> Inc. and their followers are the vocal minority for Forth-79.
>
>Maybe, but I don't think so.  At the time, I guess 90% of the Forth
>world used fig-FORTH

Then Forth-83 should not have broken compatibility with fig-Forth,
either.  And fig-Forth used true=1 (but did not have PICK and ROLL).

>You can't talk about this without actually considering the documents
>themselves.

Ok.  What about the Forth-79 document justifies the change of the
canonical flag from 1 to -1?  And the change of PICK and ROLL?

>> I have programmed much longer in Forth-83/94 than in Forth-79, and not
>> used PICK and ROLL much in either standard, yet I still find the
>> Forth-83 PICK and ROLL strange and the Forth-79 variant more
>> intuitive.
>
>OK.  I certainly think that we are into Angels Dancing On The Head Of
>A Pin territory by now.

Maybe, but then so was the Forth-83 committee.  Except that I don't
propose changing PICK and ROLL, and they did.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/3/2014 3:23:02 PM
On 2014-01-03, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> What about the Forth-79 document justifies the change of the canonical
> flag from 1 to -1?

Everyone might have used 1 for true, but Forth-79 only says is "non-zero
= true". Forth-83 merely added that standard words return all bits set.

Fault them for specifying instead of documenting, but not for creating a
conflict between what the standards said about true.

tristan

0
Tristan
1/3/2014 4:02:33 PM
Andrew Haley wrote:
>> Defining : <BUILDS CREATE ; is a very small burden for a system, but
>> jumping through hoops to get CREATE DOES> implemented on systems
>> that have problems is a much bigger burden.
> 
> But it's only a burden *to them*.  Let the people with the odd systems
> shoulder that burden; it's not a great burden, and is a direct
> consequence of the weird architecture.

I'll remember your argument and will shoot down any complaints from 
something that is specific to the systems you are concerned about ;-).  The 
standard cares about much weirder systems like one's complement, nibble 
addressed systems or such (and IMHO we shouldn't do that, because nobody 
programs for them).  Small controllers with flash for the program memory are 
*the default* in the embedded world - it's *not* a weird architecture, it is 
the state of the art - until ReRAM is ready.  You exclude something very 
popular for Forth systems from the standard, or at least make it quite 
difficult?  Really?

Come on, folks.  People here (Elizabeth) suggested to use cross compiling on 
chips that can't implement CREATE, even though they are fine to use 
interactively without cross compiler when you have <BUILDS.  WTF?  They have 
enough flash to host a system.  Obviously there are other people out there 
who have seen those problems, too, and they decided to go cross compiler or 
umbilical system for those problematic chips, because they just couldn't 
implement a standard Forth on them.  This means the standard is broken.

The complaint about 64 bit systems for sure is that it is mostly 
inconvenient.  It wastes a bit cache space, but only a few percent.  The 
complaint about embedded microcontrollers with flash is that you can't do it 
and have to go to <BUILDS.  The burden for larger systems to have an alias 
of <BUILDS to CREATE is ridiculously small, the burden of small systems to 
implement CREATE properly is much larger.

So far, the question whether small system implementers want to follow the 
standard is usually answered with a "no, because you can't do it".  Some of 
the small chips have weird Harward architectures which can't fit well into a 
standard model.  Others just have troubles implementing CREATE DOES>, and 
maybe want a slimmed down CORE, which is possible, because you are allowed 
to ship parts of CORE just as source to load.  Why exclude those systems?

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

0
Bernd
1/3/2014 4:49:52 PM
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Gforth changed division from platform-specific (but probably symmetric
> everywhere) to floored... and nobody complained.  The performance
> impact was small even for pure division microbenchmarks:

That's probably because of interpreter overhead.  In (compiled) ghc,
`quot` (symmetric) is significantly faster than `mod` (floored), enough
to make a real difference in the running speed of certain programs.
Otherwise quot is ugly and it would sure be nice if cpus implemented
floored division directly.
0
Paul
1/3/2014 5:06:48 PM
Paul Rubin <no.email@nospam.invalid> wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Gforth changed division from platform-specific (but probably symmetric
>> everywhere) to floored... and nobody complained.  The performance
>> impact was small even for pure division microbenchmarks:
> 
> That's probably because of interpreter overhead.  In (compiled) ghc,
> `quot` (symmetric) is significantly faster than `mod` (floored), enough
> to make a real difference in the running speed of certain programs.

I suspect that's an implmentation problem, nothing to do with the
actual machine.

Andrew.
0
Andrew
1/3/2014 5:10:00 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:

>>>>Not really, no.  There's no real evidence that it did any damage.
>>> 
>>> Knowing you, whatever evidence I present, you will always claim it's
>>> not real, so I won't invest any time in this futile exercise.
>>
>>Oh dear, this is my punishment for failing to agree with you.  I'm not
>>at all sure that it's even possible to show such a thing, let alone
>>real evidence.
> 
> So my expectations are right.

Not really, no.  It seems to me that you are saying that you might
have evidence for something that, IMO, it may not be possible for
anyone to have evidence for.  In addition, you say you are going to
withold such evidence because I would claim it's not real.  I think
that some skepticism is justfied.

We have our opinions; they differ.  That is all.

>>> Going forward, vendors had incompatible dialects for locals by the
>>> time the Forth-94 comittee was at work.  Following your argument, they
>>> would have been allowed to change all parts of the language
>>> incompatibly.
>>
>>No, because post-ANS, everything changed.  There was now a standard
>>worth having, and was worth keeping compatibility with.  It was not so
>>in 1983.
> 
> Forth-79 was a standard worth keeping compatibility with, certainly
> for PICK, ROLL, and the comparison words.

The situation with Forth-79 holdouts after Forth-83 was not ideal.  I
accept that.  However, I don't believe it did any great lasting damage
and that it did lead to the first standard worthy of the name, ANS
Forth.  Would it have been possible to get there by some other, less
painful route?  Given the personalities involved, maybe, maybe not.
In hindsight, the ANS path to standardization was exactly what was
needed.

Andrew.
0
Andrew
1/3/2014 5:53:55 PM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>>> Defining : <BUILDS CREATE ; is a very small burden for a system, but
>>> jumping through hoops to get CREATE DOES> implemented on systems
>>> that have problems is a much bigger burden.
>> 
>> But it's only a burden *to them*.  Let the people with the odd systems
>> shoulder that burden; it's not a great burden, and is a direct
>> consequence of the weird architecture.
> 
> I'll remember your argument and will shoot down any complaints from 
> something that is specific to the systems you are concerned about ;-).

Heh.  Touche!  Point taken.  :-)

> The standard cares about much weirder systems like one's complement,
> nibble addressed systems or such (and IMHO we shouldn't do that,
> because nobody programs for them).  Small controllers with flash for
> the program memory are *the default* in the embedded world - it's
> *not* a weird architecture, it is the state of the art - until ReRAM
> is ready.  You exclude something very popular for Forth systems from
> the standard, or at least make it quite difficult?  Really?

Absolutely not.  It only applies to such systems when they are
used in an odd way.

> The complaint about 64 bit systems for sure is that it is mostly
> inconvenient.  It wastes a bit cache space, but only a few percent.
> The complaint about embedded microcontrollers with flash is that you
> can't do it and have to go to <BUILDS.

No, only if you are doing something exceedingly odd: interactively
programming a system, with no cross compiler, with the dictionary in
flash.  Sure, you can do that, but I can't think of any reason that
anyone would do it.  I'm not saying that you're wrong to want to do
that, but I am saying that edge case is not worth standardizing
<BUILDS for.

Andrew.
0
Andrew
1/3/2014 6:03:17 PM
In article <la6png$v0u$1@online.de>, Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>Andrew Haley wrote:
>>> Defining : <BUILDS CREATE ; is a very small burden for a system, but
>>> jumping through hoops to get CREATE DOES> implemented on systems
>>> that have problems is a much bigger burden.
>>
>> But it's only a burden *to them*.  Let the people with the odd systems
>> shoulder that burden; it's not a great burden, and is a direct
>> consequence of the weird architecture.
>
>I'll remember your argument and will shoot down any complaints from
>something that is specific to the systems you are concerned about ;-).  The
>standard cares about much weirder systems like one's complement, nibble
>addressed systems or such (and IMHO we shouldn't do that, because nobody
>programs for them).  Small controllers with flash for the program memory are
>*the default* in the embedded world - it's *not* a weird architecture, it is
>the state of the art - until ReRAM is ready.  You exclude something very
>popular for Forth systems from the standard, or at least make it quite
>difficult?  Really?
>
>Come on, folks.  People here (Elizabeth) suggested to use cross compiling on
>chips that can't implement CREATE, even though they are fine to use
>interactively without cross compiler when you have <BUILDS.  WTF?  They have
>enough flash to host a system.  Obviously there are other people out there
>who have seen those problems, too, and they decided to go cross compiler or
>umbilical system for those problematic chips, because they just couldn't
>implement a standard Forth on them.  This means the standard is broken.
>
>The complaint about 64 bit systems for sure is that it is mostly
>inconvenient.  It wastes a bit cache space, but only a few percent.  The
>complaint about embedded microcontrollers with flash is that you can't do it
>and have to go to <BUILDS.  The burden for larger systems to have an alias
>of <BUILDS to CREATE is ridiculously small, the burden of small systems to
>implement CREATE properly is much larger.
>
>So far, the question whether small system implementers want to follow the
>standard is usually answered with a "no, because you can't do it".  Some of
>the small chips have weird Harward architectures which can't fit well into a
>standard model.  Others just have troubles implementing CREATE DOES>, and
>maybe want a slimmed down CORE, which is possible, because you are allowed
>to ship parts of CORE just as source to load.  Why exclude those systems?

The MSP430 is a system with code in flash and a very small RAM (<256 bytes)
The noforth implementation has CREATE DOES> and I didn't hear Albert Nijhof
complain that it was difficult.
(This is the system that was demonstrated at the German Forth Tagung,
you were there.)

There is a slide explaining the difference between compiling to flash
and ram:
    C, and , work naturally in ROM.
    ALLOT works with here.
o there are consequence of the system being in RAM.

It ends with
"
    DOES> can be used after both types of CREATE.
"

http://home.hccnet.nl/anij/nof/noforth.html

The slides of the presentation are in noforth-beethoven.zip

I used noforth myself for a demonstration where noforth itself
was compiled with gforth on a Raspberry pi, then used to build
a turnkey on the MSP430 that played big ben on the silver
tingle tangle.
I used CREATE DOES> for the note duration, not even realizing that
it was problematic.

P.S. Turnkey-ing and removing a turnkey program are all nicely done.
IMO it is better overall than the German 4e4th.

>
>--
>Bernd Paysan

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

0
albert
1/3/2014 6:19:40 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> No, only if you are doing something exceedingly odd: interactively
> programming a system, with no cross compiler, with the dictionary in
> flash.  Sure, you can do that, but I can't think of any reason that
> anyone would do it.

Is that not normal?  It's what 4e4th, Flashforth, Camelforth, and maybe
others do, I thought.

    "By default, CamelForth/430 will compile source code directly into
    the MSP430's Flash memory. This happens automatically any time the
    Instruction Dictionary Pointer (IDP) is set to a location within
    Flash ROM."  ( http://www.camelforth.com/page.php?8 )
0
Paul
1/3/2014 6:31:47 PM
On 1/3/14 6:02 AM, Tristan Plumb wrote:
> On 2014-01-03, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> What about the Forth-79 document justifies the change of the canonical
>> flag from 1 to -1?
>
> Everyone might have used 1 for true, but Forth-79 only says is "non-zero
> = true". Forth-83 merely added that standard words return all bits set.
>
> Fault them for specifying instead of documenting, but not for creating a
> conflict between what the standards said about true.

"Non-zero = true" for Forth83 and Forth94 etc., as far as words like IF, 
WHILE, and UNTIL are concerned. The issue is what do the comparison 
words (e.g. 0=, <, etc.) return? In all systems prior to Forth83 it was 
1 for TRUE, but after Forth83 it was -1. The correct question is not, 
"what is TRUE" but "what is a well-formed flag returned by the 
comparison operators."

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."
==================================================
0
Elizabeth
1/3/2014 6:54:27 PM
In article <gN2dnTjkOcj4ZlvPnZ2dnUVZ_u-dnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Bernd Paysan <bernd.paysan@gmx.de> wrote:
<SNIP>
>
>> The complaint about 64 bit systems for sure is that it is mostly
>> inconvenient.  It wastes a bit cache space, but only a few percent.
>> The complaint about embedded microcontrollers with flash is that you
>> can't do it and have to go to <BUILDS.
>
>No, only if you are doing something exceedingly odd: interactively
>programming a system, with no cross compiler, with the dictionary in
>flash.  Sure, you can do that, but I can't think of any reason that
>anyone would do it.  I'm not saying that you're wrong to want to do
>that, but I am saying that edge case is not worth standardizing
><BUILDS for.

Well... That is exactly what we're doing with noforth.

Of course you want to do that!
Interactive programming, dictionary available, files ready for the
download, and just type COLD or press a button if it fails, to get
back at your Forth.
Because this is exactly the same as I work with my linux
Forth's, except that I type lina64be or gforth instead of
pressing a button.

No cross compiler to learn! What a relief! Think about the
poor electronics people who have a hard time understanding the
first principles of programming. Cross compilation instead of
"
The LEDS are connected to port 1E.
You can type commands via a serial usb.
Try :  HEX FF 1E C!
Behold all leds go on/Verrek, da's makkelijk.
"

You can't think of any reason? You surely didn't think hard.

And it is not necessary to have <BUILDS. See my other ports.

Really a 5 euro sbc is as powerful as 70's CP/M mainframe
with dual 5" floppies (90 K each).

>
>Andrew.

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

0
albert
1/3/2014 7:19:40 PM
On 1/3/14 9:19 AM, Albert van der Horst wrote:
> In article <gN2dnTjkOcj4ZlvPnZ2dnUVZ_u-dnZ2d@supernews.com>,
> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
> <SNIP>
>>
>>> The complaint about 64 bit systems for sure is that it is mostly
>>> inconvenient.  It wastes a bit cache space, but only a few percent.
>>> The complaint about embedded microcontrollers with flash is that you
>>> can't do it and have to go to <BUILDS.
>>
>> No, only if you are doing something exceedingly odd: interactively
>> programming a system, with no cross compiler, with the dictionary in
>> flash.  Sure, you can do that, but I can't think of any reason that
>> anyone would do it.  I'm not saying that you're wrong to want to do
>> that, but I am saying that edge case is not worth standardizing
>> <BUILDS for.
>
> Well... That is exactly what we're doing with noforth.
>
> Of course you want to do that!
> Interactive programming, dictionary available, files ready for the
> download, and just type COLD or press a button if it fails, to get
> back at your Forth.
> Because this is exactly the same as I work with my linux
> Forth's, except that I type lina64be or gforth instead of
> pressing a button.

All of those conveniences are available on modern Forth cross compilers. 
But they do not come at a cost of the limitations or implementation 
difficulties such as you're putting up with.

> No cross compiler to learn! What a relief! Think about the
> poor electronics people who have a hard time understanding the
> first principles of programming. Cross compilation instead of
> "
> The LEDS are connected to port 1E.
> You can type commands via a serial usb.
> Try :  HEX FF 1E C!
> Behold all leds go on/Verrek, da's makkelijk.
> "

Yes, it's exactly like that with SwiftX.

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."
==================================================
0
Elizabeth
1/3/2014 7:56:34 PM
On 2014-01-03, Elizabeth D. Rather <erather@forth.com> wrote:
> On 1/3/14 6:02 AM, Tristan Plumb wrote:
>> On 2014-01-03, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> What about the Forth-79 document justifies the change of the canonical
>>> flag from 1 to -1?

>> Everyone might have used 1 for true, but Forth-79 only says is "non-zero
>> = true". Forth-83 merely added that standard words return all bits set.

>> Fault them for specifying instead of documenting, but not for creating a
>> conflict between what the standards said about true.

> "Non-zero = true" for Forth83 and Forth94 etc., as far as words like IF, 
> WHILE, and UNTIL are concerned. The issue is what do the comparison 
> words (e.g. 0=, <, etc.) return? In all systems prior to Forth83 it was 
> 1 for TRUE, but after Forth83 it was -1. The correct question is not, 
> "what is TRUE" but "what is a well-formed flag returned by the 
> comparison operators."

Forth79 does not specify a well-formed flag to be returned by the
comparison operators! I believe you when you say everyone used 1, but
until I read the document I was lead to believe that Forth79 stated 1 and
Forth83 changed it to -1. Hence 'specifying instead of documenting'.

tristan

0
Tristan
1/3/2014 7:59:56 PM
On 1/3/14 9:59 AM, Tristan Plumb wrote:
> On 2014-01-03, Elizabeth D. Rather <erather@forth.com> wrote:
>> On 1/3/14 6:02 AM, Tristan Plumb wrote:
>>> On 2014-01-03, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> What about the Forth-79 document justifies the change of the canonical
>>>> flag from 1 to -1?
>
>>> Everyone might have used 1 for true, but Forth-79 only says is "non-zero
>>> = true". Forth-83 merely added that standard words return all bits set.
>
>>> Fault them for specifying instead of documenting, but not for creating a
>>> conflict between what the standards said about true.
>
>> "Non-zero = true" for Forth83 and Forth94 etc., as far as words like IF,
>> WHILE, and UNTIL are concerned. The issue is what do the comparison
>> words (e.g. 0=, <, etc.) return? In all systems prior to Forth83 it was
>> 1 for TRUE, but after Forth83 it was -1. The correct question is not,
>> "what is TRUE" but "what is a well-formed flag returned by the
>> comparison operators."
>
> Forth79 does not specify a well-formed flag to be returned by the
> comparison operators! I believe you when you say everyone used 1, but
> until I read the document I was lead to believe that Forth79 stated 1 and
> Forth83 changed it to -1. Hence 'specifying instead of documenting'.

Yes it does. In 4. Definition of Terms for "flag" Forth79 says, 
"...Standard word definitions leave 1 for true, 0 for false." Then in 
the glossory for words such as 0< the stack picture is:  n -- flag

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."
==================================================
0
Elizabeth
1/3/2014 8:12:59 PM
On 2014-01-03, Elizabeth D. Rather <erather@forth.com> wrote:
> On 1/3/14 9:59 AM, Tristan Plumb wrote:
>> On 2014-01-03, Elizabeth D. Rather <erather@forth.com> wrote:
>>> On 1/3/14 6:02 AM, Tristan Plumb wrote:
>>>> On 2014-01-03, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> What about the Forth-79 document justifies the change of the canonical
>>>>> flag from 1 to -1?
>>
>>>> Everyone might have used 1 for true, but Forth-79 only says is "non-zero
>>>> = true". Forth-83 merely added that standard words return all bits set.
>>
>>>> Fault them for specifying instead of documenting, but not for creating a
>>>> conflict between what the standards said about true.
>>
>>> "Non-zero = true" for Forth83 and Forth94 etc., as far as words like IF,
>>> WHILE, and UNTIL are concerned. The issue is what do the comparison
>>> words (e.g. 0=, <, etc.) return? In all systems prior to Forth83 it was
>>> 1 for TRUE, but after Forth83 it was -1. The correct question is not,
>>> "what is TRUE" but "what is a well-formed flag returned by the
>>> comparison operators."
>>
>> Forth79 does not specify a well-formed flag to be returned by the
>> comparison operators! I believe you when you say everyone used 1, but
>> until I read the document I was lead to believe that Forth79 stated 1 and
>> Forth83 changed it to -1. Hence 'specifying instead of documenting'.

> Yes it does. In 4. Definition of Terms for "flag" Forth79 says, 
> "...Standard word definitions leave 1 for true, 0 for false." Then in 
> the glossory for words such as 0< the stack picture is:  n -- flag

<http://forthworks.com/standards/F79/F79.txt> line 127
|flag
| 
|     A numerical value with two logical states;   0 = false,   non-
|     zero = true.

Were there multiple versions?

Confused,
tristan

0
Tristan
1/3/2014 8:17:09 PM
On 2014-01-03, Tristan Plumb <st@trstn.net> wrote:
><http://forthworks.com/standards/F79/F79.txt> line 127
>|flag
>| 
>|     A numerical value with two logical states;   0 = false,   non-
>|     zero = true.
>
> Were there multiple versions?

I see, this is only an extract of the glossary and I was reading the glossary
definitions. Not the _standard_ definitions.

Sorry for the noise.
Tristan

0
Tristan
1/3/2014 8:29:56 PM
Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> The complaint about 64 bit systems for sure is that it is mostly
>> inconvenient.  It wastes a bit cache space, but only a few percent.
>> The complaint about embedded microcontrollers with flash is that you
>> can't do it and have to go to <BUILDS.
> 
> No, only if you are doing something exceedingly odd: interactively
> programming a system, with no cross compiler, with the dictionary in
> flash.  Sure, you can do that, but I can't think of any reason that
> anyone would do it.  I'm not saying that you're wrong to want to do
> that, but I am saying that edge case is not worth standardizing
> <BUILDS for.

This is not a corner case, this is the norm for programming small 
controllers.  Their RAM is unconviniently small, but flash is dead cheap, 
because one flash cell is 6f² (NOR flash), whereas one SRAM cell starts 
somewhere around 36f² (compact ones).

We had Gerald programming our name tags with a MSP430, 8k flash, 512 bytes 
RAM.  4k of the flash is for the Forth system (which is a typical fig-Forth 
style system written in assembler), the other 4k are for the program, and 
you can bulk-erase the entire user-written program quickly to start over 
again if you need to.

And of course you want to program it interactively, it is Forth!  It is fun 
to program, and these 4k were sufficient to drive an LCD dot-matrix screen, 
add a logo, display your name, a scrolling text explaining what our robot 
does, and a rocket shooting game (ok, Gerald needed to figure out how to 
free a few more bytes to actually do the shooting, but he will ;-).  This is 
not the sort of constrained environment where you absolutely need a cross 
compiler.

So this is a serious real-world use-case which can't be dismissed by 
handwaving.  Forth is that scalable, and at least for the von-Neumann 
architectures, it needs only a few tweaks like adding <BUILDS again to the 
standard do make standard Forths on such small systems possible.

So far, Anton's and my point usually was that the implementors of these 
small chips don't care about the standard, and produce somewhat annoying and 
idiosyncratic systems. But at least I talk to those guys on a regular basis, 
and ask them what prevents their systems to become standard.  For amForth, 
which is also doing direct-do-flash interactive compilation, the main show-
stopper is the Harward architecture.  A @ from RAM is just a different word 
than a fetch from flash, which is the instruction space.  There's not much 
to be done there, but there are AVR Forths out there which do emulate a 
unified memory space.  You can still use larger AVRs with 128k flash by 
having your data memory in the first 64k of the flash (minus the 16k RAM), 
and the code in the second 64k.  The cost of being standard is one compare 
and branch per @ and !, and it's really not worth to wrap the standard 
around this sort of weird architecture.

However, IMHO it *is* worth to wrap it around the much nicer 16 bit CPUs in 
that field, like the msp430 or the R8C, where all you need to be comfortable 
is <BUILDS.  The rest already is standard.  So this is the point where I 
start to agree with the small system developers:  This is not too expensive 
for the rest of the Forth world.  It's not breaking existing code - programs 
for such small systems have several further environmental restrictions.  The 
reference implementation is

: <BUILDS ( "name" -- )  CREATE ;

and as usual, you can provide this as source code.  But specifying these 
things gives implementors of small systems a guidance which will make their 
system resemble each other more than they do now.

We use these small systems as teaching aids, because you need some coolness 
factor to attract people to program in Forth.  Just hooking up a small 
controller board via USB on your PC, and talking to it via a standard 
terminal is cool enough to get people hooked.  Running Forth on a big 
desktop computer isn't particularly cool, because you have ample of 
interactive programming languages there.

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

0
Bernd
1/3/2014 8:43:28 PM
Albert van der Horst wrote:

> I used noforth myself for a demonstration where noforth itself
> was compiled with gforth on a Raspberry pi, then used to build
> a turnkey on the MSP430 that played big ben on the silver
> tingle tangle.
> I used CREATE DOES> for the note duration, not even realizing that
> it was problematic.

noForth defers the setting of the doer until FIND finds that word first 
time.  This is certainly another clever trick that doesn't cause much 
trouble, because the usual CREATE DOES> flow usually sets the doer before 
the word is used first, and if you would use <BUILDS, this is an actual hard 
requirement (you can't use <BUILDS words before you set the doer with 
DOES>).

So yes, there are tricks to make CREATE DOES> possible even without the 
dual-write trick I use.  However, it is certainly considerably more 
expensive (takes more of the precious program space of a tiny system) than a 
straight-forward <BUILDS.

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

0
Bernd
1/3/2014 9:03:40 PM
Bernd Paysan <bernd.paysan@gmx.de> writes:
> We had Gerald programming our name tags with a MSP430, 8k flash, 512 bytes 
> RAM.  4k of the flash is for the Forth system (which is a typical fig-Forth 
> style system written in assembler), the other 4k are for the program...
> And of course you want to program it interactively, it is Forth!  It is fun 
> to program, and these 4k were sufficient to drive an LCD dot-matrix screen, 

Do you really want to write a 4k program interactively with no way to
save or edit?  I thought interactivity was mostly for debugging.

Is your 4k MSP430 Forth released?  4e4th is around 8k, I think.
0
Paul
1/3/2014 9:45:02 PM
On 1/3/14 10:17 AM, Tristan Plumb wrote:
> On 2014-01-03, Elizabeth D. Rather <erather@forth.com> wrote:
>> On 1/3/14 9:59 AM, Tristan Plumb wrote:
>>> On 2014-01-03, Elizabeth D. Rather <erather@forth.com> wrote:
>>>> On 1/3/14 6:02 AM, Tristan Plumb wrote:
>>>>> On 2014-01-03, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>> What about the Forth-79 document justifies the change of the canonical
>>>>>> flag from 1 to -1?
>>>
>>>>> Everyone might have used 1 for true, but Forth-79 only says is "non-zero
>>>>> = true". Forth-83 merely added that standard words return all bits set.
>>>
>>>>> Fault them for specifying instead of documenting, but not for creating a
>>>>> conflict between what the standards said about true.
>>>
>>>> "Non-zero = true" for Forth83 and Forth94 etc., as far as words like IF,
>>>> WHILE, and UNTIL are concerned. The issue is what do the comparison
>>>> words (e.g. 0=, <, etc.) return? In all systems prior to Forth83 it was
>>>> 1 for TRUE, but after Forth83 it was -1. The correct question is not,
>>>> "what is TRUE" but "what is a well-formed flag returned by the
>>>> comparison operators."
>>>
>>> Forth79 does not specify a well-formed flag to be returned by the
>>> comparison operators! I believe you when you say everyone used 1, but
>>> until I read the document I was lead to believe that Forth79 stated 1 and
>>> Forth83 changed it to -1. Hence 'specifying instead of documenting'.
>
>> Yes it does. In 4. Definition of Terms for "flag" Forth79 says,
>> "...Standard word definitions leave 1 for true, 0 for false." Then in
>> the glossory for words such as 0< the stack picture is:  n -- flag
>
> <http://forthworks.com/standards/F79/F79.txt> line 127
> |flag
> |
> |     A numerical value with two logical states;   0 = false,   non-
> |     zero = true.
>
> Were there multiple versions?

It's in the one I found at 
https://mywebspace.wisc.edu/lnmaurer/web/forth/Forth-79.pdf. You are 
quoting the first part of the definition of "flag". I quoted the third 
sentence. This is consistent with the distinction between "truth" as 
perceived by IF, etc. (zero vs non-zero), and "TRUE" as a flag returned 
by 0= etc. (1 for Forth79, -1 after Forth83).

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."
==================================================
0
Elizabeth
1/3/2014 9:48:34 PM
Paul Rubin wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> We had Gerald programming our name tags with a MSP430, 8k flash, 512
>> bytes
>> RAM.  4k of the flash is for the Forth system (which is a typical
>> fig-Forth style system written in assembler), the other 4k are for the
>> program...
>> And of course you want to program it interactively, it is Forth!  It is
>> fun to program, and these 4k were sufficient to drive an LCD dot-matrix
>> screen,
> 
> Do you really want to write a 4k program interactively with no way to
> save or edit?  I thought interactivity was mostly for debugging.

Of course the editor is on the host.  Interactive programming is for trying 
things.  And Gerald usually wrote code into the terminal program and then 
cut&pasted it into the editor.

> Is your 4k MSP430 Forth released?  4e4th is around 8k, I think.

It's mecrisp from Matthias Koch, and released here:

http://mecrisp.sourceforge.net/

I haven't checked the size, Gerald said 4k, the download page speaks of 
9k...

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

0
Bernd
1/3/2014 10:10:14 PM
Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Is your 4k MSP430 Forth released?  4e4th is around 8k, I think.
> It's mecrisp from Matthias Koch, and released here:
> http://mecrisp.sourceforge.net/
> I haven't checked the size, Gerald said 4k, the download page speaks
> of 9k...

Oh cool, I've looked at mecrisp and it's a very nice system, but I do
wonder about that 4k vs 9k discrepancy.  There are a bunch of minimal
ATTiny85 boards (8k flash, 512B eeprom, 512B ram) and it would be
amazing to have a resident Forth in something like this:

  http://olimex.wordpress.com/2013/12/21/

I suspect the AVR code density is worse than the MSP430's though.
0
Paul
1/3/2014 11:41:43 PM
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> In article <gN2dnTjkOcj4ZlvPnZ2dnUVZ_u-dnZ2d@supernews.com>,
> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>>Bernd Paysan <bernd.paysan@gmx.de> wrote:
> <SNIP>
>>
>>> The complaint about 64 bit systems for sure is that it is mostly
>>> inconvenient.  It wastes a bit cache space, but only a few percent.
>>> The complaint about embedded microcontrollers with flash is that you
>>> can't do it and have to go to <BUILDS.
>>
>>No, only if you are doing something exceedingly odd: interactively
>>programming a system, with no cross compiler, with the dictionary in
>>flash.  Sure, you can do that, but I can't think of any reason that
>>anyone would do it.  I'm not saying that you're wrong to want to do
>>that, but I am saying that edge case is not worth standardizing
>><BUILDS for.
> 
> Well... That is exactly what we're doing with noforth.
> 
> Of course you want to do that!
> Interactive programming, dictionary available, files ready for the
> download, and just type COLD or press a button if it fails, to get
> back at your Forth.
> Because this is exactly the same as I work with my linux
> Forth's, except that I type lina64be or gforth instead of
> pressing a button.
> 
> No cross compiler to learn! What a relief! Think about the
> poor electronics people who have a hard time understanding the
> first principles of programming. Cross compilation instead of
> "
> The LEDS are connected to port 1E.
> You can type commands via a serial usb.
> Try :  HEX FF 1E C!
> Behold all leds go on/Verrek, da's makkelijk.
> "

Eh?  All this should just work with a decent Forth umbilical
cross-compiler.  You certainly don't have to sacrifice any
interactivity.  All of this should be well-understood by anyone
working in the area.  I refer you to the classic ;-) paper on the
subject:

Design Considerations for a Microcontroller Development System,
Andrew Haley, Proc. Euroforml 1988.

Andrew.
0
Andrew
1/4/2014 10:18:19 AM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
> 
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> The complaint about 64 bit systems for sure is that it is mostly
>>> inconvenient.  It wastes a bit cache space, but only a few percent.
>>> The complaint about embedded microcontrollers with flash is that you
>>> can't do it and have to go to <BUILDS.
>> 
>> No, only if you are doing something exceedingly odd: interactively
>> programming a system, with no cross compiler, with the dictionary in
>> flash.  Sure, you can do that, but I can't think of any reason that
>> anyone would do it.  I'm not saying that you're wrong to want to do
>> that, but I am saying that edge case is not worth standardizing
>> <BUILDS for.
> 
> This is not a corner case, this is the norm for programming small 
> controllers.  Their RAM is unconviniently small, but flash is dead cheap, 
> because one flash cell is 6f? (NOR flash), whereas one SRAM cell starts 
> somewhere around 36f? (compact ones).
> 
> We had Gerald programming our name tags with a MSP430, 8k flash, 512 bytes 
> RAM.  4k of the flash is for the Forth system (which is a typical fig-Forth 
> style system written in assembler), the other 4k are for the program, and 
> you can bulk-erase the entire user-written program quickly to start over 
> again if you need to.
> 
> And of course you want to program it interactively, it is Forth!

You are almost certainly communicating with the target via some sort
of host computer, so why not run an umbilical cross-compiler on it,
and not waste valuable space on the target with dictionary headers,
etc?

Andrew.
0
Andrew
1/4/2014 10:21:02 AM
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Gforth changed division from platform-specific (but probably symmetric
>> everywhere) to floored... and nobody complained.  The performance
>> impact was small even for pure division microbenchmarks:
>
>That's probably because of interpreter overhead.

Doubtful.  Division is so slow that the small overhead of Gforth is
relatively small.  You can also see that in the times for the 0.6.2
mixed division words.  If intepreter overhead was dominating, the
speed factor between the 0.6.2 and the newer implementation would
me much smaller.

>In (compiled) ghc,
>`quot` (symmetric) is significantly faster than `mod` (floored), enough
>to make a real difference in the running speed of certain programs.

My guess is that they don't know how to implement mod efficiently.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/4/2014 11:49:02 AM
Tristan Plumb <st@trstn.net> writes:
>On 2014-01-03, Elizabeth D. Rather <erather@forth.com> wrote:
>> Yes it does. In 4. Definition of Terms for "flag" Forth79 says, 
>> "...Standard word definitions leave 1 for true, 0 for false." Then in 
>> the glossory for words such as 0< the stack picture is:  n -- flag
>
><http://forthworks.com/standards/F79/F79.txt> line 127
>|flag
>| 
>|     A numerical value with two logical states;   0 = false,   non-
>|     zero = true.
>
>Were there multiple versions?

Sure, the version you link to does not have Sections 3-8.  You could
have noticed that something is missing when you see Section 9 directly
following Section 2.  Anyway, I came across
<http://www.complang.tuwien.ac.at/forth/fth79std/FORTH-79.TXT>, which
contains sections 3-8, and the plain text form may be more convenient
than the PDF form that Elizabeth Rather linked to.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/4/2014 12:00:03 PM
In article <k8udnbDRVdJ2QlrPnZ2dnUVZ_sWdnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>> In article <gN2dnTjkOcj4ZlvPnZ2dnUVZ_u-dnZ2d@supernews.com>,
>> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>>>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> <SNIP>
>>>
>>>> The complaint about 64 bit systems for sure is that it is mostly
>>>> inconvenient.  It wastes a bit cache space, but only a few percent.
>>>> The complaint about embedded microcontrollers with flash is that you
>>>> can't do it and have to go to <BUILDS.
>>>
>>>No, only if you are doing something exceedingly odd: interactively
>>>programming a system, with no cross compiler, with the dictionary in
>>>flash.  Sure, you can do that, but I can't think of any reason that
>>>anyone would do it.  I'm not saying that you're wrong to want to do
>>>that, but I am saying that edge case is not worth standardizing
>>><BUILDS for.
>>
>> Well... That is exactly what we're doing with noforth.
>>
>> Of course you want to do that!
>> Interactive programming, dictionary available, files ready for the
>> download, and just type COLD or press a button if it fails, to get
>> back at your Forth.
>> Because this is exactly the same as I work with my linux
>> Forth's, except that I type lina64be or gforth instead of
>> pressing a button.
>>
>> No cross compiler to learn! What a relief! Think about the
>> poor electronics people who have a hard time understanding the
>> first principles of programming. Cross compilation instead of
>> "
>> The LEDS are connected to port 1E.
>> You can type commands via a serial usb.
>> Try :  HEX FF 1E C!
>> Behold all leds go on/Verrek, da's makkelijk.
>> "
>
>Eh?  All this should just work with a decent Forth umbilical
>cross-compiler.  You certainly don't have to sacrifice any
>interactivity.  All of this should be well-understood by anyone
>working in the area.  I refer you to the classic ;-) paper on the
>subject:
>
>Design Considerations for a Microcontroller Development System,
>Andrew Haley, Proc. Euroforml 1988.

Of course. But you've to use a complicated tool, that you don't
quite fully understand.
If there is something I don't like about noforth, I rebuild it,
if must be on a Raspberry pi.

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

0
albert
1/4/2014 12:39:07 PM
On 2014-01-04, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Tristan Plumb <st@trstn.net> writes:
>>On 2014-01-03, Elizabeth D. Rather <erather@forth.com> wrote:
>>> Yes it does. In 4. Definition of Terms for "flag" Forth79 says, 
>>> "...Standard word definitions leave 1 for true, 0 for false." Then in 
>>> the glossory for words such as 0< the stack picture is:  n -- flag
>>
>><http://forthworks.com/standards/F79/F79.txt> line 127
>>|flag
>>| 
>>|     A numerical value with two logical states;   0 = false,   non-
>>|     zero = true.
>>
>>Were there multiple versions?

> Sure, the version you link to does not have Sections 3-8.  You could
> have noticed that something is missing when you see Section 9 directly
> following Section 2.  Anyway, I came across
><http://www.complang.tuwien.ac.at/forth/fth79std/FORTH-79.TXT>, which
> contains sections 3-8, and the plain text form may be more convenient
> than the PDF form that Elizabeth Rather linked to.

Thanks, when I found my error I started looking for a complete text
version, but mostly found bad OCRs. It (obviously) didn't occur to me
that someone might post an incomplete copy of the standard and I read the
context around every instance of 'true' and 'false' heedless to extrania
like section numbers...

Does anyone have simular text copies of 77 or 78? Google is not hopeful.

tristan

0
Tristan
1/4/2014 1:12:40 PM
Tristan Plumb <firth@trstn.net> wrote:
> 
> Does anyone have simular text copies of 77 or 78? Google is not hopeful.

I've never seen either.  It'd be interesting.

Andrew.
0
Andrew
1/4/2014 2:22:30 PM
If I understood you correctly, you point to importance of making standard s=
uitable for real customers. What you think about current situation in the I=
T and does the ANS94 meets modern requirements? Also, should we make effort=
s to describe a pack of new 'very important' words or review the basic requ=
irements for the things to be standartized?
0
Ilya
1/4/2014 9:57:47 PM
On 1/4/14 11:57 AM, Ilya Tarasov wrote:
> If I understood you correctly, you point to importance of making standard
 > suitable for real customers. What you think about current situation 
in the
> IT and does the ANS94 meets modern requirements? Also, should we make efforts
> to describe a pack of new 'very important' words or review the basic
> requirements for the things to be standartized?

The first question you have to answer, before addressing your others, is 
what is the intended purpose or market for this language? Forth was 
originally developed for what we now call embedded systems, and it is 
still optimized for that market in many ways. It has successfully been 
used in other areas, but is not competitive with languages developed 
specifically for very different application areas such as (as Gavino 
often reminds us) web development.

The current standardization effort has certainly added some "modern" 
capabilities and addressed issues found in 20 years of use of Forth94 
along the lines of "basic requirements".

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."
==================================================
0
Elizabeth
1/4/2014 10:17:35 PM
"Elizabeth D. Rather" <erather@forth.com> writes:
>> IT and does the ANS94 meets modern requirements?...
> The first question...  is what is the intended purpose or market for
> this language?

One thing I'd say is the division of ANS94 words into core, extensions,
etc. all seems done for the sake of minimizing the footprints of
resident interpreters on small targets.  Maybe future iterations can
have more features aimed at tethered implementations.
0
Paul
1/4/2014 11:08:53 PM
I have a quite successful results from Forth and I understand what you are =
talking about. I see at least two major reasons to not to bring Forth as a =
single product into the market.=20
1. Very few Forth programmers. There are almost no available market to sell=
 Forth translators.=20
2. The conception of Forth is simple enough, so many professional programme=
rs or even embedded engineers can write a highly adopted version of Forth f=
or the certain purpose.

For the ANS94, there are a suitable joke may take a place:

A woman ask her husband:
- Honey, I was with you when your company went bankrupt, when you crush you=
r car, and when you're sick. What are you thinking about it?
- I think you make me luckless!

Well, some times ago Forth was strong enough to be a quite popular language=
 at least for embedded systems. After that, standard was redefined. Many ef=
fort was applied to that job, but now we can see that Forth has a very litt=
le lifesigns. I'm sure in this case nobody should imitate 'the real job fro=
m the real world', but search for the more important steps instead. From my=
 'Forth customer' point of view, the new standards are not more than a nois=
e, because I see many ways to implement a certain feature. Moreover, the ta=
sk to solve and the hardware platform often dictates this ways and I defini=
tely don't refuse the best solution because it is 'non-standard'. Your real=
 experience is the reason for asking for your opinion. Unfortunately, as yo=
u previously pointed, there are many peoples, who wants to decide something=
, but has no a real experience to do that.
0
Ilya
1/5/2014 12:06:40 AM
Anton Ertl wrote:
> "Ed" <invalid@invalid.com> writes:
> >Forth is empirically based.  It matters whether a majority of cases favour a
> >particular solution.  It was this that drove the decision to make PICK and
> >ROLL zero-based - even at the expense of breaking code.
>
> Please enlighten me about the empirical basis of "zero-based" PICK and
> ROLL.

When the index is computed, zero-based is optimum.

>
> >Short-term
> >pain for long-term gain.
>
> Long-term pain for no gain.

Clearly not.  PICK and ROLL have been zero-based since '83 and '94.
Where are the long-term complaints?

> >Floored integer division favoured the majority of
> >cases but completely ignored the reality of hardware division which was
> >symmetric.  The result - long-term pain.
>
> What pain?

How many times do you need to be reminded?

Several vendors refused to adopt '83 division, opting for conventional division.
'94 chose a political compromise which even mathematicians saw as crazy.

This saga has been going for 30+ years.  It's time Forth ended it.

> Gforth changed division from platform-specific (but
> probably symmetric everywhere) to floored (symmetric could be chosen
> as a build option), and nobody complained.  The performanc impact was
> small even for pure division microbenchmarks:
>
> From <2007Jan26.165751@mips.complang.tuwien.ac.at>
>
> |           development     0.6.2
> |        floored symmetric symmetric
> |/        194 ms   181 ms    175 ms
> |mod      197 ms   181 ms    175 ms
> |/mod     193 ms   183 ms    175 ms
> |*/       252 ms   250 ms    908 ms
> |*/mod    258 ms   259 ms    885 ms
> |fm/mod   278 ms   277 ms   1283 ms
> |sm/rem   196 ms   196 ms   1215 ms
> |um/mod   235 ms   235 ms    693 ms
> |m*/     2018 ms  1764 ms   2373 ms

I see no compelling argument here or elsewhere for all division to be
floored.  Which isn't to say floored division has no uses.

All that '83 had to do was provide FM/MOD for those relatively few
applications which required it.  Job done.  Andso it is today.  It is the
floored-division hold-outs who wish to continue Forth's 30-year argument.



0
Ed
1/5/2014 2:14:19 AM
mhx@iae.nl wrote:
> ...
> In about 12,000 files there are only 3 significant occurrences (the rest are
> tests). On the other hand, without REPRESENT it would not have been possible
> to build the word F.N1, which I use all of the time.  It should be said
> that iForth has (F.) and (E.), driving down use of the cumbersome REPRESENT.
> Number formatting is a significant part of most programs I write.

I'm willing to be convinced.  I'd like to see those functions which could not use
(F.) and (E.) and required REPRESENT.  Can you provide the specs or source?



0
Ed
1/5/2014 2:25:32 AM
Elizabeth D. Rather wrote:
> On 1/2/14 6:52 AM, Anton Ertl wrote:
> > ...
> > The only differences I see are not in the starting situation, but what
> > the committee made from it: Forth-94 and Forth-200x did not change
> > already-standardized words incompatibly.
>
> And that has been wise.

I must have a different set of documents ...

'83 TYPE takes a signed count.  '94 changed it to unsigned.  '83 WORD and
11.8 Input Text indicates strings to 255 chars can be parsed followed by a trailing
blank.  '94 guarantees only 31 chars and excludes new programs from using
the trailing blank.  200x removed the blank altogether.  '94 permitted separate
and common f/p stack.  200x excluded systems with a common f/p stack.

What is notable about these is that they add no new facility to Forth, nor fixed
any problem.  The only effect of these changes has been the removal features
and options Forth users once had, potentially breaking programs in the process.





0
Ed
1/5/2014 2:26:29 AM
On 1/4/14 4:14 PM, Ed wrote:
> Anton Ertl wrote:
....
>> Gforth changed division from platform-specific (but
>> probably symmetric everywhere) to floored (symmetric could be chosen
>> as a build option), and nobody complained.  The performanc impact was
>> small even for pure division microbenchmarks:
>>
>>  From <2007Jan26.165751@mips.complang.tuwien.ac.at>
>>
>> |           development     0.6.2
>> |        floored symmetric symmetric
>> |/        194 ms   181 ms    175 ms
>> |mod      197 ms   181 ms    175 ms
>> |/mod     193 ms   183 ms    175 ms
>> |*/       252 ms   250 ms    908 ms
>> |*/mod    258 ms   259 ms    885 ms
>> |fm/mod   278 ms   277 ms   1283 ms
>> |sm/rem   196 ms   196 ms   1215 ms
>> |um/mod   235 ms   235 ms    693 ms
>> |m*/     2018 ms  1764 ms   2373 ms
>
> I see no compelling argument here or elsewhere for all division to be
> floored.  Which isn't to say floored division has no uses.
>
> All that '83 had to do was provide FM/MOD for those relatively few
> applications which required it.  Job done.  Andso it is today.  It is the
> floored-division hold-outs who wish to continue Forth's 30-year argument.

The argument has to do with graphics. If you wish to draw a straight 
line through zero, you have to use floored division to avoid a shoulder.

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."
==================================================
0
Elizabeth
1/5/2014 2:35:50 AM
On 1/4/14 4:26 PM, Ed wrote:
> Elizabeth D. Rather wrote:
>> On 1/2/14 6:52 AM, Anton Ertl wrote:
>>> ...
>>> The only differences I see are not in the starting situation, but what
>>> the committee made from it: Forth-94 and Forth-200x did not change
>>> already-standardized words incompatibly.
>>
>> And that has been wise.
>
> I must have a different set of documents ...
>
> '83 TYPE takes a signed count.  '94 changed it to unsigned.

Were any systems broken that depended on a negative count? I didn't 
think so. The change allowed twice as long a string.

> '83 WORD and
> 11.8 Input Text indicates strings to 255 chars can be parsed followed by a trailing
> blank.  '94 guarantees only 31 chars and excludes new programs from using
> the trailing blank.  200x removed the blank altogether.

Not sure what the 31 characters is about. WORD makes a counted string. 
It did retain the blank but advertised it as "obsolescent" to allow a 
generation (of programs) to adapt before the blank was removed 
altogether. Again, I doubt that broke any existing programs.

> '94 permitted separate
> and common f/p stack.  200x excluded systems with a common f/p stack.

The common f/p stack was retained in '94 mainly as a commitment to the 
Harris team and Chuck.

> What is notable about these is that they add no new facility to Forth, nor fixed
> any problem.  The only effect of these changes has been the removal features
> and options Forth users once had, potentially breaking programs in the process.

The TYPE change allowed strings twice as long. This was considered 
important because some people TYPE into a file. The integrated f/p stack 
was a feature that had to be documented and that one wasn't supposed to 
depend on. It still is, it's just that instead of being a documented 
option it's now an environmental restriction. I'm not at all sure about 
the value of these features or whether any actual programs were broken.

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."
==================================================
0
Elizabeth
1/5/2014 2:55:44 AM
On Sunday, January 5, 2014 3:25:32 AM UTC+1, Ed wrote:
> mhx@iae.nl wrote:
> > ...
> > In about 12,000 files there are only 3 significant occurrences (the rest are
> > tests). On the other hand, without REPRESENT it would not have been possible
> > to build the word F.N1, which I use all of the time.  It should be said
> > that iForth has (F.) and (E.), driving down use of the cumbersome REPRESENT.
> > Number formatting is a significant part of most programs I write.
> 
> I'm willing to be convinced.  I'd like to see those functions which could 
> not use (F.) and (E.) and required REPRESENT.  Can you provide the specs 
> or source?

-- app1 ----

	-- Display a number in a "engineer-friendly" way:
	-- a p n u m  k M G T

	PAD$ MyPad PRIVATE 

	CREATE specchars PRIVATE
		'z' C,	\ -24 .. -21 zepto
		'y' C,	\ -21 .. -18 yocto
		'a' C,	\ -18 .. -15 atto
		'f' C,	\ -15 .. -13 femto
		'p' C,	\ -12 .. -10 pico	
		'n' C, 	\  -9 .. -7  nano
		'u' C, 	\  -6 .. -4  micro
		'm' C, 	\  -3 .. -1  milli
		'_' C, 	\   0 .. 2  
		'K' C, 	\   3 .. 5   Kilo
		'M' C, 	\   6 .. 8   Mega
		'G' C, 	\   9 .. 11  Giga
		'T' C, 	\  12 .. 14  Tera
		'P' C,	\  15 .. 17  Peta
	
	: REMOVE-0s  ( c-addr1 u1 -- c-addr2 u2 )
		DUP 0= ?EXIT
		2DUP 1- + C@ '0' = IF 1- RECURSE ENDIF ; PRIVATE

	-- Failed (printed garbage) when PRECISION was set to 16 or higher.
	-- 31 Dec 1997; mhx: incorrect use of FLOOR detected.
	: 0e?    ( F: +/-0 -- c-addr u ) -0e 0e F~ IF S" -0 "  ELSE S" 0 "  ENDIF ; PRIVATE
	: 0e?+BL ( F: +/-0 -- c-addr u ) -0e 0e F~ IF S" -0  " ELSE S" 0  " ENDIF ; PRIVATE
	: {F.N1} ( F: r -- ) ( bool -- c-addr u )
		FDUP F0=  
		FDUP FABS 1e-24 F< OR IF  ( F: r -- ) ( bool) IF  0e?+BL  ELSE  0e?  ENDIF  EXIT ENDIF
		FLOCAL target  0 0 PRECISION LOCALS| old-prec ix offs addBL |
		old-prec #19 MIN SET-PRECISION ( was #18 )
		target MyPad PRECISION 3 + REPRESENT
		  0= IF 2DROP  MyPad 4 + 2 BLANK MyPad 6  old-prec SET-PRECISION  EXIT ENDIF
	 	SWAP DUP #-23 #19 WITHIN 
		  0= IF 2DROP old-prec SET-PRECISION target (FE.) EXIT ENDIF 
		1- S>D 3 FM/MOD TO ix TO offs
		  IF S" -" ELSE S" _" ENDIF
		MyPad offs 1+ $+ S" ." $+
		MyPad offs 1+ +  PRECISION REMOVE-0s
		DUP 0= IF 2DROP 1- ELSE $+ ENDIF
		addBL IF S"  " $+ ( ** Feb 28 2000 ) ENDIF
		ix 8 +  specchars + 1 $+
		2DUP 1- + C@ '_' = IF  addBL IF  2DUP 1- + BL SWAP C! ( 1- ) 
					   ELSE  1- ( remove _ )
					  ENDIF
				ENDIF
		OVER C@ '_' = IF 1 /STRING ENDIF
		old-prec SET-PRECISION ; PRIVATE

	: (F.N1) ( F: r -- ) ( -- c-addr u ) TRUE  {F.N1} ;
	: (F.N2) ( F: r -- ) ( -- c-addr u ) FALSE {F.N1} ;
	: F.N1   ( F: r -- ) (F.N1) TYPE ;
	: F.N2   ( F: r -- ) (F.N2) TYPE ;
	
: (F.N3) ( F: r -- ) ( -- c-addr u )
	MyPad 1 REPRESENT 
	0= IF  2DROP S" NaN" EXIT  ENDIF 
	   IF S" -" ELSE S"  " ENDIF
	ROT S>D 3 FM/MOD 8 + specchars + >S 
	CASE ABS
	  0 OF  S" ." $+ MyPad 1 $+ ENDOF
	  1 OF           MyPad 1 $+ ENDOF
	  2 OF  MyPad 1 $+ S" 0" $+ ENDOF
	ENDCASE 
	S> 1 $+  2DUP + CHAR- C@ '_' = IF 1- ENDIF ;

: F.N3 ( F: r -- ) (F.N3) TYPE ;

-- app2 (from a well-known author :-) ------

CREATE FBUF             \ string buffer
#20 CHARS ALLOT         \ set this to your max precision

\ float to ascii
: (F1)  ( F: r -- ) ( -- sign c-addr u exp )
  FBUF PRECISION  REPRESENT DROP SWAP 1-
  FBUF PRECISION  ROT <# ;

-- app3 -------
-- Read ahead in text file. This doesn't work with a terminal.

: PUTS	  ( c-addr u -- ) 0 ?DO C@+ PUTCH LOOP DROP ; PRIVATE
: PUT-LF  ( -- ) $CR COUNT PUTS ; PRIVATE

: NUM>	( F: r -- )
	PAD 4 REPRESENT
	0= IF 2DROP PAD 4
	 ELSE IF S" -" ELSE S"  " ENDIF
	      PAD 1 $+ S" ." $+ PAD 1+ 3 $+
	      ROT 1- DUP >S 0< IF S" e-" ELSE S" e+" ENDIF $+
	      S> ABS U>D -2 (UD.R) $+
	ENDIF PUTS BL PUTCH ; PRIVATE

-marcel
0
mhx
1/5/2014 3:03:52 AM
Paul Rubin <no.email@nospam.invalid> wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>>> IT and does the ANS94 meets modern requirements?...
>> The first question...  is what is the intended purpose or market for
>> this language?
> 
> One thing I'd say is the division of ANS94 words into core, extensions,
> etc. all seems done for the sake of minimizing the footprints of
> resident interpreters on small targets.

Surely it's just good modular design.

Andrew.
0
Andrew
1/5/2014 10:57:28 AM
On Sat, 04 Jan 2014 16:35:50 -1000, "Elizabeth D. Rather"
<erather@forth.com> wrote:

>The argument has to do with graphics. If you wish to draw a straight 
>line through zero, you have to use floored division to avoid a shoulder.

Or bias the coordinate system, which is often faster on current
hardware. The rationale for floored arithmetic is very thin now,
and was thin at the time.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
0
stephenXXX
1/5/2014 11:35:40 AM
Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> On Sat, 04 Jan 2014 16:35:50 -1000, "Elizabeth D. Rather"
> <erather@forth.com> wrote:
> 
>>The argument has to do with graphics. If you wish to draw a straight
>>line through zero, you have to use floored division to avoid a
>>shoulder.
> 
> Or bias the coordinate system, which is often faster on current
> hardware.

Floored arithmetic does exactly that, but does it everywhere
consistently, so the programmer doesn't have to work with that biased
system.  This saves programmer cycles for a very small cost of machine
cycles in the cases where it really is slightly slower.

> The rationale for floored arithmetic is very thin now, and was thin
> at the time.

Mathematically speaking, the rationale hasn't changed at all.  I don't
think you can argue with the rationale for making floored division
available in Forth systems.  And if there is a choice, with no cost
implications, then floored is the best default because it misbehaves
less.

I always have preferred floored division because MOD has to be
compatible with / , and the MOD that results from symmetric division
is rather less useful than a chocolate teapot.  I would have thought
that argument was sufficient.

Why do you think anything else has changed?  I suppose more processors
have signed DIV instructions, but even where they exist the difference
with floored division isn't that great, is it?

Andrew.
0
Andrew
1/5/2014 12:15:34 PM
"Ed" <invalid@invalid.com> writes:
>I must have a different set of documents ...
>
>'83 TYPE takes a signed count.

You obviously have a different document.  The Forth-83 document I have says:

|TYPE         addr +n --                    M,79
|           +n characters are displayed from memory beginning with the
|           character at addr and continuing through consecutive
|           addresses.  Nothing is displayed if +n is zero.

So the count must not be non-negative.

>'94 changed it to unsigned.

No Forth-83 compliant program became Forth-94 non-compliant because of
this change.  This is a tightening of the spec.

>'83 WORD and
>11.8 Input Text indicates strings to 255 chars can be parsed followed by a trailing
>blank.  '94 guarantees only 31 chars and excludes new programs from using
>the trailing blank.  200x removed the blank altogether.

As far as I can see, Forth-94 guarantees at least 33 chars, while I
don't see any length guarantee in Forth-83.  One can argue that this
means that the string can have up to 255 characters, but I suspect
that a number of systems that were generally considered to be Forth-83
compliant put the pictured numeric output (HOLD) buffer and PAD inside
those 255 chars.

The removal of the guaranteed trailing blank is a loosening of the
spec.  Such a removal of guarantees has to be done with care, that's
why it happened in two stages: In the first stage, it was announced
that it would be removed, in the second (18 years later) it was
removed.


>'94 permitted separate
>and common f/p stack.  200x excluded systems with a common f/p stack.

That's a tightening of the spec.  There were practically no Forth-94
programs that used FP and did not have either an environmental
dependency on a separate FP stack, or on a shared data/FP stack with
FP numbers having n cells.  In other words, Forth-94 had not
standardized FP in a way that encouraged people to write fully
standard programs.  Forth-2012 corrects that.

>What is notable about these is that they add no new facility to Forth, nor fixed
>any problem.  The only effect of these changes has been the removal features
>and options Forth users once had, potentially breaking programs in the process.

Tightening the standard does not de-standardize previously standard
programs (unlike the Forth-83 changes).

Loosening the standard does destandardize previously standard program,
but systems are still free to implement the tighter spec, so they can
still support the programs that had run on the system before; also,
loosening the spec is done in stages to give programmers time to adapt
to the new situation.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/5/2014 12:53:54 PM
Andrew Haley wrote:
> Why do you think anything else has changed?  I suppose more processors
> have signed DIV instructions, but even where they exist the difference
> with floored division isn't that great, is it?

The speed relation is

unsigned < floor(d/u) < symmetric < floored

but the differences are rather small.

If speed was the argument, floor(d/u) would be the winner: It has no bumps, 
is mathematically sound, and nobody divides by negative numbers - the case 
that you divide by a fractional number which represents [0..1[ is more 
likely, and then you need the full range of u.

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

0
Bernd
1/5/2014 2:11:10 PM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>> Why do you think anything else has changed?  I suppose more processors
>> have signed DIV instructions, but even where they exist the difference
>> with floored division isn't that great, is it?
> 
> The speed relation is
> 
> unsigned < floor(d/u) < symmetric < floored
> 
> but the differences are rather small.

On x86 I imagine you're right, but not always: it is possible to do
symmetric division (in hardware) at the same speed as unsigned.  SRT
division can be implemented this way.

Andrew.
0
Andrew
1/5/2014 4:07:02 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> One thing I'd say is the division of ANS94 words into core, extensions,
> Surely it's just good modular design.

Meh.  Imagine the C language being designed such that the WHILE
statement was part of core, but the FOR statement was an extension.
0
Paul
1/5/2014 5:14:29 PM
Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> One thing I'd say is the division of ANS94 words into core, extensions,
>> Surely it's just good modular design.
> 
> Meh.  Imagine the C language being designed such that the WHILE
> statement was part of core, but the FOR statement was an extension.

I'm not sure that particular split would make sense, but well, yes.  C
is just one big lump, Forth is modular.  That's one of the ways in
which Forth is better.

Andrew.
0
Andrew
1/5/2014 6:20:10 PM
Andrew Haley wrote:
> On x86 I imagine you're right, but not always: it is possible to do
> symmetric division (in hardware) at the same speed as unsigned.  SRT
> division can be implemented this way.

It might be possible, but who does it?  Intel has some tradition with SRT 
(famous FDIV bug), so they could.  You could use the same circuit for the 
non-restoring version of SRT to do both signed and unsigned division by 
spending an extra bit - then both signed and unsigned numbers can be 
expanded to fit into the same representation.

However, SRT is itself agnostic to floored or symmetric division, because it 
can produce negative or positive remainders, independent of the actual 
inputs, so the last step in SRT is to adjust the remainder to the chosen 
rounding method.  That's because SRT will always produce an odd quotient (a 
result of the representation), and the remainder is in the range [-d..d[.

If you want to try, here's it:

\ non-restoring division

: nr/mod ( d n -- nq nr ) 0
    8 cells 0 DO
	>r >r
	dup 0< IF
	    d2* r@ + r> r> 2*
	ELSE
	    d2* r@ - r> r> 2* 1+
	THEN
    LOOP  >r drop nip r> 2* 1+ swap ;

srt uses essentially the same algorithm, but it is less precise, so the 
final correction is a bit larger - you might end up with two correction 
steps instead of just one.

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

0
Bernd
1/5/2014 8:14:11 PM
Hans Bezemer wrote:
> Ed wrote:
>
> > Forth is empirically based.  It matters whether a majority of cases favour
> > a particular solution.  It was this that drove the decision to make PICK
> > and ROLL zero-based - even at the expense of breaking code.  Short-term
> > pain for long-term gain.  Floored integer division favoured the majority
> > of cases but completely ignored the reality of hardware division which was
> > symmetric.  The result - long-term pain.
> I'd say it is opportunistically based. "Hey, every major system has 16 bits.
> Let's make all cells 16 bits." Worst decision EVER! Completely pragmatic
> and visionless. "Hey, we can't reach our entire address range with LOOP.
> Let's violate sane design so we can." "Hey, we need to work with ordinary
> files. Let's completely ignore proper design and glue an entire C library
> on top of it." "Hey, we need to define a CORE system. Let's simply see what
> we use on an average day and mix our special brew of unsigned, mixed,
> double and single words together and call it CORE". And so on, and on and
> on. Long term pain - like ordinary program design - is avoided by vision,
> architecture and a proper design - not "what feels good at the moment to
> the majority".
> ...

As you've mentioned it I have to ask.  What do you find wrong with the
ANS file functions - and what would you use instead?

My impression is the ANS functions are more straightforward than C's.
Apart from some debatable items, they do what's necessary and can be
implemented in environments as hostile as CP/M with ease and efficiency
(much to my surprise I might add).



0
Ed
1/5/2014 11:57:52 PM
Bernd Paysan wrote:
> Ed wrote:
> > Forth is empirically based.  It matters whether a majority of cases favour
> > a particular solution.  It was this that drove the decision to make PICK
> > and ROLL zero-based - even at the expense of breaking code.  Short-term
> > pain for long-term gain.  Floored integer division favoured the majority
> > of cases but completely ignored the reality of hardware division which was
> > symmetric.  The result - long-term pain.
>
> Actually, the pain you pay here is not existing.  Symmetric hardware
> division is actually generated code by the decoder, which uses the internal
> unsigned division algorithm and some conditional code to fix the sign.  If
> you write this down for floored division, it is about as fast as the
> hardware symmetric division.

Even if the timings were similar, why would anyone choose to write a division
routine when opcode for it was sitting there in hardware ready to use with
exceptions automatically handled and documented.  With rare exception,
no-one would.

When it comes to implementing floored division those with hardware division
base it on the signed division instruction, not unsigned, for the same reasons.

>  If you use Forth Inc's floored division
> (divide by unsigned), you are even faster than the symmetric hardware
> division.

A nice technique but 83/94 "floored division" requires *signed* divisors.
Also it's not possible to detect overflows IIRC.







0
Ed
1/6/2014 1:42:17 AM
Elizabeth D. Rather wrote:
> On 1/4/14 4:14 PM, Ed wrote:
> > ...
> > All that '83 had to do was provide FM/MOD for those relatively few
> > applications which required it.  Job done.  Andso it is today.  It is the
> > floored-division hold-outs who wish to continue Forth's 30-year argument.
>
> The argument has to do with graphics. If you wish to draw a straight
> line through zero, you have to use floored division to avoid a shoulder.

That's what FM/MOD is for.  The rest of the time conventional division
works fine because most division operations involve positive arguments.

Only Forth made it into an issue - by ascribing to one name, two different
functions.





0
Ed
1/6/2014 1:42:27 AM
mhx@iae.nl wrote:
> On Sunday, January 5, 2014 3:25:32 AM UTC+1, Ed wrote:
> > mhx@iae.nl wrote:
> > > ...
> > > In about 12,000 files there are only 3 significant occurrences (the rest are
> > > tests). On the other hand, without REPRESENT it would not have been possible
> > > to build the word F.N1, which I use all of the time.  It should be said
> > > that iForth has (F.) and (E.), driving down use of the cumbersome REPRESENT.
> > > Number formatting is a significant part of most programs I write.
> >
> > I'm willing to be convinced.  I'd like to see those functions which could
> > not use (F.) and (E.) and required REPRESENT.  Can you provide the specs
> > or source?
>
> -- app1 ----
>
> -- Display a number in a "engineer-friendly" way:
> -- a p n u m  k M G T
> ...

Thanks.  I found a copy in an old iForth demo.

REPRESENT should not be necessary.  The way I'd go about implementing this
one is to use the string output from (FE.) and massage into the required form.
The following is lacking some of the frills of yours but illustrates the method.
It uses the  (FE.) function from  FPOUT  http://dxforth.webhop.org/forth.html
If one only has (F.) then the task is somewhat harder :)

 --

empty forth definitions decimal
max-precision set-precision

: split ( a u char -- a2 u2 a u-u2 )
  >r 2dup r> scan 2swap 2 pick - ;

create specchars
char z c,  char y c,  char f c,  char p c,
char u c,  char m c,  char _ c,  char K c,
char M c,  char G c,  char P c,  char T c,

\ output with 3 decimal places
\ e.g. 1.23456E3 = "1.235K"  1.0E3 = "1.000K"
: (FN.) ( r -- a u )
  3 (fe.) ( a u )
  2dup [char] E split  2drop ( a u a2 u2)
  dup if ( not NAN/INF)
    2dup  1 /string ( skip 'E')
    over c@ [char] - = ( sign) >r  1 /string
    0. 2swap  >number 2drop  d>s  r> if negate then
    18 +  3 /  dup 0 12 within if
      specchars + c@  >r  over swap blank
      r> swap c!  -trailing  exit
    then  drop
  then  2drop ;

: fn. ( r -- )  (FN.) type ;


pi f. 3.14159265358979  ok
pi fn. 3.142_ ok
10e fn. 10.000_ ok
456789e fn. 456.789K ok
+inf fn. +INF ok


Engineering notation implies a precision of 3 digits (?) so it can be useful
to limit the output to that many digits.  Here's a version which does that.

\ alternate version, output 3 significant digits max
\ e.g. 1.23456E3 = "1.23K"  1.0E3 = "1K"
: (FN.) ( r -- a u )
  precision  fdp @  2>r  3 set-precision  fdp off
  -1 (fe.) ( a u )
  2r>  fdp !  set-precision
  2dup [char] E split  2drop ( a u a2 u2)
  dup if ( not NAN/INF)
    2dup  1 /string ( skip 'E')
    over c@ [char] - = ( sign) dup >r  1 and /string
    0. 2swap  >number 2drop  d>s r> if negate then
    18 +  3 /  dup 0 12 within if
      specchars + c@  >r  over swap blank
      r> swap c!  -trailing  exit
    then  drop
  then  2drop ;

: fn. ( r -- )  (FN.) type ;

pi f. 3.14159265358979  ok
pi fn. 3.14_ ok
10e fn. 10_ ok
456789e fn. 457K ok
+inf fn. +INF ok



0
Ed
1/6/2014 3:08:45 AM
On Monday, January 6, 2014 4:08:45 AM UTC+1, Ed wrote:
> mhx@iae.nl wrote: > On Sunday, January 5, 2014 3:25:32 AM UTC+1, Ed wrote: 
> > mhx@iae.nl wrote: 
[..]
> REPRESENT should not be necessary.  The way I'd go about implementing this 
> one is to use the string output from (FE.) and massage into the required
> form. 
> The following is lacking some of the frills of yours but illustrates the 
> method. 

How do you know the frills don't need REPRESENT ?

> It uses the  (FE.) function from  FPOUT  http://dxforth.webhop.org/forth.html 
> If one only has (F.) then the task is somewhat harder :) 

I may not understand what you're getting at.

In order to avoid REPRESENT I must use (FE.), which is based on REPRESENT with added implementation-specific code to get around its bugs?

I do agree that REPRESENT needs fixing (At the time I followed your recommendations in updating iForth). REPRESENT should have been fixed 
in ANS-2000 and some kind of PLACES should have been introduced.

On a related note, I see that David's IEEE-FP extentions also seem to have 
been ignored completely (all present in iForth now). Apperently more urgent 
standard matters needed fixing first.

-marcel
0
m
1/6/2014 9:47:43 AM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>> On x86 I imagine you're right, but not always: it is possible to do
>> symmetric division (in hardware) at the same speed as unsigned.  SRT
>> division can be implemented this way.
> 
> It might be possible, but who does it?

Hard for anyone to say, especially in public, because silicon
companies are so jealous about revealing anything, but I have seen
some timings where symmetric signed division had the same speed as
unsigned, at 4 bits/cycle.  The rest is my guess!  :-)

> However, SRT is itself agnostic to floored or symmetric division,

Sure, but that doesn't really matter unless you're making your own
silicon.

Andrew.
0
Andrew
1/6/2014 10:44:00 AM
Ed wrote:
> That's what FM/MOD is for.  The rest of the time conventional division
> works fine because most division operations involve positive arguments.

We have um/mod for positive arguments.  Following your argument, / should 
really be ( u1 u2 -- u3 ), because nobody needs / for negative numbers.

I redefined VFX's divison operators to the floored ones when porting MINOS, 
because that way I got pixel-identical results.

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

0
Bernd
1/6/2014 8:51:10 PM
On Mon, 06 Jan 2014 21:51:10 +0100, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

>I redefined VFX's divison operators to the floored ones when porting MINOS, 
>because that way I got pixel-identical results.

Did you hide them from other people? No, you just don't care about 
other people's code. It's the ego problem again.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
0
stephenXXX
1/6/2014 10:41:42 PM
m.a.m.hendrix@tue.nl wrote:
> On Monday, January 6, 2014 4:08:45 AM UTC+1, Ed wrote:
> [..]
> > REPRESENT should not be necessary.  The way I'd go about implementing this
> > one is to use the string output from (FE.) and massage into the required
> > form.
> > The following is lacking some of the frills of yours but illustrates the
> > method.
>
> How do you know the frills don't need REPRESENT ?

Cite one.

> [..]
> I may not understand what you're getting at.
>
> In order to avoid REPRESENT I must use (FE.), which is based on REPRESENT with added
> implementation-specific code to get around its bugs?

I contend that once you have (FE.) (F.) (FS.) that is all that's required. (*)
It must be so because that's all that other languages provide.  Armed with
these one can transform them into other formats with a little string manipulation.

How a system designer chooses to implement (FE.) (F.) (FS.) is up to them.
One method involves using REPRESENT which I quoted.  Another which
doesn't is here:  http://dxforth.webhop.org/sfpout.html

(*) There may be a case for having a function which tests for 'non-numbers'
e.g. NAN/INF.   OTOH I imagine systems which support such numbers would
already have a suitable function e.g. FCLASS ( F: r -- ) ( -- x )


> -- app3 -------
> -- Read ahead in text file. This doesn't work with a terminal.
>
> : PUTS   ( c-addr u -- ) 0 ?DO C@+ PUTCH LOOP DROP ; PRIVATE
> : PUT-LF  ( -- ) $CR COUNT PUTS ; PRIVATE
>
> : NUM> ( F: r -- )
> PAD 4 REPRESENT
> 0= IF 2DROP PAD 4
> ELSE IF S" -" ELSE S"  " ENDIF
>       PAD 1 $+ S" ." $+ PAD 1+ 3 $+
>       ROT 1- DUP >S 0< IF S" e-" ELSE S" e+" ENDIF $+
>       S> ABS U>D -2 (UD.R) $+
> ENDIF PUTS BL PUTCH ; PRIVATE

The above appears to be sci output to 3 decimal places.  Just replace with (FS.) ...

: NUM> ( F: r -- )
  3 (FS.)  PUTS  BL PUTCH ;

pi fs. 3.14159265358979E0  ok
pi num> 3.142E+00  ok
+inf num> +INF  ok




0
Ed
1/7/2014 1:43:23 AM
Elizabeth D. Rather wrote:
> On 1/4/14 4:26 PM, Ed wrote:
> > ...
> > '83 TYPE takes a signed count.  '94 changed it to unsigned.
>
> Were any systems broken that depended on a negative count? I didn't
> think so. The change allowed twice as long a string.
>
> > '83 WORD and
> > 11.8 Input Text indicates strings to 255 chars can be parsed followed by a trailing
> > blank.  '94 guarantees only 31 chars and excludes new programs from using
> > the trailing blank.  200x removed the blank altogether.
>
> Not sure what the 31 characters is about.

minimum WORD buffer size:
ANS  ...  31+2
'83  ...  255+2

> WORD makes a counted string.
> It did retain the blank but advertised it as "obsolescent" to allow a
> generation (of programs) to adapt before the blank was removed
> altogether. Again, I doubt that broke any existing programs.
>
> > '94 permitted separate
> > and common f/p stack.  200x excluded systems with a common f/p stack.
>
> The common f/p stack was retained in '94 mainly as a commitment to the
> Harris team and Chuck.
>
> > What is notable about these is that they add no new facility to Forth, nor fixed
> > any problem.  The only effect of these changes has been the removal features
> > and options Forth users once had, potentially breaking programs in the process.
>
> The TYPE change allowed strings twice as long. This was considered
> important because some people TYPE into a file. The integrated f/p stack
> was a feature that had to be documented and that one wasn't supposed to
> depend on. It still is, it's just that instead of being a documented
> option it's now an environmental restriction. I'm not at all sure about
> the value of these features or whether any actual programs were broken.

An extraordinary set of admissions.  The TC changes the behaviour of Standard
words and then asks users whether any actual programs were broken?  Honestly?
I'm aware of the TC dismissing alternatives to their own proposals citing it would
break programs because an obscure Forth used a word with the same name.

You ask what is broken?  Forth's credibility is broken.  You cannot expect people
to invest time and money in a language which chops and changes according to the
whims of "some people".



0
Ed
1/7/2014 1:45:30 AM
Stephen Pelc wrote:

> On Mon, 06 Jan 2014 21:51:10 +0100, Bernd Paysan <bernd.paysan@gmx.de>
> wrote:
> 
>>I redefined VFX's divison operators to the floored ones when porting
>>MINOS, because that way I got pixel-identical results.
> 
> Did you hide them from other people? No, you just don't care about
> other people's code. It's the ego problem again.

Yes, I do hide them from other people by using different names for those 
divisions; we discussed that.  I started by putting the redefinitions into 
the harness, because replacing every / and */ and friends in MINOS was quite 
some work.  I wanted to have results quickly, and this was also something 
that needed discussion.  Generally speaking, MINOS programs are graphics 
programs, so they want to have a floored division, too.  That was the idea 
of redefining the division words completely: with a GUI, you enter the world 
where division rounding starts to matter, and therefore, you need to tighten 
your spec.  All this lose spec where you don't know how non-corner-cases 
behave aren't any good.

Following the argument that floored division is only needed for those 
programs which do care, changing divisions to floored will not cause any 
malfunction in those programs that don't care.  That's our experience with 
the change from Gforth 0.6.2->0.7.0, where we went to floored division: zero 
complaints.  On the other hand, changing rounding mode from floored to 
symmetric causes known malfunction to the code-base I have, so that's a bad 
idea.

So to speak: Your choice of symmetric division shows that you don't care 
about other people's code.  It's the ego problem again.  Writing standard 
systems is just as much about ego as writing standard programs.  I know that 
MINOS is demanding.  You fixed the broken inliner.  You added C bindings 
with floating point parameters on the floating point stack.  You added 
floating point locals.  If I ported MINOS to SwiftForth, the same problems 
will show up again - most of them (SwiftForth has no fancy inliner).  And 
the same problems (with the exception of the inliner), *also* did show up 
when I wrote the OpenGL MINOS widget for bigForth.  This OpenGL stuff is 
just an external constraint, as it uses float everywhere.

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

0
Bernd
1/7/2014 2:29:35 AM
On 1/6/14 3:45 PM, Ed wrote:
> Elizabeth D. Rather wrote:
>> On 1/4/14 4:26 PM, Ed wrote:
>>> ...
>>> '83 TYPE takes a signed count.  '94 changed it to unsigned.
>>
>> Were any systems broken that depended on a negative count? I didn't
>> think so. The change allowed twice as long a string.
>>
>>> '83 WORD and
>>> 11.8 Input Text indicates strings to 255 chars can be parsed followed by a trailing
>>> blank.  '94 guarantees only 31 chars and excludes new programs from using
>>> the trailing blank.  200x removed the blank altogether.
>>
>> Not sure what the 31 characters is about.
>
> minimum WORD buffer size:
> ANS  ...  31+2
> '83  ...  255+2

Ok, I found that reference, which I had forgotten. However, minimum 
specifications don't "break" programs. Only on very small embedded 
systems will you see a WORD buffer thus limited, and if it will cause 
your program pain, you need to document an environmental requirement for 
a WORD buffer of at least <n> bytes. That program will probably run into 
other difficulties anyway.

....
>
> An extraordinary set of admissions.  The TC changes the behaviour of Standard
> words and then asks users whether any actual programs were broken?  Honestly?

We asked users (via first surveys and later public review periods) when 
we were contemplating the changes. My question quoted above was for you.

> I'm aware of the TC dismissing alternatives to their own proposals citing it would
> break programs because an obscure Forth used a word with the same name.
>
> You ask what is broken?  Forth's credibility is broken.  You cannot expect people
> to invest time and money in a language which chops and changes according to the
> whims of "some people".

The record of stability as well as system conformance since Forth94 has 
been exemplary. And a 6-year development period with users invited to 4 
meetings/year, all drafts published, and so many public review periods, 
can hardly be considered whimsical.

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."
==================================================
0
Elizabeth
1/7/2014 8:15:27 AM
On 07/01/2014 03:29, Bernd Paysan wrote:
> This OpenGL stuff is
> just an external constraint, as it uses float everywhere.
>

I'm afraid it's not only OpenGL. When you're using an Apple you'll see
floats for everything and all as well. The GUI, Quartz, audio, you name 
it (stack should be FP as default on a Mac ;) And then there are 32bit 
and 64bit floats, which leads to somewhat different OS interfaces for 
SF, VFX and i4. Quite a bit of mucking around integers and floats.
Yes, I consider them Fremdkorper as well. Treat them as a 
matter-of-fact. Anyway, an Apple interface running on (top of) the three 
mentioned Forth systems is doable. I let the Apple engineers draw my 
windows and menus, their bugs their responsibility. No additional work 
for Forth vendors needed. Keeping away from internals, not attempting to 
write standard programs, enjoying differences, keeping all ego's in tact :-)

Cheers,
-r
0
Roelf
1/7/2014 10:48:01 AM
On Tue, 07 Jan 2014 03:29:35 +0100, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

>So to speak: Your choice of symmetric division shows that you don't care 
>about other people's code.  It's the ego problem again.

No. It shows that the people I consulted disagreed with your position,
probably because they work in different application domains. Overall,
clients were happy to get the speed of symmetric division on CPUs
with divide instructions, albeit at the expense of having to be
explicit in graphics and motion applications.

Different application domains demand both symmetric and floored
division. Where it matters, it is no bad thing to have to be
explicit. The ANS TC probably made the right decision.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
0
stephenXXX
1/7/2014 12:58:10 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>No, only if you are doing something exceedingly odd: interactively
>programming a system, with no cross compiler,

Doing an ordinary Forth system is "exceedingly odd"?

> with the dictionary in
>flash.

Ok, that's a difference from the Forth system of the old days, but
"exceedingly odd"?

>Sure, you can do that, but I can't think of any reason that
>anyone would do it.

It's Forth!  It's a lot simpler than an umbilical/tethered
cross-development environment.  If your message is that people should
use a cross compiler instead of an ordinary Forth system, why should
they be using a Forth cross compiler instead of, say, a C cross
compiler (with some debugger for the interactivity)?

>I'm not saying that you're wrong to want to do
>that, but I am saying that edge case is not worth standardizing
><BUILDS for.

We standardized BUFFER: and N>R NR> for less.  The problem is not
standardizing <BUILDS, the problem would be in taking away the
guarantee that DOES> can be applied to CREATEd words.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/7/2014 1:33:46 PM
"Elizabeth D. Rather" <erather@forth.com> writes:
>[Forth] has successfully been 
>used in other areas, but is not competitive with languages developed 
>specifically for very different application areas such as (as Gavino 
>often reminds us) web development.

Well, technically it could be, and I think it has some benefits there,
at least compared to languages like Java and C++, because it's
relatively straightforward to have a mixture of content text and
Forth+web framework program.

But someone would have to write the web framework, and once it's
there, what would be it's selling point?  I.e., after being
technically competetive, how would we become competetive in marketing?
Other languages like PHP and Ruby are already well entrenched in this
application area, so technical ability alone is not sufficient.  You
would have to find a killer feature that the Forth web framework has
and that the others would find hard to replicate.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/7/2014 1:47:30 PM
Stephen Pelc wrote:

> On Tue, 07 Jan 2014 03:29:35 +0100, Bernd Paysan <bernd.paysan@gmx.de>
> wrote:
> 
>>So to speak: Your choice of symmetric division shows that you don't care
>>about other people's code.  It's the ego problem again.
> 
> No. It shows that the people I consulted disagreed with your position,
> probably because they work in different application domains. Overall,
> clients were happy to get the speed of symmetric division on CPUs
> with divide instructions, albeit at the expense of having to be
> explicit in graphics and motion applications.

The typical case (all values positive) has only a small difference.  It 
depends on the CPU you use (of course), but using a microbenchmark, the 
difference between fm/mod and sm/rem in VFX is 15% (loop overhead included).  
The tradeoffs and which instruction to use are processor-dependent; so while 
last time I measured, the processor was fastet for um/mod, on the Core i7 it 
is slowest on um/mod (fm/mod is faster).

> Different application domains demand both symmetric and floored
> division. Where it matters, it is no bad thing to have to be
> explicit. The ANS TC probably made the right decision.

I still haven't seen any application that really "demands" symmetric 
division in the sense of that it would not have correct answers otherwise 
(financial rounding is round to nearest even, with rules like "if the last 
digit is 5, round to nearest even, otherwise round to nearest" - this 
usually requires multiplying the nominator by 10, doing a floored division, 
dividing the result by 10 floored, and then checking for 5 and looking for 
the next even - certainly symmetric division would completely break this).  
I can understand that there are many programs where it doesn't matter, but 
those are rarely the kind of program with many divisions.

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

0
Bernd
1/7/2014 2:13:06 PM
"Ed" <invalid@invalid.com> writes:
>Anton Ertl wrote:
>> "Ed" <invalid@invalid.com> writes:
>> >Forth is empirically based.  It matters whether a majority of cases favour a
>> >particular solution.  It was this that drove the decision to make PICK and
>> >ROLL zero-based - even at the expense of breaking code.
>>
>> Please enlighten me about the empirical basis of "zero-based" PICK and
>> ROLL.
>
>When the index is computed, zero-based is optimum.

What index?  What do you compare with what?  Which metric are you
using?  What were your results?

>> >Short-term
>> >pain for long-term gain.
>>
>> Long-term pain for no gain.
>
>Clearly not.  PICK and ROLL have been zero-based since '83 and '94.
>Where are the long-term complaints?

There is still no smooth transition from Forth-79.

>> >Floored integer division favoured the majority of
>> >cases but completely ignored the reality of hardware division which was
>> >symmetric.  The result - long-term pain.
>>
>> What pain?
>
>How many times do you need to be reminded?
>
>Several vendors refused to adopt '83 division, opting for conventional division.

But the problem here was not the "reality of hardware division", but
the redefinition of words standardized by Forth-79 with a different
meaning.

>'94 chose a political compromise which even mathematicians saw as crazy.

Sure, mathematicians tend to like floored division, so some saw the
loosening of the spec done in Forth-94 as crazy.

It is instructive to compare what happened with flags to what happened
with division: In both cases Forth-83 changed the spec incompatibly,
and Forth-94 tried to fix the consequences.

For flags the Forth-83 representation was kept, but NOT (the word that
was affected by this change on the input side) was split into two
words: 0= (79's NOT) and INVERT (83's NOT).

For division Forth-94 loosened the specification of many words
(starting with / and MOD) and provided two additional, tight ones:
FM/MOD and SM/REM.

Now consider the alternative courses that Forth-94 could have taken in
these areas:

For flags it could have loosened the spec to allow systems to
implement either 1 or -1 as canonical flag representation, with NOT
working on the system's representation.  Or make canonical flags into
an opaque cell-wide data type that the system could implement as it
sees fit, with AND OR XOR working bitwise, and ?AND ?OR ?XOR ?NOT
working on flags.

I think these courses would be worse than the one chosen for Forth-94;
Many Forth programmers would have use the carnal knowledge about the
flag representation anyway, leading to portability bugs (and these
would probably have been hard to find and fix).

For division Forth-94 could have taken an approach similar to what
they did with NOT: destandardize all the existing division words / */
etc. and standardize symmetric and floored variants (say, /S /F */S
*/F etc.); and maybe have a don't-care variant (/X */X etc.).  This
would allow us now to see in how many cases people really want
symmetric division, floored division, or where they do not care.  That
might have given us a basis for a rational decision on what to
standardize, or we might still be in the situation where we don't find
consensus.

Currently the words with the old names (/ */ etc.) are the don't-care
words, and we have FM/MOD SM/REM as primitives for constructing the
floored and symmetric variants of these words.

I think the choices made in Forth-94 in the division area is also
good: The don't-care case is probably the most frequent (cases were
both operands are only ever positive), and we have a way to get at the
Forth-79 and Forth-83 behaviour if we ever really care about it.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/7/2014 2:13:58 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>No, only if you are doing something exceedingly odd: interactively
>>programming a system, with no cross compiler,
> 
> Doing an ordinary Forth system is "exceedingly odd"?

Don't be silly.

>>with the dictionary in flash.
> 
> Ok, that's a difference from the Forth system of the old days, but
> "exceedingly odd"?

I think so, yes.  Maybe there are many people doing it, but I doubt
that.

>>Sure, you can do that, but I can't think of any reason that
>>anyone would do it.
> 
> It's Forth!  It's a lot simpler than an umbilical/tethered
> cross-development environment.  If your message is that people
> should use a cross compiler instead of an ordinary Forth system, why
> should they be using a Forth cross compiler instead of, say, a C
> cross compiler (with some debugger for the interactivity)?

Because it's Forth, obviously.  It's not a debugger, it's an
interactive Forth system.  It doesn't look much different to the user
from a "normal" Forth.  The cross-compiling umbilical environment,
utilizing the (usually) much more powerful host, is so much better
than a traditional Forth environment on a small and slow target that I
can't think of any reason that anyone would do it any other way.  It's
faster, you don't need memory for headers, and there's almost nothing
loaded into the target that's not needed for the application.  What's
not to like, really?

>>I'm not saying that you're wrong to want to do that, but I am saying
>>that edge case is not worth standardizing <BUILDS for.
> 
> We standardized BUFFER: and N>R NR> for less.  The problem is not
> standardizing <BUILDS, the problem would be in taking away the
> guarantee that DOES> can be applied to CREATEd words.

Indeed.

Andrew.
0
Andrew
1/7/2014 2:44:45 PM
Bernd Paysan wrote:
> Ed wrote:
> > That's what FM/MOD is for.  The rest of the time conventional division
> > works fine because most division operations involve positive arguments.
>
> We have um/mod for positive arguments.  Following your argument, / should
> really be ( u1 u2 -- u3 ), because nobody needs / for negative numbers.

Nice try.  How many languages do you know don't support signed division.
Which function do you imagine languages will use to synthesize floored or
Euclidean division.





0
Ed
1/7/2014 3:20:23 PM
Anton Ertl wrote:
> We standardized BUFFER: and N>R NR> for less.  The problem is not
> standardizing <BUILDS, the problem would be in taking away the
> guarantee that DOES> can be applied to CREATEd words.

No, that would be an "environmental restriction".  This environmental 
restriction also comes with the restriction that you can use DOES> on 
<BUILDS only *once*.

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

0
Bernd
1/7/2014 5:41:02 PM
stephenXXX@mpeforth.com (Stephen Pelc) writes:
> Different application domains demand both symmetric and floored
> division. 

What's an example of an application that demands the arithmetic
properties of symmetric division?  Some applications choose it because
of the artifact that it's a little bit faster on some processors (I've
long wondered why that is) and they can accept the mathematical
weirdness.  Mathematically as far as I can tell, applications either
require floored division or else they don't care.  It's not just
graphics: anything involving modular arithmetic just about certainly
needs floored division.
0
Paul
1/7/2014 6:22:08 PM
On 1/7/14 3:33 AM, Anton Ertl wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> No, only if you are doing something exceedingly odd: interactively
>> programming a system, with no cross compiler,
>
> Doing an ordinary Forth system is "exceedingly odd"?
>
>> with the dictionary in
>> flash.
>
> Ok, that's a difference from the Forth system of the old days, but
> "exceedingly odd"?

Hardware platforms with RAM as limited as you find on many 
microcontroller boards are not comparable to the systems for which Forth 
was developed. Forth was designed for interactive development assuming a 
reasonable amount of RAM, a terminal, and read/write mass storage.

With the advent of microcontrollers, the Forth community has developed 
appropriate support systems including interactive cross-compilers that 
provide all the programming facilities and conveniences of a resident 
Forth even for very limited targets. If you care about getting the work 
done, you use the tool best suited for the task.

>> Sure, you can do that, but I can't think of any reason that
>> anyone would do it.
>
> It's Forth!  It's a lot simpler than an umbilical/tethered
> cross-development environment.  If your message is that people should
> use a cross compiler instead of an ordinary Forth system, why should
> they be using a Forth cross compiler instead of, say, a C cross
> compiler (with some debugger for the interactivity)?

Interactive cross-compilers are only slightly more complicated than 
resident Forths, and the resulting development capabilities are equally 
comfortable. And there is simply no comparison between the natural Forth 
interactivity and the comparatively formal, convoluted process supported 
by C tool chains and debuggers.

>> I'm not saying that you're wrong to want to do
>> that, but I am saying that edge case is not worth standardizing
>> <BUILDS for.
>
> We standardized BUFFER: and N>R NR> for less.  The problem is not
> standardizing <BUILDS, the problem would be in taking away the
> guarantee that DOES> can be applied to CREATEd words.

BUFFER: etc. are useful for everyone. <BUILDS is not.

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."
==================================================
0
Elizabeth
1/7/2014 6:48:08 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Paul Rubin <no.email@nospam.invalid> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>> One thing I'd say is the division of ANS94 words into core, extensions,
>>> Surely it's just good modular design.
>> 
>> Meh.  Imagine the C language being designed such that the WHILE
>> statement was part of core, but the FOR statement was an extension.
>
>I'm not sure that particular split would make sense, but well, yes.  C
>is just one big lump, Forth is modular.  That's one of the ways in
>which Forth is better.

Forth is better than C in many respects (e.g., saner implementors),
but what real-world advantage do we derive from this aspect of the
Forth standard?  Good modular design?  Has anybody ever replaced one
"module" with some alternative?  Or what's the advantage of this kind
of "modular design"?

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/8/2014 1:05:37 PM
m.a.m.hendrix@tue.nl writes:
> REPRESENT should have been fixed 
>in ANS-2000 and some kind of PLACES should have been introduced.

What is ANS-2000?  If you think REPRESENT needs fixing, how about
submitting a Forth-200x RfD?

However, given that REPRESENT is modeled on SUS/POSIX ecvt(), and ecvt()
has been destandardized with the recommendation to use the
higher-level sprintf() instead, maybe we should go for something
higher-level instead of fixing REPRESENT.

Looking at sprintf conversion specifications, it can contain (I have
trimmed the following by deleting stuff that does not concern FP
conversions or is specific to the "format string" mechanism of C):

conversion specifier:
| e,E    The  double  argument  is  rounded  and  converted  in the style
|        [-]d.ddde+-dd where there is one digit before the  decimal-point
|        character and the number of digits after it is equal to the pre-
|        cision; if the precision is missing, it is taken as  6;  if  the
|        precision  is  zero,  no  decimal-point character appears.  An E
|        conversion uses the letter E (rather than e)  to  introduce  the
|        exponent.   The exponent always contains at least two digits; if
|        the value is zero, the exponent is 00.
| f, F   The double argument is rounded and converted to decimal notation
|        in  the  style  [-]ddd.ddd, where the number of digits after the
|        decimal-point character is equal to the precision specification.
|        If  the precision is missing, it is taken as 6; if the precision
|        is explicitly zero, no decimal-point character  appears.   If  a
|        decimal point appears, at least one digit appears before it.
|
|        (The  SUSv2 does not know about F and says that character string
|        representations for infinity and NaN may be made available.  The
|        C99  standard  specifies "[-]inf" or "[-]infinity" for infinity,
|        and a string starting with "nan" for NaN, in the case of f  con-
|        version,  and "[-]INF" or "[-]INFINITY" or "NAN*" in the case of
|        F conversion.)
|
| g, G   The double argument is converted in style f or e (or F or E  for
|        G  conversions).  The precision specifies the number of signifi-
|        cant digits.  If the precision is missing, 6 digits  are  given;
|        if  the  precision is zero, it is treated as 1.  Style e is used
|        if the exponent from its conversion is less than -4  or  greater
|        than or equal to the precision.  Trailing zeros are removed from
|        the fractional part of the result; a decimal point appears  only
|        if it is followed by at least one digit.
|
| a, A   (C99;  not  in  SUSv2)  For a conversion, the double argument is
|        converted to hexadecimal notation (using the letters abcdef)  in
|        the  style  [-]0xh.hhhhp+-d; for A conversion the prefix 0X, the
|        letters ABCDEF, and the exponent separator P is used.  There  is
|        one  hexadecimal  digit before the decimal point, and the number
|        of digits after it is equal to the precision.  The default  pre-
|        cision  suffices  for an exact representation of the value if an
|        exact representation in base 2 exists and  otherwise  is  suffi-
|        ciently  large  to distinguish values of type double.  The digit
|        before the decimal point is unspecified for  nonnormalized  num-
|        bers,  and nonzero but otherwise unspecified for normalized num-
|        bers.

zero or more flags

| #      The value should be converted to an  "alternate  form". [...]
|        For a, A, e, E, f, F,  g,  and  G
|        conversions,  the  result  will  always contain a decimal point,
|        even if no digits follow it (normally, a decimal  point  appears
|        in  the  results  of those conversions only if a digit follows).
|        For g and G conversions, trailing zeros are not removed from the
|        result  as  they would otherwise be.  For other conversions, the
|        result is undefined.
|
| 0      The value should be zero padded.  For d, i, o, u, x, X, a, A, e,
|        E,  f, F, g, and G conversions, the converted value is padded on
|        the left with zeros rather than blanks.  If the 0  and  -  flags
|        both  appear,  the  0  flag is ignored.
|
| -      The  converted  value is to be left adjusted on the field bound-
|        ary.  (The default is right justification.)
|        [...] the  converted  value  is  padded  on  the right with
|        blanks, rather than on the left with blanks or zeros.  A - over-
|        rides a 0 if both are given.
|
| ' '    (a  space)  A  blank should be left before a positive number (or
|        empty string) produced by a signed conversion.
|
| +      A sign (+ or -) should always be placed before a number produced
|        by a signed conversion.  By default a sign is used only for neg-
|        ative numbers.  A + overrides a space if both are used.
|
| '      (SUSv2) For decimal conversion (i, d, u, f, F, g, G) the output
|        is to be grouped with thousands' grouping characters if the
|        locale information indicates any.
|
| I      (glibc 2.2) For  decimal  integer  conversion  (i, d, u) the
|        output uses the locale's alternative output digits, if any.
|        For example, since glibc 2.2.3 this will give Arabic-Indic
|        digits in the Persian ("fa_IR") locale.

an optional minimum field width
| If the converted value has fewer characters
| than the field width, it will be padded with spaces  on  the  left  (or
| right, if the left-adjustment flag has been given).  A negative
| field  width is taken as a '-' flag followed by a positive field width.
| In no case does a nonexistent or small field width cause truncation  of
| a  field;  if the result of a conversion is wider than the field width,
| the field is expanded to contain the conversion result.

an optional precision
| An optional decimal digit string (with nonzero first digit)  specifying
| a  minimum  field  width.   If the converted value has fewer characters
| than the field width, it will be padded with spaces  on  the  left  (or
| right, if the left-adjustment flag has been given).  Instead of a deci-
| mal digit string one may write "*" or "*m$" (for some  decimal  integer
| m) to specify that the field width is given in the next argument, or in
| the m-th argument, respectively, which must be of type int.  A negative
| field  width is taken as a '-' flag followed by a positive field width.
| In no case does a nonexistent or small field width cause truncation  of
| a  field;  if the result of a conversion is wider than the field width,
| the field is expanded to contain the conversion result.

Boy, that's a lot of options.  I can understand why they went for
ecvt()/fcvt() at first.  Maybe we should also be looking at Fortran.

In any case, whatever (FE.) is doing, I doubt that it can do
everything that sprintf() can do.

>On a related note, I see that David's IEEE-FP extentions also seem to have 
>been ignored completely (all present in iForth now). Apperently more urgent 
>standard matters needed fixing first.

No CfV on that has been submitted, and apparently the proponents want
to work on it some more.  Some of the stuff they seem to plan seems
overly ambitious to me; maybe they should strike at first for the
stuff that can be easily implemented, which has a better chance to be
adopted, and it is probably also easier to specify.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/8/2014 1:29:28 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
[ordinary Forth system with the dictionary in flash]
>I think so, yes.  Maybe there are many people doing it, but I doubt
>that.

Several systems have already been named.

>>>Sure, you can do that, but I can't think of any reason that
>>>anyone would do it.
>> 
>> It's Forth!  It's a lot simpler than an umbilical/tethered
>> cross-development environment.  If your message is that people
>> should use a cross compiler instead of an ordinary Forth system, why
>> should they be using a Forth cross compiler instead of, say, a C
>> cross compiler (with some debugger for the interactivity)?
>
>Because it's Forth, obviously.  It's not a debugger, it's an
>interactive Forth system.  It doesn't look much different to the user
>from a "normal" Forth.  The cross-compiling umbilical environment,
>utilizing the (usually) much more powerful host, is so much better
>than a traditional Forth environment on a small and slow target that I
>can't think of any reason that anyone would do it any other way.  It's
>faster, you don't need memory for headers, and there's almost nothing
>loaded into the target that's not needed for the application.  What's
>not to like, really?

1) The complexity.

2) The differences from an ordinary Forth system.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/8/2014 2:52:19 PM
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> We standardized BUFFER: and N>R NR> for less.  The problem is not
>> standardizing <BUILDS, the problem would be in taking away the
>> guarantee that DOES> can be applied to CREATEd words.
>
>No, that would be an "environmental restriction".  This environmental 
>restriction also comes with the restriction that you can use DOES> on 
><BUILDS only *once*.

Somehow standardizing a word (<BUILDS) that's intended to be used only
in the context of some environmental restrictions seems wrong.  

If a significant use case of <BUILDS is to only use DOES> on each
child once, then specify that in the specification.

Having two alternative ways to achieve the same thing in the standard,
with a number of systems not implementing one of the ways, and the
others preferring that way, does not look like a well-designed
standard either.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/8/2014 3:09:03 PM
"Elizabeth D. Rather" <erather@forth.com> writes:
>With the advent of microcontrollers, the Forth community has developed 
>appropriate support systems including interactive cross-compilers that 
>provide all the programming facilities and conveniences of a resident 
>Forth even for very limited targets.

"All the programming facilities and conveniences" includes, in
particular, that there is no language-specified line between
compilation and run-time; yet in such a cross-compilation system you
have this separation in two ways: The separation between target and
host, and the separation between development time (when the host is
connected to the target) and use time (when the target is on its own).

>If you care about getting the work 
>done, you use the tool best suited for the task.

And if that tool is a resident Forth that compiles to flash, you use
that.  So why again should the standard ignore this particular use
case?

>> We standardized BUFFER: and N>R NR> for less.  The problem is not
>> standardizing <BUILDS, the problem would be in taking away the
>> guarantee that DOES> can be applied to CREATEd words.
>
>BUFFER: etc. are useful for everyone.

I named these particular words because I find them utterly useless.
In particular, the justification for BUFFER: had to do with embedded
systems, and one could easily also call that an "edge case [...] not
worth standardizing".

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/8/2014 3:24:13 PM
Anton Ertl wrote:

> m.a.m.hendrix@tue.nl writes:
>> REPRESENT should have been fixed
>>in ANS-2000 and some kind of PLACES should have been introduced.
> 
> What is ANS-2000?  If you think REPRESENT needs fixing, how about
> submitting a Forth-200x RfD?
> 
> However, given that REPRESENT is modeled on SUS/POSIX ecvt(), and ecvt()
> has been destandardized with the recommendation to use the
> higher-level sprintf() instead, maybe we should go for something
> higher-level instead of fixing REPRESENT.

One severe problem of ecvt is that it is not thread-safe.  I just replaced 
ecvt with ecvt_r (this returns into a buffer provided by the caller), which 
is thread-safe.  ecvt_r is non-POSIX, so the configure replacement-check 
will hit more often, and I should think about using sprintf() for the 
replacement (though this requires some string parsing).  After all, the 
replacement I've written is just a simple stop-gap for systems without any 
ecvt...

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

0
Bernd
1/8/2014 3:30:34 PM
On 1/8/14 4:52 AM, Anton Ertl wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> [ordinary Forth system with the dictionary in flash]
>> I think so, yes.  Maybe there are many people doing it, but I doubt
>> that.
>
> Several systems have already been named.
>
>>>> Sure, you can do that, but I can't think of any reason that
>>>> anyone would do it.
>>>
>>> It's Forth!  It's a lot simpler than an umbilical/tethered
>>> cross-development environment.  If your message is that people
>>> should use a cross compiler instead of an ordinary Forth system, why
>>> should they be using a Forth cross compiler instead of, say, a C
>>> cross compiler (with some debugger for the interactivity)?
>>
>> Because it's Forth, obviously.  It's not a debugger, it's an
>> interactive Forth system.  It doesn't look much different to the user
>>from a "normal" Forth.  The cross-compiling umbilical environment,
>> utilizing the (usually) much more powerful host, is so much better
>> than a traditional Forth environment on a small and slow target that I
>> can't think of any reason that anyone would do it any other way.  It's
>> faster, you don't need memory for headers, and there's almost nothing
>> loaded into the target that's not needed for the application.  What's
>> not to like, really?
>
> 1) The complexity.
>
> 2) The differences from an ordinary Forth system.

The complexity isn't significantly greater than a regular Forth 
metacompiler. And, of course, it's only "complex" to the developer, not 
the user.

The differences from an "ordinary Forth system" are, from the POV of a 
user, very few, conceptually obvious, and operationally explained in 
just a few sentences. People who are using SwiftX for the first time 
pick it up very easily, in my experience.

Compared with the ongoing difficulty of working in an extremely 
resource-deprived environment, it's a piece of cake.

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."
==================================================
0
Elizabeth
1/8/2014 6:41:17 PM
On 1/8/14 5:24 AM, Anton Ertl wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> With the advent of microcontrollers, the Forth community has developed
>> appropriate support systems including interactive cross-compilers that
>> provide all the programming facilities and conveniences of a resident
>> Forth even for very limited targets.
>
> "All the programming facilities and conveniences" includes, in
> particular, that there is no language-specified line between
> compilation and run-time; yet in such a cross-compilation system you
> have this separation in two ways: The separation between target and
> host, and the separation between development time (when the host is
> connected to the target) and use time (when the target is on its own).

Operationally, that line is not so major. When you're connected to a 
target, you can type in a definition and execute it, examine target 
memory, do practically anything without special procedures. When your 
target is fully tested, you unplug the umbilical. That's it. I think 
you've never tried one, and are imagining difficulties that don't exist.

>> If you care about getting the work
>> done, you use the tool best suited for the task.
>
> And if that tool is a resident Forth that compiles to flash, you use
> that.  So why again should the standard ignore this particular use
> case?

It's not clear from this conversation that the standard needs to be 
changed to accomodate it.

>>> We standardized BUFFER: and N>R NR> for less.  The problem is not
>>> standardizing <BUILDS, the problem would be in taking away the
>>> guarantee that DOES> can be applied to CREATEd words.
>>
>> BUFFER: etc. are useful for everyone.
>
> I named these particular words because I find them utterly useless.
> In particular, the justification for BUFFER: had to do with embedded
> systems, and one could easily also call that an "edge case [...] not
> worth standardizing".

I see a lot of people using BUFFER: on resident Forths. For many years 
we took flack for not having a word that defines an array, and had to 
defensively show how easy it is to build an array with CREATE/ALLOT. A 
lot of people are happy with BUFFER: as a general capability.

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."
==================================================
0
Elizabeth
1/8/2014 6:50:46 PM
On 1/8/14 3:05 AM, Anton Ertl wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Paul Rubin <no.email@nospam.invalid> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>> One thing I'd say is the division of ANS94 words into core, extensions,
>>>> Surely it's just good modular design.
>>>
>>> Meh.  Imagine the C language being designed such that the WHILE
>>> statement was part of core, but the FOR statement was an extension.
>>
>> I'm not sure that particular split would make sense, but well, yes.  C
>> is just one big lump, Forth is modular.  That's one of the ways in
>> which Forth is better.
>
> Forth is better than C in many respects (e.g., saner implementors),
> but what real-world advantage do we derive from this aspect of the
> Forth standard?  Good modular design?  Has anybody ever replaced one
> "module" with some alternative?  Or what's the advantage of this kind
> of "modular design"?

Among other things, your Standard System can omit the wordsets that 
aren't relevant to your target customers, and easily document which you 
do and do not provide. Conversely, you can document which wordsets your 
Standard Program requires, and look for Systems that meet that requirement.

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."
==================================================
0
Elizabeth
1/8/2014 6:55:46 PM
Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>Anton Ertl wrote:
>>> We standardized BUFFER: and N>R NR> for less.  The problem is not
>>> standardizing <BUILDS, the problem would be in taking away the
>>> guarantee that DOES> can be applied to CREATEd words.
>>
>>No, that would be an "environmental restriction".  This environmental
>>restriction also comes with the restriction that you can use DOES> on
>><BUILDS only *once*.
> 
> Somehow standardizing a word (<BUILDS) that's intended to be used only
> in the context of some environmental restrictions seems wrong.

IMHO the wrong thing to do was to standardize a word that can be implemented 
with clever tricks only; the tricks becoming more clever with the 
restriction of the enviroment.  Both Gforth EC R8C and noForth manage to use 
normal CREATE for DOES> in a flash-programmed system, by deploying two 
different, clever tricks.  This sort of trickery is counter the "keep it 
stupid simple" philosophy of Forth.  <BUILDS is easy to implement straight-
forward.  The whole CREATE DOES> stuff is already more demanding than the 
entire rest of Forth, so why artificially make it even more complicated?

> If a significant use case of <BUILDS is to only use DOES> on each
> child once, then specify that in the specification.
> 
> Having two alternative ways to achieve the same thing in the standard,
> with a number of systems not implementing one of the ways, and the
> others preferring that way, does not look like a well-designed
> standard either.

Of course.  But what would be the alternative?  Use <BUILDS exclusively for 
DOES>?  That would break existing code.

The question here is: Why are the small embedded system programmers only 
losely following the standard?  Even though Forth is most popular in that 
niche?  The reason is that it is too hard to implement it.  Too hard does 
not mean "impossible", but requiring that sort of guru code only a few 
people will be able to write.

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

0
Bernd
1/8/2014 7:00:37 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>>With the advent of microcontrollers, the Forth community has developed 
>>appropriate support systems including interactive cross-compilers that 
>>provide all the programming facilities and conveniences of a resident 
>>Forth even for very limited targets.
> 
> "All the programming facilities and conveniences" includes, in
> particular, that there is no language-specified line between
> compilation and run-time; yet in such a cross-compilation system you
> have this separation in two ways: The separation between target and
> host, and the separation between development time (when the host is
> connected to the target) and use time (when the target is on its
> own).

That second one isn't a property of the cross-compilation system, but
of embedded development.

Andrew.
0
Andrew
1/8/2014 10:21:09 PM
On 1/8/2014 9:00 AM, Bernd Paysan wrote:
> The question here is: Why are the small embedded system programmers only
> losely following the standard?  Even though Forth is most popular in that
> niche?  The reason is that it is too hard to implement it.  Too hard does
> not mean "impossible", but requiring that sort of guru code only a few
> people will be able to write.

Not sure which programmers you're referring to, but that's why we were 
attempting to draft a cross-compiler standard based on the Forth 
standard. This project really needs to be revived!

Aloha,
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."
==================================================

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

0
Elizabeth
1/8/2014 10:45:42 PM
Elizabeth D. Rather wrote:

> On 1/8/2014 9:00 AM, Bernd Paysan wrote:
>> The question here is: Why are the small embedded system programmers only
>> losely following the standard?  Even though Forth is most popular in that
>> niche?  The reason is that it is too hard to implement it.  Too hard does
>> not mean "impossible", but requiring that sort of guru code only a few
>> people will be able to write.
> 
> Not sure which programmers you're referring to,

The people who implement Forth systems on small processors.  There are more 
of these small processors than gurus available, so you have to keep it 
simple.

> but that's why we were
> attempting to draft a cross-compiler standard based on the Forth
> standard. This project really needs to be revived!

Yes, but that's a different topic.

There are reasons why you want to have your Forth system in the target; if 
you use a umbilical system, you need to have the exact sources related to 
the device you are plugging into.  When it's just a normal Forth system, all 
you need is a terminal program.  Many Forth enthousiasts have worked that 
way for decades, and don't see a need to change.
 
-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

0
Bernd
1/8/2014 11:16:30 PM
In article <lak78m$5lc$1@online.de>, Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Anton Ertl wrote:
>>>> We standardized BUFFER: and N>R NR> for less.  The problem is not
>>>> standardizing <BUILDS, the problem would be in taking away the
>>>> guarantee that DOES> can be applied to CREATEd words.
>>>
>>>No, that would be an "environmental restriction".  This environmental
>>>restriction also comes with the restriction that you can use DOES> on
>>><BUILDS only *once*.
>>
>> Somehow standardizing a word (<BUILDS) that's intended to be used only
>> in the context of some environmental restrictions seems wrong.
>
>IMHO the wrong thing to do was to standardize a word that can be implemented
>with clever tricks only; the tricks becoming more clever with the
>restriction of the enviroment.  Both Gforth EC R8C and noForth manage to use
>normal CREATE for DOES> in a flash-programmed system, by deploying two
>different, clever tricks.  This sort of trickery is counter the "keep it
>stupid simple" philosophy of Forth.  <BUILDS is easy to implement straight-
>forward.  The whole CREATE DOES> stuff is already more demanding than the
>entire rest of Forth, so why artificially make it even more complicated?
>
>> If a significant use case of <BUILDS is to only use DOES> on each
>> child once, then specify that in the specification.
>>
>> Having two alternative ways to achieve the same thing in the standard,
>> with a number of systems not implementing one of the ways, and the
>> others preferring that way, does not look like a well-designed
>> standard either.
>
>Of course.  But what would be the alternative?  Use <BUILDS exclusively for
>DOES>?  That would break existing code.
>
>The question here is: Why are the small embedded system programmers only
>losely following the standard?  Even though Forth is most popular in that
>niche?  The reason is that it is too hard to implement it.  Too hard does
>not mean "impossible", but requiring that sort of guru code only a few
>people will be able to write.

Do they? As far as I can tell, the only deviations from ISO in noforth
are imposed by the hardware flash restrictions. There are no gratuitous
deviations, and there was some effort ( CREATE DOES> ) to implement some
standard words that are not trivial.
So it may be true for inhouse, build-your-own Forth's but not for Forth's
that are intended for publication.
(To my surprise noforth doesn't advertise itself as ISO, but even the
metacompiler and source are accepted by at least 4 Forth's. Even more if
I count 32/64 gForth on Intel/ARM separately, and 32/64 bits lina/wina.

>--
>Bernd Paysan

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

0
albert
1/9/2014 2:16:27 AM
"Elizabeth D. Rather" <erather@forth.com> writes:
>The complexity isn't significantly greater than a regular Forth 
>metacompiler.

But we are comparing with a resident system, not a metacompiler.

>And, of course, it's only "complex" to the developer, not 
>the user.

I assume you mean the Forth system developer and user, not the
application developer and user.  Anyway, one of the virtues of Forth
is that there need not be such a separation.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/9/2014 8:14:51 AM
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 1/8/14 5:24 AM, Anton Ertl wrote:
>> "All the programming facilities and conveniences" includes, in
>> particular, that there is no language-specified line between
>> compilation and run-time; yet in such a cross-compilation system you
>> have this separation in two ways: The separation between target and
>> host, and the separation between development time (when the host is
>> connected to the target) and use time (when the target is on its own).
>
>Operationally, that line is not so major. When you're connected to a 
>target, you can type in a definition and execute it, examine target 
>memory, do practically anything without special procedures. When your 
>target is fully tested, you unplug the umbilical. That's it. I think 
>you've never tried one, and are imagining difficulties that don't exist.

I have never tried one, true.  Maybe such systems know automatically
which of the data and code of, say, the parser generator Gray should
be put on the host, the target, or both, but I doubt it.

>I see a lot of people using BUFFER: on resident Forths. For many years 
>we took flack for not having a word that defines an array, and had to 
>defensively show how easy it is to build an array with CREATE/ALLOT. A 
>lot of people are happy with BUFFER: as a general capability.

Maybe, but given how easy it is to implement BUFFER: with CREATE and
ALLOT, I have my doubts that it would have been standardized if the
edge case did not exist.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/9/2014 8:28:05 AM
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 1/8/14 3:05 AM, Anton Ertl wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> I'm not sure that particular split would make sense, but well, yes.  C
>>> is just one big lump, Forth is modular.  That's one of the ways in
>>> which Forth is better.
>>
>> Forth is better than C in many respects (e.g., saner implementors),
>> but what real-world advantage do we derive from this aspect of the
>> Forth standard?  Good modular design?  Has anybody ever replaced one
>> "module" with some alternative?  Or what's the advantage of this kind
>> of "modular design"?
>
>Among other things, your Standard System can omit the wordsets that 
>aren't relevant to your target customers, and easily document which you 
>do and do not provide. Conversely, you can document which wordsets your 
>Standard Program requires, and look for Systems that meet that requirement.

That's a nice theory, but does it happen in practice?  Most (all?)
standard systems implement all wordsets, with some lossage, like
leaving some words away, implementing some words in a useless way, or
requiring arcane incantations to get some words.  Many standard
programs use a few words from this wordset and a few words from that
wordset, so why should documenting and checking whole wordsets be
particularly useful?

The most practical check for whether a system has all the words
required by a program is to just load the program on the system.

There are some people who write CORE programs as a puzzle-solving
exercise, but I don't see a real-world advantage in that.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/9/2014 8:49:25 AM
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Anton Ertl wrote:
>>>> We standardized BUFFER: and N>R NR> for less.  The problem is not
>>>> standardizing <BUILDS, the problem would be in taking away the
>>>> guarantee that DOES> can be applied to CREATEd words.
>>>
>>>No, that would be an "environmental restriction".  This environmental
>>>restriction also comes with the restriction that you can use DOES> on
>>><BUILDS only *once*.
>> 
>> Somehow standardizing a word (<BUILDS) that's intended to be used only
>> in the context of some environmental restrictions seems wrong.
>
>IMHO the wrong thing to do was to standardize a word that can be implemented 
>with clever tricks only

Maybe, but it's now standard and has been standard since Forth-79.  So
the question is how to proceed.  We could just stick with it and
continue rely on the ability of Forth implementors to come up with
clever tricks.  But if you want to standardize something that does not
need them, it should really provide portability; otherwise there is no
point in standardizing this.

>> Having two alternative ways to achieve the same thing in the standard,
>> with a number of systems not implementing one of the ways, and the
>> others preferring that way, does not look like a well-designed
>> standard either.
>
>Of course.  But what would be the alternative?  Use <BUILDS exclusively for 
>DOES>?  That would break existing code.

First consider the possible alternatives, then how to manage the
transition.

It seems to me that there are the following uses of CREATE:

1) without DOES> with uninitialized data: There is now BUFFER: for that.

2) without DOES> with initialized data.

3) with DOES> applied once to CREATE's child, and the child is not
  executed before the DOES> is applied.  That's the usual usage of
  DOES> and you suggest using <BUILDS instead of CREATE here.

4) others: child called, later DOES> applied to that child; more than
  one DOES> applied.  These uses are rare and you do not want to
  support them.

We could have different names for the CREATEs of the different use
cases.  Or maybe there is another way.

>The question here is: Why are the small embedded system programmers only 
>losely following the standard?  Even though Forth is most popular in that 
>niche?  The reason is that it is too hard to implement it.  Too hard does 
>not mean "impossible", but requiring that sort of guru code only a few 
>people will be able to write.

I believe that the reason is that the standard provides little benefit
to small embedded systems.  Porting programs?  That's not really going
to happen there.  And for programmer portability a loosely following
the standard is good enough.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/9/2014 9:10:43 AM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> "All the programming facilities and conveniences" includes, in
>> particular, that there is no language-specified line between
>> compilation and run-time; yet in such a cross-compilation system you
>> have this separation in two ways: The separation between target and
>> host, and the separation between development time (when the host is
>> connected to the target) and use time (when the target is on its
>> own).
>
>That second one isn't a property of the cross-compilation system, but
>of embedded development.

As soon as the developer and the user differ, that's a property of any
development.  But in Forth that's not reflected in the language; the
programmer can use all language facilities at development time and at
use time, so the boundary between these times can be shifted easily,
and the same code can be useful for both times.  That's not true for
cross-compilation systems.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/9/2014 9:39:32 AM
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> In article <lak78m$5lc$1@online.de>, Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>>Anton Ertl wrote:
>>
>>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>>Anton Ertl wrote:
>>>>> We standardized BUFFER: and N>R NR> for less.  The problem is not
>>>>> standardizing <BUILDS, the problem would be in taking away the
>>>>> guarantee that DOES> can be applied to CREATEd words.
>>>>
>>>>No, that would be an "environmental restriction".  This environmental
>>>>restriction also comes with the restriction that you can use DOES> on
>>>><BUILDS only *once*.
>>>
>>> Somehow standardizing a word (<BUILDS) that's intended to be used only
>>> in the context of some environmental restrictions seems wrong.
>>
>>IMHO the wrong thing to do was to standardize a word that can be implemented
>>with clever tricks only; the tricks becoming more clever with the
>>restriction of the enviroment.  Both Gforth EC R8C and noForth manage to use
>>normal CREATE for DOES> in a flash-programmed system, by deploying two
>>different, clever tricks.

But a flash-programmed system, as you describe it, cannot be standard
anyway, not just because of multiple DOES> but also because of FORGET
et al, although I'll grant those words aren't CORE .  On the face of
it, your argument -- that <BUILDS should be standard because it's
needed to simplify implementations in such an environment -- is
ludicrous.  There are tricks/techniques (your choice) that work in
that environment with CREATE ... DOES> .

>>This sort of trickery is counter the "keep it stupid simple"
>>philosophy of Forth.  <BUILDS is easy to implement straight-
>>forward.  The whole CREATE DOES> stuff is already more demanding
>>than the entire rest of Forth, so why artificially make it even more
>>complicated?

Because you have an environment that is so very odd as to need it.

Andrew.
0
Andrew
1/9/2014 10:18:22 AM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> "All the programming facilities and conveniences" includes, in
>>> particular, that there is no language-specified line between
>>> compilation and run-time; yet in such a cross-compilation system you
>>> have this separation in two ways: The separation between target and
>>> host, and the separation between development time (when the host is
>>> connected to the target) and use time (when the target is on its
>>> own).
>>
>>That second one isn't a property of the cross-compilation system, but
>>of embedded development.
> 
> As soon as the developer and the user differ, that's a property of
> any development.  But in Forth that's not reflected in the language;
> the programmer can use all language facilities at development time
> and at use time, so the boundary between these times can be shifted
> easily, and the same code can be useful for both times.  That's not
> true for cross-compilation systems.

In what sense?  What are these things that can't be done?

Embedded systems are often resource-constrained, and a correctly-sized
system for embedded developement won't have that much wasted RAM.  If
you're using a "conventional" interactive Forth you'll run out of
memory on the target long before you run out of memory for the
application.  Unblilical systems have a very small overhead, and mean
that you are working in an environment that is as close as possible to
the actual target system.

Andrew.
0
Andrew
1/9/2014 10:28:46 AM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>But a flash-programmed system, as you describe it, cannot be standard
>anyway, not just because of multiple DOES> but also because of FORGET
>et al, although I'll grant those words aren't CORE .

I cannot make any sense of this.  What do you mean?

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/9/2014 11:19:23 AM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> "All the programming facilities and conveniences" includes, in
>>>> particular, that there is no language-specified line between
>>>> compilation and run-time; yet in such a cross-compilation system you
>>>> have this separation in two ways: The separation between target and
>>>> host, and the separation between development time (when the host is
>>>> connected to the target) and use time (when the target is on its
>>>> own).
>>>
>>>That second one isn't a property of the cross-compilation system, but
>>>of embedded development.
>> 
>> As soon as the developer and the user differ, that's a property of
>> any development.  But in Forth that's not reflected in the language;
>> the programmer can use all language facilities at development time
>> and at use time, so the boundary between these times can be shifted
>> easily, and the same code can be useful for both times.  That's not
>> true for cross-compilation systems.
>
>In what sense?  What are these things that can't be done?

Consider the parser generator Gray.  Nothing in the program says what
parts are on the host and what are on the target, what runs at
develpment time and what runs at use time.  And if you want to add
such separation, what you would add depends on the way that it is
used.  In any case, that's not "all the programming facilities and
conveniences of a resident Forth".

>Embedded systems are often resource-constrained, and a correctly-sized
>system for embedded developement won't have that much wasted RAM.  If
>you're using a "conventional" interactive Forth you'll run out of
>memory on the target long before you run out of memory for the
>application.  Unblilical systems have a very small overhead, and mean
>that you are working in an environment that is as close as possible to
>the actual target system.

Sure, if you want the minimal hardware for your application, you may
be willing to forego some of the benefits of a full Forth system and
make do with a cross-development system, but that does not make a full
Forth system "exceedingly odd".

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/9/2014 11:27:49 AM
Anton Ertl wrote:
> "Ed" <invalid@invalid.com> writes:
> >Anton Ertl wrote:
> > ...
> >> Please enlighten me about the empirical basis of "zero-based" PICK and
> >> ROLL.
> >
> >When the index is computed, zero-based is optimum.
>
> What index?  What do you compare with what?  Which metric are you
> using?

Observation and experience.

>What were your results?

Zero-based was better.  How could it be otherwise.

> >> Long-term pain for no gain.
> >
> >Clearly not.  PICK and ROLL have been zero-based since '83 and '94.
> >Where are the long-term complaints?
>
> There is still no smooth transition from Forth-79.

'No long-term complaints' sounds smooth to me.

> For division Forth-94 could have taken an approach similar to what
> they did with NOT: destandardize all the existing division words / */
> etc. and standardize symmetric and floored variants (say, /S /F */S
> */F etc.); and maybe have a don't-care variant (/X */X etc.).  This
> would allow us now to see in how many cases people really want
> symmetric division, floored division, or where they do not care.  That
> might have given us a basis for a rational decision on what to
> standardize, or we might still be in the situation where we don't find
> consensus.
>
> Currently the words with the old names (/ */ etc.) are the don't-care
> words, and we have FM/MOD SM/REM as primitives for constructing the
> floored and symmetric variants of these words.
>
> I think the choices made in Forth-94 in the division area is also
> good: The don't-care case is probably the most frequent (cases were
> both operands are only ever positive), and we have a way to get at the
> Forth-79 and Forth-83 behaviour if we ever really care about it.

Time has done what '94 couldn't and today virtually all Forth systems use
symmetric division.  Case closed.




0
Ed
1/9/2014 12:19:16 PM
Anton Ertl wrote:

> I believe that the reason is that the standard provides little benefit
> to small embedded systems.  Porting programs?  That's not really going
> to happen there.

Porting programmers.  People read Forth introduction material that is using 
the standard.

> And for programmer portability a loosely following
> the standard is good enough.

All those implementors of small embedded systems I know try to follow the 
standard where it's easy to do.  Some even invent clever tricks to be 
standard-compliant except for some arcane usage (like multiple DOES> on a 
create with intermediate execution of that word).  So people like Albert 
Nijhof and Willem Ouwerkerk or I manage to create completely standard 
embedded systems; others fail at some corner cases, or at least want support 
for some things like BUFFER:, which we already standardized.

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

0
Bernd
1/9/2014 1:37:19 PM
Anton Ertl wrote:

>>Embedded systems are often resource-constrained, and a correctly-sized
>>system for embedded developement won't have that much wasted RAM.  If
>>you're using a "conventional" interactive Forth you'll run out of
>>memory on the target long before you run out of memory for the
>>application.  Unblilical systems have a very small overhead, and mean
>>that you are working in an environment that is as close as possible to
>>the actual target system.
> 
> Sure, if you want the minimal hardware for your application, you may
> be willing to forego some of the benefits of a full Forth system and
> make do with a cross-development system, but that does not make a full
> Forth system "exceedingly odd".

Let me throw in some less than hypothetical experience:  On systems like the 
b16, with program binary sizes of usually 2k, I do use cross compiling, and 
the b16 cross assembler actually contains an umbilical system, i.e. you can 
interactively upload (and execute) single lines of code.  However, this is 
only Forth-like, not real Forth, and it definitely feels different.

On systems with 16k of flash, the constraints are much weaker, and you can 
actually use the normal interactive programming style, including extending 
the compiler and such.

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

0
Bernd
1/9/2014 1:42:46 PM
Andrew Haley wrote:
> But a flash-programmed system, as you describe it, cannot be standard
> anyway, not just because of multiple DOES> but also because of FORGET
> et al, although I'll grant those words aren't CORE .

Words not in CORE don't count.  You won't have floating point, you won't 
have file words.  It's still standard.  You can read a typical introduction 
to Forth, which focuses on CORE words, and things work on your target.

Some of these systems actually have MARKER (which wastes at most one flash 
page), most of them have EMPTY (that's resetting the system, removing all 
user-defined words); this is much better than FORGET for such an 
environment.

Multiple DOES> is something you can easily avoid.

> On the face of
> it, your argument -- that <BUILDS should be standard because it's
> needed to simplify implementations in such an environment -- is
> ludicrous.  There are tricks/techniques (your choice) that work in
> that environment with CREATE ... DOES> .

We standardized BUFFER: for much less, the trickery to implement something 
similar to BUFFER: is much easier to do.  Why are you so violently opposing 
this one?  Because it requires to acknowledge that merging <BUILDS and 
CREATE was a mistake?  Come on!  Were you personally involved in this 
mistake?

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

0
Bernd
1/9/2014 1:50:16 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>But a flash-programmed system, as you describe it, cannot be standard
>>anyway, not just because of multiple DOES> but also because of FORGET
>>et al, although I'll grant those words aren't CORE .
> 
> I cannot make any sense of this.  What do you mean?

The system that Bernd described can't do e.g. FORGET, because a while
page has to be erased.

Andrew.
0
Andrew
1/9/2014 3:04:28 PM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>> On the face of it, your argument -- that <BUILDS should be standard
>> because it's needed to simplify implementations in such an
>> environment -- is ludicrous.  There are tricks/techniques (your
>> choice) that work in that environment with CREATE ... DOES> .
> 
> We standardized BUFFER: for much less, the trickery to implement
> something similar to BUFFER: is much easier to do.

There's no portable way to do it, though.

> Why are you so violently opposing this one?  Because it requires to
> acknowledge that merging <BUILDS and CREATE was a mistake?  Come on!
> Were you personally involved in this mistake?

No, I was not: it was before my time.  I think it was a brilliant
idea, and far too valuable to miss because of some marginal systems,
and besides that, they can implement CREATE ... DOES anyway.  The only
problem is that you don't like the way that has to be done.

Andrew.
0
Andrew
1/9/2014 3:08:34 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> "All the programming facilities and conveniences" includes, in
>>>>> particular, that there is no language-specified line between
>>>>> compilation and run-time; yet in such a cross-compilation system
>>>>> you have this separation in two ways: The separation between
>>>>> target and host, and the separation between development time
>>>>> (when the host is connected to the target) and use time (when
>>>>> the target is on its own).
>>>>
>>>>That second one isn't a property of the cross-compilation system, but
>>>>of embedded development.
>>> 
>>> As soon as the developer and the user differ, that's a property of
>>> any development.  But in Forth that's not reflected in the language;
>>> the programmer can use all language facilities at development time
>>> and at use time, so the boundary between these times can be shifted
>>> easily, and the same code can be useful for both times.  That's not
>>> true for cross-compilation systems.
>>
>>In what sense?  What are these things that can't be done?
> 
> Consider the parser generator Gray.  Nothing in the program says what
> parts are on the host and what are on the target, what runs at
> develpment time and what runs at use time.  And if you want to add
> such separation, what you would add depends on the way that it is
> used.  In any case, that's not "all the programming facilities and
> conveniences of a resident Forth".

I see what you mean.  I don't think I ever said that no changes would
be required to code.

>>Embedded systems are often resource-constrained, and a correctly-sized
>>system for embedded developement won't have that much wasted RAM.  If
>>you're using a "conventional" interactive Forth you'll run out of
>>memory on the target long before you run out of memory for the
>>application.  Unblilical systems have a very small overhead, and mean
>>that you are working in an environment that is as close as possible to
>>the actual target system.
> 
> Sure, if you want the minimal hardware for your application, you may
> be willing to forego some of the benefits of a full Forth system and
> make do with a cross-development system, but that does not make a
> full Forth system "exceedingly odd".

It makes it an exceedingly odd *choice* for those of us who have used
(and love) umbilical Forths.  Having been involved in developing such
systems in 1988 and having described the techniques to eveyone who
would listen, I still look on with blank amazement at people who
develop on small embedded systems and don't use them.  As Elizabeth
says, it's a far better and more enjoyable environment than running a
full Forth system down there and taklking to it over a serial link.
In that sense, you aren't foregoing anything.  The time taken to port
stuff to such an environment (if any) is IME much less than what you
gain from having a much nicer (IMO, YMMV, etc.) system to use.

Andrew.
0
Andrew
1/9/2014 3:40:27 PM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Anton Ertl wrote:
> 
>>>Embedded systems are often resource-constrained, and a correctly-sized
>>>system for embedded developement won't have that much wasted RAM.  If
>>>you're using a "conventional" interactive Forth you'll run out of
>>>memory on the target long before you run out of memory for the
>>>application.  Unblilical systems have a very small overhead, and mean
>>>that you are working in an environment that is as close as possible to
>>>the actual target system.
>> 
>> Sure, if you want the minimal hardware for your application, you may
>> be willing to forego some of the benefits of a full Forth system and
>> make do with a cross-development system, but that does not make a full
>> Forth system "exceedingly odd".
> 
> Let me throw in some less than hypothetical experience:  On systems like the 
> b16, with program binary sizes of usually 2k, I do use cross compiling, and 
> the b16 cross assembler actually contains an umbilical system, i.e. you can 
> interactively upload (and execute) single lines of code.  However, this is 
> only Forth-like, not real Forth, and it definitely feels different.
> 
> On systems with 16k of flash, the constraints are much weaker, and
> you can actually use the normal interactive programming style,
> including extending the compiler and such.

If your cross-compiler doesn't allow you to use the normal interactive
programming style and easily to extend the compiler, then you
cross-compiler is *broken*.

Andrew.
0
Andrew
1/9/2014 3:41:53 PM
Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Andrew Haley wrote:
>>> On the face of it, your argument -- that <BUILDS should be standard
>>> because it's needed to simplify implementations in such an
>>> environment -- is ludicrous.  There are tricks/techniques (your
>>> choice) that work in that environment with CREATE ... DOES> .
>> 
>> We standardized BUFFER: for much less, the trickery to implement
>> something similar to BUFFER: is much easier to do.
> 
> There's no portable way to do it, though.

CREATE ALLOT is 100% portable.  The point for why a BSS segment is needed is 
that you don't want to store tons of zeros.  But the amount of "trickery" 
necessary to compress (and expand) long runs of zeros in you image, which 
you have to copy to RAM anyways at startup is very small, and it will 
compress all zero-initialized stuff regardless how it was allocated.

>> Why are you so violently opposing this one?  Because it requires to
>> acknowledge that merging <BUILDS and CREATE was a mistake?  Come on!
>> Were you personally involved in this mistake?
> 
> No, I was not: it was before my time.  I think it was a brilliant
> idea, and far too valuable to miss because of some marginal systems,
> and besides that, they can implement CREATE ... DOES anyway.  The only
> problem is that you don't like the way that has to be done.

It's not just about not liking that way, it's about imposing things on 
implementors that can be quite difficult to achieve.  This sort of thing 
should not go into a standard, especially not a Forth standard (you can put 
very difficult to implement stuff into C++ or Java if you like; these are 
language standards with very few people actually writing compilers).  Almost 
anything in Forth is very easy to achieve and to implement, and as BUFFER: 
above shows, we encourage people to code hints to the system so that it is 
easier to implement the system.

So I still don't understand this violent opposition to <BUILDS, whereas you 
apparently seem to like a completely superfluous word like BUFFER:.  
Implement RLE compression on your initialized data, and you'd be done.  
Expanding RLE is really trivial, and when you do a high-quality compression, 
it will provide way more opportunity to compress your image than BUFFER:.

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

0
Bernd
1/9/2014 5:33:54 PM
Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Anton Ertl wrote:
>> On systems with 16k of flash, the constraints are much weaker, and
>> you can actually use the normal interactive programming style,
>> including extending the compiler and such.
> 
> If your cross-compiler doesn't allow you to use the normal interactive
> programming style and easily to extend the compiler, then you
> cross-compiler is *broken*.

Of course the cross compiler is easily extensible, but the extensions are 
far away from normal Forth style.  E.g. if you write a compiler macro in my 
b16 cross compiler, you say macro: <name> ... end-macro.

It's probably that Forth's way to write compiler macros (with normal colon 
definition, flagged immediate) is actually the broken thing, and the cross 
compiler syntax is the right thing.

However, the b16 cross compiler does not need a target attached; it is for 
off-line as well as for on-line use.  So normally the constraint for a 
program is that it muss compile off-line.  This is not very harmful, as you 
have a full-blown hosted Forth system to access.

There are a number of other things different from a normal Forth; command 
line execution compiles one line, transfers it to the target, and execute it 
in total.  So you can do all sort of control flow stuff you can't do on a 
normal Forth.  Command line mode however is different from programming mode.

Given that b16.fs (umbilical cross-compiler) is just a few hundret lines of 
code, all the differences to standard Forth are there for ease of 
implementation, and there are a lot of those differences.

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

0
Bernd
1/9/2014 5:44:50 PM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
> 
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> Andrew Haley wrote:
>>>> On the face of it, your argument -- that <BUILDS should be standard
>>>> because it's needed to simplify implementations in such an
>>>> environment -- is ludicrous.  There are tricks/techniques (your
>>>> choice) that work in that environment with CREATE ... DOES> .
>>> 
>>> We standardized BUFFER: for much less, the trickery to implement
>>> something similar to BUFFER: is much easier to do.
>> 
>> There's no portable way to do it, though.
> 
> CREATE ALLOT is 100% portable.  The point for why a BSS segment is
> needed is that you don't want to store tons of zeros.  But the
> amount of "trickery" necessary to compress (and expand) long runs of
> zeros in you image, which you have to copy to RAM anyways at startup
> is very small, and it will compress all zero-initialized stuff
> regardless how it was allocated.
>
>>> Why are you so violently opposing this one?  Because it requires to
>>> acknowledge that merging <BUILDS and CREATE was a mistake?  Come on!
>>> Were you personally involved in this mistake?
>> 
>> No, I was not: it was before my time.  I think it was a brilliant
>> idea, and far too valuable to miss because of some marginal systems,
>> and besides that, they can implement CREATE ... DOES anyway.  The only
>> problem is that you don't like the way that has to be done.
> 
> It's not just about not liking that way, it's about imposing things
> on implementors that can be quite difficult to achieve.  This sort
> of thing should not go into a standard, especially not a Forth
> standard (you can put very difficult to implement stuff into C++ or
> Java if you like; these are language standards with very few people
> actually writing compilers).  Almost anything in Forth is very easy
> to achieve and to implement, and as BUFFER: above shows, we
> encourage people to code hints to the system so that it is easier to
> implement the system.
> 
> So I still don't understand this violent opposition to <BUILDS,
> whereas you apparently seem to like a completely superfluous word
> like BUFFER:.  Implement RLE compression on your initialized data,
> and you'd be done.  Expanding RLE is really trivial, and when you do
> a high-quality compression, it will provide way more opportunity to
> compress your image than BUFFER:.

I guess I don't much care about BUFFER, but do care about CREATE
.... DOES> .

BUFFER: seems mostly harmless, and makes sense on some embedded
systems.  All this talk about BSS is bizarre, given that BUFFER: is
explicitly uninitialized.  In a real-time system you may not have time
to zero anything.

Andrew.
0
Andrew
1/9/2014 6:32:22 PM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
> 
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> Anton Ertl wrote:
>>> On systems with 16k of flash, the constraints are much weaker, and
>>> you can actually use the normal interactive programming style,
>>> including extending the compiler and such.
>> 
>> If your cross-compiler doesn't allow you to use the normal interactive
>> programming style and easily to extend the compiler, then you
>> cross-compiler is *broken*.
> 
> Of course the cross compiler is easily extensible, but the
> extensions are far away from normal Forth style.  E.g. if you write
> a compiler macro in my b16 cross compiler, you say macro: <name>
> ... end-macro.
> 
> It's probably that Forth's way to write compiler macros (with normal
> colon definition, flagged immediate) is actually the broken thing,
> and the cross compiler syntax is the right thing.
> 
> However, the b16 cross compiler does not need a target attached; it
> is for off-line as well as for on-line use.  So normally the
> constraint for a program is that it muss compile off-line.  This is
> not very harmful, as you have a full-blown hosted Forth system to
> access.

Sure.

> There are a number of other things different from a normal Forth;
> command line execution compiles one line, transfers it to the
> target, and execute it in total.  So you can do all sort of control
> flow stuff you can't do on a normal Forth.  Command line mode
> however is different from programming mode.

I refer you again to my article of 1988, which explains (IMO, YMMV)
the right way to do it, and doesn't require a "command line mode".

Andrew.
0
Andrew
1/9/2014 6:35:13 PM
In article <cs6dnavurarz6lPPnZ2dnUVZ_rudnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>> In article <lak78m$5lc$1@online.de>, Bernd Paysan
><bernd.paysan@gmx.de> wrote:
>>>Anton Ertl wrote:
>>>
>>>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>>>Anton Ertl wrote:
>>>>>> We standardized BUFFER: and N>R NR> for less.  The problem is not
>>>>>> standardizing <BUILDS, the problem would be in taking away the
>>>>>> guarantee that DOES> can be applied to CREATEd words.
>>>>>
>>>>>No, that would be an "environmental restriction".  This environmental
>>>>>restriction also comes with the restriction that you can use DOES> on
>>>>><BUILDS only *once*.
>>>>
>>>> Somehow standardizing a word (<BUILDS) that's intended to be used only
>>>> in the context of some environmental restrictions seems wrong.
>>>
>>>IMHO the wrong thing to do was to standardize a word that can be implemented
>>>with clever tricks only; the tricks becoming more clever with the
>>>restriction of the enviroment.  Both Gforth EC R8C and noForth manage to use
>>>normal CREATE for DOES> in a flash-programmed system, by deploying two
>>>different, clever tricks.
>
>But a flash-programmed system, as you describe it, cannot be standard
>anyway, not just because of multiple DOES> but also because of FORGET
>et al, although I'll grant those words aren't CORE .  On the face of
>it, your argument -- that <BUILDS should be standard because it's
>needed to simplify implementations in such an environment -- is
>ludicrous.  There are tricks/techniques (your choice) that work in
>that environment with CREATE ... DOES> .

FORGET is obsolescent. noforth supplies MARKER that replaces it.
It is urban legend that MARKER couldn't be supplied transparently with
a Forth in flash.

>
>>>This sort of trickery is counter the "keep it stupid simple"
>>>philosophy of Forth.  <BUILDS is easy to implement straight-
>>>forward.  The whole CREATE DOES> stuff is already more demanding
>>>than the entire rest of Forth, so why artificially make it even more
>>>complicated?
>
>Because you have an environment that is so very odd as to need it.
>
>Andrew.
-- 
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

0
albert
1/9/2014 8:49:28 PM
Andrew Haley wrote:

> I refer you again to my article of 1988, which explains (IMO, YMMV)
> the right way to do it, and doesn't require a "command line mode".

Do you have it online somewhere? 1988 is a bit old ;-).  The "command line 
mode" of the b16 cross compiler is a one-liner, so the tradeoffs made here 
was the shortest possible code that could give an interactive command line.

The whole b16 project was started to find out how Chuck's new ideas fit in, 
and accept significant deviations from classical Forth for the sake of 
simplicy.

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

0
Bernd
1/9/2014 11:20:14 PM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
> 
>> I refer you again to my article of 1988, which explains (IMO, YMMV)
>> the right way to do it, and doesn't require a "command line mode".
> 
> Do you have it online somewhere? 1988 is a bit old ;-).  The "command line 
> mode" of the b16 cross compiler is a one-liner, so the tradeoffs made here 
> was the shortest possible code that could give an interactive command line.

No, I don't, and it is a bit old.  Twenty-five years ago, sigh.  :-)
I'll explain it.

Let's say the aim is to be able to run an interactive cross-compiler
with no separate command line mode.  It's just normal Forth
interaction, as closely as possible, but with cross-compiled code.

So, the aim is to be able to do:

: foo + ;
1 2 foo . 3 ok

This is how it works:

: is a cross-compiler word which is executed on the host and generates
target code into a buffer.  : also defines a dictionary entry for foo
on the host.  This is normal cross-compiler stuff.  What's different
is that if the target is online we also download the code as we go
along, if that's possible.

1 and 2 are not found as words, so are converted to numbers by the
host.

foo is found on the host.  Its runtime host action is to copy the
stack from the host to the target, tell the target to execute its code
for foo, and return the stack.

.. is not found on the target.  It is executed on the host.

Andrew.
0
Andrew
1/10/2014 11:22:55 AM
On Friday, January 10, 2014 12:22:55 PM UTC+1, Andrew Haley wrote:
> Bernd Paysan <bernd.paysan@gmx.de> wrote: 
> Andrew Haley wrote: 
[..]
> Let's say the aim is to be able to run an interactive cross-compiler 
> with no separate command line mode. 
> It's just normal Forth interaction, as closely as possible, 
> but with cross-compiled code. So, the aim is to be able to do: 
> : foo + ; 1 2 foo . 3 ok This is how it works: 
[..]

What about:  ' foo execute  (First: I assume that both host and
target have EXECUTE . Second: note that the stack is empty).

Another question:  here 3 , 4 ,  c@ emit ( or 100 dump )

-marcel


-marcel

0
m
1/10/2014 11:48:39 AM
On Friday, January 3, 2014 10:43:28 PM UTC+2, Bernd Paysan wrote:
  There's not much 
> 
> to be done there, but there are AVR Forths out there which do emulate a 
> 
> unified memory space.  You can still use larger AVRs with 128k flash by 
> 
> having your data memory in the first 64k of the flash (minus the 16k RAM), 
> 
> and the code in the second 64k.  The cost of being standard is one compare 
> 
> and branch per @ and !, and it's really not worth to wrap the standard 
> 
> around this sort of weird architecture.
> 
I just need to add to the CREATE  DOES> and flash microcontroller discussion how happy I am with design decisions I have taken with FlashForth.

Writing to flash can be done in a random fashion, so that there is no problem implementing CREATE DOES> or even a peephole optimiser.

In FlashForth the address space is virtualized inside @ ! for Harvard Arctitectures.

When writing to flash the page is modified in a ram buffer which eventually is flushed to flash when the page is full and before ACCEPT in QUIT.

As an optimization the flush is only performed in interpretive state so that compilation of multiline words do not flush until the definition is complete.

@ will read the data from the buffer or from flash directly depending on the buffer status. 

This virtualization makes memory access slower but the overhead is quite small.
Just one compare before actually accessing ram.
Most of the CPU time is spent in the inner interpreter not inside @ or ! . And there is always the assembler.


-- Mike

http://flashforth.sourceforge.net (Atmega, PIC18-24-30-33)

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

0
oh2aun
1/10/2014 2:46:53 PM
m.a.m.hendrix@tue.nl wrote:
> On Friday, January 10, 2014 12:22:55 PM UTC+1, Andrew Haley wrote:
>> Bernd Paysan <bernd.paysan@gmx.de> wrote: 
>> Andrew Haley wrote: 
> [..]
>> Let's say the aim is to be able to run an interactive cross-compiler 
>> with no separate command line mode. 
>> It's just normal Forth interaction, as closely as possible, 
>> but with cross-compiled code. So, the aim is to be able to do: 
>> : foo + ; 1 2 foo . 3 ok This is how it works: 
> [..]
> 
> What about:  ' foo execute  (First: I assume that both host and
> target have EXECUTE . Second: note that the stack is empty).

The host has a ' for target words which returns the correct address
for the target's EXECUTE .

> Another question:  here 3 , 4 ,  c@ emit ( or 100 dump )

Again, the host has a HERE that returns HERE for the target, i.e. the
one that , uses.  And there is a DUMP that dumps target memory.

There are some scenarios where some assistance is required from the
user: for instance, if you want a version of : that creates a word on
the host, you'll have to say HOST : .  But this is all normal Forth
cross-compiler stuff.

Andrew.
0
Andrew
1/10/2014 3:31:33 PM
"Ed" <invalid@invalid.com> writes:
>Anton Ertl wrote:
>> "Ed" <invalid@invalid.com> writes:
>> >Anton Ertl wrote:
>> > ...
>> >> Please enlighten me about the empirical basis of "zero-based" PICK and
>> >> ROLL.
>> >
>> >When the index is computed, zero-based is optimum.
>>
>> What index?  What do you compare with what?  Which metric are you
>> using?
>
>Observation and experience.

Ok, so you do not explain what you mean with "index" or "optimum", and
you do not want to give any information on how to reproduce your
results.  Do you want anyone to take you seriously?

>> I think the choices made in Forth-94 in the division area is also
>> good: The don't-care case is probably the most frequent (cases were
>> both operands are only ever positive), and we have a way to get at the
>> Forth-79 and Forth-83 behaviour if we ever really care about it.
>
>Time has done what '94 couldn't and today virtually all Forth systems use
>symmetric division.  Case closed.

A friend of mine said that "virtually" is a synonym for "not".  Gforth
implements floored division for / MOD etc.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/10/2014 5:19:37 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>But a flash-programmed system, as you describe it, cannot be standard
>>>anyway, not just because of multiple DOES> but also because of FORGET
>>>et al, although I'll grant those words aren't CORE .
>> 
>> I cannot make any sense of this.  What do you mean?
>
>The system that Bernd described can't do e.g. FORGET, because a while
>page has to be erased.

Well, first of all FORGET is not necessary for a standard system.
E.g., Gforth does not implement it.

Second, FORGET is perfectly possible on such a system: Only erase
pages that only contain forgotten stuff, and then set the flash
dictionary pointer to the start of the first erased page.  Yes, some
forgotten stuff will stay in flash; So what?  Flash is not tight on
these systems, and if it is, just don't use FORGET.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/10/2014 5:27:35 PM
On 1/10/14 7:19 AM, Anton Ertl wrote:
> "Ed" <invalid@invalid.com> writes:
>> Anton Ertl wrote:
>>> "Ed" <invalid@invalid.com> writes:
>>>> Anton Ertl wrote:
>>>> ...
>>>>> Please enlighten me about the empirical basis of "zero-based" PICK and
>>>>> ROLL.
>>>>
>>>> When the index is computed, zero-based is optimum.
>>>
>>> What index?  What do you compare with what?  Which metric are you
>>> using?
>>
>> Observation and experience.
>
> Ok, so you do not explain what you mean with "index" or "optimum", and
> you do not want to give any information on how to reproduce your
> results.  Do you want anyone to take you seriously?

Ok, consider:

10 CONSTANT SIZE
CREATE DATA SIZE CELLS ALLOT
: SHOW ( -- ) SIZE 0 DO  DATA I + @ . LOOP ;

Indexing here is zero-based. If it were 1-based, you'd have to say,
      SIZE 1+ 1 DO...

which is awkward. So, that's how we normally think of indexing: 0 is the 
index of the start of whatever. Therefore, 0 PICK would be the TOS 
(ignoring the argument to PICK) plus 0, or DUP.

I believe that's what Ed meant.

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."
==================================================
0
Elizabeth
1/10/2014 7:02:38 PM
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Second, FORGET is perfectly possible on such a system: Only erase
> pages that only contain forgotten stuff, and then set the flash
> dictionary pointer to the start of the first erased page.  Yes, some
> forgotten stuff will stay in flash; So what?  Flash is not tight on
> these systems, and if it is, just don't use FORGET.

Say you want to forget back to the middle of page N.  Does the obvious
way work?  I.e. erase pages N+1, N+2, etc.  Then copy page N to page
N+1, erase page N, copy page N+1 back to page N, and erase page N+1
again.  Or if you have enough RAM to buffer page N, then you can avoid
some of the flash writing and erasing.
0
Paul
1/10/2014 7:37:20 PM
On Friday, January 10, 2014 9:37:20 PM UTC+2, Paul Rubin wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: 
> > Second, FORGET is perfectly possible on such a system: Only erase
> > pages that only contain forgotten stuff, and then set the flash
> > dictionary pointer to the start of the first erased page.  Yes, some
> > forgotten stuff will stay in flash; So what?  Flash is not tight on
> > these systems, and if it is, just don't use FORGET.
> 
> Say you want to forget back to the middle of page N.  Does the obvious
> way work?  I.e. erase pages N+1, N+2, etc.  Then copy page N to page
> N+1, erase page N, copy page N+1 back to page N, and erase page N+1
> again.  Or if you have enough RAM to buffer page N, then you can avoid
> some of the flash writing and erasing.

I have considered a strategy for FORGET/MARKER which does not erase 
any flash at all.
FORGET would just make LATEST(in  EEPROM) point to before the forgetted word.
Flash would be written until it is full.

When the flash is full you would need to EMPTY, and start 
filling the device with the now hopefully debugged code.

This strategy would even out the wear on flash.
But I have not used this method since usually flash has been quite reliable.

0
oh2aun
1/10/2014 8:47:53 PM
oh2aun@gmail.com writes:
> When the flash is full you would need to EMPTY, and start 
> filling the device with the now hopefully debugged code.

I guess that's ok since reloading flash from the host is pretty quick.
The device I'm currently thinking about (attiny85) has 8k of flash and
512B of ram, so flash isn't exactly plentiful.  It does have some
eeprom, I think 1k.
0
Paul
1/10/2014 9:37:43 PM
On Friday, January 10, 2014 11:37:43 PM UTC+2, Paul Rubin wrote:
> Mikael Nordman writes:
> > When the flash is full you would need to EMPTY, and start 
> > filling the device with the now hopefully debugged code.
> 
> I guess that's ok since reloading flash from the host is pretty quick.
> The device I'm currently thinking about (attiny85) has 8k of flash and
> 512B of ram, so flash isn't exactly plentiful.  It does have some
> eeprom, I think 1k.

I have just scoped out those very small devices from a resident Forth.
For me, 16K flash, 768 bytes ram, 256 bytes eeprom, are the smallest devices to have a reasonable system in.
0
oh2aun
1/10/2014 10:24:36 PM
Anton Ertl wrote:

> "Ed" <invalid@invalid.com> writes:
>>Time has done what '94 couldn't and today virtually all Forth systems use
>>symmetric division.  Case closed.
> 
> A friend of mine said that "virtually" is a synonym for "not".  Gforth
> implements floored division for / MOD etc.

And bigForth does so, too.  Of course, both decisions were my choice, but in 
Gforth before 0.7, we had symmetric division.  It just started to show its 
problems, so I did the measurements whether this was really worth it...

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

0
Bernd
1/11/2014 12:40:26 AM
On Friday, January 3, 2014 6:13:50 AM UTC-5, Anton Ertl wrote:

> Sure, your corner of the Forth world had no interest in Forth-79, but
> that was not true for everyone, and there were even people who the
> stuck with Forh-79 long after Forth-83 had come out (Elizabeth Rather
> called them Forth-79 holdouts).  And the reasoning used in Forth-94
> was just as valid in 1983: if Forth-83 had not introduced incompatible
> changes, there would have been a smooth transition possible from
> Forth-79 to Forth-83, just as there was for Forth-94, and more people
> would have made the transition, and there would have been less, if any
> Forth-79 holdouts.

I started in 1984 with RSC-Forth which was published by Rockwell in 1983 and written by Randy Dumse and I used it for more than 20 years. No reason to go to another Forth version, because RSC-Forth was ROM based.

The manual doesn't say which Standard it is. RSC-Forth has <BUILDS and
DOES> and PICK, but no ROLL.

4.2.5 Copy a Stack Item with PICK
PICK looks down any depth into the stack and copies the nth number from the top
(not counting the n itself) and places it on top.
1 PICK
is the same as DUP , and
2 PICK
is the same as OVER .
0
visualforth
1/11/2014 5:37:59 AM
On Friday, January 3, 2014 1:03:17 PM UTC-5, Andrew Haley wrote:
> No, only if you are doing something exceedingly odd: interactively
> programming a system, with no cross compiler, with the dictionary in
> flash.  Sure, you can do that, but I can't think of any reason that
> anyone would do it...  
> Andrew.

Hard to believe, but this is where Forth came from: 
Forth is an Operating System.
Seems to be some people don't understand.

It is very important for Forth in education to have everything on the target, so you may add a display and a keypad and you have a totally independent system.
Interactively programming the system is the key, and you don't need a cross compiler! The dictionary in flash is a must! That's back to the roots, and it works!

This is for educational purposes. In a professional system things are different, in a professional system high productivity tools are a must.
0
visualforth
1/11/2014 5:54:56 AM
On Friday, January 3, 2014 4:45:02 PM UTC-5, Paul Rubin wrote:

> Do you really want to write a 4k program interactively with no way to
> save or edit?  I thought interactivity was mostly for debugging.
> 
> Is your 4k MSP430 Forth released?  4e4th is around 8k, I think.

You are right, 4e4th has an 8k flash part for user programs, which is sufficient for educational purposes.

You can download 4e4th at http://www.4e4th.org/ and use the 4E4th-IDE which is specially designed for incremental programming: http://www.4e4th-IDE.org


0
visualforth
1/11/2014 6:05:09 AM
Anton Ertl wrote:
> "Ed" <invalid@invalid.com> writes:
> >Anton Ertl wrote:
> >> "Ed" <invalid@invalid.com> writes:
> >> >Anton Ertl wrote:
> >> > ...
> >> >> Please enlighten me about the empirical basis of "zero-based" PICK and
> >> >> ROLL.
> >> >
> >> >When the index is computed, zero-based is optimum.
> >>
> >> What index?  What do you compare with what?  Which metric are you
> >> using?
> >
> >Observation and experience.
>
> Ok, so you do not explain what you mean with "index" or "optimum", and
> you do not want to give any information on how to reproduce your
> results.  Do you want anyone to take you seriously?

If you don't take me seriously that's sufficient for me.



0
Ed
1/11/2014 6:09:35 AM
On Wednesday, January 8, 2014 6:16:30 PM UTC-5, Bernd Paysan wrote:

> There are reasons why you want to have your Forth system in the target; if 
> you use a umbilical system, you need to have the exact sources related to 
> the device you are plugging into.  When it's just a normal Forth system, all 
> you need is a terminal program.  Many Forth enthousiasts have worked that 
> way for decades, and don't see a need to change.

Thanks, Bernd!
As I already wrote, I am working with such Forth systems now for thirty years.

Having a target with Forth OS on board, it is very easy to build distributed multiprocessor systems as needed for an array of test stands for example:
Connecting all these test stands with RS485, each of them having it's own Forth micro, the communication with the PC control can be done in plain language. That's a huge plus for installation and maintenance. Works great.
0
visualforth
1/11/2014 6:34:15 AM
On Wednesday, January 8, 2014 6:16:30 PM UTC-5, Bernd Paysan wrote:

> The people who implement Forth systems on small processors.  There are more 
> of these small processors than gurus available, so you have to keep it 
> simple.

How true!
The number of gurus won't change anyway.
I would like to have 4e4th on a bunch of microprocessors - the aforementioned OLIMEXINO-85S would be a candidate - but who would be able to do this?
For now we have enough work to do to improve 4e4th on the MSP430G2553 and to improve the 4E4th-IDE.
0
visualforth
1/11/2014 6:41:12 AM
On Saturday, January 11, 2014 2:12:00 AM UTC-5, Paul Rubin wrote:
> visualforth.com writes:
>=20
> > I would like to have 4e4th on a bunch of microprocessors - the
> > aforementioned OLIMEXINO-85S would be a candidate
>
> I defer to your superior knowledge of 4e4th but my first reaction is
> that running it on the OLIMEXINO-85S is probably not feasible even if
> you rewrite all the MSP430 assembly code.  The ATTiny85 has just 8k of
> code space, and its AVR8 processor almost certainly has worse code
> density than the MSP430.  When I mentioned the ATTiny85 earlier, I was
> thinking in terms of a tethered Forth for it.  If you want a resident
> Forth in it, a minimalistic token threaded implementation may allow the
> most stuff.  You might also look at the Femtoduino (www.femtoduino.com)
> which is almost as small and has much more capacity.

Paul,
Thanks for reminding me. My idea was that this is a pretty neat micro, but =
I was wondering, because these little micros normally only have little memo=
ry. It's a real pity, because these tiny little micros could be used for a =
lot of interesting stuff if they would have more memory. The Femtoduino see=
ms to do it, with more pins as SMD.
Thanks again!
0
visualforth
1/11/2014 7:04:53 AM
visualforth@rocketmail.com writes:
> I would like to have 4e4th on a bunch of microprocessors - the
> aforementioned OLIMEXINO-85S would be a candidate

I defer to your superior knowledge of 4e4th but my first reaction is
that running it on the OLIMEXINO-85S is probably not feasible even if
you rewrite all the MSP430 assembly code.  The ATTiny85 has just 8k of
code space, and its AVR8 processor almost certainly has worse code
density than the MSP430.  When I mentioned the ATTiny85 earlier, I was
thinking in terms of a tethered Forth for it.  If you want a resident
Forth in it, a minimalistic token threaded implementation may allow the
most stuff.  You might also look at the Femtoduino (www.femtoduino.com)
which is almost as small and has much more capacity.
0
Paul
1/11/2014 7:12:00 AM
On 1/8/14 1:16 PM, Bernd Paysan wrote:
> Elizabeth D. Rather wrote:
>
>> On 1/8/2014 9:00 AM, Bernd Paysan wrote:
>>> The question here is: Why are the small embedded system programmers only
>>> losely following the standard?  Even though Forth is most popular in that
>>> niche?  The reason is that it is too hard to implement it.  Too hard does
>>> not mean "impossible", but requiring that sort of guru code only a few
>>> people will be able to write.
>>
>> Not sure which programmers you're referring to,
>
> The people who implement Forth systems on small processors.  There are more
> of these small processors than gurus available, so you have to keep it
> simple.

It takes an experienced Forther to implement a system or cross-compiler 
on a processor for the first time. Thereafter, changing boards is a 
piece of cake (matter of a few hours at most).

>> but that's why we were
>> attempting to draft a cross-compiler standard based on the Forth
>> standard. This project really needs to be revived!
>
> Yes, but that's a different topic.
>
> There are reasons why you want to have your Forth system in the target; if
> you use a umbilical system, you need to have the exact sources related to
> the device you are plugging into.  When it's just a normal Forth system, all
> you need is a terminal program.  Many Forth enthousiasts have worked that
> way for decades, and don't see a need to change.

As I said above, changing a basic cross-compiler for a particular MCU is 
usually quite simple. We have had quite a few customers modify SwiftX 
for the board of their choice without help. The "exact sources" are on 
your PC, and easily modified for each board variant of the CPU family.

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."
==================================================
0
Elizabeth
1/11/2014 8:08:53 AM
visualforth@rocketmail.com wrote:

> It is very important for Forth in education to have everything on
> the target, so you may add a display and a keypad and you have a
> totally independent system.  Interactively programming the system is
> the key, and you don't need a cross compiler! The dictionary in
> flash is a must! That's back to the roots, and it works!
> 
> This is for educational purposes. In a professional system things
> are different, in a professional system high productivity tools are
> a must.

I'm not sure you do learners any favours by making them use low
productivity tools.

Andrew.
0
Andrew
1/11/2014 9:41:27 AM
visualforth@rocketmail.com wrote:
> On Friday, January 3, 2014 1:03:17 PM UTC-5, Andrew Haley wrote:
>> No, only if you are doing something exceedingly odd: interactively
>> programming a system, with no cross compiler, with the dictionary in
>> flash.  Sure, you can do that, but I can't think of any reason that
>> anyone would do it...  
> 
> Hard to believe, but this is where Forth came from: 
> Forth is an Operating System.
> Seems to be some people don't understand.

Furthermore,

I understand perfectly well: it was fairly standard to run a resident
Forth on small systems when I wrote the 1988 article.  The problem was
that they were't as productive a programming environment as PCs and
that precious target memory was wasted on the parts of Forth needed
for interaction but not the application.  One solution was to write
and debug the program on a PC, but then you'd have to emulate parts of
the system and the emulation was always imperfect.  I always disliked
that, and much preferred to do all the development on the real
hardware.

Also, the real product as shipped was unlikely to have enough spare
memory to run a full interactive system so if anything went wrong in
the field you wouldn't be able to debug the system.

Our desire was a programming environment that was just as productive
and enjoyable as Forth on a PC even when programming the smallest
microcontroller.

Andrew.
0
Andrew
1/11/2014 10:11:20 AM
m.a.m.hendrix@tue.nl wrote:
> ...
> I do agree that REPRESENT needs fixing (At the time I followed your recommendations in
> updating iForth). REPRESENT should have been fixed in ANS-2000 and some kind of PLACES
> should have been introduced.

Since we're talking fantasy ...

I would phase out  REPRESENT  F.  FS.  FE.  in favour of  (F.)  (FS.)  F.R  FS.R
(FE.)  FE.R  (the last two in FLOAT EXT).

I would *not* standardize  F.  FS.  FE.  but leave it to systems to decide how these
should behave.  Folks become accustomed to how *their*  F.  worked and are
reluctant to change!  Some systems may define  F.  to drop to scientific mode
for large/small numbers, while others might use  G.  for that.  Similarly you may
want  F.  to output  'n' decimal PLACES, while I prefer  F.  to display numbers
compactly to a maximum of PRECISION digits.

A Standard Program would use only  (F.)  (FS.)  F.R  FS.R  (FE.)  FE.R.  These
should be mode stable - no automatic switching to other modes (except under
failure conditions e.g. PNO overflow).  Their outputs must be precisely defined
so a Standard Program knows how to manipulate the string should it be desired.
If a Standard Program needs an  F. etc it can be trivially defined using one of the
above functions.

(F.)  (FS.)  F.R  FS.R  (FE.)  FE.R  do not require  PRECISION  or  PLACES
(though systems may have one or the other) since the number of decimal places
is specified by a parameter on the stack.

Systems are free to change exponent character, number of exponent digits,
trailing decimal point, negative zero, comma separators etc. however when a
Standard Program is to be run, users must reset to the default format.

That's how I'd do it - but as my interest in Forth Standards these days is incidental,
I view it as empty words on a page and not worth arguing.



0
Ed
1/11/2014 12:12:11 PM
On Sat, 11 Jan 2014 04:11:20 -0600, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:

>Our desire was a programming environment that was just as productive
>and enjoyable as Forth on a PC even when programming the smallest
>microcontroller.

The world has changed since 1988. There were quite a number of
papers on the topic of Umbilical Forths at that time.

Nowadays it is perfectly possible to run a full Forth on the target
except for tools like editors which can be provided by a host.

Our CPU of choice for low/medium volume applications runs at nearly
200 MHz, has 1 Mb of Flash and 192 kb of RAM. The distinction
and tool partitioning tend to be driven by product volume
and cost sensitivity. The choices are different now.

Arguing that people should not want what they say they want has
never been an effective tool. We prefer to offer them both
approaches in the same package and then let them choose.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
0
stephenXXX
1/11/2014 1:31:53 PM
In article <m8WdnUQxu5JajEzPnZ2dnUVZ_r2dnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>visualforth@rocketmail.com wrote:
>
>> It is very important for Forth in education to have everything on
>> the target, so you may add a display and a keypad and you have a
>> totally independent system.  Interactively programming the system is
>> the key, and you don't need a cross compiler! The dictionary in
>> flash is a must! That's back to the roots, and it works!
>>
>> This is for educational purposes. In a professional system things
>> are different, in a professional system high productivity tools are
>> a must.
>
>I'm not sure you do learners any favours by making them use low
>productivity tools.

High productivity tools come with a learning curve.
The investment versus results lay exactly opposite in education.
Very low investment in understanding for a moderate accomplishment.

{costs are probably higher too]
>
>Andrew.

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

0
albert
1/11/2014 1:33:33 PM
Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> On Sat, 11 Jan 2014 04:11:20 -0600, Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:
> 
>>Our desire was a programming environment that was just as productive
>>and enjoyable as Forth on a PC even when programming the smallest
>>microcontroller.
> 
> The world has changed since 1988. There were quite a number of
> papers on the topic of Umbilical Forths at that time.

Colour me skeptical.  I'd never seen any such papers, but of course
that doesn't mean they didn't exist.  The "talker ROM" had been around
since the seventies, but it was fairly slow to develop from that into
a full interactive environment.

> Nowadays it is perfectly possible to run a full Forth on the target
> except for tools like editors which can be provided by a host.
> 
> Our CPU of choice for low/medium volume applications runs at nearly
> 200 MHz, has 1 Mb of Flash and 192 kb of RAM. The distinction
> and tool partitioning tend to be driven by product volume
> and cost sensitivity.

And so it always was.

> The choices are different now.

The market in which *you* work has changed, but there's surely still a
market for the kind of computer that you might put into, say, a
birthday card.

> Arguing that people should not want what they say they want has
> never been an effective tool. We prefer to offer them both
> approaches in the same package and then let them choose.

I'm not trying to sell anything.  This is a dialogue in which I offer
my opinion and welcome others' opinions, in the hope that we all might
learn something.

Andrew.
0
Andrew
1/11/2014 1:52:55 PM
On 1/11/14 3:31 AM, Stephen Pelc wrote:
....
> Arguing that people should not want what they say they want has
> never been an effective tool. We prefer to offer them both
> approaches in the same package and then let them choose.

The difficulty with this argument is that a lot of the "wanting" in this 
discussion is second hand: people wanting an environment for others to 
use. One person may well be happy with a very spartan programming 
environment, but another may have higher expectations in terms of 
performance, support tools, etc., particularly if there's serious 
programming to be done. And even if the system is for newbies, many 
newbies today have expectations that will be unsatisfied, and conclude 
that "Forth" is unusable, whereas it's really that particular 
implementation that has cut too many corners.

I agree with your approach, of offering both, but in practice we find 
relatively few takers for bare-bones development.

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."
==================================================
0
Elizabeth
1/11/2014 6:43:56 PM
stephenXXX@mpeforth.com (Stephen Pelc) writes:
> Our CPU of choice for low/medium volume applications runs at nearly
> 200 MHz, has 1 Mb of Flash and 192 kb of RAM. The distinction
> and tool partitioning tend to be driven by product volume
> and cost sensitivity. 

My stuff is low volume and not terribly cost sensitive, but wants very
small physical packages.  They don't seem to make that part that way.

There is a new PJRC Teensy (Teensy 3.1) with a relative of that STM32F
you're referring to.  It has 256k of flash and 64k of ram which is still
enough for a rather fancy Forth system.  With 192k I'd be thinking of
programming in something like Lisp.
0
Paul
1/11/2014 7:28:52 PM
On Sat, 11 Jan 2014 07:52:55 -0600, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:

>> The world has changed since 1988. There were quite a number of
>> papers on the topic of Umbilical Forths at that time.
>
>Colour me skeptical.  I'd never seen any such papers, but of course
>that doesn't mean they didn't exist.  The "talker ROM" had been around
>since the seventies, but it was fairly slow to develop from that into
>a full interactive environment.

I delivered one at a Rochester conference at which there were two
other papers on the same topic.

>> The choices are different now.
>
>The market in which *you* work has changed, but there's surely still a
>market for the kind of computer that you might put into, say, a
>birthday card.

If you mean that we have kept up with the market, then I agree
with you. We've already had the internet-connected coffee-machine,
fridge and toaster. How long before we get the internet-connected
birthday card?

It's just a simple observation that as the cost of silicon falls,
silicon becomes even more pervasive and the jobs done with it
become more complex. We try to keep up.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
0
stephenXXX
1/11/2014 7:35:20 PM
On Sat, 11 Jan 2014 08:43:56 -1000, "Elizabeth D. Rather"
<erather@forth.com> wrote:

>I agree with your approach, of offering both, but in practice we find 
>relatively few takers for bare-bones development.

I agree. That's why our standalone Forths are no longer bare bones.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
0
stephenXXX
1/11/2014 7:37:09 PM
On Saturday, January 11, 2014 4:41:27 AM UTC-5, Andrew Haley wrote:
> visualforth.com wrote:

>> It is very important for Forth in education to have everything on
>> the target, so you may add a display and a keypad and you have a
>> totally independent system.  Interactively programming the system is
>> the key, and you don't need a cross compiler! The dictionary in
>> flash is a must! That's back to the roots, and it works!
>=20
>> This is for educational purposes. In a professional system things
>> are different, in a professional system high productivity tools are
> > a must.
>=20
> I'm not sure you do learners any favours by making them use low
> productivity tools.
> Andrew.

Forth is a highly productive tool and Forth is amplifying the abilities of =
the programmer. That's why Forth is a good point to start with in programmi=
ng education, let's say in K-12. If somebody gets good results, programming=
 may be his profession in perspective - if somebody likes to be a programme=
r and doesn't get anything useful done in Forth, then the best advice would=
 be to choose another professional direction.
0
visualforth
1/11/2014 7:44:22 PM
On Saturday, January 11, 2014 5:11:20 AM UTC-5, Andrew Haley wrote:
> visualforth.com wrote:
>=20
>> On Friday, January 3, 2014 1:03:17 PM UTC-5, Andrew Haley wrote:
>>> No, only if you are doing something exceedingly odd: interactively
>>> programming a system, with no cross compiler, with the dictionary in
>>> flash.  Sure, you can do that, but I can't think of any reason that
>>> anyone would do it... =20
>>=20
>> Hard to believe, but this is where Forth came from:=20
>> Forth is an Operating System.
>> Seems to be some people don't understand.
>=20
> Furthermore,
>=20
> I understand perfectly well: it was fairly standard to run a resident
> Forth on small systems when I wrote the 1988 article.  The problem was
> that they were't as productive a programming environment as PCs and
> that precious target memory was wasted on the parts of Forth needed
> for interaction but not the application.  One solution was to write
> and debug the program on a PC, but then you'd have to emulate parts of
> the system and the emulation was always imperfect.  I always disliked
> that, and much preferred to do all the development on the real
> hardware.
>=20
> Also, the real product as shipped was unlikely to have enough spare
> memory to run a full interactive system so if anything went wrong in
> the field you wouldn't be able to debug the system.
>=20
> Our desire was a programming environment that was just as productive
> and enjoyable as Forth on a PC even when programming the smallest
> microcontroller.
>=20
> Andrew.

I see.
Now you wrote about your own personal experience and your conclusions on yo=
ur personal experience.

I have a different history.
I started way before PCs have been available, using a keypad and seven-segm=
ent-display monitoring the target firmware, writing my programs with pencil=
 and paper in assembly language, looking up the machine code from a table.

So I learned how important structural programming is and how important it i=
s to have direct access to the I/O (this was the only possible way back the=
n) and immediately testing the results, programming bottom up. And I wrote =
my own VM to make my kind of programming more effective.

Then I got RSC-Forth, giving me the possibility to add mass storage to my e=
mbedded systems, and still having the opportunity to access the I/O directl=
y.
I always left the whole RSC-Forth on board, because this was good for maint=
enance, and in case filed software documentation got lost, it was still the=
re as part of the firmware.=20

RSC-Forth has the possibility to compile headerless, but I never needed to =
do so. Once I had a project which needed additions, but the on chip flash w=
as to small to hold these additional words. So I made a little addition to =
the RSC-Forth compiler to compile executable Forth-Code into the I2C-EEPROM=
 which was on board. Worked great. Is there any other programming language =
which can execute commands directly from EEPROM?

When I got my first PC, I abandoned the in-system mass storage (for which I=
 had written my own editor, by the way) and used a terminal program especia=
lly for RSC-Forth which I wrote using UR/Forth, later I ported this termina=
l program to Win32Forth abandoning the block system, using files since then=
..

Why should I ever simulate the firmware on a PC instead of testing it direc=
tly in system? Anyway, I did even this, running and testing number crunchin=
g parts on a PC with Win32Forth of my firmware which was originally written=
 in RSC-Forth - only a few adaptation words were needed to close the gap.=
=20

All the time I hated that often enough programs had to be typed twice: once=
 for testing and once edited to the whole program. That's why I developed t=
he 4E4th-IDE to make real incremental programming possible - with the 4E4th=
-IDE everything has to be typed only once, tested and eventually corrected,=
 and at the end there is a file with the completed program. For now this is=
 only for small systems for education, to show that new programming methods=
 are possible.
0
visualforth
1/11/2014 8:24:17 PM
On 1/11/14 9:44 AM, visualforth@rocketmail.com wrote:
> On Saturday, January 11, 2014 4:41:27 AM UTC-5, Andrew Haley wrote:
>> visualforth.com wrote:
>
>>> It is very important for Forth in education to have everything on
>>> the target, so you may add a display and a keypad and you have a
>>> totally independent system.  Interactively programming the system is
>>> the key, and you don't need a cross compiler! The dictionary in
>>> flash is a must! That's back to the roots, and it works!
>>
>>> This is for educational purposes. In a professional system things
>>> are different, in a professional system high productivity tools are
>>> a must.
>>
>> I'm not sure you do learners any favours by making them use low
>> productivity tools.
>> Andrew.
>
> Forth is a highly productive tool and Forth is amplifying the abilities
> of the programmer. That's why Forth is a good point to start with
> in programming education, let's say in K-12. If somebody gets good
> results, programming may be his profession in perspective - if somebody
> likes to be a programmer and doesn't get anything useful done in Forth,
> then the best advice would be to choose another professional direction.
>

Absolutely true, but some Forth environments are easier to use than 
others. If someone's first exposure to Forth is on a hard-to-use 
implementation the lesson will be "Forth is hard to use."

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."
==================================================
0
Elizabeth
1/11/2014 8:40:58 PM
Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> On Sat, 11 Jan 2014 07:52:55 -0600, Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:
> 
>>> The world has changed since 1988. There were quite a number of
>>> papers on the topic of Umbilical Forths at that time.
>>
>>Colour me skeptical.  I'd never seen any such papers, but of course
>>that doesn't mean they didn't exist.  The "talker ROM" had been around
>>since the seventies, but it was fairly slow to develop from that into
>>a full interactive environment.
> 
> I delivered one at a Rochester conference at which there were two
> other papers on the same topic.

This would be "Cross Compiling - The Ghosts of Christmas Past, Present
and Future", right?

>>> The choices are different now.
>>
>>The market in which *you* work has changed, but there's surely still a
>>market for the kind of computer that you might put into, say, a
>>birthday card.
> 
> If you mean that we have kept up with the market,

No, I don't!  But that's a reasonable question.

> then I agree with you. We've already had the internet-connected
> coffee-machine, fridge and toaster. How long before we get the
> internet-connected birthday card?
> 
> It's just a simple observation that as the cost of silicon falls,
> silicon becomes even more pervasive and the jobs done with it
> become more complex. We try to keep up.

Of course.

I'm not claiming to be up-to-date with current industrial Forth
practice -- far from it -- but I am rather bemused by people using
systems that appear to be *worse* than what I had twenty-five years
ago.

But anyway, we're off the point.  Do your interactive systems compile
directly into flash, as Bernd describes?

Andrew.
0
Andrew
1/12/2014 8:57:46 AM
By the way, if anyone is interested, there's a much better description
of chipFORTH and its origins in

Extending the Forth Environment to Single Chip Microprocessors,
A. P. Haley and C. L. Stephens, proc. Rochester Forth Conference on
Industrial Automation, June 20-24, 1989.

Andrew.
0
Andrew
1/12/2014 9:12:14 AM
In article <gZednRL8KceXxE_PnZ2dnUVZ_radnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Stephen Pelc <stephenXXX@mpeforth.com> wrote:
>> On Sat, 11 Jan 2014 07:52:55 -0600, Andrew Haley
>> <andrew29@littlepinkcloud.invalid> wrote:
>>
>>>> The world has changed since 1988. There were quite a number of
>>>> papers on the topic of Umbilical Forths at that time.
>>>
>>>Colour me skeptical.  I'd never seen any such papers, but of course
>>>that doesn't mean they didn't exist.  The "talker ROM" had been around
>>>since the seventies, but it was fairly slow to develop from that into
>>>a full interactive environment.
>>
>> I delivered one at a Rochester conference at which there were two
>> other papers on the same topic.
>
>This would be "Cross Compiling - The Ghosts of Christmas Past, Present
>and Future", right?
>
>>>> The choices are different now.
>>>
>>>The market in which *you* work has changed, but there's surely still a
>>>market for the kind of computer that you might put into, say, a
>>>birthday card.
>>
>> If you mean that we have kept up with the market,
>
>No, I don't!  But that's a reasonable question.
>
>> then I agree with you. We've already had the internet-connected
>> coffee-machine, fridge and toaster. How long before we get the
>> internet-connected birthday card?
>>
>> It's just a simple observation that as the cost of silicon falls,
>> silicon becomes even more pervasive and the jobs done with it
>> become more complex. We try to keep up.
>
>Of course.
>
>I'm not claiming to be up-to-date with current industrial Forth
>practice -- far from it -- but I am rather bemused by people using
>systems that appear to be *worse* than what I had twenty-five years
>ago.

Have you tried any? An MSP430 is at the power level and instruction
set level of a PDP11?

>
>But anyway, we're off the point.  Do your interactive systems compile
>directly into flash, as Bernd describes?
>
>Andrew.
-- 
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

0
albert
1/12/2014 11:38:46 AM
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> In article <gZednRL8KceXxE_PnZ2dnUVZ_radnZ2d@supernews.com>,
> 
>>I'm not claiming to be up-to-date with current industrial Forth
>>practice -- far from it -- but I am rather bemused by people using
>>systems that appear to be *worse* than what I had twenty-five years
>>ago.
> 
> Have you tried any? An MSP430 is at the power level and instruction
> set level of a PDP11?

I'm not talking about the hardware, but about the way it's programmed.
The hardware sounds rather nice.

Andrew.
0
Andrew
1/12/2014 1:46:52 PM
Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> Extending the Forth Environment to Single Chip Microprocessors,
>> A. P. Haley and C. L. Stephens, proc. Rochester Forth Conference on
>> Industrial Automation, June 20-24, 1989.
> 
> Any chance of an upload?

I guess I could scan it, but I've been a bit worried about copyrights.
I think that no-one would object, but what is allowed is all a bit
murky.  It really would be wonderful to scan and push the lot; having
it only on paper is a real nuisance.

Andrew.
0
Andrew
1/12/2014 4:40:07 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> Extending the Forth Environment to Single Chip Microprocessors,
> A. P. Haley and C. L. Stephens, proc. Rochester Forth Conference on
> Industrial Automation, June 20-24, 1989.

Any chance of an upload?
0
Paul
1/12/2014 4:43:19 PM
In article <kLqdnRJJ3dX6WE_PnZ2dnUVZ_jOdnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Paul Rubin <no.email@nospam.invalid> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> Extending the Forth Environment to Single Chip Microprocessors,
>>> A. P. Haley and C. L. Stephens, proc. Rochester Forth Conference on
>>> Industrial Automation, June 20-24, 1989.
>>
>> Any chance of an upload?
>
>I guess I could scan it, but I've been a bit worried about copyrights.
>I think that no-one would object, but what is allowed is all a bit
>murky.  It really would be wonderful to scan and push the lot; having
>it only on paper is a real nuisance.

1982 Rochester Forth conference.
The start say
(copyright 1982 the institute for Forth research)
Then they go on
Individual papers may be copyrighted prior.
So they can't make up their mind.

Example of an individual paper.
But then an individual paper is copyrighted then and there not by the
institute:
page 165
Manfred Peschke Intersystems with a 1982 phone number.
"microcomputer in production control and management"
The entire content of this paper copyright (c) 1982 Intersystems.
All rights reserved. Requests for copy permission should be address to
Intersystems. (Intersystems is registered by the patent office.)
This is only 10 pages worth of proceedings.

Good luck contacting Intersystems. I wouldn't even try.

Bottom line, getting the legal stuff right is more work than the scanning.

The only solution is to scan it anonymously and dump it all in the
Torrent/Warez circuit. I vehemently deny on forehand any involvement
in copies of Rochester stuff that may appear there.

They may be gotten on Warez because someone broke in into my computer
where some scans reside that I made awaiting formal permission.
(Oops, starting to scan prematurely can get you in jail if you're a US
citizen.)

Caesar's men are killing us while we try to extinguish the fire in the
library of Alexandria.

>Andrew.

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

0
albert
1/12/2014 6:00:54 PM
On Sunday, 12 January 2014 16:40:07 UTC, Andrew Haley  wrote:
> Paul Rubin <no.email@nospam.invalid> wrote:
> 
> > Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> >> Extending the Forth Environment to Single Chip Microprocessors,
> >> A. P. Haley and C. L. Stephens, proc. Rochester Forth Conference on
> >> Industrial Automation, June 20-24, 1989.
> > 
> > Any chance of an upload?
> 
> I guess I could scan it, but I've been a bit worried about copyrights.
> I think that no-one would object, but what is allowed is all a bit
> murky.  It really would be wonderful to scan and push the lot; having
> it only on paper is a real nuisance.
> 
> Andrew.

Publish & remain undamned. You (with CL Stephens) own the copyright. The publisher only owns the copyright on the compilation & form of the collection. 


0
Alex
1/12/2014 7:18:09 PM
> Anton Ertl wrote:
>
> "Ed" <invalid@invalid.com> writes:
>>Time has done what '94 couldn't and today virtually all Forth systems use
>>symmetric division.  Case closed.
>
> A friend of mine said that "virtually" is a synonym for "not".

Ascribing to words a new meaning is how Forth got itself into trouble.

Oxford dictionary:

    "virtually  adv. in effect, nearly, almost"

> Gforth
> implements floored division for / MOD etc.

How quaint.  I use an MS-DOS based Forth.  Welcome to the world of
things past.



0
Ed
1/13/2014 12:21:29 AM
Op Mon, 13 Jan 2014 11:21:29 +1100 schreef Ed:

>> Anton Ertl wrote:
>>
>> "Ed" <invalid@invalid.com> writes:
>>>Time has done what '94 couldn't and today virtually all Forth systems use
>>>symmetric division.  Case closed.
>>
>> A friend of mine said that "virtually" is a synonym for "not".
> 
> Ascribing to words a new meaning is how Forth got itself into trouble.
> 
> Oxford dictionary:
> 
>     "virtually  adv. in effect, nearly, almost"
> 
>> Gforth
>> implements floored division for / MOD etc.
> 
> How quaint.  I use an MS-DOS based Forth.  Welcome to the world of
> things past.

What has the OS to do with division?

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 
0
Coos
1/13/2014 12:50:31 AM
Coos Haak wrote:
> Op Mon, 13 Jan 2014 11:21:29 +1100 schreef Ed:
>
> >> Anton Ertl wrote:
> >>
> >> "Ed" <invalid@invalid.com> writes:
> >>>Time has done what '94 couldn't and today virtually all Forth systems use
> >>>symmetric division.  Case closed.
> >>
> >> A friend of mine said that "virtually" is a synonym for "not".
> >
> > Ascribing to words a new meaning is how Forth got itself into trouble.
> >
> > Oxford dictionary:
> >
> >     "virtually  adv. in effect, nearly, almost"
> >
> >> Gforth
> >> implements floored division for / MOD etc.
> >
> > How quaint.  I use an MS-DOS based Forth.  Welcome to the world of
> > things past.
>
> What has the OS to do with division?

I responded to a troll and it appears I must do so again.




0
Ed
1/13/2014 1:05:18 AM
Coos Haak wrote:

> Op Mon, 13 Jan 2014 11:21:29 +1100 schreef Ed:
> 
>>> Anton Ertl wrote:
>>> Gforth
>>> implements floored division for / MOD etc.
>> 
>> How quaint.  I use an MS-DOS based Forth.  Welcome to the world of
>> things past.
> 
> What has the OS to do with division?

Ed's original statement was that times have changed and floored division is 
now a thing of the past.  Gforth changed to floored in 0.7.0, i.e. some 
years ago, so we went back to the past where division was well-defined and 
not a matter of "nobody cares about accurate results, as long as the 
calculation is really fast".

Anybody with some more insight would have known that the time doesn't always 
equate with progress.  Some things are going in cycles.

The measurements I did with current Gforth on a Core i7 is that fm/mod is 
slightly faster than sm/rem (both using idiv as base) for all-positive 
numbers (the "default case" where it doesn't matter, and the performance 
freaks want the fastest division they get).  Don't ask my why it is actually 
a bit faster, it should be equal.  If you have a wild mix of positive and 
negative numbers, fm/mod is slower (branch miss penalties).  This however is 
the case where accuracy does matter.  um/mod is considerably faster, so 
probably basing fm/mod on um/mod would give a significant advantage over 
sm/rem in the default case (all positive, nothing to do).  With some 
trickery, fm/mod could also be written so that all the updates are 
conditional moves, and no branch misses are taken.

A lot of programmers do "works for me" stuff.  Stephen Pelc told me several 
times "nobody has ever complained" when I complained about things.  Hell, 
no!  I complained!  I also say that nobody complained about our 
(incompatible) switch from symmetric to floored division.  Whatever, maybe 
people were too timid to complain.  I got to the point that I complained 
about symmetric division, and I did the measurements ("is it really faster") 
and fixed my problem.

Apart from Forth, floored division is used in Oberon and Haskell (Haskell 
has quot and rem for symmetric divisions, as well).  Even Microsoft 
(Research ;-) comes to the conclusion that symmetric division is inferior:

http://research.microsoft.com/pubs/151917/divmodnote-letter.pdf

Euclidean division (where the remainder is always positive, no matter what 
the signs are) is also pretty regular.  There's also rounded division, where 
the remainder can be positive or negative, but is never larger than half of 
the quotient in magnitude; this is quite useful, too.

If of all choices the worst is taken, I suspect that it was a democratic 
choice ;-).  This is because democracy is the worst form of all governments, 
but we don't know any better (well, worst choice syndrome again ;-).

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

0
Bernd
1/13/2014 2:19:01 AM
Elizabeth D. Rather wrote:
> On 1/10/14 7:19 AM, Anton Ertl wrote:
> > "Ed" <invalid@invalid.com> writes:
> >> Anton Ertl wrote:
> >>> "Ed" <invalid@invalid.com> writes:
> >>>> Anton Ertl wrote:
> >>>> ...
> >>>>> Please enlighten me about the empirical basis of "zero-based" PICK and
> >>>>> ROLL.
> >>>>
> >>>> When the index is computed, zero-based is optimum.
> >>>
> >>> What index?  What do you compare with what?  Which metric are you
> >>> using?
> >>
> >> Observation and experience.
> >
> > Ok, so you do not explain what you mean with "index" or "optimum", and
> > you do not want to give any information on how to reproduce your
> > results.  Do you want anyone to take you seriously?
>
> Ok, consider:
>
> 10 CONSTANT SIZE
> CREATE DATA SIZE CELLS ALLOT
> : SHOW ( -- ) SIZE 0 DO  DATA I + @ . LOOP ;
>
> Indexing here is zero-based. If it were 1-based, you'd have to say,
>       SIZE 1+ 1 DO...
>
> which is awkward. So, that's how we normally think of indexing: 0 is the
> index of the start of whatever. Therefore, 0 PICK would be the TOS
> (ignoring the argument to PICK) plus 0, or DUP.
>
> I believe that's what Ed meant.

0-based PICK ROLL has been normative since '83.  If Anton wishes to challenge
the decision, it is *he* who must demonstrate why 1-based is better, or at least
performance neutral.  He has not done so but instead presses others to do his
homework.

I believe the case for 1-based PICK ROLL would be difficult to make.  How it
came to be so originally is a matter for historians.  It may have been a consequence
of PICK written in high-level.

0-based is optimum when implementing PICK and ROLL e.g. an Intel 386 n/c PICK
is just one instruction.  1-based may appear beneficial in calculations involving SP@
however such gain is illusory as it is obtained at the expense of making PICK ROLL
longer/slower which affects all uses.

FD 4/5 lists K. Scheisliek as author of the 0-based PICK ROLL proposal.  If Anton
wants more convincing he might consider contacting the author.



0
Ed
1/13/2014 2:28:45 AM
Bernd Paysan wrote:
> If of all choices the worst is taken, I suspect that it was a democratic
> choice ;-).  This is because democracy is the worst form of all
> governments, but we don't know any better (well, worst choice syndrome
> again ;-).

BTW "Democracy": Wikipedia has a nice list of languages and whether they 
have dividend or divisor as sign base for modulos:

https://en.wikipedia.org/wiki/Modulo_operation

This list shows that we are very far from a consensus on this topic.  But at 
least this list shows that most languages have found a consensus within 
their community, even C and C++ finally did that.

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

0
Bernd
1/13/2014 2:36:59 AM
Bernd Paysan <bernd.paysan@gmx.de> writes:
> Apart from Forth, floored division is used in Oberon and Haskell

Also Python. ;-)  

> (Haskell has quot and rem for symmetric divisions, as well)

Similarly with Common Lisp:

http://www.lispworks.com/documentation/HyperSpec/Body/f_mod_r.htm

CL's "floor" and "truncate" actually do the equivalent of Forth's /MOD
and return two values.
0
Paul
1/13/2014 3:22:02 AM
On Sun, 12 Jan 2014 04:12:14 -0500, Andrew Haley  
<andrew29@littlepinkcloud.invalid> wrote:

> By the way, if anyone is interested, there's a much better description
> of chipFORTH and its origins in
>
> Extending the Forth Environment to Single Chip Microprocessors,
> A. P. Haley and C. L. Stephens, proc. Rochester Forth Conference on
> Industrial Automation, June 20-24, 1989.
>

So, if we aren't interested in chipFORTH, this would could only be
possibly useful for help in putting Forth onto processors architectures
 from 1989 or earlier that are still in use today, e.g., the x86 series.

Yes?


Rod Pemberton

0
Rod
1/13/2014 7:28:01 AM
On 1/12/2014 9:28 PM, Rod Pemberton wrote:
> On Sun, 12 Jan 2014 04:12:14 -0500, Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:
>
>> By the way, if anyone is interested, there's a much better description
>> of chipFORTH and its origins in
>>
>> Extending the Forth Environment to Single Chip Microprocessors,
>> A. P. Haley and C. L. Stephens, proc. Rochester Forth Conference on
>> Industrial Automation, June 20-24, 1989.
>>
>
> So, if we aren't interested in chipFORTH, this would could only be
> possibly useful for help in putting Forth onto processors architectures
> from 1989 or earlier that are still in use today, e.g., the x86 series.

If you aren't interested in interactive cross-compilers for 
limited-resource microcontrollers (both current and past) it's of no 
interest whatever.

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."
==================================================
0
Elizabeth
1/13/2014 7:39:19 AM
Rod Pemberton <dont_use_email@xnohavenotit.cnm> wrote:
> On Sun, 12 Jan 2014 04:12:14 -0500, Andrew Haley  
> <andrew29@littlepinkcloud.invalid> wrote:
> 
>> By the way, if anyone is interested, there's a much better description
>> of chipFORTH and its origins in
>>
>> Extending the Forth Environment to Single Chip Microprocessors,
>> A. P. Haley and C. L. Stephens, proc. Rochester Forth Conference on
>> Industrial Automation, June 20-24, 1989.
> 
> So, if we aren't interested in chipFORTH, this would could only be
> possibly useful for help in putting Forth onto processors architectures
> from 1989 or earlier that are still in use today, e.g., the x86 series.
> 
> Yes?

I don't think so.  It has nothing to do with a processor's instruction
set architecture.

Andrew.
0
Andrew
1/13/2014 9:16:16 AM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>The market in which *you* work has changed, but there's surely still a
>market for the kind of computer that you might put into, say, a
>birthday card.

Sure, but the point of this discussion is that there is also a market
for computers where a resident Forth that compiles to Flash makes
sense; these systems are not "exceedingly odd".  This is also
demonstrated by the fact that there are several of them, from
different authors.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/13/2014 3:46:01 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Paul Rubin <no.email@nospam.invalid> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> Extending the Forth Environment to Single Chip Microprocessors,
>>> A. P. Haley and C. L. Stephens, proc. Rochester Forth Conference on
>>> Industrial Automation, June 20-24, 1989.
>> 
>> Any chance of an upload?
>
>I guess I could scan it, but I've been a bit worried about copyrights.
>I think that no-one would object, but what is allowed is all a bit
>murky.  It really would be wonderful to scan and push the lot; having
>it only on paper is a real nuisance.

So much for copyright being there for the benefit of the authors.  But
if you have not transferred the copyright or exclusively licensed it
to someone else, you as the authors are allowed to produce additional
copies of the work; of course that means you have to get the consent
of you coauthor.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/13/2014 4:03:25 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>The market in which *you* work has changed, but there's surely still a
>>market for the kind of computer that you might put into, say, a
>>birthday card.
> 
> Sure, but the point of this discussion is that there is also a market
> for computers where a resident Forth that compiles to Flash makes
> sense; these systems are not "exceedingly odd".  This is also
> demonstrated by the fact that there are several of them, from
> different authors.

That's interesting to me, and rather surprising, but each to their
own.  

At risk of repeating myself, I still don't think it's worth
resurrecting <BUILDS DOES> for, especially given that CREATE DOES> can
be made to work even on such a target with some contortions.

Andrew.
0
Andrew
1/13/2014 4:45:42 PM
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Second, FORGET is perfectly possible on such a system: Only erase
>> pages that only contain forgotten stuff, and then set the flash
>> dictionary pointer to the start of the first erased page.  Yes, some
>> forgotten stuff will stay in flash; So what?  Flash is not tight on
>> these systems, and if it is, just don't use FORGET.
>
>Say you want to forget back to the middle of page N.  Does the obvious
>way work?  I.e. erase pages N+1, N+2, etc.  Then copy page N to page
>N+1, erase page N, copy page N+1 back to page N, and erase page N+1
>again.

That's also a possibility, but my thinking was to just leave page N as
it is, and set the dictionary pointer to the start of page N+1.  So
FORGET usually would not reclaim all the flash memory that is
forgotten.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/13/2014 4:53:50 PM
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 1/10/14 7:19 AM, Anton Ertl wrote:
>> "Ed" <invalid@invalid.com> writes:
>>> Anton Ertl wrote:
>>>> "Ed" <invalid@invalid.com> writes:
>>>>> Anton Ertl wrote:
>>>>> ...
>>>>>> Please enlighten me about the empirical basis of "zero-based" PICK and
>>>>>> ROLL.
>>>>>
>>>>> When the index is computed, zero-based is optimum.
>>>>
>>>> What index?  What do you compare with what?  Which metric are you
>>>> using?
>>>
>>> Observation and experience.
>>
>> Ok, so you do not explain what you mean with "index" or "optimum", and
>> you do not want to give any information on how to reproduce your
>> results.  Do you want anyone to take you seriously?
>
>Ok, consider:
>
>10 CONSTANT SIZE
>CREATE DATA SIZE CELLS ALLOT
>: SHOW ( -- ) SIZE 0 DO  DATA I + @ . LOOP ;
>
>Indexing here is zero-based. If it were 1-based, you'd have to say,
>      SIZE 1+ 1 DO...
>
>which is awkward. So, that's how we normally think of indexing: 0 is the 
>index of the start of whatever.

Sure, that's a common idiom in Forth.  And maybe that's what Andrew
Haley meant with Forth being a 0-based language: some idiom, not a
language feature.

> Therefore, 0 PICK would be the TOS 
>(ignoring the argument to PICK) plus 0, or DUP.

I fail to see a connection between that idiom and PICK (and ROLL).

Also, if you ignore or take notice of arbitrary things on the stack,
any variation of PICK can be seen as "0-based".  E.g., the Forth-79
PICK is "0-based" if you take notice of the argument (and the return
value) for PICK.  But given that there is no particular reason for
PICK to be "0-based", that does not matter.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/13/2014 5:07:32 PM
on 13/01/2014 16:03:21,  wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Paul Rubin <no.email@nospam.invalid> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>> Extending the Forth Environment to Single Chip Microprocessors,
>>>> A. P. Haley and C. L. Stephens, proc. Rochester Forth Conference on
>>>> Industrial Automation, June 20-24, 1989.
>>>
>>> Any chance of an upload?
>>
>>I guess I could scan it, but I've been a bit worried about copyrights.
>>I think that no-one would object, but what is allowed is all a bit
>>murky.  It really would be wonderful to scan and push the lot; having
>>it only on paper is a real nuisance.
> 
> So much for copyright being there for the benefit of the authors. But
> if you have not transferred the copyright or exclusively licensed it
> to someone else, you as the authors are allowed to produce additional
> copies of the work; of course that means you have to get the consent
> of you coauthor.

No. His/her permission is required:

 if the co-author stipulated such a restriction *and* Andrew had been
made aware of it by the co-author
 or if Andrew wishes to assign the copyright
 or if Andrew wishes to exclusively licence it. 

For any other use, Andrew requires no explicit permission from his
co-author.


> 
> - anton

0
Alex
1/13/2014 5:21:17 PM
On Mon, 13 Jan 2014 10:45:42 -0600, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:

>At risk of repeating myself, I still don't think it's worth
>resurrecting <BUILDS DOES> for, especially given that CREATE DOES> can
>be made to work even on such a target with some contortions.

This statement is in danger of being a "proof by repeated assertion".

I have not yet managed to convince myself that I could detect all
the potential cases without having at least a spare page of Flash.
I also feel that the complexity of sticking with CREATE ... DOES>
outweighs the simplicity of adding <BUILDS.

If you believe that you have a full solution that avoids rewriting
Flash, then please let us know of it. Rewriting 1 bits to 0 is
acceptable, except for those processors (and they exist) that erase
Flash to zero.

After all, none of these Flash systems are claiming full ANS
compliance as far as I know.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
0
stephenXXX
1/13/2014 7:05:19 PM
On Sun, 12 Jan 2014 10:40:07 -0600, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:

>Paul Rubin <no.email@nospam.invalid> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> Extending the Forth Environment to Single Chip Microprocessors,
>>> A. P. Haley and C. L. Stephens, proc. Rochester Forth Conference on
>>> Industrial Automation, June 20-24, 1989.
>> 
>> Any chance of an upload?
>
>I guess I could scan it, but I've been a bit worried about copyrights.
>I think that no-one would object, but what is allowed is all a bit
>murky.  It really would be wonderful to scan and push the lot; having
>it only on paper is a real nuisance.

Didn't Peter Knaggs recently post that Larry has given him permission
to put JFAR on the web? If that is so, I would suggest that Rochester
papers are also safe. You could always ask Larry or Peter.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
0
stephenXXX
1/13/2014 7:10:43 PM
Stephen Pelc wrote:

> On Mon, 13 Jan 2014 10:45:42 -0600, Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:
> 
>>At risk of repeating myself, I still don't think it's worth
>>resurrecting <BUILDS DOES> for, especially given that CREATE DOES> can
>>be made to work even on such a target with some contortions.
> 
> This statement is in danger of being a "proof by repeated assertion".

I think Andrew has the problem that <BUILDS had there been once.  What if 
BUFFER: had there been once, and was dropped because CREATE ALLOT could do 
it just as good?  Now we would have it back.

> I have not yet managed to convince myself that I could detect all
> the potential cases without having at least a spare page of Flash.
> I also feel that the complexity of sticking with CREATE ... DOES>
> outweighs the simplicity of adding <BUILDS.

That's the main point.  These system *are* resource-constrained, so you 
don't want expensive and complicated workarounds.  And at least for the 
systems created by various people around Forth Gesellschaft, the educational 
value is also important. My experience with educating newcomers is that the 
easier it is, the more they will understand (obvious ;-).

> If you believe that you have a full solution that avoids rewriting
> Flash, then please let us know of it. Rewriting 1 bits to 0 is
> acceptable, except for those processors (and they exist) that erase
> Flash to zero.

On those you do rewriting 0 bits to 1.  The way I do it on Gforth EC R8C is 
that each code field is two cells wide, the second cell usually unused.  The 
labels for DOVAR and DODOES are manually arranged in a way that you can 
overwrite DOVAR with DODOES.  DODOES uses this second unused cell.

Downsides:

* Every word wastes one cell of precious memory (could be reduced to wasting 
only cells on CREATE)
* No more than one DOES> per CREATE
* Write a flash cell twice, which is actually allowed on the R8C in "data 
flash" (which is where the user-created program resides, as it also allows 
for more erase cycles than program flash)

> After all, none of these Flash systems are claiming full ANS
> compliance as far as I know.

I think Gforth EC R8C is fully ANS compliant when you use RAM mode for 
multiple-DOES> on a CREATE (that's the only thing that doesn't work in 
flash). Certainly it's limited to CORE and some TOOLS words.

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

0
Bernd
1/13/2014 7:53:48 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>At risk of repeating myself, I still don't think it's worth
>resurrecting <BUILDS DOES> for

Yes, now we can discuss how to support the program-in-flash systems.

It seems that Bernd Paysan suggests adding <BUILDS and then having the
program-in-flash systems have environmental restrictions on not using
CREATE...DOES> and using DOES> on <BUILDS-created words only once.

This does not look attractive to me.  I don't think it will produce a
significantly higher number of programs portable to these platforms
than the current situation.

Another idea would be to phase out CREATE...DOES> in favour of
<BUILDS...DOES> for all systems.  Do the benefits of <BUILDS for the
program-in-flash systems really outweigh the costs to all programs?

Or is there a better idea for solving the problem?


- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/14/2014 8:31:36 AM
"Ed" <invalid@invalid.com> writes:
>0-based PICK ROLL has been normative since '83.  If Anton wishes to challenge
>the decision, it is *he* who must demonstrate why 1-based is better, or at least
>performance neutral.  He has not done so but instead presses others to do his
>homework.

It was you who claimed (in <laaf88$q7i$1@speranza.aioe.org>):

|Forth is empirically based.  It matters whether a majority of cases favour a
|particular solution.  It was this that drove the decision to make PICK and
|ROLL zero-based - even at the expense of breaking code.

I asked you to elaborate on that claim.  Which you did not do.

>0-based is optimum when implementing PICK and ROLL e.g. an Intel 386 n/c PICK
>is just one instruction.

Let's see:

iForth version 2.1.2541, generated 00:39:42, January 28, 2007.
i6 binary, native floating-point, double precision.
Copyright 1996 - 2007 Marcel Hendrix.

FORTH> see pick 
Flags: ANSI
$080A4DA8  : PICK                           8BC083ED048F4500        .@.m..E.
$080A4DB0  pop         ebx                  5B                      [
$080A4DB1  inc         ebx                  43                      C
$080A4DB2  shl         ebx, 2 b#            C1E302                  Ac.
$080A4DB5  push        ebx                  53                      S
$080A4DB6  call        SP@ ( $0809EE38 ) offset NEAR 
                                            E87DA0FFFF              h  
$080A4DBB  pop         ebx                  5B                      [
$080A4DBC  pop         eax                  58                      X
$080A4DBD  add         ebx, eax             01C3                    .C
$080A4DBF  mov         ebx, [ebx 0 +] dword 8B1B                    ..
$080A4DC1  push        ebx                  53                      S
$080A4DC2  ;                                8B450083C504            .E..E.
$080A4DC8  jmp         eax                  FFE0                   `

Apparently Marcel did not optimize the general PICK, fitting for a
word that is not used often.  But note how the Forth-83 PICK caused
the "inc ebx" at $080A4DB1, which would not be present if PICK had
stayed with the Forth-79 specification.

Another go:

Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
see pick 
Code pick  
( $804C634 )  mov     ebp , dword ptr 4 [edi] [ebp*4]  \ $8B $6C $AF $4 
....

Here Forth-83 PICK is indeed just one instruction (plus NEXT), but so
is Forth-79 PICK, which would look like this:

mov     ebp , dword ptr 0 [edi] [ebp*4]

>1-based may appear beneficial in calculations involving SP@
>however such gain is illusory as it is obtained at the expense of making PICK ROLL
>longer/slower which affects all uses.

As can be seen, Forth-79 PICK is neither longer nor slower than
Forth-83 PICK.

And even if your claim was true, which it isn't, it would not justify
replacing Forth-79 PICK with a differently-named "0-based" word in
Forth-83, and certainly not changing the specification of PICK
incompatibly.

>FD 4/5 lists K. Scheisliek as author of the 0-based PICK ROLL proposal.  If Anton
>wants more convincing he might consider contacting the author.

I will ask him when I see him.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/14/2014 9:05:04 AM
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Yes, now we can discuss how to support the program-in-flash systems....
> Another idea would be to phase out CREATE...DOES> in favour of
> <BUILDS...DOES> for all systems.  Do the benefits of <BUILDS for the
> program-in-flash systems really outweigh the costs to all programs?

Surely there's an awful lot of code out there using CREATE DOES> by now.

Can there ever be more than one CREATE at a time where the code pointer
can still potentially be overwritten?  Is it enough to just assign a RAM
cell to hold the code pointer for the most recently created symbol, with
the compiler knowing to look there for it?  You'd write it out to flash
when the next symbol is created.  At the end of the program text you
might have to type "finished" or such, to make sure that the flash for
the last created word got updated.

Maybe I don't understand the problem correctly.
0
Paul
1/14/2014 9:33:41 AM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Stephen Pelc wrote:
> 
>> On Mon, 13 Jan 2014 10:45:42 -0600, Andrew Haley
>> <andrew29@littlepinkcloud.invalid> wrote:
>> 
>>>At risk of repeating myself, I still don't think it's worth
>>>resurrecting <BUILDS DOES> for, especially given that CREATE DOES> can
>>>be made to work even on such a target with some contortions.
>> 
>> This statement is in danger of being a "proof by repeated assertion".
> 
> I think Andrew has the problem that <BUILDS had there been once.

How is this a problem?

> On those you do rewriting 0 bits to 1.  The way I do it on Gforth EC R8C is 
> that each code field is two cells wide, the second cell usually unused.  The 
> labels for DOVAR and DODOES are manually arranged in a way that you can 
> overwrite DOVAR with DODOES.  DODOES uses this second unused cell.
> 
> Downsides:
> 
> * Every word wastes one cell of precious memory (could be reduced to wasting 
> only cells on CREATE)

Hold on a second: are you saying that you waste a cell for every word
(rather than just words from CREATE) voluntarily and unnecessarily,
yet you are complaining about the overhead that could be avoided by
<BUILDS ?

> * No more than one DOES> per CREATE
> * Write a flash cell twice, which is actually allowed on the R8C in "data 
> flash" (which is where the user-created program resides, as it also allows 
> for more erase cycles than program flash)

But... the alternative, <BUILDS, also wastes one cell per child of
DOES> , and it also has to write a flash cell twice, does it not?

There has to be a pointer to RAM from flash, and there has to be a
pointer to code.  So that's two cells.  This is true whether DOES> is
used or not.  When DOES> is used, add a pointer to the DOES> code
and overwrite some bits of the pointer to code.  So, there are now
three pointers.

Andrew.
0
Andrew
1/14/2014 9:41:30 AM
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Yes, now we can discuss how to support the program-in-flash systems....
>> Another idea would be to phase out CREATE...DOES> in favour of
>> <BUILDS...DOES> for all systems.  Do the benefits of <BUILDS for the
>> program-in-flash systems really outweigh the costs to all programs?
>
>Surely there's an awful lot of code out there using CREATE DOES> by now.

Yes, changing that would be the cost.  Do the benefits justify that
cost?  It does not seem so to me.

>Can there ever be more than one CREATE at a time where the code pointer
>can still potentially be overwritten?

Not in standard Forth.

>Is it enough to just assign a RAM
>cell to hold the code pointer for the most recently created symbol, with
>the compiler knowing to look there for it?  You'd write it out to flash
>when the next symbol is created.  At the end of the program text you
>might have to type "finished" or such, to make sure that the flash for
>the last created word got updated.

Probably also falls into Bernd's "too clever" category, and it would
probably be even more complicated than what he is doing now, but it
could save the second cell even for non-DOES> CREATEd words.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/14/2014 10:05:10 AM
>Paul Rubin <no.email@nospam.invalid> writes:
>>Is it enough to just assign a RAM
>>cell to hold the code pointer for the most recently created symbol, with
>>the compiler knowing to look there for it?  You'd write it out to flash
>>when the next symbol is created.

Pitfall:

variable foo
create bar  1 , ' bar foo !
foo @ execute @ .
create flip 2 ,
foo @ execute @ .

With the usual header organizations, the xt would change when you move
bar to its final destination; and you have no way of tracking all the
places where the xt could be stored.

Another implementation idea:

For a CREATE...DOES> word the header is in flash, the body is in RAM,
no?  So for a CREATEd word the flash dictionary pointer is not moved
until the next word is defined.  So we can append additional data to
the header later.  We don't need to reserve a second cell from the
start, only when we see a DOES>.

I.e., the header after CREATE would look like

Other header fields (name, link, etc.)
code field: dovar
            body pointer

DOES> would then change dovar to dodoes (with Bernd's clever trick),
and appends the code pointer, resulting in:

Other header fields (name, link, etc.)
code field: dodoes
            body pointer
            pointer to code behind DOES>

So CREATEd words don't need the extra code pointer in general, only in
connection with DOES>.  Anything wrong with this idea (apart from also
using the "too clever" trick)?

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/14/2014 11:58:24 AM
On Tuesday, January 14, 2014 10:05:04 AM UTC+1, Anton Ertl wrote:
> "Ed" <invalid@invalid.com> writes:
[..]
> Apparently Marcel did not optimize the general PICK, fitting for a
> word that is not used often.  But note how the Forth-83 PICK caused
> the "inc ebx" at $080A4DB1, which would not be present if PICK had
> stayed with the Forth-79 specification.

I don't want to interfere in this discussion, but FYI, 
more representative iForth results can be seen when 
PICK is actually *used*:

FORTH> : tt 0 pick ; ' tt idis
$01304D40  : tt
$01304D4A  mov           rbx, [rsp] qword
$01304D4E  push          rbx
$01304D4F  ;
FORTH> : tt 1 pick ; ' tt idis
Redefining tt
$01304DC0  : tt
$01304DCA  mov           rbx, [rsp 8 +] qword
$01304DCF  push          rbx
$01304DD0  ;
FORTH> : tt 19 pick ; ' tt idis
Redefining tt
$01304E40  : tt
$01304E4A  mov           rbx, [rsp #152 +] qword
$01304E52  push          rbx
$01304E53  ;

Maybe I didn't know how to do this in 2007, because PICK 
has special problems (unrelated to 0/1 indexing).

[..]

-marcel
0
mhx
1/14/2014 12:05:05 PM
mhx@iae.nl writes:
>On Tuesday, January 14, 2014 10:05:04 AM UTC+1, Anton Ertl wrote:
>> "Ed" <invalid@invalid.com> writes:
>[..]
>> Apparently Marcel did not optimize the general PICK, fitting for a
>> word that is not used often.  But note how the Forth-83 PICK caused
>> the "inc ebx" at $080A4DB1, which would not be present if PICK had
>> stayed with the Forth-79 specification.
>
>I don't want to interfere in this discussion, but FYI, 
>more representative iForth results can be seen when 
>PICK is actually *used*:
>
>FORTH> : tt 0 pick ; ' tt idis
>$01304D40  : tt
>$01304D4A  mov           rbx, [rsp] qword
>$01304D4E  push          rbx
>$01304D4F  ;
>FORTH> : tt 1 pick ; ' tt idis
>Redefining tt
>$01304DC0  : tt
>$01304DCA  mov           rbx, [rsp 8 +] qword
>$01304DCF  push          rbx
>$01304DD0  ;
>FORTH> : tt 19 pick ; ' tt idis
>Redefining tt
>$01304E40  : tt
>$01304E4A  mov           rbx, [rsp #152 +] qword
>$01304E52  push          rbx
>$01304E53  ;
>
>Maybe I didn't know how to do this in 2007, because PICK 
>has special problems (unrelated to 0/1 indexing).

You did know it, but your SEE is too clever, so I did not see this,
but only something very close to source code.

iForth version 2.1.2541, generated 00:39:42, January 28, 2007.
i6 binary, native floating-point, double precision.
Copyright 1996 - 2007 Marcel Hendrix.

FORTH> : tt 0 pick ; ' tt idis 
$08166280  : [trashed]                      8BC083ED048F4500        .@.m..E.
$08166288  mov         ebx, [esp 0 +] dword 8B1C64                  ..d
$0816628B  push        ebx                  53                      S
$0816628C  ;                                8B450083C504            .E..E.
FORTH> see tt 
Flags: TOKENIZE, ANSI
: tt  0 PICK ;  ok

Anyway, the usage of PICK with a constant argument is very common, and
as demonstrated, modern compilers optimize it into a plain stack
access, and the "base" plays no role for the generated code.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/14/2014 12:36:06 PM
On Tue, 14 Jan 2014 03:41:30 -0600, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:

>But... the alternative, <BUILDS, also wastes one cell per child of
>DOES> , and it also has to write a flash cell twice, does it not?

<BUILDS is only used with DOES> and must be used with DOES> in
such systems. Thus the critical part can be left as $FFFF and
can then be modified by DOES>. This still requires you to be
able to program an unused two-byte unit in Flash, but many
Flash systems do permit this. The MSP430 in paticular has
a suitably friendly Flash.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
0
stephenXXX
1/14/2014 1:07:48 PM
Andrew Haley wrote:
>> * Every word wastes one cell of precious memory (could be reduced to
>> wasting only cells on CREATE)
> 
> Hold on a second: are you saying that you waste a cell for every word
> (rather than just words from CREATE) voluntarily and unnecessarily,
> yet you are complaining about the overhead that could be avoided by
> <BUILDS ?

No, I just follow the general idea from the concept of not having <BUILDS 
that CREATE is the vanilla defining word, and all other defining words are 
one way or another derived from CREATE, and there's no special casing for 
DOES> (this is to be compatible with code that makes that assumption - non-
standard code, though, but not worth breaking).  There is an additional 
pointer to RAM, as well...  but that one really is only there if it needs to 
be.  The usual case for CREATE DOES> is constant data, and therefore, there 
should be a way to have constant ROM-based data after the CREATE (not 
wasting precious RAM and one pointer less in precious flash).

Let's say you want a cell array in RAM, so you would define:

: array: ( n -- )
  <BUILDS RAM here ROM , RAM cells allot
  DOES> ( n <addr> -- )  @ swap cells + ;

This separation of RAM and ROM even makes sense on a native code desktop 
Forth like VFX, iForth or bigForth, as you don't worry about sharing data 
and code in the code cache, you only worry about sharing writable data (this 
can cause a big performance hit).

> But... the alternative, <BUILDS, also wastes one cell per child of
> DOES> , and it also has to write a flash cell twice, does it not?

<BUILDS would give a reason for special-casing it - it is not the root of 
all defining words, but the special case for DOES>.  And as the usual 
embedded flashs are word-writable, you just put in the DOES> address when 
you get to the DOES>.

> There has to be a pointer to RAM from flash, and there has to be a
> pointer to code.  So that's two cells.  This is true whether DOES> is
> used or not.  When DOES> is used, add a pointer to the DOES> code
> and overwrite some bits of the pointer to code.  So, there are now
> three pointers.

Yes; the point is that there has to be one additional unused pointer for 
every header that can be modified by DOES>.

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

0
Bernd
1/14/2014 4:53:02 PM
In article <lb3q1e$ibt$1@online.de>, Bernd Paysan  <bernd.paysan@gmx.de> wrote:
>Andrew Haley wrote:
>>> * Every word wastes one cell of precious memory (could be reduced to
>>> wasting only cells on CREATE)
>>
>> Hold on a second: are you saying that you waste a cell for every word
>> (rather than just words from CREATE) voluntarily and unnecessarily,
>> yet you are complaining about the overhead that could be avoided by
>> <BUILDS ?
>
>No, I just follow the general idea from the concept of not having <BUILDS
>that CREATE is the vanilla defining word, and all other defining words are
>one way or another derived from CREATE, and there's no special casing for
>DOES> (this is to be compatible with code that makes that assumption - non-
>standard code, though, but not worth breaking).  There is an additional

No, CREATE is not the vanilla defining word! This became very clear to me
when I started designing my own indirectly threaded Forth.
CREATE is tied to DOES>. For example ciforth doesn't relate VARIABLE
in any way to CREATE and the standard doesn't require it to.
On the other hand, the standard requires CREATE'd words to have a pointer
and that must be a pointer to high level code, i.e. : ; type of code.
In many implementation, especially those compiling to native code, the
impression exists that that can be the code pointer, the same code pointer
that exists in assembler words like DROP and +.
Many implementation seem to manage that double use, or at least use enough
tricks to confound the issue.
On the other hand, in an indirect threaded forth the issue is clear.
VARIABLE has a code pointer to DOVAR, and a data area.
CREATE has a code pointer to DODOES and a data area consisting of two
fields: the DOES> pointer and the BODY in the ISO sense.
The does pointer is data, as we are well aware as soon as we are thinking
flash and separation between code and data.

Much I've seen in this thread has to do with attempts of double use
of the code pointer and the DOES> pointer. A case of premature optimisation
if there was one, and -- may I repeat -- the root of much evil.

<SNIP>

>Yes; the point is that there has to be one additional unused pointer for
>every header that can be modified by DOES>.

Let's embrace it, it is the Standard.
And I wouldn't say it is unused, superfluous maybe.

>--
>Bernd Paysan
>
-- 
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

0
albert
1/14/2014 5:35:37 PM
On 1/14/14 6:53 AM, Bernd Paysan wrote:
> Andrew Haley wrote:
>>> * Every word wastes one cell of precious memory (could be reduced to
>>> wasting only cells on CREATE)
>>
>> Hold on a second: are you saying that you waste a cell for every word
>> (rather than just words from CREATE) voluntarily and unnecessarily,
>> yet you are complaining about the overhead that could be avoided by
>> <BUILDS ?
> 
> No, I just follow the general idea from the concept of not having <BUILDS
> that CREATE is the vanilla defining word, and all other defining words are
> one way or another derived from CREATE, and there's no special casing for
> DOES> (this is to be compatible with code that makes that assumption - non-
> standard code, though, but not worth breaking).

CREATE has been tied to DOES> since 1994, 20 years now. It's good to
avoid breaking standard code, but tying yourself in knots to protect
non-standard code is unnecessary and inappropriate. CREATE can, in some
implementations, be a generic defining word, but it isn't expected to
be, and Forth94 explicitly avoided making that a requirement or even an
expectation.

> There is an additional
> pointer to RAM, as well...  but that one really is only there if it needs to
> be.  The usual case for CREATE DOES> is constant data, and therefore, there
> should be a way to have constant ROM-based data after the CREATE (not
> wasting precious RAM and one pointer less in precious flash).

I absolutely deny that "the *usual* case for CREATE DOES> is constant
data". In my experience, the most common use of it is to build variable
arrays.

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."
==================================================
0
Elizabeth
1/14/2014 6:23:37 PM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>>> * Every word wastes one cell of precious memory (could be reduced to
>>> wasting only cells on CREATE)
>> 
>> Hold on a second: are you saying that you waste a cell for every word
>> (rather than just words from CREATE) voluntarily and unnecessarily,
>> yet you are complaining about the overhead that could be avoided by
>> <BUILDS ?
> 
> No, I just follow the general idea from the concept of not having
> <BUILDS that CREATE is the vanilla defining word, and all other
> defining words are one way or another derived from CREATE, and
> there's no special casing for DOES> (this is to be compatible with
> code that makes that assumption - non- standard code, though, but
> not worth breaking).  There is an additional pointer to RAM, as
> well...  but that one really is only there if it needs to be.  The
> usual case for CREATE DOES> is constant data, 

Well, it's both, really.

> and therefore, there should be a way to have constant ROM-based data
> after the CREATE (not wasting precious RAM and one pointer less in
> precious flash).

But that's very nonstandard: by definition anything after CREATE is
writable.

> Let's say you want a cell array in RAM, so you would define:
> 
> : array: ( n -- )
>  <BUILDS RAM here ROM , RAM cells allot
>  DOES> ( n <addr> -- )  @ swap cells + ;
> 
> This separation of RAM and ROM even makes sense on a native code
> desktop Forth like VFX, iForth or bigForth, as you don't worry about
> sharing data and code in the code cache, you only worry about
> sharing writable data (this can cause a big performance hit).

Of course, I know that, but there's no reason that

: array: ( n -- )
   create cells allot
   does> ( n <addr> -- )  swap cells + ;

can't work, given appropriate definitions for CREATE and DOES>

>> There has to be a pointer to RAM from flash, and there has to be a
>> pointer to code.  So that's two cells.  This is true whether DOES> is
>> used or not.  When DOES> is used, add a pointer to the DOES> code
>> and overwrite some bits of the pointer to code.  So, there are now
>> three pointers.
> 
> Yes; the point is that there has to be one additional unused pointer
> for every header that can be modified by DOES>.

You don't need to allocate space for that pointer until DOES> is
executed, therefore there is no space wasted.

Andrew.
0
Andrew
1/14/2014 7:19:08 PM
In FlashForth CREATE compiles DOVAR and the address of the free data space.
DOES> then modifies DOVAR to DOtheDOEScode.


: defer create ['] abort , does> @execute ;
' abort . 4480 ok

ram here . 1024 ok
ram defer ping ok
see ping
62dc eb27 rcall DODEFER
62de 1024       pointer to ram
ok
1024 4480       address of abort

flash here . 62ea ok
flash defer pong ok
see pong
62f2 eb1c rcall DODEFER
62f4 62f6       pointer to  flash
62f6 4480       address of abort
ok

This works quite well but requires that DOVAR can be modified to the DODEFER in the example.
Without buffering flash in ram it is a bit difficult to implement on some flash architectures,
specially on flash that only supports block write.

In hindsight <BUILDS was a cleaner solution than CREATE because CREATE has been
given a double meaning with both of DOVAR and DOtheDOEScode.
And maybe some other DO actions as well...?
 
Mikael
0
oh2aun
1/14/2014 8:31:17 PM
Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> No, I just follow the general idea from the concept of not having
>> <BUILDS that CREATE is the vanilla defining word, and all other
>> defining words are one way or another derived from CREATE, and
>> there's no special casing for DOES> (this is to be compatible with
>> code that makes that assumption - non- standard code, though, but
>> not worth breaking).  There is an additional pointer to RAM, as
>> well...  but that one really is only there if it needs to be.  The
>> usual case for CREATE DOES> is constant data,
> 
> Well, it's both, really.

Yes, the problem with CREATE is that it is dual-purpose: First, CREATE 
<name> is just creating a data label.  And then, CREATE is the starting 
point of what becomes modified by DOES>.  There are systems where this dual 
use is no problem at all, and there are systems (as discusssed) where this 
dual use is really problematic.

The usual case of CREATE + ALLOT something in RAM is already dealt with 
BUFFER:, a special-purpose word.

>> and therefore, there should be a way to have constant ROM-based data
>> after the CREATE (not wasting precious RAM and one pointer less in
>> precious flash).
> 
> But that's very nonstandard: by definition anything after CREATE is
> writable.

Er, we are talking about dictionary-in-flash mode.  If you are in this mode, 
everything is exactly write-once.  If you want to have stuff in RAM, switch 
to RAM mode.

> Of course, I know that, but there's no reason that
> 
> : array: ( n -- )
>    create cells allot
>    does> ( n <addr> -- )  swap cells + ;
> 
> can't work, given appropriate definitions for CREATE and DOES>

And ALLOT, which however is not the case.  ALLOT manipulates the current 
dictionary, and if that's flash (ROM), then it is write-once.  Defining 
VARIABLE in that mode will redirect you to RAM space (implemented as 
CONSTANT).

You can hide this fact by being clever, but being clever is orthogonal to 
being simple.  These resource-constrained environments absolutely require 
being simple.

> You don't need to allocate space for that pointer until DOES> is
> executed, therefore there is no space wasted.

Unfortunately, the user is allowed to allocate stuff from the dictionary 
*before* DOES> is executed.  However, when you hide the flash space, and the 
user only can manipulate RAM space, while all the code and header stuff goes 
to flash, this restriction goes away.

However, as these systems are very RAM-constrained, it is important that the 
user can put all constant data into flash.

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

0
Bernd
1/14/2014 8:37:25 PM
Elizabeth D. Rather wrote:
> On 1/6/14 3:45 PM, Ed wrote:
> > Elizabeth D. Rather wrote:
> > ...
> >> Not sure what the 31 characters is about.
> >
> > minimum WORD buffer size:
> > ANS  ...  31+2
> > '83  ...  255+2
>
> Ok, I found that reference, which I had forgotten. However, minimum
> specifications don't "break" programs. Only on very small embedded
> systems will you see a WORD buffer thus limited, and if it will cause
> your program pain, you need to document an environmental requirement for
> a WORD buffer of at least <n> bytes. That program will probably run into
> other difficulties anyway.

'94 didn't need to reduce the 255+2 minimum spec for WORD's buffer.
It need only have stated systems which did not meet the spec of 255+2
had an environmental dependency which might limit the Standard Programs
they could run.  Same deal for TYPE.

'94 could have retained the '83 specs and avoided the current silliness
which requires programmers to document entitlements which existed
in Forth from earliest days.  Embedded systems low on memory should
be using forth's scheme of overlapping buffers.  That'll guarantee them
a WORD buffer much greater than the ANS minimum.

> > ...
> > You ask what is broken?  Forth's credibility is broken.  You cannot expect people
> > to invest time and money in a language which chops and changes according to the
> > whims of "some people".
>
> The record of stability as well as system conformance since Forth94 has
> been exemplary. And a 6-year development period with users invited to 4
> meetings/year, all drafts published, and so many public review periods,
> can hardly be considered whimsical.

In 1993 when I obtained a copy of DPANS had someone told me it was manna
from heaven, I might have accepted it.  But that was 20 years ago and much water
has passed under the bridge.  I've seen too much to believe everything I read.







0
Ed
1/14/2014 9:39:32 PM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
> 
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> No, I just follow the general idea from the concept of not having
>>> <BUILDS that CREATE is the vanilla defining word, and all other
>>> defining words are one way or another derived from CREATE, and
>>> there's no special casing for DOES> (this is to be compatible with
>>> code that makes that assumption - non- standard code, though, but
>>> not worth breaking).  There is an additional pointer to RAM, as
>>> well...  but that one really is only there if it needs to be.  The
>>> usual case for CREATE DOES> is constant data,
>> 
>> Well, it's both, really.
> 
> Yes, the problem with CREATE is that it is dual-purpose: First,
> CREATE <name> is just creating a data label.  And then, CREATE is
> the starting point of what becomes modified by DOES>.  There are
> systems where this dual use is no problem at all, and there are
> systems (as discusssed) where this dual use is really problematic.

I don't think so.  I think you've shot yourself in the foot by doing
that.  I think the problem is using the name CREATE to define
something other than data space.

> The usual case of CREATE + ALLOT something in RAM is already dealt with 
> BUFFER:, a special-purpose word.
> 
>>> and therefore, there should be a way to have constant ROM-based data
>>> after the CREATE (not wasting precious RAM and one pointer less in
>>> precious flash).
>> 
>> But that's very nonstandard: by definition anything after CREATE is
>> writable.
> 
> Er, we are talking about dictionary-in-flash mode.

The dictionary has to be in flash, but HERE can certainly be in RAM.

>> Of course, I know that, but there's no reason that
>> 
>> : array: ( n -- )
>>    create cells allot
>>    does> ( n <addr> -- )  swap cells + ;
>> 
>> can't work, given appropriate definitions for CREATE and DOES>
> 
> And ALLOT, which however is not the case.  ALLOT manipulates the
> current dictionary, and if that's flash (ROM), then it is
> write-once.  Defining VARIABLE in that mode will redirect you to RAM
> space (implemented as CONSTANT).

OK, you can do it that way, but I don't know why you do it that way:
you could just as easily make ram the default space for ALLOT and
HERE, and use different names for the dictionary in flash.  That's
what I always did with systems with separate code and data spaces.  It
makes porting a heck of a lot easier.

But why do you care about standards re <BUILDS when your system is so
designed as to be utterly nonstandard?  That's the part I don't
understand.

Andrew.
0
Andrew
1/14/2014 10:12:48 PM
On 1/14/14 10:37 AM, Bernd Paysan wrote:
> Andrew Haley wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> No, I just follow the general idea from the concept of not having
>>> <BUILDS that CREATE is the vanilla defining word, and all other
>>> defining words are one way or another derived from CREATE, and
>>> there's no special casing for DOES> (this is to be compatible with
>>> code that makes that assumption - non- standard code, though, but
>>> not worth breaking).  There is an additional pointer to RAM, as
>>> well...  but that one really is only there if it needs to be.  The
>>> usual case for CREATE DOES> is constant data,
>>
>> Well, it's both, really.
>
> Yes, the problem with CREATE is that it is dual-purpose: First, CREATE
> <name> is just creating a data label.  And then, CREATE is the starting
> point of what becomes modified by DOES>.  There are systems where this dual
> use is no problem at all, and there are systems (as discusssed) where this
> dual use is really problematic.
>
> The usual case of CREATE + ALLOT something in RAM is already dealt with
> BUFFER:, a special-purpose word.
>
>>> and therefore, there should be a way to have constant ROM-based data
>>> after the CREATE (not wasting precious RAM and one pointer less in
>>> precious flash).
>>
>> But that's very nonstandard: by definition anything after CREATE is
>> writable.
>
> Er, we are talking about dictionary-in-flash mode.  If you are in this mode,
> everything is exactly write-once.  If you want to have stuff in RAM, switch
> to RAM mode.
>
>> Of course, I know that, but there's no reason that
>>
>> : array: ( n -- )
>>     create cells allot
>>     does> ( n <addr> -- )  swap cells + ;
>>
>> can't work, given appropriate definitions for CREATE and DOES>
>
> And ALLOT, which however is not the case.  ALLOT manipulates the current
> dictionary, and if that's flash (ROM), then it is write-once.  Defining
> VARIABLE in that mode will redirect you to RAM space (implemented as
> CONSTANT).

Wrong. ALLOT manipulates the *data space pointer* not the dictionary, 
and HERE returns the address of the next available location in *data 
space*.

Applications have no inherent right to manipulate dictionary space. Yes, 
there have always been (and still are) systems in which data space and 
dictionary are intermingled, but as a programmer you need to be able to 
think of them separately. That concept is essential for dealing with 
RAM/ROM/FLASH environments.

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."
==================================================
0
Elizabeth
1/14/2014 10:18:20 PM
Anton Ertl wrote:
> ...
> Here Forth-83 PICK is indeed just one instruction (plus NEXT), but so
> is Forth-79 PICK, which would look like this:
>
> mov     ebp , dword ptr 0 [edi] [ebp*4]
> ...
> As can be seen, Forth-79 PICK is neither longer nor slower than
> Forth-83 PICK.

Assuming your example is correct, one case does not make the rule.
Based on my experience, if every system were required to adopt the
'79 convention for PICK and ROLL definitions would be needlessly
longer and slower.

> >FD 4/5 lists K. Scheisliek as author of the 0-based PICK ROLL proposal.  If Anton
> >wants more convincing he might consider contacting the author.
>
> I will ask him when I see him.

Since you don't take me seriously, next time try the experts before
coming to me.  Better still, don't come to me at all.



0
Ed
1/15/2014 12:37:06 AM
Elizabeth D. Rather wrote:
> Wrong. ALLOT manipulates the *data space pointer* not the dictionary,
> and HERE returns the address of the next available location in *data
> space*.
> 
> Applications have no inherent right to manipulate dictionary space. Yes,
> there have always been (and still are) systems in which data space and
> dictionary are intermingled, but as a programmer you need to be able to
> think of them separately. That concept is essential for dealing with
> RAM/ROM/FLASH environments.

The RAM/ROM part is orthogonal to data/code.  ROM is for constant data and 
constant code, RAM is for variables.  There's a lot of constant data, as 
well, and RAM can be used for temporary code - we do have use cases for 
that, too.  Some processors (8051, AVR) assign flash and RAM to these roles 
by being Harward architectures, others don't.

The current standard is not fitting well with the situation we have on these 
small controllers.  Andrew asks me why I bother with standards when my 
system is uttrly non-standard.  The reason is: I do care, but I can't, 
because the standard collides hard with the reality of these systems - so 
this opens up the question whether this is a problem with the standard or 
these systems.  One reality of these systems is that code and data are no 
longer separated in flash and RAM - the more recent systems are von Neumann 
architectures, you can intermingle data and code - and it helps to fully 
utilize the few resources if you do.

We are not talking about esotheric hardware, we are talking about mainstream 
controllers - whether small ARM Cortex-M0 or -M1, the MSP430, or the R8C 
family.  They all are no longer arcane 8 bit microcontrollers as it used to 
be, but scaled down derivatives of respected architectures (PDP-11 in case 
of MSP430 and R8C, ARM Thumb mode in case of the Cortex series).

Programs written for such systems can still be portable.  If you don't have 
a flash, but everything is in RAM (like on a PC), well, then writing to the 
ROM space is actually possible.  The program that doesn't write into ROM 
space still will work.  Unless you overdo it with switching between RAM and 
ROM, all you need to do on a PC is to define the two words as NOOP.

Let's give an example: In the R8C port of Dirk Zoller's Tetris for 
Terminals, bricks look like that (comments partially stripped in this code 
for faster downloading):

\ Define shapes of bricks:

: def-brick create
  does> rot 4 * rot + 2* + ;

: ,s" [char] " parse bounds
    DO  i c@ c,  LOOP ;

def-brick brick1
   ,s"         "
   ,s" ######  "
   ,s"   ##    "
   ,s"         "

This is all ROM space, because we have a number of bricks, but we don't have 
enough RAM for all the bricks - and the data is constant, anyways.  Then we 
have the space for two bricks which is actually in RAM:

\ this brick is actually in use:

ram
def-brick brick  ,s"         "
   ,s"         "
   ,s"         "
   ,s"         "

def-brick scratch ,s"         "
   ,s"         "
   ,s"         "
   ,s"         "
rom

The whole program fits very tightly into the available memory.  My 
experience with all these projects is that they fill up all available space, 
and therefore have to make best use of what's there.  Being free to select 
RAM or ROM for data is one of the key features that allows this.  Having one 
intermingled dictionary is also conceptually easier.  Remember: We use these 
controllers as carrot on a stick to get people interested in Forth.  It is 
much more fun to program these controllers in Forth than with C, and we do 
get them that way.  They are not interested in Forth on PCs, because Python 
gives them all they need, including interactiviy.  Python doesn't run on a 
controller.

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

0
Bernd
1/15/2014 3:19:14 AM
Bernd Paysan <bernd.paysan@gmx.de> writes:
>The usual case for CREATE DOES> is constant data, and therefore, there 
>should be a way to have constant ROM-based data after the CREATE (not 
>wasting precious RAM and one pointer less in precious flash).

But the standard CREATE...DOES> must put the data in RAM, because the
user is entitled to do stuff like

5 ' foo >body !

at any time if FOO has been CREATEd and at least one cell has been
ALLOTed.  And changing the body of a child of CREATE...DOES> is pretty
common (e.g., consider the reference implementation of X:deferred), so
dealing with that by "environmental restriction" is not a good idea.

How about this:

CREATE...DOES> has writable data.  <BUILDS...DOES> has read-only data.
The incentive for programmers to use <BUILDS where appropriate even
when they don't care for flash-based systems would be the possibility
that the compiler may optimize accesses to the data.

Implementation on a flash-based system:

CREATE produces

dovar (probably same code as docon)
RAM body pointer

If DOES> sees a dovar, it turns it into

dodoesram
RAM body pointer
code pointer

<BUILDS produces

dodoesflash
placeholder for code pointer

if DOES> sees a dodoesflash, it stores the code pointer in the
placeholder.

>Let's say you want a cell array in RAM, so you would define:
>
>: array: ( n -- )
>  <BUILDS RAM here ROM , RAM cells allot
>  DOES> ( n <addr> -- )  @ swap cells + ;

With the ideas above it might be something like either

: array: ( n1 -- )
  create cells allot
 does> ( n2 -- )
  @ swap cells + ;

or something like

: array: ( n1 -- )
  here cells allot <builds ,
 does> ( n2 -- )
  @ swap cells + ;

>This separation of RAM and ROM even makes sense on a native code desktop 
>Forth like VFX, iForth or bigForth, as you don't worry about sharing data 
>and code in the code cache, you only worry about sharing writable data (this 
>can cause a big performance hit).

It's pretty straightforward to get rid of the cache consistency
problems by just separating code from data, no need for new Forth
words; and that will also eliminate other issues, in particular
consistency problems between any kind of data and code (P5 and K6) and
lower cache utilization (any CPU with separate I-cache and D-cache).

But marking some memory areas as read-only can help optimization.  I
am not sure that ROM and RAM really are the best way to do that (e.g.,
it probably would not help for ALLOCATEd memory), but maybe they are
good enough.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/15/2014 5:52:10 PM
On Wed, 15 Jan 2014 17:52:10 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>How about this:
>
>CREATE...DOES> has writable data.  <BUILDS...DOES> has read-only data.
>The incentive for programmers to use <BUILDS where appropriate even
>when they don't care for flash-based systems would be the possibility
>that the compiler may optimize accesses to the data.
>
>Implementation on a flash-based system:
>
>CREATE produces
>
>dovar (probably same code as docon)
>RAM body pointer
>
>If DOES> sees a dovar, it turns it into
>
>dodoesram
>RAM body pointer
>code pointer
>
><BUILDS produces
>
>dodoesflash
>placeholder for code pointer
>
>if DOES> sees a dodoesflash, it stores the code pointer in the
>placeholder.

So DOES> always writes twice to Flash. No, no, no.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
0
stephenXXX
1/15/2014 9:56:41 PM
Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>The usual case for CREATE DOES> is constant data, and therefore, there
>>should be a way to have constant ROM-based data after the CREATE (not
>>wasting precious RAM and one pointer less in precious flash).
> 
> But the standard CREATE...DOES> must put the data in RAM, because the
> user is entitled to do stuff like
> 
> 5 ' foo >body !
> 
> at any time if FOO has been CREATEd and at least one cell has been
> ALLOTed.  And changing the body of a child of CREATE...DOES> is pretty
> common (e.g., consider the reference implementation of X:deferred), so
> dealing with that by "environmental restriction" is not a good idea.

You tell the Forth system whether it's RAM or ROM, so you know that you can 
only put constants into ROM (write-once flash).  If the user wants RAM, he 
says RAM.  DEFER in flash is useful for forward references (write-once 
pattern).

Arguing that the standard entitles to treat everything as RAM and therefore 
you don't want to have stuff in flash is a bit silly, because this is 
exactly the deficit of the standard implementers on small embedded systems 
face: You have much more flash than RAM on all of them.

> But marking some memory areas as read-only can help optimization.  I
> am not sure that ROM and RAM really are the best way to do that (e.g.,
> it probably would not help for ALLOCATEd memory), but maybe they are
> good enough.

I wouldn't waste too much time on constant folding ALLOCATEd memory ;-).  
The main purpose of dynamic memory is to handle things that come and go.  If 
it is just a one-time allocation of static data, don't ALLOCATE it.

One thing worth to note about embedded systems is that this has become a 
moving target after 30 years of standstill and 8051.  Now we have these 
PDP-11 derivatives with little RAM and some flash; with some small ARMs in 
between (with similar memory architecture, but usually more memory than the 
MSP430s).  Maybe in a few years, we'll have ReRAM instead of flash, and the 
write-once problem is gone.

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

0
Bernd
1/16/2014 1:02:58 AM
Bernd Paysan <bernd.paysan@gmx.de> writes:
> Now we have these PDP-11 derivatives with little RAM and some flash;

Which are thosse?
0
Lars
1/16/2014 6:19:47 AM
Lars Brinkhoff <lars.spam@nocrew.org> writes:
> Bernd Paysan <bernd.paysan@gmx.de> writes:
>> Now we have these PDP-11 derivatives with little RAM and some flash;
> Which are thosse?

I think that means MSP430.
0
Paul
1/16/2014 8:22:11 AM
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Wed, 15 Jan 2014 17:52:10 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>How about this:
>>
>>CREATE...DOES> has writable data.  <BUILDS...DOES> has read-only data.
>>The incentive for programmers to use <BUILDS where appropriate even
>>when they don't care for flash-based systems would be the possibility
>>that the compiler may optimize accesses to the data.
>>
>>Implementation on a flash-based system:
>>
>>CREATE produces
>>
>>dovar (probably same code as docon)
>>RAM body pointer
>>
>>If DOES> sees a dovar, it turns it into
>>
>>dodoesram
>>RAM body pointer
>>code pointer
>>
>><BUILDS produces
>>
>>dodoesflash
>>placeholder for code pointer
>>
>>if DOES> sees a dodoesflash, it stores the code pointer in the
>>placeholder.
>
>So DOES> always writes twice to Flash. No, no, no.

<BUILDS...DOES> writes to each cell only once.  The placeholder is not
written before the code pointer is written there.

CREATE...DOES> writes to the code field cell twice, using the trick
that Bernd uses now.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/16/2014 9:30:21 AM
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>The usual case for CREATE DOES> is constant data, and therefore, there
>>>should be a way to have constant ROM-based data after the CREATE (not
>>>wasting precious RAM and one pointer less in precious flash).
>> 
>> But the standard CREATE...DOES> must put the data in RAM, because the
>> user is entitled to do stuff like
>> 
>> 5 ' foo >body !
>> 
>> at any time if FOO has been CREATEd and at least one cell has been
>> ALLOTed.  And changing the body of a child of CREATE...DOES> is pretty
>> common (e.g., consider the reference implementation of X:deferred), so
>> dealing with that by "environmental restriction" is not a good idea.
>
>You tell the Forth system whether it's RAM or ROM, so you know that you can 
>only put constants into ROM (write-once flash).

Sure, once you have a non-standard word like ROM in your program, from
then on everything goes.  E.g., you could make ROM CREATE behave like
what I suggested for <BUILDS.

>Arguing that the standard entitles to treat everything as RAM and therefore 
>you don't want to have stuff in flash is a bit silly, because this is 
>exactly the deficit of the standard implementers on small embedded systems 
>face: You have much more flash than RAM on all of them.

I understand why there is the desire to put stuff into flash where the
standard requires writable memory.  The questions are:

Do you want to comply with the standard?

If so, what should be added to the standard to support these
flash-based systems?

If you implement standard words in a non-compliant way, you obviously
have no interest in the standard, and we can stop this discussion.

>> But marking some memory areas as read-only can help optimization.  I
>> am not sure that ROM and RAM really are the best way to do that (e.g.,
>> it probably would not help for ALLOCATEd memory), but maybe they are
>> good enough.
>
>I wouldn't waste too much time on constant folding ALLOCATEd memory ;-).  
>The main purpose of dynamic memory is to handle things that come and go.  If 
>it is just a one-time allocation of static data, don't ALLOCATE it.

Knowing that stuff in ALLOCATEd memory won't change can be used for
optimization even if that memory is later freed.  The implementation
of such optimizations is non-trivial, though.

And there are also good uses of ALLOCATE for memory that will not be FREEd.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/16/2014 9:33:18 AM
Paul Rubin wrote:

> Lars Brinkhoff <lars.spam@nocrew.org> writes:
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>> Now we have these PDP-11 derivatives with little RAM and some flash;
>> Which are thosse?
> 
> I think that means MSP430.

R8C also has a PDP-11 derived instruction set.  On the upper end, Freescale 
has now smaller ColdFire MCUs, which also could count as PDP-11 inspired 
ISAs (though 32 bit).  The smallest V1 MCU has 8k RAM and 128k flash.  The 
same applies as with the smaller controllers: Flash is ample, RAM is scarce.

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

0
Bernd
1/16/2014 2:38:04 PM
Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>You tell the Forth system whether it's RAM or ROM, so you know that you
>>can only put constants into ROM (write-once flash).
> 
> Sure, once you have a non-standard word like ROM in your program, from
> then on everything goes.  E.g., you could make ROM CREATE behave like
> what I suggested for <BUILDS.

"anything goes" still doesn't make sense.  People use tutorials like the one 
in Gforth's manual, or Starting Forth, and therefore, the ROM switch can 
only do one thing: Make the ROM the dictionary.  You can't play Humpty 
Dumpty, you must make your additions consistent, and thus easy to learn.

>>Arguing that the standard entitles to treat everything as RAM and
>>therefore you don't want to have stuff in flash is a bit silly, because
>>this is exactly the deficit of the standard implementers on small embedded
>>systems face: You have much more flash than RAM on all of them.
> 
> I understand why there is the desire to put stuff into flash where the
> standard requires writable memory.  The questions are:
> 
> Do you want to comply with the standard?

Yes.  This reduces porting effort, and makes programmers more portable (i.e. 
they have to learn less idiosyncracies to be productive with an embedded 
Forth).

> If so, what should be added to the standard to support these
> flash-based systems?

There's already something in the (to be reviewed and rewritten) cross 
compiler proposal: We need ways to deal with the fact that there can be more 
than one contiguous memory for the dictionary, and that the properties of 
these regions differ (write-many, write-once, write-few for EEPROM).

This requires adding conceptional stuff like what a write-once or write-few 
memory is, adding standard names for operators writing there (it is 
sometimes not possible to use standard ! to do so), and I think it is better 
to resurrect <BUILDS than relying on the two tricky methods I and 
Albert/Willem use.

The other option for write-once memory is a combination of

DOER: <name> ... ;

BUILDS ( doer "name" )

where you get all the header building done in one atomic operation, and then 
there is no confusion possible about how many times you could use DOES> 
(it's an atomic operation).

> If you implement standard words in a non-compliant way, you obviously
> have no interest in the standard, and we can stop this discussion.

This is the "there is no middle ground" logical fallacy: The standard has a 
deficit, i.e. a conflict between reality (write-once flash is a reality) and 
the fiction in the standard, that all memory is write-many.

I think we need to revisit the cross compiler stuff, and split it up into 
different parts, the same way we did it for the internationalization stuff.  
Each part should deal with one specific topic.  That way it is easier to 
integrate into the standard, and the components are more flexible to use 
(e.g. the memory regions can be used by flash-based standalone systems).

> Knowing that stuff in ALLOCATEd memory won't change can be used for
> optimization even if that memory is later freed.  The implementation
> of such optimizations is non-trivial, though.
> 
> And there are also good uses of ALLOCATE for memory that will not be
> FREEd.

You won't see an ALLOCATE on a small embedded system, so the discussion 
about ALLOCATE with constant data (and complicated optimizations on those) 
certainly is for larger systems only ;-).  If you are lucky, you'll get a 
native code compiler in the bigForth style on a small system (with macro 
copies, and a bit of peephole optimization).

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

0
Bernd
1/16/2014 3:09:47 PM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> 
> There's already something in the (to be reviewed and rewritten) cross 
> compiler proposal: We need ways to deal with the fact that there can be more 
> than one contiguous memory for the dictionary, and that the properties of 
> these regions differ (write-many, write-once, write-few for EEPROM).
> 
> This requires adding conceptional stuff like what a write-once or write-few 
> memory is, adding standard names for operators writing there (it is 
> sometimes not possible to use standard ! to do so), and I think it is better 
> to resurrect <BUILDS than relying on the two tricky methods I and 
> Albert/Willem use.
> 
> The other option for write-once memory is a combination of
> 
> DOER: <name> ... ;
> 
> BUILDS ( doer "name" )
> 
> where you get all the header building done in one atomic operation, and then 
> there is no confusion possible about how many times you could use DOES> 
> (it's an atomic operation).

Wouldn't it make more sense to have a word that simply takes an XT and
creates a header?  Or is there some implementation reason that won't
work?  I suppose there'd have to be a jump from the code that pushes
the address of the child word's data, which would be a bad thing, but
the result is notationally quite nice.

It'd look like

: constant   [: @ ;] builds , ;

The runtime action appears before the compile-time action.  Dunno if
that matters.

>> Knowing that stuff in ALLOCATEd memory won't change can be used for
>> optimization even if that memory is later freed.  The implementation
>> of such optimizations is non-trivial, though.
>> 
>> And there are also good uses of ALLOCATE for memory that will not be
>> FREEd.
> 
> You won't see an ALLOCATE on a small embedded system, so the discussion 
> about ALLOCATE with constant data (and complicated optimizations on those) 
> certainly is for larger systems only ;-).

Mmmm, but people keep tellink me that an embedded system has 128k of
RAM and half a megabyte of flash!  :-)

Andrew.
0
Andrew
1/17/2014 9:28:22 AM
In article <05GdnYkiIN4rakXPnZ2dnUVZ_tWdnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>
>> There's already something in the (to be reviewed and rewritten) cross
>> compiler proposal: We need ways to deal with the fact that there can be more
>> than one contiguous memory for the dictionary, and that the properties of
>> these regions differ (write-many, write-once, write-few for EEPROM).
>>
>> This requires adding conceptional stuff like what a write-once or write-few
>> memory is, adding standard names for operators writing there (it is
>> sometimes not possible to use standard ! to do so), and I think it is better
>> to resurrect <BUILDS than relying on the two tricky methods I and
>> Albert/Willem use.
>>
>> The other option for write-once memory is a combination of
>>
>> DOER: <name> ... ;
>>
>> BUILDS ( doer "name" )
>>
>> where you get all the header building done in one atomic operation, and then
>> there is no confusion possible about how many times you could use DOES>
>> (it's an atomic operation).
>
>Wouldn't it make more sense to have a word that simply takes an XT and
>creates a header?  Or is there some implementation reason that won't
>work?  I suppose there'd have to be a jump from the code that pushes
>the address of the child word's data, which would be a bad thing, but
>the result is notationally quite nice.

If you have a generic header system, then you finally would have
a clean way to handle xt's. xt's are part of the problem, not the
solution.

>
>It'd look like
>
>: constant   [: @ ;] builds , ;

>
>The runtime action appears before the compile-time action.  Dunno if
>that matters.
>
>>> Knowing that stuff in ALLOCATEd memory won't change can be used for
>>> optimization even if that memory is later freed.  The implementation
>>> of such optimizations is non-trivial, though.
>>>
>>> And there are also good uses of ALLOCATE for memory that will not be
>>> FREEd.
>>
>> You won't see an ALLOCATE on a small embedded system, so the discussion
>> about ALLOCATE with constant data (and complicated optimizations on those)
>> certainly is for larger systems only ;-).
>
>Mmmm, but people keep tellink me that an embedded system has 128k of
>RAM and half a megabyte of flash!  :-)
>
>Andrew.
-- 
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

0
albert
1/17/2014 11:39:38 AM
> <BUILDS...DOES> writes to each cell only once.  The placeholder is not
> written before the code pointer is written there.
> 
> CREATE...DOES> writes to the code field cell twice, using the trick
> that Bernd uses now.
> 
> - anton

Oh yes, this is the problem I face both on MSP430 and ARM Cortex M while compiling into Flash and posted to this list some time ago. Please finally address write once Flash memory in standard conferences. I vote for a <builds does> approach. Re-Does> should not be asked for in standard and should be declared as possible environmental depedence.

Additionally, create should exist in two flavours on native code systems: one (create) with no action at all for hand-coded assembly definitions and create or create> with the common standard action : create> <builds ( -- ) does> ( -- addr ) ; "put address on stack" for data tables.

Matthias
0
Matthias
1/17/2014 11:44:17 AM
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> In article <05GdnYkiIN4rakXPnZ2dnUVZ_tWdnZ2d@supernews.com>,
> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>>
>>> There's already something in the (to be reviewed and rewritten) cross
>>> compiler proposal: We need ways to deal with the fact that there can be more
>>> than one contiguous memory for the dictionary, and that the properties of
>>> these regions differ (write-many, write-once, write-few for EEPROM).
>>>
>>> This requires adding conceptional stuff like what a write-once or write-few
>>> memory is, adding standard names for operators writing there (it is
>>> sometimes not possible to use standard ! to do so), and I think it is better
>>> to resurrect <BUILDS than relying on the two tricky methods I and
>>> Albert/Willem use.
>>>
>>> The other option for write-once memory is a combination of
>>>
>>> DOER: <name> ... ;
>>>
>>> BUILDS ( doer "name" )
>>>
>>> where you get all the header building done in one atomic operation, and then
>>> there is no confusion possible about how many times you could use DOES>
>>> (it's an atomic operation).
>>
>>Wouldn't it make more sense to have a word that simply takes an XT and
>>creates a header?  Or is there some implementation reason that won't
>>work?  I suppose there'd have to be a jump from the code that pushes
>>the address of the child word's data, which would be a bad thing, but
>>the result is notationally quite nice.
> 
> If you have a generic header system, then you finally would have
> a clean way to handle xt's. xt's are part of the problem, not the
> solution.

I don't know what you mean.

Andrew.
0
Andrew
1/17/2014 2:16:52 PM
On Friday, January 17, 2014 1:44:17 PM UTC+2, Matthias Koch wrote:

> Oh yes, this is the problem I face both on MSP430 and ARM Cortex M while =
compiling into Flash and posted to this list some time ago. Please finally =
address write once Flash memory in standard conferences. I vote for a <buil=
ds does> approach. Re-Does> should not be asked for in standard and should =
be declared as possible environmental depedence.
>=20
> Additionally, create should exist in two flavours on native code systems:=
 one (create) with no action at all for hand-coded assembly definitions and=
 create or create> with the common standard action : create> <builds ( -- )=
 does> ( -- addr ) ; "put address on stack" for data tables.
> Matthias

For FlashForth I tried to find
a solution that makes interactive usage comfortable.
The cross compiler standard is not really applicable for a native system so=
 I skipped that.

The requirements were:

1. Possibility to have data space in all types of memory.
-> RAM EEPROM FLASH words to select the dataspace.

2. Possibility to compile code in all types of memory.
-> COMPILETOFLASH COMPILETORAM COMPILETOXXXX words to select the compilatio=
n target memory.
-> Only needed for VonNeumann, not for Harvard architecture.

3. Same words for both VonNeumann and Harvard architectures.
-> @ ! C@ C! that works with all kind of memory
-> @ ! C@ C! can branch to read/write routines based on address mapped memo=
ry types
   if the hardware does not support it directly.
-> Gets rid of multiple copies of highlevel words for each memory type.

4. Works with both block and word writeable flash.
-> Automatic ram buffer for flash writes (=3DAlways block write).
-> Enables multiple writes to flash solving all problems with word headers,=
 CREATE and DOES>
-> No need for the programmer to worry if the memory is writeonce or writef=
ew.
-> MARKER FORGET works in an optimal way.
-> Enables also peephole optimiser.

5. No need to reflash the kernel whatever the user throws at the system
-> Kernel write protection inside the flash write code.=20
-> Address range check in flash block write or HW write protection.
-> Cold literals can always be copied from write protected flash.
-> The word COLD is always FINDable.

The only case where this generic solution does not work is with flash contr=
ollers
that are very small and do not have ram to buffer one flash block.
Those controllers would need the <BUILDS word.

Some controlled writing of the word header bits is still needed
if you want to combine several bits in one write=20
(IMMEDIATE_MASK COMPILEONLY_MASK INLINED_MASK AND AND LATEST !)
Or are all flashes word:bit writeable ?

Mikael

0
oh2aun
1/17/2014 4:05:27 PM
on 17/01/2014 14:16:48, Andrew Haley wrote:
> Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>> In article <05GdnYkiIN4rakXPnZ2dnUVZ_tWdnZ2d@supernews.com>,
>> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>>>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>>>
>>>> There's already something in the (to be reviewed and rewritten) cross
>>>> compiler proposal: We need ways to deal with the fact that there can be more
>>>> than one contiguous memory for the dictionary, and that the properties of
>>>> these regions differ (write-many, write-once, write-few for EEPROM).
>>>>
>>>> This requires adding conceptional stuff like what a write-once or write-few
>>>> memory is, adding standard names for operators writing there (it is
>>>> sometimes not possible to use standard ! to do so), and I think it is better
>>>> to resurrect <BUILDS than relying on the two tricky methods I and
>>>> Albert/Willem use.
>>>>
>>>> The other option for write-once memory is a combination of
>>>>
>>>> DOER: <name> ... ;
>>>>
>>>> BUILDS ( doer "name" )
>>>>
>>>> where you get all the header building done in one atomic operation, and then
>>>> there is no confusion possible about how many times you could use DOES>
>>>> (it's an atomic operation).
>>>
>>>Wouldn't it make more sense to have a word that simply takes an XT and
>>>creates a header?  Or is there some implementation reason that won't
>>>work?  I suppose there'd have to be a jump from the code that pushes
>>>the address of the child word's data, which would be a bad thing, but
>>>the result is notationally quite nice.
>>
>> If you have a generic header system, then you finally would have
>> a clean way to handle xt's. xt's are part of the problem, not the
>> solution.
> 
> I don't know what you mean.
> 
> Andrew.
> 

I suspect we're going to have a discussion about name tokens (nts). 
0
Alex
1/17/2014 4:06:53 PM
oh2aun@gmail.com writes:
>Some controlled writing of the word header bits is still needed
>if you want to combine several bits in one write=20
>(IMMEDIATE_MASK COMPILEONLY_MASK INLINED_MASK AND AND LATEST !)
>Or are all flashes word:bit writeable ?

AFAIK they are at best cell-writable (sometimes twice to allow byte
writing).  IMMEDIATE and similar flags are certainly also a challenge,
and it's interesting that they have not been mentioned here before.

One implementation approach would be to store that information
elsewhere (e.g., a list that contains all immediate words; I leave
thinking up optimizations as an exercise to the reader).

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/17/2014 4:43:43 PM
Anton Ertl wrote:
> AFAIK they are at best cell-writable (sometimes twice to allow byte
> writing).  IMMEDIATE and similar flags are certainly also a challenge,
> and it's interesting that they have not been mentioned here before.

Yes, I wonder a bit about that, too.  I do immediate and compile-only by 
having these bits 1 as "inactive", and overwrite them with zero; in total, a 
flash word might then receive three writes.

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

0
Bernd
1/17/2014 7:37:01 PM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Anton Ertl wrote:
>> AFAIK they are at best cell-writable (sometimes twice to allow byte
>> writing).  IMMEDIATE and similar flags are certainly also a challenge,
>> and it's interesting that they have not been mentioned here before.
> 
> Yes, I wonder a bit about that, too.  I do immediate and compile-only by 
> having these bits 1 as "inactive", and overwrite them with zero; in total, a 
> flash word might then receive three writes.

Just a thought: couldn't a header or a word be constructed in a
staging area and moved to flash later?  That wouldn't be much more
complicated than all the other, er, techniques we've been talking
abut.  :-)

Andrew.
0
Andrew
1/18/2014 10:40:23 AM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Anton Ertl wrote:
>>> AFAIK they are at best cell-writable (sometimes twice to allow byte
>>> writing).  IMMEDIATE and similar flags are certainly also a challenge,
>>> and it's interesting that they have not been mentioned here before.
>> 
>> Yes, I wonder a bit about that, too.  I do immediate and compile-only by 
>> having these bits 1 as "inactive", and overwrite them with zero; in total, a 
>> flash word might then receive three writes.
>
>Just a thought: couldn't a header or a word be constructed in a
>staging area and moved to flash later?  That wouldn't be much more
>complicated than all the other, er, techniques we've been talking
>abut.  :-)

Test case:

: foo does> drop ." bla" ;
defer bar
create flip
['] flip is bar
flip .
bar .
foo
bar
immediate
] flip [
bar

The Chuck Moore way to do it would be to meet the requirements with a
specification that is more appropriate for the technology than the
standard Forth syntax for DOES> and IMMEDIATE.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/18/2014 11:56:39 AM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>> Anton Ertl wrote:
>>>> AFAIK they are at best cell-writable (sometimes twice to allow byte
>>>> writing).  IMMEDIATE and similar flags are certainly also a challenge,
>>>> and it's interesting that they have not been mentioned here before.
>>> 
>>> Yes, I wonder a bit about that, too.  I do immediate and compile-only by 
>>> having these bits 1 as "inactive", and overwrite them with zero; in total, a 
>>> flash word might then receive three writes.
>>
>>Just a thought: couldn't a header or a word be constructed in a
>>staging area and moved to flash later?  That wouldn't be much more
>>complicated than all the other, er, techniques we've been talking
>>abut.  :-)
> 
> Test case:
> 
> : foo does> drop ." bla" ;
> defer bar
> create flip
> ['] flip is bar
> flip .
> bar .
> foo
> bar
> immediate
> ] flip [
> bar

What is the naked "] flip [" supposed to do?

I can't see why this wouldn't work.  Can you explain the problem you
see here?  Is it that code cannot be executed from RAM?

> The Chuck Moore way to do it would be to meet the requirements with
> a specification that is more appropriate for the technology than the
> standard Forth syntax for DOES> and IMMEDIATE.

Perhaps so, but we seem rather to be making a mountain out of a
molehill.

Andrew.
0
Andrew
1/18/2014 4:54:12 PM
Anton Ertl wrote:
> The Chuck Moore way to do it would be to meet the requirements with a
> specification that is more appropriate for the technology than the
> standard Forth syntax for DOES> and IMMEDIATE.

Gforth's new word vtable approach also uses a staging area, as the words 
modifying the vtable (like SET-COMPILER and SET-TO) follow this state-
machine design principle.  The staging area is modified until the next 
header is created, and at that point it is finalized (and put into the 
normal dictionary if necessary - if it's a unique new vtable configuration).

The alternative approach would be something like a normal class hierarchy: 
You define the class you want to use before you create words of that class.  
The current way Gforth works is prototype based: You copy a vtable, and 
modify it if you need to (and if there's no modification, you actually refer 
to the original).

As I started implementing this, the cross compiler got the normal class 
hierarchy approach (because that's easier to implement there), and the 
actual system got the more flexible prototype-based staging area approach.  
It turned out to be so much better that the cross compiler then got the same 
staging approach.

That's certainly stuff that won't go into a small embedded system.  YMMV, 
and my experience is that for small systems and small cross compilers, the 
immediate concept is not a good idea.  Rather use something like

macro: <name> ... ;

instead for words that run in compilation mode (cross compiler: on the 
host).

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

0
Bernd
1/18/2014 5:11:22 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Wouldn't it make more sense to have a word that simply takes an XT and
>creates a header?  Or is there some implementation reason that won't
>work?  I suppose there'd have to be a jump from the code that pushes
>the address of the child word's data, which would be a bad thing, but
>the result is notationally quite nice.
>
>It'd look like
>
>: constant   [: @ ;] builds , ;

Nice.  In particular, if we have serveral alternative behaviour
implementations for the defined words, this avoids the pretty opaque
code we need now.  E.g., instead of

: imp-a DOES> code for implementation A ;
: imp-b DOES> code for implementation B ;
: def-something
  create ...
  some-condition if
    imp-a
  else
    imp-b
  then ;

we could write:

: def-something
  some-condition if
    [: code for implementation A ;]
  else
    [: code for implementation B ;]
  then
  builds ... ;

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/18/2014 5:21:35 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>>> Anton Ertl wrote:
>>>>> AFAIK they are at best cell-writable (sometimes twice to allow byte
>>>>> writing).  IMMEDIATE and similar flags are certainly also a challenge,
>>>>> and it's interesting that they have not been mentioned here before.
>>>> 
>>>> Yes, I wonder a bit about that, too.  I do immediate and compile-only by 
>>>> having these bits 1 as "inactive", and overwrite them with zero; in total, a 
>>>> flash word might then receive three writes.
>>>
>>>Just a thought: couldn't a header or a word be constructed in a
>>>staging area and moved to flash later?  That wouldn't be much more
>>>complicated than all the other, er, techniques we've been talking
>>>abut.  :-)
>> 
>> Test case:
>> 
>> : foo does> drop ." bla" ;
>> defer bar
>> create flip
>> ['] flip is bar
>> flip .
>> bar .
>> foo
>> bar
>> immediate
>> ] flip [
>> bar
>
>What is the naked "] flip [" supposed to do?

Perform the compilation semantics of FLIP, which happens to be the
execution semantics, because FLIP is (now) immediate.  I.e., print
"bla".

>I can't see why this wouldn't work.  Can you explain the problem you
>see here?  Is it that code cannot be executed from RAM?

You are right.  This test would not detect the problem that I am
thinking about: You can change a word with DOES> after you have ticked
it; so if you put it from the staging area into flash after ticking
(typically when you define the next word), will the xts that you have
created earlier still work as required by the standard?

The following test case should be better:

: foo does> drop ." bla" ;
defer bar
create flip
['] flip is bar
flip .
bar .
foo
bar
immediate
] flip [
create flop
bar

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/18/2014 5:36:19 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Bernd Paysan <bernd.paysan@gmx.de> wrote:
>>>>> Anton Ertl wrote:
> 
>>I can't see why this wouldn't work.  Can you explain the problem you
>>see here?  Is it that code cannot be executed from RAM?
> 
> You are right.  This test would not detect the problem that I am
> thinking about: You can change a word with DOES> after you have ticked
> it; so if you put it from the staging area into flash after ticking
> (typically when you define the next word), will the xts that you have
> created earlier still work as required by the standard?

Oh, I see.  It depends on what form an XT takes; it doesn't have to be
a simple address.  It could be a simple count, which would work just
fine.

Whether or not you would choose to support something like that in such
an environment just for the sake of standards compliance is another
matter.

Andrew.
0
Andrew
1/18/2014 6:17:11 PM
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> You are right.  This test would not detect the problem that I am
>> thinking about: You can change a word with DOES> after you have ticked
>> it; so if you put it from the staging area into flash after ticking
>> (typically when you define the next word), will the xts that you have
>> created earlier still work as required by the standard?
>
>Oh, I see.  It depends on what form an XT takes; it doesn't have to be
>a simple address.  It could be a simple count, which would work just
>fine.

A count, and then what?  If you have a table for getting from the xt
to the word address, that table will have the same problem: If you put
it in flash, you will first have to write one word address, later
another.

>Whether or not you would choose to support something like that in such
>an environment just for the sake of standards compliance is another
>matter.

Ok, one might have one of the following environmental restrictions in
the system:

1) Ticking a word is not allowed when the next word has not been
defined yet (the word is moved from the staging area to flash when the
next word is defined).

2) Using DOES> is not allowed on a word that has been ticked ((the
word is moved from the staging area to flash when the word is ticked
or when the next word is defined).

The second probably would affect very few programs.

- 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 2013: http://www.euroforth.org/ef13/
0
anton
1/18/2014 6:23:21 PM
Andrew Haley wrote:
> Oh, I see.  It depends on what form an XT takes; it doesn't have to be
> a simple address.

You can take it for granted that on a small embedded system it is a simple 
address.  The traditional computer science tells you that every problem can 
be solved by another indirection, but at cost of speed and memory.  And 
therefore, small embedded systems will not have these indirections.

The BUILDS ( xt "name" -- ) proposal has another problem: A doer is not an 
xt, it is the content of an xt.  With the two-cell code-field approach, this 
doesn't cause a problem: Your first cell, dobuilds, would simply take the 
second cell and execute it, after pushing the body on the stack, so

: Value  ['] @ builds , ;

will work (with @ being a primitive).  However, if the implementer likes to 
keep a one-cell code-field approach even for childs of builds, and use the 
doesjmp approach for implementing high-level doers, using an xt doesn't 
work.

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

0
Bernd
1/18/2014 7:24:08 PM
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> You are right.  This test would not detect the problem that I am
>>> thinking about: You can change a word with DOES> after you have ticked
>>> it; so if you put it from the staging area into flash after ticking
>>> (typically when you define the next word), will the xts that you have
>>> created earlier still work as required by the standard?
>>
>>Oh, I see.  It depends on what form an XT takes; it doesn't have to be
>>a simple address.  It could be a simple count, which would work just
>>fine.
> 
> A count, and then what? 

I've had a much better idea: the XT should be the address in flash
where the compiled word will be after it is copied.  EXECUTE can
detect that an address isn't (yet) an address in the dictionary, so
the code to execute must be in the staging area.

Andrew.
0
Andrew
1/18/2014 8:00:58 PM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>> Oh, I see.  It depends on what form an XT takes; it doesn't have to be
>> a simple address.
> 
> You can take it for granted that on a small embedded system it is a
> simple address.

It seems to me that the goalposts are continually being moved.

First I point out that for a really small system a chipFORTH-like
umbilical cross-compiler will work much better, at which point Stephen
points out to me that we're talking about something much larger, so I
propose a better way to handle compilation to flash in such a system,
at which point you tell me that no, it really is small.

Andrew.
0
Andrew
1/18/2014 8:05:33 PM
Andrew Haley wrote:
> It seems to me that the goalposts are continually being moved.

Different people have different goalposts.

> First I point out that for a really small system a chipFORTH-like
> umbilical cross-compiler will work much better, at which point Stephen
> points out to me that we're talking about something much larger, so I
> propose a better way to handle compilation to flash in such a system,
> at which point you tell me that no, it really is small.

The typical targets we (Forth Gesellschaft) are dealing with have about 
16-32kB flash, which is plenty for a standalone Forth system, but often only 
1k of RAM, which is really tight.  And part of our motivation is that these 
systems are educational, i.e. they should be easy to understand, which means 
their implementation should be straight-forward.

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

0
Bernd
1/18/2014 10:12:04 PM
Op Sat, 18 Jan 2014 11:56:39 GMT schreef Anton Ertl:

<snip>
> Test case:
> 
>: foo does> drop ." bla" ;
> defer bar
> create flip
> ['] flip is bar
What is ['] doing here? I would have written:
  ' flip is bar

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 
0
Coos
1/19/2014 12:12:35 AM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>> It seems to me that the goalposts are continually being moved.
> 
> Different people have different goalposts.
> 
>> First I point out that for a really small system a chipFORTH-like
>> umbilical cross-compiler will work much better, at which point Stephen
>> points out to me that we're talking about something much larger, so I
>> propose a better way to handle compilation to flash in such a system,
>> at which point you tell me that no, it really is small.
> 
> The typical targets we (Forth Gesellschaft) are dealing with have about 
> 16-32kB flash, which is plenty for a standalone Forth system, but often only 
> 1k of RAM, which is really tight.  And part of our motivation is that these 
> systems are educational, i.e. they should be easy to understand, which means 
> their implementation should be straight-forward.

Sure, but if you actually want to use something like this you probably
need to use most or all of that 1k for your application, in which case
cross-compiling is the only way to go.

Andrew.
0
Andrew
1/19/2014 9:38:34 AM
On Fri, 17 Jan 2014 03:28:22 -0600, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:

>Mmmm, but people keep tellink me that an embedded system has 128k of
>RAM and half a megabyte of flash!  :-)

I just could not resist the temptation to tease.

However, there's a serious point in all this. The chip of choice
for teaching electronics and software is probably an MSP430. It
has a reasonable CPU; humans can read the data sheets and understand
it; and it can be had in a DIP package. DIP packaging is important
because schools (at least in the UK) use solderless breadboards
which have tracks in one direction broken at the centre line.

After trying it a few times, I conclude that even the smallest
Cortex-M0 CPU is too complex (in terms of documentation) for
school and universities students as a first CPU.

TI do DIP MSP430s in the Launchpad family with programming tools.
These are cheap, but have fussy USB drivers. A Launchpad typically
has an MSP430G2553 CPU with 16k Flash and 512 bytes RAM.

For the next step up, we can move to a Cortex of some flavour. These
range from 32k Flash and 2k RAM at 24 MHz to 1/2 Mb Flash and 256 kb
RAM at 180 MHz. ST do a good range of low-cost Discovery boards with
integrated JTAG units.

I'm not going to reopen the umbilical versus standalone Forth debate.
I have developed and used both. However, the demand from people
involved with education is for a standalone embedded Forth.

On the topic of what to call the word that isn't CREATE and must
be used with DOES>, I suggest that we call it <CREATE as it reads
well and has no historical connection that I know of. Being a new
name, we can add as much or as little specification as is required
for a Flash system.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
0
stephenXXX
1/19/2014 12:32:31 PM
Andrew Haley wrote:
> Sure, but if you actually want to use something like this you probably
> need to use most or all of that 1k for your application, in which case
> cross-compiling is the only way to go.

No, since a standalone Forth system doesn't need much RAM.  After all, we 
don't implement your suggestions like staging areas for half-defined words.

I've understood your message: You want a cross compiler.  My experience is 
that I want a cross compiler when *program space* is too tight for a 
complete Forth.

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

0
Bernd
1/19/2014 1:03:00 PM
Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>> Sure, but if you actually want to use something like this you probably
>> need to use most or all of that 1k for your application, in which case
>> cross-compiling is the only way to go.
> 
> No, since a standalone Forth system doesn't need much RAM.  After all, we 
> don't implement your suggestions like staging areas for half-defined words.
> 
> I've understood your message: You want a cross compiler.

Well, yes, it's better in every way.  And 1k really isn't very much
for an application, unless that application is utterly trivial.

Andrew.