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

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

POCKET ?

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

Contents

  POCKET ? "HAA" <someone@microsoft.com> - 2017-04-21 11:55 +1000
    Re: POCKET ? Paul Rubin <no.email@nospam.invalid> - 2017-04-20 20:27 -0700
      Re: POCKET ? "HAA" <someone@microsoft.com> - 2017-04-21 13:46 +1000
        Re: POCKET ? "Elizabeth D. Rather" <erather@forth.com> - 2017-04-20 19:12 -1000
          Re: POCKET ? "HAA" <someone@microsoft.com> - 2017-04-21 21:56 +1000
            Re: POCKET ? hughaguilar96@gmail.com - 2017-04-21 18:19 -0700
              Re: POCKET ? The Beez <the.beez.speaks@gmail.com> - 2017-04-24 02:11 -0700
                Re: POCKET ? hughaguilar96@gmail.com - 2017-04-24 09:03 -0700
                  Re: POCKET ? foxaudioresearch@gmail.com - 2017-04-24 17:52 -0700
                    Re: POCKET ? hughaguilar96@gmail.com - 2017-04-24 19:00 -0700
                    Re: POCKET ? "HAA" <someone@microsoft.com> - 2017-05-05 21:10 +1000

#57681 — POCKET ?

AFAIK POCKET is a general purpose static buffer of approx 256 chars
used by system and applications.  Appears in SwiftForth and Win32F.
Anyone have further info - origins, usage etc ?

Many a time I've needed a temporary buffer e.g. to keep track of an
address at compile-time, but was loathe to create a variable.  POCKET
seems like the answer and can be allocated in high memory on start-up.
Don't have (or want) ALLOCATE.

[toc] | [next] | [standalone]

#57683

"HAA" <someone@microsoft.com> writes:
> Many a time I've needed a temporary buffer e.g. to keep track of an
> address at compile-time, but was loathe to create a variable.

PAD ?

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

#57685

Paul Rubin wrote:
> "HAA" <someone@microsoft.com> writes:
> > Many a time I've needed a temporary buffer e.g. to keep track of an
> > address at compile-time, but was loathe to create a variable.
>
> PAD ?

No good.  It moves as I'm compiling.

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

#57690

On 4/20/17 5:46 PM, HAA wrote:
> Paul Rubin wrote:
>> "HAA" <someone@microsoft.com> writes:
>>> Many a time I've needed a temporary buffer e.g. to keep track of an
>>> address at compile-time, but was loathe to create a variable.
>>
>> PAD ?
>
> No good.  It moves as I'm compiling.

The stack? That's what all the compiling words use. It really depends on 
how long you need to keep it. Maybe you could give us an example.

Cheers,
Elizabeth

-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#57715

Elizabeth D. Rather wrote:
> On 4/20/17 5:46 PM, HAA wrote:
> > Paul Rubin wrote:
> >> "HAA" <someone@microsoft.com> writes:
> >>> Many a time I've needed a temporary buffer e.g. to keep track of an
> >>> address at compile-time, but was loathe to create a variable.
> >>
> >> PAD ?
> >
> > No good.  It moves as I'm compiling.
>
> The stack? That's what all the compiling words use. It really depends on
> how long you need to keep it. Maybe you could give us an example.
>
> Cheers,
> Elizabeth

Temp store a value or string for later compilation e.g.

    :noname ... ; ( xt) pocket !    : FOO  ... [ pocket @ ] LITERAL ... ;

Other uses for POCKET.  It can be handy to have *two* string buffers to
play with e.g. recent 'splitting a string' thread.  Not keen on string stacks
for things which should be accomplished trivially.

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

#57760

On Friday, April 21, 2017 at 4:56:44 AM UTC-7, HAA wrote:
> Elizabeth D. Rather wrote:
> > On 4/20/17 5:46 PM, HAA wrote:
> > > Paul Rubin wrote:
> > >> "HAA" <someone@microsoft.com> writes:
> > >>> Many a time I've needed a temporary buffer e.g. to keep track of an
> > >>> address at compile-time, but was loathe to create a variable.
> > >>
> > >> PAD ?
> > >
> > > No good.  It moves as I'm compiling.
> >
> > The stack? That's what all the compiling words use. It really depends on
> > how long you need to keep it. Maybe you could give us an example.
> >
> > Cheers,
> > Elizabeth
> 
> Temp store a value or string for later compilation e.g.
> 
>     :noname ... ; ( xt) pocket !    : FOO  ... [ pocket @ ] LITERAL ... ;
> 
> Other uses for POCKET.  It can be handy to have *two* string buffers to
> play with e.g. recent 'splitting a string' thread.  Not keen on string stacks
> for things which should be accomplished trivially.

What if you have more than two strings? 

For example, how would you write a program that read a file into a linked list with each node containing a line of text from the file? I have READ-SEQ in LIST.4TH for this.

This whole thread is absurd! Holding strings in static buffers??? Nobody has done that since the 1970s, and it was a bad idea then too --- it is only done when RAM is in extreme shortage, and the program is very simple.

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

#57979

On Saturday, April 22, 2017 at 3:19:39 AM UTC+2, hughag...@gmail.com wrote:
> What if you have more than two strings? 
You use a circular buffer. That's what 4tH does. 4tH's string constants are kept in a separate segment, which can't be directly accessed by any of 4tH's words. In order to maintain compatibility with Forth, these strings are copied to the system buffer within 4tH's (user accessible) character segment - and the address they get there is the one which is returned. E.g. S" Hello world".

Sure, at one point in time those strings are overwritten, but that rarely poses any problems if you follow the rule "save clobbered strings somewhere else".

The consequence is though that this area called "PAD" may only be altered by the application programmer at his own risk. If you need a "user-PAD", define one yourself. 

https://sourceforge.net/p/forth-4th/wiki/Temporary%20strings/

Hans Bezemer

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

#57999

On Monday, April 24, 2017 at 2:11:14 AM UTC-7, The Beez wrote:
> On Saturday, April 22, 2017 at 3:19:39 AM UTC+2, hughag...@gmail.com wrote:
> > What if you have more than two strings? 
> You use a circular buffer. That's what 4tH does. 4tH's string constants are kept in a separate segment, which can't be directly accessed by any of 4tH's words. In order to maintain compatibility with Forth, these strings are copied to the system buffer within 4tH's (user accessible) character segment - and the address they get there is the one which is returned. E.g. S" Hello world".
> 
> Sure, at one point in time those strings are overwritten, but that rarely poses any problems if you follow the rule "save clobbered strings somewhere else".

I have had <CSTR in the novice-package since 2010. My <CSTR is loosely based on the circular buffer of strings that UR/Forth provided --- that worked pretty well. All in all, UR/Forth was the best Forth system of the 1990s! Even today, UR/Forth is more convenient for writing programs than VFX, but UR/Forth being only for MS-DOS makes it obsolete. Recently Raimond Dragomir upgraded my <CSTR, and this upgrade will be put in the next novice-package release.

My STRING-STACK.4TH is significantly better. That COW (copy-on-write) idea works quite well for boosting speed. Also, it uses less memory because it only allocates memory for strings in use. Also, it allows for strings of any size, not limited to 256 chars. Also, it provides a convenient way of accessing multiple strings (the stack-juggler words) so it is not necessary to hold the string addresses in variables as with <CSTR. All in all, STRING-STACK.4TH is very good --- I use <CSTR for a couple of words in STRING-STACK.4TH --- it does concatenation more efficiently, so it is useful for building a string by appending.

> The consequence is though that this area called "PAD" may only be altered by the application programmer at his own risk. If you need a "user-PAD", define one yourself. 

PAD is absolutely worthless. Putting PAD in the standard makes the Forth community look stupid. 

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

#58040

n Monday, April 24, 2017 at 12:03:23 PM UTC-4, hughag...@gmail.com wrote:
> 
> PAD is absolutely worthless. Putting PAD in the standard makes the Forth community look stupid.

I don't think PAD is worthless. I also made myself a string stack word set for myself, but PAD is simply a quick way to get at un-allocated dictionary space. 
If someone doesn't understand that they will find out fast enough. That's how 
Forth works. No training wheels.


B

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

#58046

On Monday, April 24, 2017 at 5:52:22 PM UTC-7, foxaudio...@gmail.com wrote:
> n Monday, April 24, 2017 at 12:03:23 PM UTC-4, hughag...@gmail.com wrote:
> > 
> > PAD is absolutely worthless. Putting PAD in the standard makes the Forth community look stupid.
> 
> I don't think PAD is worthless. I also made myself a string stack word set for myself, but PAD is simply a quick way to get at un-allocated dictionary space. 
> If someone doesn't understand that they will find out fast enough. That's how 
> Forth works. No training wheels.

Doesn't have a steering wheel either.

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

#58693

foxaudioresearch@gmail.com wrote:
> n Monday, April 24, 2017 at 12:03:23 PM UTC-4, hughag...@gmail.com wrote:
> >
> > PAD is absolutely worthless. Putting PAD in the standard makes the Forth community
> > look stupid.
>
> I don't think PAD is worthless. I also made myself a string stack word set for myself,
> but PAD is simply a quick way to get at un-allocated dictionary space. If someone
> doesn't understand that they will find out fast enough. That's how
> Forth works. No training wheels.
>
>
> B

The more I thought about it, the harder it became to justify assigning a fixed
buffer for temporary use.  Then I remembered the Forth trick of using the
free memory under the stack.  In ANS it would look something like this:

    here unused + 256 - value POCKET  ( -- adr )

Nor would it be limited to one buffer.

[toc] | [prev] | [standalone]

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

csiph-web