There are references to the IBM 7090/7094 version under IBSYS online.
In this 7094 emulator package on Github: https://github.com/Bertoid1311/B7094 (in the zipped distribution files unfortunately) I think there is a copy that is runnable? see: Docs/Bamberger-MAMOS_docs/BAMBSYSLB1_patch_for_IPLV.txt
It describes patching the available binary to make it work, with the caveat that it's unclear if the interpreter is correct/intact (but it does run the demo programs).
On the provenance of the tape: https://retrocomputingforum.com/t/umes-resurrected-sort-of/3...
Yow! This is amazing! We'll check it out asap! If this sentence was a question would I have to use a question mark instead of an exclamation point?
Why do you need the old code if you implement your own interpreter anyway? Why "(ironically) Lisp"?
Two good questions; Two different answers.
First, re "ironically":
Short answer: Lisp and IPL were competitors for the list&symbol-processing community of early AI. IPL invented a lot of what Lisp implemented in nicer syntax -- in effect, Lisp was an HLL for IPL. Lisp (obviously) won and now we're (ironically) emulating IPL in Lisp in order to emulate Lisp's underlying machine in the HLL that sits on top of that machine. (Actually - ironically^2 - SLIP won ... see below.)
Longer answer: This whole corner of language development was full of ironies. SLIP (Weizenbaum's approach to list processing) was a plug-in for Fortran (originally) and shortly thereafter, MAD. Just as Lisp wiped out IPL, it also wiped out SLIP. Ironically, today we do what Weizenbaum envisioned: Write in powerful general HLLs and add in specialized packages for things like list processing. So, in the end, SLIP won!
Thanks. I read about IPL for the first time in McCarthy's history of Lisp paper, but never took a closer look. I now also see the irony.
Re: Why do you need the old code if you implement your own interpreter anyway?
Several reasons. First, we don't need it, we want it -- it's a nice-to-have not a need-to-have.
It's nice to have for many reasons, none of them huge, but together they vie towards having it if we can find it:
1. What we're after is running the old AIs, not having IPL-V. We don't intend to write any new IPL code. The old AIs just happen to be written in IPL.
2. We can run the code without having to reformat it. There are numerous annoying nuances when recreating a very old language, not the least of which is the importance of card columns, which is annoying to "wrap parens around".
3. If we bother to write an emulator anyway, we can test our emulator against the real thing.
4. IPL-V being Lisp's conceptual machine code (one version of it, anyway), it should be easy to do so, so there's that as an engineering experiment.
5. Writing anything in Lisp is fun so it's an excuse to take a break from ... well, from pretty much anything else on my agenda, most of which do not require Lisp programming (although I often manage to squeeze some in anyway. :-)
BTW, Re: #2: There was a proposal for a Lisp-Like IPL that used s-expressions as list representations (actually, they call it "linear"): https://apps.dtic.mil/sti/tr/pdf/AD0611841.pdf
Interesting. Having the old compiler and an emulator is certainly helpful, but of course also yet another complexity. From my experience, it's very useful to have some decently large programs in the target language, the output of which are known. Thanks for the document, I will talke a look at it.
Excellent point. We have many decently large programs. In fact, we have pretty much the jackpot. Ed Feigenbaum famously wrote EPAM, one of the first simulators of human memory. Not only is the program extensively documented in numerous published papers and reports, and not only is entire the code online (https://purl.stanford.edu/vq775jv4844) but if you look at that code, it's actually a compiler output, so it shows us how pretty much every type of IPL-V instruction compiles!
Preservation.
They seem to care about it, which is why they're doing what they're doing in the first place.