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

31–40 of 155 posts

Re: Debian riscv64

#31

Post by sanxiyn »

erik_seaberg wrote: post #30
sanxiyn wrote: post #17

Earlier quoted context omitted.

> Check for feature presence That is the hard part. On Intel you can use CPUID, but it is ARM policy to not expose such instructions. You can read /proc/cpuinfo, but that is Linux-specific. Edit: there is a reason for ARM policy: CPUID is a well known virtualization hazard. In fact, KVM immediately traps if you execute CPUID on guest. ARM made a good decision here. Still, it means things can't work exactly like it wo…

https://news.ycombinator.com/item?id=18542040 talks about registers with a similar purpose.

Only in EL1, which means you can only use them in kernel.

Re: Debian riscv64

#32

Post by tw1984 »

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.

Re: Debian riscv64

#33

Post by snvzz »

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

Re: Debian riscv64

#34

Post by pjmlp »

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.

Re: Debian riscv64

#35

Post by KingLancelot »

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

Microsoft, Intel, AMD, NVIDIA.

Only one I didn’t see was Apple, hell even Raspberry Pi is there.

Re: Debian riscv64

#36

Post by KingLancelot »

lmm wrote: post #21
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?

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.

[dead]

Re: Debian riscv64

#37

Post by swagmoney1606 »

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.

Still a step in the right direction.

Re: Debian riscv64

#40

Post by IntelMiner »

cmeacham98 wrote: post #15
viraptor wrote: post #13

Earlier quoted context omitted.

Would anything prevent compilers from approaching it like SSE on Intel? Check for feature presence and enable the appropriate path (if using compiler-generated code).

Debian distributes compiled binaries. Thus, they have to either turn processor features on in all their binaries, or off (or distribute two sets of binaries).

You're thinking of optimizing the code for a specific processor. Run-time codepaths that detect CPU features have existed since MMX and SSE
Post reply on HN