Discussion So what do you guys think of MIPS Open?

[whm1974]

Well the MIPS ISA has been opened up under a BSD style license:
https://www.mips.com/mipsopen/
Longer article:
https://www.electronicdesign.com/embedded-revolution/what-opening-mips-architecture-could-mean

Only MIPS version 6 has been made opened by Wave Technologies along with PowerVR. They basically doing this due to having lost major market share to ARM and that RISC-V has gain a large following and that many startups are using it.

One advantage the MIPS Open has over RISC-V is maturity as MIPS has been long established and proven to work and hardware is available. I will consider this as useful as both a stopgap and as a backup in case RISC-V falls flat. Of course this will also give end-users another option to choose the best solutions.

I do see both RISC-V and MIPS Open co-existing among FOSS users, but what are you thoughts on this?

 

[whm1974]

This is typical of the silly marketing that goes around RISC-V. Did you check who made the quotes cited in that "article"? 4 from Naveed Sherwani, CEO of SiFive, Martin Fink CTO of WD (early adopter who has a vested interest in seeing RISC-V not fail) and Rick O'Connor member of the RISC-V foundation. Would you really trust these people to have an unbiased view of RISC-V?

Well I don't since I'm trying to be as unbiased as possible and I will probably wait until affordable RISC-V based SBCs are available before making any judgement calls.

 

[DrMrLordX]

Well I don't since I'm trying to be as unbiased as possible and I will probably wait until affordable RISC-V based SBCs are available before making any judgement calls.

I was going to say that if anyone really wants to examine these new architectures in comparison to the rest of the market, the wise thing to do is to bench the hardware against other offerings and see how things shake out.

And while I am also very interested in POWER overall, I do not think most OpenPOWER CPUs operate in the same power envelope as RISC-V.

 

[whm1974]

I was going to say that if anyone really wants to examine these new architectures in comparison to the rest of the market, the wise thing to do is to bench the hardware against other offerings and see how things shake out.

And while I am also very interested in POWER overall, I do not think most OpenPOWER CPUs operate in the same power envelope as RISC-V.

Well there is also www.LowRISC.org that is also working on both an open source SoC and a SBC using it. However I don't expect their work to bear fruit anytime soon. Maybe in a few years perhaps?

 

[DrMrLordX]

Well there is also www.LowRISC.org that is also working on both an open source SoC and a SBC using it. However I don't expect their work to bear fruit anytime soon. Maybe in a few years perhaps?

Maybe. With RISC-V at least we can get some hardware sooner or later and maybe bench it against ARM to see how things go. OpenRISC will take awhile.

 

[Thala]

Whenever me or anyone else criticizes RV in concept or implementation, you just reply with "yeah, but the RV foundation says no."

Do you think the limited immediate range, lack of pre- or post-increment addressing modes, lack of embedded-oriented SIMD, and current selection of cores are good or bad? Why or why not? What makes RV better (or worse) than SPARC or MIPS, one of which is open and the other of which will be soon? How about vs ARM, which is not open but is the de facto standard in low-power 64-bit, and the dominant player in 32-bit as well?

Indeed there are big gaps in the ISA, just want to add count leading signs/zeros or popcount. But its not only the ISA, there is no comprehensive definition of the memory model, so its not clear where you have to add fences. And then there is even redundant stuff. For in stance any RV implementation has to implement both LL/SC instruction, swaps and atomics. ARM deprecated swaps for good reason. They should have went only with LL/SC and be done with it.

 

[Tuna-Fish]

Of course you're free to criticize RV. But the design goal of RV is to have a small and simple base ISA.
A 400MHz RV core could very well be faster, cheaper and have same power draw as a more complex ISA at 300Mhz at same process (figures just for explanation).

That's really unlikely, mostly because the density of the machine code is so bad. These days, memory access is a huge proportion of the total power use, especially at low power levels, and RISC-V has right about the worst density of any modern in-use ISA. It's really hard to catch up to other systems in power use when you need to dynamically fetch at least 30% more instructions to do the same basic tasks. I mean, the only memory addressing mode RISC-V has is reg+disp, you cannot even do simple register+register and there are no autoincrements either. For low power use, modern ARM shows how it's done, with clean load/store architecture but with useful complex addressing modes.

That being said, it's very easy to see why RISC-V went for the decisions they did. They optimized for making the CPUs easy to implement. This is a very good quality for research cpus, as it allows concentrating on the things you are actually researching, and minimizing the work of fighting the ISA. I believe we will see many interesting things tried out on RISC-V that would have been to hard or expensive to do before it, and while most of those will fail, there will be a couple of ideas that will turn out to be really good and then added to the better ISAs.

However, the enthusiasm about RISC-V replacing ARM or even x86 at any level is quite misguided, for the simple reason that performance is, and will remain really bad on all metrics, both on power use and raw speed. And that's okay, that's not what RISC-V was designed for, anyway.

MIPS R6 is also better than RISC-V in almost all respects. However, it is in an uncomfortable position between ARMv8, which costs money but can be licensed at reasonable cost and is better and more widely deployed, and RISC-V, which is simpler and easier to work with. Even though I personally prefer modern MIPS to RISC-V, I don't really see much of a future for it.

 

[teejee]

Indeed there are big gaps in the ISA, just want to add count leading signs/zeros or popcount. But its not only the ISA, there is no comprehensive definition of the memory model, so its not clear where you have to add fences. And then there is even redundant stuff. For in stance any RV implementation has to implement both LL/SC instruction, swaps and atomics. ARM deprecated swaps for good reason. They should have went only with LL/SC and be done with it.

The memory model is clearly specified in the latest draft that you can read here:
https://github.com/riscv/riscv-isa-manual/releases/tag/draft-20190213-8d5ad23

And popcount is part of the vector extension which almost certainly will be part of more perfomance oriented RISC-V CPUs.

The other issues you mention might very well be solved or dismissed for good reasons as well. I haven't had time to check.

 

[teejee]

That's really unlikely, mostly because the density of the machine code is so bad. These days, memory access is a huge proportion of the total power use, especially at low power levels, and RISC-V has right about the worst density of any modern in-use ISA. It's really hard to catch up to other systems in power use when you need to dynamically fetch at least 30% more instructions to do the same basic tasks. I mean, the only memory addressing mode RISC-V has is reg+disp, you cannot even do simple register+register and there are no autoincrements either. For low power use, modern ARM shows how it's done, with clean load/store architecture but with useful complex addressing modes.

That being said, it's very easy to see why RISC-V went for the decisions they did. They optimized for making the CPUs easy to implement. This is a very good quality for research cpus, as it allows concentrating on the things you are actually researching, and minimizing the work of fighting the ISA. I believe we will see many interesting things tried out on RISC-V that would have been to hard or expensive to do before it, and while most of those will fail, there will be a couple of ideas that will turn out to be really good and then added to the better ISAs.

However, the enthusiasm about RISC-V replacing ARM or even x86 at any level is quite misguided, for the simple reason that performance is, and will remain really bad on all metrics, both on power use and raw speed. And that's okay, that's not what RISC-V was designed for, anyway.

MIPS R6 is also better than RISC-V in almost all respects. However, it is in an uncomfortable position between ARMv8, which costs money but can be licensed at reasonable cost and is better and more widely deployed, and RISC-V, which is simpler and easier to work with. Even though I personally prefer modern MIPS to RISC-V, I don't really see much of a future for it.

There is a compressed variant of the RV encoding specified, and it has very competitive both static and dynamic code size. It is already used in for example some SiFive cores, so nothing exotic for the future.

 

[SarahKerrigan]

The memory model is clearly specified in the latest draft that you can read here:
https://github.com/riscv/riscv-isa-manual/releases/tag/draft-20190213-8d5ad23

And popcount is part of the vector extension which almost certainly will be part of more perfomance oriented RISC-V CPUs.

The other issues you mention might very well be solved or dismissed for good reasons as well. I haven't had time to check.

As far as I know, popcnt in the vector extension will only be for vector predicate registers, not GPRs. Do you know of anything to prove that wrong? The "XBitmanip" non-standard extension proposal has popcnt, along with some useful stuff like rotates - do you really think a base ISA with no rotates is a good idea? Think about crypto...

This, and the things I mentioned above, strike me as stuff that is really essential for a good ISA, and in their absence, incompatible implementations of the missing features seem likely to emerge.

 

[teejee]

As far as I know, popcnt in the vector extension will only be for vector predicate registers, not GPRs. Do you know of anything to prove that wrong? The "XBitmanip" non-standard extension proposal has popcnt, along with some useful stuff like rotates - do you really think a base ISA with no rotates is a good idea? Think about crypto...

This, and the things I mentioned above, strike me as stuff that is really essential for a good ISA, and in their absence, incompatible implementations of the missing features seem likely to emerge.

The base ISA is intended for simple cores, special instructions for crypto does not belong there. But it should of course be part of an official Risc-V extension, and this work is ongoing but I don't know the status.

It seems like many of you judge current status of RISC-V compared to high-end desktop/server/smartphone ISA's and get dissapointed since RV is not there yet.
RV will take of in other areas (happens today). But maybe in some years we'll see high-end RV CPU's.

 

[SarahKerrigan]

The base ISA is intended for simple cores, special instructions for crypto does not belong there. But it should of course be part of an official Risc-V extension, and this work is ongoing but I don't know the status.

It seems like many of you judge current status of RISC-V compared to high-end desktop/server/smartphone ISA's and get dissapointed since RV is not there yet.
RV will take of in other areas (happens today). But maybe in some years we'll see high-end RV CPU's.

Integer rotation is not a "special instruction for crypto." It is an extremely common and basic instruction that happens to be necessary for many ciphers to not run like crap, in addition to being very important for other code streams too.

RISC-V, by leaving out important and common stuff like that, gives vendors an incentive to build their own implementations. That is the road to fragmentation.

 

[teejee]

Integer rotation is not a "special instruction for crypto." It is an extremely common and basic instruction that happens to be necessary for many ciphers to not run like crap, in addition to being very important for other code streams too.

RISC-V, by leaving out important and common stuff like that, gives vendors an incentive to build their own implementations. That is the road to fragmentation.

I agree that a solid standard bit manipulation extension should have been available by now. The 'B'-extension is reserved for this.

It is actually partially AMD's fault that this has been delayed. An AMD emplyoyer was heading the bit manipulation working group for a while but AMD never signed for the membership so they got a major issue related to patents/ownership etc and more or less dissolved the working group. But work is still ongoing though.