HERE 4 C, &g C, &e C, &i C, &t C, >ALLOC ,
animals 1 CELLS + COUNT TYPE
goat
Groetjes Albert
Why would you ALLOT first and then laboriously ALLOCATE and move?
Marcel Hendrix <mhx@iae.nl> writes:
Why would you ALLOT first and then laboriously ALLOCATE and move?
I guess it's for the example's sake.
Gforth has
: save-mem ( addr1 u -- addr2 u ) \ gforth
\g copy a memory block into a newly allocated region in the heap
with 9 uses inside Gforth (and I use it regularly elsewhere). There
is also a less frequently used
: save-mem-dict ( addr1 u -- addr2 u )
ALLOC allows to build memory structures the usual wayin the dictionary.
that ALLOTs the memory instead of ALLOCATEing it.
One big advantage of SAVE-MEM over >ALLOC is that it has a stack
diagram.
- anton--
In article <2022Nov14.194253@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
Marcel Hendrix <mhx@iae.nl> writes:
Why would you ALLOT first and then laboriously ALLOCATE and move?
I guess it's for the example's sake.
Gforth has
: save-mem ( addr1 u -- addr2 u ) \ gforth
\g copy a memory block into a newly allocated region in the heap
with 9 uses inside Gforth (and I use it regularly elsewhere). There
is also a less frequently used
: save-mem-dict ( addr1 u -- addr2 u )
That is not an alternative!
In article <2022Nov14.194253@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
Marcel Hendrix <mhx@iae.nl> writes:
Why would you ALLOT first and then laboriously ALLOCATE and move?
I guess it's for the example's sake.
Gforth has
: save-mem ( addr1 u -- addr2 u ) \ gforth
\g copy a memory block into a newly allocated region in the heap
with 9 uses inside Gforth (and I use it regularly elsewhere). There
is also a less frequently used
: save-mem-dict ( addr1 u -- addr2 u )
That is not an alternative!
: /$ ( a -- a' ) count + ; \ next string
: $, ( a -- a' ) dup , /$ ;
: $,s ( a -- ) begin dup c@ while $, repeat drop ;
here ( a)
," aap" ," geit"
0 c,
create animals ( a) $,s
animals 1 cells + @ count type
In article <2022Nov14.194253@mips.complang.tuwien.ac.at>,[...]
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
Gforth has
: save-mem ( addr1 u -- addr2 u ) \ gforth
\g copy a memory block into a newly allocated region in the heap
with 9 uses inside Gforth (and I use it regularly elsewhere).
That is not an alternative!
ALLOC allows to build memory structures the usual wayin the dictionary.
You probably have a hard time to recover the space "addr1 u".
One big advantage of SAVE-MEM over >ALLOC is that it has a stack
diagram.
It has actual documentation, that comprises a stack diagram.
The convention has been explained numerous times.
...
Suppose that you have a
0 0 class point
M: y M; ,
M: x M; ,
endclass
In my book that also generates a word that builds an anonymous
point `BUILD-point and a `^point containing a pointer to the
current point object.
CREATE points
HERE 3 4 BUILD-point >ALLOC ,
HERE 13 14 BUILD-point >ALLOC ,
points 1 CELLS + @ ^point ! ( make the second point current)
x ? y ?
13 14 OK
See my point now?
...
Suppose that you have a
0 0 class point
M: y M; ,
M: x M; ,
endclass
In my book that also generates a word that builds an anonymous
point `BUILD-point and a `^point containing a pointer to the
current point object.
CREATE points
HERE 3 4 BUILD-point >ALLOC ,
HERE 13 14 BUILD-point >ALLOC ,
points 1 CELLS + @ ^point ! ( make the second point current)
x ? y ?
13 14 OK
See my point now?
I can't speak for OOP needs. As I don't have (or particularly want) ALLOCATE >I try to look for alternate strategies e.g. ALLOTing buffers at run-time rather
than compile-time - not least because I have more RAM available.
[Actually I don't use values, I patch the data field of constants.
That amounts to the same trick.
dea ("name token") must be the xt of a constant.
: AT-HERE HERE SWAP >DFA ! ; ( dea -- )
: REALLOT SWAP AT-HERE ALLOT ; ( amount dea -- )
Come to think of it, if you use VALUE's, it is nasty to implement,
because the VALUE has to be changed, and that is only possible
if the name is parsed. That triggers a rename to AT-HERE: .
Perfect demonstration of the reason why true Forthers hate VALUE's.]
none albert schrieb am Donnerstag, 17. November 2022 um 12:37:45 UTC+1:
[Actually I don't use values, I patch the data field of constants.
That amounts to the same trick.
dea ("name token") must be the xt of a constant.
: AT-HERE HERE SWAP >DFA ! ; ( dea -- )
: REALLOT SWAP AT-HERE ALLOT ; ( amount dea -- )
Come to think of it, if you use VALUE's, it is nasty to implement,
because the VALUE has to be changed, and that is only possible
if the name is parsed. That triggers a rename to AT-HERE: .
Perfect demonstration of the reason why true Forthers hate VALUE's.]
Well, what's wrong with parsing TO VALUENAME during compile-time,
when the system is already parsing anyhow?
Anyway, compiled it should result to a non-parsing
<VALUEADDRESS> ! / 2! / F! / Loc!
and/or what you have.
I can't speak for OOP needs. As I don't have (or particularly want) ALLOCATE I try to look for alternate strategies e.g. ALLOTing buffers at run-time rather
than compile-time - not least because I have more RAM available.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 475 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 19:42:08 |
| Calls: | 9,487 |
| Calls today: | 6 |
| Files: | 13,617 |
| Messages: | 6,121,093 |