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 4 of 4 — ← Prev page 1 2 3 [4]

#31565

On Saturday, June 14, 2014 5:54:18 PM UTC-4, Elizabeth D. Rather wrote:
> On 6/14/14 10:08 AM, BruceMcF wrote:
>> The simplest data block allocation was just to store the block number being used in some variable "and remember". After all, if you have that block number stored in a variable, you can just fetch and print out the variable to remember which block is being used for that. Better practice was to have Block 0 as a comment block which said which blocks were being used for what, and sometimes Block 1 for the normal blocks to load up for that disk (since these were often removable floppy disks).

> Here's the way FORTH, Inc. and other traditional systems did it: A  system configured some number of block buffers (at least 2, sometimes up to 32). Each had a status cell that recorded what block was in that buffer. Its sign was set if the block had been changed since being read from disk. Each user had a "current block" which was the default accessed either by the text editor (if source) or data base system if data. If you requested a different block, the system would first check the current buffers to see if it was in memory; if so, no disk access was required. If it had to be read, the "oldest" buffer would be selected. If its block had been changed, it was written, and then the requested block would be read. This method minimized the number of disk accesses, since that was the slowest thing that could happen.

Yes, "I remember that well" (to quote from a classic movie song). In that setting, someone who has the habit of slicing off a chunk of blocks at the top can have (say):
   128 DATA-BLOCKS !

... in their preferred "set-up project" block, and extend the block LIST command to label it a "DATA Block" if the block called is bigger than (in this example) 127 ~ which would have worked well as a warning because all my block editing words worked on the SCR block, which was set by LIST.

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

#31550

In article <97b6c191-02c0-43e4-8717-3ad21c9b2fba@googlegroups.com>,
BruceMcF  <agila61@netscape.net> wrote:
>On Sunday, June 8, 2014 8:42:14 PM UTC-4, visua...@rocketmail.com wrote:
>> I am not familiar with memory allocation, but I have a question:
>
>> Can this stuff been done using blocks - with the size changed from 1k
>to 16k - as virtual memory?
>
>What blocks did in classic Forth on 8-bit machines with 16 bit addresses
>is expand their effective address space, since you could have 64K
>distinct BLOCKS, each with 1K of RAM, for up to 64M of randomly
>accessible data in a two-stage access system.
>
>But since Blocks were first and foremost to hold and maintain source, it
>wasn't common for Blocks to be treated as a pool of two-stage-access
>heap to be drawn on and released ... it was more common for specific
>Blocks to be given assigned roles, so that if a range of blocks was
>being used as de facto virtual memory, that range was reserved up front.
>
>The simplest data block allocation was just to store the block number
>being used in some variable "and remember". After all, if you have that
>block number stored in a variable, you can just fetch and print out the
>variable to remember which block is being used for that. Better practice
>was to have Block 0 as a comment block which said which blocks were
>being used for what, and sometimes Block 1 for the normal blocks to load
>up for that disk (since these were often removable floppy disks).
>
>Another simple approach is to slice off a set of blocks at the top,
>store their first and end block in a double variable, and update the
>block editor words to give you a warning and a y/n to proceed when
>editing in the data black range.

A simple approach that has become viable is the word WANTED .
It expects that the name of a word is mentioned in the "index" line,
first line of each block, like so:
"
    ( ASSEMBLER )                           \ AvdH  B4jan12
"
or
"
   ( VALUE TO FROM )                        \ ..
"
Now
    "ASSEMBLER" WANTED
loads the first block where ASSEMBLER appears in the index line.
There is also WANT and some refinements I made over the years,
allowing one library for 16 32 64 bits, and MSDOS linux Windows. 1]
(The interface is the same, but the implementation differs.)
200 blocks is sufficient to have a considerable amount of specialties
available, still keeping them out of the kernel and sufficient fast
LOADing.

Customary is to have WANT and WANTED in block 1. I have experimented
with replacing that block to make the mechanism and my existing
library work with gforth.

>
>If you wanted to use 4K or 16K superblocks, and you want to reuse
>existing facilities, its a lot more robust to start out by just
>accepting the overhead of the double moves and write words to copy 4K or
>16K of data to or from a range of blocks that you have allocated to
>data. If the approach proves useful, that is the time to copy the BLOCK
>word definitions and write a set of parallel SBLOCK word definitions,
>with buffer updating built to follow the scheme.
>
>But you've got all the overhead of any other two-tier access system ~
>you've got to set up where the window into the other data space is
>located, and manage how you make sure you have that window focused on
>the part you need at the time that you need it.
>

The WANT system is one-tier. To add the word MEMOIZE , just insert
the block with MEMOIZE and its index line, anywhere. This is assuming
the blocks are just in a file. To make it easier to use regular editors,
I replace each 64-th character with a ^J. Those block files are probably
 useable by most other forths, I've tried gforth.
Having load blocks, or having to redefine the constant EDITOR whenever
the editor changes places, is just a bad memory to me.

1] More conventions:
    -Searching stops with an empty index line.
      (So blocks behind that can be used conventionally.)
    - if after loading the block the word is not present,
       continue with following blocks.
    -An index line may contain LI? this is just executed.
      On an non-linux system, it breaks off loading the block.
     E.g. you'll see consecutive blocks with index lines:
     ( TURNKEY ) ?LI      \ ..
     ( TURNKEY ) ?MS      \ ..
     ( TURNKEY ) ?DPMI    \ ..
     ( TURNKEY ) ?WI      \ ..
-- 
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]

#31567

On Sunday, June 15, 2014 7:59:11 AM UTC-4, Albert van der Horst wrote:
> In article <97b6c191-02c0-43e4-8717-3ad21c9b2fba@googlegroups.com>, 
> BruceMcF  <agila61@netscape.net> wrote:

>>But since Blocks were first and foremost to hold and maintain source, it 
>>wasn't common for Blocks to be treated as a pool of two-stage-access
>>heap to be drawn on and released ... it was more common for specific
>>Blocks to be given assigned roles, so that if a range of blocks was
>>being used as de facto virtual memory, that range was reserved up front.
...

>>If you wanted to use 4K or 16K superblocks, and you want to reuse
>>existing facilities, its a lot more robust to start out by just 
>>accepting the overhead of the double moves and write words to copy 4K or 
>>16K of data to or from a range of blocks that you have allocated to
>>data. If the approach proves useful, that is the time to copy the BLOCK
>>word definitions and write a set of parallel SBLOCK word definitions,
>>with buffer updating built to follow the scheme.
>>But you've got all the overhead of any other two-tier access system ~
>>you've got to set up where the window into the other data space is
>>located, and manage how you make sure you have that window focused on
>>the part you need at the time that you need it.
 
> The WANT system is one-tier. To add the word MEMOIZE , just insert 
> the block with MEMOIZE and its index line, anywhere. This is assuming
> the blocks are just in a file.

Yes, when a whole block can be seen as a single chunk of data, then there is just one level.

And the two-tier data access was most often in the form of some kind of database, which in a flat database is intrinsically two-tier, per-record then per-field, with the database access words handling the conversion from the per-record view to the per-block view.

Indeed, that is still available as a strategy today ... if you have a CSV file with a side INFO file, scan through a CSV file to find the maximum length of each entry, determine how many lines in multiples of two are required per CSV line, set up a linked list of fields reading the INFO file to get the name for each field, and you'd have an easy intermediate data format for all manner of manipulation or file format conversions.

> To make it easier to use regular editors,
> I replace each 64-th character with a ^J. Those block files are probably
>  useable by most other forths, I've tried gforth.
 
Any ANS standard forth that treats control characters in the input buffer as equivalent to blanks will do just fine with that. That is not required but it is the norm.

The standard block words don't know that they are end of line carriage returns, but it knows that each 64th position is the end of a line, so \ works, even though it works for different reasons when that line is read from a file and when it is ready from a block.

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

#31568

On Sunday, June 15, 2014 3:55:47 PM UTC-4, BruceMcF wrote:
> Indeed, that is still available as a strategy today ... if you have a CSV file with a side INFO file, scan through a CSV file to find the maximum length of each entry, determine how many lines in multiples of two are required per CSV line, set up a linked list of fields reading the INFO file to get the name for each field, and you'd have an easy intermediate data format for all manner of manipulation or file format conversions.

That is, powers of two .... one test bed for portability is a special vocabulary with block words defined for a single Block buffer, so to stress test that the process works for records larger than the provided number of block buffers, you only need a test CSV file with more than 1024 chars worth of space required to accommodate a record with maximum sized data in each field.

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

#31456

I started to implement this but lost steam when it dawned on me that it would be several weeks work before I was actually using any of the systems I was planning to build on top of this.  I don't have that kind of free time right now, nor is there a pressing need for it - but it's still a nifty solution on the shelf.

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

#31684

Worked on this tonight.  Regions are kept track of with 2-cell data structures pointing to a first subregion and a last one.

Looking for ideas on a word for clearing a region.  ( region -- )  Looking for a nice & simple non-compound word, due to the general nature of this system.  When cleared, all the region's subregions are marked as allocated-but-free.

Ideas:

TOPPLE
NULLIFY
RELEASE

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

#31686

On 20/06/2014 06:57, Roger Levy wrote:
> Worked on this tonight.  Regions are kept track of with 2-cell data structures pointing to a first subregion and a last one.
>
> Looking for ideas on a word for clearing a region.  ( region -- )  Looking for a nice & simple non-compound word, due to the general nature of this system.  When cleared, all the region's subregions are marked as allocated-but-free.
>
> Ideas:
>
> TOPPLE
> NULLIFY
> RELEASE
>
RELEASE is good. Though it's (IMO) ambiguous. It could easily 
collide with names in a users application, for example.

I like the idea of pre-fixes or suffixes at the library code 
level. That way, it is clear(er) to the reader later on that a 
particular word refers to something in the library.

For example, in my string library, all the string functions 
contain a $ sign. DROP$ SWAP$ DUP$ ROT$ +$ ==$? etc.

You might like to try consider a similar convention. It probably 
goes against the Forth grain, but don't let the purists put you 
off ;-).

A possible suggestion: -R as a suffix:

* CLAIM-R
* FREE-R
* COMPACT-R

etc. It's immediately clear what the word is referring to. 
Contrast with:

CLAIM
FREE
COMPACT

See? They could refer to anything.

HTH

Mark

Other suggestions:

* RECLAIM
* FREE-R (free region)

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

#31687

> RELEASE is good. Though it's (IMO) ambiguous. It could easily 
> 
> collide with names in a users application, for example.

When I design the name of a core-language-level word, I try to think of possible uses for the name in the intended application.  RELEASE is good, but it is indeed too vague.

> * CLAIM-R
> 
> * FREE-R
> 
> * COMPACT-R
> 
> 
> 
> etc. It's immediately clear what the word is referring to. 
> 
> Contrast with:
> 
> 
> 
> CLAIM
> 
> FREE
> 
> COMPACT
> 
> 
> 
> See? They could refer to anything.

Coming from a multi-language background, I see why you'd think that Forth's lack of easy name reuse is a disadvantage; after all in OOP languages a method can share the same name as another so long as it's in a different class, yet ironically most use CamelCase and LongButFoolproofMethodNames.  To me, once a word is defined in Forth, I know what it means in the relevant domain.  I  design to the domain.  The problem is when you must mix domains, sometimes you have no choice.  On the contrary, COMPACT-R could mean anything just as much as COMPACT, but the -R just adds noise.   You might as well say COMPACT-REGION, but we're trying to maintain a sense of simplicity here, so the exposed words should be simple.  They'll be used a lot, so there won't be any confusion.  What if ALLOT was ALLOT-DICTIONARY-BYTES, or CALLOT-D?  What if all core Forth words were that way?  This is intended to be a core extension word, so it's very much in the "Forth domain".  I'm not a purist, I just know that minimizing punctuation and compound words when possible has real benefits and there's no point in bucking the convention just for the sake of doing so.  Hope that makes sense.

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

#31707

RECLAIM is the one closest to the function ~ you are reclaiming memory from use by a prior region user so that they can be used by a future region user.

You are not actually releasing it ~ its still allocated, its just been made available for use again. You definitely are not nullifying it. TOPPLE would be, eg, if there was an incumbent master manager function and you are replacing it.

I'd call it REGION-RECLAIM but its your source, so you get to decide whether tis better to suffer the slings and arrows of hypothetical namespace collisions or to hyphenate, and by hyphenating, end them.

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

#31710

RECLAIM is exactly what I decided to use last night, before I read your post this morning. :)

i'm going with this lexicon:


TRIM ( region bytes -- ) resize a region (reduction only)

RESERVED ( region -- bytes ) get region's current size

RECLAIM ( region -- ) 0 TRIM

RESERVE ( region bytes -- address ) request memory from a region

/BLOCK ( -- bytes ) get the internal subregion allocation unit

REGION ( -- <name> ) define a named region

/REGION ( -- bytes ) get the region struct size

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

#31712

On Saturday, June 21, 2014 11:51:24 AM UTC-4, Roger Levy wrote:
> RECLAIM is exactly what I decided to use last night, before
> I read your post this morning. :)
 
> i'm going with this lexicon: 

> TRIM ( region bytes -- ) resize a region (reduction only)
> RESERVED ( region -- bytes ) get region's current size
> RECLAIM ( region -- ) 0 TRIM
> RESERVE ( region bytes -- address ) request memory from a
>    region
> /BLOCK ( -- bytes ) get the internal subregion allocation
>    unit
> REGION ( -- <name> ) define a named region
> /REGION ( -- bytes ) get the region struct size

I quite like 6 out of 7 of those ~ however if I encountered /BLOCK out of the blue, I'd assume it would be equivalent to:
    1024 CHARS CONSTANT /BLOCK

/CHUNK perhaps?

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

#31714

> I quite like 6 out of 7 of those ~ however if I encountered /BLOCK out of the blue, I'd assume it would be equivalent to:
> 
>     1024 CHARS CONSTANT /BLOCK
> 
> 
> 
> /CHUNK perhaps?

I debated with myself over this.  Thanks for the feedback - if I called it /CHUNK though that seems a bit vague; maybe the allocation unit needs a special, memorable name.  /PARTITION ?  /AU (allocation unit)?  

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

#31717

On Saturday, June 21, 2014 2:10:59 PM UTC-4, Roger Levy wrote:
>> I quite like 6 out of 7 of those ~ however if I encountered /BLOCK out of the blue, I'd assume it would be equivalent to:

>>     1024 CHARS CONSTANT /BLOCK
>>  
>> /CHUNK perhaps?

> I debated with myself over this.  Thanks for the feedback - if I called it /CHUNK though that seems a bit vague; maybe the allocation unit needs a special, memorable name.  /PARTITION ?  /AU (allocation unit)?

Not /AU given "au" is often read as "address unit".

Vague? So are TRIM RESERVED RESERVE and RECLAIM ~ the only non-vague ones are REGION and /REGION. Precise are:
   TRIM-REGION
   REGION-RESERVED
   REGION-RESERVE
   RECLAIM-REGION
   /REGION-CHUNK

... but you'd rather not hyphenate, and have a strategy of naming them as first-order words similar to BLOCK and LOAD and INCLUDE. As a prospective first-order word, I think /CHUNK for the memory allocation unit has some history in some dusty corners of computer science ~ I'm guessing that's where I got it.

If the documentation explains that the unit of allocation is called a CHUNK then its not vague in that context, and at least it is (1) apropos and (2) not calling to mind quite different and already existing ANS Forth connotations.

If you want an acronym to make it precise without hyphenating, /AU brings "au" for address unit to mind, but /RAU for "region allocation unit" would at least not likely be confused for something else, though it may sense a reader scrambling for the glossary.

/CHUNK comes to my mind because I vaguely recall having had cross 16bit/32bit BLOCK database words allocating in 8-cell units referred to as CHUNKs in their various handler words, so 64 chunks per block in a 16bit/8bit system, 32 chunks per block in a 32bit/8bit system (and I guess 16 chunks per block in a 64bit/8bit system, though that wasn't an issue) and I could work with cell data within any given CHUNK without worrying about variable cells per block on my 32-bit DOS Forth or 128K 16-bit DOS Forth (IIRC, separate dataspace & codespace, I assume the dataspace had the stacks) or C64. I guess the same principle to port code between an ANS Forth BLOCK system and a mini-block system that lined up block size with individual flash block size.

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

#31720

> If the documentation explains that the unit of allocation is called a CHUNK then its not vague in that context, and at least it is (1) apropos and (2) not calling to mind quite different and already existing ANS Forth connotations.

Chunk kind of feels right.  It's a concept I'll be using a lot in application code, so it might as well make it a simple word like that.  I'm not sure though.  

I know that it'll be used for things like dynamic arrays, that will allocate more subregions as needed, using the allocation unit size.  In that sense chunk fits the idea of subregions, which is wrong, so it could make it confusing.  Something like "block" or "brick" fits, because when I think of those words I think of a standardized rectangular thing, which is what these units are.  I don't use classic blocks, so maybe I don't care about confusing people from that era ;)  Still it'd be nice to come up with a new name that fits.

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

#31724

On Saturday, June 21, 2014 3:39:01 PM UTC-4, Roger Levy wrote:
> > If the documentation explains that the unit of allocation is called a CHUNK then its not vague in that context, and at least it is (1) apropos and (2) not calling to mind quite different and already existing ANS Forth connotations.

> Chunk kind of feels right.  It's a concept I'll be using a lot in application code, so it might as well make it a simple word like that.  I'm not sure though.  
> 
> 
> 
> I know that it'll be used for things like dynamic arrays, that will allocate more subregions as needed, using the allocation unit size.  In that sense chunk fits the idea of subregions, which is wrong, so it could make it confusing.

Well, the definition google define: returns in the noun sense is:

noun
noun: chunk; plural noun: chunks

    1.
    a thick, solid piece of something.
    "huge chunks of masonry littered the street"

With synonyms: lump, hunk, wedge, block, slab, square, nugget, brick, cube, bar, cake

So if you were getting cute, you could have /HUNK and hold in reserve if you ever encountered an "1CHARS>1" system, Hunks in terms of character capacity, C-hunk-size or ... /CHUNK
... badum bum *crash*

But that's kind of the sense that I'm using it in ~ a thick and solid enough piece of memory that naive dynamic allocation doesn't suffer from as much "this piece is just one or two cells short of what you need" fragmentation, and so the most modest of memory space requests may often only need one or two chunks.

> Something like "block" or "brick" fits, because when I think of those words I think of a standardized rectangular thing, which is what these units are.

Per above, both synonyms of chunk, suggesting this is all in the right general neighborhood.

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

#31726

> So if you were getting cute, you could have /HUNK and hold in reserve if you ever encountered an "1CHARS>1" system, Hunks in terms of character capacity, C-hunk-size or ... /CHUNK
> 
> ... badum bum *crash*

....... 

yeah, cute. :P

i might go with /SEGMENT.  the common definition of segment has to do with x86 but that's a mess i'm okay with bulldozing over.

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

#31739

In article <513bed46-d1d1-41a9-9a27-9d8f1341b0a4@googlegroups.com>,
Roger Levy  <roger.levy@gmail.com> wrote:
>> So if you were getting cute, you could have /HUNK and hold in reserve
>if you ever encountered an "1CHARS>1" system, Hunks in terms of
>character capacity, C-hunk-size or ... /CHUNK
>>
>> ... badum bum *crash*
>
>.......
>
>yeah, cute. :P
>
>i might go with /SEGMENT.  the common definition of segment has to do
>with x86 but that's a mess i'm okay with bulldozing over.

To be accurate, segment is a part of memory where addresses that
can be related among themselves. It was introduced in Unix etc.
when relocation came into fashion.
Then x86 implemented it in hardware and to avoid confusion the
term section came into use.

The name suggest that addresses in the same segment can be
meaningfully compared, but not so from different segments.

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]

#31750

On Sunday, June 22, 2014 9:58:56 AM UTC-4, Albert van der Horst wrote:
> To be accurate, segment is a part of memory where addresses that 
> can be related among themselves. It was introduced in Unix etc.
> when relocation came into fashion.
> Then x86 implemented it in hardware and to avoid confusion the
> term section came into use.
>
> The name suggest that addresses in the same segment can be 
> meaningfully compared, but not so from different segments.

Whereas in the present case, they are a given allocation unit and a set of them allocated all at the same time can all serve as a single segment (though I presume the size is a mutable constant rather than fixed constant, that is, that  different systems with different available memory might have different sized units).

Further confirming ``/chunk'' as a good name, since a chunk is often a piece of something bigger ~ that is, among generic 'first order' namings, though I'd still rather be explicit about chunk of what with ``/region-chunk''.

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

#31721

I think I'm going to group regions as part of my toolbelt, I want to use my arrays and quicksort.  Subregions have to be sorted by size to find the best match for a requested amount of memory.  I think.  Is there a more efficient way?

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

#31843

I finished implementing the memory manager yesterday.  I'll publish it when I get around to publishing my toolbelt, since it's part of it.

There is a word RESERVE for requesting memory which is guaranteed to be "sequential" (within each subregion - it's for arrays but possibly other data structures too) but I was thinking to add another word that can scan all subregions in a region first for gaps, when you don't need anything in a region to be sequential in memory.

I have plans for "combine" and "split" operations, to fight fragmentation, but they aren't finished.  They aren't used at the moment.

Also, I went with /SEGMENT for the allocation unit size.  Right now it's 16384+256.  The constant can be changed to almost anything by the user.

[toc] | [prev] | [standalone]

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

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

csiph-web