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]

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

[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

[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

[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

[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

[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

[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

[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

[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

[slashrio]

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

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 !

[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 !

[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

[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

[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.

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???

[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???

[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???

[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???

[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???

[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.

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: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.

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?

[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.

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.

Re:Nope

[UnknownSoldier]

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

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:RPi form factor?

[bugs2squash]

like this one ?

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:Nope

[iTrawl]

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

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.

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: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

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.

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: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).

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.