amforth-devel

[Amforth-devel] heap and allot question

[Bernard M. <bme...@gm...>]

Hi All,

I am trying to implement a word that allocates a word on the heap, stores a
value in it, and returns it's RAM address.

The word is  : >RAM  ( x -- addr )  HEAP 1 CELLS ALLOT TUCK ! ;

The question is regarding amforths implementation of heap and allot. I
believe it uses the eeprom to save the address i.e "heap e@" returns the RAM
address of the top of heap?

If this is correct, then should the code line above be : >RAM  ( x -- addr )
 HEAP e@ 1 CELLS ALLOT TUCK ! ;

Thanks,
Bernard Mentink

Re: [Amforth-devel] heap and allot question

[Matthias T. <mt...@we...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bernard Mentink schrieb:
>
> If this is correct, then should the code line above be : >RAM  ( x --
addr )
>  HEAP e@ 1 CELLS ALLOT TUCK ! ;

with  : tuck swap over ; you are right ;=)

please note: heap is not a forth value, it gives only a eeprom
cell address.

Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIiWLU9bEHdGEMFjMRAqSQAJ9epDtgzM6JaVoVhMLRBombtBpXgACfUxwW
8wVrcO0fOw15IOJ3sthiwJg=
=EWlX
-----END PGP SIGNATURE-----

Re: [Amforth-devel] heap and allot question

[Bernard M. <bme...@gm...>]

>please note: heap is not a forth value, it gives only a eeprom
>cell address.

Hi Matthias,

Shouldn't heap return the address of the top of heap, you can't actually use
the 4 offset until you use e@ to get the address so it should be included in
the "heap" word. That would also make it ans compatible right?

I realize that if you change "heap" then some words that use heap will have
to be re-coded ..

Cheers,
Bernard

On Fri, Jul 25, 2008 at 5:21 PM, Matthias Trute <mt...@we...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bernard Mentink schrieb:
> >
> > If this is correct, then should the code line above be : >RAM  ( x --
> addr )
> >  HEAP e@ 1 CELLS ALLOT TUCK ! ;
>
> with  : tuck swap over ; you are right ;=)
>
> please note: heap is not a forth value, it gives only a eeprom
> cell address.
>
> Matthias
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIiWLU9bEHdGEMFjMRAqSQAJ9epDtgzM6JaVoVhMLRBombtBpXgACfUxwW
> 8wVrcO0fOw15IOJ3sthiwJg=
> =EWlX
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] heap and allot question

[Matthias T. <mt...@we...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bernard,
Bernard Mentink wrote

>> please note: heap is not a forth value, it gives only a eeprom
>> cell address.
>
> Hi Matthias,
>
> Shouldn't heap return the address of the top of heap, you can't
> actually use the 4 offset until you use e@ to get the address so it
> should be included in the "heap" word. That would also make it ans
> compatible right?

HEAP itself is not part of ANS94 / I do not find it there at least.

Looking at the code that uses HEAP directly, most of them use the
sequence "heap e@" so changing it to a real VALUE should be an
easy task.

> I realize that if you change "heap" then some words that use heap
> will have to be re-coded ..

Oh, don't worry too much. "most" code use ALLOT (that is part of ANS).
heap
is pretty much amforth specific. If no-one objects, I'll review most
of the EEPROM
based variables and turn them into real VALUEs.

: allot heap + to heap ;

(The sequence could be factored into a word of its own: add-to, ,
(comma) has a similiar
code)

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIjBko9bEHdGEMFjMRAtwoAJ4sy3AJXIGmDc2Ko/H7Zu/7YphYfwCfWXiB
2bnBWFDqT7sDzUtjVfK87vo=
=K81d
-----END PGP SIGNATURE-----

Re: [Amforth-devel] heap and allot question

[Bernard M. <bme...@gm...>]

Hi Matthias,

Sounds great. Bear in mind that the multitask.frt example which uses heap,
will need to be updated too. I havn't checked for others ..

Cheers,
Bernard

On Sun, Jul 27, 2008 at 6:43 PM, Matthias Trute <mt...@we...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bernard,
> Bernard Mentink wrote
>
> >> please note: heap is not a forth value, it gives only a eeprom
> >> cell address.
> >
> > Hi Matthias,
> >
> > Shouldn't heap return the address of the top of heap, you can't
> > actually use the 4 offset until you use e@ to get the address so it
> > should be included in the "heap" word. That would also make it ans
> > compatible right?
>
> HEAP itself is not part of ANS94 / I do not find it there at least.
>
> Looking at the code that uses HEAP directly, most of them use the
> sequence "heap e@" so changing it to a real VALUE should be an
> easy task.
>
> > I realize that if you change "heap" then some words that use heap
> > will have to be re-coded ..
>
> Oh, don't worry too much. "most" code use ALLOT (that is part of ANS).
> heap
> is pretty much amforth specific. If no-one objects, I'll review most
> of the EEPROM
> based variables and turn them into real VALUEs.
>
> : allot heap + to heap ;
>
> (The sequence could be factored into a word of its own: add-to, ,
> (comma) has a similiar
> code)
>
> Matthias
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIjBko9bEHdGEMFjMRAtwoAJ4sy3AJXIGmDc2Ko/H7Zu/7YphYfwCfWXiB
> 2bnBWFDqT7sDzUtjVfK87vo=
> =K81d
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth-devel] heap and allot question

[Matthias T. <mt...@we...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bernard Mentink wrote:

> Sounds great. Bear in mind that the multitask.frt example which
> uses heap, will need to be updated too. I havn't checked for others
> ..

I hopefully found all.

Just for the record: HERE, EDP, HEAP and HEAD are now forth VALUEs.
When they are called they give now the current value insted of the eeprom
address where the value is stored. To change any of them, use the command
TO (  ... 17 to here ... ). The DP pointer is gone, HERE does its job now.

please test now and report ;=)

Cheers,
Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIjEFo9bEHdGEMFjMRAnaJAJ4uWHOMajeYtVM/J0zWG6gr2VrXpACfVfoh
qqQQAjjLmR78EzdK2nrEymA=
=XLov
-----END PGP SIGNATURE-----

Re: [Amforth-devel] heap and allot question

[Kalus M. <mic...@on...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Matthias.

> HERE, EDP, HEAP and HEAD are now forth VALUEs.


I object!

Think twice bevor you go on with this.


a) Lets take a look at gforth, which is ANS Forth reference.

see dp
: dp
   useraddr <68>  @ ; ok
see here
: here
   dp @ ; ok

HERE gives you an address that is user dependend. If you have an  
userarea in amforth, dont make HERE absolute. You still will need DP  
I guess. It should be possible to perform a task switch with as less  
variables as possible.

b) What you had in mind calling the eprom variable HEAP was something  
like 2) of citation below. Now we want to have standard access to  
this unuses Ram. You already coded:

: PAD ( --add ) HEAP E@ ;
: HLD ( --adr ) PAD ;

So "heap" is just the name of a pointer in eeprom. This is ok that  
way. I think it is no good idea to use it as a name for a distinct  
ram area. So if you want access to an an dedicated ram area, use its  
name instead, use PAD or HLD. Thats the way it is traditionaly done  
in forth. May be we should even rename the pointer "heap" to  
"rampointer" to avoid further confusion about what a heap realy has  
to be.

Now, the standard way to determine the size and location of the rest  
of unused RAM was named ALLOCATE, FREE and RESIZE (see quotation below).

If you do that, you also have to keep track of the use of ram. Maybe  
you want semaphores holding size and address of ram areas.


I dindnt check this. But the idea is:

\  ram-semaphor in eeprom indicating use of RAM above PAD and HLD,
\  10 --> adr-of-ram-in-use
\  12 --> size-of-ram-in-use

...  (somewhere) pad padsize + 10 e!  0 12 e! ...

: allocate ( u -- adr f )
   12 e@ 0= IF 12 e!  10 e@  0 ELSE  12 e@ THEN  ;

: free ( adr -- f )
   10 e@ = IF  0 12 e!  0  ELSE  12 e@ THEN ;

Since we dont have big ram jet, maybe there is no need to RESIZE an  
allocated area so far or to allocate mor than one area.


Michael



<Citations>

Maybe you want to take a look at this too:

heap is:

1) a specialized tree-based data structure that satisfies the heap  
property: if B is a child node of A, then key(A) ≥ key(B).

http://en.wikipedia.org/wiki/Heap_%28data_structure%29


2) memory allocated from a large pool of unused memory area called  
the heap (also called the free store). Since the precise location of  
the allocation is not known in advance, the memory is accessed  
indirectly, usually via a reference.

http://en.wikipedia.org/wiki/Dynamic_memory_allocation


gforth

5.7.3 Heap allocation
Heap allocation supports deallocation of allocated memory in any  
order. Dictionary allocation is not affected by it (i.e., it does not  
end a contiguous region). In Gforth, these words are implemented  
using the standard C library calls malloc(), free() and resize(). The  
memory region produced by one invocation of allocate or resize is  
internally contiguous. There is no contiguity between such a region  
and any other region (including others allocated from the heap).

allocate ( u – a-addr wior ) \ memory “allocate”
Allocate u address units of contiguous data space. The initial  
contents of the data space
is undefined. If the allocation is successful, a-addr is the start  
address of the allocated
region and wior is 0. If the allocation fails, a-addr is undefined  
and wior is a non-zero I/O
result code.

free ( a-addr – wior ) \ memory “free”
Return the region of data space starting at a-addr to the system. The  
region must
originally have been obtained using allocate or resize. If the  
operational is successful,
wior is 0. If the operation fails, wior is a non-zero I/O result code.

resize ( a-addr1 u – a-addr2 wior) \ memory “resize”
Change the size of the allocated area at a-addr1 to u address units,  
possibly moving the contents to a different area. a-addr2 is the  
address of the resulting area. If the operation is successful, wior  
is 0. If the operation fails, wior is a non-zero I/O result code. If  
a-addr1 is 0, Gforth’s (but not the Standard) resize allocates u  
address units.

</ciatations>





Am 27.07.2008 um 11:35 schrieb Matthias Trute:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bernard Mentink wrote:
>
>> Sounds great. Bear in mind that the multitask.frt example which
>> uses heap, will need to be updated too. I havn't checked for others
>> ..
>
> I hopefully found all.
>
> Just for the record: HERE, EDP, HEAP and HEAD are now forth VALUEs.
> When they are called they give now the current value insted of the  
> eeprom
> address where the value is stored. To change any of them, use the  
> command
> TO (  ... 17 to here ... ). The DP pointer is gone, HERE does its  
> job now.
>
> please test now and report ;=)
>
> Cheers,
> Matthias
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIjEFo9bEHdGEMFjMRAnaJAJ4uWHOMajeYtVM/J0zWG6gr2VrXpACfVfoh
> qqQQAjjLmR78EzdK2nrEymA=
> =XLov
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFIjFSVJ3DLQCvSXtcRAkT2AJsHRMIpOTKXAYxbUAtW0OGSc5QxcACeNKfq
LqQ2HzTOKwLFwh5mmMh+45U=
=RGRN
-----END PGP SIGNATURE-----

Re: [Amforth-devel] heap and allot question

[Matthias T. <mt...@we...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Michael,

Kalus Michael wrote:

>> HERE, EDP, HEAP and HEAD are now forth VALUEs.
>
> I object!
>
> Think twice bevor you go on with this.

I did and do think that's a good thing.

why?

First: code that uses HERE is not portable to amforth at all since
HERE (or the information it carries) is and needs to be located in
EEPROM. The traditional sequence " ... here  @ .. " needs to be
rewritten to " .. here e@ .." vs. (new) " ..  here .. ". Same work.

Second: The new solution needs less code space. A good thing
esp on little Atmegas.

Third: It simplifies the view on the controller. Now all EEPROM
usage is either via Edefer (like turnkey) or VALUE.

> HERE gives you an address that is user dependend. If you have an
> userarea in amforth, dont make HERE absolute.

How is HERE based upon USER? HERE in amforth points to
the first free dictionary (flash) cell. All USERs share the same
dictionary in the same state, there is no "local" dictionary.

> You still will need DP I guess. It should be possible to perform a
>  task switch with as less variables as possible.

Task switches do not worry about HERE. They basically switch user
pointer and the stacks. The dictionary is untouched.


regarding alloc/free:

The use of allocate and free tend to fragment the RAM,
so you have to deal with holes and need to combine
them if possible. That this is neither easy nor trivial
show the countless implementations of malloc for C,
each for its own special optimization. It can be done
in and for amforth but I doubt that it will be part of
the core system. More like the multitasker: a loadable
module.

The trivial forth allot with negative values to give RAM
back to the system is, well, trivial. It has no flexibility but
does not need much.

> 2) memory allocated from a large pool of unused memory area called
>  the heap (also called the free store). Since the precise
> locationof the allocation is not known in advance, the memory is
> accessed indirectly, usually via a reference.

I considered this (or a similiar) technique to implement a virtual
memory management to make real ANS buffers on systems that do
not have enough real RAM.

> gforth
>
> 5.7.3 Heap allocation ... In Gforth, these words are implemented
> using the standard C library calls malloc(), free() and resize().

amforth does not have such a comfortable runtime environment.
It has to do all by itself.


Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIjIYL9bEHdGEMFjMRAuRqAJ4mxb+Pl1ElFWc3UyDuEQ6fulNP9ACgioY7
BZmTPJjnEFwWNMdVzasS73M=
=I8Ov
-----END PGP SIGNATURE-----