Re: using MISC (post 1987 Forth hardware) opcodes
- From: Adam Warner <usenet@xxxxxxxxxxxxxxxxx>
- Date: Sun, 16 Jul 2006 16:56:27 +1200
On Sat, 15 Jul 2006 16:36:57 +0000, Marc Olschok wrote:
Here's an example I came up with within the
limitations of my Forth knowledge: Write recursive and tail recursive
words to naively sum the integers from 1 to the first element on the stack.
Perhaps this is just not a good enough example to support your claim.
Or it may depend on the particular Forth dialect used.
In Retroforth I found
: trsum ( s n -- s' ) 0; tuck + swap 1- trsum ;
quite intuitive.
Instead of "recurse" it uses the definitions name, which I find more
readable anyway.
The other nice feature is 0; :
it leaves the current definition if the
if the TOS is 0 it consumes the TOS and leaves the current word,
if the TOS is nonzero then nothing is done (in particular the TOS
is not consumed). Hence you do not need IF...THEN constructs and
the cleanup afterward.
Thanks for the nice example!
[...]
If your Forth does not have decent sized stacks then you cannot
effectively run recursive definitions, you cannot prototype using
recursive definitions and you will be inhibited from even thinking
recursively. You'll be forced into premature optimisation, writing harder
code for a less expressive Forth.
I have never experienced such a problem.
We agree I did not provide a good enough example to support my claim. This
one should be bulletproof: You have a reason to trace though a deep
tree-like data structure. Mechanically this involves pushing paths you
still need to travel onto a stack every time you branch within the tree.
Recursion makes this mechanical process invisible.
Here's part of the data structure. I'll describe tracing through the right
size of the solid region:
a
/ \
b c
. / \
. d e
. . . / \
. . f g
. . / \
. h i
. / \
. j k
. / \
. l m
. / \
. n o
. / \
. p q
. .
. .
. . .
. . .
1. Push (b) and process (c).
2. Push (d) and process (e).
3. Push (f) and process (g).
4. Push (h) and process (i).
5. Push (j) and process (k).
6. Push (l) and process (m).
7. Push (n) and process (o).
8. Push (p) and process (q). Return.
9. Pop (p) and process. Return.
10. Pop (n) and process. Return.
11. Pop (l) and process. Return.
12. Pop (j) and process. Return.
13. Pop (h) and process. Return.
14. Pop (f) and process. Return.
15. Pop (d) and process. Return.
16. Pop (b) and process. Return.
An environment with six cell stacks cannot traverse this data structure
(without implementing userspace stacks out of heap memory). The stack is
blown around point 7 (earlier if there is already data on the return stack).
A six cell environmental dependency is simply too low for general purpose
programming tasks. Whoever is willing to concede this (by highlighting a
specialised embedded environment) should beware of claiming that such a
restricted environment is also easier to program.
Regards,
Adam
.
- Follow-Ups:
- Re: using MISC (post 1987 Forth hardware) opcodes
- From: John Doty
- Re: using MISC (post 1987 Forth hardware) opcodes
- From: jmdrake_98
- Re: using MISC (post 1987 Forth hardware) opcodes
- References:
- using MISC (post 1987 Forth hardware) opcodes
- From: Jeff Fox
- Re: using MISC (post 1987 Forth hardware) opcodes
- From: Bernd Paysan
- Re: using MISC (post 1987 Forth hardware) opcodes
- From: Jeff Fox
- Re: using MISC (post 1987 Forth hardware) opcodes
- From: Adam Warner
- Re: using MISC (post 1987 Forth hardware) opcodes
- From: Jeff Fox
- Re: using MISC (post 1987 Forth hardware) opcodes
- From: Adam Warner
- Re: using MISC (post 1987 Forth hardware) opcodes
- From: Marc Olschok
- using MISC (post 1987 Forth hardware) opcodes
- Prev by Date: Re: using MISC (post 1987 Forth hardware) opcodes
- Next by Date: Re: Bytecode
- Previous by thread: Re: using MISC (post 1987 Forth hardware) opcodes
- Next by thread: Re: using MISC (post 1987 Forth hardware) opcodes
- Index(es):
Relevant Pages
|