tor
lda tos
pha
lda tos+1
pha
jmp pops ; nothing gained here
rfrom
pla
tay
pla
jmp pushya ; four bytes smaller, only [13] clocks
Things that wind up on the return stack because of BRK, JSR, and interrupts would still be in their natural little-endian order, but it is possible/necessary for the programmer to know what's going on in those cases.
Forth requires separate data and return stack, for other interpreted language, having everything on the hardware stack would make sense, as soon as you mostly work with the top-of-stack and rarely work with the inner items.
To be honnest, if you need a stack of 16-bit items and separate data/return stacks, then I'd use the hardware stack as a return stack, and either split-stack or zero page for data stack. If ~64 items is enough, then by all mean use ZP and don't split so that you can use (ZP,X) for addressing memory, and if you need between 64 and 256 items depth, then split stack is perfect (you'll have to copy to ZP temporaries for a couple of instructions).
I am just starting to learn forth, but it would seem to me that using VRAIABLE too much isn't the philosophy of the language and should be normally avoided, just like global variables in more conventional languages. If VARIABLE is in the top 5 of the most used words, very likely it was the result of a conversion from another programing language.
As somebody who hasn't used the language all that much, I'm always curious how complex Forth code gets for heap-oriented programs and algorithms. Data lifetime is not necessarily tied to its creating function lifetime, and lots of code needs to reference contextual data that isn't necessarily passed in to it.
I know that in languages like the JVM (which has a stack-oriented bytecode), the data stack is used very intermediately. Values are stored to & retrieved from local variables often, instead of juggling them around the data stack. Pretty much just the current expression evaluation is kept on the stack. Of course, it's expected that the compiler will optimize this when translating to its register-based target, but it also does keep the stack based code clean and straightforward.
While there's a lot of compacting tricks you can do with processing immediate data in Forth via keeping it all on the stack, at some level of complexity you need to be able to handle longer lived data structures.
Just about every HLL in the world (except BASIC) uses a stack to temporarily store local variables and these variables are given up when the subroutine involved exits. Forth has a VARIABLE word for long term data storage.
If you want encapsulated data (which other words can't access) then here is a neat trick I use:
Right, in effect you have to invent your own memory management from scratch. So much that is seen about Forth is on manipulating the data stack, defining variables, or dictionary states that only work with LIFO alloc/dealloc semantics.
In writing complex editors or any form of analyzers that deal with modifying large graph structures (ie, interconnected data structures that might come and go (consider an optimizing whole-program compiler)), the data doesn't live on the stack, nor in individual variables, and their allocations/deallocations happen in any order as opposed to LIFO.
Obviously Chuck Moore has built all sorts of complex tooling on top of Forth. I wonder if he has his own alloc/dealloc heap manager, or if he works purely with preallocated object pools, or what. Because variables and the dictionary stack don't provide the direct means to do such things, and it's a tough problem to solve well.
If you want a heap manager then LOAD one in. If your Forth implementation doesn't have one then I posted some code for one a few months back. (viewtopic.php?p=36663#p36663). You don't need all the bells and whistles included in an application and taking up megabytes of space whether they are needed or not before the application can be considered useful.
I get that Forth is not everybody's cup of tea. Reading pre-written code can be especially daunting. However making a whole bunch of strawman arguments against Forth isn't doing you any good.
I'm not making strawman arguments, I'm legitimately asking how these things are done. I've done a decent amount of stack-based intermediate formats inside compilers, had some huge PostScript jobs in the past, etc, but I'm not really a Forth-head. I haven't heard of malloc-style heap managers mentioned around Forth before (though haven't really searched around either), so I didn't know if there were common libraries for things like this, or if people using Forth tend to back away from that and use more static allocation (pooling and such).
I haven't heard of malloc-style heap managers mentioned around Forth before (though haven't really searched around either), so I didn't know if there were common libraries for things like this, or if people using Forth tend to back away from that and use more static allocation (pooling and such).
It would have been better to post questions about memory management in Forth and deciding if you like the answers instead of making unresearched remarks as in your previous post.
I wrote a heap manager for Forth because I was curious about linked-lists and binary trees etc. (Mind you, I have also experimented with these structures in BASIC using parallel arrays). I could probably have found something on-line (maybe gforth has one) but I usually find it less hassley (and more satisfying) to write my own. That is the power of Forth.
It would have been better to post questions about memory management in Forth and deciding if you like the answers instead of making unresearched remarks as in your previous post.
Not to belabor the point, but that's what I did. Including saying what I've already seen that didn't cover the answer.
I get that Forth is not everybody's cup of tea. Reading pre-written code can be especially daunting. However making a whole bunch of strawman arguments against Forth isn't doing you any good.
I don't think White Flame was making a strawman argument—his questions are interesting. I've often wondered about how one would avoid "data volatility" (for lack of a better term) in Forth. I'm not a Forth user, but as a matter of course, I tend to be interested in how such environments work.
I don't think White Flame was making a strawman argument—his questions are interesting ...
Yeah, White Flame has a quirky sense of humor and a posting style that is a bit "dryer" than many others here, so his tone sometimes gets misinterpreted. I feel quite comfortable in assuming that he wasn't trying to offend. I'll refrain from giving examples of forum members who are genuinely offensive, because that's not my style, but White Flame definitely doesn't belong on that list (at least not on my personal list).
I will concur that my natural communication style is abnormally dry. I get that a lot IRL as well.
It generally comes from being overly introspective and dealing heavily with AI design and conceptual communication. But at the end of the day, I actually prefer being precise to the alternatives.
As somebody who hasn't used the language all that much, I'm always curious how complex Forth code gets for heap-oriented programs and algorithms.
Had I read that opening statement correctly the posts that followed would have been of a different nature so, my bad.
The short answer is, "no worse than with C" (aside from the usual caveats about Forth syntax).
You might have to write your own MALLOC and FREE words but K&R's Ansi C shows you how. As a matter of fact, there are a number of standard functions in that book that are worthy of being coded in Forth.
Hmmm. I co-wrote a paper on the subject of memory allocation many years ago for the Journal of Forth Application and Research, but upon checking I see that I never put it on-line. Some of that work made it into Section C of my 1989 Master's dissertation. (Now, where did I put that program listing?) It was nothing particularly sophisticated, but it does serve as an existence proof.
