Anybody booted an OS from scratch on still-running PDP-10?
Robert Maas, http://tinyurl.com/uh3t
machine, to avoid any dependency on C or other high-level language
during the bootstrap process, to avoid the claim that C is more
important than Lisp because Lisp requires C but nothing requires
Lisp. It would be nice to demonstrate that Common Lisp can be
created without any help from C, nor any other programming language
beyond assembly language, either to compile Lisp itself, or to
compile the operating system that Lisp requires to operate.
Somebody in that thread on that other newsgroup mentionned this
newsgroup, which I never heard of before, so that's why I'm
suddenly here. So, does anybody here know of anyone who has
hand-coded some sort of bootstrap program such as DDT (on a PDP-10
of course) and from that point build an OS sufficient to support a
filesystem whereupon compiling a Common Lisp program would make
sense? Or use some very old OS that was hand-coded in assembly
language for PDP-10? Then has any such person bootstrapped to any
version of Lisp that is sufficient to write binary files (needed to
compile Lisp to a file) from within Lisp? Once that point is
reached, I believe it would be relatively easy to bootstrap the
rest of the way to a fullfledged minimal subset of Common Lisp, and
then to all of Common Lisp.
John Sauter
> Recently the topic came up of bootstrapping Common Lisp from a bare
> machine, to avoid any dependency on C or other high-level language
> during the bootstrap process, to avoid the claim that C is more
> important than Lisp because Lisp requires C but nothing requires
> Lisp. It would be nice to demonstrate that Common Lisp can be
> created without any help from C, nor any other programming language
> beyond assembly language, either to compile Lisp itself, or to
> compile the operating system that Lisp requires to operate.
>
> newsgroup, which I never heard of before, so that's why I'm
> suddenly here. So, does anybody here know of anyone who has
> hand-coded some sort of bootstrap program such as DDT (on a PDP-10
> of course) and from that point build an OS sufficient to support a
> filesystem whereupon compiling a Common Lisp program would make
> sense? Or use some very old OS that was hand-coded in assembly
> language for PDP-10? Then has any such person bootstrapped to any
> version of Lisp that is sufficient to write binary files (needed to
> compile Lisp to a file) from within Lisp? Once that point is
> reached, I believe it would be relatively easy to bootstrap the
> then to all of Common Lisp.
You seem to be under the impression that operating systems are based on
the C language. This is not the case for older systems such as the
PDP-10. Except for Unix, operating systems developed before about 1980
were coded in assembly language. If you can find a working PDP-10, you
can boot its native operating system, TOPS-10, and run its native
version of Lisp, which is Lisp 1.6, without any fear of being dependent
on the C language.
Finding a C-free implementation of Common Lisp may be a harder problem
to solve. I checked on GNU Common Lisp, but it is obviously coded in C.
John Sauter (John_...@systemeyescomputerstore.com)
jmfbahciv
> machine, to avoid any dependency on C or other high-level language
> during the bootstrap process, to avoid the claim that C is more
> important than Lisp because Lisp requires C but nothing requires
> Lisp. It would be nice to demonstrate that Common Lisp can be
> created without any help from C, nor any other programming language
> beyond assembly language, either to compile Lisp itself, or to
> compile the operating system that Lisp requires to operate.
>
> Somebody in that thread on that other newsgroup mentionned this
> newsgroup, which I never heard of before, so that's why I'm
> suddenly here. So, does anybody here know of anyone who has
> hand-coded some sort of bootstrap program such as DDT (on a PDP-10
> of course) and from that point build an OS sufficient to support a
> filesystem whereupon compiling a Common Lisp program would make
> sense?
You didn't have to do that with a -10 but John told you about that.
There was a company, whose name I cannot recall, who made LISP
machines. Kalman Reti, Bob Houk were people who worked there.
I want to say it was Semantics but that's not right. It was
on the stock exchange during the 1980s. I'm pretty sure the
name started with an s.
I don't know if any of their work exists nor what happened to it.
I lost track.
/BAH
Mike Ross
Symbolics.
http://en.wikipedia.org/wiki/Symbolics
Mike
--
http://www.corestore.org
'As I walk along these shores
I am the history within'
Mark Crispin
> Finding a C-free implementation of Common Lisp may be a harder problem
> to solve. I checked on GNU Common Lisp, but it is obviously coded in C.
TOPS-20 Common Lisp was written in assembly language.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
van...@vsta.org
> ... I actually got a
> course in introductory Lisp, taught by JMcC in 1961 or 1962.
> We punched a lot of parens on cards.
There was a short set of MIT course notes "Lisp: A Radical Introduction",
something like that. Does anybody have a copy? I remember it as being
amazingly good at introducing the true heart of Lisp.
Thanks,
Andy Valencia
Rob Warnock
+---------------
| Finding a C-free implementation of Common Lisp may be a harder problem
| to solve. I checked on GNU Common Lisp, but it is obviously coded in C.
Well, *tiny* parts of it [~1%] are coded in C [initial startup code,
some low-level O/S interactions (e.g., signal handling), the GC],
but the vast majority [~99%] is coded in Common Lisp itself and
compiled directly to native machine code.
Your point remains, however, that it's certainly not C-free.
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
jmfbahciv
That's it. Thank you very much.
/BAH
jmfbahciv
Yay! How are you?
<snip>
/BAH
Carl Appellof
"jmfbahciv" <jmfbahciv@aol> wrote in message
news:4YednUVgScL3ju_V...@rcn.net...
> Mike Ross wrote:
>> Symbolics.
>>
>> http://en.wikipedia.org/wiki/Symbolics
>
> That's it. Thank you very much.
>
>
> /BAH
I followed a similar link to Lisp Machines Inc.
(http://en.wikipedia.org/wiki/Lisp_Machines%2C_Inc.)
Interesting interplay between the two companies and their founders'
philosophies. Both companies demonstrate that a machine can run Lisp as its
native language.
Carl
Carl Appellof
"jmfbahciv" <jmfbahciv@aol> wrote in message
news:4YednUVgScL3ju_V...@rcn.net...
> Mike Ross wrote:
I followed a similar link to Lisp Machines Inc.
(http://en.wikipedia.org/wiki/Lisp_Machines)
Rich Alderson
jaycx2.3....@spamgourmet.com.remove (Robert Maas,
http://tinyurl.com/uh3t) writes:
> Somebody in that thread on that other newsgroup mentionned this
> newsgroup, which I never heard of before, so that's why I'm
> suddenly here. So, does anybody here know of anyone who has
> hand-coded some sort of bootstrap program such as DDT (on a PDP-10
> of course) and from that point build an OS sufficient to support a
> filesystem whereupon compiling a Common Lisp program would make
> sense?
> Or use some very old OS that was hand-coded in assembly
> language for PDP-10?
Well, ITS (the Incompatible Timesharing System) was first coded for the PDP-6,
which is architecturally very close to the PDP-10, and was later ported to the
10. MACLISP, one of the important influences on Common Lisp, was written in
MIDAS, the PDP-6/10 assembler created for ITS. From MACLISP came not only
Common Lisp, but also Scheme (and Rabbit, a Scheme compiler) and MACSYMA.
MACLISP was ported to TOPS-20 (and its ancestor TENEX), which may seem very old
to you but which is still under development at XKL, as well as to WAITS.
> Then has any such person bootstrapped to any
> version of Lisp that is sufficient to write binary files (needed to
> compile Lisp to a file) from within Lisp? Once that point is
> reached, I believe it would be relatively easy to bootstrap the
> rest of the way to a fullfledged minimal subset of Common Lisp, and
> then to all of Common Lisp.
There were several other lisps for the PDP-10, under different operating
systems. John Sauter mentioned LISP 1.6, which I believe ran under Tops-10 and
WAITS (the Stanford Artificial Intelligence Laboratory derivative which
diverged very very early). BBNLisp => Interlisp (later ported to a family of
Lisp machines developed by Xerox). Portable Standard Lisp (from Utah, basis of
the REDUCE mathematics package, similar in spirit to MACSYMA).
And there is ELISP, Rutgers' original implementation of Common Lisp, written
for TOPS-20; eventually, this became TOPS-20 Common Lisp.
All of these (with the possible exception of Utah's PSL, I simply don't
remember for certain) were all written in assembler and Lisp.
The C-based Lisps, such as Franz, were PDP-10 Lisp wannabees.
--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless
PacoLinux
Hi:
Another Lisp machine : http://www.unlambda.com/cadr
Paco
glen herrmannsfeldt
> On Sun, 6 Jul 2008, John Sauter posted:
>> Finding a C-free implementation of Common Lisp may be a harder problem
>> to solve. I checked on GNU Common Lisp, but it is obviously coded in C.
> TOPS-20 Common Lisp was written in assembly language.
I wonder, are there enough similarities between the 7090 and PDP-10
(in addition to word length) that 7090 assembly could be a starting
point for PDP-10 assembly?
-- glen
John Sauter
>
> I wonder, are there enough similarities between the 7090 and PDP-10
> (in addition to word length) that 7090 assembly could be a starting
> point for PDP-10 assembly?
>
subtracted from the address part of an instruction to form the effective
address. This compares to the PDP-10's 15 index registers, which are
added to the address part of an instruction.
The IBM 7090 does arithmetic into two registers, called the AC and MQ,
whereas the PDP-10 has 16 general registers (15 of which are also the
index registers) for arithmetic sources and destinations. The PDP-10
has 18-bit addresses compared to the IBM 7090's 15-bit addresses. The
IBM 7090 uses sign-magnitude arithmetic whereas the PDP-10 uses twos
complement.
The PDP-10's multi-register design is more like the IBM System/360 than
the IBM 7090, despite the shorter word length of IBM System/360.
John Sauter (John_...@systemeyescomputerstore.com)
glen herrmannsfeldt
(I wrote)
>> I wonder, are there enough similarities between the 7090 and PDP-10
>> (in addition to word length) that 7090 assembly could be a starting
>> point for PDP-10 assembly?
> Not really. The IBM 7090 has three index registers, which can be
> subtracted from the address part of an instruction to form the effective
> address. This compares to the PDP-10's 15 index registers, which are
> added to the address part of an instruction.
> The IBM 7090 does arithmetic into two registers, called the AC and MQ,
> whereas the PDP-10 has 16 general registers (15 of which are also the
> index registers) for arithmetic sources and destinations. The PDP-10
> has 18-bit addresses compared to the IBM 7090's 15-bit addresses. The
> IBM 7090 uses sign-magnitude arithmetic whereas the PDP-10 uses twos
> complement.
In those cases, the 7090 seems to be a subset of the PDP-10,
so it should be possible, though maybe not optimal, to directly
convert 7090 to PDP-10.
This would be similar to the way the 8086 is a superset of
the 8080 instruction set, such that with a little conversion
they are supposed to be source level compatible.
Subtracting index registers would seem to explain why 704
Fortran, presumably with similar index registers, stores
arrays in decreasing order in memory.
-- glen
John Sauter
While translation is certainly possible (for example, treat IBM 7090
assembly language as a high-level language and compile it) the result
would not be very useful, I think. The IBM 7090 did not have exec mode,
so all I/O was done by the application using the I/O instructions.
In a typical IBM 7090 installation, input was read from tape drive A5,
and output was written to A6 (print) and A7 (card punch). Those could
be emulated as files, of course, but the result would be like a Fortran
program that doesn't use the terminal.
The limit of 32,768 words of memory would cramp the style of any modern
programmer.
The IBM 7090 did not have a disk drive until late in its life, so
algorithms that required read-write storage were written to use tape
drives, rewinding them when necessary. An IBM 7090 doing a sort was
quite a sight, with all of its tape drives reading, writing or
rewinding. Translating that to the PDP-10 would result in a program
which used disk files as simulated tape drives, instead of using the
disk as a block-replaceable device, which would make sorting much more
efficient.
Even discounting the instruction set differences, the IBM 7090 and the
PDP-10 were different enough that I would not want a translated IBM 7090
program, even as a starting point. Professor McCarthy's Lisp and Chess
programs, for example, were rewritten from scratch for the PDP-10. As
far as I know, the programmers did not even consult the IBM 7090
assembly language listings.
John Sauter (John_...@systemeyescomputerstore.com)
Brian Harvey
> In those cases, the 7090 seems to be a subset of the PDP-10,
Yeah, but the 7090 (or at least the 7094, which is what I cut my teeth on)
had the CRQ (pronounced "crock" :-) instruction! The acronym is for "Convert
by Rotation from the MQ" and I don't remember the details, but it split the
contents of the MQ register into six 6-bit bytes, used each of them as an
index into a table in memory, and used what it found there to replace the
byte, more or less.
John Sauter <John_...@systemeyescomputerstore.com> writes:
>While translation is certainly possible (for example, treat IBM 7090
>assembly language as a high-level language and compile it) the result
>would not be very useful, I think. The IBM 7090 did not have exec mode,
>so all I/O was done by the application using the I/O instructions.
>In a typical IBM 7090 installation, input was read from tape drive A5,
>and output was written to A6 (print) and A7 (card punch). Those could
>be emulated as files, of course, but the result would be like a Fortran
>program that doesn't use the terminal.
If one were to use this architecture as the basis for anything, I think it'd
be wise to start with one particular 7094: the one at MIT that ran CTSS, one
claimant for the first practical timesharing system title. It had system
calls for I/O, a disk, etc. Thompson and Ritchie cite it as a source for
some of the ideas in Unix.
Of course the architecture had its flaws, such as the one-instruction user
program that would get the machine into an uninterruptable loop! Still,
some of us still have warm feelings toward the 7094. Its bootstrap loader
was an even more amazing kludge than the shadow ACs on the PDP-6.
Robert Maas, http://tinyurl.com/uh3t
> You seem to be under the impression that operating systems are
> based on the C language.
No, you are mistaken. My "impression" is that while very old
systems were based on something other than C, all common operating
systems during the 21st century are written in C. One slightly
earlier system (Macintosh, up until about five years ago when it
converted to Linux with System 10) was written mostly in Pascal AFAIK.
> This is not the case for older systems such as the PDP-10.
That's correct, and has always been my "impression", so you are
merely confirming what I already knew. IBM's mainframe systems
likewise predated C. I don't know about RSX-11m, that flaky
system on the DEC PDP-11.
(It really pissed me off that *EVERY* time there was a momentary
glich in the phone line that dropped carrier lock for even a
fraction of a second, the I/O driver signalled END OF FILE on input
from modem to PDP-11 which was a control-D which was LOGOFF.
Several times per hour, when dialed into RSX-11m over 300 baud
acoustic coupler, I would see a brief glitch of phone line noise
(tilde curly-brace stuff like that) immediately followed by the
logout message actually transmitted to my terminal. If the system
is so smart it believes I've gone offline, then why is it
transmitting the logoff message to me over that same modem port
that it believes is no longer connected??? Stupid!!! At least it
could ask for confirmation of wish to log out, and time out after
ten seconds with default YES-LOGOUT if I don't respond. No, it
logged me out immediately after each phone-line noise transient.
It was impossible to get any useful work done via dialup to
Arrrrrrg!!!-Sucks-11M.)
My point was that it might be difficult to still find any very old
(pre-C) computers still working today, or to find any new computers
that use ancient operating systems. Like does there even exist a
version of handcoded-assembly-language VM/CMS that runs on the
latest Intel CPU?? (I'm not even going to ask about a
handcoded-assembly-language version of ITS or TOPS-10 or TENEX or
TOPS-20/TWENEX or ZetaLisp that runs on Intel CPU.)
> Except for Unix, operating systems developed before about 1980
> were coded in assembly language.
Yes, that has always been my understanding ("impression").
> If you can find a working PDP-10,
<http://www.lyricsdownload.com/essex-easier-said-than-done-lyrics.html>
<moot>
> you can boot its native operating system, TOPS-10, and run its
> native version of Lisp, which is Lisp 1.6, without any fear of
> being dependent on the C language.
</moot>
Is that the version I used at SU-AI, called "Stanford Lisp 1.6",
or is that a precursor, where Stanford's version had to be modified
from the TOPS-10 version to run on WAITS?
I think maybe MIT's Lisp 1.5 might actually be a better choice.
It developed to MacLisp which ran on ITS, but what did Lisp 1.5 run on?
> Finding a C-free implementation of Common Lisp may be a harder
> problem to solve.
I agree. That's why my idea would be to first get some very ancient
version of Lisp (1.5 or 1.6) running on some ancient OS, then
enhance that version of Lisp to be capable of generating
executables with a decent API similar to LAP and SYSLISP (BOOTLAP
for the pre-LispEnv start-up code, LAP per se only during
bootstrapping toward SYSLISP, SYSLISP for everything else), then
use that to generate the executable for the guts of CL-on-ancient-OS.
At least one of my several non-C bootstrapping ideas was that.
Crafting a brand-new modern non-C OS would be another idea.
I rather liked MIT/ITS's idea of using DDT as a bootstrapping
environment. Octal or Hexadecimal micro-DDT ought to be simple to
code directly in machine language (never mind assembly langauge!!),
then use that to patch itself to build up more DDT commands in
parallel with more DDT input/output modes such as symbolic opcodes
and symbolic memory-location names and parse+print of fullfledged
assembly-language syntax. This would be an extreme demonstration of
bottom-up tool-building as a software-development methodology.
Maybe what I should do is write an Altair 8800 bare-machine
emulator, complete with the notorious front panel of toggle
switches, as a CGI application, then everyone who wants can play
with it in lieu of a Knuth-Mix emulator. I would design an
event-scripting language, vaguely similar in concept to AppleEvents
as used in Macintosh keyboard macro recorders and HyperTalk GUI
scripting but using s-expression syntax of course (not XML!!!).
Then anyone could collect a transcript of their fiddling with
toggle switches on the Altair and later play back these as scripts
to quickly get from a virgin machine state to a re-creation of an
"interesting" machine state from which to pick up where the person
left off before. By simply deleting the last several steps in a
saved script, and then re-doing that initial segment of the script,
"UNDO" could be effected, to recover from accidently erasing
something important by storing something in the wrong location or
passing inappropriate parameters to a COPY-BLOCK-OF-MEMORY
function. I suppose I'd need at least two versions of the emulator:
- one that operates like a command-line interface
(user types a whole sequence of proposed actions using shorthand
notation into a TextArea, clicks SUBMIT button, and those are
converted to s-expression notation then executed in a batch)
- one that has live JavaScript buttons to execute each step immediately.
Before I undertake such a project, has it already been done?
Or I might invent my own CPU instruction set for my emulator,
an extreme RISC design based on ideas from one or more of these:
<http://esolangs.org/wiki/Hello_world_program_in_esoteric_languages>
In particular these languages seem to have potential:
<http://esolangs.org/wiki/DOGO>
<http://esolangs.org/wiki/Evil>
<http://esolangs.org/wiki/Full_0>
The way I boostrapped my Altair was as follows:
- Using the front panel I manually entered the first bootstrap loader:
<http://www.rawbw.com/~rem/NewPub/OldCodeSamples/BOOT1.M80.txt>
(Sorry, I can't find the hexadecimal binary of that.)
which read pairs of ASCII charcters from the first
serial port (hence from my Beehive 3A terminal), combined them
in a simple arithmetic way, and stored the result in the next
memory location.
- Running that program, I keyed in, in the very strange 3n+1
notation it requires, the second bootstrap program:
<http://www.rawbw.com/~rem/NewPub/OldCodeSamples/BOOT2.M80.txt>
(Sorry, I can't find the hexadecimal binary of that, nor 3n+1 notation.)
which correctly decoded hexadecimal values, but otherwise worked just
like the first program.
- Running that program, I keyed in, in ordinary hexadecimal notation,
a crude bootstrap downloader.
- Running that program, I downloaded from PDP-10 over modem a better
downloader.
- Running that program, I downloaded all the rest of my 8080 software.
With the MOS 6502 computer that Clem Smith built for me a few years
earlier, a crude bootstrap downloader was already in the pROM as
delivered, so I could skip the first three bootstrap steps. But
that was in some sense cheating, using a PDP-10 to cross-assemble
the pROM contents and generate the PTP file that was used to burn
the pROM. But then using the PDP-10 to cross-assemble the better
downloader and all subsequent software for 6502 and 8080 was
somewhat of a cheat anyway. But without even a paper-tape drive for
either machine, I needed to use the PDP-10 as a remote-virtual-disk
for any major software I wrote for either machine anyway, so there
was no practical way not to cheat in some way. Still if I had used
the PDP-10 *only* as a remote virtual disk, whereby I hand-coded
everything on 6502 or 8080, uploaded to PDP-10 for backup, and
downloaded again when the micro computer erased its RAM, that would
have been sorta not cheating at all.
Does anybody have a modern Intel Pentium or more recent CPU on a
board with RAM and two serial ports and some sort of "front panel"
whereby it could be bootstrapped from the front panel to the point
of running the equivalent of BOOT1 above, then the equivalent of
BOOT2 entered in 3n+1 notation from a terminal connected to one of
the serial ports, at which point it wouldn't be too hard to start
developing a crude DDT-like interactive environment? Although
modern CPUs are designed to operate very quickly using interleaved
instruction pipelines, I'm sure that for manual bootstrapping
purposes they could be programmed in "slow mode" by wrapping each
regular instruction with a barrier that forces completion before
moving on to the next instruction, whereby writing correct machine
code by hand (in hexadecimal or octal, not assembly language) would
be almost as easy as it was with ancient computers such as MOS 6502
or Intel 8080, and fast enough for these purposes. It's OK if you
don't *really* have a hardwired VT100 terminal and have to use a
Macintosh with VT100 emulator instead.
Rob Warnock
+---------------
| Of course the [7094] architecture had its flaws, such as the
| one-instruction user program that would get the machine into
| an uninterruptable loop!
Hmmm... Wonder if that was why the PDP-10 architects were so
careful to define that PDP-10 instructions were required to
be interruptable each *each* address resolution step, even
in a long indirect+indexing chain, precisely to make sure
that "JRST @." was interruptable! ;-} ;-}
And it was! Equally importantly, so was this:
t1: jrst @t2
...
t2: jfcl @t3
...
t3: jfcl @t4
...
t4: jfcl @t1
glen herrmannsfeldt
> Yeah, but the 7090 (or at least the 7094, which is what I cut my teeth on)
> had the CRQ (pronounced "crock" :-) instruction! The acronym is for "Convert
> by Rotation from the MQ" and I don't remember the details, but it split the
> contents of the MQ register into six 6-bit bytes, used each of them as an
> index into a table in memory, and used what it found there to replace the
> byte, more or less.
One I have wondered about is card input. It seems that 72 columns
of each card row are read into two 36 bit words. That means the
equivalent of bit transpose to get it into character column format.
After that, I suppose CRQ would convert to the appropriate character
code.
(snip)
> Of course the architecture had its flaws, such as the one-instruction user
> program that would get the machine into an uninterruptable loop! Still,
> some of us still have warm feelings toward the 7094. Its bootstrap loader
> was an even more amazing kludge than the shadow ACs on the PDP-6.
Do you mean the execute instruction bug? That even power down
reset won't get out of? (Remember, PC in core memory.)
I though that was earlier than the 7094, but it could have been.
-- glen
Brian Harvey
>One I have wondered about is card input. It seems that 72 columns
>of each card row are read into two 36 bit words. That means the
>equivalent of bit transpose to get it into character column format.
>After that, I suppose CRQ would convert to the appropriate character
>code.
Except for the bootstrap loader card, it was rare for a 7094 to read cards at
all; off in the corner of the room would be a 1401 that would transfer the
card decks to tape. Otherwise the expensive 7094 would spend too much time
idling while waiting for the slow card reader. (A big advance in, I think,
the 1410 was that it could handle Simultaneous Peripheral Operations On Line,
an acronym that lives on in /var/spool.) It's my impression that you could
tell the hardware whether to read cards in columns (as characters) or in rows
(as bits), but I'm not sure if the 1401 was smart enough to know when to
expect a binary card in a 7094 job deck.
>Do you mean the execute instruction bug? That even power down
>reset won't get out of? (Remember, PC in core memory.)
>I though that was earlier than the 7094, but it could have been.
I think powering down would fix it -- by the time of the 7094 the registers
were transistors, even though the memory was core.
glen herrmannsfeldt
> glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>>One I have wondered about is card input. It seems that 72 columns
>>of each card row are read into two 36 bit words. That means the
>>equivalent of bit transpose to get it into character column format.
>>After that, I suppose CRQ would convert to the appropriate character
>>code.
> Except for the bootstrap loader card, it was rare for a 7094 to read cards at
> all; off in the corner of the room would be a 1401 that would transfer the
> card decks to tape. Otherwise the expensive 7094 would spend too much time
> idling while waiting for the slow card reader. (A big advance in, I think,
> the 1410 was that it could handle Simultaneous Peripheral Operations On Line,
> an acronym that lives on in /var/spool.) It's my impression that you could
> tell the hardware whether to read cards in columns (as characters) or in rows
> (as bits), but I'm not sure if the 1401 was smart enough to know when to
> expect a binary card in a 7094 job deck.
I think it was the 704 that read cards row-wise, with the resulting
72 column limit still with us in many places. I was thinking that
feature would still be there in the 7094, but maybe not.
>>Do you mean the execute instruction bug? That even power down
>>reset won't get out of? (Remember, PC in core memory.)
>>I though that was earlier than the 7094, but it could have been.
> I think powering down would fix it -- by the time of the 7094 the registers
> were transistors, even though the memory was core.
OK, I thought it was the 702 or 704 that had that problem.
(Requiring waving magnets around in the core memory box
would fix the problem.)
-- glen
Robert Maas, http://tinyurl.com/uh3t
> There was a short set of MIT course notes "Lisp: A Radical
> Introduction", something like that. Does anybody have a copy? I
> remember it as being amazingly good at introducing the true heart
> of Lisp.
If anybody has that available as text/html or text/plain, I'd be
very curious to see it. If I were to proclaim the true heart of
Lisp myself, I'd probably say something like:
- Nested lists are a fundamental built-in feature of the language,
rather than some add-on. These are the primary way to express
hierarchial data, and *also* the primary way to express parse
trees of source code, thus functions to operate upon data work
exactly the same to operate upon parse trees. This
representation of parse trees is well documented, unlike other
languages where it exists inside the compiler but is essentially
hidden from access by users.
- A decent way to capture free variables and re-express them as
formal parameters to functions, namely by means of the lambda
calculus, allows first-class functions to be created with
minimal effort whenever desired.
- A decent way to capture free variables from multiple locations
inside different function definitions and re-express them as
"own"/"static" variables, namely by means of lexical closures,
which are built automatially whenever function definitions have
free variables that are resolved inside an enclosing lexical
binding environment, allows shared own/static variables to be
generated with minimal effort whenever desired.
- Multiple paradigms are supported and can be mixed any way desired:
- Procedural, including mutually recursive functions;
- Functional, using lexical closures to emulate currying;
- "Object Oriented" classes with methods;
- Generic functions that specialize over built-in types and user-defined classes
- Specially defined "domain-specific" languages defined by means of:
- Macros, which retain the syntax<=>source-parse-tree
mapping, but change the semantics by then mapping the
original source-parse-tree to a different source-parse-tree;
- Readtable changes, which enhance the syntax<=>source-parse-tree mapping;
- Parsers, which can totally replace that mapping.
- A decent-sized library is included to do the most common types of
low-level tasks in processing several types of data: strings of
text, nested lists, lookup tables (both sequential and hashs),
streams and files, numbers (including arbitrary-size integers).
- Interpreted code typed in live during a run, and compiled code
loaded in from disk files, all have the same semantics and
interoperate, thus supporting both line-at-a-time development or
tool-calling and library loading together.
Note that some of those are specific to Common Lisp (and a few
other Lisps), while some are generic to all Lisps from the very
first. I'm curious whether those MIT course notes apply only to
what has been in Lisp since the beginning, or apply to all of what
Lisp is now in the form of ANSI Common Lisp? (I've taken the latter
approach above.)
John Sauter
>
> Except for the bootstrap loader card, it was rare for a 7094 to read cards at
> all; off in the corner of the room would be a 1401 that would transfer the
> card decks to tape. Otherwise the expensive 7094 would spend too much time
> idling while waiting for the slow card reader. (A big advance in, I think,
> the 1410 was that it could handle Simultaneous Peripheral Operations On Line,
> an acronym that lives on in /var/spool.) It's my impression that you could
> tell the hardware whether to read cards in columns (as characters) or in rows
> (as bits), but I'm not sure if the 1401 was smart enough to know when to
> expect a binary card in a 7094 job deck.
>
Don Gold of the Stanford Computation Center wrote a program for our IBM
1401 that allowed it to simultaneously perform card-to-tape and
tape-to-print (and punch). Apparently, it was a major piece of coding,
since the IBM 1401 was not intended to be used in this way.
The IBM 1401 operated in support of the IBM 7090, so its peripheral
operations were considered "off-line".
I believe binary cards were written with different parity than text
cards, but my memory is weak on this point.
John Sauter (John_...@systemeyescomputerstore.com)
John Sauter
>
> I think it was the 704 that read cards row-wise, with the resulting
> 72 column limit still with us in many places. I was thinking that
> feature would still be there in the 7094, but maybe not.
>
The IBM 7090, at least, still read cards from its on-line card reader in
"row binary". As I recall, the first 72 columns of an 80-column card
were read into 24 36-bit words. Software unscrambled the 72 6-bit
characters from that.
John Sauter (John_...@systemeyescomputerstore.com)
jmfbahciv
All systems would have done that. Would you have preferred the
next person who called that line to be logged in as you?
>
> My point was that it might be difficult to still find any very old
> (pre-C) computers still working today, or to find any new computers
> that use ancient operating systems.
Huh? Those old computer architectures were still being manufactured
in 2000. Look for companies called Mentec and XKL.
>Like does there even exist a
> version of handcoded-assembly-language VM/CMS that runs on the
> latest Intel CPU?? (I'm not even going to ask about a
> handcoded-assembly-language version of ITS or TOPS-10 or TENEX or
> TOPS-20/TWENEX or ZetaLisp that runs on Intel CPU.)
Good because it is two different hardware architectures.
<snip>
/BAH
jmfbahciv
> Brian Harvey wrote:
>
>>
>> Except for the bootstrap loader card, it was rare for a 7094 to read
>> cards at
>> all; off in the corner of the room would be a 1401 that would transfer
>> the
>> card decks to tape. Otherwise the expensive 7094 would spend too much
>> time
>> idling while waiting for the slow card reader. (A big advance in, I
>> think,
>> the 1410 was that it could handle Simultaneous Peripheral Operations
>> On Line,
>> an acronym that lives on in /var/spool.) It's my impression that you
>> could
>> tell the hardware whether to read cards in columns (as characters) or
>> in rows
>> (as bits), but I'm not sure if the 1401 was smart enough to know when to
>> expect a binary card in a 7094 job deck.
>>
>
> Don Gold of the Stanford Computation Center wrote a program for our IBM
> 1401 that allowed it to simultaneously perform card-to-tape and
> tape-to-print (and punch). Apparently, it was a major piece of coding,
> since the IBM 1401 was not intended to be used in this way.
Did it get hot?
<snip>
/BAH
Robert Maas, http://tinyurl.com/uh3t
> | to solve. I checked on GNU Common Lisp, but it is obviously coded in C.
> Well, *tiny* parts of it [~1%] are coded in C [initial startup code,
> some low-level O/S interactions (e.g., signal handling), the GC],
> but the vast majority [~99%] is coded in Common Lisp itself and
> compiled directly to native machine code.
> Your point remains, however, that it's certainly not C-free.
I'd like to emphasize that a bit more: McCarthy et al demonstrated
way back at the start of Lisp that from a few primitives all the
rest of Lisp can be built simply by defining layers of functions
and macros on top of the few necessary primitives. Common Lisp has
a few more essential primitives to deal with:
- multiple value return
- keyword arguments (I'll ignore optional argument as a crock by comparison)
- sets of lexical-closure functions sharing a set of lexical bindings
(the most common case being just one lexical-closure function with
just one own/static variable, but I'll take the whole st{u"}ck if I may)
- configurable readtables and packages
Common Lisp also has a bunch of additional primitive data types:
-- characters, arrays, strings, hashtables, etc. etc.
plus two mechanisms for defining new users-level data types:
-- DEFSTRUCT classes and instances thereof
-- CLOS classes and instances thereof
However there's no absolute requirement that those additional
primitive datatypes need be so. It's entirely reasonable to build
an alternate model of all the functionality of Common Lisp where
all those additional primitive data types are implemented as
intentional data types instead, or using either of those two
mechanisms for building new user-level data types.
For example if integers masquerade as character codes, as they did
in MacLisp, and as they *still* do in Emacs-lisp, a DEFSTRUCT class
or a CLOS class could be made to wrap around them in much the same
way that Java defines class Integer to wrap around ints etc.
The main advantage of *actual* data types
(regardless of whether primitive or user-defined by DEFSTRUCT or CLOS)
instead of mere intentional data types is that they carry their
intention along with them instead of requiring external knowledge
of their intentional type, thus different kinds of them can be
mixed in containers, or passed to generic functions such as PRINT,
and upon fetching an element of such a mixed-contents container or
attempting to print such a value the "right" thing happens
automatically.
For example, if we emulate the intentional type of character by
simply CONSing a keyword :CHARACTER in front of it, thus
(:CHARACTER #x71) would represent the character 'q' which today's
Common Lisp would express as #\q. Now we *could* have a reader
macro that when it sees #\q generates the internal form of
(:CHARACTER #x71). But if it sees an actual list (:CHARACTER #x71)
it would generate the same exact internal list. Then when it comes
time to print it out, we'd need to set a "mode" for PRINT as to
whether that kind of list is to be interpreted as a list per se or
as our intentional datatype of character. And if we try to make a
list of mixed objects, some which are supposed to be these
intentional-character-objects and others which are supposed to be
*actual* intentional next-level lists, it would be hopeless to
devise an algorithm for choosing the intention, except if we had a
priority system where some intentions mask others for data values
that could be either. I suppose that would work. Maybe READ should
signal an error whenever it parses something as a list which would
be preferably intended as something else such as a character.
So anyway, my point is that if we are willing to live with internal
emulations of ambiguous intentional datatypes which can be resolved
only by a priori knowledge such as a "mode" or a priority of
intention for equivalent internal data values, then all we really
need to implement from outside of Lisp are those few primitives of
McCarthy's original design plus those few additional essential
mechanisms of Common Lisp. So the question is what non-Lisp
language will be used to create those essential primitives?
In GNU Common Lisp, from my understanding of what was written
above, 100% of those essential primitives are coded in C. The goal
of avoiding CL reliance on C is to change that to 0% of essential
primitives coded in C. That was the point of my original bootstrap
discussion, how to find a bare machine that can be easily
bootstrapped to the point where a crude operating system plus Lisp
primitives can be coded without C, or else to find some
still-working computer that runs a pre-C operating system such as
Tops-10 or ITS. No, I do not accept an Intel 8080 with BASIC!!!!
I don't want CL dependent on BASIC and Bill Gates either!!!!!!!!
So how close to the Silicon Valley (San Jose to Palo Alto) does
there still exist a working ancient-computer with pre-C operating
system, with some kind of mass-storage system such as paper tape or
audio cassette modem on which to save the day's work?
(Neither my homebrew Clem Smith MOS-6502, nor my Altair 8800, had any
mass storage system. I relied on the PDP-10 (at SU-AI and/or MIT-MC)
through modem and telephone dialup for mass storage, both long gone.
That's why I am asking. Those two computers of mine, even if they
still work today, wouldn't be able to build Lisp without using a
remote Unix computer as mass storage. Nevermind that Lisp plus OS
wouldn't fit in 4k bytes on MOS-6502 computer and would be a tight
fit in 28k bytes on Altair.)
Another option: Does anybody know of a way to interface between a
USB "memory stick" and RS-232? Imagine the idea of an Altair 8800
interfaced to a 137 megabyte memory stick!!! I seem to recall that
PCNET protocol fit in 2k bytes on 6502, so something similarily
lean could possibly emulate a virtual RAM device whereby the 6502
or 8080 runs a virtual-machine emulator that uses the memory stick
as if it were the main memory.
OT: Same question changed: USB "memory stick" to SCSI bus, so that
I could connect the memory stick to my Macintosh Performa 600.
glen herrmannsfeldt
> Another option: Does anybody know of a way to interface between a
> USB "memory stick" and RS-232? Imagine the idea of an Altair 8800
> interfaced to a 137 megabyte memory stick!!! I seem to recall that
> PCNET protocol fit in 2k bytes on 6502, so something similarily
> lean could possibly emulate a virtual RAM device whereby the 6502
> or 8080 runs a virtual-machine emulator that uses the memory stick
> as if it were the main memory.
I believe it should be easy to interface a CF card to
the S100 bus, or most microcomputer buses. Some of the other
memory cards might be about as easy, or easier. USB is a little
harder, though.
-- glen
Scott Hemphill
Here's a product for the apple II, for example:
http://dreher.net/CFforAppleII
Scott
--
Scott Hemphill hemp...@alumni.caltech.edu
"This isn't flying. This is falling, with style." -- Buzz Lightyear
Rich Alderson
http://tinyurl.com/uh3t) writes:
> So how close to the Silicon Valley (San Jose to Palo Alto) does
> there still exist a working ancient-computer with pre-C operating
> system, with some kind of mass-storage system such as paper tape or
> audio cassette modem on which to save the day's work?
I think I pointed you at PDPplanet.org, where you can sign up for accounts on a
real, live KL-10-based DECSYSTEM-2065 running Tops-10 v7.04 and a real, live
XKL Toad-1 System running TOPS-20 v7.1. The 2065 was manufactured in 1983,
according to its QA sticker from the factory; the Toad was built c. April, 1996
in Redmond, WA, by a team that included the present writer.
How ancient do you want to go?
We will have a PDP-7 running in the near future. According to the Bill of Sale
included in the documentation included with the system when we acquired it, it
was built in early 1966 (delivery date was March of that year). It of course
predates the C language (which appears to be your personal bugaboo) by several
years. We would be willing to discuss a reasonable project plan for something
like "implement something that never existed bout could have" like a Lisp.
> (Neither my homebrew Clem Smith MOS-6502, nor my Altair 8800, had any
> mass storage system. I relied on the PDP-10 (at SU-AI and/or MIT-MC)
> through modem and telephone dialup for mass storage, both long gone.
> That's why I am asking. Those two computers of mine, even if they
> still work today, wouldn't be able to build Lisp without using a
> remote Unix computer as mass storage. Nevermind that Lisp plus OS
> wouldn't fit in 4k bytes on MOS-6502 computer and would be a tight
> fit in 28k bytes on Altair.)
So don't use an OS! LISP fit in 4K words on the PDP-1, and loaded from paper
tape. If you have a Lisp, what more do you need?
Rich Alderson
>> From: John Sauter <John_Sau...@systemeyescomputerstore.com>
>> You seem to be under the impression that operating systems are
>> based on the C language.
> No, you are mistaken. My "impression" is that while very old
> systems were based on something other than C, all common operating
> systems during the 21st century are written in C. One slightly
> earlier system (Macintosh, up until about five years ago when it
> converted to Linux with System 10) was written mostly in Pascal AFAIK.
>> This is not the case for older systems such as the PDP-10.
>
> That's correct, and has always been my "impression", so you are
> merely confirming what I already knew. IBM's mainframe systems
> likewise predated C. I don't know about RSX-11m, that flaky
> system on the DEC PDP-11.
RSX-11M, like RSX-11A, -11B, -11C, and -11D before it, was written in Macro-11.
> My point was that it might be difficult to still find any very old
> (pre-C) computers still working today, or to find any new computers
> that use ancient operating systems. Like does there even exist a
> version of handcoded-assembly-language VM/CMS that runs on the
> latest Intel CPU?? (I'm not even going to ask about a
> handcoded-assembly-language version of ITS or TOPS-10 or TENEX or
> TOPS-20/TWENEX or ZetaLisp that runs on Intel CPU.)
It's not hard at all to find such a computer. It's FAR easier to find such a
computer than to find any decent operating system such as those you list on an
Intel CPU!
(On the other hand, there was a research project at, IIRC, USC or perhaps ISI
which was interested in implementing TENEX under VM/370 in the early 80s. It
used 2 SVCs to implement the 512 possible JSYi.)
>> Except for Unix, operating systems developed before about 1980
>> were coded in assembly language.
> Yes, that has always been my understanding ("impression").
>> If you can find a working PDP-10,
> <http://www.lyricsdownload.com/essex-easier-said-than-done-lyrics.html>
No, it's a lot easier done than that:
and click on the Community button.
> <moot>
>> you can boot its native operating system, TOPS-10, and run its
>> native version of Lisp, which is Lisp 1.6, without any fear of
>> being dependent on the C language.
> </moot>
> Is that the version I used at SU-AI, called "Stanford Lisp 1.6",
> or is that a precursor, where Stanford's version had to be modified
> from the TOPS-10 version to run on WAITS?
No, the WAITS version was developed based on LISP 1.5, and given an incremented
number to reflect the history.
> I think maybe MIT's Lisp 1.5 might actually be a better choice.
> It developed to MacLisp which ran on ITS, but what did Lisp 1.5 run on?
An IBM 7040, IIRC. It's based on Dartmouth's LISP 1 which ran on a 704.
Hmm. Those are all so-called EVALQUOTE Lisps, where the PDP-1 LISP and MACLISP
and Common Lisp are "EVAL" Lisps.
>> Finding a C-free implementation of Common Lisp may be a harder
>> problem to solve.
> I agree. That's why my idea would be to first get some very ancient
> version of Lisp (1.5 or 1.6) running on some ancient OS, then
> enhance that version of Lisp to be capable of generating
> executables with a decent API similar to LAP and SYSLISP (BOOTLAP
> for the pre-LispEnv start-up code, LAP per se only during
> bootstrapping toward SYSLISP, SYSLISP for everything else), then
> use that to generate the executable for the guts of CL-on-ancient-OS.
> At least one of my several non-C bootstrapping ideas was that.
Why not try this: Use MACLISP on a TOPS-20 system (where it runs natively),
and create a compiler for your micro target, then bootstrap your LISP
implementation using that? If it was good enough for Guy Steele when he
created the Rabbit compiler for Scheme...
> Crafting a brand-new modern non-C OS would be another idea.
> I rather liked MIT/ITS's idea of using DDT as a bootstrapping
> environment. Octal or Hexadecimal micro-DDT ought to be simple to
> code directly in machine language (never mind assembly langauge!!),
> then use that to patch itself to build up more DDT commands in
> parallel with more DDT input/output modes such as symbolic opcodes
> and symbolic memory-location names and parse+print of fullfledged
> assembly-language syntax. This would be an extreme demonstration of
> bottom-up tool-building as a software-development methodology.
You misunderstand the history of ITS and DDT. DDT was not a bootstrapping
environment; rather, one of the ITS hackers created a version of DDT capable of
handling multiple forks (processes), and made it the top level shell program.
Rich Alderson
http://tinyurl.com/uh3t) writes:
>> From: John Sauter <John_Sau...@systemeyescomputerstore.com>
>> You seem to be under the impression that operating systems are
>> based on the C language.
> No, you are mistaken. My "impression" is that while very old
> systems were based on something other than C, all common operating
> systems during the 21st century are written in C. One slightly
> earlier system (Macintosh, up until about five years ago when it
> converted to Linux with System 10) was written mostly in Pascal AFAIK.
I forgot to comment on this.
Mac OS X is not Linux. It's generally BSD grafted onto Mach, with extensions.
I highly recommend Amit Singh's _Mac OS X Internals: A Systems Approach_ for
details.
toby
Maas, http://tinyurl.com/uh3t) wrote:
> > From: John Sauter <John_Sau...@systemeyescomputerstore.com>
> > You seem to be under the impression that operating systems are
> > based on the C language.
>
> No, you are mistaken. My "impression" is that while very old
> systems were based on something other than C, all common operating
> systems during the 21st century are written in C. One slightly
> earlier system (Macintosh, up until about five years ago when it
> converted to Linux with System 10)
Actually the first version of OS X, 10.0, was released more than 7
years ago (24 March 2001). This is real UNIX; OS X is not directly
related to Linux, although most popular Linux software also runs well
on OS X.
> was written mostly in Pascal AFAIK.
Initially 68000 assembler and Pascal, but the latter - a Lisa legacy -
was progressively phased out in the late 1980s, and new development in
Systems 7, 8 and 9 was increasingly in C. This was effectively
mandated by the introduction of the PowerPC architecture to the
Macintosh product line in 1994, as Apple's MPW included Motorola's
state-of-the-art C compiler for PPC but (iirc) no corresponding native
Pascal compiler. By that time, C was considered the standard
workstation language; Pascal had become marginal. Third party
developers were encouraged to port to C to take full advantage of the
PowerPC's speed (and an endless stream of new system APIs).
With OS X, Apple began to tout Objective-C as the preferred
application development language, and presumably large chunks of their
windowing system and API layers are written in that.
toby
Maas, http://tinyurl.com/uh3t) wrote:
> > You seem to be under the impression that operating systems are
> > based on the C language.
>
> No, you are mistaken. My "impression" is that while very old
> systems were based on something other than C, all common operating
> My point was that it might be difficult to still find any very old
> (pre-C) computers still working today
I don't think there's much C in VAX/VMS, and working VAXes aren't hard
to find.
toby
> Brian Harvey <b...@cs.berkeley.edu> wrote:
>
> +---------------
> | Of course the [7094] architecture had its flaws, such as the
> | one-instruction user program that would get the machine into
> | an uninterruptable loop!
> +---------------
>
> Hmmm... Wonder if that was why the PDP-10 architects were so
> careful to define that PDP-10 instructions were required to
> be interruptable each *each* address resolution step, even
> in a long indirect+indexing chain, precisely to make sure
> that "JRST @." was interruptable! ;-} ;-}
The DG Nova made the same faux pas in model 3 and fixed it in model 4
(iirc).
>
> And it was! Equally importantly, so was this:
>
> t1: jrst @t2
> ...
> t2: jfcl @t3
> ...
> t3: jfcl @t4
> ...
> t4: jfcl @t1
>
> -Rob
>
> -----
> Rob Warnock <r...@rpw3.org>
Morten Reistad
Rich Alderson <ne...@alderson.users.panix.com> wrote:
>jaycx2.3....@spamgourmet.com.remove (Robert Maas,
>http://tinyurl.com/uh3t) writes:
>
>> So how close to the Silicon Valley (San Jose to Palo Alto) does
>> there still exist a working ancient-computer with pre-C operating
>> system, with some kind of mass-storage system such as paper tape or
>> audio cassette modem on which to save the day's work?
>
>I think I pointed you at PDPplanet.org, where you can sign up for accounts on a
>real, live KL-10-based DECSYSTEM-2065 running Tops-10 v7.04 and a real, live
>XKL Toad-1 System running TOPS-20 v7.1. The 2065 was manufactured in 1983,
>according to its QA sticker from the factory; the Toad was built c. April, 1996
>in Redmond, WA, by a team that included the present writer.
>
>How ancient do you want to go?
>
>We will have a PDP-7 running in the near future. According to the Bill of Sale
>included in the documentation included with the system when we acquired it, it
>was built in early 1966 (delivery date was March of that year). It of course
>predates the C language (which appears to be your personal bugaboo) by several
>years. We would be willing to discuss a reasonable project plan for something
>like "implement something that never existed bout could have" like a Lisp.
Or, for somethine non-DEC (yes, I know this is the wrong newsgroup for
that) ; any 50-series Prime machine runs Primos, which is written in
PL/1 (no less than three different dialects), Fortran and some
assembler. You don't have to use C, or C++, at all for that machine.
They were built in the period 1976(400)-1994(5350), and you may even
have them in "deskside" variants.
>> (Neither my homebrew Clem Smith MOS-6502, nor my Altair 8800, had any
>> mass storage system. I relied on the PDP-10 (at SU-AI and/or MIT-MC)
>> through modem and telephone dialup for mass storage, both long gone.
>> That's why I am asking. Those two computers of mine, even if they
>> still work today, wouldn't be able to build Lisp without using a
>> remote Unix computer as mass storage. Nevermind that Lisp plus OS
>> wouldn't fit in 4k bytes on MOS-6502 computer and would be a tight
>> fit in 28k bytes on Altair.)
>
>So don't use an OS! LISP fit in 4K words on the PDP-1, and loaded from paper
>tape. If you have a Lisp, what more do you need?
The rest of emacs ? Then you have a shell!
-- mrr
glen herrmannsfeldt
> On Jul 20, 10:34 pm, r...@rpw3.org (Rob Warnock) wrote:
(snip)
>>Hmmm... Wonder if that was why the PDP-10 architects were so
>>careful to define that PDP-10 instructions were required to
>>be interruptable each *each* address resolution step, even
>>in a long indirect+indexing chain, precisely to make sure
>>that "JRST @." was interruptable! ;-} ;-}
> The DG Nova made the same faux pas in model 3 and fixed it in model 4
It is why the S/360 EXecute instruction isn't allowed to
execute another EX. S/360 has no instructions that are
interruptible such that they can be continued later.
Those were added in S/370, such as Move Long (MVCL).
-- glen
Robert Maas, http://tinyurl.com/uh3t
> > mass storage system. I relied on the PDP-10 (at SU-AI and/or MIT-MC)
> > through modem and telephone dialup for mass storage, both long gone.
> > That's why I am asking. Those two computers of mine, even if they
> > still work today, wouldn't be able to build Lisp without using a
> > remote Unix computer as mass storage. Nevermind that Lisp plus OS
> > wouldn't fit in 4k bytes on MOS-6502 computer and would be a tight
> > fit in 28k bytes on Altair.)
> So don't use an OS! LISP fit in 4K words on the PDP-1, and
> loaded from paper tape. If you have a Lisp, what more do you need?
A paper tape reader. I didn't have one. There was no way to build
up permanent storage of anything I might create, except on the
remote PDP-10, using SAIL and MacLisp and CROSS for various aspects
of the archiving and cross-assembly.
Also, 4k words is more than 4k bytes.
Maybe I'll write a MOS-6502 emulator and see if I can develop a
Lisp that runs in 4k bytes using the 6502 instruction set.
Maybe I'll write the emulator in Pocket Forth. ... Just kidding.
Actually more likely I'll write a no-syntax virtual machine with
programming all by information retrieval (menus and filesystem
browser). You want a literal constant? You select from menu:
- integer
- string
- filesystem reference
Then you go into an editor or filesystem dialog to design your
literal or find the file whose path+name you want.
Once you have one or more literal values, you check the checkboxes
for the data you want to feed into some data-processing operation,
and the system gives you a menu of appropriate known functions. For
example, if you have a string and an integer, you might want the
nth character of the string, or the sub-string starting or ending
at that position, or the decimal or other radix representation or
s-expression parsed from the string starting at that location, or
you might want to use the string as a format string with the
integer as a substitition parameter to the FORMAT function.