As Paul mentioned, this was about GnuEmacs. Sorry, I should have been
more clear.
The lisp code is sortof semicompiled. I don't remember for sure, but I
think it's tokenized. Anyway, all of it read in and processed, and
sitting in memory, and then the memory dump is done, so you don't read
in 50 lisp modules every time you start GnuEmacs.
And I actually still program in TECO from time to time, under RSX. :-)
Johnny
On 2021-11-12 21:49, Thomas DeBellis wrote:
> I'm not 100% sure, but I don't believe that ITS/Tops-20/TENEX Emacs
> quite does this. It is built on top of TECO, which you will recall as a
> language that is so terse that it looks like line noise. I don't think
> it's a very big stretch to compare it a byte code interpreter.
>
> I do not recall that the EMACS libraries that are loaded are not /quite/
> compiled. They have all the comments and unnecessary white space
> stripped out, which would, of course speed execution.
>
> gnuEmacs does a similar thing for the LISP code; it's still interpreted
> as I recall.
>
> On 11/12/21 10:59 AM, Johnny Billquist wrote:
>> RMS kept the idea alive in Emacs, where even today you fire up the
>> core system, load all kind of libraries, and then you do a memory
>> dump, which is the runnable Emacs image.
>>
>> JOhnny
>>
>> On 2021-11-12 16:06, Thomas DeBellis wrote:
>>> It's not uncommon or it least it didn't used to be. Here are three
>>> examples:
>>>
>>> First, I believe early versions of Smalltalk did exactly this.
>>>
>>> Second, at WPI, we implemented two commands called freeze and thaw,
>>> which would take all the information in the currently running job
>>> (AC's, PC, open files, Etc.) and write them into a file. You could
>>> ^C, freeze, come back later, thaw the .ICE file (frozen job, get it?)
>>> and be right where you were. One common use was when a dial up was
>>> abruptly disconnected by call waiting. The monitor would notice you
>>> were detached and perform a freeze on your behalf, thus both freeing
>>> up the job slot and not losing your work. Saved me a bunch of
>>> TECO'ing. It could have been extended to batch jobs running out of
>>> processor time, but I don't remember if it was.
>>>
>>> I liked it so much that I tried to implement it at Columbia for
>>> Tops-20. Tried... I think the problem I ran into was that I
>>> couldn't find out timers and get the same fork handles. Or one of
>>> the problems. Another was security, which I'll discuss below.
>>>
>>> Third, at Columbia, it was used extensively in our chronically CPU
>>> starved environment:
>>>
>>> * The EXEC could save the PCL environment (but I think this originally
>>> was part of the CMU implementation)
>>> * The mailing system keeps a binary file of forwarding bindings. If
>>> you edit the text source, the newer write date is noticed and the
>>> binary is 'recompiled'
>>> * I lifted the feature for LPTSPL's LPFORM.INI parser when I realized
>>> how often it was getting reparsed (basically after any idle period
>>> between jobs)
>>>
>>> From the information security standpoint, you have to consider the
>>> usage of these kinds of files. Obviously, you wouldn't want to thaw
>>> something with JACCT set unless the existing job had the ability to
>>> get that, was [1,2] without some fairly careful checking. Ditto
>>> Tops-20, if the fork had capabilities. I mean, if somebody could get
>>> write access to the binary, then they could potentially compromise
>>> system security with a little strategic FILDDT'ing (or EXAMINE and
>>> DEPOSIT, if it came to that).
>>>
>>> A 'legitimately' corrupt binary could also crash the fork on start
>>> up, but I don't recall as we ever fully addressed that. I think a
>>> checksum would have been the obvious start, but I guess we didn't
>>> want to spend the cycles.
>>>
>>> In these days of multi-gigahertz processors, I don't see the children
>>> discussing it much at all.
>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> On 11/12/21 9:24 AM, Paul Koning wrote:
>>>>
>>>> That's a bit like how RSX-11/D and IAS boot -- by reloading the
>>>> image of memory when you issued the SAV command. Pretty clever: you
>>>> set things up the way you want them to be, and then you make that
>>>> state persistent.
>>>> paul
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> On Nov 11, 2021, at 6:22 PM, Johnny Billquist <bqt at softjar.se>
>>>>> wrote: I must admit that I hadn't considered the possibility of
>>>>> just saving the core. Which of course can accomplish the same thing
>>>>> in a neat way.
>>>>>
>>
--
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