| View previous topic :: View next topic |
| Author |
Message |
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 488
Location: Salem, OR
|
|
| Back to top |
|
 |
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10655
Location: Somewhere over Atlanta, Georgia
|
 Posted: Thu Aug 21, 2014 3:13 pm Post subject: |
 |
|
Thanks for that link. Interesting. However, even though they state that their architecture will run at greater than 1 GHz on those FPGA boards, the current cores are in-order execution with minimal cache, which likely translates to performance equivalent to a < 400 MHz Pentium, so I don't see it becoming a practical "daily driver" right away.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 488
Location: Salem, OR
|
| Posted: Thu Aug 21, 2014 3:59 pm Post subject: |
|
|
| John R. Graham wrote: | Thanks for that link. Interesting. However, even though they state that their architecture will run at greater than 1 GHz on those FPGA boards, the current cores are in-order execution with minimal cache, which likely translates to performance equivalent to a < 400 MHz Pentium, so I don't see it becoming a practical "daily driver" right away.
- John |
Would that lack of performance be a result of the architecture, itself, or a result of the fact that it runs on a an FPGA board? I read at http://www.lowrisc.org/ that they are hoping to manufacture a run of chips that might sell for $10 in a couple of years. Would such a chip be, in your guess, have the same problems or competitive with what's available to day from AMD or Intel? |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10655
Location: Somewhere over Atlanta, Georgia
|
| Posted: Fri Aug 22, 2014 2:27 am Post subject: |
|
|
Partially because of the architecture. Absolutely positively not competitive with AMD and Intel, for at least three insurmountable (in the near term) reasons:- Clock for clock, CISC provides 2 to 3 x performance vs. RISC.
- AMD and (especially) Intel have access to semiconductor processes that the RISC-V chip makers simply won't have.
- There's a huge amount of additional complexity that helps modern x86 run faster (e.g., out of order execution, branch prediction).
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 488
Location: Salem, OR
|
| Posted: Fri Aug 22, 2014 2:46 pm Post subject: |
|
|
| John R. Graham wrote: | Partially because of the architecture. Absolutely positively not competitive with AMD and Intel, for at least three insurmountable (in the near term) reasons:- Clock for clock, CISC provides 2 to 3 x performance vs. RISC.
- John |
I shared your comments and learned of a paper presented at the 19th IEEE International Symposium on High Performance Computer titled "Architecture Power Struggles: Revisiting the RISC vs. CISC Debate on Contemporary ARM and x86 Architectures" which suggests otherwise:
| Quote: | Our study suggests that whether the ISA is RISC or CISC is irrelevant...
Our study suggests that at performance levels in the range of A8 and higher, RISC/CISC is irrelevant for performance, power, and energy.
Thus, while ISA evolution has been continuous, it has focused on enabling specialization and has been largely agnostic of RISC or CISC.
http://research.cs.wisc.edu/vertical/papers/2013/hpca13-isa-power-struggles.pdf |
I do not mean to be argumentative, but what you have written sounds very damning for RISC-V and with all due respect, I do not want people to read this thread thinking that statement is the final word on the matter. Your statement above seemed particularly compelling, so I wanted to learn more and share what I found. |
|
| Back to top |
|
|
_chris
n00b
Joined: 22 Aug 2014
Posts: 2
|
| Posted: Fri Aug 22, 2014 5:18 pm Post subject: |
|
|
As a RISC-V user, I would like to clarify a few misconceptions in this thread.
| John R. Graham wrote: | | Thanks for that link. Interesting. However, even though they state that their architecture will run at greater than 1 GHz on those FPGA boards, the current cores are in-order execution with minimal cache, which likely translates to performance equivalent to a < 400 MHz Pentium, so I don't see it becoming a practical "daily driver" right away. |
I believe you misunderstood the links. The provided "Rocket" in-order core runs at well over 1 GHz in silicon. For an FPGA, it depends on what you buy, but I've been able to run it at 100 MHz while using 64kB level 1 caches and 256kB level 2 caches using the above zedboard. Just to make life easy for people with really tiny FPGAs, we provided a version with very small caches. But that's just a parameter.
| John R. Graham wrote: | | "Clock for clock, CISC provides 2 to 3 x performance vs. RISC." |
Incorrect. Modern, high performance CISC processors translate CISC instructions into RISC micro-ops. This is almost always a 1:1 conversion (if they want to see any decent performance anyways). As the previously quoted Wisc "ISA Struggles" paper demonstrated, CISC and RISC are fairly equal in performance- certainly not 2-3x.
| John R. Graham wrote: | | "AMD and (especially) Intel have access to semiconductor processes that the RISC-V chip makers simply won't have." |
Intel's main advantage has always been its foundries. But AMD (and pretty much all other processor companies like NVIDIA and Apple) are fabless.
| John R. Graham wrote: | | "There's a huge amount of additional complexity that helps modern x86 run faster (e.g., out of order execution, branch prediction)." |
OoO and branch prediction are micro-architectural implementation details that are completely orthogonal to the ISA. If anything, x86 makes OoO harder than RISC, requiring incredibly complex decoder units that they attempt to turn off for energy and performance reasons when they can (aka, the "run in RISC mode"). There is no reason RISC-V can't utilize the same micro-architectural features to run as fast as modern x86 processors (and in fact, I know of at least IIT Madras building OoO RISC-V cores). Performance will be dependent on the quality of the implementation, not the instruction set architecture.
| John R. Graham wrote: | | I don't see it becoming a practical "daily driver" right away. |
I think the biggest hurdle to Gentoo on RISC-V would be the device driver story (Linux already works, but most system calls are proxied onto something else, like the ARM core attached to the FPGA). I think "lowrisc" is a good group to follow who are working on building exactly what jlpoole wants - an open-source SoC that can run Linux and talk to your devices. |
|
| Back to top |
|
|
lowrisc
n00b
Joined: 23 Aug 2014
Posts: 1
|
| Posted: Sat Aug 23, 2014 5:56 pm Post subject: |
|
|
Hi all,
yes, as Chris notes, the lowRISC team is aiming to create (and sell, in volume) a RISC-V based SoC. We're a not-for-profit organization.
Our (placeholder) website is at www.lowrisc.org (it has a brief FAQ).
We're also hiring right now! Two positions are open based in Cambridge UK (closing date 9 Sep 2014).
Personally, I'm a huge Gentoo fan (and user), so I hope we will see it running on one of our devices some day. 
_________________
Gavin |
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 488
Location: Salem, OR
|
| Posted: Sat Aug 23, 2014 6:40 pm Post subject: |
|
|
Gavin's reputation in the open source world is noteworthy: http://www.gnome.org/news/2013/07/interview-with-gavin-ferris-gnome-privacy-campaign-donor/
In 2007, he started with Ubuntu. As of July 2013 he reconsidered his choice and moved to Gentoo about two years ago, undoubtedly touched by the omniscient one.
I'm pleased to learn of his participation as a principal in this endeavour.
A milestone will be running Gentoo on such a platform and then comparing results from standardized performance tests. It's tempting to try installing Gentoo on a system Zybo or Zedboard (see my prior postings in this thread) just to do a proof-of-concept and have a baseline for performance. Could also compare with my experiences on a Sheeva Plug (1.2GHz Marvell Sheeva CPU), Genesi Efika (Freescale i.MX515 (ARM Cortex-A8 800MHz)), and BeagleBone (AM335x 720MHz ARM® processor) just for kicks. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54577
Location: 56N 3W
|
| Posted: Sat Aug 23, 2014 8:22 pm Post subject: |
|
|
I'll stir the pot a little.
its been a long time since AMD or Intel made anything but a RISC CPU.
The microcode just makes their offerings look like CISC systems.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3426
|
| Posted: Sun Aug 24, 2014 4:49 pm Post subject: |
|
|
| Quote: | its been a long time since AMD or Intel made anything but a RISC CPU.
The microcode just makes their offerings look like CISC systems. |
A bit of "what if" kind of question, but..... Would it be possible to recompile our toys and make them use native architecture rather than have RISC pretend CISC?
Would it give noticable performance boost? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54577
Location: 56N 3W
|
| Posted: Sun Aug 24, 2014 5:04 pm Post subject: |
|
|
szatox,
In theory, you can write your own microcode for you CPU but its a daunting task - even when you know which bit in the microcode does what.
The first thing you need to to is to reverse engineer existing an microcode, which itself may not be correct.
In effect, the microcode builds up CISC instructions from a sequence of RISC instructions.
Being able to do that in the microcode will be faster than the extra RISC instructions since less instructions need to be fetched from RAM.
Of course, if you know how the hardware operates maybe you can optimise the microcode better than AMD/Intel but somehow I doubt you have the time for that.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
_chris
n00b
Joined: 22 Aug 2014
Posts: 2
|
| Posted: Sun Aug 24, 2014 9:32 pm Post subject: |
|
|
| szatox wrote: | | Quote: | its been a long time since AMD or Intel made anything but a RISC CPU.
The microcode just makes their offerings look like CISC systems. |
A bit of "what if" kind of question, but..... Would it be possible to recompile our toys and make them use native architecture rather than have RISC pretend CISC?
Would it give noticable performance boost? |
As NeddySeagoon mentioned, the best you could do is write your own micro-code to govern the x86->RISC uop translation. This has two huge assumptions (which aren't true) - 1) you have the ability to upload your own micro-code and 2) you understand the micro-code.
Unless you are Intel (or the NSA), I don't know of anybody who has the ability to patch micro-code. But let's assume we do...
For performance, most of the x86 instructions are 1:1 to the RISC uops. So there's nothing to gain here. Then there's instructions like string operations, but I bet Intel has put serious development into making those instructions very fast. So I doubt a hacker will do better than Intel.
Of course, if you control the micro-code, you can always add your own x86 instructions that will only run on your own hacked Intel processor. I'm not sure what there is to win here though, especially if you're a RISC person who doesn't believe in heavily micro-coded instructions.
Perhaps what you were really asking is "would there be a performance improvement if we could remove the complicated x86 front-end and direct execute RISC micro-ops with no complicated translation required?" That's a damn good question and the answer is hotly debated. I'll give two answers to that question.
The first is "almost certainly." In fact, high performance x86 processors make use of uop caches to allow them to turn off the x86 fetch and decode front-end, and run "RISC-style" straight out of the uop cache (treating it as a regular RISC L1 instruction cache). This gives Intel significant performance and power savings. So naturally, one would think this would be a win if they could just always get away with it, right?
My second answer is "not really." First, you would need to handle all of the corner cases of executing weird x86 instructions, otherwise you are no longer an x86 processor. So you already need the hardware datapaths for stopping the machine and injecting micro-code. Second, most executed x86 instructions are 1:1 decoded to RISC uops, so they already can basically execute "natively" as is. And this common case datapath is what's on the "critical path" of the machine, allowing it to speculate that it can execute stuff quickly with minimal decode anways. And again, Intel has added uop caches, so they can still stay CISC and get the benefits of RISC, so why bother trying to be "more pure"? Finally, all of the complicated x86 front-end let's them do weird things like micro-op fusion, micro-op cracking, and other such things to get great performance that would match an equivalent RISC machine.
Basically what I'm saying is I suspect CISC and RISC are probably not very different in terms of raw machine performance (although low-power CISC may be very difficult) ... but in terms of ease to build, CISC has got to be a fucking terrible architecture to implement, verify, and debug. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54577
Location: 56N 3W
|
| Posted: Mon Aug 25, 2014 4:39 pm Post subject: |
|
|
_chris,
| _chris wrote: | | ... CISC has got to be a fucking terrible architecture to implement, verify, and debug. |
There is lots of evidence for that. Consider the early AMD x86 CPUs. They didn't have the same bugs an the Intel chips so there were a few nasty corner cases.
As Intel was the defacto standard for x86, it didn't matter that Intel chips did not work as advertised, just that the AMD offering was different.
AMD learned the lesson and copied the Intel bugs too.
I have been in the position of debugging microcode for an in house embedded system.
It gets really hard when you run out of space in the microcode storage area but you need just one more line.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3520
|
| Posted: Tue Feb 19, 2019 11:26 pm Post subject: |
|
|
I just found this rather old thread, and am re-awakening it.
I may well have a need for RISC-V in my day job. I'm looking at something that needs an embedded processor, and I'd like to pick it up off the shelf. Furthermore, due to the nature of the project, I believe I need to fully expose the design and software to the customers, so RISC-V is very handy for that purpose. I might have liked the m6809, from familiarity, code density, and not needing any sort of linking loader or other complex infrastructure, but I also probably need to stay closer to mainstream. For the other stretch, I think it would be good in Rust.
So a quick RISC-V search indicates that there at least is a Gentoo project underway to port to it. Though to be honest, that is completely inappropriate for me, because my use will be embedded - no OS, maybe not even a monitor, just an application, self-test, etc. However it would be best to have a RISC-V ecosystem to work with, get familiar, etc.
To begin, is there a RISC-V emulator somewhere in Gentoo-land? My intent would be to cross-compile, but I'd absolutely need emulation. I'm a long time from even submitting the design, much less seeing hardware. By the way, my usage is ASIC, not fpga.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
pa4wdh
l33t
Joined: 16 Dec 2005
Posts: 882
|
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3520
|
| Posted: Thu Sep 17, 2020 12:21 pm Post subject: |
|
|
Presuming the nVidia purchase of ARM goes through, it wouldn't surprise me to see more live in RISC-V. Safe port in the storm, and all of that. It's not clear that ARM will be safe any more, after the purchase.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
pa4wdh
l33t
Joined: 16 Dec 2005
Posts: 882
|
| Posted: Fri Sep 18, 2020 6:58 am Post subject: |
|
|
The nVidia/ARM deal is worrying indeed.
Yesterday i had my first experiment with QEMU for RISC-V and got a fedora version for RISC-V booting. Since this is all emulated it was very slow, but it worked
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world
My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com |
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 488
Location: Salem, OR
|
|
| Back to top |
|
|
pa4wdh
l33t
Joined: 16 Dec 2005
Posts: 882
|
| Posted: Fri Sep 18, 2020 2:37 pm Post subject: |
|
|
I'm really curious about that hardware ... can't wait for October 
Is there any documentation or tooling to get gentoo going on a new architecture? I guess i'll have to start by cross-compiling a kernel and toolchain and create a stage1 from that.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world
My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com |
|
| Back to top |
|
|
pa4wdh
l33t
Joined: 16 Dec 2005
Posts: 882
|
| Posted: Thu Oct 15, 2020 5:49 pm Post subject: |
|
|
I've been playing with qemu's risc-v emulation a bit and got to the point where i have a working gentoo. I'm sharing my my steps, maybe it helps someone else Feedback and tips are welcome too of course.
Crossdev
We need to cross compile a kernel, so we need a risc-v toolchain. To build that we can use crossdev, so first we need to emerge crossdev.
With crossdev installed we can build a risc-v toolchain: crossdev -S -t riscv64-linux-gnu.
Kernel
Now we have a toolchain we can cross-comile the kernel. Download the most recent one from https://kernel.org and unpack it.
Copy the defconfig for risc-v: cp arch/riscv/configs/defconfig .config
Configure the kernel using make ARCH=riscv menuconfig
I added CONFIG_DRM_BOCHS=y and CONFIG_DRM_CIRRUS_QEMU=y to be able to use qemu's graphical display, the serial console is a bit crappy in my opinion.
Quit menuconfig and save the config.
Now actually build the kernel: make ARCH=riscv CROSS_COMPILE=riscv64-gnu-linux- Image
The finished product will be arch/riscv/boot/Image
Disk image
Now create a disk image using dd, for example: dd of=/dev/zero of=disk.img bs=1024k count=2k which will create a 2GB file
Format it: mkfs.ext2 disk.img
Mount the disk image: mount disk.img <some mountpoint>
Download a stage3 tarball here: https://dev.gentoo.org/~dilfridge/stages/
Extract the stage3 tarball in the mountpoint.
Edit etc/inittab and:
- Enable the "s0" line to enable the serial console if yuu want
- Find the line with s0 (serial) or c1 (console) and add -a root to agetty's parameters. This will auto-login root, this is needed because root doesn't have a password yet.
Add the disk to fstab:
/dev/vda / ext2 noatime 0 1 >> etc/fstab (be careful, not /etc/fstab )
Umount the image
Qemu
Make sure to set QEMU_SOFTMMU_TARGETS="riscv64" in make.conf and emerge qemu
When that's done, boot your risc-v gentoo with:
| Code: |
qemu-system-riscv64 -machine virt -smp 2 -m 2G \
-bios /usr/share/qemu/opensbi-riscv64-virt-fw_jump.bin \
-kernel <Path to your cross compiled Image> \
-append "root=/dev/vda net.ifnames=0 console=tty0 ip=dhcp" \
-usb \
-device nec-usb-xhci,id=xhci \
-device usb-kbd,bus=xhci.0 \
-device bochs-display,xres=640,yres=480 \
-device virtio-blk-device,drive=hd0 \
-drive file=<path to disk.img>,format=raw,id=hd0 \
-netdev user,id=net0 -device e1000e,netdev=net0 \
|
Once booted (be patient, on my system this takes a few minutes) root will be logged in automatically. Give root a password with the passwd command and remove the autologin from /etc/inittab.
Now you can finish your install as you would do after chrooting into your new install.
Enjoy!
Edit:
Added root autologin to work around not having a root password at first boot, added ip=dhcp to -append line.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world
My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com
Last edited by pa4wdh on Sun Oct 18, 2020 11:16 am; edited 1 time in total |
|
| Back to top |
|
|
pa4wdh
l33t
Joined: 16 Dec 2005
Posts: 882
|
| Posted: Fri Oct 16, 2020 5:34 pm Post subject: |
|
|
To get networking going you'll need DHCP. Because there is no dhcp client in the stage3 you'll have to add "ip=dhcp" to the -append line. The kernel will take care of setting up the interface and routing. You'll have to setup the DNS yourself in /etc/resolv.conf.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world
My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com |
|
| Back to top |
|
|
pa4wdh
l33t
Joined: 16 Dec 2005
Posts: 882
|
| Posted: Thu Oct 29, 2020 9:20 pm Post subject: |
|
|
Today some more info about the Risc-V PC was revealed:
https://www.sifive.com/blog/the-heart-of-risc-v-development-is-unmatched
Specs look nice, price it a bit higher compared to standard hardware. It doesn't contain video hardware, so GPU with good open source drivers is required. Any ideas? "Good open source drivers" rules out most nVidia and AMD cards s far as I know
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world
My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com |
|
| Back to top |
|
|
JustAnother
Apprentice
Joined: 23 Sep 2016
Posts: 191
|
| Posted: Sun Jan 03, 2021 10:01 pm Post subject: |
|
|
I was looking at this page:
https://www.sifive.com/boards/hifive-unmatched
They said $665, which is a bit steep for a new toy, but hey, it's a neat one.
Would anybody care to make a guess as to how (and why) the price of these boards will evolve over time? They need to get the price down to about $300 to get some real volume. This technology could be a game changer later on. Who knows? |
|
| Back to top |
|
|
pa4wdh
l33t
Joined: 16 Dec 2005
Posts: 882
|
| Posted: Mon Jan 04, 2021 7:23 am Post subject: |
|
|
Since it's brand new (it's still on pre-order now, expected to be available in a few weeks) and the volume is low, i don't expect prices to go down anytime soon.
If you want a cheaper alternative take a look at the PicoRio, it's a Raspberry-Pi formfactor RISC-V board. It's still in development, so it will take some time before it's available, but it'll be (a lot) cheaper.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world
My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com |
|
| Back to top |
|
|
pa4wdh
l33t
Joined: 16 Dec 2005
Posts: 882
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on Alternative Architectures
