Re: I want to learn forth but...
- From: rickman <gnuarm@xxxxxxxxx>
- Date: Wed, 11 Mar 2009 21:18:43 -0700 (PDT)
On Mar 11, 11:19 pm, pml540...@xxxxxxxxx wrote:
rickman wrote:
On Feb 14, 4:04 am, pml540...@xxxxxxxxx wrote:
rickman wrote:
.
.
.
The method you outlined ignores what happens as the
words in the loop are executed. Your original description of
executing a word copies new instructions on the top of the stack. So
either this new code copied to the stack can clobber the instructions
within the loop that have been executed, or they must be put on the
very top of the stack. If the former the loop code must be read each
time the loop is executed. If the latter, the stack must have all the
same features as random access memory and the end of each word must
have a return instruction
And there's the faulty assumption. It need not have the same features,
and the work of the return isn't there. In fact, it would be better
not even to have a marker but a copy length associated with the loop
instruction, in case of nesting.
I don't need to know how it is constructed to know how it has to
operate. Here is an example...
: word3 word3a word3b word3c ;
: word1 word2 BEGIN word3 word4 UNTIL ;
Stack -- word1
Stack -- UNTIL word4 word3 BEGIN word2
execute word2, right?
Stack -- UNTIL word4 word3 BEGIN
execute word3... where does the definition of word3 go???
Stack -- UNTIL word4 word3 BEGIN word3c word3b word3a
-- or --
Stack -- UNTIL word4 word3c word3b word3a
If word3 is executed same way as word1 and word2 the loop has been
clobbered and so must be reloaded each time around. If word3 is
executed the other way, then when word3c is executed there either
needs to be some sort of return instruction to tell the processor
where to fetch the next instruction, or it will execute the loop over
again.
What am I missing about this?
And that example has made a faulty assumption. Basically that is not
following the overview I gave. It actually goes more like this:-
loop 5 w1 w2 w3 w4 w5 w6 w7 ... ( this says, loop the next 5 words
until a condition is met )
w1 w2 w3 w4 w5 loop 5 w1 w2 w3 w4 w5 w6 w7 ...
w1a w1b w2 w3 w4 w5 loop 5 w1 w2 w3 w4 w5 w6 w7 ...
and so on, until the loop is about to break, when it goes:-
loop 5 w1 w2 w3 w4 w5 w6 w7 ...
w6 w7 ...
So what is special about this? It doesn't really matter what the
control structure is. What is important is that the instructions are
not being fetched from a stack. A stack only has two operations, push
and pop. If the program has to pop 5 instructions and then go back
and pop them again, there is an extra operation that is a *random*
access. This is not possible with a stack. Random accesses are only
possible with RAM, hence the name Random Access Memory.
If I understand the point of using a stack for instructions, it is
that a *stack* can be made much more efficiently and run faster than a
RAM. But when you add other addressing modes to a stack, it no longer
has those advantages, it has to be implemented differently. If you
know of another form of memory that has advantages in an application
like this, then you need to explain the details.
That's true in general, but not in special cases. I wasn't
recommending it but bringing it out as food for thought. I have
actually seen this model used as the calling method for the batch
language of an operating system, where the overheads were not very
important and it was a cheap way to get flexibility. PML.
Perhaps, but what exactly was the advantage?
I looked into what was happening there, and it turned out that it
avoided needing an open ended amount of open file handles
corresponding to each "subroutine" file being called. There was an
anonymous file that served as an execution stack, and whenever a
"call" was made - even the initial use of a batch file - a single file
was temporarily opened and copied, then closed before further actions
were taken. I even used the trick myself once, in an application
written in a Basic variant that didn't give me enough flexibility for
the kind of calls I needed but did let me modify a string of
characters representing pending tokens conveniently. PML.
What you have described was just a file cache. Multiple files were
stored in a single file to limit the number of file handles needed.
That does not require any special code execution mechanism. That is a
completely unrelated problem and solution. In fact, I don't see how
this could be a "stack". Items are added and removed from a stack.
The subroutines had to be copied to the cache file and not removed.
No, they were removed - incrementally, as each batch command was
obeyed. And Multiple files were not stored there, only lines prepended
from multiple files, with no distinction between lines from different
files. The prepending and consuming was a stack style use.
They could have easily been executed in the standard way from that
cache file.
No, because then you would have needed all the machinery for handling
them as distinct chunks of commands, with labels and return markers
and so on. PML.
I still don't know what you are talking about. You mention stacks and
then talk about looping and other operations that stacks don't
support. When a stack is implemented in RAM, you can use any number
of operations on that stack because it is really a RAM with random
access methods. The stack is just "emulated". Because it is really a
RAM, it has no advantages over just using a RAM with an instruction
pointer.
If I am missing something basic here, we need to start over. Please
don't ask me to read Henry Baker's paper again. I read that I I feel
I understand it. If you want to correct some misunderstanding on my
part, you need to explain it to me, *all* of it. I read your posts
and get disconnected pieces that don't connect in a whole solution.
Is there a way to get this to make sense to me? Or are we at
loggerheads?
Rick
.
- References:
- Re: I want to learn forth but...
- From: pml540114
- Re: I want to learn forth but...
- Prev by Date: Re: I want to learn forth but...
- Next by Date: Re: Reference Point for Code Size
- Previous by thread: Re: I want to learn forth but...
- Next by thread: Re: I want to learn forth but...
- Index(es):
Relevant Pages
|
