The only Alto-friendly feature of Chifir is its frame buffer (which simplifies some things but complicates others with its one pixel per 32 bit word scheme). Since the Alto is a 16 bit machine the 32 bit VM has to do some extra work, though detecting carry and overflow is easier on a wider machine.
There is indeed no indexing but it has indirect addressing (essentially load and store).
What about the other āAltoā specific features, that seem
to give other ALTO emulators (hardware or software) problems? like the computer mouse (patented disney-apple-food4euro 2027 ) or the hard disk. I donāt agree with all the features point and click operating sytems have but a
portrait monitor is the way to go.
Chifir has no disk nor mouse as described in the paper, so I donāt know how that is supposed to work.
Iāve just discovered this forum. As a Covid lockdown project, I have been ātweakingā the ABD Intel IMP compiler and put it on github under siliconsam/imp2021. I extended the compiler to embed a limited sub-set of āassemblerā code and removed a large amount of C source replacing it with IMP77. I also added some utlities to read/write the iCode generated and the āobjectā language generated by pass2. The IMP source code is common to Windows and Linux (apart from underscores for external C I/O calls)
Wow! That came out of nowhere - I had no idea you were working on this! Iām looking forward to trying it.
You mentioned next plans - if you do start an ARM code generator, you may get a start with PSRās code generator for the original ARM:
https://history.dcs.ed.ac.uk/archive/languages/imp77/pass2-arm.imp
https://history.dcs.ed.ac.uk/archive/languages/imp77/pass3-arm.imp
Also Index of /archive/languages/imp77-acorn-tmp
Thereās also a Pascal front end but the Pascal code wonāt all be online because of licensed test suites.
Though you mentioned using an iBurg system, so an LLVM backend would be the most useful option in terms of portability.
I couldnāt tell from your description if this included a native Linux version or if you just meant the Windows code ran under Linux using Wine? A fully linux-hosted version would be great.
We can probably find most of the imp library sources in Imp somewhere or other.
Great to see this. Are you on the Edinburgh Computer History mailing list or FB group as well? We need to let the rest of the Edinburgh folks know.
Welcome!
Sounds great - but I canāt find itā¦ is the repository private perhaps?
URL for IMP2021 (a year that will live in infamy!) is
GitHub - siliconsam/imp2021.
You should be able to copy the repository via github tools.
jdmcmullin
Graham,
There are 2 versions of pass3 (COFF and ELF) (still in C) but I did write a FreePascal translation of the COFF generator.
The repository should be loaded on a Windows box (I use 8.1 and 10)
There is a script called makelinux (in the source folder) which runs on Windows to generate the ELF object files and a source tree. This generated source tree can be copied accros to a Linux box (I use a Centos 7 VM on my Windows 8,1 box). You may need to ātweakā the makefile in the compiler and lib folders to ensure the correct ar,install commands work. From then on the IMP compiler is ānativeā to the Linux box. You can alter the source code and rebuild to your hearts content (in Linux and avoid Windows)
Most source code is common to Windows and Linux, code differences ocur when accessing non-IMP routines. I used %alias a lot so some alias strings have an underscore (only difference)
I didnāt know of the Edinburgh Computer History mailing list or FB group. Can you give me instructions on how to join?
Iām a Hull Universith Maths graduate (70-73), only contact was via Lattice Logic ~25+ years ago when I worked for Ferranti Electronics.
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
The MLP-900 was another machine specifically made to emulate others.
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).
Thank you, for the comment about the Edinburgh archive.
Ben.
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
Blimey! I remember visiting Edinburgh Uni and seeing one of them - and the photo in the PDF has just rekindled that memory. Amazing.
Wish I could remember what that visit was about, but 40 years ago nowā¦
(Mutter, mutter, picked the wrong university, grumbleā¦)
Thanks,
-Gordon
There are many source codes (in IMP), docs, binaries (.mob) and pics (mainly in .IFF, not the Amiga format) on the EMAS site
https://history.dcs.ed.ac.uk/archive/os/
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)
Thanks. Yes, Iāve seen that thanks to Grahame when looking for Mouses stuff, but hadnāt equated the Fred to APM when I looked a while back!
-Gordon