Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Julian Fondren Newsgroups: comp.lang.forth Subject: Re: multi-threading in Forth? Date: Thu, 04 Aug 2011 13:54:21 -0500 Organization: A noiseless patient Spider Lines: 99 Message-ID: <86d3gl57oi.fsf@gmail.com> References: <07679799958436@frunobulax.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx04.eternal-september.org; posting-host="cO8zBIpB9LiP7q+vFZIJrA"; logging-data="10925"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19hsVbKfy4cGpOrajM8pyWdex7AnOFaiG0=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (windows-nt) Cancel-Lock: sha1:KgMs3ApoE2N6/iyVSlHaDHpGzxU= sha1:2MsVXMRaQSfR4+Li6fQcYExLl3A= Xref: x330-a1.tempe.blueboxinc.net comp.lang.forth:4589 Mark Wills writes: > On 04/08/2011 12:42, coos haak wrote: >> Op Thu, 04 Aug 2011 08:25:27 +0100 schreef Mark Wills: >> >>> On 04/08/2011 05:36, Marcel Hendrix wrote: >>>> To implement this non-standard code, please use this non-standard trick >>>> (as shown earlier) to prevent in-lining: >>>> >>>> : foo r> r> swap>r>r [ -opt ] ; >>>> : bar 11 . foo 111 . ; >>>> : baz 22 . bar 222 . ; >>>> >>>> FORTH> baz 22 11 222 111 ok >>>> >>>> -marcel >>>> >>> >>> What's non-standard about that code? >> >> The placement of return addresses on the return stack is not demanded by >> the current standard. E.g. FigForth and F83 placed them on the return >> stack, by tradition and simplicity. Currently an implementation may place >> them anywhere, even not on the return stack. >> So manipulation of items on the return stack by Foo is allowed, but there >> is no guarantee that you manipulate return addresses. >> >> I too have an implementation where the inlining in FOO (called CO here, >> courtesy of Albert) must be switched of. >> > > Do you have any idea just how ridiculous that sounds? :-/ I realise > you are just quoting the standard, but jeesh... "The placement of > return addresses on the return stack is not demanded by the current > standard"... FFS... Is it possible to produce a more left-leaning > woolly standard than the current one? I think not! There's no need to beat on ANS Forth; it correctly tells you that this technique will have portability issues. Just deal with them. It's not like a much-less-followed standard would be free of issues like this. If you search for "recognizing tail recursion" on Google Groups (still useful for Usenet, just not for following it), you'll find some interesting comments about this and the standard's position on it. So, just declare an environmental dependency on... whatever this is called, exactly, and use system optimizer hooks on those systems that are otherwise OK with the practice. You're now aware of the iForth hook; the SwiftForth hook is NO-TAIL-RECURSION , used like IMMEDIATE \ : call >r ; : concat ( c-addr1 u1 c-addr2 u2 -- c-addr3 u1+u2 ) third 2dup + dup >r allocate throw >r r@ + swap move r@ swap move r> r> ; : free-after ( a u -- a u ) over r> swap >r ['] call catch r> free throw throw ; \ Frees after the string is typed : x s" hi" s" there" concat free-after cr type ; \ Frees after the string is typed in Z : y s" hi" s" there" concat free-after ; : z y cr type ; If you want the X behavior but not the Z behavior in this instance, use NO-TAIL-RECURSION on FREE-AFTER and Y will reliably do the wrong thing of freeing the string before returning it. From another time that this has been discussed: http://groups.google.com/group/comp.lang.forth/msg/7e37f3b5f43cddf9 SP> The chances of understanding are much improved by extensive SP> commenting or documentation in the source code. They are SP> also improved by suitable choice of word names, even if these SP> are simply renamings. SP> In the case of LATER, the assumption that return addresses are SP> on the return stack was unstated. Michael has proposed using SP> RA as an indicator for this. It is an unfortunate side-effect SP> of ANS Forth that such techniques are sometimes disparaged. SP> SP> : later \ -- : resume in CALLER'S CALLER SP> \ Document assumptions here SP> ra> ra> swap >ra >ra SP> ; SP> SP> Some code just *is* difficult to understand, and Forth seems SP> to enable use of difficult (rare?) techniques more than most SP> other languages. SP> SP> This particular example should not be discouraged, it should SP> instead be documented and placed in a system layer rather SP> than an application layer. I would rather call this word SP> some thing like SP> ;LATER: SP> [LATER] SP> to indicate that something startling will happen.