While I wasn't around during development of the Bellmac 32 processor, I did know a few people at Bell Labs who were involved, which leads to this story which was related to me many, many years ago. Apologies if this is just a figment of my recollection.
Apparently, the very first samples of the chip had a serious bug: instructions that jumped to new memory address would sometimes jump instead to an address within some small number of locations of the desired target. The developers took to informally calling this the "Jump Approximate" instruction. To work around this, the C compiler was hacked to pad instructions around all jump targets with no-ops. Obviously this was a perf issue, but Unix was still brought up, and later the bug was ultimately fixed and the compiler hack backed out.
Hi Andrew, Thanks for commenting and sorry for the delay in replying. That's a fascinating story. I suspect that it's not the only time no-ops have had to be inserted in code to deal with bugs! The Bellmac is on my (long) list of architectures to write about so I'll make sure to remember this anecdote. Best wishes.
I remember some enthusiasm for Hobbit in mobile battery powered designs like EO. AFAIR Moto countered with its Dragonball used in smart pagers early Palm devices. There was also discussion of "Asynchronous ARM" designs that looked cool in view of Sutherlands whitepaper "Micropipelines."
Like specialty CPUs for Lisp, Smalltalk, Forth, and Java, Hobbit seemingly could not find design wins versus more general purpose and widely adopted X86 and ARM variants. Later Transmeta marketed lower power consumption while maintaining X86 software compatibility.
This was a lot of fun. Thank you. Re your closing note (the iPhone launch): With my MBA students, I used to show the 2007 iPhone announcement with Steve Jobs and Stan Sigman from the then-Cingular Wireless. This was as part of a class on network operators as integrators of products from other companies. I would show the photo of the two CEOs on stage and ask if anyone could name the CEO next to Jobs. The only people who ever could were AT&T employees who were part-time MBA students.
Nice post, thanks! It's interesting to consider how mis-estimation of compiler capabilities has influenced processor design. Here the Hobbit replaced registers with a stack cache on the grounds that compilers were buggy and register allocation was hard, where nowadays even very sophisticated compilers are pretty reliable and register allocation is good enough to get the job done. The tag-match for the stack cache lookup would surely have made wider super-scalar or out-of-order designs much harder. Consider the other course: Itanium's designers expected that the compiler would be able to find and use enough instruction-level parallelism, and keep a sliding register window aligned, when neither of those ended up coming to pass, and instead branch prediction and register renaming ended up running rings around it.
AT&T/WE did produce a very useful and widely used processor at about that time, also designed for execution of C code: the DSP32 (later DSP32C in CMOS). Interesting for being a floating-point-only DSP at a time of mostly fixed-point designs, and for having only 24-bit integer/pointer general purpose registers. Nice machine that got away with having a very literal and simple C compiler (as long as you used the "register" keyword appropriately!)
The TI C6000 family of DSPs also had "C target" as an explicit design point. By that time C-target meant byte-addresssible memory and regular 32-bit words for instructions and data, and a single unified address space (all of which were uncommon in the previous generation of DSPs).
I powered up my eo440 a couple of years ago (all eo employees received a free one). The battery had long since died, but it powered up from the power adapter. One major problem was that the only network connectivity it has is a dial-up modem designed to connect to AT&T's companion service, which of course is long defunct. Another surprise was that the system date can only be set as late as something like 2000 (I forget the exact year, but it was long before 2020 when I was trying this!) I had to set it to a year within the allowed range whose dates mapped to 2020.
This article also reminded me of another C Machine I worked with - a software one! Before I joined Active Book Company, I worked at another Hermann Hauser company, European Educational Software, or E2S. One of the goals of that company was to develop a C virtual machine so that the applications we were developing could be compiled to its bytecode and executed on a wide range of hardware. (This was many years before the JVM, but after p-code Pascal.) The VM work was done by a consultant who I think was attached to Paul Bond's Tripos company. Unfortunately, the project never came to fruition, and I can't find any references to it on the web.
One final note about Hermann Hauser. He's an absolutely stellar guy! I worked for him at several companies, from Acorn through Active Book, and he personally helped me during a very dark period of my life, for which I will be eternally grateful to him.
While I wasn't around during development of the Bellmac 32 processor, I did know a few people at Bell Labs who were involved, which leads to this story which was related to me many, many years ago. Apologies if this is just a figment of my recollection.
Apparently, the very first samples of the chip had a serious bug: instructions that jumped to new memory address would sometimes jump instead to an address within some small number of locations of the desired target. The developers took to informally calling this the "Jump Approximate" instruction. To work around this, the C compiler was hacked to pad instructions around all jump targets with no-ops. Obviously this was a perf issue, but Unix was still brought up, and later the bug was ultimately fixed and the compiler hack backed out.
Hi Andrew, Thanks for commenting and sorry for the delay in replying. That's a fascinating story. I suspect that it's not the only time no-ops have had to be inserted in code to deal with bugs! The Bellmac is on my (long) list of architectures to write about so I'll make sure to remember this anecdote. Best wishes.
FYI an old but good reference for chips/devices like Bellmac, SOAR, 432 , S/38, ROMP, Scheme-83 etc.
Software-Oriented Computer Architecture: Tutorial by Fernandez and Lang
https://www.amazon.com/Software-Oriented-Computer-Architecture-Eduardo-Fernandez/dp/0818607084
Hi Will, Thanks - that looks like a really interesting reference. I see that there is also a copy at the Internet Archive. Best wishes.
https://archive.org/details/tutorialsoftware0000unse_s5q2
I remember some enthusiasm for Hobbit in mobile battery powered designs like EO. AFAIR Moto countered with its Dragonball used in smart pagers early Palm devices. There was also discussion of "Asynchronous ARM" designs that looked cool in view of Sutherlands whitepaper "Micropipelines."
Like specialty CPUs for Lisp, Smalltalk, Forth, and Java, Hobbit seemingly could not find design wins versus more general purpose and widely adopted X86 and ARM variants. Later Transmeta marketed lower power consumption while maintaining X86 software compatibility.
This was a lot of fun. Thank you. Re your closing note (the iPhone launch): With my MBA students, I used to show the 2007 iPhone announcement with Steve Jobs and Stan Sigman from the then-Cingular Wireless. This was as part of a class on network operators as integrators of products from other companies. I would show the photo of the two CEOs on stage and ask if anyone could name the CEO next to Jobs. The only people who ever could were AT&T employees who were part-time MBA students.
Nice post, thanks! It's interesting to consider how mis-estimation of compiler capabilities has influenced processor design. Here the Hobbit replaced registers with a stack cache on the grounds that compilers were buggy and register allocation was hard, where nowadays even very sophisticated compilers are pretty reliable and register allocation is good enough to get the job done. The tag-match for the stack cache lookup would surely have made wider super-scalar or out-of-order designs much harder. Consider the other course: Itanium's designers expected that the compiler would be able to find and use enough instruction-level parallelism, and keep a sliding register window aligned, when neither of those ended up coming to pass, and instead branch prediction and register renaming ended up running rings around it.
AT&T/WE did produce a very useful and widely used processor at about that time, also designed for execution of C code: the DSP32 (later DSP32C in CMOS). Interesting for being a floating-point-only DSP at a time of mostly fixed-point designs, and for having only 24-bit integer/pointer general purpose registers. Nice machine that got away with having a very literal and simple C compiler (as long as you used the "register" keyword appropriately!)
The TI C6000 family of DSPs also had "C target" as an explicit design point. By that time C-target meant byte-addresssible memory and regular 32-bit words for instructions and data, and a single unified address space (all of which were uncommon in the previous generation of DSPs).
Interesting memory jogger, thanks!
I powered up my eo440 a couple of years ago (all eo employees received a free one). The battery had long since died, but it powered up from the power adapter. One major problem was that the only network connectivity it has is a dial-up modem designed to connect to AT&T's companion service, which of course is long defunct. Another surprise was that the system date can only be set as late as something like 2000 (I forget the exact year, but it was long before 2020 when I was trying this!) I had to set it to a year within the allowed range whose dates mapped to 2020.
This article also reminded me of another C Machine I worked with - a software one! Before I joined Active Book Company, I worked at another Hermann Hauser company, European Educational Software, or E2S. One of the goals of that company was to develop a C virtual machine so that the applications we were developing could be compiled to its bytecode and executed on a wide range of hardware. (This was many years before the JVM, but after p-code Pascal.) The VM work was done by a consultant who I think was attached to Paul Bond's Tripos company. Unfortunately, the project never came to fruition, and I can't find any references to it on the web.
One final note about Hermann Hauser. He's an absolutely stellar guy! I worked for him at several companies, from Acorn through Active Book, and he personally helped me during a very dark period of my life, for which I will be eternally grateful to him.