Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian riscv64

blog.aurel32.net

Post reply on HN
Print view View original

71–80 of 155 posts

Re: Debian riscv64

#71

Post by panick21_ »

pjmlp wrote: post #39
swagmoney1606 wrote: post #37

Earlier quoted context omitted.

Still a step in the right direction.

A path already trailed by OpenSPARC and PowerPC.

No it isn't. PowerPC was never free. I think you mean OpenPOWER. Again that was just marketing, it wasn't free in anyway. Only the pressure of RISC-V lead to POWER and MIPS becoming more free over time.

And even if OpenSPARC had a open spec, but was only for 32bit. The 64 bit version would never become a standard. You need more then air dropping a spec. You need people to continue to push it forward and evolve it. You need to build a community around a standard. Sun simply wasn't interested in doing that, they just made a spec and left it there.

OpenSPARC had some success, being used for space by ESA for example. But it didn't get adoption in education. The venders of embedded chips were not interest. But the time was just not ready, the OpenSource ecosystem wasn't ready and the publisher (Sun) didn't care about embedded. The seperation between chip makers and fabs had not fully happened yet.

Saying that RISC-V is like POWER is just fundamentally false.

Saying RISC-V is like SPARC 32-bit is slightly more correct, but misses a whole lot context that is non-technical.

Yes we should give Sun credit for what they did with SPARC. But RISC-V is quite a different thing.

Re: Debian riscv64

#73

Post by ur-whale »

LatticeAnimal wrote: post #3

I don't fully understand riscv, but shouldn't this be something like `RV64GC`? Are they building for the base riscv with no isa extensions? This might be addressed somewhere in the debian docs but I didn't see it.

If there is a downfall of RISCV, it's going to be the myriad of sub-architectures and their weird naming schemes, with an added layer of marketing drones muddying up the waters even further.

This is going to confuse the hell out of the potential customer base and it would be a crying shame, wasting a golden opportunity to get out of the oxygen-choking clutches of proprietary ISA vendors (who at this point are purely rent-seeking and add exactly zero actual economic value to the ecosystem).

Re: Debian riscv64

#74

Post by panick21_ »

pjmlp wrote: post #34
tw1984 wrote: post #32

a true milestone! hope it is also the beginning of the end - ISA shouldn't be some tightly controlled assets managed by some lawyers and CXOs, companies shouldn't be sued for just trying to invest into certain ecosystems.

RISC V is not extension free, and a CPU is meaningless without a, most likely, proprietary board.

OpenSource boards have been a thing for far longer then open SoCs. So of course most of the board in the world will be proprietary and that fine. But open boards has been possible for a while, and the open source tools to do that are fairly good.

RISC-V makes it possible to have Open CPU or even OpenSOC on an OpenBoard. That basically wasn't even possible before. We are even getting to a point where there are open PDKs. There are libraries of analog IPs that are open. Now that there are lots of options for OpenCpu people are going after the missing stuff. Open Ethernet PHI and so on. There is also now a big movement in regard to making the tooling open source to compete with commercial tooling. OpenROAD, OpenLane, Verilator and so on.

The benefits of this are amazing. Project like Core-V, OpenTitan and so on simply wouldn't have happened.

You have things like RISC-V International, the Chips Alliance, LowRisc, Google and many others working on all aspects to make a fully open ecosystem possible.

But that doesn't change the fact that most SoC and most board in the world will be property, RISC-V or no RISC-V.

> RISC V is not extension free

Not sure what this means. Exertions are part of RISC-V. The waste majority of extensions used in the real world are all part of the same standard put forward by RISC-V International.

Most of the non-standard extensions came about before there was a standard for them, and most are converging to the standard pretty fast.

Re: Debian riscv64

#75

Post by bregma »

totetsu wrote: post #51
lmm wrote: post #21

Earlier quoted context omitted.

Well-written applications will just work. Badly-written applications may require patches or be impractical to build at all, and some system software may not make sense on the architecture at all. There's a whole lot of build infrastructure for Debian; by default the package maintainer doesn't need to do anything specific, building for all architectures will happen by default.

What kind of assumptions would badly-written applications make to make themselves impractical to cross-build?

Othar than word size (eg. i386 vs. x86_64), endianness (eg. PPC vs. x86), alignment (eg. ARM vs. x86) there's plenty of other low-level issues like parameter passing conventions, call frame handling, exception handling, presence or absence of optional instructions or registers, and a number of other subtle gotchas that could affect a port. Instruction probing is one of the ones we run into where everything builds find and fails at runtime.

If you're working at a high enough level you're probably fine. Like the difference between being an auto mechanic and using the app to hail a ride.

Re: Debian riscv64

#76

Post by pjmlp »

Pet_Ant wrote: post #60
pjmlp wrote: post #50

Earlier quoted context omitted.

OpenPOWER Foundation exists since 2013. SPARC is quite alive for Solaris customers, and there are still plenty of them. Regardless, it doesn't change the fact that they were there first. Anyone that thinks basic ISA being open source, will prevent extensions, proprietary boards or boot firmware are fooling themselves. Sure, it may do for a couple of maker community projects, Arduino style, and that is about it.

> SPARC is quite alive for Solaris customers Fujitsu has announced plans to transition away from SPARC by 2030. Oracle has laid off their staff, after the M8 in 2017. ( https://en.m.wikipedia.org/wiki/SPARC ) If SPARC isn’t dead, then it’s in palliative care, and not far behind Itanium. Shame because SPARC T series was interesting and I wonder what it would look like today at modern geometries and using chiplets.

May be, it is still being sold, and doesn't have anything to do with the point of being there first.

Re: Debian riscv64

#77

Post by pjmlp »

panick21_ wrote: post #71
pjmlp wrote: post #39

Earlier quoted context omitted.

A path already trailed by OpenSPARC and PowerPC.

No it isn't. PowerPC was never free. I think you mean OpenPOWER. Again that was just marketing, it wasn't free in anyway. Only the pressure of RISC-V lead to POWER and MIPS becoming more free over time. And even if OpenSPARC had a open spec, but was only for 32bit. The 64 bit version would never become a standard. You need more then air dropping a spec. You need people to continue to push it forward and evolve it. Yo…

Until we get a RISC V computer on Media Markt being sold to average joe/jane, FOSS everything, it is going to be hardly any different.

Re: Debian riscv64

#78

Post by zokula »

snvzz wrote: post #33
tw1984 wrote: post #32

a true milestone! hope it is also the beginning of the end - ISA shouldn't be some tightly controlled assets managed by some lawyers and CXOs, companies shouldn't be sued for just trying to invest into certain ecosystems.

The proprietary ISA ship has long sailed[0]. RISC-V is inevitable[1]. 0. https://riscv.org/members/ 1. https://www.youtube.com/watch?v=ktjSvlelKPk

[dead]

Re: Debian riscv64

#79

Post by sylware »

This is the mechanical progression for risc-v: legacy support.

The real future is riscv64 assembly written software with a very conservative usage of a preprocessor (or we will end up with c++ syntax grade preprocessing), and software written with very high level languages which interpreters are written in riscv64 assembly with a very conservative usage of a preprocessor (python? javascript? etc). That because risc-v is meant to be the CPU ISA standard.

I really hope risc-v will be a success.

Re: Debian riscv64

#80

Post by planede »

sohrob wrote: post #16

When Debian is ported to a new architecture does that mean something special needs to happen to all of the packages in the repository for them to work on that new architecture?

Maybe some packages may need special attention, like various language runtimes and browsers that normally do JIT compilation to the target architecture. I guess some of these might work in interpreted mode, but not as efficiently.
Post reply on HN