>ALLOC

[none) (albert]

A useful word that I use more and more is an addition
to the ALLOCATE wordsset.
Often words are geared towards creating a data structure at
HERE. They can be in the way. >ALLOC moves it to allocated
space.

\ Make a freshly created object at `HERE permanent.
: >ALLOC DUP >R HERE OVER - DUP ALLOCATE THROW
DUP >R SWAP MOVE R> R> DP ! ;
\ DP ! can be replace by a negative ALLOT.

Example (counted strings)
CREATE animals
HERE 3 C, &a C, &a C, &p C, >ALLOC ,
HERE 4 C, &g C, &e C, &i C, &t C, >ALLOC ,

animals 1 CELLS + COUNT TYPE
goat


Groetjes Albert

[Marcel Hendrix]

On Monday, November 14, 2022 at 1:10:43 PM UTC+1, none albert wrote:
[..]

HERE 4 C, &g C, &e C, &i C, &t C, >ALLOC ,
animals 1 CELLS + COUNT TYPE
goat

It has a build Dutch->English translator unit?

Groetjes Albert

Why would you ALLOT first and then laboriously ALLOCATE and move?
Can't you just swap DP with some allocated memory and then swap DP
back? Or use A" instead of S" ?

-marcel

[Anton Ertl]

Post by Marcel Hendrix
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 ALLOTs the memory instead of ALLOCATEing it.

One big advantage of SAVE-MEM over >ALLOC is that it has a stack
diagram.

- anton

[none) (albert]

Post by Anton Ertl

Post by Marcel Hendrix
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!

Post by Anton Ertl
ALLOC allows to build memory structures the usual way

in the dictionary.
You probably have a hard time to recover the space "addr1 u".

Post by Anton Ertl
that ALLOTs the memory instead of ALLOCATEing it.
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.
I really need to write an uglifyer that translates
actual documentation to a stack diagram.

Post by Anton Ertl
- anton

[dxforth]

Post by none) (albert

Post by Anton Ertl

Post by Marcel Hendrix
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

[none) (albert]

Post by dxforth

Post by none) (albert

Post by Anton Ertl

Post by Marcel Hendrix
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 , /$ ;
here ( a)
," aap" ," geit"
0 c,
create animals ( a) $,s

Nice, but.

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?

Groetjes Albert

[dxforth]

Post by none) (albert
...
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 ,
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.

[none) (albert]

Post by dxforth

Post by none) (albert
...
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 ,
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.

I don't want to have large buffers allocated in an executable either.
I use REALLOT.
Preliminary (for testing) I have
VALUE BUFFER HERE TO BUFFER 1 , 2 ,
In the main word (that is executed by the turnkey) it goes
: main 2,000,000 BUFFER REALLOT .... ;
expanding the buffer to 2 Mbyte, and of course it can depend
on in line arguments such as.

linux>turnkey 1000
then it would be `` 1 ARG[] EVALUATE DUP * CELLS BUFFER REALLOT ...
^ 10000 ^ (but only in this execution instance)

[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.]

Groetjes Albert

[[e-mail]]

Post by none) (albert
[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.

[none) (albert]

Post by ***@arcor.de

Post by none) (albert
[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.

Pray, try to implement the above with values.

Groetjes Albert

[S Jack]

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.

I have ALLOCATE, string stack, local macros and possibly other code that
I never or seldom use. The problem is my hang-up. If I build foo and it
uses the string stack that made the operation very easy, I go back and
re-do foo so that it doesn't require a string stack. I feel a need to not
have words depended on big-gun resources. Yes, use the resource in a
script but not in the build of a word (unless it's a throw away word
in the script).
--
me

[Anton Ertl]

Post by none) (albert

Post by Anton Ertl
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).

[...]

Post by none) (albert
That is not an alternative!

I would not know from your nebulous description of >ALLOC.

Post by none) (albert

Post by Anton Ertl
ALLOC allows to build memory structures the usual way

in the dictionary.

"The usual way"?

Post by none) (albert
You probably have a hard time to recover the space "addr1 u".

Not in the least. The usual use of SAVE-MEM is when the memory at
addr1 u could be overwritten or its lifetime ends otherwise.
Otherwise, just let it stay there, and don't use SAVE-MEM.

Post by none) (albert

Post by Anton Ertl
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.

I don't see at a quick glance what happens on the stack, so it's not
useful for me, so I did not learn your way[1]. I also find the
"documentation" of >ALLOC unclear in other respects. The only thing
that made it clear to me that it is somewhat different from SAVE-MEM
was the examples.

[1] According to <https://en.wikipedia.org/wiki/Convention_(norm)>, "A
convention is a set of agreed, stipulated, or generally accepted
standards, norms, social norms, or criteria"; so your way of
documenting is not a convention, just like Humpty-Dumpty's use of
"glory" is not a convention.

- anton