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

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

I need a real big data stack

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

Contents

  I need a real big data stack lehs <skydda.barnen@gmail.com> - 2016-01-20 10:19 -0800
    Re: I need a real big data stack "Elizabeth D. Rather" <erather@forth.com> - 2016-01-20 09:45 -1000
      Re: I need a real big data stack lehs <skydda.barnen@gmail.com> - 2016-01-20 12:33 -0800
        Re: I need a real big data stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-21 13:53 +0000
          Re: I need a real big data stack lehs <skydda.barnen@gmail.com> - 2016-02-13 09:41 -0800
            Re: I need a real big data stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-02-14 15:09 +0000
              Re: I need a real big data stack lehs <skydda.barnen@gmail.com> - 2016-02-14 11:11 -0800
                Re: I need a real big data stack Coos Haak <chforth@hccnet.nl> - 2016-02-14 20:41 +0100
                  Re: I need a real big data stack lehs <skydda.barnen@gmail.com> - 2016-02-14 14:24 -0800
    Re: I need a real big data stack Whammo <sidciavic@gmail.com> - 2016-01-20 11:46 -0800
      Re: I need a real big data stack lehs <skydda.barnen@gmail.com> - 2016-01-20 12:36 -0800
        Re: I need a real big data stack Whammo <sidciavic@gmail.com> - 2016-01-21 19:12 -0800
          Re: I need a real big data stack lehs <skydda.barnen@gmail.com> - 2016-01-22 02:25 -0800
      Re: I need a real big data stack lehs <skydda.barnen@gmail.com> - 2016-01-20 12:38 -0800
    Re: I need a real big data stack Pablo Hugo Reda <pabloreda@gmail.com> - 2016-01-20 12:04 -0800
    Re: I need a real big data stack Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-01-20 20:15 +0000
      Re: I need a real big data stack lehs <skydda.barnen@gmail.com> - 2016-01-20 12:40 -0800
        Re: I need a real big data stack Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-01-21 00:00 +0000
        Re: I need a real big data stack Paul Rubin <no.email@nospam.invalid> - 2016-01-20 17:42 -0800
          Re: I need a real big data stack Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-21 10:45 +0000
            Re: I need a real big data stack Paul Rubin <no.email@nospam.invalid> - 2016-01-21 10:41 -0800
              Re: I need a real big data stack "Elizabeth D. Rather" <erather@forth.com> - 2016-01-21 09:02 -1000
                Re: I need a real big data stack hughaguilar96@gmail.com - 2016-01-21 16:42 -0800
              Re: I need a real big data stack lehs <skydda.barnen@gmail.com> - 2016-01-21 15:24 -0800
                Re: I need a real big data stack Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-22 01:13 +0000
                  Re: I need a real big data stack hughaguilar96@gmail.com - 2016-01-21 17:53 -0800
                    Re: I need a real big data stack Julian Fondren <julian.fondren@gmail.com> - 2016-01-21 19:09 -0800
                      Re: I need a real big data stack Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-22 15:24 +0000
                    Re: I need a real big data stack Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-22 15:16 +0000
                      Re: I need a real big data stack "Elizabeth D. Rather" <erather@forth.com> - 2016-01-22 09:07 -1000
                  Re: I need a real big data stack Coos Haak <chforth@hccnet.nl> - 2016-01-22 15:03 +0100
      Re: I need a real big data stack Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-21 10:36 +0000
    Re: I need a real big data stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-21 13:32 +0000
      Re: I need a real big data stack Ron Aaron <rambamist@gmail.com> - 2016-01-21 15:51 +0200
      Re: I need a real big data stack lehs <skydda.barnen@gmail.com> - 2016-01-21 15:20 -0800
        Re: I need a real big data stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-22 15:28 +0000

Page 1 of 2  [1] 2  Next page →

#44965 — I need a real big data stack

I can do it in SP-Forth and I could do it in FIG-Forth. I understand that it creates problem with portability and that there are no standard words to change the stack buffer area, but I would like to be able to do it anyway.

Is it possible in GForth?

http://forthmath.blogspot.se/

[toc] | [next] | [standalone]

#44966

On 1/20/16 8:19 AM, lehs wrote:
> I can do it in SP-Forth and I could do it in FIG-Forth. I understand
> that it creates problem with portability and that there are no
> standard words to change the stack buffer area, but I would like
> to be able to do it anyway.
>
> Is it possible in GForth?
>
> http://forthmath.blogspot.se/
>

In many implementations, the data stack is situated in unused memory, so 
it can be quite large (1 Mb or more, especially on PCs). As it is of 
indefinite size, re-sizing is not relevant.

If you're looking for portability for an application, just declare a 
dependency on "at least <n> bytes of data stack space", and then 
potential users can determine whether a particular system can meet that 
or not.

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]

#44972

Den onsdag 20 januari 2016 kl. 20:45:54 UTC+1 skrev Elizabeth D. Rather:
> On 1/20/16 8:19 AM, lehs wrote:
> > I can do it in SP-Forth and I could do it in FIG-Forth. I understand
> > that it creates problem with portability and that there are no
> > standard words to change the stack buffer area, but I would like
> > to be able to do it anyway.
> >
> > Is it possible in GForth?
> >
> > http://forthmath.blogspot.se/
> >
> 
> In many implementations, the data stack is situated in unused memory, so 
> it can be quite large (1 Mb or more, especially on PCs). As it is of 
> indefinite size, re-sizing is not relevant.
> 
> If you're looking for portability for an application, just declare a 
> dependency on "at least <n> bytes of data stack space", and then 
> potential users can determine whether a particular system can meet that 
> or not.
> 
> 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."
> ==================================================

How to put the stack in unused indefinite memory? In GForth there seems to be some control that abort if the number on the stack is greater than the stack first implemented in the dictionary. Even if the stack is reallocated thru variables as s0 and sp0.

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

#44993

lehs <skydda.barnen@gmail.com> writes:
>How to put the stack in unused indefinite memory? In GForth there seems to be some control that abort if the number on the stack is greater than the stack first implemented in the dictionary. Even if the stack is reallocated thru variables as s0 and sp0.

Gforth has two mechanisms for checking the stack depth: 

1) Unaccessible guard pages around the stacks on decent OSs; these
should not play a role here.

2) It calls ?STACK on between any two words proecessed by the text
interpreter.  ?STACK compares sp@ against sp0.  So if you want to
setup your own stack, you need to change them both, e.g.:

: new-data-stack ( u -- )
  dup aligned allocate throw + dup sp0 ! sp! ;
1000000 new-data-stack

But the -d option is better because it still gives you guard page
protection, while option 2 does not.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#45508

Den torsdag 21 januari 2016 kl. 15:05:37 UTC+1 skrev Anton Ertl:
> lehs <skydda.barnen@gmail.com> writes:
> >How to put the stack in unused indefinite memory? In GForth there seems to be some control that abort if the number on the stack is greater than the stack first implemented in the dictionary. Even if the stack is reallocated thru variables as s0 and sp0.
> 
> Gforth has two mechanisms for checking the stack depth: 
> 
> 1) Unaccessible guard pages around the stacks on decent OSs; these
> should not play a role here.
> 
> 2) It calls ?STACK on between any two words proecessed by the text
> interpreter.  ?STACK compares sp@ against sp0.  So if you want to
> setup your own stack, you need to change them both, e.g.:
> 
> : new-data-stack ( u -- )
>   dup aligned allocate throw + dup sp0 ! sp! ;
> 1000000 new-data-stack
> 
> But the -d option is better because it still gives you guard page
> protection, while option 2 does not.
> 
> - anton
> -- 
> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>      New standard: http://www.forth200x.org/forth200x.html
>    EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
What would the second alternative be for the return stack? I've got error messages when trying similar methods.

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

#45519

lehs <skydda.barnen@gmail.com> writes:
>> 2) It calls ?STACK on between any two words proecessed by the text
>> interpreter.  ?STACK compares sp@ against sp0.  So if you want to
>> setup your own stack, you need to change them both, e.g.:
>>=20
>> : new-data-stack ( u -- )
>>   dup aligned allocate throw + dup sp0 ! sp! ;
>> 1000000 new-data-stack
...
>What would the second alternative be for the return stack? I've got error m=
>essages when trying similar methods.

You could try changing rp0 and then calling QUIT (untested).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#45526

Den söndag 14 februari 2016 kl. 16:14:27 UTC+1 skrev Anton Ertl:
> lehs <skydda.barnen@gmail.com> writes:
> >> 2) It calls ?STACK on between any two words proecessed by the text
> >> interpreter.  ?STACK compares sp@ against sp0.  So if you want to
> >> setup your own stack, you need to change them both, e.g.:
> >>=20
> >> : new-data-stack ( u -- )
> >>   dup aligned allocate throw + dup sp0 ! sp! ;
> >> 1000000 new-data-stack
> ...
> >What would the second alternative be for the return stack? I've got error m=
> >essages when trying similar methods.
> 
> You could try changing rp0 and then calling QUIT (untested).
> 
> - anton
> -- 
> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>      New standard: http://www.forth200x.org/forth200x.html
>    EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

100008 allocate throw 100000 - rp0 ! quit

gives an error message 'invalid memory address' on GForth Android, but then it works ok. Thanks!

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

#45530

Op Sun, 14 Feb 2016 11:11:01 -0800 (PST) schreef lehs:

> Den söndag 14 februari 2016 kl. 16:14:27 UTC+1 skrev Anton Ertl:
>> lehs <skydda.barnen@gmail.com> writes:
>>>> 2) It calls ?STACK on between any two words proecessed by the text
>>>> interpreter.  ?STACK compares sp@ against sp0.  So if you want to
>>>> setup your own stack, you need to change them both, e.g.:
>>>>=20
>>>> : new-data-stack ( u -- )
>>>>   dup aligned allocate throw + dup sp0 ! sp! ;
>>>> 1000000 new-data-stack
>> ...
>>>What would the second alternative be for the return stack? I've got error m=
>>>essages when trying similar methods.
>> 
>> You could try changing rp0 and then calling QUIT (untested).
>> 
>> - anton
>> -- 
>> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
>> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>>      New standard: http://www.forth200x.org/forth200x.html
>>    EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
> 
> 100008 allocate throw 100000 - rp0 ! quit
> 
> gives an error message 'invalid memory address' on GForth Android, but then it works ok. Thanks!

I have no problem with Android. But why subtract 100000? This way you have
a stack of 2 cells. Did you mean '+' ?

groet Coos

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

#45536

Den söndag 14 februari 2016 kl. 20:41:56 UTC+1 skrev Coos Haak:
> Op Sun, 14 Feb 2016 11:11:01 -0800 (PST) schreef lehs:
> 
> > Den söndag 14 februari 2016 kl. 16:14:27 UTC+1 skrev Anton Ertl:
> >> lehs <skydda.barnen@gmail.com> writes:
> >>>> 2) It calls ?STACK on between any two words proecessed by the text
> >>>> interpreter.  ?STACK compares sp@ against sp0.  So if you want to
> >>>> setup your own stack, you need to change them both, e.g.:
> >>>>=20
> >>>> : new-data-stack ( u -- )
> >>>>   dup aligned allocate throw + dup sp0 ! sp! ;
> >>>> 1000000 new-data-stack
> >> ...
> >>>What would the second alternative be for the return stack? I've got error m=
> >>>essages when trying similar methods.
> >> 
> >> You could try changing rp0 and then calling QUIT (untested).
> >> 
> >> - anton
> >> -- 
> >> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> >> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
> >>      New standard: http://www.forth200x.org/forth200x.html
> >>    EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/
> > 
> > 100008 allocate throw 100000 - rp0 ! quit
> > 
> > gives an error message 'invalid memory address' on GForth Android, but then it works ok. Thanks!
> 
> I have no problem with Android. But why subtract 100000? This way you have
> a stack of 2 cells. Did you mean '+' ?
> 
> groet Coos

You're right, thanks!

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

#44967

 You don't need a real big data stack.
You need to factor your problems.

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

#44974

Den onsdag 20 januari 2016 kl. 20:47:01 UTC+1 skrev Whammo:
> You don't need a real big data stack.
> You need to factor your problems.

I need it for an implementation of sets on the stack. Even if a set is rather small, the number of subsets fast grow very big, with a big powerset.

Else, factoring is never wrong.

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

#45008

On Wednesday, January 20, 2016 at 12:36:11 PM UTC-8, lehs wrote:
> Den onsdag 20 januari 2016 kl. 20:47:01 UTC+1 skrev Whammo:
> > You don't need a real big data stack.
> > You need to factor your problems.
> 
> I need it for an implementation of sets on the stack. Even if a set is rather small, the number of subsets fast grow very big, with a big powerset.
> 
> Else, factoring is never wrong.

 I take it you're creating a library rather than solving a specific problem?

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

#45020

Den fredag 22 januari 2016 kl. 04:12:29 UTC+1 skrev Whammo:
> On Wednesday, January 20, 2016 at 12:36:11 PM UTC-8, lehs wrote:
> > Den onsdag 20 januari 2016 kl. 20:47:01 UTC+1 skrev Whammo:
> > > You don't need a real big data stack.
> > > You need to factor your problems.
> > 
> > I need it for an implementation of sets on the stack. Even if a set is rather small, the number of subsets fast grow very big, with a big powerset.
> > 
> > Else, factoring is never wrong.
> 
>  I take it you're creating a library rather than solving a specific problem?
No, not really a library. A library has an air of optimal solutions. That's for the professionals. I want to have fun and try to create an experimental environment.

Since I started enjoy myself with sets the need of stack space growed enormously. Recursive computation of all subsets of a set with 24 elements creates 16777216 sets on the stack.

Using the stacks for sets may not be efficient, but it's simple and an interesting experiment.



Nnnn

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

#44975

Den onsdag 20 januari 2016 kl. 20:47:01 UTC+1 skrev Whammo:
> You don't need a real big data stack.
> You need to factor your problems.

Yes, that's the alternative. But using the data stack makes my implementation of sets easier and nicer. 

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

#44970

El miércoles, 20 de enero de 2016, 15:19:38 (UTC-3), lehs  escribió:
> I can do it in SP-Forth and I could do it in FIG-Forth. I understand that it creates problem with portability and that there are no standard words to change the stack buffer area, but I would like to be able to do it anyway.
> 
> Is it possible in GForth?
> 
> http://forthmath.blogspot.se/

why not make a external stack with words for manipulate?

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

#44971

On Wed, 20 Jan 2016 10:19:36 -0800 (PST)
lehs <skydda.barnen@gmail.com> wrote:

> I can do it in SP-Forth and I could do it in FIG-Forth. I
> understand that it creates problem with portability and that
> there are no standard words to change the stack buffer area,
> but I would like to be able to do it anyway.
> 
> Is it possible in GForth?

Yes, but googled as I was too lazy to read manual: 

https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Stack-and-Dictionary-Sizes.html

> 
> http://forthmath.blogspot.se/

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

#44976

Den onsdag 20 januari 2016 kl. 21:15:14 UTC+1 skrev Jan Coombs:
> On Wed, 20 Jan 2016 10:19:36 -0800 (PST)
> lehs <skydda.barnen@gmail.com> wrote:
> 
> > I can do it in SP-Forth and I could do it in FIG-Forth. I
> > understand that it creates problem with portability and that
> > there are no standard words to change the stack buffer area,
> > but I would like to be able to do it anyway.
> > 
> > Is it possible in GForth?
> 
> Yes, but googled as I was too lazy to read manual: 
> 
> https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Stack-and-Dictionary-Sizes.html
> 
> > 
> > http://forthmath.blogspot.se/

I may need a stack of hundreds of thousands bytes. Not what i want in the dictionary...

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

#44978

On Wed, 20 Jan 2016 12:40:18 -0800 (PST)
lehs <skydda.barnen@gmail.com> wrote:

> Den onsdag 20 januari 2016 kl. 21:15:14 UTC+1 skrev Jan Coombs:
> > On Wed, 20 Jan 2016 10:19:36 -0800 (PST)
> > lehs <skydda.barnen@gmail.com> wrote:
> > 
> > > I can do it in SP-Forth and I could do it in FIG-Forth. I
> > > understand that it creates problem with portability and
> > > that there are no standard words to change the stack
> > > buffer area, but I would like to be able to do it anyway.
> > > 
> > > Is it possible in GForth?
> > 
> > Yes, but googled as I was too lazy to read manual: 
> > 
> > https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Stack-and-Dictionary-Sizes.html
> 
> I may need a stack of hundreds of thousands bytes. Not what i
> want in the dictionary...

try this:

jan:~$ gforth -d 1048576
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation,
Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type
`license' Type `bye' to exit
: t 130000 0 do i loop cr depth . ;  ok
t 
130000  ok
.s <130000> 129991 129992 129993 129994 129995 129996 129997
129998 129999  ok


It was mentioned in the above ref, but this one is better:

https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Invoking-Gforth.html#Invoking-Gforth


Jan Coombs

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

#44979

lehs <skydda.barnen@gmail.com> writes:
> I may need a stack of hundreds of thousands bytes. Not what i want in
> the dictionary...

I think it's better to put it in the dictionary, which is the usual
place to put large memory objects.  The stack is for immediate
calculations and you should usually know the exact stack picture.

From
http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Invoking-Gforth.html :

  --dictionary-size size
  -m size

      Allocate size space for the Forth dictionary space instead of
      using the default specified in the image (typically 256K). The
      size specification for this and subsequent options consists of an
      integer and a unit (e.g., 4M). The unit can be one of b (bytes), e
      (element size, in this case Cells), k (kilobytes), M (Megabytes),
      G (Gigabytes), and T (Terabytes). If no unit is specified, e is
      used.

I think this says the default setting is 256K cells: 1MB or 2MB
depending on the machine word size.  But you can make it much larger.

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

#44987

Paul Rubin <no.email@nospam.invalid> writes:

>lehs <skydda.barnen@gmail.com> writes:
>> I may need a stack of hundreds of thousands bytes. Not what i want in
>> the dictionary...

>I think it's better to put it in the dictionary, which is the usual
>place to put large memory objects.  The stack is for immediate
>calculations and you should usually know the exact stack picture.

Usual, but not always. The stack is for temporary objects, however large.
If large objects are used in stack not heap fashion, a large data stack
use may be a perfect solution.
E.g. one of the rosetta codes ask for the first N k-almost primes.
One could combine a set of N k-1-almost with a set of N 1-almost
given N^2 elements on the stack. Sort them and keep the N smallest
in the permanent store for k-almost primes.

Similarly Stern Brocot algorithms ask for large stack use, where
other languages are obliged to implement a special stack in code.

>From
>http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Invoking-Gforth.html :

>  --dictionary-size size
>  -m size

>      Allocate size space for the Forth dictionary space instead of
>      using the default specified in the image (typically 256K). The
>      size specification for this and subsequent options consists of an
>      integer and a unit (e.g., 4M). The unit can be one of b (bytes), e
>      (element size, in this case Cells), k (kilobytes), M (Megabytes),
>      G (Gigabytes), and T (Terabytes). If no unit is specified, e is
>      used.

>I think this says the default setting is 256K cells: 1MB or 2MB
>depending on the machine word size.  But you can make it much larger.

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]

Page 1 of 2  [1] 2  Next page →

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

csiph-web