Hi!
(I’m also new here.)
Thanks very much for posting the Mouses emulator!
Do you also have the tools mentioned in the readme (mouses-devel-r0.zip) or can explain the (disc) format?
And why not put the emulator on sites like bitsavers or at least the EMAS site (the sources of Mouses are freely available), so that maybe an emulator for EMAS could be created.
Long time ago, I tried out the (older) IMP compilers from jdmcmullin (thanks for your efforts!) and others but that’s another, long story.
The new 2021 version is too complicated (for me). Aren’t most IMP sources (EMAS/APM) IMP80? If someone has to adjust the code (and libs), someone also could rewrite the code in another language. Has to be done for hardware stuff anyway. Much better would be an emulator and/or (disc/tape) tools (pack, extract, convert).
Share the wealth is good idea. Look what happened to the Edinburgh IMP archive,
one crash and they never recovered from it.
One problem is with portable code, it has to be written from the start to be portable
often a subset programing lanuage. if(*b++) blah; does not port to FORTRAN IV
well, but t=b[i];i=i+1;if(t) blah; does better.
You also need to include a macro processor, for languges like C.
Was not a MACRO PROCESSOR was how you got a high level languge at one time?
print(“hello world”) becomes move string “hello world” to card punch, punch card.
ben
Unfortunately I’m not the source of the Mouses kit - that was passed to me from Fiona Culloch who was one of the users/developers (along with the creator, Peter Robertson; and Chris Whitfield and Ian Young). You’d have to contact her for any updates.
If you want to try the new x86 imp, I put together a bootstrap compiler in C which is not yet part of the distro, but if you want to risk a try, create an empty directory on linux and in that directory issue wget https://gtoal.com/imp77-in-C/DevRelease0.3/MAKE-ALL.sh ; sh < MAKE-ALL.sh |& tee MAKE.LOG (or just read the README at https://gtoal.com/imp77-in-C/DevRelease0.3/README.txt ) Don’t expect it to work on 64 bit-only linux, or FreeBSD, or MacOS. It’ll either work really well or really badly I’m not looking for feedback right now as I’m working on something else.
To answer the comment by ‘oldben’ in another post, the Edinburgh archive neither crashed nor was lost; however it was transferred to Edinburgh’s Informatics department who have such excessive security on remote access that we’ve never ever managed to log on to their systems to make updates, and the files are frozen as of some years back. I have any newer acquisitions on my home system (and backups) pending either access, getting the domain back, or setting up a second site outside the ed.ac.uk domain. Also we are well aware of portability issues, using subsets of a language, etc, and not only have done so but have even worked on a couple of subset compilers that could be easily bootstrapped in the future (specifically in the KDF9 recovery project).
I don’t know how to contact these authors and maybe they won’t give out their code.
The discs were created with a tool called mvol (I only found IBM’s Move Volume). No need for extracting them either as all contents (SRC and binaries) are available in the sources. Creating discs or tapes is useful. The OS can also read IBM tapes. The only tools I know are the Hercules DASD tools.
I wonder, why both are spending so much time on IMP77 compilers. Even if they work and even if they were IMP80, I think someone can only run small, basic/text-like code + has to check and rewrite all IMP code and libs (depending on the hardware) + get a 32 bit linux.
As said the only way for me, running the relevant software on the EMAS site without rewriting all the code, are emulators. One for EMAS on ICL290xx, one for the APM machine, and maybe for the others like PDP-9/15, VAX etc. Christopher Lisle wrote one for the Fred / APM machine (for 68k Emulator Musashi by Karl Stenerud (MAME)), one for Amdahl (470 ?) and we have the MOUSES. We should make a call, find the authors and volunteers and start emulating projects.
Here is a PDF with screenshots of the APM including games like Frogger and Pacman
I extracted most pics (one showing another APM machine in rack format) and made slideshows on YouTube. Still missing the RLE compressed and other IFF subformats.
whispers 64 bits
Small is relative, measuring size in bytes is miss leading. Size is based on the
addressing word size since pointers and ints are often the same. Your program
+data fits in the space given or it does not.
ch = *p ++
.CODE
LD.W A Z ] _P
LD.B B A ] 0
ST.B B Z ] _CH
LD.W A Z ] _P
ADD A #1
ST.W A Z ] _P
.DATA
_P
DW MY-STRING
_CH
DW 0
EXTERNAL MY-STRING
2 words data. 4/8/16 bytes data
That is 6 instructions, or 12 words. You have 24/48/96 bytes for the basic code
block. Look ma, UNICODE to me.
Why no UNICODE. A) word size is not a constant, B) computers don’t have the
basic UNICODE instruction set. A unicode instruction set would have all the primitives needed to impliment higer level software constructs,
C: multi-pass translation,
Ben.
Yes, I know.
Have you seen some IMP source codes?
Most are huge. And have many deps, incs, libs etc.
Especially the 68k APM machine (late 80s ?)
Hundreds of lines. Maybe a couple of MBs.
No. Not having any IMP hardware I just glanced at IMP 77 (15?) years ago
I was plannig to port IMP or some other language to a home brew
cpu I am designing, from that era. Right now is running a emulation
on a DE1 FPGA development card, with a semi-stable instuction set.
20 bit words/10 bit bytes, BCD floating point.
(2901 alu + external BCD adder)
My only real IMP77 experience was c1978/79 on a 32-bit “mini” - an Interdata 7/32. This is a 32-bit machine with a good number of registers. I use it as a sort of benchmark of what was possible then to frustrate myself about what I’m doing now. I think the Interdata was a nice CPU… It seemed to support half a dozen idiot schoolboys abusing it quite well…
How hard to take your 20- bit system up to 32? I’m looking at a Gowin FPGA that has 16MB of RAM on-board. It’s a bit of a beast but capable of taking a RISC-V core with room left over…
I’ve gone down to BCPL route for now - not sure I have the time or means to look at Imp again but who knows.
Oh, I do remember those microwave-sized machines from my brief time in the CS department at Edinburgh. And somehow, the memory of them being called Fred machines has just surfaced too, as a result perhaps of thinking about IMP77. I might have written just a page or two of code in that language. I had no idea what I was doing with high level languages! Or proper computers for that matter.
I do have some ideas for a 8/16/32? or 8/16/48? bit cpu, that I can try after I finish this design. I have only 512x8 static ram with my fpga card, so I have no need
for a bigger machine. I do have a few meg of dynamic-ram, but no interface for it.
The main advantage with a 20 or 24 bit machine (or 36 bit) is you get better basic floating point. I also have 512Mb direct address space compared to bank switched 16 bit cpu for the era my design is with, TTL logic and 4 or 16k dynamic ram and 80x24 terminals. Ben.
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.
I’m not looking for feedback right now as I’m working on something else.