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

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

A brief note regarding BUFFER:

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

Contents

  A brief note regarding BUFFER: Julian Fondren <julian.fondren@gmail.com> - 2017-02-24 22:59 -0800
    Re: A brief note regarding BUFFER: "Elizabeth D. Rather" <erather@forth.com> - 2017-02-24 21:31 -1000
    Re: A brief note regarding BUFFER: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-25 17:40 +0000

#55090 — A brief note regarding BUFFER:

Hello clf,

Suppose you have hard limits and some mild configuration at compile
time, with code like

  [undefined] max-users [if]
    100 constant max-users
  [then]

  create user-table  max-users user-size * allot
  create enemies     max-users cells allot
  ... and so on ...

Not all software is permitted to use all available resources and then
kill its host when under duress, and for such software it's nice to be
able to say that when tuned a certain way it'll use at most some
amount of memory.


Now let's suppose someone says "I'd like to see how this code works
with 100 million users". You would likely have to rewrite the above:

  max-users user-size * allocate throw constant user-table
  max-users cells allocate throw constant enemies

It's just not as nice, is it?


If you had used BUFFER: instead...

  [undefined] max-users [if]
    100 constant max-users
  [then]

  max-users user-size * buffer: user-table
  max-users cells  buffer: enemies
  ... and so on ...

It would likely be completely fine to load this prelude:

  100,000,000 drop constant max-users
  : buffer: ( size "name" -- )  \ dynamic version
    allocate throw constant ;

The original purpose of BUFFER: was I gather so that such regions
could use special memory, on embedded platforms, rather than
dictionary space. But non-embedded Forths also have a dictionary space
vs. special memory distinction.

[toc] | [next] | [standalone]

#55091

On 2/24/17 8:59 PM, Julian Fondren wrote:
> Hello clf,
>
> Suppose you have hard limits and some mild configuration at compile
> time, with code like
>
>   [undefined] max-users [if]
>     100 constant max-users
>   [then]
>
>   create user-table  max-users user-size * allot
>   create enemies     max-users cells allot
>   ... and so on ...
>
> Not all software is permitted to use all available resources and then
> kill its host when under duress, and for such software it's nice to be
> able to say that when tuned a certain way it'll use at most some
> amount of memory.
>
>
> Now let's suppose someone says "I'd like to see how this code works
> with 100 million users". You would likely have to rewrite the above:
>
>   max-users user-size * allocate throw constant user-table
>   max-users cells allocate throw constant enemies
>
> It's just not as nice, is it?
>
>
> If you had used BUFFER: instead...
>
>   [undefined] max-users [if]
>     100 constant max-users
>   [then]
>
>   max-users user-size * buffer: user-table
>   max-users cells  buffer: enemies
>   ... and so on ...
>
> It would likely be completely fine to load this prelude:
>
>   100,000,000 drop constant max-users
>   : buffer: ( size "name" -- )  \ dynamic version
>     allocate throw constant ;
>
> The original purpose of BUFFER: was I gather so that such regions
> could use special memory, on embedded platforms, rather than
> dictionary space. But non-embedded Forths also have a dictionary space
> vs. special memory distinction.

Where BUFFER: space is allocated is very system-dependent. In hosted 
systems, it's typically in the dictionary. In embedded systems, it's 
usually in RAM, either initialized or uninitialized RAM; in any case, 
it's in data space (whether data space is integrated with dictionary or 
not).

I find your example baffling, as I have never seen multiple users 
managed in any way like your examples. In particular, all the multi-user 
Forths I have used set up users in a fixed way at compile time, with 
different sizes depending upon their intended use.

Cheers,
Elizabeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USAI

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

#55100

Julian Fondren <julian.fondren@gmail.com> writes:
>Hello clf,
>
>Suppose you have hard limits and some mild configuration at compile
>time, with code like
>
>  [undefined] max-users [if]
>    100 constant max-users
>  [then]
>
>  create user-table  max-users user-size * allot
>  create enemies     max-users cells allot
>  ... and so on ...
>
>Not all software is permitted to use all available resources and then
>kill its host when under duress, and for such software it's nice to be
>able to say that when tuned a certain way it'll use at most some
>amount of memory.
>
>
>Now let's suppose someone says "I'd like to see how this code works
>with 100 million users". You would likely have to rewrite the above:
>
>  max-users user-size * allocate throw constant user-table
>  max-users cells allocate throw constant enemies

Or you can keep the code and call the system with

gforth -m 4G ...

(assuming that 4GB of dictionary is enough); and you can use
--vm-commit (and configure the OS to avoid overcommitting memory) to
let the process die right away instead of only under duress.

- 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 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [standalone]

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

csiph-web