RISC V in the future?

[lfen]

you said you are a fan (see your above post).

I said "Here a fan of ZFS/rust/RISC-V .... but also fan of ext4/C/ARM"
What I was trying to explain but you failed to understand is that if I m fan of RISC-V it s because of the openness but If something else succeed on delivering what i want (open hardware with same perf ) i would be happy. Until then, I'm happy to use ARM

so, apart from its uber-freedom, you don't know about any advantages of it over existing, well developed and established CPU architectures?

I suppose you are happy with Windows, right ? So there is no point in continuing the discussion further as we dont think the same way ...
But I will anyway give you one more advantage (that I already told you): even cheaper product because company wont have to pay royalty fees to ARM.  

SPARC is an ISA, there is nothing in it, making it unsuitable for low power usages. as of POWER, I told you about Freescale/NXP devices. I am on tablet now, it's inconvenient, otherwise I'd post some links to devices (routers) powered by QoriQ CPUs.

You dont know what you are talking about, do you ?
You said earlier "I don't know about SPARC" but now you know that  there is nothing in it, making it unsuitable for low power usages ?
Of course you can use it for low power usage, but it's not the best choice because they are more concerned in throughput and extreme power usage.

Why x86 ISA is not good for low power usages ? Because if I m following you, nothing prevents you in using it in low power devices. And you will be right, but it will use more power, so in the end ARM is better.
Let me explain you why: x86 instruction can go from 1 to 14 bytes long and can take multiple cycle to execute. In the other hand ARM instruction are much simpler with only one to 2 words long.
So ARM has a huge advantage. So you cannot say ISA doesn't matter.

Regarding POWER, as I said I dont know about it, but here is what said NXP about it:
"Currently, we offer ARM products for Mid-performance and Low-power networking product segments, Power-based solutions for High-performance networking segment."
So it seems NXP doesnt think like you.
But if I m wrong and if one day one company can deliever more open CPU based on POWER for embedded devices, I would be happy

there is no 1 SoC fully open source. not a one. reset boot ROM code, GPUs, Wifi/BT chips, baseband processors running its entire OS inside, firmwares inside SD cards, eMMC modules, SSDs, HDDs etc. and there will never be. but it's so easy to make gullible fans believe in some freedom, just repeat often the "we are free" mantra and it's done. no matter, the resulting SoC will have dozens of non-free "blobs". finally, for what the reasons end users might want that a CPU would be open sourced? what would they do with those hardware design files? they won't be even able to check them out. even if you are a C programmer, that doesn't mean that you will be able to check some 75000 lines of code of a project. it will take many months of learning it, before you start to get what's inside. and here we are talking about hardware design files, that only a bunch of people could understand. why end users would need them? for me it's moronic openness, a much better one is when a vendor releases a good documetation on its product, so that people wishing to provide their software for it, could do that. it's much more imporant. secrets, that need to be kept secretive, will be kept that way, because no sane owner of them would sacrifice their profitability to some illusional religion of everything needed to be open sourced.

ouch ... lots of blabla for nothing.
I agree with you on something: FOR YOU Linux is useless. It's free but you may need blob to run your wifi drver, and you dont understand C, and there is millions of line of code.
So I can understand that you are happy with windows
But you should understand that other guys have ability to read/modify/write in linux kernel. And no, if you need an improvement in the XXX mouse device driver, you dont have to read all the million of code. But if you dont know that, you may start reading some file system code ....

One more thing: If we want more freedom, we do accept to have that step by step.
You can be happy with your linux with blob FW. You may then try to get ride of them in the future by buying as free as possible devices.
Other people wont mind about blob FW and will be happy

It's the same for RISC-V. It's one step towards openness. You dont care, but other guys do

[z4v4l]

When i said, "i don't know about SPARC", I meant not knowing of whether it's used in embedded or not. once I even learnt SPARC assembly and remember something about it. anyway, your arguments about SPARC/POWER/x86 being not suitable for low power usage aren't convincing. at least to say. and variable length instructions... come on, if you think this is the reason x86 takes more power, then you have no idea what you are talking about. stop it, don't ashame yourself. the router with the PowerPC CPU i talked about is a ten ports (i guess) with a dual core CPU, running at 500MHz with the half of gigabyte of RAM thing. is it "high end" network appliance or more SOHO one? I cannot  use normal computer now to throw the link at you. it's something mikrotik. hell, this uboot thing started as a linux loader for freescale PPC mobile processors. there was a lot of them. but you may keep arguing about those architectures being not suitable. after all, now when we know variable length of instructions on x86 is the reason of the latter being power hungry, who knows what else fantastic stories you can tell. what do we, stupid windows users, understand in such a thin matter.
next, I talked about an example of a big software project written in C to demonstrate, that openness doesn't guarantee, everybody is able, in a timely manner to evaluate it, to review, understand, fix, improve. it's illusion. foreign code is as foreign language, it takes a lot of time to understand it. more security is illusion, and those infamous bugs in bash, that were lying in front of millions eyes, from the very beginning, from the 80ths, are a good example. they were fixed only in 17, after exploits appear. I wanted to demonstrate it, for comparing with CPU files (written in a hardware design language), that the latter is even more of problem to grasp outside of the team developed it. not for you to start silly and stereotypical story of how linux fans all are modifying linux code all the time and windows users apparently are dumb blondes only able to click mouse in response. yeah, wright. of course, you know linux source code. I bet, if I open any file from the source code of it and ask what this thing is about, you would fail after a few minutes of hopeless staring at it. you see, the fact, that you recompile that linux 100 times per year doesn't make you a linux kernel developer. and even among them ones know their field and have no idea about other parts. and you do realize, I hope, that publishing code of CPU in no way prevents one from inserting some "goodies", not covered by the published code? do you? you just can't "compile" your own in a garage and use it safely. you can't check the CPU code, because it's possible only in theory, in reality, you will need years to get it, but even if you have checked it out and ensured everything is all right, nobody is threatening your freedom, still, you won't be able to recreate this thing. it's not being made on a 3D printer. you will need to have in addition an open source silicon manufacturer. this is all about the hype. why it's so pointless and nonsensical.

and of course, that RISC-V might be cheaper only if it is crappier than ARM. because the work needed to have been put there for the product to be in line with existing, competing products cannot appear magically, it needs engineers and they need to pay their bills, you get the idea? they need to earn money for their work. that's why your open schmopen thing is gonna suck compared to corporate product or be just a vaporware, which RISC-V is so far.

in sum, you don't know about any benefits of RISC-V, apart from the very questionable and mostly religious - opensourceness. and even with that you chose to pretend not noticing my argument about practical impossibility of fully open source SoC, your beautiful story falls apart, so you resorted to repeating your mantras about how opensource is important for you and how windows users are stupid. but the thing is - none SoC vendor ever will produce open source SoC. and the reason is not willing to abuse your or my privacy or endanger freedom they just have competitors and don't want that their hardwork was blatantly stolen by them. look, red hat polishes their linux, makes it suitable for enterprise usage, which is apparently not an easy task. and then oracle shows up and makes a rip off of RHEL, calls it pathetically unbreakable linux and takes advantage of this for in expense of the red hat work. very fair. but at least red hat knew what they go with. these hardware vendors, making for example GPUs, having profit from their hardwork, they never will open their HW design for some smartasses stealing it, it would be suicide.

[lfen]

When i said, "i don't know about SPARC", I meant not knowing of whether it's used in embedded or not. once I even learnt SPARC assembly and remember something about it. anyway, your arguments about SPARC/POWER/x86 being not suitable for low power usage aren't convincing. at least to say. and variable length instructions... come on, if you think this is the reason x86 takes more power, then you have no idea what you are talking about. stop it, don't ashame yourself. the router with the PowerPC CPU i talked about is a ten ports (i guess) with a dual core CPU, running at 500MHz with the half of gigabyte of RAM thing. is it "high end" network appliance or more SOHO one? I cannot  use normal computer now to throw the link at you. it's something mikrotik. hell, this uboot thing started as a linux loader for freescale PPC mobile processors. there was a lot of them. but you may keep arguing about those architectures being not suitable. after all, now when we know variable length of instructions on x86 is the reason of the latter being power hungry, who knows what else fantastic stories you can tell. what do we, stupid windows users, understand in such a thin matter.
next, I talked about an example of a big software project written in C to demonstrate, that openness doesn't guarantee, everybody is able, in a timely manner to evaluate it, to review, understand, fix, improve. it's illusion. foreign code is as foreign language, it takes a lot of time to understand it. more security is illusion, and those infamous bugs in bash, that were lying in front of millions eyes, from the very beginning, from the 80ths, are a good example. they were fixed only in 17, after exploits appear. I wanted to demonstrate it, for comparing with CPU files (written in a hardware design language), that the latter is even more of problem to grasp outside of the team developed it. not for you to start silly and stereotypical story of how linux fans all are modifying linux code all the time and windows users apparently are dumb blondes only able to click mouse in response. yeah, wright. of course, you know linux source code. I bet, if I open any file from the source code of it and ask what this thing is about, you would fail after a few minutes of hopeless staring at it. you see, the fact, that you recompile that linux 100 times per year doesn't make you a linux kernel developer. and even among them ones know their field and have no idea about other parts. and you do realize, I hope, that publishing code of CPU in no way prevents one from inserting some "goodies", not covered by the published code? do you? you just can't "compile" your own in a garage and use it safely. you can't check the CPU code, because it's possible only in theory, in reality, you will need years to get it, but even if you have checked it out and ensured everything is all right, nobody is threatening your freedom, still, you won't be able to recreate this thing. it's not being made on a 3D printer. you will need to have in addition an open source silicon manufacturer. this is all about the hype. why it's so pointless and nonsensical.

and of course, that RISC-V might be cheaper only if it is crappier than ARM. because the work needed to have been put there for the product to be in line with existing, competing products cannot appear magically, it needs engineers and they need to pay their bills, you get the idea? they need to earn money for their work. that's why your open schmopen thing is gonna suck compared to corporate product or be just a vaporware, which RISC-V is so far.

in sum, you don't know about any benefits of RISC-V, apart from the very questionable and mostly religious - opensourceness. and even with that you chose to pretend not noticing my argument about practical impossibility of fully open source SoC, your beautiful story falls apart, so you resorted to repeating your mantras about how opensource is important for you and how windows users are stupid. but the thing is - none SoC vendor ever will produce open source SoC. and the reason is not willing to abuse your or my privacy or endanger freedom they just have competitors and don't want that their hardwork was blatantly stolen by them. look, red hat polishes their linux, makes it suitable for enterprise usage, which is apparently not an easy task. and then oracle shows up and makes a rip off of RHEL, calls it pathetically unbreakable linux and takes advantage of this for in expense of the red hat work. very fair. but at least red hat knew what they go with. these hardware vendors, making for example GPUs, having profit from their hardwork, they never will open their HW design for some smartasses stealing it, it would be suicide.

If your x86 CPU need more cycle to execute an instruction than an ARM CPU, then this means your x86 CPU will indeed require more energy.
If you cannot understand that, then I can't help you. 
By the way, you remind me Ballmer who was calling Linux a cancer. By creating free software you destroy computer engineer job ...

Be open, accept that people may think differently than you. 
Also accept that some people do know kernel programming. (if you dont believe me, then at least you should understand that other guys do know that). 
If you dont have the knowledge of something then you cannot make the deduction that nobody have this knowledge. Even if you are "smart" because you already wrote some program in ASM (or visual basic or whatever)

[z4v4l]

if you think, that the variable length of x86 instructions make them run slowly or need more power, then you shouldn't even start that discussion - that shows you really have no idea of that, just read some wikipedia or what. learn how instructions are fetched and compare how many instructions per clock x86 executes and how many of them execute its competitors. hint - instruction length and intsructions per clock speed of execution are not related. and fyi x86 code is more dense than RISC code, its instructions variable length even speeds things up, because more instructions are in the I-cache. and they aren't fetched byte per clock, oh it's ridiculous.

I am open, i just wondered what exactly cool features of RISC-V made you its fan, even before its real appearance. and you talked about everything, even mentioned Ballmer, but you didn't say a thing about those features. which pretty much shows it all.

[lfen]

if you think, that the variable length of x86 instructions make them run slowly or need more power, then you shouldn't even start that discussion - that shows you really have no idea of that, just read some wikipedia or what. learn how instructions are fetched and compare how many instructions per clock x86 executes and how many of them execute its competitors. hint - instruction length and intsructions per clock speed of execution are not related. and fyi x86 code is more dense than RISC code, its instructions variable length even speeds things up, because more instructions are in the I-cache. and they aren't fetched byte per clock, oh it's ridiculous.

I am open, i just wondered what exactly cool features of RISC-V made you its fan, even before its real appearance. and you talked about everything, even mentioned Ballmer, but you didn't say a thing about those features. which pretty much shows it all.

My god ... you dont get it.
What I was trying to explain you is that x86 ISA is more complex than the one you have in ARM.
And it's also a fact that, on average, x86 CPU instructions requires more cycle to run. This is a fact and not debatable. 
I dont care if you dont agree. (ask yourself why intel has failed on mobile and iot devices)

For the RISC advantage I already told you ... I will repeat for the last time:
- The cost. Especially on IoT devices
- freedom. But forget this one if you cannot even understand why Linux is good
If you want more reason (which are consequences of the 2 1st arguments):
- I think in the future you will see several implementation at lower cost. We can expect good innovation 
- more competition cannot be bad. Maybe that will even put pressure on ARM resulting on good inovation also on ARM side
But this is nothing for you. Not for me.

Will it fail ? We dont know. Let's wait and see.
If we were all thinking like you, we would still have Windows Millennium. 

But I wont continue the discussion further because we keep saying the same things.

again:
You will cut my response as you wish and you will say I'm stupid because blabla x86 is as efficient as ARM and I should document on that, And blabla instruction length. 
I will say you are wrong blabla. You dont know what you are talking about. blabla more clock cycle.
goto again

[z4v4l]

My god ... you dont get it.
What I was trying to explain you is that x86 ISA is more complex than the one you have in ARM.

No, you said, that because x86 instructions are of variable length, their execution takes more power (which is BS). Some excerpts of your nonsense:

Let me explain you why: x86 instruction can go from 1 to 14 bytes long and can take multiple cycle to execute. In the other hand ARM instruction are much simpler with only one to 2 words long.
So ARM has a huge advantage. So you cannot say ISA doesn't matter.

If your x86 CPU need more cycle to execute an instruction than an ARM CPU, then this means your x86 CPU will indeed require more energy.

Below quotes show you have zero understanding on what you are trying to talk about. I suggested you to stop that, but you are persistent in your wish to show your ignorance. Instructions on any architectures can take more, than 1 cycle to execute. this depends on many factors, the CPU has zero influence on, the most noticeable example is load/store instructions accessing external memory. the length of instructions hardly makes difference on the speed of execution - instructions are fetched from the I-cache in multiple per cycle. and I've said, ironically, but this ancient x86 CISC variable length approach resulted in better cache usage - instructions turned to be more compact, so less cache misses, less latencies.

And it's also a fact that, on average, x86 CPU instructions requires more cycle to run. This is a fact and not debatable.
I dont care if you dont agree. (ask yourself why intel has failed on mobile and iot devices)

No, the facts are totally opposite. ARM yet isn't near to x86 in terms of instructions per cycle speed. Only the newest, upcoming Cortexes (77 and forward) are promised to get closer, somewhat, to some x86 CPUs in these terms.
Again, it's a wasteful talk, because you failed to make some googling on the subject before trying to prove something and keep telling nonsense. Here, let me google for you, - two articles, describing new thingies from Intel and ARM - 1, 2. Notice the diagram in the second article, - so far ARM CPUs aren't comparable by speed with x86. That picture is from ARM and they compare with U series, still they can't draw it the way you did - claiming ARM outperforms "undebatable" in terms of IPC. And truthfulness of the picture is yet to be seen. Intel as we see, isn't sitting and waiting. ARM CPUs shine in power saving, but it comes in expense of lower frequency and simpler internal design, with the latter resulting in the ARM lag in terms of IPC speed. IPC depends on the level of how sophisticated is the internal design of the processor, a so called "microarchitecture". Just read (the first article) how insanely complex it is in the upcoming Ice Lake x86 CPUs. It's state of the art and everybody is catching up. This is what is "not debatable".
Let's put it simple - if an ARM CPU executed more IPC, than the x86 counterpart, running at the same frequency, then it would outperform the latter in tests. You know what, it doesn't. an x86 CPU from 2008, something like Core 2 Quad Q6600 x4 at 2.4GHz still will blow away any current ARM quad core CPU running at the same frequency. It does this even having twice as less general purpose registers - which results in more often accesses to memory - a much slower operation. still x86 CPUs from decade ago outperfrom current ARM counterparts. And everybody knows this. Do you know this? No? then go and test. Until you have tests showing otherwise, don't say a word, because I can grab any test comparison from the web, showing how yet ARM lags behind x86. in terms of IPC includingly.
I am an ARM fan, I am an x86 fan, I don't care about opensource religion, I enjoy technology. I would be interested in that RISC-V thing as well, should it be something more than a tiresome advertizement by random dudes on forums talking about the same and only illusional "advantage" - open source. Just let's not say what we want but what isn't nearly the truth and everything will be OK.

[Arwen]

Ignoring the warm / heated discussion, here are my comments;

My first NAS used a single core SPARCv8, (aka 32 bit), somewhat embedded processor running Linux, (Infrant ReadyNAS 1000s).
The SPARC T1 can be used embedded, just select the number of cores and number of threads per core needed. It's designed to
be upto 8 cores, with upto 4 threads per core, (for 32 threads). Of course, the SPARC T1 is dated, it's just one of the first multi-threaded
OpenSource processors released.

Or you could take the Epson PhotoPC 500 camera. It was my first and only digital camera, the rest were multi-function devices like Android tablets or phones. If I remember correctly, the PhotoPC 500 used a SPARC processor.

Stock PCs, and any PC compatible hardware, (embedded or not), will have legacy things that would not be needed on a new design.


RISC-V has certain advantages over older designs. The "thumb" instructions, (using ARM terminology for compressed / shorter / limited
instructions), on RISC-V can be mixed with regular instructions. Even to the point of having the compiler or assembler prefer them over their
regular counterparts! This is because these "thumb", (RISC-V uses compressed wording), are reserved in the overall instruction bit map.

Further, if a CPU designer does not need a specific set of instructions, like floating point, they can be left off. Or new instructions implemented
for specialized designs. I would personally like checksum, compression & encryption instructions that OpenZFS uses, added for a NAS
processor.

Today, most laptops or desktops are 64 bit to allow for larger than 4GB of memory. But, the old Intel designed arch. requires 16 bit & 32 bit
backward compatibility. We all know what happened when Intel tried to force 64 bit only CPUs on us, they sank like the Titanic, (which is why
a common name for the Itanium is Itanic).

That happened about 20 years ago. Now we have much more tools available, (both software & hardware), so a brand new CPU type, like
RISC-V64GC, can be made completely open, but still very usable. That means we can try and avoid the Intel security Tax on performance,
(Meltdown, TLBleed, ForeShadow and the ever popular Spectre).


What I would like to see is an open sourced CPU, (like the RISC-V), made for desktops and laptops, that anyone can view the source code.
Perhaps only a tiny percent of the people who view the CPU source code would understand it. But, hundreds if not thousands of people
could make comments and potentially drive improvements. I've seen, (and been a very light weight submitter to), OpenSource sofware
that has hundreds of participants. Some are core developers, others, (again like me), were just fringe assistants.

All that said, I have hopes for a RISC-V desktop of reasonable price / performance, (or laptop). But I don't see it happening for another 2
years at a minimum.

Edit: Forgot to mention Epson PhotoPC 500 which uses embedded SPARC processor

[jack1]

I never understood this hype about RISC-V...

Risc is not great, its arm that has a problem.
Arm seems to follow the unwritten law "soc without cellular modem and linux support OR soc with cellular modem and no linux"
plus license restrictions... closed source drivers... arm is simply not... ok

[kaylios]

You want a CPU with 4G/wifi modem in it ? What is the benefit ? Energies consumption ?
But I agree that the restrictions on ARM is not good. But ARM SOC are currently the best SOC we currently have for embedded stuffs.

[Paraplegic Racehorse]

Well, maybe you need to wait a year or three. Looks like Huawei is investigating RISC-V processors...

https://bit-tech.net/news/tech/cpus/huaw...embargo/1/

Sent from my moto x4 using Tapatalk