Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #11125 > unrolled thread

Memory management

Back to article view | Back to comp.lang.forth

Contents

  Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-10 21:56 +0100
    Re: Memory management "Elizabeth D. Rather" <erather@forth.com> - 2012-04-10 10:18 -1000
      Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-10 22:43 +0100
        Re: Memory management "Elizabeth D. Rather" <erather@forth.com> - 2012-04-10 11:38 -1000
          Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 10:33 +0100
            Re: Memory management Paul Rubin <no.email@nospam.invalid> - 2012-04-11 02:35 -0700
              Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 12:20 +0100
                Re: Memory management Paul Rubin <no.email@nospam.invalid> - 2012-04-11 08:41 -0700
                  Re: Memory management David Thompson <dave.thompson2@verizon.net> - 2012-05-13 00:08 -0400
                  PDP-11 [Was: Memory management] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-13 09:18 -0500
                    Re: PDP-11 Paul Rubin <no.email@nospam.invalid> - 2012-05-14 01:09 -0700
                      Re: PDP-11 Paul Rubin <no.email@nospam.invalid> - 2012-05-14 01:19 -0700
                    Re: PDP-11 [Was: Memory management] Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-13 07:46 -0700
                      Re: PDP-11 [Was: Memory management] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-05-15 03:27 -0500
                      Re: PDP-11 [Was: Memory management] Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-05-15 11:30 +0000
                      Re: PDP-11 [Was: Memory management] Stan Barr <plan.b@dsl.pipex.com> - 2012-05-15 15:21 +0000
              Re: Memory management Nomen Nescio <nobody@dizum.com> - 2012-04-11 21:35 +0200
    Re: Memory management BruceMcF <agila61@netscape.net> - 2012-04-10 14:59 -0700
      Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 10:39 +0100
        Re: Memory management stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-11 09:53 +0000
          Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 12:15 +0100
            Re: Memory management stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-11 10:59 +0000
            Re: Memory management "Elizabeth D. Rather" <erather@forth.com> - 2012-04-11 07:44 -1000
              Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 20:50 +0100
                Re: Memory management Paul Rubin <no.email@nospam.invalid> - 2012-04-11 11:54 -0700
                  Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 21:03 +0100
                Re: Memory management vandys@vsta.org - 2012-04-11 19:09 +0000
                  Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 21:48 +0100
                  Re: Memory management Jecel <jecel@merlintec.com> - 2012-05-15 10:04 -0700
                    Re: Memory management vandys@vsta.org - 2012-05-15 17:29 +0000
                      Re: Memory management "A. K." <akk@nospam.org> - 2012-05-15 20:41 +0200
                Re: Memory management BruceMcF <agila61@netscape.net> - 2012-04-11 12:33 -0700
                  Re: Memory management Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2012-04-11 21:53 +0100
                    Re: Memory management BruceMcF <agila61@netscape.net> - 2012-04-11 13:43 -0700
                Re: Memory management Tarkin <tarkin000@gmail.com> - 2012-05-13 21:20 -0700
        Re: Memory management BruceMcF <agila61@netscape.net> - 2012-04-11 04:51 -0700

Page 2 of 2 — ← Prev page 1 [2]

#11146

In comp.lang.forth, Stephen Pelc wrote:

>>Just wondering, is such functionality available by now.
>
> Yes. It's even been done several times in the last 20 years. MPE did
> one for a client in the 1980s, and there has been at least one more
> specialised O/S since then.

Do you mean: Forth-based O/S ?

> Why does anyone need a new O/S now?

Why new OS? Being Linux user since 15 years I was always of the opinion,
that I've got much more, than I really need. Actually something like DOS/32
- having 4 GB address space and cooperative multitasking - could be quite
enough. Besides: you can do more interesting things having direct access to
hardware.

Actually, someone is even trying to desing one -
http://freedos-32.sourceforge.net/ - but it seems to be aimed only at x86
processors, and the project seems to be somewhat stalled.

Like I wrote, I'm not going to create one starting even tomorrow - but
playing for some time with Andy's ForthOS I was wondering, could it be made
such "general purpose OS". And the ability I'm asking for is essential for
something like this. One cannot just take assumption: "well, Forth
applications are not that resource-hungry, we've got plenty of RAM nowadays,
there won't be any problem". We don't know, what the user shall do using his
machine, and there shouldn't be anything wrong with starting and closing as
many applications - and as many times - as (s)he needs.
-- 
Forth is a preserver of health (Hippocrates)

[toc] | [prev] | [next] | [standalone]

#11149

On 11 Apr 2012 12:15:23 +0100, Zbiggy
<zbigniew2011REMOVE@gmail.REMOVE.com> wrote:

>In comp.lang.forth, Stephen Pelc wrote:
>
>>>Just wondering, is such functionality available by now.
>>
>> Yes. It's even been done several times in the last 20 years. MPE did
>> one for a client in the 1980s, and there has been at least one more
>> specialised O/S since then.
>
>Do you mean: Forth-based O/S ?

Yes.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#11157

On 4/11/12 1:15 AM, Zbiggy wrote:
> In comp.lang.forth, Stephen Pelc wrote:
>
>>> Just wondering, is such functionality available by now.
>>
>> Yes. It's even been done several times in the last 20 years. MPE did
>> one for a client in the 1980s, and there has been at least one more
>> specialised O/S since then.
>
> Do you mean: Forth-based O/S ?
>
>> Why does anyone need a new O/S now?
>
> Why new OS? Being Linux user since 15 years I was always of the opinion,
> that I've got much more, than I really need. Actually something like DOS/32
> - having 4 GB address space and cooperative multitasking - could be quite
> enough. Besides: you can do more interesting things having direct access to
> hardware.

It's all about tradeoffs. If you allow direct access to hardware in a 
general-purpose OS, you're at risk from user programs which do bad 
things with it (e.g. turn off devices they shouldn't, erase disk or 
flash, etc.). In a special-purpose Forth box, you have more control. My 
concern is that by the time you've built in all the special features and 
protections to allow arbitrary user programs written in whatever 
languages you end up with something not unlike the bare-bones Linux 
variants discussed in another thread. And they already exist, and lots 
of people understand them, so why bother?

> Actually, someone is even trying to desing one -
> http://freedos-32.sourceforge.net/ - but it seems to be aimed only at x86
> processors, and the project seems to be somewhat stalled.
>
> Like I wrote, I'm not going to create one starting even tomorrow - but
> playing for some time with Andy's ForthOS I was wondering, could it be made
> such "general purpose OS". And the ability I'm asking for is essential for
> something like this. One cannot just take assumption: "well, Forth
> applications are not that resource-hungry, we've got plenty of RAM nowadays,
> there won't be any problem". We don't know, what the user shall do using his
> machine, and there shouldn't be anything wrong with starting and closing as
> many applications - and as many times - as (s)he needs.

That kind of programming for "what-if" scenarios is what makes OSs what 
they are. If you want something different, start with different 
thinking: programming for the situation you have, with a system that is 
flexible enough to adapt to change when it occurs (which may not be the 
potential change that you were worrying about hypothetically).

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#11159

In comp.lang.forth, Elizabeth D. Rather wrote:

> It's all about tradeoffs. If you allow direct access to hardware in a 
> general-purpose OS, you're at risk from user programs which do bad 
> things with it (e.g. turn off devices they shouldn't, erase disk or 
> flash, etc.).

But nowadays the computers are cheaper than ever before. If such user will
do "bad things" - it'll be done only to his own software, on his own disk.

That's why I wrote, that I don't need (probably) most of Linux offerings;
all that Unix-derivatives have been imported from big machines, where - say
- a hundred or so users were working using "dumb terminals", and where such
"bad thing" could mean that the work of the remaining 99 users can be
stopped, if not totally wasted. But such situation isn't valid for someone's
own PC, therefore no need for that much "protection", which makes impossible
e.g. playing various funny things with VGA, using its registers directly.

> In a special-purpose Forth box, you have more control. My 
> concern is that by the time you've built in all the special features and 
> protections to allow arbitrary user programs written in whatever 
> languages

That could be "long term" target - but for today, I was only wondering about
possibility to "remove" something, that is "somewhere in the middle" of
vocabulary (assumption is, that on its words don't depend any other words).
And then how to reclaim that "hole", which appeared in the place of
"removed" words (and data).

Only next step would be to allow something like relocatable "Forth binary"
(or maybe something like "P-code", like it was in case of 8-bit BASICs?),
and only then "binary compiled from the source written in whatever language".

> you end up with something not unlike the bare-bones Linux 
> variants discussed in another thread. And they already exist, and lots 
> of people understand them, so why bother?

But the point is, that actually I don't need that much protection. We all(?)
were using DOS at some time (I'm still using FreeDOS), with no protections
at all, and it proved to be useful.

> That kind of programming for "what-if" scenarios is what makes OSs what 
> they are.

No, this time it wasn't "what-if"; I'm just pretty sure, that the described
action will occur. I'm doing it all the time (running applications when they
are needed, closing them after the work is done, not keeping them "hanging
around" in RAM).

> If you want something different, start with different 
> thinking: programming for the situation you have,

See above.

> with a system that is 
> flexible enough to adapt to change when it occurs (which may not be the 
> potential change that you were worrying about hypothetically).

Yes, that's why I'm examining Andy's ForthOS. If I only had more free time
for this...
-- 
Forth is a preserver of health (Hippocrates)

[toc] | [prev] | [next] | [standalone]

#11160

Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> writes:
> But the point is, that actually I don't need that much protection. We all(?)
> were using DOS at some time (I'm still using FreeDOS), with no protections
> at all, and it proved to be useful.

If your FreeDOS box has open ports on the internet, it's a multi-user
system and needs protection.  For that matter, as Stuxnet showed, you
may need protection even if your system isn't networked.

[toc] | [prev] | [next] | [standalone]

#11161

In comp.lang.forth, Paul Rubin wrote:

>> But the point is, that actually I don't need that much protection. We all(?)
>> were using DOS at some time (I'm still using FreeDOS), with no protections
>> at all, and it proved to be useful.
>
> If your FreeDOS box has open ports on the internet, it's a multi-user
> system and needs protection.  For that matter, as Stuxnet showed, you
> may need protection even if your system isn't networked.

No, it hasn't ( http://www.freedos.org/ ) - and I didn't mean "protection"
as firewall or something. Presently it is common to have such kind of
protection built-in directly in router, for example.

I wrote "protection" in the meaning e.g. "drivers layer separating
applications from hardware" and so on. Having drivers available won't hurt,
of course - but their use (when trying to make use out of some hardware)
shouldn't be mandatory, like it is in Linux/BSDs.
-- 
Forth is a preserver of health (Hippocrates)

[toc] | [prev] | [next] | [standalone]

#11163

Zbiggy <zbigniew2011REMOVE@gmail.remove.com> wrote:
> That could be "long term" target - but for today, I was only wondering about
> possibility to "remove" something, that is "somewhere in the middle" of
> vocabulary (assumption is, that on its words don't depend any other words).
> And then how to reclaim that "hole", which appeared in the place of
> "removed" words (and data).

You're talking about something which Smalltalk has been doing since the
1970's; methods--like everything else--are objects.  You can take the
class:method association and atomically point it at a new method object.
The old one can be garbage collected (and will, at least once any remaining
pointers to it are retired).  Not only could you do this, it was *the* way
that methods were added and updated.  When you booted a Smalltalk image, you
were running bits in the 1990's with continuity back to the VM images built
in the 1970's.  It was only in the 1990's that the Smalltalk architects, now
working on their "Squeak" implementation, went back and added "bootup" source
code so they could rigorously document how all of the necessary state of the
VM image had come into being.  Until that point, there were data structures
which were hand inserted in the 1970's and still depended upon in all VM's
twenty years later.

Lacking strong memory semantics with garbage collection, it's hard to design
a bullet proof system of comparable ability.  You can allocate colon
definition memory dynamically, and then free it later.  But how do you know
when it's safe to free it?  If you FORGET everything which follows, fine, but
then why bother with dynamic memory?  You can implement a poor man's memory
reference counter by sweeping colon defs, but what about ['] constructs
inside CODE words?  Or references in an array?  It feels like a losing battle
to me.

So I guess you'd have to look towards Factor.  I can't tell if it does
exactly what you want, but at least it has characteristics which make it a
reasonable starting point.

OTOH, if you have a system which can boot in < 0.10 seconds, and metacompile
itself in less than 10 seconds, you might be better off to not worry about
it.  When you want to change the system, just update the source, build, then
boot.  My own experience with ForthOS is that this approach works quite well.

-- 
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

[toc] | [prev] | [next] | [standalone]

#11167

In comp.lang.forth, vandys@vsta.org wrote:

> Lacking strong memory semantics with garbage collection, it's hard to design
> a bullet proof system of comparable ability.  You can allocate colon
> definition memory dynamically, and then free it later.  But how do you know
> when it's safe to free it?  If you FORGET everything which follows, fine, but
> then why bother with dynamic memory?  You can implement a poor man's memory
> reference counter by sweeping colon defs, but what about ['] constructs
> inside CODE words?  Or references in an array?  It feels like a losing battle
> to me.

Well, my assumption was - maybe not stated straight enough - that the user
will remove only "applications", I mean here: the programs, whose wordset
isn't in any way a "base" for another vocabulary/wordset (nothing more uses
their wordset neither directly, nor indirectly). Say, it'll be an editor. Or
a spreadsheet. Or simply a game.

Of course, there is always a place for human operator's error - but, as
I wrote, there's nothing that wrong with that, when we're talking about PC,
not about mainframe. Besides: as you noted, he'll restart the OS in
a fraction of a second.

> So I guess you'd have to look towards Factor.  I can't tell if it does
> exactly what you want, but at least it has characteristics which make it a
> reasonable starting point.
>
> OTOH, if you have a system which can boot in < 0.10 seconds, and metacompile
> itself in less than 10 seconds, you might be better off to not worry about
> it.  When you want to change the system, just update the source, build, then
> boot.  My own experience with ForthOS is that this approach works quite well.

Yes, for today it seems enough - I'm just wondering (since I've got no
idea), how much effort it would take to introduce some kind of "garbage
collection". How much more complicated would the system become.
-- 
Forth is a preserver of health (Hippocrates)

[toc] | [prev] | [next] | [standalone]

#12191

Andy,

> [...] It was only in the 1990's that the Smalltalk architects, now
> working on their "Squeak" implementation, went back and added "bootup" source
> code so they could rigorously document how all of the necessary state of the
> VM image had come into being.  Until that point, there were data structures
> which were hand inserted in the 1970's and still depended upon in all VM's
> twenty years later.

Aren't you thinking about Little Smalltalk? Squeak and Pharo still have stuff in their images that was last hand crafted in 1974.

-- Jecel

[toc] | [prev] | [next] | [standalone]

#12192

Jecel <jecel@merlintec.com> wrote:
> Andy,
>> [...] It was only in the 1990's that the Smalltalk architects, now
>> working on their "Squeak" implementation, went back and added "bootup" source
>> code so they could rigorously document how all of the necessary state of the
>> VM image had come into being.
> Aren't you thinking about Little Smalltalk? Squeak and Pharo still have
> stuff in their images that was last hand crafted in 1974.

I pretty definitely remember this activity WRT Squeak.  But just because I'm
sure doesn't mean I'm right. :->

BTW, anybody who wants to play with Smalltalk in its elemental form should
definitely look at Tiny Smalltalk.  Timothy Budd had done a very toy-like
Smalltalk years ago, and then did a new generation of the system which was
pretty much a true (if minimalist) Smalltalk system.  It had coasted to a
halt with the source sitting on his web site, and I tidied it up some and
it's available at:

    http://www.vsta.org/smalltalk/

-- 
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

[toc] | [prev] | [next] | [standalone]

#12195

On 15.05.2012 19:29, vandys@vsta.org wrote:
> Jecel<jecel@merlintec.com>  wrote:
>> Andy,
>>> [...] It was only in the 1990's that the Smalltalk architects, now
>>> working on their "Squeak" implementation, went back and added "bootup" source
>>> code so they could rigorously document how all of the necessary state of the
>>> VM image had come into being.
>> Aren't you thinking about Little Smalltalk? Squeak and Pharo still have
>> stuff in their images that was last hand crafted in 1974.
>
> I pretty definitely remember this activity WRT Squeak.  But just because I'm
> sure doesn't mean I'm right. :->
>
> BTW, anybody who wants to play with Smalltalk in its elemental form should
> definitely look at Tiny Smalltalk.  Timothy Budd had done a very toy-like
> Smalltalk years ago, and then did a new generation of the system which was
> pretty much a true (if minimalist) Smalltalk system.  It had coasted to a
> halt with the source sitting on his web site, and I tidied it up some and
> it's available at:
>
>      http://www.vsta.org/smalltalk/
>

Thanks for the interesting link !  :-)

[toc] | [prev] | [next] | [standalone]

#11165

On Apr 11, 3:50 pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
wrote:
> That could be "long term" target - but for today, I was only wondering
> about possibility to "remove" something, that is "somewhere in the middle"
> of vocabulary (assumption is, that on its words don't depend any other
> words). And then how to reclaim that "hole", which appeared in the place
> of "removed" words (and data).

> Only next step would be to allow something like relocatable "Forth binary"
> (or maybe something like "P-code", like it was in case of 8-bit BASICs?),
> and only then "binary compiled from the source written in whatever
> language".

The simplest way to do that is to have a distinct area for compilation
of these apps, organized into slots of a set size, and register a
compilation source into the system by compiling it regularly and
working out how many slots it will require. To load it, compile it
into that area starting at slot boundary that gives sufficient free
slots. To unload it, register those slots as free with the slot
allocator, and it'll get overwritten if the space is needed when
another app is loaded.

Compile it from source every time and relocating the binary is not an
issue.

Having the dictionary in distinct parts is an established, as, for
example, when the base Kernel is in ROM or flash RAM and newly
compiled words are in RAM.

[toc] | [prev] | [next] | [standalone]

#11168

In comp.lang.forth, BruceMcF wrote:

> The simplest way to do that is to have a distinct area for compilation
> of these apps, organized into slots of a set size [..]

Well, that seems to be idea worthy of further research. :)
-- 
Forth is a preserver of health (Hippocrates)

[toc] | [prev] | [next] | [standalone]

#11170

On Apr 11, 4:53 pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
wrote:
> In comp.lang.forth, BruceMcF wrote:
>> The simplest way to do that is to have a distinct area for compilation
>> of these apps, organized into slots of a set size [..]

> Well, that seems to be idea worthy of further research. :)

I vaguely recall an overlay loader that worked a bit like that, with
the slots being 1K in size and being used as extra block buffers when
not used for overlays.

I don't recall whether it was a working system or an experiment,
though it was more complicated than what I sketched, as pre-compiled
overlays were solving problems of storage size and compilation speed
that are not the bottlenecks they once were. Compiling directly from
source seems like it would simplify out quite a lot of the complexity
of that approach.

[toc] | [prev] | [next] | [standalone]

#12152

On Apr 11, 3:50 pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
wrote:
> In comp.lang.forth, Elizabeth D. Rather wrote:
>
> > It's all about tradeoffs. If you allow direct access to hardware in a
> > general-purpose OS, you're at risk from user programs which do bad
> > things with it (e.g. turn off devices they shouldn't, erase disk or
> > flash, etc.).
>
> But nowadays the computers are cheaper than ever before. If such user will
> do "bad things" - it'll be done only to his own software, on his own disk.
>

NOT necessarily. Remember early Linux distros' X packages
documentation
warning about setting fire to your monitor?

You can actually damage the hardware. The scale of the problem is not
likely to be on par with reconstructing a partition table- the
possibility
exists on trashing a motherboard component, rendering it, and quantums
know
what else, useless. I _believe_ most hardware is pretty failsafe when
it
comes to actually igniting, but would I bet my machine on it?

> That's why I wrote, that I don't need (probably) most of Linux offerings;
> all that Unix-derivatives have been imported from big machines, where - say
> - a hundred or so users were working using "dumb terminals", and where such
> "bad thing" could mean that the work of the remaining 99 users can be
> stopped, if not totally wasted. But such situation isn't valid for someone's
> own PC, therefore no need for that much "protection", which makes impossible
> e.g. playing various funny things with VGA, using its registers directly.
>

...

> > In a special-purpose Forth box, you have more control. My
> > concern is that by the time you've built in all the special features and
> > protections to allow arbitrary user programs written in whatever
> > languages
>
> That could be "long term" target - but for today, I was only wondering about
> possibility to "remove" something, that is "somewhere in the middle" of
> vocabulary (assumption is, that on its words don't depend any other words).
> And then how to reclaim that "hole", which appeared in the place of
> "removed" words (and data).
>
> Only next step would be to allow something like relocatable "Forth binary"
> (or maybe something like "P-code", like it was in case of 8-bit BASICs?),
> and only then "binary compiled from the source written in whatever language".
>
> > you end up with something not unlike the bare-bones Linux
> > variants discussed in another thread. And they already exist, and lots
> > of people understand them, so why bother?
>
> But the point is, that actually I don't need that much protection. We all(?)
> were using DOS at some time (I'm still using FreeDOS), with no protections
> at all, and it proved to be useful.
>


> > That kind of programming for "what-if" scenarios is what makes OSs what
> > they are.
>
> No, this time it wasn't "what-if"; I'm just pretty sure, that the described
> action will occur. I'm doing it all the time (running applications when they
> are needed, closing them after the work is done, not keeping them "hanging
> around" in RAM).
>
> > If you want something different, start with different
> > thinking: programming for the situation you have,
>
> See above.
>
> > with a system that is
> > flexible enough to adapt to change when it occurs (which may not be the
> > potential change that you were worrying about hypothetically).
>
> Yes, that's why I'm examining Andy's ForthOS. If I only had more free time
> for this...
> --
> Forth is a preserver of health (Hippocrates)

food for thought,
  Tarkin

[toc] | [prev] | [next] | [standalone]

#11150

On Apr 11, 5:39 am, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
wrote:
> In comp.lang.forth, BruceMcF wrote:

> Yes, I realize that - but you know, that I meant something different: not
> running Forth application with its "engine" under Linux/Windows/whatever,
> but is it possible by now under control of some kind of multitasked Forth
> OS. It's essential in case of such "general purpose OS", because you'll
> never know, how many times during his "session" user will be starting and
> closing applications (and how many apps, and how much resource-hungry).

> Just wondering, is such functionality available by now.

It or something close to it was available in the late 70's / early
80's. You have a Forth that compiles relocatable code (that is,
relative rather than absolute branches), and supports multiple
overlays. The reloadable overlays have their own USER variable space.
There's a word that marks the start of an overlay, and remembers the
USER variable allocation at that point. Then a word that saves the
overlay.

When loaded, you might have something like:
    Dict_BASE ... dict ... HERE ... Overlay_N ... Overlay_1 Dict_END

... or something like:
    Dict_BASE ... dict ... HERE ... Dict_End Overlay_1 ... Overlay_N

The thing is, if you have relocatable code, with the modern speed of
compilation, it would be simpler to just have a word that puts a end
point on the section of code killed by MARKER and then when the MARKER
executes, you just copy the existing dictionary code above the MARKER
block down.

And if working on some kind of free standing Forth with general
purpose applications ... the odds are that you run out of applications
that you need for that context or time to program additional
applications for the system before you run out of code space, and as
long as you have code space for putting all your applications in a
single dictionary, there's no reason to implement the means to recover
the dictionary space from a single application.

Indeed, a hosted Forth that plays well with others means that you can
spend you time programming the stuff you don't have yet, and don't
have to spend any time programming stuff from scratch that you already
have, so unless there was some reason for the programming from scratch
that can attract that interest of a programming community, its hard to
see it getting very far.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web