Re: [Amforth-devel] heap and allot question

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

-----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

amforth is an extendible interpreter on microcontrollers

Re: [Amforth-devel] heap and allot question