Hacker News new | past | comments | ask | show | jobs | submit login
SOAR-ing Away with Smalltalk: Berkeley RISC-III (thechipletter.substack.com)
49 points by rbanffy 3 months ago | hide | past | favorite | 6 comments



The article could have mentioned that the idea of instructions to operate on tagged words was carried forward into SPARC.


In the SOAR all instructions could be tagged or not (the % bit selected this). They then tested the effectiveness of this (Patterson's "quantitative approach") by changing their compiler to output non tagged versions of a given instruction with explicit software checking and then comparing the results of several benchmarks with the same code using the tagged instructions. It turned out that only the tagged ADD had a measurable result.

So when the SPARC was created it included a TADD instruction. It also had a TSUB for symmetry even though the SOAR guys showed it didn't really help. The tags were moved from the top bit on SOAR to the bottom two bits in SPARC. Unfortunately exception handling on 32 bit SPARCs was really slow so pure software alternatives actually performed better. This exception handling problem also made register windows far less interesting than they had been in the Berkeley designs (this was improved in SPARC v9).


That and register windows. SPARC was designed to run C very efficiently.


I'd say all RISC CPUs were designed with the intention to run C very efficiently. However virtually all other designers didn't come to the conclusion that register windows were a good idea.

Patterson has said they only did that on RISC-I and RISC-II because Berkeley didn't have as good compiler technology as the MIPS guys at Stanford, and once you have a compiler with good register allocation the now standard Argument / Saved / Temp register split as an ABI convention is better.


RISC-I and II had register windows.


hi




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: