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 1 of 2  [1] 2  Next page →

#11125 — Memory management

My question is rather about "standalone" Forths:

Say we've got a system, where we want to run - then close - several
applications at the same time, just like I'm doing it now under Linux (mutt,
WWW browser, newsreader, xterm windows etc.).

If I don't need particular application at the moment: does there exists any
way to get rid of it - of course I don't mean here neither FORGET, nor
MARKER; just "close window" or something like that - then to reclaim the
freed memory?
-- 
Forth is a preserver of health (Hippocrates)

[toc] | [next] | [standalone]

#11129

On 4/10/12 10:56 AM, Zbiggy wrote:
> My question is rather about "standalone" Forths:
>
> Say we've got a system, where we want to run - then close - several
> applications at the same time, just like I'm doing it now under Linux (mutt,
> WWW browser, newsreader, xterm windows etc.).
>
> If I don't need particular application at the moment: does there exists any
> way to get rid of it - of course I don't mean here neither FORGET, nor
> MARKER; just "close window" or something like that - then to reclaim the
> freed memory?

It depends on how the system is built and configured. If you're 
compiling from source on disk or flash, it's easy to configure your 
subordinate apps as overlays with MARKER (don't know why you reject 
that). With a little more effort you could precompile your apps to a 
specified memory slot and manage them that way, and there are several 
other possible approaches.

The overriding question is, do you *ever* want them to all be in memory 
and available at the same time? If so, you need sufficient memory for 
that, so you may as well have them all in memory all the time even if 
you aren't using them all the time.

Since Forth systems & apps are so small, most hardware configurations 
have way more program memory than is needed, so saving memory for apps 
is less of a driving issue.  Data space is more likely to be needed in 
massive quantities, which is when the Memory Allocation wordset proves 
most useful.

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]

#11130

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

> It depends on how the system is built and configured. If you're 
> compiling from source on disk or flash, it's easy to configure your 
> subordinate apps as overlays with MARKER (don't know why you reject 
> that).

Using MARKER - or FORGET - I'm removing all from given "marker" place.
Therefore if I have loaded - say - WWW browser, then xterm, some other
applications, when I want just to release memory taken by browser, by using
MARKER I'm removing browser along with all the later loaded applications.

That's not what I want; I wanted just to get rid of the browser, and to keep
the rest.

> With a little more effort you could precompile your apps to a 
> specified memory slot and manage them that way, and there are several 
> other possible approaches.

Is such "binary" relocatable?

> The overriding question is, do you *ever* want them to all be in memory 
> and available at the same time?

Just like this moment: using the SLRN to read news (one app), I'm using
editor "joe" to edit (second app), and all this in XTerm window (third app)
- at the same time there is window manager active (fourth app)... and so on.

When I finish, joe editor will be terminated, and I won't need it, until
I'll edit another reply. Then why should I keep it in RAM; it's better to
release memory for another application.

> If so, you need sufficient memory for 
> that, so you may as well have them all in memory all the time even if 
> you aren't using them all the time.
>
> Since Forth systems & apps are so small, most hardware configurations 
> have way more program memory than is needed [..]

Yes, but in case it won't be enough, I'm curious about available
possibilities. My question is of pure technical nature: is it possible - and
if so, how - not "is it better to keep application in RAM, or not".

Say, that we've got some kind of Forth OS - coincidence with Andy's ForthOS
not deliberate, I mean just any "standalone Forth" - designed for "ordinary
user", who hasn't any idea about MARKERs, FORGETs and so on. He/she just
closes the WWW browser window, but is willing to keep all other applications
running (we've got multitasking). Then I'm wondering, how are possibilities
to reclaim the memory a minute ago occupied by browser - for other programs
the user can run. Will there appear an "empty hole" in address space, after
browser removal, or can we somehow relocate all the other, running apps,
"down the address space"? Or can this (now unused) memory be reclaimed other
way?

At my current level I'm familiar just with FORGET/MARKER, that will remove
everything "since the given point" - that's why I'm asking for more
sophisticated approach.
-- 
Forth is a preserver of health (Hippocrates)

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

#11134

On 4/10/12 11:43 AM, Zbiggy wrote:
> In comp.lang.forth, Elizabeth D. Rather wrote:
>
>> It depends on how the system is built and configured. If you're
>> compiling from source on disk or flash, it's easy to configure your
>> subordinate apps as overlays with MARKER (don't know why you reject
>> that).
>
> Using MARKER - or FORGET - I'm removing all from given "marker" place.
> Therefore if I have loaded - say - WWW browser, then xterm, some other
> applications, when I want just to release memory taken by browser, by using
> MARKER I'm removing browser along with all the later loaded applications.
>
> That's not what I want; I wanted just to get rid of the browser, and to keep
> the rest.
>
>> With a little more effort you could precompile your apps to a
>> specified memory slot and manage them that way, and there are several
>> other possible approaches.
>
> Is such "binary" relocatable?

Most compiled Forth is not relocatable, though there's no reason why one 
couldn't make one that is. Easier to make fixed memory areas and compile 
to those.

>> The overriding question is, do you *ever* want them to all be in memory
>> and available at the same time?
>
> Just like this moment: using the SLRN to read news (one app), I'm using
> editor "joe" to edit (second app), and all this in XTerm window (third app)
> - at the same time there is window manager active (fourth app)... and so on.
>
> When I finish, joe editor will be terminated, and I won't need it, until
> I'll edit another reply. Then why should I keep it in RAM; it's better to
> release memory for another application.
>
>> If so, you need sufficient memory for
>> that, so you may as well have them all in memory all the time even if
>> you aren't using them all the time.
>>
>> Since Forth systems&  apps are so small, most hardware configurations
>> have way more program memory than is needed [..]
>
> Yes, but in case it won't be enough, I'm curious about available
> possibilities. My question is of pure technical nature: is it possible - and
> if so, how - not "is it better to keep application in RAM, or not".

Most of the memory required by a browser (or other memory-hogging apps) 
is actually data storage. If you write your app to use ALLOCATE/FREE you 
can release that space without necessarily "unloading" the app. When you 
re-activate the app it will allocate data space it needs.

> Say, that we've got some kind of Forth OS - coincidence with Andy's ForthOS
> not deliberate, I mean just any "standalone Forth" - designed for "ordinary
> user", who hasn't any idea about MARKERs, FORGETs and so on. He/she just
> closes the WWW browser window, but is willing to keep all other applications
> running (we've got multitasking). Then I'm wondering, how are possibilities
> to reclaim the memory a minute ago occupied by browser - for other programs
> the user can run. Will there appear an "empty hole" in address space, after
> browser removal, or can we somehow relocate all the other, running apps,
> "down the address space"? Or can this (now unused) memory be reclaimed other
> way?

Standalone Forths are not designed as fully general-purpose OSs, but to 
support a particular main application with options (utilities, etc.). 
The main application stays in memory all the time, doing its thing. The 
options are mutually exclusive, though it's possible to create branches 
each capable of supporting a mutually exclusive option.

> At my current level I'm familiar just with FORGET/MARKER, that will remove
> everything "since the given point" - that's why I'm asking for more
> sophisticated approach.

Look at the Memory Allocation wordset. It's primarily for data, but it's 
data that tends to occupy the most space, after all.

Yes, it's technically possible to make a standalone Forth that compiles 
relocatable apps that can be loaded from binary and discarded, but to 
date no one has done so that I know of. The reason, I think, is that 
there isn't sufficient incentive given the very small memory footprint 
that Forth programs require and the presence of tools such as 
ALLOCATE/FREE that makes it easy to manage large data buffers if 
necessary. Forthers are generally less interested in solving 
hypothetical problems than in practical, real-life challenges that pay 
the bills.

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]

#11141

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

> Most of the memory required by a browser (or other memory-hogging apps) 
> is actually data storage. If you write your app to use ALLOCATE/FREE you 
> can release that space without necessarily "unloading" the app. When you 
> re-activate the app it will allocate data space it needs.

Thanks, I'll look for some more about ALLOCATE/FREE.

> Standalone Forths are not designed as fully general-purpose OSs, but to 
> support a particular main application with options (utilities, etc.). 

Yes - and I'm pondering about possibility to create such "general-purpose
OS" written in Forth, instead in C. Not that I'm going to start designing
one tomorrow ;) - just wondering, is such functionality available. But it
doesn't seem so at the moment.

>> At my current level I'm familiar just with FORGET/MARKER, that will remove
>> everything "since the given point" - that's why I'm asking for more
>> sophisticated approach.
>
> Look at the Memory Allocation wordset. It's primarily for data, but it's 
> data that tends to occupy the most space, after all.
>
> Yes, it's technically possible to make a standalone Forth that compiles 
> relocatable apps that can be loaded from binary and discarded, but to 
> date no one has done so that I know of. The reason, I think, is that 
> there isn't sufficient incentive given the very small memory footprint 
> that Forth programs require and the presence of tools such as 
> ALLOCATE/FREE that makes it easy to manage large data buffers if 
> necessary. Forthers are generally less interested in solving 
> hypothetical problems than in practical, real-life challenges that pay 
> the bills.

Well, man cannot live by bread alone...
-- 
Forth is a preserver of health (Hippocrates)

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

#11143

Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> writes:
> Yes - and I'm pondering about possibility to create such "general-purpose
> OS" written in Forth, instead in C. Not that I'm going to start designing
> one tomorrow ;) - just wondering, is such functionality available. But it
> doesn't seem so at the moment.

I think Forth traditionally wants to put all the code into a single
chunk of memory.  And for a "general purpose OS" you really want some
kind of memory protection between processes so they don't trash each
other by accident.  You could use either the CPU's memory protection
hardware (if it has some), or special versions of ! and @ that checked
against some boundaries.  You'd also be able to implement address
translation with either of those methods.  

You wouldn't even have to use ALLOCATE.  You could use an ALLOT-like
allocator and just shuffle images around to keep memory contiguous, like
old fashioned mainframe OS's did.  

It's not real clear to me what kind of programs you'd want to write
under such an OS, but it could be fun as an educational or class
project.

I wonder if DCPU-16 would be an interesting target platform for it.
This is a virtual 16-bit CPU representing the shipboard computer on a
spaceship in a new Minecraft-ish game.  I don't know anything about it
(I've never played Minecraft either) but it's been getting quite a bit
of attention in nerd circles, various compilers have been targeted to
it, etc.

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

#11148

In comp.lang.forth, Paul Rubin wrote:

> You wouldn't even have to use ALLOCATE.  You could use an ALLOT-like
> allocator and just shuffle images around to keep memory contiguous, like
> old fashioned mainframe OS's did.  

But what about jump target addresses, branching etc.? Was it recalculated in
the real time? How was recognized, what is a program, and what part is a
binary data (say JPG-image data, or widgets' images)?

> It's not real clear to me what kind of programs you'd want to write
> under such an OS, but it could be fun as an educational or class
> project.

At the moment I've got no idea either - just considering, what is possible
to be done.

> I wonder if DCPU-16 would be an interesting target platform for it.
> This is a virtual 16-bit CPU representing the shipboard computer on a
> spaceship in a new Minecraft-ish game.  I don't know anything about it
> (I've never played Minecraft either) but it's been getting quite a bit
> of attention in nerd circles, various compilers have been targeted to
> it, etc.

Maybe it's worthy to take a look at it.
-- 
Forth is a preserver of health (Hippocrates)

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

#11155

Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> writes:
>> allocator and just shuffle images around to keep memory contiguous, like
>> old fashioned mainframe OS's did.  
>
> But what about jump target addresses, branching etc.? Was it recalculated in
> the real time? How was recognized, what is a program, and what part is a
> binary data (say JPG-image data, or widgets' images)?

That stuff was before my time, but I think in the PDP-10, they may have
had a hardware register containing an address offset, that would get
updated when the program got moved.  They must have also had an address
range trap so your program couldn't clobber someone else's.  I remember
reading early Unix on the PDP-11/20 had no protection at all, and it was
easy to crash the whole multi-user box by accident.  On at system they
may have just compiled position-independent code (all jump addresses are
relative, etc).

> At the moment I've got no idea either - just considering, what is
> possible to be done.

Well, you're in the same situation as any other OS writer, a world of
possibilities is before you.  I see at xen.org that one of the selling
points of the Xen hypervisor (sort of a hardware abstraction layer
without an OS, that you run OS's on top of) is that it's "small", since
it's "only" 150,000 lines of C. :-P

>> I wonder if DCPU-16 would be an interesting target platform for it.
> Maybe it's worthy to take a look at it.

Might be an interesting target for Forth in general.

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

#12098

On Wed, 11 Apr 2012 08:41:12 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

> Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> writes:
> >> allocator and just shuffle images around to keep memory contiguous, like
> >> old fashioned mainframe OS's did.  
> >
> > But what about jump target addresses, branching etc.? Was it recalculated in
> > the real time? How was recognized, what is a program, and what part is a
> > binary data (say JPG-image data, or widgets' images)?
> 
> That stuff was before my time, but I think in the PDP-10, they may have
> had a hardware register containing an address offset, that would get
> updated when the program got moved.  They must have also had an address
> range trap so your program couldn't clobber someone else's.  I remember

The first model PDP-10 from DEC, KA10, had two sets of base/offset and
limit register, for two halves of the address space, boringly named
'low segment' and 'high segment'. MIT (ITS) and BBN (TENEX) each
designed and built their own paging hardware to replace the DEC
scheme. DEC got the hint and KI10, KL10, KS10 models had paging.

> reading early Unix on the PDP-11/20 had no protection at all, and it was
> easy to crash the whole multi-user box by accident.  On at system they
> may have just compiled position-independent code (all jump addresses are
> relative, etc).
> 
That's certainly possible, using addressing modes 67 and 77. But I
don't know if that's what actually was done.

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

#12100 — PDP-11 [Was: Memory management]

Paul Rubin <no.email@nospam.invalid> wrote:

> I remember reading early Unix on the PDP-11/20 had no protection at
> all, and it was easy to crash the whole multi-user box by accident.

Just as an aside, the PDP-11 was a superb Forth target.  A lot of
primitives were two or three instructions, and the interrupt structure
and the I/O subsystem were very well-designed; it is certainly the
nicest polyFORTH system I have used.  It's worth noting the
performance advantage you can get from I/O hardware that is really
straightforward: for example, it was possible to handle a serial
interrupt with just a few instructions.  This made it possible to
handle many terminals on what was a pretty small machine.

Andrew.

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

#12109 — Re: PDP-11

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> Just as an aside, the PDP-11 was a superb Forth target.  A lot of
> primitives were two or three instructions, and the interrupt structure
> and the I/O subsystem were very well-designed; it is certainly the
> nicest polyFORTH system I have used.  

Yeah, I remember thinking "jmp @(r5)+" sure sounds like the NEXT
for a threaded interpreter (I didn't know Forth terminology at
the time though).  The TI MSP430 has a similar but not identical
instruction set and it looks pretty attractive as an embedded Forth
target for similar reasons.

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

#12110 — Re: PDP-11

Paul Rubin <no.email@nospam.invalid> writes:
> Yeah, I remember thinking "jmp @(r5)+" sure sounds like the NEXT

Hmm, maybe I meant just "jmp (r5)+" without the extra layer of
indirection.  I'm sure there were suitable variants for DTC and ITC,
etc.  It's been a while since I thought about this.

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

#12147 — Re: PDP-11 [Was: Memory management]

On May 13, 3:18 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Paul Rubin <no.em...@nospam.invalid> wrote:
> > I remember reading early Unix on the PDP-11/20 had no protection at
> > all, and it was easy to crash the whole multi-user box by accident.
>
> Just as an aside, the PDP-11 was a superb Forth target.  A lot of
> primitives were two or three instructions, and the interrupt structure
> and the I/O subsystem were very well-designed; it is certainly the
> nicest polyFORTH system I have used.  It's worth noting the
> performance advantage you can get from I/O hardware that is really
> straightforward: for example, it was possible to handle a serial
> interrupt with just a few instructions.  This made it possible to
> handle many terminals on what was a pretty small machine.
>
> Andrew.

It's a shame this stuff isn't documented anywhere. I find the old
stuff very interesting!

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

#12170 — Re: PDP-11 [Was: Memory management]

Mark Wills <markrobertwills@yahoo.co.uk> wrote:
> On May 13, 3:18?pm, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> Paul Rubin <no.em...@nospam.invalid> wrote:
>> > I remember reading early Unix on the PDP-11/20 had no protection at
>> > all, and it was easy to crash the whole multi-user box by accident.
>>
>> Just as an aside, the PDP-11 was a superb Forth target. A lot of
>> primitives were two or three instructions, and the interrupt structure
>> and the I/O subsystem were very well-designed; it is certainly the
>> nicest polyFORTH system I have used. It's worth noting the
>> performance advantage you can get from I/O hardware that is really
>> straightforward: for example, it was possible to handle a serial
>> interrupt with just a few instructions. This made it possible to
>> handle many terminals on what was a pretty small machine.
> 
> It's a shame this stuff isn't documented anywhere. I find the old
> stuff very interesting!

I think the '11 is pretty well documented, actually, partly because it
was so important for UNIX.

This is IMO of more than purely nostalgic interest.  The '11 was, as
Tony Hoare said of ALGOL 60, not only an improvement on its
predecessors but also on nearly all its successors.  There is a
parallel with Forth, for sure.

Andrew.

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

#12180 — Re: PDP-11 [Was: Memory management]

In article <b9886908-4b87-4518-a572-18e0e3b9beee@z19g2000vbe.googlegroups.com>,
Mark Wills  <markrobertwills@yahoo.co.uk> wrote:
>On May 13, 3:18=A0pm, Andrew Haley <andre...@littlepinkcloud.invalid>
>wrote:
>> Paul Rubin <no.em...@nospam.invalid> wrote:
>> > I remember reading early Unix on the PDP-11/20 had no protection at
>> > all, and it was easy to crash the whole multi-user box by accident.
>>
>> Just as an aside, the PDP-11 was a superb Forth target. =A0A lot of
>> primitives were two or three instructions, and the interrupt structure
>> and the I/O subsystem were very well-designed; it is certainly the
>> nicest polyFORTH system I have used. =A0It's worth noting the
>> performance advantage you can get from I/O hardware that is really
>> straightforward: for example, it was possible to handle a serial
>> interrupt with just a few instructions. =A0This made it possible to
>> handle many terminals on what was a pretty small machine.
>>
>> Andrew.
>
>It's a shame this stuff isn't documented anywhere. I find the old
>stuff very interesting!

I've the FORTRAN and Task Building manuals for the PDP (1979).
Plans are to scan them and put them on the Internet, possibly
risking the wrath of Intel, who owns probably the copyright of those
manuals.

An assembly language manual is definitively more interesting.

Groetjes Albert


--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#12190 — Re: PDP-11 [Was: Memory management]

On Sun, 13 May 2012 07:46:58 -0700 (PDT), Mark Wills 
<markrobertwills@yahoo.co.uk> wrote:
> On May 13, 3:18 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> Paul Rubin <no.em...@nospam.invalid> wrote:
>> > I remember reading early Unix on the PDP-11/20 had no protection at
>> > all, and it was easy to crash the whole multi-user box by accident.
>>
>> Just as an aside, the PDP-11 was a superb Forth target.  A lot of
>> primitives were two or three instructions, and the interrupt structure
>> and the I/O subsystem were very well-designed; it is certainly the
>> nicest polyFORTH system I have used.  It's worth noting the
>> performance advantage you can get from I/O hardware that is really
>> straightforward: for example, it was possible to handle a serial
>> interrupt with just a few instructions.  This made it possible to
>> handle many terminals on what was a pretty small machine.
>>
>> Andrew.
>
> It's a shame this stuff isn't documented anywhere. I find the old
> stuff very interesting!

Most PDP-11 stuff is well documented online.  Bitsavers is a good
place to start.  http://www.bitsavers.org/

Some of us still run PDP-11s and PDP-11 FIG-Forth - under RT-11 in 
my case.

-- 
Cheers,
Stan Barr     plan.b .at. dsl .dot. pipex .dot. com

The future was never like this!

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

#11166

Paul Rubin <no.email@nospam.invalid> wrote:

> You wouldn't even have to use ALLOCATE.  You could use an ALLOT-like
> allocator and just shuffle images around to keep memory contiguous, like
> old fashioned mainframe OS's did.

What are you talking about here?

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

#11135

On Apr 10, 4:56 pm, Zbiggy <zbigniew2011REM...@gmail.REMOVE.com>
wrote:
> If I don't need particular application at the moment: does there exists any
> way to get rid of it - of course I don't mean here neither FORGET, nor
> MARKER; just "close window" or something like that - then to reclaim the
> freed memory?

There is if the implementation provides it.

How easy it is to find a modern implementation that provides that is
another question ~ various versions of that were more common thirty
years ago on 8bit systems with 32K to 256K of RAM. Most standalone
systems today are for micro-controllers, and more often for persistent
tasks. And if some supplementary maintenance facilities are provided,
they could indeed ALLOCATE some RAM to generate an instance and FREE
that RAM when the instance is done with ~ but there's no particular
benefit even in that context in deleting the portion of the dictionary
that is supporting the task. The point is that when the maintenance is
done and the main task(s) restarted, they'll be using that RAM
themselves, but the dictionary in some form of persistent flash RAM
used as ROM means that you're better off *not* reclaiming that memory,
since you have much less flash wear just leaving that in the
dictionary and using it when you need it.

And general purpose utilities in that kind of mix and match setting
are more often done with Forth as an application of an operating
system ~ by launching an instance of the Forth itself set to compile
and run the application, so that you kill the instance of the app by
killing that instance of the Forth. I do that on occasion when using
gforth. Its not even MARKER and execute the marker ~ its just click a
script that launches gforth with that application as the script name
on the command line, then kill the whole thing when you're done.

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

#11142

In comp.lang.forth, BruceMcF wrote:

> [..] The point is that when the maintenance is
> done and the main task(s) restarted, they'll be using that RAM
> themselves, but the dictionary in some form of persistent flash RAM
> used as ROM means that you're better off *not* reclaiming that memory,
> since you have much less flash wear just leaving that in the
> dictionary and using it when you need it.
>
> And general purpose utilities in that kind of mix and match setting
> are more often done with Forth as an application of an operating
> system ~ by launching an instance of the Forth itself set to compile
> and run the application, so that you kill the instance of the app by
> killing that instance of the Forth. I do that on occasion when using
> gforth. Its not even MARKER and execute the marker ~ its just click a
> script that launches gforth with that application as the script name
> on the command line, then kill the whole thing when you're done.

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.
-- 
Forth is a preserver of health (Hippocrates)

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

#11145

On 11 Apr 2012 10:39:16 +0100, Zbiggy
<zbigniew2011REMOVE@gmail.REMOVE.com> 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.
...
>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.

Why does anyone need a new O/S now?

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]

Page 1 of 2  [1] 2  Next page →

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

csiph-web