Compiler and Testbed Progress

We have made a couple of small tokens of progress over the past several weeks. This post is a brief update to report on those.

ALGOLXEM Compiles Algol and ESPOL

As previously reported, we had succeeded in porting the B5500 Mark XVI Algol and ESPOL compilers to the modern Unisys MCP (E-mode) environment, where they function as cross-compilers to generate B5500 object code files. We hope ultimately to feed these object files to our emulator. We call these cross-compilers ALGOLXEM and ESPOLXEM, respectively, with "XEM" standing for "cross-compiled on E-mode."

These are not quite full ports of the B5500 compilers, but are intended only to be sufficient to compile enough software that we can test and bootstrap the emulator into running the MCP operating system. In particular, most of the exotic source handling (patch merging, include files, CAST tapes, etc.) was difficult to port, and was simply removed from the compiler.

We had compiled a number of relatively small programs with these compilers, and as far as we have been able to tell, they had been generating the correct output. This hardly constitutes exhaustive testing, however, and I had been somewhat dreading the prospect of trying to compile the Algol compiler with its XEM counterpart. Frankly, I was expecting a train wreck in the form of compiler crashes, conversion errors, and source transcription errors that had gotten past the initial tests, and I wasn't looking forward to it.

Late last month, I found myself in possession of an idle afternoon. On a whim, I decided just to try compiling the B5500 Algol compiler and see what happened. Imagine my surprise when not only did the XEM compiler finish normally, but reported only seven syntax errors in the 12,700-line source file.

Three of those errors turned out to be straightforward typos in the original B5500 compiler source transcription. The rest were due to two bugs in ALGOLXEM, which in turn were due to typos in the original B5500 source. Finding and fixing those took all of an hour, at which point the XEM compiler compiled the B5500 compiler successfully on the second attempt.

This was too easy, so I decided to try the same thing with the B5500 ESPOL compiler. The first compilation finished with eight syntax errors, which all turned out to be typos in the ESPOL compiler source. After fixing those, ESPOL compiled on the second attempt as well.

No one is more amazed than me at the ease with which we have reached this step in the project. Of course, successfully compiling those two large programs hardly indicates that ALGOLXEM is working entirely correctly, but it is a very encouraging sign, indeed.

Comparative Timings

One interesting byproduct of these tests is that we now have some significant run-time data to compare against the B5500 times. I did these compilations on an MCP SDK (development) system called the LX100. For the past 15 years, Unisys has been very successful in emulating the E-mode architecture on Intel processors running under Windows, using that approach to replace proprietary hardware in the lower end of their product line. The SDK is composed of the standard E-mode emulator and a special development-only software license. In my case, it is running on a several years-old Dell workstation under Windows XP.

The emulated systems are typically throttled to a specified performance level. Unisys has long had a system performance metric termed RPM (Relative Performance Measure). It is determined from a mix of benchmarks for various types of workloads and normalized so that a specific model of the A6 (a late 1980s design) had an RPM value of 100. My SDK system has an RPM of 300. By way of comparison, a single-processor B6500/6700 system had an RPM of 50-60, and current high-end MCP systems have RPM ratings in excess of 20,000 per processor. To make a more general performance comparison, there are slightly less than 25 RPM per Gartner MIP.

Somewhere in the early 1970s I read a report stating that the B6500 designers were expecting an 8-10 times performance improvement over the B5500, but that they seldom got as high as a factor of eight except on heavily numeric benchmarks. That suggests that the B5500 probably had an RPM rating of roughly 7 to 10.

There are two sets of timings available from B5500 compilations. One is the time printed by the compiler at the end of its listing. This is the elapsed time, from the Algol TIME(1) intrinsic, excluding any initialization and termination for the compilation—specifically, it's the amount of time the compiler spent executing its PROGRAM procedure.

The other timings are those reported by the MCP. We have this for the Algol compilation on the B5500 from 1977, but not for the ESPOL compilation. The following table summarizes the data for the B5500 and XEM compilations (ET=elapsed time, CPU=processor time, I/O=channel usage time). In each case, these compilations generated a full listing and a cross-reference. All times are in seconds.

Compilation	Lines	Compiler ET	MCP ET	MCP CPU	MCP I/O
B5500 Algol	12,712	532	1045	736	369
XEM Algol	12,706	36	48	40	14
B5500 ESPOL	6,918	816	n/a	n/a	n/a
XEM ESPOL	6,916	21	28	24	8

The small differences in the number of lines of code reported by the compilers are probably due to the differing numbers of "$-card" pragmas which are not visible in the listings.

To be fair, the XEM runs were made on my otherwise idle development system. In addition to a 300 RPM rating, this system has 32 megawords of E-mode memory, so it does no virtual memory overlay. Disk I/Os are also heavily cached by the underlying Windows environment.

By contrast, the B5500 probably had the maximum 32 kilowords of real memory. We cannot know what other load was on the system while the compilation was taking place, although there probably was some. The 30% difference between CPU and elapsed time for Algol suggests that interference from other tasks was not all that great; the significantly higher elapsed time for the ESPOL compilation suggests that it was running in a busier mix of jobs. The Head-per-Track disk used by the B5500 had an average access time of about 40 milliseconds and a transfer rate of perhaps 200 KB per second—reasonable for its time but very slow by today's standards, let alone the lack of any memory caching.

From the single data point available by comparing the two compilations of the Algol compiler, it appears that the B5500 may have had an RPM rating of about 16 for this type of workload—about twice what I had been expecting. That would have made it about one-fourth the speed of the B6500 in this case, which considering that the B6500 seldom showed its hoped-for 8-10X improvement over the B5500, may have been typical performance.