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