[HN Gopher] GNU toolchain for RISC-V including GCC
___________________________________________________________________
GNU toolchain for RISC-V including GCC
Author : teleforce
Score : 166 points
Date : 2023-04-14 02:36 UTC (20 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| sakras wrote:
| Can anyone in the know explain the significance of this
| toolchain? Haven't we been able to compile for RISC-V for years
| now? At the very least I was doing it ~4 years ago for my
| undergrad research
| bayindirh wrote:
| Having a completely Free and Open Source toolchain for a CPU
| architecture is a great thing to have, which means one can
| develop tools and other layers on top of it which can be Free
| and Open Source as well.
|
| Many processors and platforms die because of lack of GNU
| licensed tools if they fail to be adopted by a critical mass or
| the developer of the platform doesn't feel like supporting it
| anymore (Radxa Rock comes into my mind).
|
| So, having an unencumbered and free toolchain ensures that the
| platform can live on no-matter-what. It's very valuable in my
| eyes because of that.
| riceart wrote:
| I think the person you're replying to likely knows all this?
| But thanks, I guess -- people doing architecture or compiler
| research likely don't need an explanation of the benefits of
| an open source compiler, especially for RISC-V. In case you
| are not aware - RISC-V support was added to gcc years ago (I
| believe it was the first major C compiler targeting it), so
| the question is what is the significance of this particular
| repo (hardly unique as far as packaged scripts go - it seems
| to just pull in the various upstream components as
| submodules) being posted now. I sort of have the same
| question.
| bayindirh wrote:
| While I know what RISC-V is, and how it's unique among its
| peers, I'm not very knowledgeable about which toolchain
| provides which level of support for it.
|
| So, IOW, I wasn't aware the level of support present in
| RISC-V in GCC, TIL.
|
| Asnwering your question, the README.md vaguely tells me
| that it provides a single-step, complete cross compilation
| toolchain to reduce project startup overheads. I consider
| this repo as an "exploded container" designed to be
| deployed in a VM to put your code in and get your binaries
| out. I guess the whole chain is composed of GNUs own tools,
| or with GPL licensed stuff, so it's not encumbered by
| anything, or broken by a tool because "we now provide this
| support in our closed source fork" situations.
| riceart wrote:
| The support in gcc and clang for RISC-V is so mature at
| this point that there are binaries and ports in
| distributions like Debian, arch, and windows (Msys),
| *BSD. It would probably be more convenient and
| reproducible to start with those.
|
| > I consider this repo as an "exploded container"
| designed to be deployed in a VM to put your code in and
| get your binaries out.
|
| Only after compiling the whole thing. And it's not like
| this does anything special to enforce reproducibility.
|
| On that note there are preexisting docker containers.
| bayindirh wrote:
| Considering this repository started its life in 2014,
| maybe here's the place where all started, and helped
| incubating said containers and distro support over the
| years?
|
| Considering it has 858 forks incl. by corporations like
| WD Semi and SiFive, I think I'm not too far off in my
| guess.
| riceart wrote:
| No. gcc and clang development do not occur on github and
| likely never will. Gcc didn't even use git until
| relatively recently (not in 2014). You can go look up the
| mailing list archives - this repo predates nothing.
|
| > helped incubating said containers and distro support
| over the years?
|
| Tool chain build scripts for gcc and clang have existed
| for as nearly as long as the respective projects have
| been around - which in the case of gcc is over 30 years.
|
| Also see https://crosstool-ng.github.io/
|
| Distros like Debian have been packaging cross compilers
| for decades with their own tooling, long before 2014.
| MSYS has existed for I can't remember (long before 2014).
|
| As someone below said - this is a "very solved problem".
|
| Not that this repo isn't useful - but I think posted here
| out of context clearly it is conveying the impression
| that it is bringing something novel to RISC-V which isn't
| the case.
| stffrdhrn wrote:
| I think what is nice about this project is that it combines
| everything in a mono repo which is nice for setting up
| continuous integration and other testing workflows. This
| project can be used to build toolchains for newlib (bare
| metal), musl and glibc. It also will allow building qemu and
| spike (instruction simulation) simulators to allow running
| RISC-V code without special hardware. It can then run each
| project's test suites as well as it has some integration tests
| (dhrystone).
|
| This repo will be useful for getting started with toolchain
| development. If you are just a user wanting to write c/c++ app
| code then use your distro's toolchain packages.
| snvzz wrote:
| This is just a guess, but perhaps this is just someone who's
| written a script to easily set up a crossdev toolchain.
|
| ... which is indeed a very solved problem. Most distributions
| have RISC-V toolchains packaged and readily available.
| MobiusHorizons wrote:
| you don't even need a dedicated cross compiler if you have
| clang installed (eg the standard clang you can install from
| homebrew, or the one shipped with freebsd). you just have to
| pass it a few flags to target risc v. `clang --target=riscv32
| -march=rv32i -mabi=ilp32`
| snvzz wrote:
| Yes, and I have done this.
|
| I love llvm/clang.
| chungy wrote:
| It is odd. It's trivially installable on Debian from any host
| architecture, even.
| nine_k wrote:
| Was the previous toolchain all under GPL? This might be the
| significant change.
| Gigachad wrote:
| Unless the existing one was proprietary, wouldn't this be no
| change at all since an MIT toolchain gives you everything GPL
| gives + more.
| zen_1 wrote:
| This is still GCC, so it's guaranteed to be under the GPL
| chatmasta wrote:
| I'm guessing this was posted because RISC-V SBCs are starting
| to ship, with VisionFive2 and Pine64 recently announcing
| availability of their boards (although I haven't seen the one
| from Pine64 in stock yet). Especially with the RaspberryPi
| shortage, I expect that as RISC-V gains software stability,
| these boards will start to fill the SBC niche.
|
| Meanwhile, institutions like NASA [0] and the EU [1] are making
| big investments in the architecture. You can sense the hype by
| looking at the top submissions in r/riscv [2] from the past
| year.
|
| I think this architecture is very promising. I'm excited for
| the ecosystem to mature.
|
| [0] https://www.techspot.com/news/95911-sifive-risc-v-cores-
| micr...
|
| [1] https://www.hpcwire.com/2022/12/16/europe-to-dish-
| out-e270-m...
|
| [2] https://old.reddit.com/r/RISCV/top/?sort=top&t=year
| shash wrote:
| Isn't this the one everyone is using currently? What's new here?
| sylware wrote:
| I don't really get the point of this toolchain. Isn't risc-v
| support already in the binutils and gcc?
|
| That said, on risc-v, gcc is mostly for legacy code as risc-v, a
| standard modern ISA free from toxic IP and that worldwide, is the
| signal of the start the assembly era. At best expect very high-
| level language interpreters
| (python/lua/ruby/javascript//whatever) to have a risc-v assembly
| written implementations.
| bayindirh wrote:
| That repo is 8 years old. It's probably why RISC-V support is
| already there.
| sylware wrote:
| good catch.
| ddevault wrote:
| GCC has had upstream support for RISC-V for ages, and your
| typical cross or native GNU toolchain (via your distros or
| otherwise) supports it.
___________________________________________________________________
(page generated 2023-04-14 23:02 UTC)