It might be possible but you will have to work hard on finding ways to
overlay it.
If you can do that, and just have a couple of K of space left, you'll be
good. It might be rather slow, but it would still have the same
capabilities.
Johnny
On 2016-05-30 04:10, Dave McGuire wrote:
I think this is fantastic. Is there any chance of this running on
non-PLUS RSX? I'm running it on several non-22-bit systems (real iron)
at LSSM. I'd love to have an emacs-style editor available on those systems.
-Dave
On 05/29/2016 01:31 PM, Johnny Billquist wrote:
Not sure if anyone really cares, but I figure it
don't hurt to tell
anyway...
I have for many years used a very old version of MicroEMACS for RSX. I
eventually started searching around for alternatives, but realized
during that search that most Emacs clones are horribly huge (including
MicroEMACS), not portable at all (even if they claim to be), and
generally also expects to just allocate gobs of memory to keep all data
in ram.
Now, RSX, being a PDP-11 OS, have a 16-bit address space limitation. So
just allocating memory is never going to be a solution. There is a C
compiler, which is pretty much ANSI C. But it is not Unix, and gives you
the C standard IO library, but not low level Unix calls.
On the plus side, most of the library can sit in supervisor space, and
not consume any memory in your process space.
Clones I've looked at:
MicroEMACS - Huge and difficult to port. Use lots of memory.
JOVE - Small (runs on 2.11BSD), but horribly difficult to port.
mg - Huge and difficult. Use lots of memory.
AMIS - Huge, and written in Pascal. Not necessarily bad, but adapting
the code to a new system requires mucking around some, made worse by the
small differences in different Pascal compilers, and the lack of any
preprocessor, as well as the bonehead type system in Pascal. Also use
lots of memory, but it has been made to run on small machines (including
PDP-11 with RSTS/E) in the past, so it is a solveable problem.
Atto - Hard to port.
JED - Huge.
I looked at dozens more, which were not even worth looking deeper into,
or to list here.
The long and short of it was that, even though there are numerous
implementations out there, they all suck, from my point of view.
With all that in mind, I decided to write my own Emacs clone instead
(yes, I got horribly upset with the lousy quality of most code I looked
at, if someone wants to hear some rants, contact me privately).
I started about a month ago, and at this point, it's working, and quite
useful. And I guess if other people are in a similar situation, they
might be interested in looking into this, and possibly make use of it.
Quick run through:
. ANSI C sources.
. Mostly uses the C standard IO library. Exception is terminal I/O,
which requires some small pieces reimplemented if you want to port it.
So, if you have an ANSI C compiler, porting should be very low effort.
. Only works on ANSI terminals today. It would be doable to extend with
other terminal support, but I don't have any need, and since I do not
have, nor want to depend on curses, it will require coding to either
have a module to uses curses, if that is wanted, or handling of specific
terminals.
. The compiled code, using PDP-11 C, ends (at the moment) up at around
36 Kbytes of binary. The C library and RMS sits mostly in supervisor
mode, and is not accounted for in this.
. Data usage is about 8K for various storage and strings.
. Code dependecies are very much in a tree, so overlaying is easy, if
wanted/needed, and that capability exists on the host.
. Since I compile with split I/D space, this means than about 56K of
dataspace can be used for buffering of various sorts.
. File buffers are kept in a temporary file, and read/written to memory
as needed (pretty much a demand-paging virtual memory implementation in
the application).
. The virtual, paged memory is about 4G, which is an absolute limit on
memory usage. Practical file limit is (I would guesstimate) around 1G.
. Most basic EMACS editing functions are implemented, including split
windows, multiple buffers, kill buffer, moving around in various ways,
and some semi-stupid automatic indentation handling for C code. Also
incremental searching in a proper fashion.
. Speed, tested on a real PDP-11/93 is pretty acceptable. Testing on a
file about 1000 lines takes a couple of second to open, and a couple of
seconds if you try to search from the start to the end. Most other
things move faster.
. The program is not suitable for editing binary data. The C standard
I/O library don't really lend itself to binary I/O, and this code have
to live within those constraints.
There are still lots of functionality that I'm working on adding, such
as repeats (almost done) and macros (only started thinking about it).
If people have functions they consider extra important, let me know, and
I'll see if I can add them. If people want to contribute code, I'll be
happy to incorporate changes as well, as long as they make sense.
The sources, as well as a compiled RSX-11M-PLUS binary for PDP-11 C
V1.2, can be found at HECnet: MIM::DU:[NEMA], or
ftp:://nema at mim.update.uu.se/.
This editor is now installed as ...EMA on MIM::, so if you type "EMA
filename", you can see how it works there.
It is now my tool for doing further development. I have ditched
MicroEMACS. So I'm constantly testing the thing, as I am developing
it... :-)
Maybe someone will find it useful...
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