OpenRISC Conference at TU Munich. Thanks to everyone there for a thoroughly stimulating and enjoyable workshop. We hear the videos and slides will soon be posted online. A question we were often asked there, and previously in blog postings and emails, is why we didn’t just build on the OpenRISC project? We were very aware of OpenRISC and carefully studied the ISA in 2010 before deciding not to use it. The following technical problems were behind our decision to start from scratch rather than improve OpenRISC: 1) The 16-bit immediate field takes up too much of the encoding space, making it difficult to add extensions. There’s also no support for extended-length instructions, which is another way to support extensions. 2) There was no 64-bit address space version. While there has been some work since 2010 towards the 64-bit address space version of OpenRISC, hardware implementations and software stacks are still not available. 3) Branch delay slots. At the time we investigated OpenRISC, the architecture still had mandatory delay slots, though recent variants of OpenRISC allow the branch delay slot to be optionally removed. 4) There was no support for compressed instructions. We wanted to support a dense instruction encoding to reduce static code size in embedded systems, and to reduce dynamic instruction traffic in high-end servers. If we had made these changes to OpenRISC, we’d have effectively designed a new ISA in any case.]]>