drogon,
I’ve bought a Rosco kit and also 2 of the 4MB memory boards. Just need to find my soldering iron.
FYI, I’m working on enhancing the IMP77 x86 compiler (see GitHub - siliconsam/imp2021)
Next project would be to port the x86 code generator to the soldered up 68K machine.
John is working on a native X86 32-bit compiler; Bob Eager is working on a new Imp80 compiler, and I’m working on an Imp to C translator that targets GCC (using GCC extensions for nested procedure support, dynamic array declarations, etc - all the good old Algol constructs that C normally avoids) which is intended to be a full compiler for Imp77 with Imp80 extensions. I had written a translator before which was more of an aid to manual translation, but this one will behave exactly like a real compiler, you won’t even be aware of the C output unless you ask to see it. The future of Imp is looking quite rosy! (btw I’m in the middle of a big restructuring of my Imp to C code at the moment so the current online source doesn’t run right now, but if you’re interested in compilers, the WIP source code is dumped to https://gtoal.com/compilers101/new-imp-to-c/compile.c.html daily.)
Great news!
But I wonder if it will be easy to use and what sources can be used (EMAS 2,3 or even APM ?).
I somehow doubt that any notable sources with the many include files will compile/run without proper emulators.
There are some interesting codes on the EMAS site.
I recently found code11.txt by Dutch Mr. Straatman. Wouldn’t he/the code be useful?
! RECODE FOR IMP PROGRAMS
! THIS PROGRAM TAKES THE THIRD PASS
! OUTPUT OF THE IMP COMPILER
! AND MAKES A RECODE IN ASSEMBLY
! OF EVERY IMP SOURCE LINE
! AUTHOR K. STRAATMAN
! MATHEMATISCH INSTITUUT
! RIJKSUNIVERSITEIT TE GRONINGEN
code11.txt (code11.imp) seems to be aimed at IMP compiled on the PDP-11. Don’t know which PDP-11 O/S.
FYI,the IMP2021 IMP compiler (pass2) already outputs pseudo-Intel assembler text in the .cod file
It can also interleave the iCode from pass1 in the .cod file so you can see what “machine code” is generated by the iCode input. You need to define the environment variable IMP_ICODE to enable this.
eg for Windows $set IMP_ICODE=1
for Linux: export IMP_ICODE=1
I also added utils to convert the iCode to an iCode “assembler” textual file, and also to read the iCode “assembler” and output the binary iCode.
So, if you wanted to create a language front-end that parses your language and outputs iCode assembler text then the Intel pass2 + pass3 programs will create object code for Windows/Linux.
Oh, obviously this will be better than thought. The compile.c should (later) also been able to handle 68K code. I think ~80-90% of the IMP80 sources (and maybe ~70-80 % of all imp sources) are for the APM/Fred.
I still wonder what the goal is. Will it also read the 68k MOB binaries and display everything? Then it’s not just a compiler but rather an emulator.
Wouldn’t it be better/easier to make an 68k compiler?
Some system files and libraries I think are missing or at least not public to the archives. But maybe they have them as well.
I wasn’t aware that 11 stands for PDP11. I think the file was not in the pdp folder.
Oh, obviously this will be better than thought. The compile.c should (later) also been able to handle 68K code. I think ~80-90% of the IMP80 sources (and maybe ~70-80 % of all imp sources) are for the APM/Fred.
I still wonder what the goal is. Will it also read the 68k MOB binaries and display everything? Then it’s not just a compiler but rather an emulator.
Wouldn’t it be better/easier to make an 68k compiler?
Some system files and libraries I think are missing or at least not public to the archives. But maybe they have them as well.
I’m not entirely sure what you are aiming for as you’ve mentioned half a dozen systems in various posts, but let me try to paint a wider picture and see if maybe it clarifies anything for you.
Our archives were a case of ‘grab everything while we still can’ and are admittedly hard to find your way around. Most everything we have is there - the only things removed were anything that was obviously personal data or in one case, everything in that person’s Emas directory until we had time to sort through it, because his research had allowed him access to many copyrighted texts for stylistic analysis, which we don’t have permission to publish. Because of a somewhat awkward (not antagonistic, just difficult due to security issues and DPR interpretations) relationship with the University, we lost the ability to update the archive a few years back, so anything acquired since then is on my net server ( https://gtoal.com/history.dcs.ed.ac.uk/archive/ ) or on my home computer, pending being sorted out and uploaded. Most of the later items are published papers rather than source code.
The archive contains files for the old ICL 4/75 EMAS, the 2900 series Emas versions, and even a few for the later IBM version. It has sources - some machine readable, some scans of listings - for older systems invented at Edinburgh such as the PDP15 O/S, Legos, Isys, the original Filestore, etc. We have sources for the pdp-11 system Deimos, the 68K APM (aka Fred Machine, named after the designer Fred King) and a few files from the department’s Vax/VMS - but most of the VMS archive is on a CD at Edinburgh that hasn’t been shared with us. We have compiler sources that - if compiled into modern binaries - would allow us to cross-compile files for any of these old systems that we still have sources from. This is where the compilers come in…
Back in the early 2000’s my classmate Andy Davis resurrected an Imp77 compiler but it was a 16-bit only version, and it sort of went ‘stiff’. This year, John McMullen resurrected Andy’s compiler and this time upgraded it to a 32-bit version - except it was 32-bit only, it didn’t have support for 16-bit data. Turns out many of the archive sources require both 16 and 32 bit support (not to mention being byte-sex dependent in several cases.) And there have been so many dialects of Imp (every compiler writer seems to have felt compelled to add their own tweaks so there are as many dialects as there are compilers) - that it is a major job getting any arbitrary program to compile under the current 32 bit Imp77. So my justification for creating yet another Imp compiler - this time an Imp to C transpiler - was that it would support all the various dialects! Most could be turned on by default as they did not cause incompatibilities, though a few would have to be handled by command line options when the behaviour of two dialects were mutually incompatible. The potential mess of many sets of options, however, could be avoided by this strategy: once the transpiler was working, it would run the original front-ends of all the old compilers before attempting to translate any program into C - using the old compilers as a syntax checker effectively - so that the relevant translation options could be determined by observing which of the ancient compilers managed to syntax-check the user’s program successfully! 
Sounds crazy but it is looking like it will work, I have a few of the old front-ends working now, plus the old syntax checkers themselves which were Imp front-ends without a code generator, built for speed (and for checking sources from within your editor without exiting to compile properly). By the way modern systems are so fast that using these old compilers as a syntax check is so quick it isn’t even noticable!
So this new Imp to C that I first mentioned in an earlier post is almost working, but not quite ready for release as there are a few small issues in the generated C that are still being fixed by a manual edit. But with that caveat you can have a look at some programs that have already been translated to get an idea of where it is going, in: Index of /compilers101/new-imp-to-c/examples I don’t believe there are any remaining Imp constructs that I haven’t worked out a way to represent in GCC’s extended version of C. I think GCC has finally caught up with Algol-family compilers of the 70’s and 80’s
That all said - you may ask why the interest in compilers rather than emulators - well, the short answer is we don’t have binaries for most of the systems, so we need to resurrect the old compilers in order to create binaries that can be emulated. And to do that we need a modern compiler that will compile the older compilers. We do have a few system under emulation: we run a Vax/VMS that hosts the Vax Imp77 compiler - a pretty definitive and relatively modern implementation of Imp77 - and we have Mouses running as you know. We have a sort of emulator for the PDP15 - but not the full system, just the compiler and runtime. And that’s it. Lack of manpower to produce anything else. If you wanted the APM to be emulated, try to twist Brian Foley’s arm. Maybe even Fred’s if he’s still interested, though I doubt he would be as he’s moved on in life. Bob Eager has show some interest in a 2900 emulator - there was a problem a few years ago in that ICL (or was it Fujitsu by then) was being proprietary about the 2900 architecture as they were still selling their own system to emulate their old legacy hardware. Bob was also the person who put together the set of sources for the IBM version of EMAS and could perhaps get it running under the Hercules emulator, but again that’s a huge amount of work (and needs compiler bootstrapping which I think is why he was working on a new Imp80 compiler) and I don’t know if he has the enthusiasm to take that on for an audience of maybe 2 or three people interested in seeing EMAS run again! We do have a tape of the Dec10 compiler which might work under a Supnik emulator, though I tried bringing up a Dec10 myself and didn’t recognise any of the system - I suspect the emulation I found was the wrong Dec10 O/S. But the Imp compiler is available if you want to try it. There is potentially an RK11 drive with a binary of “Guts” on it - the Groningen University Time Sharing system - the only O/S written in Imp outside the country. Harry Whitfield was the professor there. Compiled in Imp77 for the PDP11. (And the source of that PDP11 RECODE you mentioned earlier. btw we can find recode programs for most of the architectures but they’re not much use if you don’t have binaries to feed through them.) However I loaned the drive to someone in the Netherlands who said he could read the disk for us back in the 90’s and I never heard from him again. So that’s about it as far as old systems and what we have that might get them going again. By all means email me if you have questions or need help locating files somewhere in the archives. (I don’t always notice notifications about posts here, email is more likely to get to me).
PS Before mine, there was a contemporary Imp80 to C translator written by Peter Stephens of the ERCC/EPCL who wrote most of the EMAS Imp compilers. It was pretty good - given the limitations of standard C which meant that a few constructs could not be translated - but the source code of the compiler (which was a modified version of the regular compiler) had got out of synch with the grammar file describing the language, and when some constructs were hit (if I remember rightly anything that used records in all but the simplest ways) the compiler crashed. Lacking the correct grammar file to rebuild the grammar from, we were unable to repair it, and by that time Peter was enjoying his retirement and not interested in working on the same programs he’d spent the last 40 years working on, and who could blame him! So some years later I had a crack at imp2c - twice - once by decompiling Imp77’s ICode and once with a new parser I wrote from scratch - the first just wasn’t practical as the code it generated might work but was too simplified to be maintainable as an actual C program, and the latter failed to implement all the constructs and I hadn’t learned enough about compiler writing at that point to get it right. This third attempt in progress is after a few years more experience and I’m confident it will work. Most of the code is clean and maintainable; there’s one area that I was still learning as I wrote it (type matching for declarations and expression evaluation) and although that is coming together via a lot of ad-hoc individual cases, I don’t want to release it until I get it working and then re-design it more generally and more elegantly than the current work-in-progress. (Especially as I would like to turn this exercise into a book on how to write a transpiler!)
Thanks for your detailed summary! (I was aware of most of it, but might be of interest for others).
So, there’s few manpower.
There are some few people left who have the knowledge (some might have no interest, others have, but not sharing their code).
And there’s more software and earlier attempts from others that haven’t been made public either.
(Earlier APM emulation, Mouses development kit, other existing emulators).
I am convinced that there are several people who are interested and willing to help but when not widely announcing it and sharing code (like the Mouses emulator for SIMH) noone can help.
So we can only wait for either results or maybe some more finding this here (with knowledge or volunteers).
I am just interested in these rare machines and OS after having found the EMAS sources and the “boot disk”. I’m mainly interested in the ICL 2900. The APM is also interesting and there’s more software but that’s obviously more difficult (needs someone with the hardware to dump it).
My knowledge is limited, and after reading and trying for one year or almost two, I gave it up for now. And yes, I’m also interested in other hardware.
You need to go both ways, A C to imp compiler or translator.
One for C89 and 64K Data and Code size and one for todays C
meg-a-ram programs . The same goes for any code written
in C to remain portable, at least for historical systems.
I’m curious about the DEC-10 compiler. Would it be possible to make the files available somewhere public, such as GitHub?
It’s all here: Index of /archive/dec10 - fetch the tar file, browse the unpacked files. I’m giving github a little longer to see if it is stable - we’ve been through the rise and fall of google’s file repository, freshmeat.net, sourceforge etc already, no reason to believe github will have the necessary longevity, especially after being hijacked by M$. Every M$ URL I’ve ever bookmarked has ended up gone or moved elsewhere a few years later.
Actually the software preservation group of the BCS and also the kdf9 group have looked at this question of maintaining emulators in the long term and came up with a solution of using a subset of C to write them in (at the same level as Skimp, mentioned in an earlier post), that would be easy to recreate a compiler for if C ever died out - a possibility on the sort of time scale we were contemplating - look at Algol60 for example - the standard language for publishing algorithms in back in the 60’s/70’s - now barely exists and the compilers are a half-hearted effort. Indeed I had a hack at knocking together a subset C compiler myself, just to see if it could be done by an average programmer… it wasn’t great but sufficed as a proof of concept.
C is not portable to other languages because of the macro processor, and pointer
operations. Algol is not portable do to lack I/O and the fact that most computers
at the time had the same word length 36 bits. (pre-1960). Modern stuff is not portable
because it directly compiles to a RISC or X86 computer with 8 bit bytes…
Writeing portable code, still depends on the base hardware being similar in architecture
byte vs word addressing, 32K words of memory, 64Kb.1 Meg of memory.24/31/32/64 bit address space.
The best we can hope for is to have portable code and historical code, for different era’s of computing and architecures.
C has already died out, with the demise of the PDP 11, and 16 bit computers.
High level languges, are too abstract, so things like hardware like overflow and carry out
never made it as high level construct, some thing I see as useful in all modern designs,
Modern here being a binary computer, 16 bits or better. With the PDP 11, assembler
was still around for the nasty bits in C. Need 64 bit math you could have library for it
and still be portable. If C had #asm #end_asm carry_flag and over_flow (hardware variables) as standard I am sure don’t need a new standard every few years to meet hardware changes as we do today.
Modern languages don’t expose all sorts of architectural details because they hurt the compiler to do so. C gets into all sorts of problems precisely because it exposes machine behaviour and this prevents optimisations. It’s why fortran is more optimal for some mathematical problems than C even today.
Ultimately a compiler is a mathematical transform, of an expression and the ability to find an optimal transformation for a given execution environment depends upon the sum of the implicit and explicit information provided to the compiler. C for example gets into a hole because of pointer aliasing and partly as a result of that the lack of explicit or implicit ability to work out what is pure and can be lifted.
In other words exposing hardware behaviour can actually make the compiler much much less effective.
I would agree on the eras of computing. One thing that Fuzix really showed me is that it’s possible to build a very portable OS for a given historical range of capability but there are very difficult boundaries above and below it. Older systems had very slow very asynchronous I/O which Fuzix can’t handle, then there is the slice of the 8bit/16bit era where I/O was fast and most of the fancy DMA engines went away, or merely became faster burst transfers. At the other end is the sudden growth from 1MB to 32bit, virtual memory and 8MB+ memory where the original Linux lived and where Fuzix doesn’t really stretch at all. Beyond that you’ve got large scale SMP, gigabytes of memory and again the needs of efficient code change totally, and I guess now we also have the GPU era.
Same with hardware. Slow cycle times drove wide cisc architectures, 36bits was a nice number for accuracy reasons too. The availability of small fast SRAM drove narrower multi-cycle systems, fast RAM made risc possible, then the resulting fast processors drove caching and in turn went wide again with multiple piplelines because we got back to cycle times.
I always worry when I hear the words “On a CD”. CD-R and CD-RW degrade with time, and over time “on a CD” turns out to be “no longer on a CD”. Unlike old magnetic media there isn’t a rescue path either to my knowledge. So whilst we can recover all sorts of ancient disks by spinning them slowly with teflon and a modern disk head on top and other crazy stuff like magnetic imaging, rescue for CD media is basically null.
I would say a Compiler transforms strings around more than a mathematical transform.
I have never belived in all the computer science stuff about parsing and crap to make things
be abstract.You need multi-pass compilers to gather information needed, before you can transform symbolic information to mapping of data and code.
Ben.
PS: I belive in CISC and no CACHES and 36 bits.
There was a time that was perhaps true- it’s very visible in B where the non function parts are almost assembler pass through.
A modern language compiler though turns the entire thing into a giant data structure and performs mathematical transforms on it in order to generate a potentially quite unrelated implementation that is the same (within the transformation rules) but happens to be efficiently executable on the processor. Even things like types are mostly just annotations on range/accuracy except when being used to express fixed layouts in things like storage.
If you look at what goes into a rust compiler and what comes out the other end it’s very different to the old days.
As to 36bit and no cache, the speed of light becomes a bit of a problem at 5 GHz. Even the insides of a modern processor ic are floor planned for things like propogation delays.
Simula 67 may be interesting regarding I/O. It just has interfaces like INTIN, INTFIX, INREAL and OUTINT, OUTFIX, OUTREAL and INIMAGE, OUTIMAGE to flush buffers. So there’s really not much to implement for a specific implementation. Also, it features full-fledged objects and simulation classes. While Simula 67 isn’t especially available, it may serve as an inspiration.
Why in 1967 we had that in the labs, we are just getting now all the ideas from back then?
(around the year 2000).I guess C is for programs, Fortran for science,Cobol for banking and every thing else for teaching computer science.
An addendum to the above saga of Peter Stephens’ Imp to C converter. I said the grammar file had got out of synch with the code, and that we didn’t have the input to the grammar file that generated the tables used in the code… well, after a lot of hacking and comparing multiple slightly-different grammar files, I was eventually able to create one which generated exactly the same tables as used in the imp to c compiler This means that any discrepancies between the grammar tables and the code that uses the tables can theoretically be found and fixed now. Unfortunately… the entire system is written in Imp80 and does not compile using our current Imp77 native x86 compiler, so fixing the Imp to C translator will have to wait until a) Bob Eager finishes his Imp80 compiler for 386; or B) John McMullin extends our Imp77 compiler to handle both 16 and 32 bit data and we convert Imp to C from Imp80 to Imp77 (non trivial); or C) I complete my own Imp to C converter! (The latter being somewhat ironic as Peter Stephens’ one will no longer be needed if I do).
Why go C? Fortran IV was the universial high level langage in 1977 :). Do you need a 386, as there
are lots of emulators out now for the older machines. Did you have any strange hardware for imp 80,
like a 68000 based computer, providing you can find parts that would make a good retro project.
Ben.