14 Nov
2021
14 Nov
'21
1:13 p.m.
On 2021-11-12 22:36, Thomas DeBellis wrote:
gnuemacs?? There's a processor limitation or
hardship?? That's never
occurred to me as I'm running on Tops-20 right now, which is plenty
different from anything else.? The M1 is still fairly new, so maybe
people haven't gotten around to gnuemacs just yet.? Some will insist on
vi...
It's more properly a question of how does a executable file look like
for this specific platform. So it's directly about OS behavior, but this
also leads to processor specifics.
Think about thinks like dynamically loaded libraries, the startup code,
having the stack sane, registers setup, and all kind of stuff that ld
would normally do for you. GnuEmacs have to do all of that itself.
And there is plenty of compiled code in GnuEmacs, as compared to lisp
code. The whole lisp system itself, for example. But also some core
functionality, which looks like Lisp functions are in fact written in C
for speed.
But from this perspective, it's all very straight forward from a porting
point of view. The problem do come when you want to basically dump all
memory as a runnable file. (And you do not want to include shared
libraries in that file, but instead actually set it up to load those
libraries again when running, and all that other stuff mentioned above.)
Johnny
I have done a microscopic amount of programming in gnu LISP to customize
it; in other words to make gnemacs work more like Tops-20/TENEX/ITS TECO
based EMACS so that it doesn't drive me crazy.? This code functions on
the other platforms I use (Mac OSX, Windows, Ubuntu) with no
modifications.? Obviously some kinds of key bindings are tricky as well
as fonts.
If you want to call it this, gnemacs does have some compiled code, that
is C based built-in functions.? I have had occasion to look at some of
the C source in order to make sure that I understood actually what was
going to be done.? I don't recall seeing any kind of a processor
restriction per se, although there could have been conditionals to
better leverage certain processors.
I guess you could differentiate it like the difference between MIDAS
based TECO and EMACS based TECO macros.
> ------------------------------------------------------------------------
> On 11/12/21 4:07 PM, Paul Koning wrote:
>
> I think Johnny was talking about current Emacs. That might explain why it's hard
to port -- for example, there is a Mac version (AquaMacs) but no Arm64 (Apple M1 chip)
version because of the trickery associated with the dump machinery.
>
> paul
>> ------------------------------------------------------------------------
>> On Nov 12, 2021, at 3:49 PM, Thomas DeBellis<tommytimesharing at gmail.com>
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
--
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