Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #30165 > unrolled thread
| Started by | Laurent Laborde <kerdezixe@gmail.com> |
|---|---|
| First post | 2014-05-07 13:06 -0700 |
| Last post | 2014-05-07 20:01 -0700 |
| Articles | 20 on this page of 155 — 23 participants |
Back to article view | Back to comp.lang.forth
gforth too bloated ? Laurent Laborde <kerdezixe@gmail.com> - 2014-05-07 13:06 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-07 13:31 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-08 00:10 +0200
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-07 23:21 -0700
Re: gforth too bloated ? Laurent Laborde <kerdezixe@gmail.com> - 2014-05-08 04:07 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-08 14:21 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-09 17:36 +0000
Re: gforth too bloated ? dambere@web.de - 2014-05-09 15:01 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-10 00:05 +0200
Re: gforth too bloated ? Melzzzzz <mel@zzzzz.invalid> - 2014-05-10 00:30 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-10 09:16 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-10 03:27 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-09 20:42 -0700
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-07 22:32 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-07 21:06 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-09 04:14 -0500
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-09 13:42 -0400
Re: gforth too bloated ? Roger Levy <roger.levy@gmail.com> - 2014-05-09 11:48 -0700
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-09 15:18 -0400
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-09 09:19 -1000
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-09 15:30 -0400
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-09 13:21 -1000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 05:16 -0500
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 05:28 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-10 10:39 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 12:04 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-11 12:10 +0000
Re: gforth too bloated ? Bill Long <blongo@gmail.com> - 2014-05-11 13:11 +0000
Re: gforth too bloated ? Stan Barr <plan.b@dsl.pipex.com> - 2014-05-11 16:17 +0000
Re: gforth too bloated ? Bill Long <blongo@gmail.com> - 2014-05-11 17:10 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-11 08:34 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-11 22:12 +0200
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-12 00:38 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-12 00:35 +0000
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-11 23:29 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-11 23:37 -0700
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-11 23:40 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-12 00:39 -0700
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-12 10:20 +0000
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-12 05:10 -0700
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-13 09:17 +0000
Re: gforth too bloated ? Howerd <howerdo@yahoo.co.uk> - 2014-05-13 04:28 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-12 03:19 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-13 16:40 +0000
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-13 07:56 -1000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 11:52 +0000
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-14 08:15 -1000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 16:09 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 09:42 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 17:21 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 10:45 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-13 12:56 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 12:03 +0000
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-14 09:17 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-14 16:50 +0000
Re: gforth too bloated ? AKK <akk@nospam.org> - 2014-05-14 20:26 +0200
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-14 20:38 +0200
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-14 20:02 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-15 14:22 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-15 17:39 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 15:03 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 15:06 -0700
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 15:32 -0700
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-16 02:13 +0200
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-15 20:18 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 04:08 -0500
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 04:28 -0500
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 09:23 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 07:52 -0500
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-17 09:19 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 11:51 -0500
Re: gforth too bloated ? Samuel DEVULDER <samuel-dot-devulder-at-laposte-dot-net> - 2014-05-17 22:00 +0200
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-16 09:20 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 07:54 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-16 15:51 +0200
Re: gforth too bloated ? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-05-16 07:59 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 13:39 +0000
Re: gforth too bloated ? Mark Wills <markwills1970@gmail.com> - 2014-05-16 01:22 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 04:11 -0500
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-16 15:43 +0200
Re: gforth too bloated ? Mark Wills <markwills1970@gmail.com> - 2014-05-16 01:26 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-16 03:42 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 13:19 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-16 17:59 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-18 13:20 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-18 14:08 -0400
Re: gforth too bloated ? "Elizabeth D. Rather" <erather@forth.com> - 2014-05-18 10:07 -1000
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-21 21:37 -0400
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-22 10:06 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-22 10:04 +0000
Re: gforth too bloated ? Coos Haak <chforth@hccnet.nl> - 2014-05-22 15:39 +0200
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-22 13:36 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 11:59 +0000
Re: gforth too bloated ? m.a.m.hendrix@tue.nl - 2014-05-20 07:11 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 14:48 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-21 20:27 +0000
Re: gforth too bloated ? Mark Wills <markwills1970@gmail.com> - 2014-05-22 02:23 -0700
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:51 +0000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 13:41 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-21 17:41 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:41 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-21 17:40 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:16 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-17 21:09 -0400
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-15 03:57 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-15 15:50 +0200
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-15 10:07 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-16 16:33 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-17 08:04 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-17 19:03 +0200
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-18 04:06 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-19 01:38 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 13:38 +0000
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-20 21:39 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-21 15:49 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-17 20:30 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-17 17:59 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-18 04:08 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-18 11:07 +0000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-18 11:15 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-18 12:11 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 12:36 +0000
Re: gforth too bloated ? m.a.m.hendrix@tue.nl - 2014-05-20 07:17 -0700
Re: gforth too bloated ? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-05-20 16:26 +0200
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-20 09:27 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-20 15:48 +0000
Re: gforth too bloated ? "Alex McDonald" <blog@rivadpm.com> - 2014-05-20 18:35 +0100
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-21 03:45 -0500
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-21 14:28 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-21 11:56 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-21 20:54 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-22 14:06 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-22 17:02 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 13:05 +0000
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-23 19:19 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-22 14:30 +0000
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-22 12:09 -0500
Re: gforth too bloated ? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-21 17:22 -0400
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:03 +0000
Re: gforth too bloated ? "Alex McDonald" <blog@rivadpm.com> - 2014-05-20 16:57 +0100
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-20 21:28 +0200
Re: gforth too bloated ? "Alex McDonald" <blog@rivadpm.com> - 2014-05-20 21:56 +0100
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-21 00:21 +0200
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-21 21:42 +0000
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-22 02:15 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-23 14:47 +0000
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-21 14:12 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-21 21:24 +0000
Re: gforth too bloated ? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-10 12:00 +0000
Re: gforth too bloated ? rickman <gnuarm@gmail.com> - 2014-05-10 13:16 -0400
Re: gforth too bloated ? Paul Rubin <no.email@nospam.invalid> - 2014-05-10 11:05 -0700
Re: gforth too bloated ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-05-10 18:11 -0500
Re: gforth too bloated ? Bernd Paysan <bernd.paysan@gmx.de> - 2014-05-11 02:12 +0200
Re: gforth too bloated ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-09 16:36 +0000
Re: gforth too bloated ? jacko <jackokring@gmail.com> - 2014-05-07 20:01 -0700
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-23 14:41 +0000 |
| Message-ID | <2014May23.164148@mips.complang.tuwien.ac.at> |
| In reply to | #30540 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>On Tue, 20 May 2014 10:48:10 -0400, Anton Ertl
><anton@mips.complang.tuwien.ac.at> wrote:
>> Maybe not in such a simple definition as 2DUP, but in a more demanding
>> one, I expect more errors than with {: ... :}. If you have to
>> concentrate on both reversing the order of locals and whatever else is
>> going on in the word, there is an increased chance that you will
>> overlook something.
>>
>
>You already have to reverse the order in Forth. The stack image in
>Forth is expressed in reverse order: ( a b c -- ) The c itme is on
>the top of the stack.
Yes, that's not the reverse order, that's the push order (c is pushed
last). It's the same order as {: ... :} is using, and the reverse
order of what LOCALS| is using. You confuse yourself by calling both
orders "reverse".
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-05-21 17:40 -0400 |
| Message-ID | <op.xf8buihs6zenlw@localhost> |
| In reply to | #30471 |
On Tue, 20 May 2014 07:59:36 -0400, Anton Ertl
<anton@mips.complang.tuwien.ac.at> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>> On Sun, 18 May 2014 09:20:57 -0400, Anton Ertl
>> <anton@mips.complang.tuwien.ac.at> wrote:
>>> However, what you missed is that, however simple you may claim the
>>> reversal is, you got the order in this relatively simple definition
>>> wrong on the first attempt.
>>
>> Not true.
>>
>> I was asking about why a word used to define locals wasn't used.
>> That seemed far more reasonable to me than the braces.
>>
>> You chose a Forth, iForth, which happened to have a word LOCAL
>> which worked similarly to what I was asking about and named the
>> same as what I chose, but has a different ordering from what I
>> posted. That doesn't get to redefine or define the order on
>> what I posted.
>>
>> So, the supposedly incorrect ordering was actually "ex post facto".
>
> Name one Forth system that has LOCAL, where the first version of your
> 2DUP works!
>
I can't because none of them exist. I was not aware that a word named
LOCAL existed in some Forths. As far as I knew, it was only the name
I applied to the concept I was attempting to discuss: replacing brace
based locals with a single word declaring each local independently. If
that's what's causing you issues, we can change it if you wish, ex post
facto, so that it's less confusing as to what I was saying:
s/LOCAL/RODSLOCALCONCEPT/
> The word LOCAL has been discussed here several times, always with the
> meaning implemented in iForth. Why do you claim you had a different
> meaning in mind, [...]
See above.
> [...] and if so, why did you not explain that meaning when
> you posted the code, nor when I first pointed out the mistake [...]
It seemed obvious to me, but it's clear now that my perspective
is different from yours.
> (instead, you posted two versions of the code that would work with
> iForth).
I was just pointing out that if an actual implemenation of the concept
works differently than a theoretical one, it's easy to correct the syntax.
> So how would you specify your LOCAL with { ... } like ordering, and
> how would it be implemented?
As stated previously, (see "Admittedly, it's likely...") if an
implementation is stack based it would likely to work like iForth.
If some other method was used, it could be different.
>>> Reverse polish notation is "x y -"
>>
>> Is that "x - y" or "y - x" ... ?
>
> x-y in infix is x y - in postfix.
Is x subtracted from y or is y subtracted from x? It's not clear
from Forth's "x y - " order. Typically, Forth use the top-of-stack
as the primary value operated against. That would indicate x is
subtracted from y. That's the opposite of the actual ordering.
I.e., this is an example where ordering is "not important" in Forth.
This was stated previously here:
>> Most stack operators operate against the top-of-stack as the
>> primary data item. Subtraction in Forth is reversed from that.
>> The point is that the order is not clear, and could be perceived
>> as being reversed by some people, even some Forth programmers.
>> I.e., it could be argued that subtraction in Forth should've
>> been implemented as "y - x".
>>
>> So, how is the "reversed" order here any different from LOCAL?
>
> Are you really arguing that subtraction in Forth should have reversed
> arguments [...] in order to justify that the error-prone LOCAL is
> "better" than { ... } ?
No, I'm pointing out that Forth has never made any attempt at using
a rational and consistent order of operations. I.e., if it's not a
problem with other long implemented things in Forth, why does is it
matter for LOCALS? From my perspective, the answer is that it doesn't.
It's rhetorical.
> (without giving a reason for that)
This was stated previously too:
RP> "Most stack operators operate against the top-of-stack as the
primary data item."
> Reality check: The ordering of - arguments is not reversed, [...]
...
> [...] and the iForth LOCAL is error-prone, [...]
As my brother likes to say for any statements he perceives to be
unfounded: "That's YOUR opinion."
The point is it shouldn't really matter if it's backwards or error
prone in Forth. Forth is rife with such unfixed issues.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-23 14:16 +0000 |
| Message-ID | <2014May23.161603@mips.complang.tuwien.ac.at> |
| In reply to | #30539 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>>>> Reverse polish notation is "x y -"
>>>
>>> Is that "x - y" or "y - x" ... ?
>>
>> x-y in infix is x y - in postfix.
>
>Is x subtracted from y or is y subtracted from x?
2 1 - gives 1.
>It's not clear
> from Forth's "x y - " order.
It's clearly specified in the standard:
|6.1.0160 - minus CORE ( n1|u1 n2|u2 -- n3|u3 )
|
|Subtract n2|u2 from n1|u1, giving the difference n3|u3.
>Typically, Forth use the top-of-stack
>as the primary value operated against.
Why do you think so? The rules I give in the Gforth tutorial
<http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Designing-the-stack-effect-Tutorial.html>
are:
|The general guideline is to design the stack effect such that the word
|is simple to use in most cases, even if that complicates the
|implementation of the word. Some concrete rules are:
|
| * Words consume all of their parameters (e.g., .).
| * If there is a convention on the order of parameters (e.g., from
| mathematics or another programming language), stick with it
| (e.g., -).
| * If one parameter usually requires only a short computation
| (e.g., it is a constant), pass it on the top of the
| stack. Conversely, parameters that usually require a long
| sequence of code to compute should be passed as the bottom
| (i.e., first) parameter. This makes the code easier to read,
| because the reader does not need to keep track of the bottom
| item through a long sequence of code (or, alternatively, through
| stack manipulations). E.g., ! (store, see Memory) expects the
| address on top of the stack because it is usually simpler to
| compute than the stored value (often the address is just a
| variable).
| * Similarly, results that are usually consumed quickly should be
| returned on the top of stack, whereas a result that is often
| used in long computations should be passed as bottom
| result. E.g., the file words like open-file return the error
| code on the top of stack, because it is usually consumed quickly
| by throw; moreover, the error code has to be checked before
| doing anything with the other results.
|
|These rules are just general guidelines, don't lose sight of the
|overall goal to make the words easy to use. E.g., if the convention
|rule conflicts with the computation-length rule, you might decide in
|favour of the convention if the word will be used rarely, and in
|favour of the computation-length rule if the word will be used
|frequently (because with frequent use the cost of breaking the
|computation-length rule would be quite high, and frequent use makes it
|easier to remember an unconventional order).
>No, I'm pointing out that Forth has never made any attempt at using
>a rational and consistent order of operations. I.e., if it's not a
>problem with other long implemented things in Forth, why does is it
>matter for LOCALS? From my perspective, the answer is that it doesn't.
It matters for other words, even if you did not understand how to
design good stack effects. In any case, the issue with LOCAL and
LOCALS| is different. If I have a word FOO with stack effect ( a b c
-- d ), and I want to pass a=1, b=2, and c=3, I write
1 2 3 foo
There is no reordering involved here. And if I want to put these
values in locals, I write
: foo { a b c -- d }
... ;
And as demonstrated by RODSLOCALCONCEPT, this is also the order that
you were thinking of first. By contrast, with LOCALS or iForth's
LOCAL, I have to reverse the order, which requires extra mental
effort.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-05-17 21:09 -0400 |
| Message-ID | <op.xf06tgmb6zenlw@localhost> |
| In reply to | #30419 |
On Fri, 16 May 2014 09:19:00 -0400, Anton Ertl
<anton@mips.complang.tuwien.ac.at> wrote:
> : test { x y } x y x y ; ok
> : test
> >l >l @local0 @local1 @local0 @local1 lp+2 ;
What seems to be an issue is that for an interpreter to compile the
body, then 'x' or 'y' *MUST* be in the dictionary. They must be
immediate words, compiling words, and somehow made temporary so they
aren't left in the dictionary.
That's not including the issue of defining them and assigning the
appropriate local to them which must be handled with { brace.
The other option is to define another interpreter for } brace ...
The rest can be restructured as mentioned in Andrew's post, so that
the compiled code for lp+2 corresponds to the locations of the } brace.
Something like:
: cln_lcl r> lp + ;
: test
>l >l ' cln_lcl >r 2 >r @local0 @local1 @local0 @local1 ;
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-15 03:57 -0500 |
| Message-ID | <yaqdnbUix53lHOnOnZ2dnUVZ_s2dnZ2d@supernews.com> |
| In reply to | #30368 |
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] >>>>I don't know anything about these tools (or why anyone would want a >>>>primitive generator) but there is at least a clue here that something >>>>might be wrong. >>> >>> Ignorance is strength? You can read about it in a number of papers, >>> including the first one on Gforth from 20 years ago [ertl93]. As to >>> what might be wrong: It's a relatively complex part of a relatively >>> complex system, and it works, so it is not that attractive for >>> tinkering. You might say that the complexity is wrong; >> >>This looks like a consequence of the desire to have a portable >>implementation based on standard tools, e.g. GCC. Which was, I think >>my original point: that the decision to write Forth-in-not-Forth leads >>to additional complexity. > > It is not a consequence of using non-Forth tools, as demonstrated by a > number of Forth systems that use non-Forth tools and don't have a > primitive generator, such as JonesForth, PFE, ThisForth etc. Why not? I didn't say it was an inevitable consequence. > An analytic Forth compiler needs to know the stack effects of the > primitives, so we will reuse the primitive specifications for that, > so we still need the primitive generator for the native-code > compiler, even when that is written in Forth and generates machine > code directly. Why? Once you have the definitions of the primitives in a form that it needs, the analytic compiler can generate code for them. What does a "primitive generator" do in an analytic compiler? >>> in that case you are free to use any of the systems that value >>> simplicity over Gforth's goals, say colorForth. >> >>Indeed, but that's rather beside the point. > > Maybe it is beside your point, but my point is: Simplicity is not > the only relevant criterion. No, it's not, and you will see nowhere that I claimed it was. A system also has to be effective and pleasant to use. [I do not find GForth pleasant to use because I can't find anything when I look for it. That is partly due to its complexity and partly because I have a mental model of how a Forth system should work which GForth does not fit. Maybe that's just my problem, but I doubt it.] However, simplicity is one of the most important attributes of the Forth language and a Forth system. A Forth system which is not easy to understand and change loses much of what is precious; I have explained why I believe this, in this group. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-05-15 15:50 +0200 |
| Message-ID | <ll2gni$qlv$1@online.de> |
| In reply to | #30395 |
Andrew Haley wrote: > [I do not find GForth pleasant to use because I can't find anything > when I look for it. That is partly due to its complexity and partly > because I have a mental model of how a Forth system should work which > GForth does not fit. Maybe that's just my problem, but I doubt it.] That begs the question: how do you look for it, and what do you expect? Gforth doesn't have a "locate" or "view" yet (we probably should implement it), but it supplies tags for emacs and vi. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-15 10:07 -0500 |
| Message-ID | <3smdnTRH6tOtRenOnZ2dnUVZ_t6dnZ2d@supernews.com> |
| In reply to | #30396 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> [I do not find GForth pleasant to use because I can't find anything >> when I look for it. That is partly due to its complexity and partly >> because I have a mental model of how a Forth system should work which >> GForth does not fit. Maybe that's just my problem, but I doubt it.] > > That begs the question: how do you look for it, and what do you > expect? Gforth doesn't have a "locate" or "view" yet (we probably > should implement it), but it supplies tags for emacs and vi. I like to be able to browse. LOCATE is the first point of call, of course. I'd expect that to get me the source code for any word in the dictionary. Like this: locate dup /home/aph/SwiftForth/src/kernel/core.f 357: ICODE DUP ( x -- x x ) 358: PUSH(EBX) \ copy x onto the stack 359: RET END-CODE 360: Straight away I know the source for DUP and which file it is in. Of course, I very much prefer not having to leave the Forth development environment. In the case of Forth in not-Forth, I'd expect to see some not-Forth here. Some things I expect to be harder: for example, a metacompiler doesn't leave much trace, so I'd have to go looking for it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-16 16:33 +0000 |
| Message-ID | <2014May16.183349@mips.complang.tuwien.ac.at> |
| In reply to | #30395 |
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]
>>>>>I don't know anything about these tools (or why anyone would want a
>>>>>primitive generator) but there is at least a clue here that something
>>>>>might be wrong.
>>>>
>>>> Ignorance is strength? You can read about it in a number of papers,
>>>> including the first one on Gforth from 20 years ago [ertl93]. As to
>>>> what might be wrong: It's a relatively complex part of a relatively
>>>> complex system, and it works, so it is not that attractive for
>>>> tinkering. You might say that the complexity is wrong;
>>>
>>>This looks like a consequence of the desire to have a portable
>>>implementation based on standard tools, e.g. GCC. Which was, I think
>>>my original point: that the decision to write Forth-in-not-Forth leads
>>>to additional complexity.
>>
>> It is not a consequence of using non-Forth tools, as demonstrated by a
>> number of Forth systems that use non-Forth tools and don't have a
>> primitive generator, such as JonesForth, PFE, ThisForth etc.
>
>Why not? I didn't say it was an inevitable consequence.
What kind of consequence do you mean then? One system (Gforth) has
such a generator, both when it works with non-Forth tools (Gforth for
big machines) and when it does the classical Forth-via-Forth assembler
(Gforth EC); in the latter case it is actually the
primitive-replacement generator. Others that use either approach
don't. I call it a design decision.
>> An analytic Forth compiler needs to know the stack effects of the
>> primitives, so we will reuse the primitive specifications for that,
>> so we still need the primitive generator for the native-code
>> compiler, even when that is written in Forth and generates machine
>> code directly.
>
>Why? Once you have the definitions of the primitives in a form that
>it needs, the analytic compiler can generate code for them. What does
>a "primitive generator" do in an analytic compiler?
It provided the definitions of the primitives in the form that it
needs.
>> Maybe it is beside your point, but my point is: Simplicity is not
>> the only relevant criterion.
>
>No, it's not, and you will see nowhere that I claimed it was. A
>system also has to be effective and pleasant to use.
>
>[I do not find GForth pleasant to use because I can't find anything
>when I look for it. That is partly due to its complexity and partly
>because I have a mental model of how a Forth system should work which
>GForth does not fit. Maybe that's just my problem, but I doubt it.]
Probably. There is always the habit factor. And the little things
are the worst ones, such as when a Forth system does not exit when I
press ^D on an empty line (SwiftForth passes that test nicely), or
that takes itself so seriously that it writes many lines of
announcements when starting, or worse, erases the terminal (SwiftForth
is a positive example in that respect too).
So I gather you are missing LOCATE and VIEW. Adding them adds
complexity. So, IYO, should we add them to Gforth? Why, or why not?
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-17 08:04 -0500 |
| Message-ID | <XM2dnY8S6fTrw-rOnZ2dnUVZ_tGdnZ2d@supernews.com> |
| In reply to | #30427 |
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] >>>>>>I don't know anything about these tools (or why anyone would want a >>>>>>primitive generator) but there is at least a clue here that something >>>>>>might be wrong. >>>>> >>>>> Ignorance is strength? You can read about it in a number of papers, >>>>> including the first one on Gforth from 20 years ago [ertl93]. As to >>>>> what might be wrong: It's a relatively complex part of a relatively >>>>> complex system, and it works, so it is not that attractive for >>>>> tinkering. You might say that the complexity is wrong; >>>> >>>>This looks like a consequence of the desire to have a portable >>>>implementation based on standard tools, e.g. GCC. Which was, I think >>>>my original point: that the decision to write Forth-in-not-Forth leads >>>>to additional complexity. >>> >>> It is not a consequence of using non-Forth tools, as demonstrated by a >>> number of Forth systems that use non-Forth tools and don't have a >>> primitive generator, such as JonesForth, PFE, ThisForth etc. >> >>Why not? I didn't say it was an inevitable consequence. > > What kind of consequence do you mean then? Looking at your paper, it seems that to get good performace from Forth in C, you need a lot of primitives, so you need a primitive generator. Of course, it's all more complicated than that, and I apologise if I've misread what you wrote. > One system (Gforth) has such a generator, both when it works with > non-Forth tools (Gforth for big machines) and when it does the > classical Forth-via-Forth assembler (Gforth EC); in the latter case > it is actually the primitive-replacement generator. Others that use > either approach don't. I call it a design decision. It's certainly that. >>> An analytic Forth compiler needs to know the stack effects of the >>> primitives, so we will reuse the primitive specifications for that, >>> so we still need the primitive generator for the native-code >>> compiler, even when that is written in Forth and generates machine >>> code directly. >> >>Why? Once you have the definitions of the primitives in a form that >>it needs, the analytic compiler can generate code for them. What does >>a "primitive generator" do in an analytic compiler? > > It provided the definitions of the primitives in the form that it > needs. OK, so these are the patterns that are used in a compiler to convert the source language into its IR. Fair enough. >>> Maybe it is beside your point, but my point is: Simplicity is not >>> the only relevant criterion. >> >>No, it's not, and you will see nowhere that I claimed it was. A >>system also has to be effective and pleasant to use. >> >>[I do not find GForth pleasant to use because I can't find anything >>when I look for it. That is partly due to its complexity and partly >>because I have a mental model of how a Forth system should work which >>GForth does not fit. Maybe that's just my problem, but I doubt it.] > > Probably. There is always the habit factor. Definitely so, yes. I have used many Forth systems, and GForth was the first I have used (or, truthfully, played with for a short while) that I couldn't make any sense of. I would have ported transactional memory to GForth, but IIRC someone told me that GForth doesn't support concurrency anyway. > And the little things are the worst ones, such as when a Forth > system does not exit when I press ^D on an empty line (SwiftForth > passes that test nicely), or that takes itself so seriously that it > writes many lines of announcements when starting, or worse, erases > the terminal (SwiftForth is a positive example in that respect too). > > So I gather you are missing LOCATE and VIEW. Adding them adds > complexity. So, IYO, should we add them to Gforth? Why, or why > not? Transparency is always good, and these very simple tools would make the system more transparent. (It is possible that adding LOCATE to Gforth would not be simple; I don't know.) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-05-17 19:03 +0200 |
| Message-ID | <ll84pp$2fp$1@online.de> |
| In reply to | #30436 |
Andrew Haley wrote:
> Definitely so, yes. I have used many Forth systems, and GForth was
> the first I have used (or, truthfully, played with for a short while)
> that I couldn't make any sense of. I would have ported transactional
> memory to GForth, but IIRC someone told me that GForth doesn't support
> concurrency anyway.
It probably didn't back then; the git head version supports pthreads, and we
have atomic versions of memory exchange, increment+exchange and conditional
exchange.
> Transparency is always good, and these very simple tools would make
> the system more transparent. (It is possible that adding LOCATE to
> Gforth would not be simple; I don't know.)
Actually, it's dead easy. Just have your emacs open with a server started
and forth mode loaded, and call
sh emacsclient -e '(forth-find-tag "wordname")'
I'll add that in a minute (for git head Gforth):
\ view/locate
require string.fs
: view ( "name" -- )
[: ." emacsclient -e '(forth-find-tag " '"' emit
parse-name type '"' emit ." )'" ;] $tmp system ;
That at least fits my workflow with emacs open and Forth in the terminal.
Current git head also has an alias LOCATE for VIEW.
If someone knows how to remote control info mode - (Info-topic "foo") works
only in interactive mode, not with emacsclient - I could add a HELP function
that way, too.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-18 04:06 -0500 |
| Message-ID | <z7-dnedB_5Vj6uXOnZ2dnUVZ_rWdnZ2d@supernews.com> |
| In reply to | #30440 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> Definitely so, yes. I have used many Forth systems, and GForth was >> the first I have used (or, truthfully, played with for a short while) >> that I couldn't make any sense of. I would have ported transactional >> memory to GForth, but IIRC someone told me that GForth doesn't support >> concurrency anyway. > > It probably didn't back then; the git head version supports > pthreads, and we have atomic versions of memory exchange, > increment+exchange and conditional exchange. OK, so I can try transactional memory on GForth. It doesn't have much in the way of dependencies so it should be fine. >> Transparency is always good, and these very simple tools would make >> the system more transparent. (It is possible that adding LOCATE to >> Gforth would not be simple; I don't know.) > > Actually, it's dead easy. Just have your emacs open with a server started > and forth mode loaded, and call > > sh emacsclient -e '(forth-find-tag "wordname")' > > I'll add that in a minute (for git head Gforth): > > \ view/locate > > require string.fs > > : view ( "name" -- ) > [: ." emacsclient -e '(forth-find-tag " '"' emit > parse-name type '"' emit ." )'" ;] $tmp system ; Is that going to work with wordlists, etc? I don't know how forth-find-tag works. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-05-19 01:38 +0200 |
| Message-ID | <llbgaa$srg$1@online.de> |
| In reply to | #30446 |
Andrew Haley wrote: > OK, so I can try transactional memory on GForth. It doesn't have much > in the way of dependencies so it should be fine. Yes, go ahead. If you need some assembler, the ABI-CODE words are the right way (they call code with the usual calling convention of the platform, so you don't have to know which register is your stack - that's non-portable). >> : view ( "name" -- ) >> [: ." emacsclient -e '(forth-find-tag " '"' emit >> parse-name type '"' emit ." )'" ;] $tmp system ; > > Is that going to work with wordlists, etc? I don't know how > forth-find-tag works. It uses etags, so there is only one flat list. So it will not work if different vocabularies have the same word inside. Also, if you want to add your own code to the TAGS file, you have to compile it with gforth etags.fs <your files> This will produce a TAGS file, which you combine with the system's TAGS file (you or we probably want to automate this, so a shell script like this would help): -----------gforth-tag------------ #!/bin/bash gforth etags $* -e bye cat /usr/local/share/$(gforth --version 2>&1 | tr ' ' '/')/TAGS >>TAGS -----------gforth-tag------------ However, I think that a header change for view is not too complicated: the view field would go first; it would contain the number of the file (in the loadfilenames array), the line and the cursor position. VIEW still would use emacsclient, but with +<line>:<cpos> <file> instead. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-20 13:38 +0000 |
| Message-ID | <2014May20.153845@mips.complang.tuwien.ac.at> |
| In reply to | #30455 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Andrew Haley wrote:
[Bernd Paysan:]
>>> : view ( "name" -- )
>>> [: ." emacsclient -e '(forth-find-tag " '"' emit
>>> parse-name type '"' emit ." )'" ;] $tmp system ;
>>
>> Is that going to work with wordlists, etc? I don't know how
>> forth-find-tag works.
>
>It uses etags, so there is only one flat list. So it will not work if
>different vocabularies have the same word inside.
It will work, in a way: After finding the first occurence of a
definition in the way above, you can do C-u M-. to get the next one.
Repeat until you are at the right one (it does not work if the
definition lines are identical, though).
In a way a very Forthy solution: a short program that gives you 90% of
what you want. And if you adjust your way of working appropriately,
it gives you 100% of what you need:-).
>Also, if you want to add
>your own code to the TAGS file, you have to compile it with
>
>gforth etags.fs <your files>
>
>This will produce a TAGS file, which you combine with the system's TAGS file
>(you or we probably want to automate this, so a shell script like this would
>help):
Or you can just tell emacs to use several tags tables. E.g., you can
put something like this at the start of the file:
\ Local Variables:
\ tags-table-list: ("." "/usr/share/gforth/0.7.0/")
\ End:
>However, I think that a header change for view is not too complicated: the
>view field would go first; it would contain the number of the file (in the
>loadfilenames array), the line and the cursor position. VIEW still would
>use emacsclient, but with +<line>:<cpos> <file> instead.
More generally, it should use $EDITOR (at least on Unix, not sure what
is appropriate on Windows); decent editors understand the +line syntax
(vi on my box does not understand +line:col, though).
For LOCATE, how do we know what to display? Everything up to the next
definition? Everything up to an empty line? Also show preceding
lines until a non-empty line is found (some people put comments before
definitions)?
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-05-20 21:39 +0200 |
| Message-ID | <llgb16$30k$1@online.de> |
| In reply to | #30477 |
Anton Ertl wrote:
> Or you can just tell emacs to use several tags tables. E.g., you can
> put something like this at the start of the file:
>
> \ Local Variables:
> \ tags-table-list: ("." "/usr/share/gforth/0.7.0/")
> \ End:
That doesn't work, it only specifies where to log for TAGS.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-21 15:49 +0000 |
| Message-ID | <2014May21.174914@mips.complang.tuwien.ac.at> |
| In reply to | #30492 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Or you can just tell emacs to use several tags tables. E.g., you can
>> put something like this at the start of the file:
>>
>> \ Local Variables:
>> \ tags-table-list: ("." "/usr/share/gforth/0.7.0/")
>> \ End:
>
>That doesn't work, it only specifies where to log for TAGS.
I played around a bit with this, with the following example:
---------------
create foo
wordlist constant wl
wl set-current
5 constant foo
----------------
Adding the "Local Variables:" stuff does not work as intended, because
it specifies the variable as buffer-local, which has some effect, but
not the intended one.
Telling Emacs explicitly to visit the tags table TAGS and also
/usr/share/gforth/0.7.0 is more, but not totally successful: I can
M-. for FOO, WL, and WORDLIST, but the first attempt at CREATE failed;
the second attempt worked. Strange.
Doing
(setq tags-table-list '("." "/usr/share/gforth/0.7.0/"))
gives pretty much the same results as visiting the tags tables
explicitly.
Makes me wonder how to use a certain tags-table-list in a set of
files/buffers, and others in other files/buffers.
All tested with Emacs 23.3.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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-05-17 20:30 -0400 |
| Message-ID | <op.xf040vgo6zenlw@localhost> |
| In reply to | #30436 |
On Sat, 17 May 2014 09:04:54 -0400, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:
> Looking at your paper, it seems that to get good [performance]
> from Forth in C, you need a lot of primitives, so you need a
> primitive generator.
I think it's true of Forth in general that you need a lot of
primitives to get good performance.
I haven't been following this thread, so this reply may be
"out in left field" a bit ...
In Forths that use "primitives" (low-level) words, the primitives do
the work. The high-level Forth words are just nesting overhead which
eventually call the primitives to do some work.
A high-level colon definition can call other high-level definitions
or low-level "primitives".
( >R R> DUP SWAP are primitives )
In C, that'd be something like:
void over(void)
{
to_r();
dup();
r_from();
swap();
}
void tuck(void)
{
swap();
over();
}
As you can see, the high-level definitions for TUCK and
OVER don't do any work. They just call other high-level
words in Forth or other procedures in C. This is unneeded
overhead. to_r() dup() r_from() swap() do the low-level
work. (Not shown.) These do the appropriate data and
return stack manipulations in C or assembly.
So, for Forth to be efficient, all high-level words,
TUCK and OVER in this example, need to be re-coded or
compiled as low-level words or "primitives" in C or
assembly. This is true of a Forth with it's base code
in C or assembly.
So, instead of calling other functions, over() and tuck()
in C would contain inlined C functions, or the direct stack
operations coded in C similar to what's used to implement
to_r() dup() r_from() swap() etc, or inlined assembly.
In Forth, you'd start by expanding TUCK by replacing OVER
the only non-primitive in the definition:
: TUCK SWAP OVER ;
: TUCK SWAP >R DUP R> SWAP ;
At which point, since this was a simple definition, with
minimal nesting, we're done. TUCK is now written in terms
of primitives. The only other step that can be taken is
to code TUCK directly in assembly or C.
If this was a more complicated high-level word, you'd
keep unrolling until you're complete, then rewrite in C
or assembly, as appropriate.
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-17 17:59 -0700 |
| Message-ID | <7x8upz3ns3.fsf@ruckus.brouhaha.com> |
| In reply to | #30442 |
"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes: > So, for Forth to be efficient, all high-level words, TUCK and OVER in > this example, need to be re-coded or compiled as low-level words or > "primitives" in C or assembly. This is true of a Forth with it's base > code in C or assembly. The idea of an "analytic" compiler (a term I've heard only in connection with Forth) is that the compiler would abstractly figure out the dataflow and simplify it before generating code. So for example "SWAP SWAP SWAP SWAP" would compile into no code at all and typical Forth "stackrobatic" code when the top few stack elements were in registers would be eliminated by the compiler, which would instead just track what values were in which registers. http://en.wikipedia.org/wiki/Static_single_assignment_form discusses how compilers of recent vintage do this type of thing.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-05-18 04:08 -0500 |
| Message-ID | <z7-dneZB_5U_5eXOnZ2dnUVZ_rWdnZ2d@supernews.com> |
| In reply to | #30442 |
Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> On Sat, 17 May 2014 09:04:54 -0400, Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:
>
>> Looking at your paper, it seems that to get good [performance]
>> from Forth in C, you need a lot of primitives, so you need a
>> primitive generator.
>
> I think it's true of Forth in general that you need a lot of
> primitives to get good performance.
>
> I haven't been following this thread, so this reply may be
> "out in left field" a bit ...
>
> In Forths that use "primitives" (low-level) words, the primitives do
> the work. The high-level Forth words are just nesting overhead which
> eventually call the primitives to do some work.
>
> A high-level colon definition can call other high-level definitions
> or low-level "primitives".
>
> ( >R R> DUP SWAP are primitives )
>
>
> In C, that'd be something like:
>
> void over(void)
> {
> to_r();
> dup();
> r_from();
> swap();
> }
But what maniac would write such a thing? Maybe for some sort of
ultra- minimalist theoretical Forth, but otherwise I really don't
think so.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-18 11:07 +0000 |
| Message-ID | <2014May18.130701@mips.complang.tuwien.ac.at> |
| In reply to | #30447 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> void over(void)
>> {
>> to_r();
>> dup();
>> r_from();
>> swap();
>> }
>
>But what maniac would write such a thing? Maybe for some sort of
>ultra- minimalist theoretical Forth, but otherwise I really don't
>think so.
The Gforth prim file contains many primitive replacements, so that you
have to implement just a few primitives when you port to a new machine
with the Forth-in-Forth-assembler method. IIRC 10 or so are
sufficient. When you have these 10 working, you can add more, the
replacements will no longer be used, and the system is faster. And
the nice thing is: when you add a new primitive, and the system stops
working, you have a good idea where the bug is. That being said, the
definition of OVER in prim is:
over ( w1 w2 -- w1 w2 w1 ) core
:
sp@ cell+ @ ;
i.e., the primitive replacement looks as follows:
: over ( w1 w2 -- w1 w2 w1 )
sp@ cell+ @ ;
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-05-18 11:15 +0000 |
| Message-ID | <2014May18.131531@mips.complang.tuwien.ac.at> |
| In reply to | #30436 |
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:
>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> [Andrew Haley]
>>>>>>>I don't know anything about these tools (or why anyone would want a
>>>>>>>primitive generator) but there is at least a clue here that something
>>>>>>>might be wrong.
>>>>>>
>>>>>> Ignorance is strength? You can read about it in a number of papers,
>>>>>> including the first one on Gforth from 20 years ago [ertl93]. As to
>>>>>> what might be wrong: It's a relatively complex part of a relatively
>>>>>> complex system, and it works, so it is not that attractive for
>>>>>> tinkering. You might say that the complexity is wrong;
>>>>>
>>>>>This looks like a consequence of the desire to have a portable
>>>>>implementation based on standard tools, e.g. GCC. Which was, I think
>>>>>my original point: that the decision to write Forth-in-not-Forth leads
>>>>>to additional complexity.
>>>>
>>>> It is not a consequence of using non-Forth tools, as demonstrated by a
>>>> number of Forth systems that use non-Forth tools and don't have a
>>>> primitive generator, such as JonesForth, PFE, ThisForth etc.
>>>
>>>Why not? I didn't say it was an inevitable consequence.
>>
>> What kind of consequence do you mean then?
>
>Looking at your paper, it seems that to get good performace from Forth
>in C, you need a lot of primitives, so you need a primitive generator.
It's more like: To get good performance from a threaded-code
implementation, you implement many words as primitives. Since we
implement every primitive only once (instead of once per
architecture), we can afford that; ok, you might say that that's a
consequence of using C, but it's not a direct consequence; moreover, a
single-architecture Forth-in-Forth-assembler implementation could
affort that, too.
And the more primitives you implement, the more you benefit from a
primitive generator. I don't know if the generator saved any work in
the original Gforth, but it certainly was more interesting than
hand-coding (and debugging) all the stack access code directly.
Later, the fact that we already had the stack effect explicit in the
primitives (instead of as C code) helped when I added static
superinstructions and static stack caching.
There was a bit of that already at the start, as we could compile
Gforth without and with keeping the TOS in a register, to cater for
machines with more or fewer registers (although, as it turns out,
keeping the TOS in a register does not increase register pressure, but
I did not know that until much later). This was achieved on the C
level through C macros instead of at the primitive generator level,
but IIRC I only noticed that this is possible after work had already
started; and I don't think I would have realized that this is possible
if I had coded directly in C. E.g., PFE does not do this (but that
may also be due to the threading method used in PFE).
For a comparison, here are + and DUP in PFE and in gforth:
Code (dupe) dup ( w -- w w ) core dupe
{ :
--sp; sp@ @ ;
sp[0] = sp[1];
}
Code (plus) + ( n1 n2 -- n ) core plus
{ n = n1+n2;
sp[1] += sp[0];
sp++;
}
LISTWORDS (core) =
{
...
CO ("+", plus),
...
CO ("DUP", dupe),
...
}
>> So I gather you are missing LOCATE and VIEW. Adding them adds
>> complexity. So, IYO, should we add them to Gforth? Why, or why
>> not?
>
>Transparency is always good, and these very simple tools would make
>the system more transparent. (It is possible that adding LOCATE to
>Gforth would not be simple; I don't know.)
Not that hard, but the traditional way (rather than Bernds
LOCATE-on-top-of-etags way) requires a header change, and that's
harder than one would wish for, because it requires changes in both
the cross-compiler and the compiler, and such changes often cause
problems in bootstrapping, and we write [ifdef]s and such to work
around that. Note that both the cross-compiler and the compiler are
written in Forth.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web