Editing IBM 801 (section)

==Later modifications==
Having been originally designed for a limited-function system, the 801 design lacked a number of features seen on larger machines. Notable among these was the lack of hardware support for [[virtual memory]], which was not needed for the controller role and had been implemented in software on early 801 systems that needed it. For more widespread use, hardware support was a must-have feature. Additionally, by the 1980s the computer world as a whole was moving towards [[32-bit]] systems, and there was a desire to do the same with the 801.{{sfn|Cocke|Markstein|1990|p=7}}

Moving to a 32-bit format had another significant advantage. In practice, it was found that the two-operand format was difficult to use in typical math code. Ideally, both input operands would remain in registers where they could be reused in subsequent operations. In the two-operand format, one of the two values was overwritten with the result, and it was often the case that one of the values had to be re-loaded from memory. By moving to a 32-bit format, the extra bits in the instruction words allowed an additional register to be specified, so that the output of such operations could be directed to a separate register. The larger instruction word also allowed the number of registers to be increased from sixteen to thirty-two, a change that had been obvious from the examination of 801 code. Despite the expansion of the instruction words from 24 to 32-bits, programs did not grow by the corresponding 33% due to avoided loads and saves due to these two changes.{{sfn|Cocke|Markstein|1990|p=7}}

Other desirable additions include instructions for working with string data that was encoded in "packed" format with several characters in a single memory word, and additions for working with [[binary-coded decimal]], including an adder that could carry across four-bit decimal numbers.{{sfn|Cocke|Markstein|1990|p=7}}

When the new version of the 801 was run as a simulator on the 370, the team was surprised to find that code compiled to the 801 and run in the simulator would often run faster than the same [[source code]] compiled directly to 370 [[machine code]] using the 370's [[PL/I]] compiler.{{sfn|Cocke|Markstein|1990|p=8}} When they ported their experimental "PL.8" language back to the 370 and compiled applications using it, those applications ran as much as three times as fast as the PL/I versions. This was due to the compiler making RISC-like decisions about how the generated code uses the processor registers, thereby optimizing out as many memory accesses as possible. These were just as expensive on the 370 as the 801, but this cost was normally hidden by the simplicity of a single line of CISC code. The PL.8 compiler was much more aggressive about avoiding loads and saves, thereby resulting in higher performance even on a CISC processor.{{sfn|Cocke|Markstein|1990|p=8}}