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

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

C-to-stack, and locals versus global stacks?

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

Contents

  C-to-stack, and locals versus global stacks? jacko <jackokring@gmail.com> - 2014-05-01 10:46 -0700
    Re: C-to-stack, and locals versus global stacks? Paul Rubin <no.email@nospam.invalid> - 2014-05-01 12:12 -0700
    Re: C-to-stack, and locals versus global stacks? Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-05-01 21:25 -0700

#30041 — C-to-stack, and locals versus global stacks?

Some context pulled from Epic Fail thread.

"However, to achieve this the virtual machine design has local variable support." - This in  an incorrect fact. 

"To achieve this the virtual machine design can have global vocabulary contexted named-stack definitions. In effect allowing nesting for local effect by stack name." 

That's in the part 
<http://www.complang.tuwien.ac.at/forth/faq/faq-general-5.html#ss5.1> 
"5.1 Where can I find a C-to-Forth compiler?", and it's about MPE's 
C-to-stack-machine compiler.  It would surprise me if you know better 
about this compiler than Stephen Pelc, but you can certainly discuss 
it with him here. 

<End of context>

The basic point I'm on about is the equivalence of named global stacks and locals. For non nested functions there is definitely little difference (except with threading), and for nested functions, the stack nature allows "stacking" older local values on the global named stacks.

For complex structures such as stacks, not only should recall and store top be defined, but also the full content load and store. EVAL, TO, STATE and RESTORE would perhaps but not necessarily be good words for these. Then the expression STATE <var> TO <var2> could do a context switch on a stack, perhaps even stacking the whole stack if var2 was a stack itself.

It's likely that EVAL would never be needed as a prefix, given automatic execution of words, but could be used postfix to evaluate code on top of the main stack. This is also like asserting that a single @ should be implicit, and it has to be if addressing is to be kept out of the picture. It could be that the total object is placed on the main stack, for later @ or ! but then overloading of operators and other matters, such as longer code, start to enter in to the picture.

I considered it best to just have a lower number of entities with higher functionality. Basically, a ring of numbers (a.k.a. a string) with a current character (or number), and a list of words or strings. The complex number type should be just an extension of numbers (or color phased characters) within a string. It would not surprise me to have just integer nodes, nest nodes, symbol nodes, and complex (or any square root) double nodes to start, with stack nodes, table nodes and vocabulary nodes added on.

[toc] | [next] | [standalone]

#30043

jacko <jackokring@gmail.com> writes:
> "However, to achieve this the virtual machine design has local
> variable support." - This in an incorrect fact.

As I remember, the code generated by that compiler (if it's the one I
remember) made extensive use of PICK or equivalent, to reach deeply into
the stack interior.  I figured that was what was meant by "locals".

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

#30053

What is a "named global stack" ?

[toc] | [prev] | [standalone]

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

csiph-web