On 7/10/2021 18:26, Ruvim wrote:
> On 2021-10-04 19:32, Anton Ertl wrote:
>> Ruvim <ruvim.pinka@gmail.com> writes:
>>> On 2021-10-01 19:11, Anton Ertl wrote:
>>>> Well, the interface that Gforth has is relatively simple: You switch
>>>> to a section, and all ALLOTs then go into that section.
>>>
>>> In Gforth, code generation also goes into that section.
>>
>> The threaded code goes there, yes.
>>
>>> But if a system separates code and data, code generation will not go
>>> into that section, but remains in the original section.
>>
>> Why should it?
>
> Just to make sense for programs.
>
> If code generation goes into the old section, then this feature does not
> provide any substantially new capabilities to a *program*.

Perhaps you need to state what you think is the goal of gforth sections
before attempting to formalize it. I won't offer one as I'm equally
puzzled.

> If both data and code generation go into the single new section, then
> this way isn't compatible with some implementations, since it unites
> data and code.

Over the years there have been various reasons to implement 'sections' -
mostly incompatible. Dividing code, data and heads was popular for
segmented cpu's such as the 8086. I implemented sections (two) for
the purpose of segregating compiler and development tools from the
application. The DOS version puts heads in its own segment however
this is invisible to the user. The scheme has worked out very well -
as one would expect given most languages differentiate compiler and
application.

> Actually, a capability to create a data section with a set of methods
> like ",", "C,", "ALLOT", etc, can be useful for a program. Such a
> section has the following advantages:
> - it's completely separated from code generation;
> - it provides a convenient way to build compound data objects;
> - it allows to avoid allocating many small blocks in the heap;
> - it allows to easy clear recently created objects in LIFO order;
> - it allows to easy clear all objects (a whole section) at once;
> - multiple sections can be used independently in the same time.
> Thus, it's just a technique of memory management. I used this approach
> in some applications.

Coincidentally (or not) the functions you've listed above happen to be
the only 'compiler' words I make available to compiler-less turnkey
applications. I include F, and S, for floats and strings respectively.
The ability to 'allot' data on-the-fly at run-time is very handy -
particularly when there is no ALLOCATE. Also easier to use.

On 2021-10-07 17:54, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2021-10-07 13:17, Anton Ertl wrote:
>>> The relevance of a standardized sections wordset (aka API) would be to
>>> get around such restrictions.
>>
>> It's not easy, if possible at all. A library or extension can provide
>> defining words (or redefine some standard words) that uses data space. E.g.:
>>
>> : variable ( "name" -- ) align here >r 0 , : r> lit, postpone ; ;
>>
>> and now data space (the current data space section) is used when a
>> variable is created.
>
> Yes, but point is that it is in the current section. Other sections
> are unaffected.

Of course, other *private* sections of the program are not affected.
But other sections of the system can be affected in the general case, as
you also show in your definition for "variable" below.

>
> Therefore I can do
>
> create foo 5 ,
> next-section variable bar previous-section bar ,
> 6 ,
>
> and get a contiguous region starting at the body of FOO, containing 5,
> BAR, and 6.
>
> I can also define your VARIABLE above a little differently:
>
> : variable : next-section here 0 , previous-section lit, postpone ; ;

Yes, it provides a program with a way to have contiguous regions in data
space regardless of calling other words.

But usually it's possible for a program to call other words before or
after reserving these regions. I haven't faced a case when it's impossible.

So, this system's stack of data space sections provides a program with
just some additional convenience.

But the same convenience of reserving contiguous regions is provided by
user-defined data sections too. And user-defined data sections can be
already implemented in a portable way (as I mentioned in my previous
message). Even a stack of sections can be implemented by a program (but
the system will not use it, only the program).

Thus, the stack of data sections does not provide any substantially new
capabilities to a *program*. By substantially new capabilities I mean
such capabilities that cannot be efficiently implemented in a standard
way (i.e., in portable way).

So again I return to a capability that implies *compilation* to
different sections too. This capability cannot be implemented in a
standard way.

In my old extension, a separate abstract part of the dictionary that can
be used to compile definitions I called "storage".

Probably, a better word than "storage" can be found for this term.
Nevertheless, some rough formalization using this word is as follows.

A storage: a set of memory regions in the dictionary that can contain
definitions and data objects.

The active storage: a storage to which the compilation word list belongs.

A word list belongs to only one storage. Unless otherwise specified, a
word list belongs to the storage that was active when this word list was
created.

Data space is reserved and new definition are compiled in the memory
regions of the active storage only. The regions mentioned in 3.3.3.2 are
contiguous withing the same storage only. No change in the active
storage may affect other storages (including their contiguous regions).

A more advanced requirement is to allow nested compilation into a
different storage. It seems, this requirement is more difficult to
formalize.

An interesting question whether the regions allocated via ALLOCATE
should belong to some storage, or not. It matters for a method that
frees a storage (all space of the storage).

Another question is what parameters are required to create a storage.
Is it enough to specify the size available for code and the size
available for data?

NB: a mechanism of storages is targeted to programs. Under the hood a
storage can even contain a stack of sections that the system uses
internally. But such details cannot be exposed to programs, since they
can be different in different implementations.

--
Ruvim

On 2021-10-08 03:18, dxforth wrote:
> On 7/10/2021 18:26, Ruvim wrote:
>> On 2021-10-04 19:32, Anton Ertl wrote:
>>> Ruvim <ruvim.pinka@gmail.com> writes:
>>>> On 2021-10-01 19:11, Anton Ertl wrote:
>>>>> Well, the interface that Gforth has is relatively simple: You switch
>>>>> to a section, and all ALLOTs then go into that section.
>>>>
>>>> In Gforth, code generation also goes into that section.
>>>
>>> The threaded code goes there, yes.
>>>
>>>> But if a system separates code and data, code generation will not go
>>>> into that section, but remains in the original section.
>>>
>>> Why should it?
>>
>> Just to make sense for programs.
>>
>> If code generation goes into the old section, then this feature does not
>> provide any substantially new capabilities to a *program*.
>
> Perhaps you need to state what you think is the goal of gforth sections
> before attempting to formalize it.  I won't offer one as I'm equally
> puzzled.

Yes, and I stated it already several times.

E.g., see news:sjecsk$5vn$1@dont-email.me (2021-10-04 08:09 GMT)
https://groups.google.com/g/comp.lang.forth/c/LvyQ5B_FtEA/m/vCv_bbZmBAAJ

| A more appealing feature for programs is not just to have
| separate parts in data space, but separate parts
| of dictionary that can be used also to compile definitions.

In Gforth this feature almost available via its sections.

Despite the subject, I don't want to formalize the Gforth's sections,
but a more abstract model, that I try to describe. Since a particular
use case of sections is not portable, as you also mentioned below.

And the notion of section cannot be used to formalize a more abstract
model, since "section" implies a single address range, when the
dictionary may have many address ranges, and some of them (namely that
belong to code space) may be even not accessible to a program.

>> If both data and code generation go into the single new section, then
>> this way isn't compatible with some implementations, since it unites
>> data and code.
>
> Over the years there have been various reasons to implement 'sections' -
> mostly incompatible.  Dividing code, data and heads was popular for
> segmented cpu's such as the 8086.  I implemented sections (two) for
> the purpose of segregating compiler and development tools from the
> application.  The DOS version puts heads in its own segment however
> this is invisible to the user.  The scheme has worked out very well -
> as one would expect given most languages differentiate compiler and
> application.

The Forth dictionary represents a more abstract model, and it's
compatible with very different implementations.

What it lacks is a capability to manage different dictionaries, or
different parts of the dictionary (a methods to create them and destroy).

Having such a capability, a program will be able to load different
modules, use them, and free them independently of each other. Also, a
program will be able to create closures with arbitrary life time, in a
portable way. At the moment a program can create closures, but it's very
limited to destroy them.

>> Actually, a capability to create a data section with a set of methods
>> like ",", "C,", "ALLOT", etc, can be useful for a program. Such a
>> section has the following advantages:
>>     - it's completely separated from code generation;
>>     - it provides a convenient way to build compound data objects;
>>     - it allows to avoid allocating many small blocks in the heap;
>>     - it allows to easy clear recently created objects in LIFO order;
>>     - it allows to easy clear all objects (a whole section) at once;
>>     - multiple sections can be used independently in the same time.
>> Thus, it's just a technique of memory management. I used this approach
>> in some applications.
>
> Coincidentally (or not) the functions you've listed above happen to be
> the only 'compiler' words I make available to compiler-less turnkey
> applications.  I include F, and S, for floats and strings respectively.
> The ability to 'allot' data on-the-fly at run-time is very handy -
> particularly when there is no ALLOCATE.  Also easier to use.

Yes. Sometimes you need a heap too, but in many applications data space
section is enough.

--
Ruvim

In article <sis0do$acl$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>On 2021-08-06 10:50, Anton Ertl wrote:
>> We have added multiple sections [ertl-sections16] to Gforth. Sections
>> are the same concept as in assembly language and binary formats
>> (e.g. ELF): Classical Forth has one section=dictionary: A stretch of
>> memory from the start to HERE, with the address space behind available
>> for future allocation.
>
>If data space and code space are separated in a Forth system, do you
>consider them as one section, or two sections?

If you separate data space and code space, you do consider them two sections.
Separation of two spaces is the definition of sections.
If you subtract the address of the field from a address of the struct as
a whole this is allowed.
If you jump from on address to another address in the code space, this is normal,
the distance of the jump is defined.
Subtracting the address of a field from the address you jump to, is weird,
and implied by your phrase "data space and code space".
(This is not to say that you cannot jump to a data field, and it is likely
to lead to a crash.)

So in short: a tautology.

>--
>Ruvim
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst