#riscv64 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #riscv64, aggregated by home.social.
-
The irony: the entire RISC-V base ISA (RV64GC) is beautifully RISC: simple opcodes, fixed 32-bit instructions (+ compressed), load/store architecture, no flags, no implicit state. Then RVV comes along and throws all those principles out the window: global implicit state, microcode-like behavior, variable semantics of the same instruction.
Because vsetvli changes the semantics of all subsequent V-instructions based on the current VLEN configuration. For a JIT compiler in an Emulator and for an Emulator in general, this means having to continuously track the vtype state and react to any changes, a fundamental contradiction to the principle of statically analyzable instructions. It feels like the RISC-V Foundation sacrificed the simplicity and elegance of the RISC principle to create a powerful but extremely complex "super-SIMD" that is difficult to efficiently map in a JIT. A more traditional SIMD extension with fixed vector widths and clearly defined instruction semantics would have been much more JIT-friendly. The upcoming P extension does go in that direction, but it is primarily targeted at embedded and low-power applications rather than high-performance computing.
#riscv #riscv64 #emulation #pasriscv #object_pascal #delphi #free_pascal
-
The irony: the entire RISC-V base ISA (RV64GC) is beautifully RISC: simple opcodes, fixed 32-bit instructions (+ compressed), load/store architecture, no flags, no implicit state. Then RVV comes along and throws all those principles out the window: global implicit state, microcode-like behavior, variable semantics of the same instruction.
Because vsetvli changes the semantics of all subsequent V-instructions based on the current VLEN configuration. For a JIT compiler in an Emulator and for an Emulator in general, this means having to continuously track the vtype state and react to any changes, a fundamental contradiction to the principle of statically analyzable instructions. It feels like the RISC-V Foundation sacrificed the simplicity and elegance of the RISC principle to create a powerful but extremely complex "super-SIMD" that is difficult to efficiently map in a JIT. A more traditional SIMD extension with fixed vector widths and clearly defined instruction semantics would have been much more JIT-friendly. The upcoming P extension does go in that direction, but it is primarily targeted at embedded and low-power applications rather than high-performance computing.
#riscv #riscv64 #emulation #pasriscv #object_pascal #delphi #free_pascal
-
The irony: the entire RISC-V base ISA (RV64GC) is beautifully RISC: simple opcodes, fixed 32-bit instructions (+ compressed), load/store architecture, no flags, no implicit state. Then RVV comes along and throws all those principles out the window: global implicit state, microcode-like behavior, variable semantics of the same instruction.
Because vsetvli changes the semantics of all subsequent V-instructions based on the current VLEN configuration. For a JIT compiler in an Emulator and for an Emulator in general, this means having to continuously track the vtype state and react to any changes, a fundamental contradiction to the principle of statically analyzable instructions. It feels like the RISC-V Foundation sacrificed the simplicity and elegance of the RISC principle to create a powerful but extremely complex "super-SIMD" that is difficult to efficiently map in a JIT. A more traditional SIMD extension with fixed vector widths and clearly defined instruction semantics would have been much more JIT-friendly. The upcoming P extension does go in that direction, but it is primarily targeted at embedded and low-power applications rather than high-performance computing.
#riscv #riscv64 #emulation #pasriscv #object_pascal #delphi #free_pascal
-
The irony: the entire RISC-V base ISA (RV64GC) is beautifully RISC: simple opcodes, fixed 32-bit instructions (+ compressed), load/store architecture, no flags, no implicit state. Then RVV comes along and throws all those principles out the window: global implicit state, microcode-like behavior, variable semantics of the same instruction.
Because vsetvli changes the semantics of all subsequent V-instructions based on the current VLEN configuration. For a JIT compiler in an Emulator and for an Emulator in general, this means having to continuously track the vtype state and react to any changes, a fundamental contradiction to the principle of statically analyzable instructions. It feels like the RISC-V Foundation sacrificed the simplicity and elegance of the RISC principle to create a powerful but extremely complex "super-SIMD" that is difficult to efficiently map in a JIT. A more traditional SIMD extension with fixed vector widths and clearly defined instruction semantics would have been much more JIT-friendly. The upcoming P extension does go in that direction, but it is primarily targeted at embedded and low-power applications rather than high-performance computing.
#riscv #riscv64 #emulation #pasriscv #object_pascal #delphi #free_pascal
-
The irony: the entire RISC-V base ISA (RV64GC) is beautifully RISC: simple opcodes, fixed 32-bit instructions (+ compressed), load/store architecture, no flags, no implicit state. Then RVV comes along and throws all those principles out the window: global implicit state, microcode-like behavior, variable semantics of the same instruction.
Because vsetvli changes the semantics of all subsequent V-instructions based on the current VLEN configuration. For a JIT compiler in an Emulator and for an Emulator in general, this means having to continuously track the vtype state and react to any changes, a fundamental contradiction to the principle of statically analyzable instructions. It feels like the RISC-V Foundation sacrificed the simplicity and elegance of the RISC principle to create a powerful but extremely complex "super-SIMD" that is difficult to efficiently map in a JIT. A more traditional SIMD extension with fixed vector widths and clearly defined instruction semantics would have been much more JIT-friendly. The upcoming P extension does go in that direction, but it is primarily targeted at embedded and low-power applications rather than high-performance computing.
#riscv #riscv64 #emulation #pasriscv #object_pascal #delphi #free_pascal
-
« Milk-V Titan : Powered by a 2 GHz UR-DP1000 octa-core RISC-V CPU, the Titan mini-ITX motherboard supports up to 64GB DIMM memory and M.2 NVMe storage (PCIe Gen4 x4), and features a PCIe Gen4 x16 slot for a graphics card or other expansion, Gigabit Ethernet, four USB 3.0 ports, a BMC, and more. »
-
PasRISCV now has its own local CLI debugger alongside the GDB remote server. It supports breakpoints, single-stepping, register & memory inspection, and allows simultaneous local CLI and remote GDB sessions. A public debugger API enables future graphical debugger frontends.
-
PasRISCV now has its own local CLI debugger alongside the GDB remote server. It supports breakpoints, single-stepping, register & memory inspection, and allows simultaneous local CLI and remote GDB sessions. A public debugger API enables future graphical debugger frontends.
-
PasRISCV now has its own local CLI debugger alongside the GDB remote server. It supports breakpoints, single-stepping, register & memory inspection, and allows simultaneous local CLI and remote GDB sessions. A public debugger API enables future graphical debugger frontends.
-
PasRISCV now has its own local CLI debugger alongside the GDB remote server. It supports breakpoints, single-stepping, register & memory inspection, and allows simultaneous local CLI and remote GDB sessions. A public debugger API enables future graphical debugger frontends.
-
PasRISCV now has its own local CLI debugger alongside the GDB remote server. It supports breakpoints, single-stepping, register & memory inspection, and allows simultaneous local CLI and remote GDB sessions. A public debugger API enables future graphical debugger frontends.
-
The #OpenPrinting #CUPS #Snap is now available for #RISCV in the Snap Store!
To build it it just needed to add #riscv64 as supported architecture in the snapcraft.yaml file.
I has taken 2:30 hours (!) to build on my #DeepComputing / #Framework RISC-V board, and the build servers of the Snap Store need the same time to build it.
Thanks to Heinrich Schuchardt (xypron), RISC-V expert at #Canonical, for providing me a kernel which does bridge networking.
-
I really need to setup a crossbuild environment for #pkgsrc ...
Building rust which is a dependency for ansible on the #VisionFive2 is now in its third day of building and I'd like it to be done by Friday ^^'
#riscv #riscv64 #NetBSD #SBC #OpenSource #opensourcehardware #build -
So since the irradium #Crux #Linux derivate on my #VisionFive2 was broken (didn't boot anymore without any errors, just froze) and I never liked this distro anyway I was looking for alternatives... and for some reason the @netbsd generic "qemu" image... just booted and installed out of the box xD
#RISCV #StarFive #riscv64 #SBC #opensource #netbsd #bsd #freedom -
I was able to boot Alpine on hifive permier p550
alpine:~# uname -a
Linux alpine 6.6.67-0-eswin #1-Alpine SMP PREEMPT_DYNAMIC Thu, 26 Dec 2024 14:02:15 +0000 riscv64 LinuxBut I'm not sure if linux-eswin is a good name for the kernel package.
-
Took a fair bit of mucking about (mainly because I haven't updated the firmware in a year), but I finally got #openbsd76 running on my #starfive #visionfive2 .
-
Took a fair bit of mucking about (mainly because I haven't updated the firmware in a year), but I finally got #openbsd76 running on my #starfive #visionfive2 .
-
Took a fair bit of mucking about (mainly because I haven't updated the firmware in a year), but I finally got #openbsd76 running on my #starfive #visionfive2 .
-
Took a fair bit of mucking about (mainly because I haven't updated the firmware in a year), but I finally got #openbsd76 running on my #starfive #visionfive2 .
-
Took a fair bit of mucking about (mainly because I haven't updated the firmware in a year), but I finally got #openbsd76 running on my #starfive #visionfive2 .
-
Almost done porting #Infix to our first #riscv64 target, a #VisionFive2 so cool 😎
-
I saw there's a #qrv64 kernel for #Plan9 #riscv #riscv64 from a master's thesis I'm reading
Has anyone tried #RISC #9Front ? I'm curious if the #MilkV #MilkVMars could run everything either natively or under #QEMU; I just flashed the board I'm using with #Debian from #StarFive to make sure it boots and functions
It might be unstable, but it might also outperform my #RaspberryPi "9Pi3B"
-
Need to update Gunther at some point.
#VisionFive2 #RISCV #riscv64 #riscvsbc #raspberrypi #raspberrypi3 #raspberrypi5 #opensourcehardware #sbc #singleboardcomputer -
So put my #VisionFive2 where it belongs xD
Now the actual work can start 🧐 😆
#RISCV #riscv64 #sbc #opensourcehardware #linux #StarFive #riscvsbc -
Since a friend of mine has access to a free of charge 3D printer, courtesy of the German tax payer (us), I got myself a nice case printed for the #VisionFive2 .
Have to add some active cooling on top which will make it look less cool, but otherwise it's running at around 58°C with just the passive cooler and over 65 when under load.
#RISCV #riscv64 #sbc #starfive #OpenSourceHardware -
The Firmware update on my #VisionFive2 worked really well actually. I didn't adjust the version strings though so the openSBI now shows the board and build date instead of 1.4 or w/e the latest but it's fine.
Now let's hope Amazon delivers the new SD cards and if they work I can finally continue to dabble around with other systems but the standard #debian image 😅🙏🏻
#RISCV #riscv64 #sbc #OpenSourceHardware #starfive
