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.
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.
ANT - my hobby OS for x86 and ARM.