Steve, FORTH uses the data stack in a manner that is indeed analogous to allocation from a heap. Actually, FORTH was designed to work on machines that don't necessarily even have an OS, let alone a heap.
A typical programming pattern in FORTH is to temporarily store data on the return stack, e.g., loop counters, and to restore the data to the data stack (and remove it from the return stack) before exiting a routine. I have often wondered whether it would be better to have TWO data stacks and a return stack in FORTH. Bruce, Yes, my reading of the implementation book is that data and return information are stored on a common stack, in the manner of C, Pascal, etc.. I don't know about any efforts to separate the two for Icon, but I'm not in the implementation loop for Icon or Unicon. I do NOT favor separating co-expressions into separate processes or threads in the VM!! Perhaps a thread or pseudothread model could be ADDED to the language/VM if need be, but there are certain algorithms (program execution monitoring, aspect-oriented progeramming, co-routine programming, etc.) that would work best with co-expressions just as they are. I (as a dilettante) have wondered whether making the VM thread-safe would warrant the implementation effort and what it would take to do so. I am not of the opinion that there is much benefit to it, but opinions may differ. -----Original Message----- From: Steve Wampler [mailto:[EMAIL PROTECTED] Sent: Thursday, December 30, 2004 10:40 AM To: Bruce Rennie Cc: [email protected] Subject: Re: [Unicon-group] UnIcon/Icon Virtual Machine - possible changes Bruce Rennie wrote: > Has there been any attempt to restructure the UnIcon/Icon virtual > machine so that there are separate data and processor(return) stacks? > The model that I'm comparing to is the FORTH virtual machine - data > stack and return stack. > .. > > What I am interested in is whether any research has been done into the > separation of the stack and what problems were found in doing so. It > seems to me that some of the difficulties in the VM implementation would > be alleviated by doing the separation, possibly allowing co-expressions > to become full fledged processes/threads within the VM - just a thought. > Hi Bruce, This is an intriguing idea, but not one I fully understand. Can you give a simple example of what is meant by separating the data and return stacks? I'm guessing that this means keeping the control flow information (return points, generator resumption information, etc.) on a stack and allocating parameter/local variable storage blocks in the heap. Is that at all close? I'm not sure I see the advantage of using two separate stacks instead of a stack + heap storage blocks. Thanks! Steve (others: is this the type of discussion that should be moved to the 'other' Unicon mailing list?) -- -- Steve Wampler [EMAIL PROTECTED] The gods that smiled upon your birth are laughing now. -- fortune cookie ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Unicon-group mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/unicon-group ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Unicon-group mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/unicon-group
