Linux Now Has its First Open Source RISC-V Processor (designnews.com)

"SiFive has declared that 2018 will be the year of RISC V Linux processors," writes Design News. An anonymous reader quotes their report: When it released its first open-source system on a chip, the Freeform Everywhere 310, last year, Silicon Valley startup SiFive was aiming to push the RISC-V architecture to transform the hardware industry in the way that Linux transformed the software industry. Now the company has delivered further on that promise with the release of the U54-MC Coreplex, the first RISC-V-based chip that supports Linux, Unix, and FreeBSD... This latest development has RISC-V enthusiasts particularly excited because now it opens up a whole new world of use cases for the architecture and paves the way for RISC-V processors to compete with ARM cores and similar offerings in the enterprise and consumer space...

"The U54 Coreplexes are great for companies looking to build SoC's around RISC-V," Andrew Waterman co-founder and chief engineer at SiFive, as well as the one of the co-creators of RISC-V, told Design News. "The forthcoming silicon is going to enable much better software development for RISC-V." Waterman said that, while SiFive had developed low-level software such as compilers for RISC-V the company really hopes that the open-source community will be taking a much broader role going forward and really pushing the technology forward. "No matter how big of a role we would want to have we can't make a dent," Waterman said. "But what we can do is make sure the army of engineers out there are empowered."

Comments

For those of us that don't know

[Anonymous Coward]

What's the big advantage with RISC over ARM or x86? I'm especially curious as to the advantages with embedded devices since that's what this seams to be geared towards.

Re:For those of us that don't know

[TheRealMindChild]

What's the big advantage with RISC over ARM or x86

Licensing costs

Re:For those of us that don't know

[Anonymous Coward]

ARM is a RISC chip.

Re:For those of us that don't know

[I75BJC]

Reduced Instruction Set Computer = a set of attributes that allows it to have a lower cycles per instruction (CPI) than a complex instruction set computer (CISC) (Wikipedia) Intel's Core chips are CISC. RISC chips can do more work at the same speed than CISC chips. So, RISC chips are cheaper to run. All the older UNIX boxes used RISC chips and were powerhouses.

Re:For those of us that don't know

[iggymanz]

actually there really aren't CISC chips any more, the current x86_64 for example really only emulates that instruction set with RISC and microcode

Re: For those of us that don't know

[maugle]

Bingo. All the companies involved in making SoCs will be looking to cut out the ARM licensing fee. ARM typically takes $1-10 million up front plus 1-2% per chip, so you can see how their customers would be eager to keep that for themselves.

Re:For those of us that don't know

[ShanghaiBill]

What's the big advantage with RISC over ARM or x86?

ARM is a RISC chip. Originally, ARM stood for Acorn RISC Machine.

The news here is not that it is RISC, but that it is open source.

So as long as you have your own fab, or a few million $ to rent one, you can make your own chips ... but the real advantage is that you can look at the design files and see for yourself that there are no backdoors.

Re:For those of us that don't know

[Anonymous Coward]

Less instruction sets makes assemblers and compilers easier to implement, also is easier to anyone check if there is a bug or abusable feature (There are people and businesses that do not require or want ARM TrustZone, AMD PSP or Intel ATM).
Licensing also matters a lot, is easier to develop further without fear of litigation and research groups can find and publish better reviews and recommendations without fear of being sued.

Re:For those of us that don't know

[Anonymous Coward]

ARM is a RISC chip.

So is Intel, on the inside. :-)

Re:For those of us that don't know

[Anonymous Coward]

Key is not just that instruction set is reduced (not just fewer, also simpler operations so multiple instructions may be needed to do the same job as some x86/x64 complex instructions) its that all the instructions are the same size and thus the next instruction starts in a predictable location. Makes for much reduced transistor count and thus lower power usage. ARM is a special case designed for low power use, but in general RISC can have a much faster and more efficient instruction pipeline given the transistor count. And if low power consumption isn't a must (which it is for most RISC which are phones and tablets these days) and you can throw tons of transistors at it, a RISC makes it much easier to do things like speculative execution which is to execute both possible outcomes of a conditional branch, and throw the unnecessary results away. (The more times you can follow both branch possibilities increases arithmetic units exponentially, so easy to throw transistors at the problem, and Intel being able to keep shrinking and lowering voltage is what kept them ahead) Not the only trick in the book, out of order execution is great too, but harder to explain.

Non-low-power risc is a real speciality these days but a desktop powered risc with the transistor count of a core duo or something like that would really blow your socks off.

Re:For those of us that don't know

[Anonymous Coward]

RISC + microcode = CISC. Maybe not in terms of instruction set design; but certainly this is how old CISC-era CPUs worked. What really happens is more of a data flow processor. x86 instructions get rewritten on the fly. Sometimes there is fallback to microcode. It's more like a JVM JIT but at the hardware/CPU level.

Re: For those of us that don't know

[Anonymous Coward]

No, all the older unix boxes were PDP-11s. A bunch of the less older unix boxes were 68000. I have an older uxix box that has an 8086 processor.

Re:For those of us that don't know

[thinkwaitfast]

Someone needs to publish instructions now on how to DIY fab and we're all set. I did this a billion years ago in college, but with much simpler devices.

Re: For those of us that don't know

[Anonymous Coward]

Then we will be able to make 'do it yourself' chips in our basements of about the complexity as a 80286.

Really, it's not a homebrew thing, unless, maybe, you're E Musk.

Re:For those of us that don't know

[slashrio]

Let me guess, a diode?

Re:For those of us that don't know

[K. S. Kyosuke]

Also, cleaner design, presumably. Good for compiler writers, perhaps?

Re:For those of us that don't know

[thinkwaitfast]

Almost. Add transistor for dtl.

Re:For those of us that don't know

[fisted]

But you can't verify that the design you're looking at is what the plant actually implemented on the chip.

Re:For those of us that don't know

[Anonymous Coward]

Very much of a smaller problem than something hidden in the design.

Re: For those of us that don't know

[tlhIngan]

Bingo. All the companies involved in making SoCs will be looking to cut out the ARM licensing fee. ARM typically takes $1-10 million up front plus 1-2% per chip, so you can see how their customers would be eager to keep that for themselves.

So what kind of performance are we talking about? Are they equivalent to the latest and greatest (and thus most expensive licensing) ARMs? Or are we only running them at 25MHz on an FPGA? (And what kind of FPGA? Since there's a range from $10 FPGAs to $100,000 FPGAs).

Also important is cost - do you know why most TVs are smart? It's because the SoCs now are so fast that after the basic TV management software is put in, you're barely using 1% of it. The SoC is so cheap, you can choose between a 100MHz ARM TV SoC, or one that uses a mass produced smartphone chip code and get a quad core 1.5GHz SoC for less money.

Hell, even in the microcontroller space things can be screwy with the proliferation of microcontroller ARM chips. Nothing like coding up something with real 32-bit integers and stuff.

So other than niche open-source hardware laptops... is there a market?

Re:For those of us that don't know

[TheRaven64]

Less instruction sets makes assemblers and compilers easier to implement

I'll give you assemblers (though assemblers are so trivial that there's little benefit from this), but not compilers. A big motivation for the original RISC revolution was that compilers were only using a tiny fraction of the microcoded instructions added to CISC chips and you could make the hardware a lot faster by throwing away all of the decoder logic required to support them. Compilers can always restrict themselves to a Turing-complete subset of any ISA.

RISC-V is very simple, but that's not always a good thing. For example, most modern architectures have a way of checking the carry flag for integer addition, which is important for things like constant-time crypto (or anything that uses big integer arithmetic) and also for automatic boxing for dynamic languages. RISC-V doesn't, which makes these operations a lot harder to implement. On x86 or ARM, you have direct access to the carry bit as a condition code.

Similarly, RISC-V lacks a conditional move / select instruction. Krste and I have had some very long arguments about this. Two years ago, I had a student add a conditional move to RISC-V and demonstrate that, for an in-order pipeline, you get around a 20% speedup from an area overhead of under 1%. You can get the same speedup by (roughly) quadrupling the amount of branch predictor state. Krste's objection to conditional move comes from the Alpha, where the conditional move was the only instruction requiring three read ports on the register file. On in-order systems, this is very cheap. On superscalar out-of-order implementations, you effectively get it for free from your register rename engine (executing a conditional move is a register rename operation). On in-order superscalar designs without register renaming, it's a bit painful, but that's a weird space (no ARM chips are in this window anymore, for example). Krste's counter argument is that you can do micro-op fusion on the high-end parts to spot the conditional-branch-move sequence, but that complicates decoder logic (ARM avoids micro-op fusion because of the power cost).

Most of the other instructions in modern ISAs are there for a reason. For example, ARMv7 and ARMv8 have a rich set of bitfield insert and extract instructions. These are rarely used, but they are used in a few critical paths that have a big impact on overall performance. The scaled addressing modes on RISC-V initially look like a good way of saving opcode space, but unfortunately they preclude a common optimisation in dynamic languages, where you use the low bit to differentiate pointers from integers. If you set the low bit in valid pointers, then you can fold the -1 into your conventional loads. For example, if you want to load the field at offset 8 in an object, you do a load with an immediate offset 7. In RISC-V, a 32-bit load must have an immediate that's a multiple of 4, so this is not possible and you end up requiring an extra arithmetic instruction (and, often, an extra register) for each object / method pair.

At a higher level, the lack of instruction cache coherency between cores makes JITs very inefficient on multicore RISC-V. Every time you generate code, you must do a system call, the OS must send an IPI to every core, and then run the i-cache invalidate instruction. All other modern instruction sets require this to be piggybacked on the normal cache coherency logic (where it's a few orders of magnitude cheaper). SPARC was the last holdout, but Java running far faster on x86 than SPARC put pressure on them to change.

Licensing also matters a lot

This is true, but not in the way that you think. Companies don't pay an ARM license because they like giving ARM money, they pay an ARM license because it buys them entry into the ARM ecosystem. Apple spends a lot of money developing ARM compilers, but they spend a lot less money developing ARM compilers than the rest of the ARM

Re: For those of us that don't know

[james_gnz]

other than niche open-source hardware laptops... is there a market?

I'd guess it'll probably become ubiquitous in devices that are either very small or very large, but won't make much of a dent in the PC market (where x86 is already entrenched) or the tablet/phone market (where ARM is already entrenched). Kind of like how we've got the Linux kernel on supercomputers and servers, tablets, phones, watches, routers, etc., but not so much on PCs, where MS Windows was already entrenched.

I think I remember a video from one of the people involved in RISC-V saying that it was originally just intended for use in courses about CPU design. They kept revising it whenever a PhD student figured out a better way of doing something. Then they started getting calls from people in India asking "Why do you keep changing the spec?" It was being used as an embedded processor in special purpose chips. Nvidia is planning to use it as an embedded processor in their GPUs, apparently (replacing their in-house processor "Falcon"). So RISC-V's already making inroads here.

Google's apparently interested in it for their servers too. At that scale, the savings from higher efficiency could offset research and development costs. I think RISC-V will probably take over server farms and supercomputers eventually.

For PCs, I think you're right, it'll probably be a niche market.

Re: For those of us that don't know

[Anonymous Coward]

I already make systems on chips more complex than a 286 and faster as well.

Just get an FPGA dev kit for 50 bucks, put a RISC V core on there, together with your own custom logic, and away you go.

Next step is to find 100 grand and get it made into a real chip....

But that only makes sense if you want to build a lot of whatever it is.

Re:For those of us that don't know

[Anonymous Coward]

Really?

Looking at the 3000 page ARM instruction set manual I would say it has evolved into a hideous CISC.

Re:For those of us that don't know

[Anonymous Coward]

It's "RISC-V".

This new RISC-V core is an ARM Cortex A35 competitor, according to the product page. In the 28nm chip they'd produced, it's not going to outperform a Raspberry Pi, and I don't know what the graphics options are or if there's PCIe. Obviously licensees have free reign to add their own features.

It's benefit is a fully open ISA, and licensing costs (as an underdog product).

The ISA will likely be quite popular in the future, although whether it will ever be comparable in volume to ARM in the consumer space is a different matter entirely. However in markets where the ISA isn't important (embedded), it has already started gaining some traction.

Re: For those of us that don't know

[Anonymous Coward]

AN FPGA IS NOT AN OPEN SOURCE CHIP.

People keep making this assumption. We are talking here about real hardware design.

Furthermore, you are NOT going to set up a foundry of your own to make a competetive FPGA that is open source hardware.

Re:For those of us that don't know

[Anonymous Coward]

Well, that and you can pour it onto an FPGA as a control processor for your fabric and then be able to pour it onto an ASIC and expect the design to stay mostly the same. So, you can make designs that shrink parts count and still be very capable. Prior to the 32 and 64-bit RISC-V designs coming out from SiFive, the SpinalHDL project, and others, you'd have had to use the FPGA company's soft core, licensed from Cobham Giesler one of their LEON cores, licensed from the likes of Cortus, etc.- and if you ended up needing to go ASIC, you'd have to go do it again or license an ARM implementation or buy an external chip making you do redesign.

Most of the people commenting on this announcement are utterly clueless (Not you, you were barking up the right tree there...) that this IS pretty damn big as a deal and all.

- No or LOW licensing costs (depending on what you're doing with SiFive's stuff...)
- FPGA and ASIC friendly to the point of being almost a drop on for either with little to no changes needed for a switch to the other.
- Lower power consumption and cell/gate count utilization as good or better than the vendors' soft cores
- Consistent CPU instruction set across all the bit widths and implementations of the cores.

What's not to like? Oh, that's right...this is /. Most of the posters on here are the electronic equivalent of poo flingers.

Re:For those of us that don't know

[Anonymous Coward]

Think FPGA or ASIC. By the by, you're one of the clueless fucks I mentioned in my earlier post above... We won't get into gate logic- most of the CPU core designs you can mention that can be implemented as FPGA, ASIC, or raw custom silicon on a chip are closed source, welded shut designs. You can't really verify them or you're paying millions upon millions for a single implementation. No way to verify any of it in the first place.

If you've no clue about what in the fuck you're talking about, shut the fuck up, k?

Re:For those of us that don't know

[fisted]

Could you rephrase that in a way that doesn't suggest you just had an OCD attack? Preferrably not before cooling down for a few hours. I have honestly no idea what you were even trying to say. You can't verify the design, but that's not a problem because you can't verify other designs either? Maybe?

Re: For those of us that don't know

[AmiMoJo]

Those costs are microscopic compared to the loss of sales from producing a CPU that doesn't run the operating systems and applications people actually want. Maybe once they get this thing running Android it might start to make sense, but I doubt it is competitive in terms of performance per watt.

Re:For those of us that don't know

[AmiMoJo]

Than Raven, this is the best post I've read in a very long time. Wish I had mod-points.

Re: For those of us that don't know

[Qbertino]

RISC is generally considered "The better Architecture" (TM). Of course that statement is super-broad but truth be told, ARM was initially designed with lots of modern day improvements in mind whilst x86 was made with a more "make it work and get it to mass market ASAP" approach. Hence the success of x86 despite ARM microcomputers being roughly 2 decades ahead back in the late 80ies/early 90ies.
ARM actually is the newer architecture but the Acorn Archimedes was proprietary and closed, just like the Amiga back in the day, that's why they lost out against PC/x86.

Point in case: Modern ARM performance per Watt is through the friggin roof vis-a-vis current x86 for relatively standard operations. That's why cheapo ARM netbooks with laughable batteries still get 6 hours of runtime per charge. Also is ARM in some ways way simpler in architecture (*reduced* instruction set command - RISC) and thus easier to produce and optimize.

I expect ARM to take over userspace computing once the entire stack is covered by open hardware. Smartphones and tablets already are on this path, when FOSH (Free Open Source Hardware) hits the road, this trend will accelerate, IMHO.

My 2 eurocents.

Re: For those of us that don't know

[Anonymous Coward]

"The os people want." Get real, this thing is NOT for running windows. But you can have a cheapet unix server, or a cheaper processor for embedded devices. Those markets are big enough - it isn't all about laptops.

Re: For those of us that don't know

[Anonymous Coward]

On the other hand, if you target ARM, you already have a nice ready-to-go software environment and a shitload of programmers that understand it. If you go with some snowflake architecture, you're choices are much more narrow, and any developers that you bring on will have to learn about a different platform again.

Just ask Apple how snowflake architectures work out in the end. Or Sun. Or Digital.

Re:For those of us that don't know

[coofercat]

Way back in the mists of time I worked for a chip fab company. They bought some competitor chips, whipped the tops off them and examined them under a microscope.

Granted, you're unlikely to see a one-transistor change or something, but it's incredibly unlikely any change that actually does more than introduce some bugs is going to be that small. It's a tedious process though, and the chip you examine is waste afterwards, so you can only check a small subset, and even then you don't know if the one you chose at random was a 'good' one or that the one you put into your laptop was a p0wned one.

Another alternative that's less destructive is to have the fab make the wafers and ship them to you (perhaps after chopping them up into die). You then package them yourself after visual checks on each one. The security responsibility is yours, and checking every single die is going to add a lot of expense, but it would be possible to ensure security this way. How you convince anyone else that you've done all of this correctly and that they should now pay top-prices for 'secure' chips is another problem you'd have to solve though.

Re:For those of us that don't know

[fisted]

Way back in the mists of time

I guess that's the thing.

AFAIK these days dies have too small of a feature size for meaningful optical inspection (feature size way smaller than the wavelength of light), and dozens of layers from which, even if you could, you'd only see the topmost one, and simply way too many features to begin with.

Re: For those of us that don't know

[Anonymous Coward]

That's why cheapo ARM netbooks with laughable batteries still get 6 hours of runtime per charge.

and it takes 2 hours to boot and crashes the first non mobile website you hit, realistically the performance per watt is still pretty good but its not a massive gap, to get an arm running as good as even the low end x68 cpu's takes about the same amount of power

Re:For those of us that don't know

[Eravnrekaree]

There are no technical advantages. RISC is basically dead as a serious idea, most chips today are CISC with complex parallel instruction sets for math. So called RISC instruction sets such as ARM are quite complex, as complex as x86 is, certainly far more complex than an 8086.

It has been mentioned that there is no significant overhead in implementing x86 over other CPU ISAs. Its an old myth that doesn't hold water.

Licensing is cited as a reason for another ISA. I think that this if I am not mistaken applies only to schematics of the chip, rather than to the Instruction Set Architecture,. People have made independant implementations of x86 ISA, it can be done, you dont need Intels schematics to do it, you can make your own electronics. Since RISC-V seems to be using their own schematic anyway, they could have made it support x86-64, why reinvent another incompatible instruction set? Then it could use off the shelf and well supported x86 binaries.

So, I dont see any logic in them inventing an incompatable ISA rather than just using x86.

Re:For those of us that don't know

[Eravnrekaree]

Licensing? If your making your own electronic schematics, you dont need to license anything. As far as instruction set architecture itself, the ISA is basically a language, and it has been independantly implemented without licensing, such as BOCHS, since language are not copyrightable. Since RISC-V is not using Intel schematics, it could have easily supported x86-64 without any licensing fees, with its own electronics implementation.

Re:For those of us that don't know

[Eravnrekaree]

This isnt true. With implementing a compiler, you want to have AVX, SSE instructions etc so that you can more easily optimize your code. A simple instruction set would mean less ways to optimize the code. The compiler can choose which instructions to use it.

Writing a compiler for a Turing Tarpit is more difficult, the smaller the instruction set, the more code that the compiler has to write to emulate things not implemented on the CPU.

Re:For those of us that don't know

[Megol]

Less instruction sets makes assemblers and compilers easier to implement

I'll give you assemblers (though assemblers are so trivial that there's little benefit from this), but not compilers. A big motivation for the original RISC revolution was that compilers were only using a tiny fraction of the microcoded instructions added to CISC chips and you could make the hardware a lot faster by throwing away all of the decoder logic required to support them. Compilers can always restrict themselves to a Turing-complete subset of any ISA.

RISC-V is very simple, but that's not always a good thing. For example, most modern architectures have a way of checking the carry flag for integer addition, which is important for things like constant-time crypto (or anything that uses big integer arithmetic) and also for automatic boxing for dynamic languages. RISC-V doesn't, which makes these operations a lot harder to implement. On x86 or ARM, you have direct access to the carry bit as a condition code.

Similarly, RISC-V lacks a conditional move / select instruction. Krste and I have had some very long arguments about this. Two years ago, I had a student add a conditional move to RISC-V and demonstrate that, for an in-order pipeline, you get around a 20% speedup from an area overhead of under 1%. You can get the same speedup by (roughly) quadrupling the amount of branch predictor state. Krste's objection to conditional move comes from the Alpha, where the conditional move was the only instruction requiring three read ports on the register file. On in-order systems, this is very cheap. On superscalar out-of-order implementations, you effectively get it for free from your register rename engine (executing a conditional move is a register rename operation). On in-order superscalar designs without register renaming, it's a bit painful, but that's a weird space (no ARM chips are in this window anymore, for example). Krste's counter argument is that you can do micro-op fusion on the high-end parts to spot the conditional-branch-move sequence, but that complicates decoder logic (ARM avoids micro-op fusion because of the power cost).

Exactly how do you expect conditional moves to be executed at the renaming stage? They are conditional which means either one have to have the condition ready at the rename stage (extremely unlikely) or one have to speculate. To speculate one have to have a predictor, a way to rollback the operation (and dependents) and tracking logic. This isn't free. One would also need to verify the prediction so some kind of operation have to be executed*.

Just using branches instead would at worst add a few cycles of mispredict latency - from the fetch + decode stages. That would also remove the complications given that branches have to be supported anyway.

(* unless one can piggy-back on another operation)

Most of the other instructions in modern ISAs are there for a reason. For example, ARMv7 and ARMv8 have a rich set of bitfield insert and extract instructions. These are rarely used, but they are used in a few critical paths that have a big impact on overall performance. The scaled addressing modes on RISC-V initially look like a good way of saving opcode space, but unfortunately they preclude a common optimisation in dynamic languages, where you use the low bit to differentiate pointers from integers. If you set the low bit in valid pointers, then you can fold the -1 into your conventional loads. For example, if you want to load the field at offset 8 in an object, you do a load with an immediate offset 7. In RISC-V, a 32-bit load must have an immediate that's a multiple of 4, so this is not possible and you end up requiring an extra arithmetic instruction (and, often, an extra register) for each object / method pair.

This is a disadvantage if one expect that all processors are the same and expect the code optimized for one ISA (and likely microarchitecture) should run

Re: For those of us that don't know

[Anonymous Coward]

Me too :(

Re:For those of us that don't know

[Megol]

Not really. The Pentium Pro could perhaps be called internally RISC as it executed simple 2 in - 1 out operations (though they were more complicated than normal RISC instructions). This is easiest visible in relatively simple instructions that have more than one input like ADC.

Modern x86 execute complicated operations that are designed for x86 execution efficiency. Simplified compared to the (worst case) x86 instructions? Absolutely - but far from any RISC design.

Re:For those of us that don't know

[Anonymous Coward]

> Granted, you're unlikely to see a one-transistor change

And that's about all they need to screw you over. This was here a year or two ago, all it takes is 20 transistors and one capacitor, and knowledge of where on the die you've placed your (privilege) flag register, and you're screwed.

Re:For those of us that don't know

[Megol]

X86 is CISC. Even if x86 chips were internally RISC with a translation layer they would still be CISC as the ISA is CISC. Implementation doesn't matter.

But x86 chips aren't RISC processors just CISC processors using a simplified internal representation, a representation that is designed to execute effectively and be a good fit to x86 instructions. They are still far more complicated than RISC instructions.

Re:For those of us that don't know

[TheRaven64]

Exactly how do you expect conditional moves to be executed at the renaming stage?

The conventional way is to enqueue the operation just as you do any other operation that has not-yet-ready dependencies. When the condition is known, the rename logic collapses the two candidate rename registers into a single one and forwards this to the pipeline. Variations of this technique are used in most mainstream superscalar cores. The rename engine is already one of the most complex bits of logic in your CPU, supporting conditional moves adds very little extra complexity and gives a huge boost to code density.

This is a disadvantage if one expect that all processors are the same and expect the code optimized for one ISA (and likely microarchitecture) should run well on other ISAs. Really bad.

If you come along with a new ISA and say 'oh, so you've spent the last 30 years working out how to optimise this category of languages? That's nice, but those techniques won't work with our ISA' then you'd better have a compelling alternative.

That isn't the only way to solve that problem, in fact that sounds like a very bad design.

It is on RISC-V. For the J extension, we'll probably mandate coherent i-caches, because that's the only sane way of solving this problem. Lazy updates or indirection don't help this, unless you want to add a conditional i-cache flush on every branch, and even that would break on-stack replacement (deoptimisation), where is not always a branch in the old code, but there is in the new code, and it is essential for correctness that you run the new code and not the old.

MIPS was killed?

Yes. It's still hanging on a bit at the low end, mostly in routers, where some vendors have ancient licenses and don't care that power and performance both suck in comparison to newer cores. It's dead at the high end - Cavium was the last vendor doing decent new designs and they've moved entirely to ARMv8. ImagTec tried to get people interested in MIPSr6, but the only thing that MIPS had going for it was the ability to run legacy MIPS code, and MIPSr6 wasn't backwards compatible.

Custom instruction support is a requirement for a subset of the market and it doesn't cause any problem

Really? ARM seems to be doing very well without it. And ARM partners seem to do very well being able to put their own specialised cores in SoCs, but have a common ARM ISA driving them. ARM was just bought by Softbank for $32bn, meanwhile, all of the surviving bits of MIPS were just sold off by a dying ImagTec for $65m. Which strategy do you think worked better?

Can't run the code from a microcontroller interfacing a custom LIDAR on the desktop computer? Who the fuck cares? Really?

How much does it cost you to validate the toolchain for that custom LIDAR? If it's the same toolchain that every other vendor's chip uses, not much. If it's a custom one that handles your special magic instructions, that cost goes up. And now your vendor can't upstream the changes to the compiler, because they break other implementations (as happened with almost all of the MIPS vendor GCC forks), so how much is it going to cost you if you have to back-port the library that you want to use in your LIDAR system from C++20 or C21 to the dialect supported by your vendor's compiler? All of these are the reasons that people abandoned MIPS.

Re:For those of us that don't know

[AmiMoJo]

You can. De-cap the chip, use a microscope to photograph it and computer vision software to compare it to your design files.

People have done it for older chips, e.g. decoding ROMs visually or just trying to figure out how something works. With a modern process you will need more expensive equipment due to everything being smaller, but it's far from impossible to do.

Re:For those of us that don't know

[angel'o'sphere]

So, I dont see any logic in them inventing an incompatable ISA rather than just using x86.
That does not wonder me, as every claim you make in your post is wrong.

RISC is basically dead as a serious idea,
Wrong.
most chips today are CISC
Wrong. Wrong by chip type, and wrong by sold units.

Re:For those of us that don't know

[fisted]

far from impossible

Are you sure about that? I agree that it is theoretically possible, but in practical terms, I believe it is.

People have done it for older chips

Yep, and older chips in comparison are huge and have something like 2-3 interconnect layers. Modern chips have a tiny feature size, and on top of the silicon, a stack of >10 interconnect layers, your microscope will have a hard time looking through those (that is, provided these things could be optically inspected in the first place -- the wavelength of light currently is two orders of magnitude bigger than the feature size).

I for one are not aware of a process that can remove exactly a nm-thick layer of interconnects (in order to expose the next one in the stack) without damaging that next layer. If you are, please enlighten me.

Re:For those of us that don't know

[AaronW]

I agree with much of what you said. I work at a company that designs its own CPUs from the ground up. We migrated in the last few years from multi-core 64-bit MIPS to ARMv8.x. We actually added a number of instructions to the MIPS standard including insert, extract and a host of atomic instructions and I can tell you that insert/extract are used quite extensively in the compiler once the proper tuning was added. Most of my work has been with the MIPS processors and I can tell you that, especially in embedded cases or when dealing with hardware, insert/extract are used extensively. Anywhere you see code mucking about with masks and combining bits or setting flags, etc, insert/extract are quite useful.

For example, something like x = (y >> 9) & 0x3f is replaced by a single instruction, something like ext t8, t9, 9, 6 (assuming x and y are integers). Insert is similarly useful.

There are some big improvements with ARM64 such as load/store pair and an even greater wealth of atomic instructions and additional conditional instructions. It is very common to load a sequence of memory addresses into registers.

Re:For those of us that don't know

[AaronW]

I can tell you that the vendor I work for did add custom instructions to MIPS. Some were not difficult to deal with because MIPS reserved coprocessor 2 for just this reason, others are more complicated. We also have a very sizeable compiler and toolchain team which also has upstreamed most of the changes. With MIPS we were able to do some interesting extensions such as adding a lot more encryption and hashing algorithms, though in many cases these would not be used in most environments. We also added transactional memory, something Intel later added (which was broken in their first implementation) but ARM has been dragging their feet.

Re: For those of us that don't know

[IAN]

Those costs are microscopic compared to the loss of sales from producing a CPU that doesn't run the operating systems and applications people actually want.

The first wave of RISC-V users had no intention to have it as a user-facing component. These days it's common for a SoC or a GPU to have its own orchestration/housekeeping CPU, and manufacturers would prefer to avoid ARM licensing cost for that. Nvidia is probably the highest-profile early user; a talk by one of their engineers goes into quite some detail.

Re:For those of us that don't know

[Anonymous Coward]

supporting conditional moves adds very little extra complexity and gives a huge boost to code density

Do you have any benchmarks or peer-review studies supporting this assertion, or should we just take your word for it?

Which strategy do you think worked better?

Do you have any actual evidence that ARM's success compared to MIPS has to do with ARM more control over custom instructions? Or do we have to take your word for it again?

I mean, you do a really good job spewing out intelligent sounding technobabble, and it's slightly more entertaining to read than the usual conspiracy theory nutcase comments (probably posted by Russian professional trolls who infest dying forums) which dominate Slashdot these days, but I don't see any references or actual studies backing up your assertions.

My experience is that you're a pedantic twerp, and based on your Slashdot posting history, a pretty unpleasant person. No surprise you still post here when the nutcases and jerks have driven out most other posters.

Re:For those of us that don't know

[slashrio]

Done that, been there, don't remember any more. :)

Re:For those of us that don't know

[Anonymous Coward]

The feature size size today is in the lower range of the visible wave length spectrum, but it is larger than X-ray wave lengths (after all, to produce the small feature sizes we need something that can expose the etching masks).

Here's an example of what can be done:
https://www.bunniestudios.com/blog/?p=4937

Re:For those of us that don't know

[fisted]

The feature size size today is in the lower range of the visible wave length spectrum

According to wikipedia, the visible spectrum ends at around 390nm.
Intel is currently doing 10nm and planning to go down to 7nm next year.

Here's an example of what can be done: https://www.bunniestudios.com/...

Now that's pretty impressive. However, it says the best possible current resolution is 14.6nm, so it can't currently resolve state of the art dies.
Also those pretty pictures? Their scale is in micrometers, as shown on them.

Re:For those of us that don't know

[Megol]

The common design for a high-performance OoO core today is something like this:
(Warning! Very simplified!)

Fetch - Decode - Rename - Schedule - Execute - Retire

With a common register file for architectural and speculative data.

The Fetch stage require the predicted next instruction (chunk) address and produces raw instruction data for the decoders.
Decoders chops up instructions, identifies and extracts fields including register specifiers.
The Rename stage allocates registers from the register file for all register writes and updates an internal remapping table so that later register reads will read from the relevant register file entry, in parallel all register reads in decoded instructions are looked up in the remapping table.

For reads:
physical_register=remap[instruction_reg_field]

For writes:
physical_register=allocate_physical_register()
remap[instruction_reg_field]=physical_register

Later stages only use physical registers and not the instruction set defined ones.

Not having enough free registers would stall the pipeline, this is a bad thing. Solution: have enough physical registers that it's impossible or very unlikely to run out of physical registers.

Let's assume the conditional move is defined as:

CMOVE R_dest, R_src, R_cond

if (R_cond) R_dest = R_src;

Here my main objection should be clear: the renamer doesn't care about actual data, just register identifiers. To the renamer R_cond is just an architectural register identifier, not the data it contains or will contain in the future.

That is good as data is produced by the execution units several clocks below the rename logic in best case. In worst case the operation producing the condition to be checked can be stalled 100+ clocks waiting for external data.

Not only would allowing the renamer to snoop result data complicate the already expensive renaming logic, it would complicate bypass logic between execution units and would _still_ often stall when a CMOVE reaches the rename stage. Very expensive stalls.

1) The renamer doesn't have the data required for a conditional move.

This isn't unique. Instruction fetch have the same general problem, when a conditional branch instruction reaches the decode stage it doesn't in general have access to the condition it depends on. The solution is branch prediction, if the branch is likely to be taken (condition true) the front-end of the pipeline is speculatively redirected to fetch from the branch address otherwise it is ignored. If the prediction is later determined to be wrong all instructions and results resulting from that misprediction are undone.

2) Conditional moves in the renamer require speculation similar to a branch predictor.

But let's assume we handle a conditional move like a branch. IOW we use the branch predictor, we detect the CMOVE at decode and if the predictor says it is likely to be taken it is tagged so that the renamer can detect this and handle it appropriately.
We could also use a dedicated predictor still tagging the CMOVE. That could be better.

What should the renamer do with a CMOVE?
--
CMOVE Rd, Rs, Rc

Ps=remap[Rs]
Pc=remap[Rc]

if (predictor_tag) remap[Rd]=Ps
--
But we still have to have some way to check the prediction, that is: that Rc will get a value indicating a true condition in the future. Cleanest way is just allow the CMOVE to continue down the pipeline.

However there's still a problem remaining. One that also exist when doing non-conditional MOV elimination in the renamer like modern x86.
We can have one physical register mapped to several architectural ones. This have to be tracked and handled. Worst case: 32 RISC registers can be mapped to one physical entry.

Again: Exactly how do you expect conditional moves to be executed at the renaming stage?

Supports "Unix"? Which fucking one?!

[Anonymous Coward]

... supports Linux, Unix, and FreeBSD. ...

When they say "Unix", which OS are they talking about? Solaris? AIX? HP-UX? macOS? UnixWare? OpenServer? One of the many other variants?

Seriously, how the fuck did that crap end up in the summary? Yes, I realize it's from the article, but EditorDavid should've seen that it's nonsensical and should have fixed up the summary before it ended up on the Slashdot front page!

Even timothy probably wouldn't have screwed up like this!

Re:Supports "Unix"? Which fucking one?!

[Nutria]

EditorDavid should've seen that it's nonsensical

LOLOL

Well Done !

[johnjones]

Quite an achievement !

It always amazes me that governments dont invest in this level, for example the french military will avoid certain american tech but seem happy to pay an unauditable Intel corporation

at least the European Space Agency made their own Sparc processor but I've seen little other investments made with public money that might actually benefit the public and be verifiable by outsiders...
                     

Re:Well Done !

[Anonymous Coward]

Russia is making their own chip. And I don't blame them! Chips made by US companies cannot be trusted.

https://www.siliconrepublic.com/comms/russian-cpu-debut-us-tech-breakaway

http://hexus.net/tech/news/cpu/71357-russia-building-baikal-processor-replace-amd-intel-chips/

Re:Well Done !

[AmiMoJo]

China has its own line of MIPS CPUs that are pretty competitive.

They are actually one of the few fully open platforms in existence, where everything is fully documented. Well, the masks used to make the silicon are not, but you can at least verify the operation of the CPU yourself to a larger extent, and you don't need binary blob microcode updates.

Re:Well Done !

[Anonymous Coward]

Because most countries in the world are not Dictatorships but free market Democracies.

Re:Well Done !

[Bert64]

You mean the loongson chips? I've not been able to actually buy any of those chips (at least not the newer multi core variant)...

Re:Well Done !

[AmiMoJo]

Yeah, those. They are hard to get hold of outside China. Seems like a trip to Guangzhou is required.

The bottom line

[Neo-Rio-101]

I think the big take-away that will drive the adoption of an open source CPU, is the fact that governments and corporations can be sure that there's no secret spying implemented within it.
This presumes that you can trust whoever ends up making these CPUs based on the design.

Re:The bottom line

[Anonymous Coward]

An architecture doesn't provide any assurance of lack of spyware. A brand new house could be bugged, even if you are given all the blueprints and architectural plans, and those documents are examined by security experts.

Re:The bottom line

[Anonymous Coward]

An architecture doesn't provide any assurance of lack of spyware. A brand new house could be bugged, even if you are given all the blueprints and architectural plans, and those documents are examined by security experts.

What he's implying is that if the designs for the CPU are open then you can build it yourself and be sure that the CPU doesn't have any backdoors in it. In the same way as if you built your house yourself you can be sure it doesn't have a secret bug. In other words just as long as you check the designs are correct (properly sound isolated and with no special microwave reflectors and you also check that all the people doing the building are trustworthy (normally you make sure you use a security cleared set of your own nationals).

This is difficult but not impossible. Getting the same assurance with a CPU you buy is impossible.

Re:The bottom line

[TheRaven64]

No they can't and the DARPA SSITH program (yes, DARPA sometimes names projects with Star Wars references) is explicitly intended to try to address this problem. At present, unless you not only run your own fab, but also build your own equipment and don't license things from the likes of Cadence, you have no guarantees that the thing that you get back doesn't have secret vulnerabilities introduced. Trying to verify that the chip you get back corresponds to the RTL that you sent to the fab is a very hard problem.

Re:The bottom line

[Wrath0fb0b]

This and much worse.

The chip that you get from the fab needs to be correspond to the RTL that you sent.

The actual chip ROM that they program has to correspond to the ROM that you want.

The firmware programmed* onto any of the peripherals has to correspond to the firmware you want.

The compiler has to be known not to dynamically insert backdoors when compiling. And no, you cannot verify this by inspecting the compiler source [PDF].

* No, I'll recompile the open-source firmware and reprogram it. Besides the fact that you will be recompiling on an untrusted system, how do you know that are you actually reprogramming it? Because the chip reported success? Maybe their firmware allows itself to be reprogrammed but patches the incoming firmware in a few key places as it comes in?

Re:The bottom line

[Anonymous Coward]

> And no, you cannot verify this by inspecting the compiler source

But you can detect something's fishy by diverse double compilation Find a compiler unlikely to have the same trojan behavior as your "regular" compiler, and compile your regular sources with each one. If it's all good, you now have two functionally equivalent binaries of your regular compiler, which are different binaries (because you used different compilers to build them). Recompile your regular sources with these two functionally identical differing binaries, and you should get identical binaries of your regular compiler. If they're identical, your regular compiler was clean. If not, you have problems...

Re:The bottom line

[Wrath0fb0b]

Maybe after months of trying to create exactly reproducible builds (hint: it took Debian three frickin years), fighting with the fact that compilers randomize their optimizations (for good and unrelated reasons) and all that noise. That's what's required to get the same version of gcc to produce identical binaries of your regular compiler.

Then you'll figure out that you didn't really appreciate the full scope of the problem because the compiler is just one small place in the system. In fact, the original ACM paper points out that it demonstrates the concept with respect to a C compiler but the same exactly problem resides in the loader and in the microcode of the CPU itself. Each step into the depths reveals a new place where your program is just data* swimming by some other program that can patch it along the way.

* In fact, that's what the entire edifice of computing is built on -- that what is code on one layer of the system is actually just input or output to another. It's so familiar we don't even realize it. When we type 'apt-get whatever' or "execv" or "dlopen" our program is just another blob that someone else's program chews through.

Re:Covfefe Post

[Anonymous Coward]

He was trying to say corespondent

I'd buy in a heartbeat if no IME or UEFI net stack

[Anonymous Coward]

This company needs to (if they haven't already) get an international, non-goverment group of silicon and firmware security experts do a full audit to ensure the architecture and reference designs contain no Intel ME or UEFI stuff and no undocumented instructions; no silicon- or BIOS-level network stack, no DMA memory access, and a fully-open BIOS. They would have a real comfy niche that neither Intel, AMD nor ARM (with their non-TrustZones) are now willing to fill.

Best get those designs hosted and fabbed outside of the US, Russian and Chinese spheres of influence, too.. or maybe that's not possible, so just make them in all three, with auditing up the wazoo.

Trusted Foundries???

[ad454]

I am a huge supporter of open hardware projects, especially the ESA and Oracle supported opensparc architectures.

https://en.m.wikipedia.org/wik...

However without a trusted silicon foundry to make chips without hardware back doors, all of the vetting of the hardware design "source" RTL won't be enough to establish trust. Even running netlists in FPGAs won't be enough if you can't trust the FPGA manufacturer or the foundry that built it.

In the end, we as consumers are stuck without any truly secure hardware options, free of backdoors.

My advice, assume all processors have backdoors and select those designed and made in places that cannot be compelled by the country in which you live for backdoor access.

Re:Trusted Foundries???

[Anonymous Coward]

It's good to see someone else as paranoid as me regarding hardware trustability.

Re:Trusted Foundries???

[Anonymous Coward]

"My advice, assume all processors have backdoors and select those designed and made in places that cannot be compelled by the country in which you live for backdoor access."

This is word salad.

Re:Trusted Foundries???

[Anonymous Coward]

"In the end, we as consumers are stuck without any truly secure hardware options, free of backdoors."

What do you think of the Raptor Talos-II?

https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation/updates/talos-tm-is-back-talos-tm-ii-now-available

Re:Trusted Foundries???

[aliquis]

My advice, assume all processors have backdoors and select those designed and made in places that cannot be compelled by the country in which you live for backdoor access.

Here in Sweden the authorities aren't allowed to register your political opinions.

However I assume Interpol are and they co-operate with them. .. And they are ~everywhere.

Re:Trusted Foundries???

[Anonymous Coward]

Would it be possible to include some kind of (hardware/physical or software based) checksum which guarantees these chips haven't been modified with any kind of backdoor?

Re:Trusted Foundries???

[Anonymous Coward]

You could. But given the design is open source and spy agencies get shitloads of money, they could easily redesign the spec sent to a fab so that it does work out properly.

The more complex you try to make this security feature, the more overhead you add to the design as well as its ability to function as a processor.
Eventually it becomes infeasible for any significant use-cases as a processor due to said overhead.

In the end, the only real way to try figure it out would be to analyse chips after an order has been placed, see if the design differs in any way from the one given and sue the ass off the fab that did it if they do change it.

Re:Trusted Foundries???

[Anonymous Coward]

Bend over and I'll show you the access he means.

Re:Trusted Foundries???

[Anonymous Coward]

They look great, thanks for the link. Just wish I had the money!

Re:Trusted Foundries???

[Anonymous Coward]

Hah, Belgian here. Do you know what interpol is? Of course they are everywhere - your local police are the local arm of Interpol.

With a budget of €150,000,000... they tend to have a smaller budget than most police forces in large cities.

Hard to track and care about you when their budget is so small that they tend to promote and work on databases and interoperability between member states.

Of course, if as a swede you went to Russia and they filed your political opinion which was illegal, the local swedish police would arrest you. Not because they have your 'opnion' on file, but because Russia put out a warrant with interpol.

Re:Trusted Foundries???

[Lennie]

Baby steps, you can't go from completely closed to completely open in one step.

I believe it was this talk by Bunnie that talks about the usefulness and uselessness of where we are now and how long a way there is still to get to get something we trust:

https://www.youtube.com/watch?...

Re:Trusted Foundries???

[Anonymous Coward]

Bingo! All these wannabe "security" "gurus" are clueless poo-flingers. They think they have the answers. It's actually quite friggin' simple, really- and you nailed it in one.

Re:Trusted Foundries???

[AmiMoJo]

There are other effective mitigation strategies for potentially compromised hardware. For example, you could mix vendors with carefully controlled cross-domain access so that an exploit in one does not compromise others.

I'd love to see an open source security processor for this reason. It would be extremely valuable to have a crypto engine and secure key storage that you could trust. Unfortunately such things are also very difficult to design and fabricate.

Re:Trusted Foundries???

[Megol]

I don't think you realize what Interpol is. It's mainly a system to enable some level of co-operation of police forces between different countries. Criminals don't care about borders after all...

Interpol doesn't really do anything but pass information.

Re:Trusted Foundries???

[Anonymous Coward]

Or......... Run everything on 3.5Mhz Zilog 80s. The NSA will just knock on your actual back door and ask you what you are encrypting, rather than wait for your bugged chip to get finished encrypting with a backdoor. However whatever Ethernet or Wifi module you are using could probably still do a pretty good job of letting them in. But as soon as letters took twice as long (likely more) to appear, you'd know you had guests.

Re:Trusted Foundries???

[tamyrlin]

If you are really really paranoid you could build your own processor using TTL logic (or perhaps CMOS logic may be better). It is not going to be very fast, but it is unlikely that the TTL chips are backdoored (and even if they are backdoored it is unlikely that the backdoor will be able to harm this system since the design of your processor is unlikely to be known by the vendor). The performance will of course not be good enough for running a web browser for example, but it could be good enough in many embedded situations.

I've been toying with the idea of doing this together with a very minimal compiler designed to be easy to inspect for security hole and easy to assemble by hand to minimize the risk of backdoors in order to ensure that really paranoid people can bootstrap a system which is extremely unlikely to contain backdoors. (I'm not that paranoid myself, I would just like the challenge of building a TTL based computer good enough to boot Linux :))

Re:Trusted Foundries???

[Anonymous Coward]

Run the core on an FPGA, perhaps?

Re:Trusted Foundries???

[cheesybagel]

Yep. But read about the "European Gendarmerie Force"...

Re:Trusted Foundries???

[aliquis]

Interpol doesn't really do anything but pass information.

So you mean they won't get information about Swedish residents anyway?

What made me wonder was because in a video two(?) guys from NMR was stopped by the police who was very sure they would go to Gothenburg, where NMR would have a demonstration.

That would to me suggest the police knew they had sympathies with them or even had gathered intelligence about them going there, which is a political event.

In some way that would to me seem to suggest they do care about their political sympathies after all and since Interpol is just fine with profiling and registering people and Sweden is participated I assumed that maybe they report these individuals to Interpol instead and then a register is created there which they have access to anyhow regardless of what our laws say.

Or you don't think Swedish authorities will contribute such data to Interpol because of how our laws are?

Re:Trusted Foundries???

[aliquis]

Which was illegal in Russia? Even though I was in Sweden?
Not sure Swedish police would arrest me for having an opinion in Sweden which is ok regardless of what Russia thought about it?
Here in Sweden you are free to have your opinion. Just not express it.

Umm...

[Anonymous Coward]

Didn't linux support RISC already?

Re:I'd buy in a heartbeat if no IME or UEFI net st

[Anonymous Coward]

I would think it's safe to say that there is no Intel ME in their low-level hardware design. But Trustzone is an ARM chip, and I wouldn't be surprised if that wound up in the spec somewhere.

Since it is an open-source effort, expect that the Russians and Chinese will be looking at it for domestic adoption, perhaps in violation of whatever licenses cover the hardware designs. Russia has already essentially adopted Elbrus (for now) while the Chinese seem to be vacillating between their own homebrew Loongson chips and VIA CPUs. And whatever else they can appropriate from others.

Can someone please explain?

[HotNeedleOfInquiry]

The article says RISC-V supports Linux. I always assumed an operating systems supports the processor. Not the other way around.

Re:Can someone please explain?

[Anonymous Coward]

The article says RISC-V supports Linux. I always assumed an operating systems supports the processor. Not the other way around.

It's more about who is willing to put in the effort to support a CPU. It's far more than just a kernel. There is a tool chain, C library, assembly optimizations for libraries like OpenSSL. There is quite a bit of effort involved. And to bring up a new CPU architecture means that this work is often shouldered by the organization championing the architecture.

Consider x86-64 (i.e. amd64): AMD did quite a bit of this legwork. And then Intel just moved in and benefitted from it. Such is life in the CPU architecture business.

I suspect the RISC V folks have put in a bit of effort in getting everything going, including a GCC port. Plus for a CPU to really support Linux it needs an MMU. In fact it needs a certain kind of MMU. Yes, there is uCLinux. But the implication here, to embedded systems guys, is that this architecture can support memory protected operating systems. Not every CPU can (e.g. Analog Devices BlackFin).

Re:Can someone please explain?

[Anonymous Coward]

The vast majority of possible architectures do not support Linux. Linux requires a 32 or 64 bit architecture with directly addressable 8-bit bytes, little or big endian, an MMU, a reasonable page size, memory-mapped I/O (that could probably be worked around), no word-level memory tags (or an emulation that hides them), full access to the entire memory space from all CPUs, and a bunch of other things.

Anything even slightly esoteric, like 36-bit or 24-bit or MMU-less or protection-only MMU or segmented memory or middle endian or tagged memory is just not supported. The most numerous CPUs, namely microcontrollers and DSP's, are unable to run Linux. IBM's System z and System i only run Linux under a hypervisor that makes those architectures look like what Linux wants.

Classic Crays as well as the various mainframe- and minicomputer architectures are generally incompatible with Linux.

The only reason it seems that everything will run Linux is that the modern CPUs you actually interact with are essentially all the same, apart from the instruction encoding.

Re: Can someone please explain?

[Anonymous Coward]

You can run linux on weird cpus, but expect more work in porting. Pages bigger than 4k? Whoops, wont work with existing file systems. But provide your own fs, and you can use linux. Just not with ext2.

36bit is not a problem. It will run like 32 bit with extras - or like a 64 bit system with some restrictive limits thrown in.

What kind of C compiler toolchain supports it

[Anonymous Coward]

gcc + binutils?

Re:What kind of C compiler toolchain supports it

[Anonymous Coward]

Yes, GCC and clang support generating RISC-V code.

Re:I'd buy in a heartbeat if no IME or UEFI net st

[Anonymous Coward]

But Trustzone is an ARM chip, and I wouldn't be surprised if that wound up in the spec somewhere.

TrustZone is basically a masked boot ROM included in many ARM SoC's. As RISC V isn't compatible with ARM it isn't really applicable. The problem here is can you trust that when you get the silicon the first instruction you execute is really the first instruction. It's hard to say that an evil chip manufacturer doesn't put in a small virtualization ROM in the chip at the bootstrap address. So even if you are writing a bootloader from scratch you can't guarantee you aren't running in a VM prison and your HW is compromised.

This is a rather tricky problem. It would take the likes of an organization like DARPA to solve it.

As in "can we prove our HW is trusted even when we don't trust the manufacturer." To really provide any sort of trust every word in memory would have to have an origin tag that is asserted on the bus and you basically break the CPU up into two chips (made by separate manufacturers, of course) that cross-check each other using these tag bits. It will result in some performance sacrifice. A multi-chip CPU will always perform worse than a single chip one; especially in terms of power consumption. But it's probably the only way to ensure that a chip manufacturer doesn't put you in a prison that you don't even know you're in.

Kind of like a Truman show for software.

Lame aim.

[Anonymous Coward]

"aiming to push the RISC-V architecture to transform the hardware industry in the way that Linux transformed the software industry"

So... virtually no users, then?

RPi form factor?

[Anonymous Coward]

So SiFive sells a dev PCB for one of their chips that is Arduino compatible. Since this chip seems to be more for higher end embedded systems perhaps it would be smart to build up a dev board that is in the same form factor as a Raspberry Pi. Complete with the same 40 pin header. It would help not only hardware hobbyists with piles of Pi Hats already in existence but also serve as a development board for professionals. Saving the cost that would normally be associated with designing a dev kit.

Re:RPi form factor?

[bugs2squash]

like this one ?

Re:RPi form factor?

[Anonymous Coward]

That's a nice little FPGA board (thanks for the link) but it would be nice to see the actual chip SiFive produced as opposed to an FPGA implementation. Well, I guess the hopes are that it will be cheaper than slapping a spartan down on a board.

And I ... won't back down!

[Anonymous Coward]

- List of Soviet computer systems
https://en.wikipedia.org/wiki/...

- History of computer hardware in Soviet Bloc countries
https://en.wikipedia.org/wiki/...

- Category:Computing in the Soviet Union
https://en.wikipedia.org/wiki/...

That's a start, comrade!

That's what I was wondering.

[Anonymous Coward]

I came here to ask this question. Does it tie into existing kernel support in such a way that it is actually supporting them, or are they contributing to those projects to provide support, or what?

Can this CPU be implemented on FPGA?

[gweihir]

If not, the "open source" part does not mean a lot for most people.

Re: Can this CPU be implemented on FPGA?

[Anonymous Coward]

Do you have a source of open source FPGAs? Most that I know of are very closed. The FPGA toolchains from the major vendors are also very closed source. I downloaded a Xilinx toolchain this weekend, it even has export restrictions I had to agree to.

Re: Can this CPU be implemented on FPGA?

[bugs2squash]

Try icestorm

Re:Can this CPU be implemented on FPGA?

[TheRaven64]

Not sure about this one, but the RISC-V Rocket cores can run in various FPGAs (as can the Sodor cores, which are more useful if you want to learn about computer architecture, but are a bit out of date in terms of conformance to the RISC-V spec). The lowRISC SoC includes the Rocket core and can also run in FPGA. The FreeBSD RISC-V bringup was done in a mixture of software emulator and lowRISC in FPGA.

Re: Can this CPU be implemented on FPGA?

[TeknoHog]

Do you have a source of open source FPGAs? Most that I know of are very closed.

I'm not sure this is what the GP means. There are already several opensource CPU designs ready for FPGA implementation, for example at opencores.

It's a good point to keep in mind that a closed FPGA toolchain could introduce unintended features in your opensource CPU. However, it's basically the same issue as running Linux on an Intel processor -- the practical implementation is not fully open source, even if the original software is.

Re: Can this CPU be implemented on FPGA?

[gweihir]

Indeed. Of course, a fully open tool-chain and a fully open FPGA would be better, bit there are things you can do to prevent the tool-chain from messing with your design or to make it obvious. And I really doubt FPGA vendors would hide significant extra hardware in there on the off chance they can compromise CPUs.

Re:Can this CPU be implemented on FPGA?

[gweihir]

Still interesting. Thanks. I think that eventually high-security computing will have to go that way, probably with master-checker pairs implemented in different FPGAs or something like it on top of it.

Has it backdoors?

[UBfusion]

I'm not optimistic this cpu would be allowed to be mass-produced, since it appears it won't have any of backdoors the Intel and AMD ones have.

Re:Has it backdoors?

[Midnight Thunder]

I'm not optimistic this cpu would be allowed to be mass-produced, since it appears it won't have any of backdoors the Intel and AMD ones have.

That’s the difference between implementation and specific implementations. Who is even to say there isn’t a secret instruction in a given implementation? The problem will end up being whether the open implementation provides enough value of a licensed technology like ARM.

Sometimes the open solution is more costly than the paid solution, so we will see what happens down the road.

Re:Has it backdoors?

[Midnight Thunder]

That was meant to be ‘reference implementation’ vs ‘actual implementation’, but I failed in putting that.

Re:I'd buy in a heartbeat if no IME or UEFI net st

[hairyfeet]

Can ANYBODY provide any REAL evidence of this supposed AMD ARM chip? Because I have scoured the net and have only found a couple of 2012 articles saying "We plan to do this sometime" and ZERO actual code, ZERO actual layouts showing the location of this ARM core, and ZERO lists of any actual CPU/APU that have this installed.

The only actual facts I can find are 1.- AMD licensed an ARM Coretex 5, and 2.- They have used it on exactly ONE CHIP, the Jaguar APU which they sold to MSFT and Sony for their game consoles, that's it. NO other chips, NO security features that having such a chip would have that would appeal to business customers like remote corporate control of assets, not a damned thing but a bunch of FUD that all trace back to the same articles from 2012.

Re:Covfefe Post

[Anonymous Coward]

And interestingly enough, neither of you two can spell it.

Nope

[Anonymous Coward]

Linux has not transformed the software industry.

Re:Nope

[UnknownSoldier]

2 Billion devices running Android, not to mention all the other cheap computing devices (IoT), isn't enough???

Re:Nope

[iTrawl]

Even Microsoft is shipping Ubuntu with their Windows these days. I'd say it transformed the software industry quite a bit.

Re:Nope

[Anonymous Coward]

as dumb ass posts using a linux server.

Re:Nope

[Anonymous Coward]

Yeah, except for being the OS installed on over half the computers it sight, and inspiring the development of a userspace where pretty much everything is commoditized so that I basically don't ever buy software anymore (except for games), it hasn't transformed software.

Saying Linux has transformed the software industry is like saying the internal combustion engine has transformed the transportation industry. Find some backwoods hillbilly who still relies on his horse or Microsoft Windows, and he'll be happy to explain your error in small words, for your ignorant city-dwellin' mind.

Re:I'd buy in a heartbeat if no IME or UEFI net st

[Anonymous Coward]

contain no [omitted] UEFI stuff

Minor nitpick: UEFI has been ported to RISC-V, but this CPU will most likely work with non-UEFI boot firmware.

First OpenSource ISA in mainline was LEON

[Anonymous Coward]

This is not the first. That would have been LEON SPARC. There are a few others also, but the next 'actively maintained' might be J-Core (SH). RISC-V is interesting, I'm a big fan of open computing. But no, it's not a first.

Both. They are compatible

[raymorris]

It goes both ways. A manufacturer isn't going to release a new high-power CPU that can't run any operating system. The CPU needs to "support" (be compatible with) some operating system, and the company making the CPU will likely need to be involved with the first OS port.

The case of AMD64, aka x64, is a good example. Before the CPU was actually produced, AMD made a emulator, then AMD and Suse ported Linux to the new instruction set. By actually running Linux on the new instruction set they could identify any problems with the CPU design design before making it in actual silicon.

  Four years later, Microsoft released some x64 support in Windows. So you could say that first the hardware CPU was manufactured to support 64-bit Linux, which existed before the CPU was produced. Years later, Windows started supporting the CPU. Similarly, back in 1995, Linux added support for 64 Alpha processors, which existed before Linux supported them.

Re:Both. They are compatible

[Anonymous Coward]

I think it is interesting at the second. Last year Microsoft announced that Win 7 will not support the new Intel Skylake CPUs. But what does that mean?

Windows runs on x64 and Skylake is an x64 chip. So of course a Skylake CPU will run Windows 7.

But if Windows 7 is truly incompatible with Skylake CPUs, then doesn't that mean the Skylake CPU is not compatible with x64? Which would be a much bigger issue.

The misreporting on this topic has stunned me.

My interpretation is: Skylake CPUs will run Windows 7. Skylake CPUs will come with new features that Windows 7 will not be able to take advantage of. To use all of the new features of a Skylake CPU then the user must upgrade to Windows 10.

Of course I've had no luck determine what that list of "new features" actually is...

Re:I'd buy in a heartbeat if no IME or UEFI net st

[Anonymous Coward]

no DMA memory access

What, you want the processor to block every time it is loading something to cache and for a core or more to be churning when transferring to/from memory and peripherals? DMA isn't a problem in general, although it is possible to have bad implementations and security is harder if peripherals are allowed to just pull from memory without bounds. Making a sane and secure setup where DMA is controlled and requests are validated would still be DMA in the sense the processor can go back to work or sit idle while dedicated hardware handles the transfer.

Re:I'd buy in a heartbeat if no IME or UEFI net st

[Anonymous Coward]

Sigh. Again I was being brief and unspecific, mea culpa. I was thinking of the Firewire remote DMA access, not *local* DMA access that is useful and appropriate within the machine. I was recalling avenues that had been in past used to compromise Apple machines (no, I don't have references here, it's late and I'm lazy. I fully admit I don't recall all of the details and probably even got some wrong.. this isn't a technical discussion, but one of general principles.) Perhaps it's not germane to this thread. I was just thinking of avenues that might be used to compromise an otherwise-trusted architecture. Tear away at my vague assertions as much as you like.. I was simply trying to portray the things we should look for, being paranoid, in a new architecture that serves people rather than intelligence agencies.

Please stop being so pedantic people. I was just trying to point out ways in which a supposedly open architecture could still be un-trustworthy if we're all not careful to demand proper auditing of all possible avenues of exfiltration.

Re:Covfefe Post

[Anonymous Coward]

Funny. I don't see anything but disaster, division and uncertainty. Not to mention a whole lot of trolling.

But...

[LordHighExecutioner]

...does it run Windows ? (ducks...)

Re:I'd buy in a heartbeat if no IME or UEFI net st

[TheRaven64]

This is a rather tricky problem. It would take the likes of an organization like DARPA to solve it.

DARPA's SSITH program is attempting to address this, but I suspect that a complete solution is much bigger than a single DARPA program.

Re:I'd buy in a heartbeat if no IME or UEFI net st

[TheRaven64]

The guy in the office diagonally across from me has one on his desk, not sure if you count that as 'real evidence'. They were the boards that ARM was selling as early developer systems for ARMv8. I've not seen much evidence of AMD trying to make them into a large-scale product.

Not Open Source

[Going_Digital]

While the RISC-4 IA is open, the U54 is a closed design. So while the having an open IA is better than nothing, don't expect to be looking at the intricate details of how processors like the U54 are designed as that part is strictly closed. It is unfortunate that semiconductor fabrication is so prohibitively expensive leaving FPGAs as the only viable option for community designs.

Re:Not Open Source

[Anonymous Coward]

While the RISC-4 IA is open, the U54 is a closed design.

This processor is all about "licensing" and intellectual property (IP). The opening line of this article makes SiFive's intentions very clear: "SiFive has taped out and started licensing its U54-MC Coreplex, its first RISC-V IP designed to run Linux." (Emphasis mine.)

Re: I'd buy in a heartbeat if no IME or UEFI net s

[Anonymous Coward]

Can't you do a first article inspection and closely observe thr processor coming out of the reset vector?

Processors DO still need to boot up out of reset vectors, and oscilloscopes still exist. In fact very good oscilloscopes exist, though software folks are VERY abstracted away from the reality of processor cycles at that level these days. Even if it's buried in the silicon power supply ripple analysis can be performed.

Cleaner = better.

[Anonymous Coward]

https://en.wikipedia.org/wiki/RISC-V

IMHO, the 32-bit float instructions must be removed. Only 64-bit double instructions will be accepted for better accuracy (very useful for supercomputers).

Re:Cleaner = better.

[Anonymous Coward]

The following architectures are very similar.

https://en.wikipedia.org/wiki/DLX

https://en.wikipedia.org/wiki/MIPS_architecture

https://en.wikipedia.org/wiki/ARM_architecture

https://en.wikipedia.org/wiki/RISC-V

Their ISAs are type RISC but some mechanisms in silicon are complex & better.

Well, for compressing bytecodes, the Big-endian is little better than Little-endian.

Re:Cleaner = better.

[Megol]

I'd expect someone with such an extreme opinion to at least try to argue for it.

Floats are generally enough. They require less hardware and the hardware consume less power per operation. Less memory bandwidth and less memory space are needed. IMO most uses of doubles are either to be safe or to try to compensate for lack of analysis of the problem at hand.

But I can be even more extreme than you: only 128 bit fixpoint numbers should be allowed. Of course stored in ones complement.

Re:Cleaner = better.

[K. S. Kyosuke]

I can see languages like Scheme (Gambit, Chez, Gauche...) being happy with FP64-only operations and FP64/FP32/FP16 stores/loads since the language doesn't know (shorter) "C"-floats anyway, with the loads and stores solving the memory problems but with intermediate results at desired higher precisions. Outside of GPUs, the benefits of FP32 availability seem much smaller. And regarding the "trying to compensate for lack of analysis", I vaguely recall even Kahan himself recommending for going for the widest word you can use as being the most logical thing you can do regardless of your analysis, and even expecting x87's 80 bits not to be the ultimate width of FPU logic but only a stepping stone until we get more transistors (it got kind of stuck since then but we *did* get standardized 128b floats quite recently).

Skylake is more than x64. Applications will work

[raymorris]

>. But if Windows 7 is truly incompatible with Skylake CPUs, then doesn't that mean the Skylake CPU is not compatible with x64?

Applications written on / for Windows 7 should work on Skylake. The operating system needs to be concerned with more than just the instruction set. The OS has to support the busses in use (NVME and USB3), the power management scheme, the boot process (UEFI, not BIOS), hardware interrupts, etc. A few manufacturers have tested some of their Skylake models with Windows 7.

JavaScript in RISC-V variant?

[Anonymous Coward]

> IMHO, the 32-bit float instructions must be removed. Only 64-bit double instructions will be accepted for better accuracy (very useful for supercomputers).

In https://en.wikipedia.org/wiki/Double-precision_floating-point_format#JavaScript says:

As specified by the ECMAScript standard, all arithmetic in JavaScript shall be done using double-precision floating-point arithmetic.

Should have added this on your SN post :)

[Anonymous Coward]

Question for you then:
How do the J2/3/4 open source SuperH designs compare?

I know the reason for current limitations is waiting for patents to expire which should lead to future chips with even more opcodes and features as a result. And they had pretty extreme FP performance back in the late 90s/early 00s when they were produced. I seem to remember there were other pitfalls to their architecture, but getting a processor that is Management Engine (Aka Clipper+Palladium+TPM) free is a huge boon to the future of computer security, and must be done while we still can before it gets ingrained into law that it is required.

Having said all this: Is it perhaps time for a different CPU project, or a fork of RISC-V with these missing features added, at the risk of binary incompatibility, but to the benefit of performance and perhaps security?

Re:Should have added this on your SN post :)

[TheRaven64]

How do the J2/3/4 open source SuperH designs compare?

I've not looked at SuperH in detail, so I can't really compare.

I seem to remember there were other pitfalls to their architecture, but getting a processor that is Management Engine (Aka Clipper+Palladium+TPM) free is a huge boon to the future of computer security

I disagree. A TPM, secure enclave, or equivalent, is increasingly vital for computer security. It is absolutely essential that you have some write-only storage for encryption keys into a coprocessor that will perform signing / signature verification / encryption / decryption, but which does not allow the keys to be exfiltrated. Anything less than this and a single OS-level compromise means that you need to reset every password and revoke every key that you've used on that machine.

Having said all this: Is it perhaps time for a different CPU project, or a fork of RISC-V with these missing features added, at the risk of binary incompatibility, but to the benefit of performance and perhaps security?

There are lots of extensions to RISC-V, but the problem there is fragmentation. You need the A extension if you want to run a real OS. You probably need the C extension, because compilers are starting to default to using it. The M extension is useful, so people will probably start using it soon. Hardware floating point is expensive on low-end parts, so you're going to end up with some having F, some having D, and some having neither (this was a pain for OS support for ARM until recently - now ARM basically mandates floating point on anything that is likely to run an OS), and a few will support Q. L is unlikely to be used outside of COBOL and Java, so isn't too much of an issue (one is niche, the other is typically JIT'd so it doesn't matter too much if only some targets support it). And that's before there's any widely deployed silicon. Expect vendors to add their own special RISC-V instructions, making their own versions of toolchains and operating systems incompatible.

RISC-V isn't the first project to try this. OpenRISC has been around for a lot longer, but RISC-V managed to get a lot more momentum. I don't think that a competing project would find it easy to get any of this. It remains to be seen whether this momentum can translate to a viable ecosystem.

CISC is, ahem, WAY better than RISC for ASM coders

[Seven Spirals]

RISC-V is cool insomuch that it's free as in freedom. However, as an ASM programmer, I won't be touching it. As others have already pointed out more eloquently, the RISC idea was to make up for lack of decent ISA with compilers. For the most part, it worked out. However, it doesn't change the fact that most RISC processors are freakin MISERABLE to program. I'm speaking from everyday experience. People might complain about x86 having some stupid addressing modes, but trust me, that's NOTHING compared to how austere the environment is when you are doing modern ASM on an RISC based system. I'm much more excited about the non-open source Apollo M68080 core for AmigaOS (and possibly Macs and Atari ST's soon). It's not going to excite the *nix crowd, and it's not free or open source. However, it's much fun & easy to write ASM on. I'm not dissing the RISC-V, it sounds like they already have compiler back ends lined up. So, that should be interesting, but as an ASM coder, I'm not especially interested in RISC-V. I could make a LONG post of the things I'd miss if I had to stay on a RISC platform. However, few others would, since almost everything is in C or C++ that matters nowadays.

1995 prophesized Risc will change everything

[Cito]

Risc architecture will change everything!

triple the speed of a pentium!

it even has a pci bus!

https://youtu.be/wPrUmViN_5c

Is possible JavaScript on RISC-V!!!

[Anonymous Coward]

I think that Mozilla & Google will be happier if RISC-V supports JavaScript efficiently.

It's my list of popular languages for RISC-V in a near future:

1st JavaScript.
2nd ActionScript.
3rd TypeScript.
4th Rust.
5th Python. ...
20th Java. ...
30th C#.

Some notes on branch prediction vs conditional exe

[tamyrlin]

Just wanted to chime in with some notes on conditional execution:

First of all, if all you care about is single-issue non-superscalar with a relatively deep pipeline, conditional execution is probably a good idea in my experience due to the very low implementation cost. Especially if your branch prediction is lousy. However, if you are aiming for high-end systems conditional move may not be that big of a deal. See for example the following analysis from Linus Torvalds regarding cmov: http://yarchive.net/comp/linux... where it can be seen that cmov is basically a win only if you have situations where a branch predictor wouldn't do a good job. However, it may still be a good idea to keep some sort of conditional instruction around since it is likely to be useful if you are dealing with for example lossless compression/decompressions since you are typically dealing with unpredictable data in this case.

I could also chime in with an interesting tidbit from ARM1. Conditional execution was probably a really big deal here since the ARM1 didn't have any caches. It did however have support for burst reads from memory. As long as it was fetching instructions sequentially it could basically sustain a very high instruction throughput. A branch would however reduce the performance significantly since the burst had to be aborted. Conditional execution could be done while maintaining the burst however. This is one of the reasons why ARM1 with about 30000 transistors was competitive in performance with for example the 68020 which had close to 200000 transistors. If the ARM instruction set was designed today however it is likely that the designers would not go crazy with conditional execution since the bits could be better used for something else.

Re:Skylake is more than x64. Applications will wor

[Anonymous Coward]

Original AC here. Thank you for taking the time to reply, and I daren't use /. as my personal research machine. But I can't find *any* actual details online along the lines you mention.

USB3 worked before, it will work after (the USB2 specification has not changed, for example).

NVME affects storage, again, I can't find any details online.

What I was asking was: why announce "Skylake does not work on Windows 7 and won't receive any Windows updates" instead of "Windows 7 will have limited support for Skylake architecture. Running Windows 7 disables or restricts these features: ..., ..., ..., ...," etc...

I'm not pointing fingers or ascribing blame here, I'm giving an example. When Microsoft stopped releasing details for security patches because "reasons" I feel like tech reporting has just all gone downhill and it is almost impossible to get any actual details.

Does anyone have any thoughts on that? I don't think I'm going too far off topic, as it all relates to CPU support and having a better understanding of how it all works leads to a better understanding of whether RISC-V will work for you.

Key issue:

[Anonymous Coward]

None of these chip designs has been fabbed in a serious attempt at commercial market penetration.

The best outcome would be a board fabbed with a custom LGA775 style northbridge+southbridge and a patent free standardized frontside bus that open sparc, superh j and risc-v chips could all be plugged into.

This would eliminate monoculture risks, help multiple processor architectures get bootstrapped, and help us decentralize the motherboard ecosystem to what it was like before Intel fucked all the chipset designers in the mid 90s with first the Pentium and then Pentium Pro/2 chipsets leading to the demise of basically every 3rd party chipset company except Acer Labs and VIA.

Disables the ability to install and unknown things

[raymorris]

> "Running Windows 7 disables or restricts these features:"

They don't know what all features in various updates may not work, and they don't want to figure that out for an officially obselete operating system. One thing that often may not work is booting. Installing from a OEM disk probably won't work because it won't have the drivers for a USB3 keyboard and mouse. Power management will often not work - once the machine goes to sleep, it may not wake up again.

APPLICATION code generally is tied to a specific instruction set and OS. Application code doesn't generally care about the hardware, because the operating system takes care of the hardware. On the other hand, the operating system DOES care about the hardware, and Skylake hardware is different. Skylake is NOT "Ivy Bridge, faster" - it's a different microarchitecture.

> USB3 worked before, it will work after (the USB2 specification has not changed, for example).

Windows 7 does not support USB3 out of the box. USB2 is not USB3. They have one thing in common - similar names. USB2 is a synchronous, half duplex protocol over
one pair of wires. USB3 is an asynchronous, full duplex protocol with three pairs.

Re:Some notes on branch prediction vs conditional

[TheRaven64]

However, if you are aiming for high-end systems conditional move may not be that big of a deal. See for example the following analysis from Linus Torvalds regarding cmov

The problem with Torvalds' analysis (which is otherwise pretty good and worth reading) is that it only looks at local effects. The problem with branches is not that they're individually expensive, it's that each one makes all of them slightly more expensive. A toy branch predictor is basically a record of what happened at each branch, to hint what to do next time. Modern predictors use a variety of different strategies (normally in parallel) with local state stored in something like a hash table and global state shared with all branch locations. If the branch that you've added happens to hit the same table entry as another, then it may cause mispredictions elsewhere. This is horrible to try to model, because you have a performance cliff that moves depending on code layout (which is part of the reason why randomising the order of functions in a program can have around a 20% impact on performance).

The probability of misses increases based on branch density. Short branches have another issue, which is that typical superscalar processors don't make per-instruction predictions, they make predictions per fetch granule. If you have an 4-way superscalar processor, then you get one prediction for each 4 instructions. If you have two branches in there, then they'll be predicted together. This means that you really don't want a short branch immediately followed by another branch (or following a not-taken branch) unless you're really careful about alignment.

Note that some processors have spectacularly bad implementations of either branch prediction or conditional moves. PowerPC is notorious for this, where the performance difference between the two representations varies hugely between different iterations by the same vendor (and more between vendors), so compiler tuning is almost impossible.

If the ARM instruction set was designed today however it is likely that the designers would not go crazy with conditional execution since the bits could be better used for something else

You can see this with ARMv8. Most of the predication is gone, there are basically just conditional moves (conditional select) and conditional branches. There was apparently a lot of argument about whether to allow conditional loads. These are very useful because most other conditional patterns can be reduced to a conditional move: calculate both sides and select the one that you wanted, but is the condition is 'pointer is not null' then you can't speculatively load and then decide not to take the trap. Another proposed alternative is to have a non-trapping load (i.e. one that returns zero if that load would trap), though this can be difficult in the presence of swapping (the processor doesn't know the difference between a not-present page and a not-present-now-but-can-be-swapped-in page).

Re:Disables the ability to install and unknown thi

[Anonymous Coward]

"Skylake is NOT "Ivy Bridge, faster" - it's a different microarchitecture."

So Skylake is not x64????????????????????????

Re:I'd buy in a heartbeat if no IME or UEFI net st

[hairyfeet]

So in other words no actual products on shelves which backs up what I've been saying all along, the "AMD does it too!" is nothing but FUD being shoved out probably by fanboys.

Re:I'd buy in a heartbeat if no IME or UEFI net st

[TheRaven64]

AMD's ARM strategy is... complicated. As far as I can tell, they are very enthusiastic in their desire to plan to have a plan.