The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: bqt@update.uu.se (Johnny Billquist)
Subject: [TUHS] Emacs and undump
Date: Mon, 27 Feb 2017 11:24:47 +0100	[thread overview]
Message-ID: <145bd49e-7390-034b-f8c3-002e6e6f15fe@update.uu.se> (raw)
In-Reply-To: <mailman.342.1488180370.3779.tuhs@minnie.tuhs.org>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2484 bytes --]

On 2017-02-27 08:26, Lars Brinkhoff <lars at nocrew.org> wrote:
> Tim Bradshaw wrote:
>>> David wrote:
>>> I remember that GNU Emacs launched the first time and then dumped
>>> itself out as a core file. Each subsequent launch would then ‘undump’
>>> itself back into memory. All this because launching emacs the first
>>> time required compiling all that lisp code.
>> It still works like that.  Indeed that's the conventional way that
>> Lisp systems tend to work for delivering applications
> Emacs came from ITS, and many Lisps derive from Maclisp which also came
> from ITS.  In ITS, it was common for applications to be dumped into a
> loadable core image, even if they were written in assembly language.

Not only i ITS. This is how things work in OS/8, for example. I believe 
it is also how things work in TOPS-10 and quite possible also in TOPS-20.
Not sure about RT-11, but I wouldn't be surprised if that's the way 
there too.

Essentially, the linker leaves the image in memory. It does not write it 
to a file. And then, the command decode have a command for dumping your 
memory to disk, as a runable image. There is some information kept 
around that the linker sets up, which means you don't normally have to 
tell the command decoder which parts of memory to save, or what the 
start address is, and so on. But you can also give that information in 
your save command.

One of the nice things of this approach is that you can load an image 
into memory, and then use the debugger to look around in it, change it, 
or run it. And if the program exists, it is still in memory, including 
all data, which means you can check the state of everything at exit 
time. And of course, if you want to, you can load a program, patch 
around in it, in memory, and then run it. And, of course, you can load a 
program, run some part of it, and dump it to disk at that stage, so all 
initializations have been done.

Your memory is always around, and is not tied to a process that comes 
and goes.

Of course, the back side of that is that you can't really run several 
programs at once.

But it's not hard to see that RMS and GNU Emacs (coming from these 
systems) wanted the same thing again. It do have some points.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


       reply	other threads:[~2017-02-27 10:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.342.1488180370.3779.tuhs@minnie.tuhs.org>
2017-02-27 10:24 ` Johnny Billquist [this message]
2017-02-27 10:30   ` Lars Brinkhoff
2017-02-27 10:47     ` Johnny Billquist
2017-02-27 14:04       ` Arthur Krewat
2017-02-28 11:55         ` Ronald Natalie
     [not found] <mailman.346.1488208394.3779.tuhs@minnie.tuhs.org>
2017-02-27 20:09 ` Johnny Billquist
2017-02-27 20:26   ` Lars Brinkhoff
2017-02-27 21:06     ` Johnny Billquist
     [not found] <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
2017-02-26 19:16 ` David
2017-02-26 19:28   ` Mantas Mikulėnas
2017-02-27  6:41   ` Tim Bradshaw
2017-02-27  7:19     ` Lars Brinkhoff
2017-02-27  7:26       ` Warner Losh
2017-02-27  8:12         ` Nick Downing
2017-02-27 14:33           ` Derek Fawcus
2017-02-27 14:50             ` Nick Downing
2017-02-27 15:43               ` Derek Fawcus
2017-02-27 16:43             ` Joerg Schilling
     [not found]               ` <CAH1jEzZjvOhHnbvsWcw8gbx9d_W47DbBidYd_tteCr5dC6H2ng@mail.gmail.com>
2017-02-28  0:02                 ` Nick Downing
2017-02-27 12:59       ` tfb
2017-02-27 10:35   ` Joerg Schilling
2017-02-27 15:13     ` Tony Finch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=145bd49e-7390-034b-f8c3-002e6e6f15fe@update.uu.se \
    --to=bqt@update.uu.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).