I moved to Ann Arbor in 1975 and ultimately was recruited by none other than Geoffrey Leach, who was on the team that ported XPL to the Sigma 5.
In those days, getting data into computers was often through keyboard entry. As you might imagine, this is error prone. Sycor invented the intelligent terminal in order to address this problem. The first terminals were built out of medium scale ICs. Programs would be loaded from cassettes, and data would be saved to the cassette.
The next level of product was more sophisticated, incuding an operating system. The CPU was an 8085 and the hardware included a disk. The language in use was PL/M along with assembler.
The PL/M compiler, which was written in Fortran, was proving very difficult to maintain. The system required modification to the compiler to fit with the requirements of the system. Additionally, it was felt that there were some shortcomings in the language itself.
XPL along with PL/M were models for this new language.
The language was called Syclops. (Yes, I groaned when this name was chosen. )With input from the team of programmers and technical management, the language underwent two significant revisions.
Our project started out on a 360/25 or 360/35 running batch jobs. Our language of choice was PL/I. Wiser heads eventually prevailed, and they acquired a PDP-10 running Tops-10.
This provided time-sharing capability to all programmers.
The host language was now Bliss 36, a unique systems programming language. It was a good match for writing the compiler, and much better than PL/I.
The language in use was PL/M, so our design had to be fairly close to that. Partway through the project, we changed the language based on input from the users.
Thus, we changed the host computer, the host language and the target language on this project.
One of the team members, Jeanne Musinski PhD, a student of Jeffrey Ullman, discovered a better error recovery mechanism and published a paper about this. She was responsible for building the parser. I took up the challenge of code generation. The third member of the team worked on the semantic output from the parser and the documentation for the language.
We were a bit young to know how long it should take, so we did it in a year.
Since most of the users were hard-core assembly language programmers, a legible output of the assembled code was a necessity.
To help their performance calculations, the assembly output would put the total clock cycle count at the end of each basic block. It would also put out some instructive comments about the logic exercised, such as moving a register value to a saved location.
An amusing incident repeated itself once or twice in the beginning. A programmer would bring a listing showing some goofy assembly output from the compiler. We would sit down and go over it instruction by instruction. Generally, three quarters of the way through there would be the realization that the code was OK, and likely optimized in a way that was usual for them. The boss said "A compiler should generate code that an assembly language programmer would get fired for writing."
One day the VP came rushing in with a complaint from one of the programmers. "Why did you say it would take a week to fix this simple bug?" Our reply was that we had reports of two bugs. "We told the person who reported the bug that one bug would be fixed right away, and the other would take a little while ". "The short one is already fixed. We never said a week. The longer one will be fixed later this afternoon."
The mismatch of expectations was that the older Fortran code base for the PL/M compiler was very difficult to work with. Our new base was much streamlined and as a result we were able to turn things around in a matter of hours, not a week.