The Ribbon wasn't too bad as an idea. Unifying the toolbar and menu bar makes a lot of sense, though on small-screen devices it was a problem. The thing that made it a UI disaster was automatically moving things around, breaking muscle memory and making it impossible to use anyone else's version of Office.

There's a lot more politics to it than that. LibreOffice started as Novell's Go-OO fork, which contained things covered by MS patents that could not be upstreamed because the indemnity only covered Novell. They managed to spin it very well about wanting to avoid Oracle being in control though...

It's an entirely new ISA that is intended to be freely licensable.

There are 32-bit and 64-bit variants of the ISA (128-bit is coming). It also includes a variable-length instruction encoding (though currently all instructions are 32 bits) so that it's easy to extend (finding gaps in the MIPS opcode space can be challenging).

Really? Usually we want to use something for teaching that's easy to understand and modify...

Which you don't do with a simplified Verilog implementation. If you want to be able to easily modify something in an academic setting, then you want a high-level HDL, such as BlueSpec or CHISEL. BERI or Rocket fits this need a lot better that MIPSfpga.

Thanks for clarifying. There was nothing in the web page to indicate this (a fairly common omission on ImagTec blog postings, by the way).

I'm sorry, but that's complete nonsense. All of the branch-likely instructions were removed and replaced by the compact branches. These are emitted by gcc and are very common in gcc-compiled code (which appears to use them when it can't find an instruction to fill the delay slot with). Trust me on this - I spend a huge amount of my life looking at objdump output from MIPS binaries and instruction traces.

No you don't. You reused the opcodes, unless there's a newer version of the spec than the one I've seen.

There was a study posted on Slashdot about this myth a few years ago. They concluded that Americans care more about their teeth because good dental care is expensive and so is a status symbol. Having few teeth is one of the stereotypes of poor/stupid people in the US. Middle class and aspiring middle class people in the US spend money on their teeth (cosmetically, at least) because if they don't then they look poor. For people in the UK, anyone can afford good dental care (for a while, it was easier for very poor people to because a lot of dentists weren't taking new NHS customers except under duress and people on certain forms of income support had guaranteed treatment), so going to the dentist is just seen as a chore and often slipped down priorities.

I was slightly ahead for arithmetic (but not by much), but I was at the very bottom for writing - to the extent that I was the only one having to stay in at break times for extra practice. This was not at a selective school (I started at one aged 7), this was at a school with a full mix of ability.

That's rather my point. My school managed to teach all of us those things, what's wrong with schools in the USA?

I keep a tiny wireless access point in my suitcase for these cases. Even with ethernet on my laptop, my phone and tablet don't have an RJ-45 connector and I don't always want to be using my laptop as an AP. Most hotel networks can't come close to saturating 802.11g, let alone .n.

I'm moderately associated with RISC V (the lowRISC people are upstairs and I'm in the acknowledgements section of the RISC V spec). The main drawback of RISC V currently is the lack of software. Krste claims that the cost of the software ecosystem for RISC V will be around a billion dollars. My friends at ARM think that he's underestimated that by at least a factor of two. I had a student working on RISC V this year (using the BlueSpec in-order implementation) and the state of the LLVM toolchain is a joke - it's several man-years of work away from basic functional correctness (he had to fix a number of bugs to get simple benchmarks to work), getting it to be as performant as ARM (or even MIPS) is a lot further out.

MIPS ought to have a big advantage there, but they've squandered it. MIPSr6 is actually quite a nice ISA (I like it more than RISC V), but it is not backwards compatible with MIPS I-V or MIPSr1-5 (yes, those are different. Just go with it), so they lose all of their software ecosystem.

Sadly, both processors lost to the dust, in the end. Back around 2005, there were a lot of people who couldn't spell dual though, and 'duel processor' machines were going for about half what people were paying people who could spell for 'dual processor' machines on eBay. It was an object lesson in the financial value of learning to spell...

lowRISC is cool, but it's not that useful for universities. For research (and teaching), FPGAs are much more useful because of the short turn-around. It takes me about 1-2 hours to go from making changes to our processor to finishing the boot of an OS on the FPGA and doesn't require anyone else's input (unless there are bugs, then some help is often useful!). The cycle for getting a chip fabbed is a much longer process, usually requiring a small team and a lot of money.

If you want a MIPS implementation that you can run in an FPGA, then we've built one and released it under an Apache-style license (not exactly the Apache license, because the Apache license says 'the software' in a lot of places). It's an implementation of a version of the (64-bit) MIPS ISA that is over 20 years old, so any relevant patents have expired. We've been using this in teaching for a couple of years (one exercise is to replace the branch predictor, for example). It's written in a high-level HDL, so more amenable to research and teaching uses, because the code is easy to make invasive changes to.

It's not clear what version of the MIPS ISA they're implementing (the article I read just said MIPS32, which covers a whole range of things). It sounds like it's MIPS32r6, which is not backwards compatible with any previous MIPS version. The only value of MIPS over something like RISC V (which is increasingly the standard ISA for computer architecture research) is that there's a large body of existing software for it, so you can do real evaluation.

We've done a clean-room reimplementation of MIPS III (R4K compatible) implementation in BlueSpec, which is a high-level HDL. MIPS III and the R4K are over 20 years old, so any architecture-specific patents will have expired. In comparison, this core is only 32-bit (really not interesting for research) and is written in a low-level HDL (making the kind of invasive changes that you want to do in research difficult), and is an ISA that has very little software support.

There were probably some people with very expensive AGP cards that were needed for some custom display hardware. I used a PCI (not PCIe) graphics card for a while because it was the only thing that could drive a small LCD monitor that I'd bought cheaply.

We use the Terasic DE4 for most things, but it's insanely expensive - definitely only a board to use if someone else is paying. The SoCKit is quite nice - much cheaper and has a dual-core ARM board. We've ported FreeBSD to the ARM (adding devices for programming the FPGA) and our MIPS-compatible softcore to the FPGA, with virtio communicating between the two, which makes it easy to play with heterogeneous multicore. It's mainly intended for prototyping accelerator cores and there's a fast cache-coherent interconnect between the ARM cores and the FPGA so it's quite a nice platform to play with if you want to try and offload computation to the FPGA. It's a fairly small FPGA by modern standards, but still big enough for our CPU, which is a 6-stage in-order pipeline with caches, TLB, branch predictor and so on.