Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #4541 > unrolled thread

multi-threading in Forth?

Back to article view | Back to comp.lang.forth

Contents

  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 1 of 4  [1] 2 3 4  Next page →

#4541 — multi-threading in Forth?

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?

[toc] | [next] | [standalone]

#4542

Michael L Gassanenko <m_l_g3@yahoo.com> writes Re: multi-threading in Forth?

> 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?

Why not try iForth? It has multi-thread/core stuff that works even when using 
it to write SSE/SSE2 floating-point code for Jack (audio-manager) callbacks.

iForth runs on Windows, Linux and OS X. You can have either a 32 or a 64 bit 
version on these OSs.

-marcel

[toc] | [prev] | [next] | [standalone]

#4544

In comp.lang.forth, Marcel Hendrix wrote:

> Why not try iForth? It has multi-thread/core stuff that works even when using
> it to write SSE/SSE2 floating-point code for Jack (audio-manager) callbacks.

On the page http://home.iae.nl/users/mhx/i4faq.html there is a remark:

"Tcl/Tk 8.0 works spectacularly well together with iForth under Windows XP,
as shown above".

...and there's a screenshot. To be more specific: did you indeed mean
"TCL/Tk" - or just Tk alone, as graphics kit used by iForth (without TCL
involved in any way)?
-- 
...but I'm ready to learn ('bout) of the power of Forth

[toc] | [prev] | [next] | [standalone]

#4569

Marcel Hendrix wrote:
> Michael L Gassanenko <m_l_g3@yahoo.com> writes Re: multi-threading in Forth?
> 
>> 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?
> 
> Why not try iForth? It has multi-thread/core stuff that works even when using 
> it to write SSE/SSE2 floating-point code for Jack (audio-manager) callbacks.
> 
> iForth runs on Windows, Linux and OS X. You can have either a 32 or a 64 bit 
> version on these OSs.
> 
> -marcel
> 
> 

:-(

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

[toc] | [prev] | [next] | [standalone]

#4570

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

[toc] | [prev] | [next] | [standalone]

#4571

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?

[toc] | [prev] | [next] | [standalone]

#4572

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.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

[toc] | [prev] | [next] | [standalone]

#4573

In comp.lang.forth, coos haak wrote:

> I too have an implementation where the inlining in FOO (called CO here,
> courtesy of Albert) must be switched of.

So what "return stack" serves for in such implementation, which isn't using
it for keeping the return addresses? Just as "spare parameter stack"?

Actually, _why not_ place return address exactly on return stack? What's the
point, what can we gain such way?
-- 
...but I'm ready to learn ('bout) of the power of Forth

[toc] | [prev] | [next] | [standalone]

#4574

On 8/4/11 7:35 AM, Zbiggy wrote:
> In comp.lang.forth, coos haak wrote:
>
>> I too have an implementation where the inlining in FOO (called CO here,
>> courtesy of Albert) must be switched of.
>
> So what "return stack" serves for in such implementation, which isn't using
> it for keeping the return addresses? Just as "spare parameter stack"?
>
> Actually, _why not_ place return address exactly on return stack? What's the
> point, what can we gain such way?

Some processors manage subroutine calls with internal registers or 
stacks and the implementation can get much better performance by using 
them. But the Standard gives an entitlement for using the Return Stack 
with >R R@ and R> so on those implementations a cosmetic Return Stack 
has to be provided to support these words.

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]

#4575

In comp.lang.forth, Elizabeth D Rather wrote:

> Some processors manage subroutine calls with internal registers or 
> stacks and the implementation can get much better performance by using 
> them.

1. From this thread I understood, that it has been done on Intel CPU. Is the
above valid also for Intel/AMD ones (that most popular among PC users)?

2. Even in a case of some "exotic" CPUs, where it could be maybe even a
requirement: isn't even in such case possible to "map" somehow that internal
registers to return stack available from within Forth?

Actually, I would expect to find return address on the return stack,
according to its name.
-- 
...but I'm ready to learn ('bout) of the power of Forth

[toc] | [prev] | [next] | [standalone]

#4577

On 8/4/11 8:38 AM, Zbiggy wrote:
> In comp.lang.forth, Elizabeth D Rather wrote:
>
>> Some processors manage subroutine calls with internal registers or
>> stacks and the implementation can get much better performance by using
>> them.
>
> 1. From this thread I understood, that it has been done on Intel CPU. Is the
> above valid also for Intel/AMD ones (that most popular among PC users)?

I don't have a list, although I can think of some 8051 variants on which 
return addresses are managed differently.  But the point of a Standard 
is to define programmer entitlements that are independent of CPU while 
allowing implementers to optimize performance underneath.

> 2. Even in a case of some "exotic" CPUs, where it could be maybe even a
> requirement: isn't even in such case possible to "map" somehow that internal
> registers to return stack available from within Forth?

No, because on some (at least that I am familiar with) there isn't a 
single cell-sized register that you can treat that way, and there may be 
other limitations.

> Actually, I would expect to find return address on the return stack,
> according to its name.

Well, yes, that was certainly its original use, and probably how it 
works on the vast majority of implementations.

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]

#4582

On 04/08/2011 15:12, Elizabeth D Rather wrote:
> I don't have a list, although I can think of some 8051 variants on which
> return addresses are managed differently. But the point of a Standard is
> to define programmer entitlements that are independent of CPU while
> allowing implementers to optimize performance underneath.

What, like a return stack, you mean ;-)

[toc] | [prev] | [next] | [standalone]

#4590

Elizabeth D Rather wrote:
> On 8/4/11 8:38 AM, Zbiggy wrote:
>> In comp.lang.forth, Elizabeth D Rather wrote:
>>
>>> Some processors manage subroutine calls with internal registers or
>>> stacks and the implementation can get much better performance by using
>>> them.
>>
>> 1. From this thread I understood, that it has been done on Intel CPU. 
>> Is the
>> above valid also for Intel/AMD ones (that most popular among PC users)?
> 
> I don't have a list, although I can think of some 8051 variants on which 
> return addresses are managed differently.  But the point of a Standard 
> is to define programmer entitlements that are independent of CPU while 
> allowing implementers to optimize performance underneath.

8051 was just fine; IIRC it was AVR that had a small circular buffer
for return addresses. OTOH, if one really cares, it is possible
to have a real return stack even on such hardware, you just don't
have to use that  poor excuse for a stack.

> 
>> 2. Even in a case of some "exotic" CPUs, where it could be maybe even a
>> requirement: isn't even in such case possible to "map" somehow that 
>> internal
>> registers to return stack available from within Forth?
> 
> No, because on some (at least that I am familiar with) there isn't a 
> single cell-sized register that you can treat that way, and there may be 
> other limitations.
/
I suspect the systems for such hardware are not 100% standard
for different reasons, one of which is that the users of
exotic hardware value access to their device more than
standard-compliance.

> 
>> Actually, I would expect to find return address on the return stack,
>> according to its name.
> 
> Well, yes, that was certainly its original use, and probably how it 
> works on the vast majority of implementations.
> 
> Cheers,
> Elizabeth
> 

In 1994 it was unclear whether the return address manipulations are
a dirty hack or an important technique. The TC just chose the easier
option.

Strictly speaking, a Forth function has the following inputs:
1) the data stack
2) the interpretation stack (the return stack plus the interpretation 
pointer IP)
3) the memory state

The "ordinary" words like DUP and ! create a new state of
the data stack and/or memory and the interpretation stack
(because they at least advance IP) and (!) invoke the
function that was pointed to by IP passing to it the
newly created inputs.

But this is not the only way to use the argument IP: for
example, BRANCH fetches a destination address from IP,
and passes control to the function pointed to by the
destination address, with the IP in interpretation
stack state replaced by a new address.

More complicated actions are possible too, for example,
it is possible to call the code at IP multiple times.
(You won't be able to EXIT there after that, you will
have to RDROP EXIT instead.)

But again, although all this is theoretically important,
the TC wanted an _industrial_ standard rather an
academic one, and there had been no common practice
of industrial use of such techniques. (Yes, there used
to be a significant industrial use.)

So the return address manipulations were left beyond
the standard. Of course, the standard was misread as
discouraging the use or r.a.manipulations (as well
as a prohibiting a lot of other techniques).

At the moment, ability to define my own control
structures is a must for me, so I checked whether
this stuff works.

[toc] | [prev] | [next] | [standalone]

#4596

mlg3 <m_l_g3@yahoo.com> wrote:
> Elizabeth D Rather wrote:
>> On 8/4/11 8:38 AM, Zbiggy wrote:
>>> In comp.lang.forth, Elizabeth D Rather wrote:
>>>
>>>> Some processors manage subroutine calls with internal registers or
>>>> stacks and the implementation can get much better performance by using
>>>> them.
>>>
>>> 1. From this thread I understood, that it has been done on Intel CPU. 
>>> Is the
>>> above valid also for Intel/AMD ones (that most popular among PC users)?
>> 
>> I don't have a list, although I can think of some 8051 variants on which 
>> return addresses are managed differently.  But the point of a Standard 
>> is to define programmer entitlements that are independent of CPU while 
>> allowing implementers to optimize performance underneath.
> 
> 8051 was just fine; IIRC it was AVR that had a small circular buffer
> for return addresses.

It depends on your Forth.  If you compile to native code you're going
to have to use the internal stack for return addresses, and this is
limited to less than 256 bytes.  (Actually, much less than 256 bytes
if you want to use internal memory for anything else.)  I don't think
you can use this stack for >R etc as well as return addresses:
internal RAM is just too precious.

> OTOH, if one really cares, it is possible to have a real return
> stack even on such hardware, you just don't have to use that poor
> excuse for a stack.

At some considerable cost in performance, yes.  On every entry to a
word you could push the return address into external RAM.  It's always
a trade-off.

Andrew.

[toc] | [prev] | [next] | [standalone]

#4581

On 04/08/2011 14:38, Zbiggy wrote:
> In comp.lang.forth, Elizabeth D Rather wrote:
>
>> Some processors manage subroutine calls with internal registers or
>> stacks and the implementation can get much better performance by using
>> them.
>
> 1. From this thread I understood, that it has been done on Intel CPU. Is the
> above valid also for Intel/AMD ones (that most popular among PC users)?
>
> 2. Even in a case of some "exotic" CPUs, where it could be maybe even a
> requirement: isn't even in such case possible to "map" somehow that internal
> registers to return stack available from within Forth?
>
> Actually, I would expect to find return address on the return stack,
> according to its name.

Exactly! So we're saying the old "Breakfast, lunch, dinner" example in 
Brodie wouldn't work?

[toc] | [prev] | [next] | [standalone]

#4587

In comp.lang.forth, Mark Wills wrote:

> Exactly! So we're saying the old "Breakfast, lunch, dinner" example in 
> Brodie wouldn't work?

I'm afraid, that without necessary modifications on iForth it won't work.
But I didn't try iForth yet.
-- 
...but I'm ready to learn ('bout) of the power of Forth

[toc] | [prev] | [next] | [standalone]

#4602

On 8/4/11 10:49 AM, Mark Wills wrote:
> On 04/08/2011 14:38, Zbiggy wrote:
>> In comp.lang.forth, Elizabeth D Rather wrote:
>>
>>> Some processors manage subroutine calls with internal registers or
>>> stacks and the implementation can get much better performance by using
>>> them.
>>
>> 1. From this thread I understood, that it has been done on Intel CPU.
>> Is the
>> above valid also for Intel/AMD ones (that most popular among PC users)?
>>
>> 2. Even in a case of some "exotic" CPUs, where it could be maybe even a
>> requirement: isn't even in such case possible to "map" somehow that
>> internal
>> registers to return stack available from within Forth?
>>
>> Actually, I would expect to find return address on the return stack,
>> according to its name.
>
> Exactly! So we're saying the old "Breakfast, lunch, dinner" example in
> Brodie wouldn't work?

There are many things in Brodie's books that won't work on many modern 
Forths, for very good reasons.  That is why folks here keep pointing out 
that Starting Forth, though readable and fun, is seriously dated and 
can't be relied upon technically.

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]

#4578

On 4 Aug 2011 14:35:31 +0200, Zbiggy
<zbigniew2011REMOVE@gmail.REMOVE.com> wrote:

>So what "return stack" serves for in such implementation, which isn't using
>it for keeping the return addresses? Just as "spare parameter stack"?

In terms of the ANS and Forth200x standards, yes.

>Actually, _why not_ place return address exactly on return stack? What's the
>point, what can we gain such way?

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.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#4583

On 04/08/2011 15:16, Stephen Pelc wrote:
> On 4 Aug 2011 14:35:31 +0200, Zbiggy
> <zbigniew2011REMOVE@gmail.REMOVE.com>  wrote:
>
>> So what "return stack" serves for in such implementation, which isn't using
>> it for keeping the return addresses? Just as "spare parameter stack"?
>
> In terms of the ANS and Forth200x standards, yes.
>
>> Actually, _why not_ place return address exactly on return stack? What's the
>> point, what can we gain such way?
>
> 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.
>
> Stephen
>
>

Okay, now it's making more sense! Perhaps the return stack should be 
obsoleted?

[toc] | [prev] | [next] | [standalone]

#4586

On Thu, 04 Aug 2011 16:51:54 +0100, Mark Wills
<markrobertwills@yahoo.co.uk> wrote:

>Okay, now it's making more sense! Perhaps the return stack should be 
>obsoleted?

No. The wording of the standard is that it is only standard to remove
stuff that you put on the return stack yourself, which excludes
return addresses. On the majority of desktop systems, i386, x86_64
or ARM, using R@ and friends to access a return address will not
surprise you.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web