For example LibreOffice was forked from OpenOffice because to much potential contributors was frustrated by the way the OpenOffice maintainers was with them in the past.
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...
Does RISC-V follow the MIPS instruction set AT ALL?
It's an entirely new ISA that is intended to be freely licensable.
The site says variable 32/64/128 bit address space - does that mean the ALU and registers are statically or dynamically configurable to have variable lengths?
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).
The university professors do have an interest to teach their students with an industrial core, not some subset or a core created in academia and not tried in industry much.
Really? Usually we want to use something for teaching that's easy to understand and modify...
The main idea is: the students can play with the core, create multicore systems, modify caches, etc.
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.
Somehow you have the impression that MIPSfpga is Release 6 - it is not.
Thanks for clarifying. There was nothing in the web page to indicate this (a fairly common omission on ImagTec blog postings, by the way).
Although you are correct that the ISA has been updated in Release 6, the instructions that have been removed are really old and not used by existing software
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.
Even so, we still have trap and emulate mechanisms that ensure we do not break compatibility.
No you don't. You reused the opcodes, unless there's a newer version of the spec than the one I've seen.
Yay for you. You were so smart reading, writing, and doing long division at kindergarten age. If only everyone else was so brilliant.
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.
Its not natural or obvious how to use the three seashells. School is there to teach that.
That's rather my point. My school managed to teach all of us those things, what's wrong with schools in the USA?
The hotel with only wired in the room.
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
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.
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.
Any suggestions on that FPGA board?
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.
"I am, therefore I am." -- Akira