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

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

Region-based dynamic memory management idea

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

Contents

  Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-07 23:35 -0700
    Re: Region-based dynamic memory management idea Mark Wills <markwills1970@gmail.com> - 2014-06-08 03:20 -0700
      Re: Region-based dynamic memory management idea Mark Wills <markwills1970@gmail.com> - 2014-06-08 03:39 -0700
    Re: Region-based dynamic memory management idea anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-08 13:23 +0000
      Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-08 07:44 -0700
        Re: Region-based dynamic memory management idea anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-08 15:05 +0000
          Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-08 09:01 -0700
            Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-08 09:32 -0700
              Re: Region-based dynamic memory management idea Mark Wills <markwills1970@gmail.com> - 2014-06-08 10:08 -0700
                Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-08 21:05 -0700
                  Re: Region-based dynamic memory management idea Mark Wills <markwills1970@gmail.com> - 2014-06-09 06:47 -0700
                Re: Region-based dynamic memory management idea Alexander Skobelev <al.skobelev@gmail.com> - 2014-06-09 08:27 +0400
                  Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-08 22:42 -0700
                  Re: Region-based dynamic memory management idea Mark Wills <markwills1970@gmail.com> - 2014-06-09 06:53 -0700
                    Re: Region-based dynamic memory management idea Alexander Skobelev <al.skobelev@gmail.com> - 2014-06-10 09:24 +0400
            Re: Region-based dynamic memory management idea anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-09 14:55 +0000
          Re: Region-based dynamic memory management idea "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-08 21:10 -0400
            Re: Region-based dynamic memory management idea "Elizabeth D. Rather" <erather@forth.com> - 2014-06-08 16:55 -1000
            Re: Region-based dynamic memory management idea visualforth@rocketmail.com - 2014-06-08 20:34 -0700
              Re: Region-based dynamic memory management idea "Elizabeth D. Rather" <erather@forth.com> - 2014-06-08 18:55 -1000
                Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-08 22:50 -0700
                  Re: Region-based dynamic memory management idea "Elizabeth D. Rather" <erather@forth.com> - 2014-06-09 12:54 -1000
                    Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-09 17:33 -0700
                      Re: Region-based dynamic memory management idea Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-10 04:37 -0500
                    Re: Region-based dynamic memory management idea bruce.mcfarling@gmail.com - 2014-06-19 13:38 -0700
                Re: Region-based dynamic memory management idea albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-09 12:40 +0000
            Re: Region-based dynamic memory management idea Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-09 05:21 -0500
            Re: Region-based dynamic memory management idea anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-10 16:50 +0000
              Re: Region-based dynamic memory management idea "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-10 17:36 -0400
              Re: Region-based dynamic memory management idea bruce.mcfarling@gmail.com - 2014-06-14 09:52 -0700
          Re: Region-based dynamic memory management idea humptydumpty <ouatubi@gmail.com> - 2014-06-11 03:44 -0700
            Re: Region-based dynamic memory management idea anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-11 16:33 +0000
              Re: Region-based dynamic memory management idea humptydumpty <ouatubi@gmail.com> - 2014-06-12 14:01 -0700
                Re: Region-based dynamic memory management idea anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-13 16:42 +0000
                  Re: Region-based dynamic memory management idea humptydumpty <ouatubi@gmail.com> - 2014-06-13 13:45 -0700
                    Re: Region-based dynamic memory management idea anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-14 09:56 +0000
                      Re: Region-based dynamic memory management idea humptydumpty <ouatubi@gmail.com> - 2014-06-14 06:29 -0700
                  Re: Region-based dynamic memory management idea Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-06-16 00:19 +0100
      Re: Region-based dynamic memory management idea Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-08 21:47 +0200
        Re: Region-based dynamic memory management idea anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-09 15:24 +0000
          Re: Region-based dynamic memory management idea Mark Wills <markwills1970@gmail.com> - 2014-06-09 09:10 -0700
            Re: Region-based dynamic memory management idea anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-10 16:09 +0000
              Re: Region-based dynamic memory management idea BruceMcF <agila61@netscape.net> - 2014-06-14 14:04 -0700
          Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-09 10:02 -0700
            Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-09 10:08 -0700
              Re: Region-based dynamic memory management idea anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-10 15:31 +0000
                Re: Region-based dynamic memory management idea BruceMcF <agila61@netscape.net> - 2014-06-14 13:27 -0700
            Re: Region-based dynamic memory management idea anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-10 15:51 +0000
          Re: Region-based dynamic memory management idea bruce.mcfarling@gmail.com - 2014-06-14 09:09 -0700
            Re: Region-based dynamic memory management idea mhx@iae.nl - 2014-06-14 09:49 -0700
              Re: Region-based dynamic memory management idea bruce.mcfarling@gmail.com - 2014-06-14 10:09 -0700
              Re: Region-based dynamic memory management idea albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-14 19:36 +0000
                Re: Region-based dynamic memory management idea mhx@iae.nl - 2014-06-14 23:06 -0700
                  Re: Region-based dynamic memory management idea albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-15 12:33 +0000
                    Re: Region-based dynamic memory management idea BruceMcF <agila61@netscape.net> - 2014-06-15 12:11 -0700
                      Re: Region-based dynamic memory management idea albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-15 19:38 +0000
    Re: Region-based dynamic memory management idea visualforth@rocketmail.com - 2014-06-08 17:42 -0700
      Re: Region-based dynamic memory management idea anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-09 15:43 +0000
      Re: Region-based dynamic memory management idea BruceMcF <agila61@netscape.net> - 2014-06-14 13:08 -0700
        Re: Region-based dynamic memory management idea "Elizabeth D. Rather" <erather@forth.com> - 2014-06-14 11:54 -1000
          Re: Region-based dynamic memory management idea BruceMcF <agila61@netscape.net> - 2014-06-15 12:36 -0700
        Re: Region-based dynamic memory management idea albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-15 11:59 +0000
          Re: Region-based dynamic memory management idea BruceMcF <agila61@netscape.net> - 2014-06-15 12:55 -0700
            Re: Region-based dynamic memory management idea BruceMcF <agila61@netscape.net> - 2014-06-15 13:02 -0700
    Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-12 10:26 -0700
    Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-19 22:57 -0700
      Re: Region-based dynamic memory management idea Mark Wills <markwills1970@gmail.com> - 2014-06-20 07:40 +0100
        Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-20 00:14 -0700
          Re: Region-based dynamic memory management idea bruce.mcfarling@gmail.com - 2014-06-20 20:17 -0700
            Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-21 08:51 -0700
              Re: Region-based dynamic memory management idea bruce.mcfarling@gmail.com - 2014-06-21 10:07 -0700
                Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-21 11:10 -0700
                  Re: Region-based dynamic memory management idea bruce.mcfarling@gmail.com - 2014-06-21 12:17 -0700
                    Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-21 12:39 -0700
                      Re: Region-based dynamic memory management idea bruce.mcfarling@gmail.com - 2014-06-21 13:54 -0700
                        Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-21 14:53 -0700
                          Re: Region-based dynamic memory management idea albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-22 13:58 +0000
                            Re: Region-based dynamic memory management idea BruceMcF <agila61@netscape.net> - 2014-06-22 15:26 -0700
    Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-21 13:25 -0700
    Re: Region-based dynamic memory management idea Roger Levy <roger.levy@gmail.com> - 2014-06-25 14:55 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#31316

> If this is your project, you control pad usage and can set rules 
> 
> according to your needs. If it's a group project, the group can :-) 
> 
> Systems aren't supposed to use PAD; it's a programmer convenience.
> 

To add to this point that you definitely don't have to use it: PAD is too unstructured, even for me. If I used it I'd likely completely forget about it in a month, use it again in a different file and wonder why everything suddenly breaks.

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

#31354

On 6/8/14 7:50 PM, Roger Levy wrote:
>
>> If this is your project, you control pad usage and can set rules
>>
>> according to your needs. If it's a group project, the group can :-)
>>
>> Systems aren't supposed to use PAD; it's a programmer convenience.
>>
>
> To add to this point that you definitely don't have to use it: PAD is too unstructured, even for me. If I used it I'd likely completely forget about it in a month, use it again in a different file and wonder why everything suddenly breaks.
>

It's really best used for a very temporary situation, such as a place to 
put a string till you decide what to do with it next, or a string being 
used as a search-string, etc. If the use of PAD is confined to a local 
region (e.g. one definition or a few closely-coupled ones) it's quite 
manageable and saves a lot of allocation/deallocation steps.

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]

#31355

> It's really best used for a very temporary situation, such as a place to 
> 
> put a string till you decide what to do with it next, or a string being 
> 
> used as a search-string, etc. If the use of PAD is confined to a local 
> 
> region (e.g. one definition or a few closely-coupled ones) it's quite 
> 
> manageable and saves a lot of allocation/deallocation steps.
> 

I'm willing to wager that my comfort threshold regarding structuredness is probably just a notch above yours - I would definitely find a way to screw this up.  In my projects I try to keep shortcuts like this localized with a quick in-and-out but with things that are much safer, like my circular string buffer.  I have never been able to judge how low-level is too low-level a word to be using PAD in - know what I mean?  As another example, I have the A register in my toolbelt, but I ended up using a word I defined, A!> , which allows words that use the A register to be re-entrant.  I don't even dare use A! except after a A!> in the same word because I've screwed that up enough times. :P

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

#31368

Roger Levy <roger.levy@gmail.com> wrote:
> Elizabeth Rather wrote:
>> [PAD is] really best used for a very temporary situation, such as a
>> place to put a string till you decide what to do with it next, or a
>> string being used as a search-string, etc. If the use of PAD is
>> confined to a local region (e.g. one definition or a few
>> closely-coupled ones) it's quite manageable and saves a lot of
>> allocation/deallocation steps.

> I'm willing to wager that my comfort threshold regarding
> structuredness is probably just a notch above yours - I would
> definitely find a way to screw this up.  In my projects I try to
> keep shortcuts like this localized with a quick in-and-out but with
> things that are much safer, like my circular string buffer.  I have
> never been able to judge how low-level is too low-level a word to be
> using PAD in - know what I mean?

I wonder if this is more of a design thing.  PAD is (should be,
anyway) a task-local buffer, and tasks are often be pretty small.  In
such cases, it's not at all hard to determine that PAD is being used
safely.  Of course, this all depends on the application.

Andrew.

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

#31669

On Monday, June 9, 2014 6:54:00 PM UTC-4, Elizabeth D. Rather wrote:
> On 6/8/14 7:50 PM, Roger Levy wrote:
>> To add to this point that you definitely don't have to use
>> it: PAD is too unstructured, even for me. If I used it I'd
>> likely completely forget about it in a month, use it again
>> in a different file and wonder why everything suddenly
>> breaks.

> It's really best used for a very temporary situation, such
> as a place to put a string till you decide what to do with
> it next, or a string being used as a search-string, etc. If
> the use of PAD is confined to a local region (e.g. one
> definition or a few closely-coupled ones) it's quite 
> manageable and saves a lot of allocation/deallocation steps.

Yes ~ and it can be very handy to use as the stand-in caller-side buffer when developing a word where the caller hands the buffer over.

I've get a situation where I use free space inside a working text stack / text result string allotment for things like swapping location of text strings in the text stack. The text swaps can work in chunks smaller than the full size being swapped ... but at a penalty in extra MOVEs, so if the free space gets down to a few chars, it can really bog down. So ``free$'' is a buffer that is used instead when the free space gets very small:

[UNDEFINED] free$ [IF]
   CREATE free$-buffer 16 CHARS ALLOT
   : free$ ( -- ca u ) free$-buffer 16 ;
[THEN]

Up above that in the file is:

\ Uncomment to use PAD as a working buffer:
\     : free$ ( -- ca u ) PAD 32 ;

If using the source system-side, I can let it define free$ or allocate or allot a larger free$ for it in advance of loading.

If using the source user-side, I can also uncomment the PAD definition if I want, or define free$ for myself using PAD. Or on a forth system providing a stable ANS WORD buffer for backward compatibility only, could use the WORD buffer for free$.

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

#31324

In article <WNGdnYaex-DLowjOnZ2dnUVZ_vKdnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 6/8/14 5:34 PM, visualforth@rocketmail.com wrote:
>> On Sunday, June 8, 2014 9:10:58 PM UTC-4, Rod Pemberton wrote:
>>
>>>   ...  Who needs string concatenation in Forth when you can
>>> group things together with colon definitions?  I.e., if the strings aren't
>>> useful separately, you'd create a new string in Forth.  Who needs string
>>> concatenation in Forth when you can create a new colon definition?
>...
>>
>> Handling of strings is easy this way, and it can't be done - or is
>very complicated - with colon definitions, because I cannot change the
>content of a colon definition.
>
>I agree. A string is inherently a data object, not a function. Colon
>definitions are really designed for functions. Forth is particularly
>good at letting you design and manage data objects as you wish, and it's
>best not to confuse the two.
>
>> The only problem is the pad usage, because if different words use this
>$+ command, I need to save the string inside the word which uses $+
>
>If this is your project, you control pad usage and can set rules
>according to your needs. If it's a group project, the group can :-)
>Systems aren't supposed to use PAD; it's a programmer convenience.

A sufficient solution is
    CREATE _PAD 1024 ALLOT
and use _PAD instead within your system 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."
>==================================================
-- 
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]

#31321

Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> On Sun, 08 Jun 2014 11:05:36 -0400, Anton Ertl  
> <anton@mips.complang.tuwien.ac.at> wrote:
> 
>> str+ ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 )
>> It has to allocate memory for the result.
> 
> Wow, that really looks like the C way of string concatenation to me ...
> Well, it's a Forth like attempt to do the same thing, anyway.

It's string concatenation.  You put one string at the end of the
other.  It's not the C way of doing string concatentation, it's just
concatentation.

> str+ would definately want to allocate new space from the sum of the
> sizes for the prior space, instead of being passed a handle.  I'm
> not sure how you'd go about freeing and re-using the space for the
> original two strings.  I.e., str+ would seem to cause a memory leak
> in the dictionary, but so does defining new definitions.  I quess it
> could be argued as to whether it's truly a memory leak or just
> additional allocation of dictionary space since the Forth dictionary
> is designed as a heap.

The Forth dictionary isn't a heap: it's usually a stack.

> Isn't the Forth way to leave both strings exactly where they already
> are?  I.e., if the strings are to be printed, you'd create a new
> word in Forth to print both ...  Who needs string concatenation in
> Forth when you can group things together with colon definitions?
> I.e., if the strings aren't useful separately, you'd create a new
> string in Forth.  Who needs string concatenation in Forth when you
> can create a new colon definition?

If you need to concatenate the strings, then you have to put the
result somewhere.

> Oh, you're trying to optimize Forth again aren't you?  Or, as Hugh
> would say, you're trying to convert Forth into C, yet again.

What has any of this to do with C?  Region-based memory management
isn't specific to any language.  It's not part of the standard C
library.

Andrew.

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

#31376

"Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>On Sun, 08 Jun 2014 11:05:36 -0400, Anton Ertl  
><anton@mips.complang.tuwien.ac.at> wrote:
>
>> str+ ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 )
>> It has to allocate memory for the result.
>
>Wow, that really looks like the C way of string concatenation to me ...

Really?  *The* C way of string concatenation is strcat(), and a Forth
stack effect for that function would be:

( dest src -- dest )

where dest and src represent zero-terminated strings.  I think you
could not get much farther from STR+ than with strcat(), and still
have a string concatenation word/function.  In particular and relevant
to the original topic, STR+ allocates memory, and strcat does not.

>I'm not
>sure how you'd go about freeing and re-using the space for the
>original two strings.

Than maybe you should give up on C and convert to Java.  Or do you
know how you free and reuse the src operand when using strcat()?

- 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 2014: http://www.euroforth.org/ef14/

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

#31381

On Tue, 10 Jun 2014 12:50:32 -0400, Anton Ertl  
<anton@mips.complang.tuwien.ac.at> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> writes:
>> On Sun, 08 Jun 2014 11:05:36 -0400, Anton Ertl
>> <anton@mips.complang.tuwien.ac.at> wrote:

>>> str+ ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 )
>>> It has to allocate memory for the result.
>>
>> Wow, that really looks like the C way of string concatenation to me ...
>
> Really?  *The* C way of string concatenation is strcat(), and a Forth
> stack effect for that function would be:
>
> ( dest src -- dest )
>
> where dest and src represent zero-terminated strings.

Yes, you must disregard the termination method to compare the two.
So, we drop the length from Forth:

str+ ( c-addr1 c-addr2 -- c-addr3 )

Now, they look much closer.

If c-addr1 is sufficiently large, then c-addr1 could be equal to
c-addr3, i.e., no allocation required.

str+ ( dest src -- dest )

In which case, they're now equal except for termination.

Of course, Forth complicates string termination, so we must provide
additional information to the Forth word, re-complicating things:

str+ ( dest u1 src u2 -- dest u3 )

> I think you
> could not get much farther from STR+ than with strcat(), and still
> have a string concatenation word/function.

They're both concatenation, so they're closer than not ...

> In particular and relevant
> to the original topic, STR+ allocates memory, and strcat does not.

So, STR+ is not identical and comprises roughly about five C function
calls ... 2 strlen's, 1 malloc, 1 strcpy, 1 strcat and some miscellaneous
arithmetic. It's still much closer to the C way of doing things.  The
point was it doesn't appear to be the Forth way.  The Forth way would
be colon definitions or some manipulation of the parser and/or writing
into the input stream/buffer to use ." to define the concatenated string.

>> I'm not
>> sure how you'd go about freeing and re-using the space for the
>> original two strings.
>
> Than maybe you should give up on C and convert to Java.

You snipped so much, I think you replied to something else here...

I was talking about the space already allocated in a typical Forth
dictionary for "c-addr1 u1" and "c-addr2 u2".  AFAIK, using the
standard HERE DP ALLOT Forth mechanism, there is no way in Forth to
reclaim just the space for those two strings.  Those two strings
will be packed inbetween other Forth words.  So, you'd need extra
functionality, i.e., a garbage collector or paging, to reclaim the
space.  So, without the ability to reclaim that space, the best you
can do is add another string to the dictionary, i.e., "c-addr3 u3",
causing additional consumption of stack space, which could be
considered a memory leak.

> Or do you
> know how you free and reuse the src operand when using strcat()?

It's not needed.  As you pointed out, C's allocation and concatenation
mechanisms are purely separate.  I.e., the src operand is assumed
to be sufficiently large than strcat can safely append.  It's the
programmer's job to make sure that it is large enough.  Of course,
some programmers fail to take care of the details in C, which is also
a strong argument against using Forth.  If you were to do the same
thing in Forth using STR+, i.e., extra large allocation for "c-addr1 u1",
then I'd claim that's even stronger support that you've embraced the
C way.


Rod Pemberton

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

#31536

On Tuesday, June 10, 2014 12:50:32 PM UTC-4, Anton Ertl wrote:
> Really?  *The* C way of string concatenation is strcat(), and a Forth 
> stack effect for that function would be:

> ( dest src -- dest )
 
> where dest and src represent zero-terminated strings.  I think you 
> could not get much farther from STR+ than with strcat(), and still
> have a string concatenation word/function.  In particular and relevant
> to the original topic, STR+ allocates memory, and strcat does not.

I can think of one approach that is a little further away. In this approach there is a token stack, "T$", which is organized in memory as:

T$[bottom]: pointer to T$[1]
T$[top]: pointer to T$[n]
R$[end]: pointer to first char free in R
R$-base: {result text copied to result text pool here} ...
T$-base: {token text copied to text pool here} ...
...
T$[n]: pointer to free space at end of T$-base
T$[n-1]: pointer to start of top string in text pool
T$[n-2]: pointer to start of second string in text pool
...
T$[1]: pointer to T$-base, first string in text pool

And the content of the T$-stack variable is the address of T$[bottom].

So the two concatenates are, first, token concatenate
\ >T$ ( ca u -- || TS: -- str ) push token onto top of stack
\ T$+ ( TS: str1 str2 -- str3 ) concatenate str1 and str2
   >T$ >T$ T$+

... and result string concatenate:
\ >R$ ( ca u -- ) append string to result string
\ R$0 ( -- ) reset result string to null string
   R$0 >R$ >R$

... or, working with a token stack other than the current one:
   MY-STR SWAP-STR >R
      R$0 >R$ >R$
   R> STR ! ...

At present its allotted memory and abort on overflow, which is the result of the end of the token string and the top of the string pointer stack attempting to cross (when the R$ buffer is too small, the T$ buffer attempts to move up to accommodate, so all not enough space problems, whether not enough R$ text space, not enough T$ text space, or not enough T$ stack pointer space resolve down to the end of the T$ pool and the bottom of the T$ stack trying to cross).

But if shifted to allocate and RESIZE on overflow, it would be a case of persisting data structure that could require an unanticipated amount of new space at an unanticipated time if applied to an application with substantially more space requirements than a process considered, such as taking a base directory, subdirectory and filename process set up for modest length directory and file names and modest depth trees and applying them to some auto-generated "make it unique no matter how long it may be" namespace and a much deeper directory tree.

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

#31401

On Sunday, June 8, 2014 6:05:36 PM UTC+3, Anton Ertl wrote:
> Roger Levy <...> writes:
> 
> >Anton, actually I was intrigued to research into regions because of your ta=
> 
> >lk.=20
> 
> >
> 
> >> The main problem I see with this in Forth is that you have to pass the
> 
> >> region handle around.  But I think I have solved that by having a
> 
> >> current-region context-variable.  I.e.,
> 
> >> basic-block [: bla bla ;] with-region
> 
> >
> 
> >Why does the handle need to be passed around?  Assuming that no data is mov=
> 
> >ed around by the component, which is how I'd do it, handles should only be =
> 
> >need to be stored in a variable or field.
> 
> 
> 
> Consider
> 
> 
> 
> str+ ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 )
> 
> 
> 
> It has to allocate memory for the result.  Which region handle should
> 
> it use?  Or should I pass a region-handle to it?
> 
> 
> 
> str+ ( c-addr1 u1 c-addr2 u2 region-id -- c-addr3 u3 )
> 
> 
> 
> And the same goes for any general-purpose word that allocates memory:
> 
> If you want to allocte memory from regions, you somehow have to tell
> 
> it which region to allocate from.  If you pass it explicitly, as in
> 
> the second str+, regions become cumbersome.  If you use global
> 
> variables (without managing them at a higher level), your code is only
> 
> useful for this one program (and even there changes might requires
> 
> changing the region handles in a number of places).
> 
> 
> 
> - 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 2014: http://www.euroforth.org/ef14/

Hi!

After thinking about how to use whatever resources from an OS
, acquired-used-then-released be it memory, file-descriptors, etc ...

Maybe we should not mix *acquiring/releasing* resources with *using* them?
Maybe we should postpone until latest possible acquiring/releasing resources 
(define words for them and using them), like using values in physics-problems
only when formulas for solving are all ready worked out?

Have a nice day,
humptydumpty

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

#31410

humptydumpty <ouatubi@gmail.com> writes:
>On Sunday, June 8, 2014 6:05:36 PM UTC+3, Anton Ertl wrote:
>After thinking about how to use whatever resources from an OS
>, acquired-used-then-released be it memory, file-descriptors, etc ...
>
>Maybe we should not mix *acquiring/releasing* resources with *using* them?
>Maybe we should postpone until latest possible acquiring/releasing resources 
>(define words for them and using them), like using values in physics-problems
>only when formulas for solving are all ready worked out?

That's too abstract for me.  What would the effect be on how we should
write code?

- 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 2014: http://www.euroforth.org/ef14/

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

#31463

On Wednesday, June 11, 2014 7:33:50 PM UTC+3, Anton Ertl wrote:
> humptydumpty <...> writes:
> 
> >On Sunday, June 8, 2014 6:05:36 PM UTC+3, Anton Ertl wrote:
> 
> >After thinking about how to use whatever resources from an OS
> 
> >, acquired-used-then-released be it memory, file-descriptors, etc ...
> 
> >
> 
> >Maybe we should not mix *acquiring/releasing* resources with *using* them?
> 
> >Maybe we should postpone until latest possible acquiring/releasing resources 
> 
> >(define words for them and using them), like using values in physics-problems
> 
> >only when formulas for solving are all ready worked out?
> 
> 
> 
> That's too abstract for me.  What would the effect be on how we should
> 
> write code?
> 
> 
> 
> - 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 2014: http://www.euroforth.org/ef14/


Hi!

First thing, is just an opinion. It could be a wrong one:

Looking at first description of str+ ( ca1 u1 ca2 u2 -- ca3 u3 ;allocate
 memory and concatenate STRING1 STRING2 into allocated memory,return
 BUFFER ).  str+ do too much: concatenate strings + acquire heap resource
 from OS.  More, the place where and time when that heap will be freed
 is unknown.

As a digression, that resembles (my past)novice use of variables: define,
store values in them knowing that somewhere sometime they will be used.

Maybe a way of do this is something like that:
: str+ ( ca1 u1 ca2 u2 cad ud -- ;concatenate STRING1 STRING2 into
 DESTINATION buffer)  string!+ string!+ 2drop ;

: string!+ ( cas us cad ud -- cad+us ud-us ;safely copy SOURCE into DESTINATION,
return FREE space from destination ) ... ;
...
And continue to develop DSL for problem to solve until the logic of 
problem is nearly done; then write user-words with care to 
acquiring/releasing-resources. Also at user-words level, use of variables
could be beneficial. 

For keeping together acquisition and release of resources,
some words would help:

: with          H( ..xt resource -- ..exception resource )
        >R CATCH R>
;
: with-dict     H( .. u xt[..a n--..] -- .. )
...
;
: with-heap     H( .. u xt[..a n--..] -- .. )
        OVER ALLOCATE  THROW    ( u xt a )
        2>R R@ SWAP 2R> with    ( ..exc a )
        FREE                    ( ..exc exc' )
        SWAP THROW THROW
;
: file-with     H( .. xt[..fd--..] ca u wfam -- .. )
...
;
...
Please remark that xt has stack-effect between [ ] .

Just for flavor:

s" alfa" s" betalog"  4dup nip + nip :noname  2dup 2>R str+ 2R> dump ; with-heap

I hope I make myself more clear.
 
Have a nice day,
humptydumpty

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

#31492

humptydumpty <ouatubi@gmail.com> writes:
>Looking at first description of str+ ( ca1 u1 ca2 u2 -- ca3 u3 ;allocate
> memory and concatenate STRING1 STRING2 into allocated memory,return
> BUFFER ).  str+ do too much: concatenate strings + acquire heap resource
> from OS.  More, the place where and time when that heap will be freed
> is unknown.
>
>As a digression, that resembles (my past)novice use of variables: define,
>store values in them knowing that somewhere sometime they will be used.
>
>Maybe a way of do this is something like that:
>: str+ ( ca1 u1 ca2 u2 cad ud -- ;concatenate STRING1 STRING2 into
> DESTINATION buffer)  string!+ string!+ 2drop ;

Yes, that kind of interface is more common in Forth, especially in the
standard (e.g., READ-LINE, or SUBSTITUTE), because ALLOCATE etc. is
optional in the standard.

I think it's a bad interface: you don't know how to size the buffer
(well, for STR+ it's possible to know in advance, but for other words
it's not or at least it's much too cumbersome; it's even quite
cumbersome for STR+), and you have to report the case when the buffer
is not big enough (which your STR+ does not do), and the client of the
word has to write code to handle this case.  All of which makes
working with this interface style quite arduous.  As a result, we
regularly get new string packages.

Note that we don't use this kind of style for working with numbers,
there we just have ( n1 n2 -- n ).

I think that a STR+ ( c-addr1 u1 c-addr2 u2 -- c-addr u ) is an
improvement, even though the requirement to keep track of the
allocated string is a burden.


Combining that interface style with regions (with an implicitly-passed
current region) is a further improvement.  Getting back to your
statement, there we have a separation of allocation/release decisions
and use (although different from what you had in mind).  The word that
does the do-region makes a part of the allocation and all of the
release decision, and STR+ does another part of the allocation, plus
the use.  And I think that part of the allocation (how many bytes to
allocate) should be in STR+, because that part depends on the data,
and not on the context.

>For keeping together acquisition and release of resources,
>some words would help:
>
>: with          H( ..xt resource -- ..exception resource )
>        >R CATCH R>
>;
>: with-dict     H( .. u xt[..a n--..] -- .. )
>...
>;
>: with-heap     H( .. u xt[..a n--..] -- .. )
>        OVER ALLOCATE  THROW    ( u xt a )
>        2>R R@ SWAP 2R> with    ( ..exc a )
>        FREE                    ( ..exc exc' )
>        SWAP THROW THROW
>;
>: file-with     H( .. xt[..fd--..] ca u wfam -- .. )
>...
>;
>...
>Please remark that xt has stack-effect between [ ] .
>
>Just for flavor:
>
>s" alfa" s" betalog"  4dup nip + nip :noname  2dup 2>R str+ 2R> dump ; with-heap

Ok, that looks better than other properly scaffolded uses of this kind
of interface, but that's because for str+ you can determine the buffer
size in advance, and you deallocate the string quickly.  That's also
easy to do with an ALLOCATEing STR+ combined with FREE.

s" alfa" s" betalog" str+ over swap dump free throw

Regions support things that are cumbersome with FREE, but anyway,
here's a version of that with regions:

s" alfa" s" betalog" :noname str+ dump ; do-with-region

- 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 2014: http://www.euroforth.org/ef14/

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

#31499

On Friday, June 13, 2014 7:42:17 PM UTC+3, Anton Ertl wrote:
> humptydumpty <...> writes:
> 
> >Looking at first description of str+ ( ca1 u1 ca2 u2 -- ca3 u3 ;allocate
> 
> > memory and concatenate STRING1 STRING2 into allocated memory,return
> 
> > BUFFER ).  str+ do too much: concatenate strings + acquire heap resource
> 
> > from OS.  More, the place where and time when that heap will be freed
> 
> > is unknown.
> 
> >
> 
> >As a digression, that resembles (my past)novice use of variables: define,
> 
> >store values in them knowing that somewhere sometime they will be used.
> 
> >
> 
> >Maybe a way of do this is something like that:
> 
> >: str+ ( ca1 u1 ca2 u2 cad ud -- ;concatenate STRING1 STRING2 into
> 
> > DESTINATION buffer)  string!+ string!+ 2drop ;
> 
> 
> 
> Yes, that kind of interface is more common in Forth, especially in the
> 
> standard (e.g., READ-LINE, or SUBSTITUTE), because ALLOCATE etc. is
> 
> optional in the standard.
> 


HI!
> 
> I think it's a bad interface: you don't know how to size the buffer
> 
> (well, for STR+ it's possible to know in advance, but for other words
> 
> it's not or at least it's much too cumbersome; it's even quite
> 
> cumbersome for STR+), and you have to report the case when the buffer
> 
> is not big enough (which your STR+ does not do), and the client of the
> 
> word has to write code to handle this case.  All of which makes
> 
> working with this interface style quite arduous.  As a result, we
> 
> regularly get new string packages.
> 

I never used a word like STR+ , I wrote that definition only to provide
an alternative. Instead, regularly I use STRING!+ which return
free part of buffer that is the form of pair 'address 0' when buffer is full.
That is enough information to know when intervention is needed.
Also STRING!+ is safe, i.e. if somehow source is bigger than free buffer
only length of free buffer will be copied from source, and of course
return also pair 'address 0'.

> 
> 
> Note that we don't use this kind of style for working with numbers,
> 
> there we just have ( n1 n2 -- n ).
> 
> 
> 
> I think that a STR+ ( c-addr1 u1 c-addr2 u2 -- c-addr u ) is an
> 
> improvement, even though the requirement to keep track of the
> 
> allocated string is a burden.
> 
> 
> 
> 
> 
> Combining that interface style with regions (with an implicitly-passed
> 
> current region) is a further improvement.  Getting back to your
> 
> statement, there we have a separation of allocation/release decisions
> 
> and use (although different from what you had in mind).  The word that
> 
> does the do-region makes a part of the allocation and all of the
> 
> release decision, and STR+ does another part of the allocation, plus
> 
> the use.  And I think that part of the allocation (how many bytes to
> 
> allocate) should be in STR+, because that part depends on the data,
> 
> and not on the context.
> 
> 
> 
> >For keeping together acquisition and release of resources,
> 
> >some words would help:
> 
> >
> 
> >: with          H( ..xt resource -- ..exception resource )
> 
> >        >R CATCH R>
> 
> >;
> 
> >: with-dict     H( .. u xt[..a n--..] -- .. )
> 
> >...
> 
> >;
> 
> >: with-heap     H( .. u xt[..a n--..] -- .. )
> 
> >        OVER ALLOCATE  THROW    ( u xt a )
> 
> >        2>R R@ SWAP 2R> with    ( ..exc a )
> 
> >        FREE                    ( ..exc exc' )
> 
> >        SWAP THROW THROW
> 
> >;
> 
> >: file-with     H( .. xt[..fd--..] ca u wfam -- .. )
> 
> >...
> 
> >;
> 
> >...
> 
> >Please remark that xt has stack-effect between [ ] .
> 
> >
> 
> >Just for flavor:
> 
> >
> 
> >s" alfa" s" betalog"  4dup nip + nip :noname  2dup 2>R str+ 2R> dump ; with-heap
> 
> 
> 
> Ok, that looks better than other properly scaffolded uses of this kind
> 
> of interface, but that's because for str+ you can determine the buffer
> 
> size in advance, and you deallocate the string quickly.  That's also
> 
> easy to do with an ALLOCATEing STR+ combined with FREE.
> 

How STR+ know how much will allocate?  It must calculate his memory needs.
In my approach memory size is calculated explicitly. In STR+ case, is burried
inside.  Is there a clear winner?


> 
> 
> s" alfa" s" betalog" str+ over swap dump free throw
>

Suppose that instead of 'dump' is a word that throw an exception,
then we end up with a memory leak.

 
> 
> 
> Regions support things that are cumbersome with FREE, but anyway,
> 
> here's a version of that with regions:
> 
> 
> 
> s" alfa" s" betalog" :noname str+ dump ; do-with-region
> 

Where is freed space allocated by STR+ ? 

> 
> - 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 2014: http://www.euroforth.org/ef14/

Have a nice day,
humptydumpty

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

#31526

humptydumpty <ouatubi@gmail.com> writes:
>I never used a word like STR+ , I wrote that definition only to provide
>an alternative. Instead, regularly I use STRING!+ which return
>free part of buffer that is the form of pair 'address 0' when buffer is full.
>That is enough information to know when intervention is needed.
>Also STRING!+ is safe, i.e. if somehow source is bigger than free buffer
>only length of free buffer will be copied from source, and of course
>return also pair 'address 0'.

Yes, that's pretty good for a non-allocating interface, but you still
have to wrap it in code that checks the remaining size and deals with
the buffer-may-be-too-small situation.

>How STR+ know how much will allocate?  It must calculate his memory needs.
>In my approach memory size is calculated explicitly. In STR+ case, is burried
>inside.  Is there a clear winner?

Sure, doing it inside STR+ is superior.  Then this computation is only
needed in one place; if you do it outside, you need to repeat it at
every place that calls STR+.

>> s" alfa" s" betalog" str+ over swap dump free throw
>>
>
>Suppose that instead of 'dump' is a word that throw an exception,
>then we end up with a memory leak.

Yes, so if you want to avoid that, you may wrap that word in a CATCH.
Or you use regions (at least my regions package will include words
that deallocate the region on exceptions).

>> Regions support things that are cumbersome with FREE, but anyway,
>> 
>> here's a version of that with regions:
>> 
>> 
>> 
>> s" alfa" s" betalog" :noname str+ dump ; do-with-region
>> 
>
>Where is freed space allocated by STR+ ? 

STR+ allocates from the current region,

do-with-region ( ... xt -- ... )

creates the region and makes it current, executes the xt, and frees
the region.  Does that answer your question?

- 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 2014: http://www.euroforth.org/ef14/

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

#31530

On Saturday, June 14, 2014 12:56:58 PM UTC+3, Anton Ertl wrote:
> humptydumpty <...> writes:
> 
> >I never used a word like STR+ , I wrote that definition only to provide
> 
> >an alternative. Instead, regularly I use STRING!+ which return
> 
> >free part of buffer that is the form of pair 'address 0' when buffer is full.
> 
> >That is enough information to know when intervention is needed.
> 
> >Also STRING!+ is safe, i.e. if somehow source is bigger than free buffer
> 
> >only length of free buffer will be copied from source, and of course
> 
> >return also pair 'address 0'.
> 
> 
> 
> Yes, that's pretty good for a non-allocating interface, but you still
> 
> have to wrap it in code that checks the remaining size and deals with
> 
> the buffer-may-be-too-small situation.
> 
> 
> 
> >How STR+ know how much will allocate?  It must calculate his memory needs.
> 
> >In my approach memory size is calculated explicitly. In STR+ case, is burried
> 
> >inside.  Is there a clear winner?
> 
>
> 
> Sure, doing it inside STR+ is superior.  Then this computation is only
> 
> needed in one place; if you do it outside, you need to repeat it at
> 
> every place that calls STR+.
> 
> 
> 
> >> s" alfa" s" betalog" str+ over swap dump free throw
> 
> >>
> 
> >
> 
> >Suppose that instead of 'dump' is a word that throw an exception,
> 
> >then we end up with a memory leak.
> 
> 
> 
> Yes, so if you want to avoid that, you may wrap that word in a CATCH.
> 
> Or you use regions (at least my regions package will include words
> 
> that deallocate the region on exceptions).
> 
>


Hi!
 
> 
> >> Regions support things that are cumbersome with FREE, but anyway,
> 
> >> 
> 
> >> here's a version of that with regions:
> 
> >> 
> 
> >> 
> 
> >> 
> 
> >> s" alfa" s" betalog" :noname str+ dump ; do-with-region
> 
> >> 
> 
> >
> 
> >Where is freed space allocated by STR+ ? 
> 
>
> 
> STR+ allocates from the current region,
> 
> 
> 
> do-with-region ( ... xt -- ... )
> 
> 
> 
> creates the region and makes it current, executes the xt, and frees
> 
> the region.


That sounds good.


>Does that answer your question?

Yes, thanks and I wait to see region-package released :-)

> 
> 
> 
> - 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 2014: http://www.euroforth.org/ef14/


Have a nice day,
humptydumpty

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

#31572

On 13/06/2014 17:42, Anton Ertl wrote:
> humptydumpty <ouatubi@gmail.com> writes:
>> Looking at first description of str+ ( ca1 u1 ca2 u2 -- ca3 u3 ;allocate
>> memory and concatenate STRING1 STRING2 into allocated memory,return
>> BUFFER ).  str+ do too much: concatenate strings + acquire heap resource
>> from OS.  More, the place where and time when that heap will be freed
>> is unknown.
>>
>> As a digression, that resembles (my past)novice use of variables: define,
>> store values in them knowing that somewhere sometime they will be used.
>>
>> Maybe a way of do this is something like that:
>> : str+ ( ca1 u1 ca2 u2 cad ud -- ;concatenate STRING1 STRING2 into
>> DESTINATION buffer)  string!+ string!+ 2drop ;
>
> Yes, that kind of interface is more common in Forth, especially in the
> standard (e.g., READ-LINE, or SUBSTITUTE), because ALLOCATE etc. is
> optional in the standard.
>
> I think it's a bad interface: you don't know how to size the buffer
> (well, for STR+ it's possible to know in advance, but for other words
> it's not or at least it's much too cumbersome; it's even quite
> cumbersome for STR+), and you have to report the case when the buffer
> is not big enough (which your STR+ does not do), and the client of the
> word has to write code to handle this case.  All of which makes
> working with this interface style quite arduous.  As a result, we
> regularly get new string packages.
>
> Note that we don't use this kind of style for working with numbers,
> there we just have ( n1 n2 -- n ).
>
> I think that a STR+ ( c-addr1 u1 c-addr2 u2 -- c-addr u ) is an
> improvement, even though the requirement to keep track of the
> allocated string is a burden.
>

I use a current concatenation buffer so my equivalent of your STR+ is 
simply STR+ ( c-addr u -- ) which checks there is room in the current 
buffer and copies the string to the end of previous concatenations. This 
requires extra words to allocate/free a buffer, clear it and to get the 
final result. This seems to fit well with the concept of memory regions 
with a current region.

For use at a higher level I have words on top of this that interpret a 
pattern string (like an extended sprintf) that use the above to 
construct a string in a concatenation buffer. The pattern string can 
contain meta and escaped characters, references (e.g. to regular 
expression results), commands such as calls to Forth words, 
conditionals, sprintf functionality. Anything unrecognised is simply 
copied to the buffer. This meets my needs and is simple to use.

[...]


-- 
Gerry

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

#31301

Anton Ertl wrote:
> The main problem I see with my current interface is how to deal with
> RESIZE.  I have chosen one approach, but I am not entirely happy
> with it.  RESIZE also costs quite a bit in the implementation.

I think the problem you have is that you are under the impression that you 
need to know how big the block was before.  Let's assume for readability you 
use the normal dictionary words as words underneath the region based 
allocater, and you store the size of the allocation in the cell before:

: allocate ( size -- addr ior )  dup , here swap allot align 0 ;
: free ( addr -- ior ) drop 0 ;
: resize ( addr size -- addr1 ior )
  over dup cell- @ + aligned here = IF  \ last block can grow or shrink
      2dup + here - allot align over cell- ! 0  EXIT  THEN
  over cell- @ over u>= IF \ every block can shrink
      over ! 0 EXIT  THEN  \ won't remember how much it might grow
  swap >r allocate over r@ swap r> cell- @ move ;

This is optimizing shrinks and copies only the necessary amount on grows, 
and allows to grow the most recent block, which e.g. in the typical string 
accumulation pattern is a good idea.

Let's assume we don't want to pay extra cost for RESIZE if we do just normal 
allocate, and we make sure that newer regions are always allocated right 
behind the previous region (e.g. by using sbrk() as region allocation 
primitive):

: allocate ( size -- addr ior )  here swap allot align 0 ;
: free ( addr -- ior ) drop 0 ;
: resize ( addr size -- addr1 ior )
  dup allocate >r >r r@ swap move r> r> ;

This doesn't have a cost on allocate, and has a much simpler resize, which 
however doesn't optimize on common cases.  Yes, it does leak information 
from the other blocks into the newly resized block, but that's not a 
security relevant allocator (Gforth git head provides allocation for 
security critical stuff like secret keys with ALLOC+LOCK in unix/mmap.fs - 
this stuff will not even get swapped out, and it has guard pages).

I probably would go with the first solution, and add a word for fixed-size 
allocations (the "ALLOT" from above) that doesn't have the overhead, but 
returns memory that can't be resized.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#31331

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> The main problem I see with my current interface is how to deal with
>> RESIZE.  I have chosen one approach, but I am not entirely happy
>> with it.  RESIZE also costs quite a bit in the implementation.
>
>I think the problem you have is that you are under the impression that you 
>need to know how big the block was before.

That's an implementation problem, but I have a solution for that.

But the problem where I am not happy about the solution is the
interface:

The only reason why I am implementing RESIZE at all is so that people
can use code written for ALLOCATE/FREE/RESIZE in combination with
region-based allocation.

But for RESIZE it's not entirely clear how that should work in
combination with the current region.  The memory to be RESIZEd might
come from another region or may not be region-allocated at all.  And
many uses of RESIZE are for things that live for the rest of the
process.  But others do not.  So I had to make some assumptions, and
they will be wrong for some uses, and I am unhappy about that.

- 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 2014: http://www.euroforth.org/ef14/

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web