Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #4541 > unrolled thread
| Started by | Michael L Gassanenko <m_l_g3@yahoo.com> |
|---|---|
| First post | 2011-08-02 02:01 -0700 |
| Last post | 2011-08-03 03:53 -0500 |
| Articles | 15 on this page of 75 — 18 participants |
Back to article view | Back to comp.lang.forth
multi-threading in Forth? Michael L Gassanenko <m_l_g3@yahoo.com> - 2011-08-02 02:01 -0700
Re: multi-threading in Forth? mhx@iae.nl (Marcel Hendrix) - 2011-08-02 11:22 +0200
Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-02 15:26 +0200
Re: multi-threading in Forth? mlg3 <m_l_g3@yahoo.com> - 2011-08-04 01:06 +0400
Re: multi-threading in Forth? mhx@iae.nl (Marcel Hendrix) - 2011-08-04 06:36 +0200
Re: multi-threading in Forth? Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-04 08:25 +0100
Re: multi-threading in Forth? coos haak <chforth@hccnet.nl> - 2011-08-04 13:42 +0200
Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-04 14:35 +0200
Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-04 08:30 -0500
Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-04 15:38 +0200
Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-04 09:12 -0500
Re: multi-threading in Forth? Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-04 16:50 +0100
Re: multi-threading in Forth? mlg3 <m_l_g3@yahoo.com> - 2011-08-04 23:52 +0400
Re: multi-threading in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-05 08:50 -0500
Re: multi-threading in Forth? Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-04 16:49 +0100
Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-04 19:23 +0200
Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-05 10:57 -0500
Re: multi-threading in Forth? stephenXXX@mpeforth.com (Stephen Pelc) - 2011-08-04 14:16 +0000
Re: multi-threading in Forth? Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-04 16:51 +0100
Re: multi-threading in Forth? stephenXXX@mpeforth.com (Stephen Pelc) - 2011-08-04 17:14 +0000
Re: multi-threading in Forth? "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-06 03:46 -0400
Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-04 19:11 +0200
Re: multi-threading in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-05 08:43 -0500
Re: multi-threading in Forth? mlg3 <m_l_g3@yahoo.com> - 2011-08-06 01:49 +0400
Re: multi-threading in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-06 03:13 -0500
Re: multi-threading in Forth? mlg3 <m_l_g3@yahoo.com> - 2011-08-09 04:41 +0400
Re: multi-threading in Forth? mlg3 <m_l_g3@yahoo.com> - 2011-08-09 11:01 +0400
Re: multi-threading in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-10 09:02 -0500
Re: multi-threading in Forth? mlg3 <m_l_g3@yahoo.com> - 2011-08-11 01:10 +0400
Re: multi-threading in Forth? Ouatu Bogdan <ouatubi@gmail.com> - 2011-08-10 13:22 +0000
Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-06 01:12 +0200
Re: multi-threading in Forth? coos haak <chforth@hccnet.nl> - 2011-08-06 02:37 +0200
Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-06 12:54 +0200
Re: multi-threading in Forth? alextangent <blog@rivadpm.com> - 2011-08-06 12:15 +0100
Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-05 22:23 -0500
Re: multi-threading in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-06 03:17 -0500
Re: multi-threading in Forth? Julian Fondren <ayrnieu@gmail.com> - 2011-08-05 19:02 -0500
Re: multi-threading in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-06 04:01 -0500
return-address manipulation (was: multi-threading in Forth?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-06 16:35 +0000
Re: return-address manipulation Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-08-07 11:45 +0100
Re: return-address manipulation Josh Grams <josh@qualdan.com> - 2011-08-08 09:40 +0000
Re: return-address manipulation Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-08-08 12:17 +0100
Re: return-address manipulation Josh Grams <josh@qualdan.com> - 2011-08-08 12:29 +0000
Re: return-address manipulation mlg3 <m_l_g3@yahoo.com> - 2011-08-09 03:54 +0400
Re: return-address manipulation mlg3 <m_l_g3@yahoo.com> - 2011-08-09 02:52 +0400
Re: return-address manipulation Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-08-09 20:54 +0100
Re: return-address manipulation mlg3 <m_l_g3@yahoo.com> - 2011-08-11 09:00 +0400
Re: return-address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-09 14:49 -0500
Re: return-address manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-10 09:03 +0000
Re: return-address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-10 05:13 -0500
Re: return-address manipulation mlg3 <m_l_g3@yahoo.com> - 2011-08-11 09:24 +0400
Re: return-address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-11 04:09 -0500
Re: return-address manipulation mlg3 <m_l_g3@yahoo.com> - 2011-08-11 09:36 +0400
Re: return-address manipulation mlg3 <m_l_g3@yahoo.com> - 2011-08-11 09:54 +0400
Re: return-address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-11 04:16 -0500
Re: multi-threading in Forth? Julian Fondren <ayrnieu@gmail.com> - 2011-08-07 01:43 -0500
Re: multi-threading in Forth? Spam@ControlQ.com - 2011-08-06 12:36 -0400
Re: multi-threading in Forth? Julian Fondren <ayrnieu@gmail.com> - 2011-08-07 01:13 -0500
Re: multi-threading in Forth? mlg3 <m_l_g3@yahoo.com> - 2011-08-09 02:35 +0400
Re: multi-threading in Forth? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-08-07 10:08 +0000
Re: multi-threading in Forth? Josh Grams <josh@qualdan.com> - 2011-08-07 13:45 +0000
Re: multi-threading in Forth? mhx@iae.nl (Marcel Hendrix) - 2011-08-05 17:17 +0200
Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-05 19:23 +0200
Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-05 10:53 -0500
Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-05 19:18 +0200
Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-06 09:59 -0500
Re: multi-threading in Forth? Spam@ControlQ.com - 2011-08-06 12:28 -0400
Re: multi-threading in Forth? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-08-06 11:29 +0000
Re: multi-threading in Forth? Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-04 16:47 +0100
Re: multi-threading in Forth? Julian Fondren <ayrnieu@gmail.com> - 2011-08-04 13:54 -0500
Re: multi-threading in Forth? coos haak <chforth@hccnet.nl> - 2011-08-04 22:02 +0200
Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-02 08:23 -0500
Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-02 15:30 +0200
Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-02 08:53 -0500
Re: multi-threading in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-03 03:53 -0500
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Josh Grams <josh@qualdan.com> |
|---|---|
| Date | 2011-08-07 13:45 +0000 |
| Message-ID | <4e3e9704$0$28364$a8266bb1@newsreader.readnews.com> |
| In reply to | #4609 |
Julian Fondren wrote: <8662mb5rw8.fsf@gmail.com> > I'm privately becoming more and more confident that fiddling with the > return stack is a huge readability and therefore maintainability win, return address manipulation > : with-base ( u -- ) > r> BASE @ >r swap BASE ! > ['] call catch r> BASE ! throw ; > > : x1 ( ... "to end of line" -- ... ) > 16 with-base 0 parse evaluate ; vs. immediate words > : base[ ( u -- ) > postpone BASE postpone @ postpone >r > postpone BASE postpone ! ; immediate > : ]base ( -- ) > postpone r> postpone BASE postpone ! ; immediate > > : x2 ( ... "to end of line" -- ... ) > 16 base[ 0 parse evaluate ]base ; The other thing you can do is: : with-base ( xt u -- ) base @ >r base ! catch r> base ! throw ; : x3 ( ... "to end of line" -- ... ) 0 parse ['] evaluate 16 with-base ; It forces you to name your inner functionality, but that's usually not *too* inconvenient. As Anton mentioned elsewhere, nested anonymous code blocks would help with that. It has a bunch of caveats, but you might take a look at Gerry Jackson's lambda expressions in ANS Forth, if you're into that sort of thing. http://www.qlikz.org/forth/library/lambda.html If you and are willing to write system-dependent code, you can do it much more simply with something like `AHEAD [ :NONAME ] ... THEN`. :NONAME often does things (like set up for locals) which don't nest, so you may have to modify it, but I think it's possible to do roughly this on many systems, and it would be interesting to see how many and publish a portability layer. But I just don't have much time for programming any more... --Josh
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2011-08-05 17:17 +0200 |
| Message-ID | <86181898958436@frunobulax.edu> |
| In reply to | #4585 |
Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> writes Re: multi-threading in Forth? [..] > I think, that "rule" doesn't necessarily mean formal requirement of any > standard committee - it can be just "traditional solution", present and known > since 30 years, if it still does its work with no problems. But it generally doesn't (have no problems), and never did. This means that it is not a portable technique, or one that can be made portable, and that is the reason the Standard does not mandate it (The Standard's goal is not to define better Forths). > So if I'm trying to use a compiler written for some "exotic" hardware, yes: > I can expect the presence of some non-standard solution. But why in the case > of compiler written for most popular hardware? There surely is some > rationale behind it, although IMHO if such change won't give any tremendous > profits (much greater efficiency?), perhaps it's better to _not_ introduce > it, because most programmers will expect to find the things working "old way". There might be some misunderstanding here. iForth DOES use a return stack, there are real return addresses on it, and you can manipulate these if you know what you are doing (and know about [ -opt ]). Unmanaged access to return stack items that weren't put there by the program itself will lead to problems. The reason for this is that R> >R R@ etc. are first inlined and then optimized away, as are other short definitions. For the purposes and target audience of iForth this is many times more important than the benefits of return stack manipulation (which is still possible by either using [ -opt ] or by redefining R> >R etc.) -marcel BTW: Yes, iForth does/did interface to both Tcl and Tk. However, the ActiveState implementation I just now tried it with on Windows 7 seems to have a broken pipe interface (older implementations worked).
[toc] | [prev] | [next] | [standalone]
| From | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| Date | 2011-08-05 19:23 +0200 |
| Message-ID | <slrnj3ohan.7er.zbigniew2011REMOVE@Tichy.myhome.org> |
| In reply to | #4597 |
In comp.lang.forth, Marcel Hendrix wrote:
> There might be some misunderstanding here. iForth DOES use a return stack,
> there are real return addresses on it, and you can manipulate these if you
> know what you are doing (and know about [ -opt ]).
Then I've got to take a closer look at iForth, and its docs.
> BTW: Yes, iForth does/did interface to both Tcl and Tk. However, the
> ActiveState implementation I just now tried it with on Windows 7 seems to
> have a broken pipe interface (older implementations worked).
Maybe it could be worthy to let them (TCT) know, so they could be able to
fix it in 8.6.0 "final".
--
...but I'm ready to learn ('bout) of the power of Forth
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2011-08-05 10:53 -0500 |
| Message-ID | <XLydnWmSS-yAj6HTnZ2dnUVZ_t6dnZ2d@supernews.com> |
| In reply to | #4585 |
On 8/4/11 12:11 PM, Zbiggy wrote: > In comp.lang.forth, Stephen Pelc wrote: > >> In practice, embedded Forths using 8051s may keep return addresses on >> a third stack. However, what you see more often is that a return >> address may be larger than a cell size (DSP, PIC ...) or may not be >> formatted as you expect (e.g. Cortex-M has bit 0 always set). >> >> Hence, there are occasion when you *need* to isolate the return >> address words because they are not just R@ and friends. Yes, this >> sort of problem is seen regularly. > > Of course, it's better to create Forth compiler with "strange return stack", > than to not make it at all. But I understand the described situation rather > as a rationale, why ANS-standard doesn't impose the strict rules about stack: > "...because sometimes can be not possible to fulfil such requirement" - than > as a statement: "actually, return stack can be implemented in any way". Yes: > formally it can - it isn't forbidden by law, therefore no Forth creator will > be punished - but the question is: should it really be treated so blithely? It's a matter of tradeoffs. If you stick around here, you'll see that nothing regarding a Standard is done "blithely". In this case, it is possible that handling return addresses differently can produce a very significant improvement in performance. That benefits every application that runs on the platform. Manipulating return addresses, on the other hand, is a technique that is fraught with problems and negative impact on readability and maintainability, and a strategy that is rarely (if ever) actually required. So the decision seems pretty logical, to me. > ...What is return stack, is described in every > Forth primer. And then we can see, that the rule works "sometimes". It works often. If it's important to you to do this stuff, as others have said, just declare a dependency on being able to do it, bear in mind that what you're doing won't run everywhere, and live with that. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| Date | 2011-08-05 19:18 +0200 |
| Message-ID | <slrnj3oh19.7er.zbigniew2011REMOVE@Tichy.myhome.org> |
| In reply to | #4601 |
In comp.lang.forth, Elizabeth D Rather wrote:
> It's a matter of tradeoffs. If you stick around here, you'll see that
> nothing regarding a Standard is done "blithely".
I'm pretty sure about it - but I meant exactly the opposite: the
things/rules, which _aren't formally_ standarized. But - despite of this -
were created/used in some specific way during years.
> In this case, it is
> possible that handling return addresses differently can produce a very
> significant improvement in performance. That benefits every application
> that runs on the platform. Manipulating return addresses, on the other
> hand, is a technique that is fraught with problems and negative impact
> on readability and maintainability, and a strategy that is rarely (if
> ever) actually required. So the decision seems pretty logical, to me.
Well, in "Starting Forth" it has been introduced as quite normal procedure,
just one of possible ways to do things.
But, actually, my point was, that I would expect the return addresses on...
yes, on return stack.
--
...but I'm ready to learn ('bout) of the power of Forth
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2011-08-06 09:59 -0500 |
| Message-ID | <kqudnRHEccNWy6DTnZ2dnUVZ_sadnZ2d@supernews.com> |
| In reply to | #4603 |
On 8/5/11 12:18 PM, Zbiggy wrote: > In comp.lang.forth, Elizabeth D Rather wrote: > >> It's a matter of tradeoffs. If you stick around here, you'll see that >> nothing regarding a Standard is done "blithely". > > I'm pretty sure about it - but I meant exactly the opposite: the > things/rules, which _aren't formally_ standarized. But - despite of this - > were created/used in some specific way during years. > >> In this case, it is >> possible that handling return addresses differently can produce a very >> significant improvement in performance. That benefits every application >> that runs on the platform. Manipulating return addresses, on the other >> hand, is a technique that is fraught with problems and negative impact >> on readability and maintainability, and a strategy that is rarely (if >> ever) actually required. So the decision seems pretty logical, to me. > > Well, in "Starting Forth" it has been introduced as quite normal procedure, > just one of possible ways to do things. Yes, in the 1980's when SF was written, Forth83 mandated implementation details that you could use in this way. You could also depend on being able to access up to 65535 bytes of memory, 16-bit values on the data stack, and indirect-threaded implementation. As I have explained elsewhere in this thread, removing implementation details from the standard 20 years ago has enabled modern Forths to be much faster and more powerful. Moral: do not rely on any text written in the mid-1980's to be accurately descriptive of 2011 technology. > But, actually, my point was, that I would expect the return addresses on... > yes, on return stack. That was historically accurate, and still works in some implementations. It is not universally true. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Spam@ControlQ.com |
|---|---|
| Date | 2011-08-06 12:28 -0400 |
| Message-ID | <alpine.BSF.2.00.1108061224160.37413@yoko.controlq.com> |
| In reply to | #4622 |
On Sat, 6 Aug 2011, Elizabeth D Rather wrote: > > That was historically accurate, and still works in some implementations. It > is not universally true. > Elizabeth correctly refers to the implicit contract which is the standard behaviour of Forth. There are things upon which application developers can rely, but implementation details are not one of those. That frees implementers from being stuck forever with the fig model, and allows Forth to evolve. The balance is a healthy one. Rob Sciuk
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2011-08-06 11:29 +0000 |
| Message-ID | <lpi7xp.i7g@spenarnc.xs4all.nl> |
| In reply to | #4601 |
In article <XLydnWmSS-yAj6HTnZ2dnUVZ_t6dnZ2d@supernews.com>, Elizabeth D Rather <erather@forth.com> wrote: >On 8/4/11 12:11 PM, Zbiggy wrote: >> In comp.lang.forth, Stephen Pelc wrote: >> >>> In practice, embedded Forths using 8051s may keep return addresses on >>> a third stack. However, what you see more often is that a return >>> address may be larger than a cell size (DSP, PIC ...) or may not be >>> formatted as you expect (e.g. Cortex-M has bit 0 always set). >>> >>> Hence, there are occasion when you *need* to isolate the return >>> address words because they are not just R@ and friends. Yes, this >>> sort of problem is seen regularly. >> >> Of course, it's better to create Forth compiler with "strange return stack", >> than to not make it at all. But I understand the described situation rather >> as a rationale, why ANS-standard doesn't impose the strict rules about stack: >> "...because sometimes can be not possible to fulfil such requirement" - than >> as a statement: "actually, return stack can be implemented in any way". Yes: >> formally it can - it isn't forbidden by law, therefore no Forth creator will >> be punished - but the question is: should it really be treated so blithely? > >It's a matter of tradeoffs. If you stick around here, you'll see that >nothing regarding a Standard is done "blithely". In this case, it is >possible that handling return addresses differently can produce a very >significant improvement in performance. That benefits every application >that runs on the platform. Manipulating return addresses, on the other >hand, is a technique that is fraught with problems and negative impact >on readability and maintainability, and a strategy that is rarely (if >ever) actually required. So the decision seems pretty logical, to me. Take the example of `` :; '' of colorforth ( CO in my book). Some considered it an example of beneficial use of the return stack to implement coroutines: : CO R> R> SWAP >R >R ; It is much better though to consider CO as an abstraction in it own right. The explicit return stack manipulation is a possible implementation technique. In ciforth CO is a code word with just one instruction. In colorforth :; is an instruction at the machine level. > >Cheers, >Elizabeth Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2011-08-04 16:47 +0100 |
| Message-ID | <j1eev7$n41$1@dont-email.me> |
| In reply to | #4572 |
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: >>> mlg3<m_l_g3@yahoo.com> writes Re: multi-threading in Forth? >>> >>>> Marcel Hendrix wrote: >>>>> Michael L Gassanenko<m_l_g3@yahoo.com> writes Re: multi-threading in Forth? >>> [..] >>>> :-( >>> >>>> iForth: >>>> FORTH> : foo r> r> swap>r>r ; ok >>>> FORTH> : bar 11 . foo 111 . ; ok >>>> FORTH> : baz 22 . bar 222 . ; ok >>>> FORTH> baz 22 11 111 222 ok >>> >>>> which means I cannot implement control structures in Forth. >>> >>>> For comparison, Gforth: >>>> : foo r> r> swap>r>r ; ok >>>> : bar 11 . foo 111 . ; ok >>>> : baz 22 . bar 222 . ; ok >>>> baz 22 11 222 111 ok >>> >>> 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!
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <ayrnieu@gmail.com> |
|---|---|
| Date | 2011-08-04 13:54 -0500 |
| Message-ID | <86d3gl57oi.fsf@gmail.com> |
| In reply to | #4580 |
Mark Wills <markrobertwills@yahoo.co.uk> 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.
[toc] | [prev] | [next] | [standalone]
| From | coos haak <chforth@hccnet.nl> |
|---|---|
| Date | 2011-08-04 22:02 +0200 |
| Message-ID | <wxcoyx0calzv$.ewxor4jo3ts9.dlg@40tude.net> |
| In reply to | #4580 |
Op Thu, 04 Aug 2011 16:47:48 +0100 schreef Mark Wills: > 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: >>>> mlg3<m_l_g3@yahoo.com> writes Re: multi-threading in Forth? >>>> >>>>> Marcel Hendrix wrote: >>>>>> Michael L Gassanenko<m_l_g3@yahoo.com> writes Re: multi-threading in Forth? >>>> [..] >>>>> :-( >>>> >>>>> iForth: >>>>> FORTH> : foo r> r> swap>r>r ; ok >>>>> FORTH> : bar 11 . foo 111 . ; ok >>>>> FORTH> : baz 22 . bar 222 . ; ok >>>>> FORTH> baz 22 11 111 222 ok >>>> >>>>> which means I cannot implement control structures in Forth. >>>> >>>>> For comparison, Gforth: >>>>> : foo r> r> swap>r>r ; ok >>>>> : bar 11 . foo 111 . ; ok >>>>> : baz 22 . bar 222 . ; ok >>>>> baz 22 11 222 111 ok >>>> >>>> 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! See 3.2.3.3 Return stack And the comments of several in this thread. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2011-08-02 08:23 -0500 |
| Message-ID | <cu-dnVN9drzZZ6rTnZ2dnUVZ_tudnZ2d@supernews.com> |
| In reply to | #4541 |
On 8/2/11 4:01 AM, Michael L Gassanenko wrote: > While Google still works... > > Hi, everybody, I want to play a bit with multi-threading in Forth. I need to > create several OS threads, preferably under Linux (amd64), and I need some > synchronization primitive. And I don't want to implement that stuff myself. > It would be nice to have a code example as well. (And if the synchronization > primitive was a message/runnable queue...) If the threads could run on > different cores, that would be great. > > Any out-of-box solutions? > Sorry, all the multi-threading we've worked with has been either fully native (e.g. SwiftX, polyFORTH) or Windows-based, which I think has a very different set of rules/constraints from Linux. I haven't looked at Linux SwiftForth, it may have what you need. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> |
|---|---|
| Date | 2011-08-02 15:30 +0200 |
| Message-ID | <slrnj3g6hn.3i8.zbigniew2011REMOVE@Tichy.myhome.org> |
| In reply to | #4543 |
In comp.lang.forth, Elizabeth D Rather wrote:
> Sorry, all the multi-threading we've worked with has been either fully
> native (e.g. SwiftX, polyFORTH) or Windows-based, which I think has a
> very different set of rules/constraints from Linux. I haven't looked at
> Linux SwiftForth, it may have what you need.
Did you mean by the above, that multi-threading in Linux SwiftForth is
"deactivated" somehow, and - for example - one won't be able to use more
than just one core of CPU?
--
...but I'm ready to learn ('bout) of the power of Forth
[toc] | [prev] | [next] | [standalone]
| From | Elizabeth D Rather <erather@forth.com> |
|---|---|
| Date | 2011-08-02 08:53 -0500 |
| Message-ID | <Fe6dnRp43c7qnKXTnZ2dnUVZ_oKdnZ2d@supernews.com> |
| In reply to | #4545 |
On 8/2/11 8:30 AM, Zbiggy wrote: > In comp.lang.forth, Elizabeth D Rather wrote: > >> Sorry, all the multi-threading we've worked with has been either fully >> native (e.g. SwiftX, polyFORTH) or Windows-based, which I think has a >> very different set of rules/constraints from Linux. I haven't looked at >> Linux SwiftForth, it may have what you need. > > Did you mean by the above, that multi-threading in Linux SwiftForth is > "deactivated" somehow, and - for example - one won't be able to use more > than just one core of CPU? I mean that I haven't used it or read the manual, so I don't know what's there or how it works. Download it and try for yourself! Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-08-03 03:53 -0500 |
| Message-ID | <IeydnSSLQ9TjkaTTnZ2dnUVZ_hqdnZ2d@supernews.com> |
| In reply to | #4546 |
Elizabeth D Rather <erather@forth.com> wrote: > On 8/2/11 8:30 AM, Zbiggy wrote: >> In comp.lang.forth, Elizabeth D Rather wrote: >> >>> Sorry, all the multi-threading we've worked with has been either fully >>> native (e.g. SwiftX, polyFORTH) or Windows-based, which I think has a >>> very different set of rules/constraints from Linux. I haven't looked at >>> Linux SwiftForth, it may have what you need. >> >> Did you mean by the above, that multi-threading in Linux SwiftForth is >> "deactivated" somehow, and - for example - one won't be able to use more >> than just one core of CPU? > > I mean that I haven't used it or read the manual, so I don't know what's > there or how it works. Download it and try for yourself! It works just fine. Linux SwiftForth tasks are libc threads, and the result is a very clean fit. It scales well with little overhead to multiple cores. Andrew.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.forth
csiph-web