Path: csiph.com!aioe.org!.POSTED!not-for-mail From: Rod Pemberton Newsgroups: comp.lang.forth Subject: Re: Stack Sizes Date: Fri, 7 Oct 2016 23:05:03 -0400 Organization: Aioe.org NNTP Server Lines: 49 Message-ID: <20161007230503.2b35c2d3@_> References: <87k2dkwuqs.fsf@nightsong.com> NNTP-Posting-Host: n4wpt9zq8xR26Ttf9mo2BA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 X-Newsreader: Claws Mail 3.13.1 (GTK+ 2.24.13; x86_64-unknown-linux-gnu) Xref: csiph.com comp.lang.forth:51687 On Fri, 7 Oct 2016 02:26:54 -0400 rickman wrote: > On 10/7/2016 2:14 AM, Paul Rubin wrote: > > rickman writes: > >> A register/stack hybrid by giving a limited range of access into > >> the stack for operands. > > > > This sounds like a register window architecture, e.g. SPARC. They > > were in vogue in workstation processors for a while, but then went > > out of favor, I think because of difficulties making them > > superscalar or something like that. For a small fpga softcore > > maybe that doesn't matter. > > Lol, no, I don't think not being "superscalar" matters to a MISC CPU. > Not familiar with register window, but that sounds a bit like it, but > put it on top of a stack. The idea is to do away with most of the > stack manipulations, OVER, DUP, etc. buy implementing them with small > offsets and stack pointer adjustments other than +1/0/-1. > > One of the issues in stack machines is dealing with more than a > couple or three stack items. I think a small offset into the stack > will make this work a lot better. > It would be useful if you could move the pointer from position at the top of the stack, while guaranteeing that items now above the new pointer location were not corrupted. E.g., if you wanted to swap the 3rd and 4th items, you could: 1) change data stack pointer to point to 3rd item 2) "protect" the items between new and old position, i.e., "guard" the 1st and 2nd items 3) SWAP, which would swap the 3rd and 4th items 4) restore data stack pointer 5) remove "guard" protecting 1st and 2nd items from being overwritten I noticed this type of situation come up both in Forth code and C code converted to Forth. This would make all data stack operations independent of the current stack position. I'm just not sure how to do it more effectively than moving items to the return stack. Guarding the data would be the hard part in software, I think, without needing to use to two block moves of data, which would slow this down. Swapping the stack pointer is quick and easy. Rod Pemberton