Was FORTRAN buggy 4332
 |
Yes, I understand this. That's why the Jupiter was an emulation. Right. However, I keep running into people who believe...
the cp67h updates to cp67 kernel (runs on 360-67, provides 360 virtual machines, and 370 virtual machines as an option). cp67i updates to cp67 (at least thinks it is running on 370, provides 370 virtual machines).
this was running regularly at cambridge a year before first 370 engineering model was operational. when endicott had an engineering model 370-145 ready to boot (lore is that ipl-boot button was actually a knife switch) ... cp67i kernel was brought in to boot as test of the machine.
the initial boot failed ... after a little diagnostic, it was determined that the engineering machine had reversed the "B2" opcodes for two instructions (i believe PTLB and RRB). the cp67i kernel was quickly patched and reboot then went succesfully.
since this was the first engineering prototype machine ... it was quickly patched to correspond to the official architecture definition.
recent posts mentioning cp67h and cp67i updates for the cp67 kernel
I've also mentioned another problem with getting vm370 up and running on 370-125 ... recent post mentioning the effort
360 instructions would pretest starting and ending addresses for argument ... for things like protection (fetch & store) or page fault (at least on 360-67) ... and indicate exception before even starting the instruction. 370 introduced a couple (long) instructions that executed incrementally. machine would process "long" (compare, move) instruction argument locations incrementally and only indicate fault-exception when it encountered storage access problem (for storage address being directly processed).
move long had two pair of registers, with origin start&length and destination start&length. on instruction completion (or exception) the registers would indicate how far processing had gotten (incrementing argument addresses and decrementing remaining length). move long also provide for "pad" byte for scenario where origin length was less than destination length. it was possible to use this for clearing storage by setting the pad byte to zero, the origin length to zero and the destination length to the desired amount.
early vm370 kernel used mvcl early in the boot process to both clear memory and test for size of memory (by setting destination length to max). when the instruction encountered end-of-memory would would result in exception and the registers would be update to reflect where end-of-memory was.
Unfortunately. It is causing a belief that what works on a TTY screen is reality. I started noticing this atbreastude about 10 years ago. It's now crept into the computer biz. Sure. But...
early 370-125s were shipped to customers with a "bug" in the long instructions microcode ... it would "pretest" starting and ending argument addresses and cause an exception interrupt if there was a problem before even starting the instruction (instead of executing the instructions incrementally and only generate exception when it got to argument storage address with an issue).
But don't you see? In order to reproduce every form of hardware failure of a piece of gear, you have to have the real physical piece of...
as a result, vm370 would think there was no real storage on 370-125 to execute in and fail.
besides having to optimize vm370 kernel size to fit it into 370-125 256kbytes, it also had to be modified to get around the 125 mvcl microcode "bug" (at least until 125s were retrofitted with fix).
misc. past posts mentioning the MVCL bug on 370-125