Path: csiph.com!eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.lang.forth Subject: Re: How can " dup drop " be anything other than a nop Date: Fri, 02 Oct 2015 01:02:12 -0400 Organization: Aioe.org NNTP Server Lines: 47 Message-ID: References: <25ebdfea-1331-4e72-80a9-8655570855cb@googlegroups.com> NNTP-Posting-Host: n4wpt9zq8xR26Ttf9mo2BA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:42307 On Wed, 30 Sep 2015 22:20:42 -0400, Bob Armstrong wrote: > | ... weird issue w simply nested fns remains > > text> "lf tokcut rho | |>| 1432 | works > : tst "lf tokcut ; text> tst rho | works not > : tst "lf dup drop tokcut ; text> tst rho | works > : tst dup drop "lf tokcut ; text> tst rho | works not > > Without even knowing anything else , how can a " dup drop " have any effect ? Is it that "dup drop" is doing something or fixing something, or rather is it that _anything_ inbetween "lf and tokcut fixes the issue? ... I.e., my instinct would be that that there is something wrong with either "lf or your outer interpreter which is being reset by "dup drop" prior to tokcut. FYI, you seem to think DUP DROP is a NOP, which it effectively is, but the way it's implemented, it has two side effects which could be the sources of problems or fixes. 1) It puts a value on the stack, which is still present even though the stack pointer has been repointed, i.e., the value is still present above the top of stack location. E.g., it's possible something may be accessing the value there and then working. 2) It saves and restores EAX. Yes, that's a side effect. I.e., perhaps corruption of EAX occurs between "lf and tokcut without the DUP DROP sequence being present. Therefore, it works correctly. This could be an issue if you're mixing C (or some another high-level language) and assembly and haven't preserved the compilers in-use registers when switching between assembly and C. These in-use registers get "clobbered" or destroyed, unless your assembly preserves their contents. EAX is usually a register which is destroyed by high-level languages. Rod Pemberton -- Just how many texting and calendar apps does humanity need? Just how many food articles from neurotic millenials do we need?