Pine64 komt met Star64-singleboardcomputer die voor het eerst RISC-V-chip heeft

Pine64 brengt voor het eerst een singleboardcomputer uit die werkt op een chip met een RISC-V-core. De Star64 heeft een StarFive-processor met vier 1,5GHz-kernen die volgens het bedrijf vergelijkbaar is met de prestaties van de Rockchip RK3566.

Pine64 hintte eerder al op een nieuwe singleboardcomputer, maar geeft nu voor het eerst details over de Star64. Dat is de eerste singleboardcomputer van het bedrijf die draait op een chip met een RISC-V-kern. De SBC heeft een StarFive JH7110 64bit-cpu met vier SiFive FU740-cores van 1,5GHz. Het bedrijf zegt dat de soc qua prestaties vergelijkbaar is met de Quartz64-board van het bedrijf, die gebruikmaakt van een Rockchip RK3566, een quadcore ARM Cortex A55-chip. De computer heeft daarnaast een geïntegreerde BXE-2-32-gpu en komt in configuraties beschikbaar met 4GB of 8GB geheugen.

De Star64 heeft daarnaast een PCI-e-aansluiting, een USB 3.0-poort en GPIO-pins. Ook zijn er twee gigabitethernetpoorten aanwezig op het apparaat, maar er komt 'op een later moment' een goedkopere variant uit die slechts een ethernetpoort heeft.

Pine64 zegt dat de SBC een 'Model A'-ontwerp krijgt met afmetingen van 133x80x19mm. De prijzen en beschikbaarheid van het apparaat zijn nog niet bekend.

Reacties (92)

[bahamapleister]

Wat is er bijzonder aan een RISC-V ontwerp? Volgens Wikipedia is het open-source in tegenstelling tot andere ontwerpen. Zijn er nog andere verschillen?

[Hans1990]

RISC-V is opzichzelf geen ontwerp, maar een ISA (instructie set architecture).

Bijvoorbeeld, ARM levert een redelijk compleet pakket met gegevens aan om een processor te bouwen. Zo zal de ISA voor een bepaalde generatie ARM cores vast liggen, maar zijn er ook verschillende core designs te licenseren die verschillende prestatieniveau's halen. De bekende ontwerphuizen bouwen er peripherals en geheugenbussen omheen, en dan is de SOC klaar. Sommige fabrikanten (Apple met M1, maar ook anderen) passen cores nog verder aan naar eigen inzicht.

Bij RISC-V ligt dit allemaal veel losser. De instructieset heeft meerdere losse extensies, en je kan zelf kiezen wat je nodig hebt. Het minimum wat je nodig hebt is kunnen werken met 32-bit integers. In de instructieset is er zelfs ruimte in de opcodes gelaten dat je eigen instructies kan toevoegen. De implementatie van de processor, zoals de pipeline e.d. is ook niet vastgesteld en wordt tevens ook door de industrie/community geleverd.

In zekere aspecten heeft dit zeker voordelen. Als je een eigen ASIC of FPGA ontwerp bouwt, kan je er voor kiezen om een high-performance core design te maken/licenseren die superscalar (meerdere instructies tegelijk uitwerken), speculative execution, meerdere ALU's enzovoort. Je gaat dan richting desktop PC levels performance.

Maar je kan ook optimaliseren voor size. In de open source community is er echter ook een zogenaamde "bit-serial" implementatie genaamd SERV. Deze CPU is enorm klein doordat het 1 bit van een 32-bit instructie per clock cycle verwerkt. Een instructie om 2 getallen bij elkaar op te tellen kost dus 32 cycles. Reguliere CPUs doen dat in 1 cycle, en CPUs met meerdere ALU's kunnen nog hogere throughput halen.

Waarom zou je dat willen? Omdat het kan. De CPU is letterlijk paar honderd flipflops. Zodoende passen er 6000 SERV cores op 1 grote FPGA. De performance is wel om te huilen, omdat 1 CPU core dus eigenlijk 32 kloktikken per instructie nodig heeft.
Er is echter nog wel een legitieme gebruiksreden voor. Stel je maakt een ASIC die een klein processortje nodig heeft om even wat bits op de goede plek te zetten bij opstarten, en voor de rest niets doet. Dan kan je met een paar honderd flipflops dat al doen, en kan je zelfs de firmware later nog aanpassen.

Paar alinea's terug zei ik "in zekere zin", omdat ik nog niet helemaal overtuigd ben of dit 'de' aanpak is voor software developers. Voor hardware developers is RISC-V fantastisch omdat het nog niet uitgekneed is. Echter van verschillende microcontrollers die ik tot zover heb zien uitkomen met RISC-V hebben ze vaak ook eigen GCC compiler builds (nodig) juist omdat ze eigen instructies toevoegen aan de processor. Het is een klassieke eigenschap van OpenSource waarbij iemand die een stuk software wilt verbeteren, maar vervolgens de samenwerking of richting van het project niet bevalt en z'n eigen fork maakt. Zodoende heb je 2 software pakketten die hetzelfde doen. En is dit wenselijk voor een compiler die dezelfde architectuur zou moeten gebruiken? Of moeten we er mee leven dat je bepaalde 'proprietary' instructie set extensies enkel kan gebruiken als je de fabrikant z'n (mogelijk slecht onderhouden & sterk verouderde) compiler fork gebruikt?

Tevens hekel ik ook dat van veel chips niet duidelijk is welk performance niveau je kan verwachten. Een "RISC-V core" zegt mij niets hoe snel die kan zijn, zoals ik al net schets met een superscalar vs bit-serial implementatie.

[Reactie gewijzigd door Hans1990 op 25 juli 2024 19:52]

[ouhaha]

je samenvatting is vrij goed, en ik kan me er terug in vinden. Hoewel je focust op hardware zelf (zie verder hieronder). Voor je laatste punt : het zou leuk zijn om ook wat CoreMark/MHz of zo te hebben

De meeste cores uiteraard volgende minstens de basic set, en eventueel een of meerdere gestandaardiseerde uitbreidingen (bijvoorbeeld floating point, ...).

Kortom is er ook een test-suite beschikbaar naast de instructieset zelf, om te checken of je er aan voldoet.

Het leuke is, als je voldoet aan die instructiesets, weet je dat je perfect compatibel bent met de compilers, en alle software pakketten (ook operating systemen) voor RISC-V. En dat is direct een veel groter ecosysteem dat je zelf voor je eigen instructieset moet ontwikkelen. GCC, LLVM, en zoveel meer. Geoptimaliseerde libraries... Je tapt direct in iets veel groter.

Voor x86 of ARM, heb je een licentie nodig! Daar zit hem het grote verschil.

Mijn buikgevoel:
- voor alle 'simpele' controllers, ik denk aan DSL modems/routers, disk-controllers (WD is ermee bezig), straks ook TV boxen, maar ook de controllers in allerlei simpele machines (maairobot, wasmachine, ...), ik vermoed dingen zoals Raspberry Pis (zie dit artikel), wordt het op termijn RISC-V. Of het daarna ook aanslaat naar grotere performance... geen idee.

[SG]

Ik denk het niet.
Die risk-v is zo een niche.
Dat als je dat nodig hebt je dan afdeling.
Die op niveau van chip architectuur hoge kennis moet hebben.
Je ook platform moet ontwikkelen mobo waar dit op komt zeer custom.
De OS moet ontwikkelen uit fork van andere.
Daarnaast applicatie die hier van gebruik gaat maken van unieke feature combi voor zeer specifieke use case.

Het kosten plaatje gaat dan in werknemer zitten die op alle benodige kennis domeinen redelijke experts in moeten zijn. Duur team.

FPGA kan je Risk-V IP in licentie kopen misschien zijn er ook simple gratis IP voor. Of je implemented een softcore Risk-v zelf. Wat ook hogere FPGA softcore ontwikkeling kennis vergt. Kan je ook ZinQ met hardware arm core nemen

Naast dat bij arm er ook genoeg versies zijn met ook nodige optioneel dat niet zomaar alles werkt op andere arm platform zoals de native pfsense hardware.

[Hans1990]

De basis instructie set verandert inderdaad niet. Anders kan je het geen RISC-V core noemen. Al zou je een stuk software compileren met de standaard GCC of andere variant compiler, dan zou je werkende software moeten bouwen. En in theorie zou je genoeg standaard software builds kunnen vinden die bijvoorbeeld met een rv32imac core Linux en GNU tools oid zou kunnen gebruiken.

Echter net zoals op X86 die verschillende instructie set extensies kent, moet de executable die draait daar wel bewust van zijn welke instructies die wel of niet kan uitvoeren. Stel je voegt floating point toe, dan zal er software zijn die daar graag gebruik van wilt maken. Eveneens zo met x86 extensies zoals SSE of AVX. Al zou je deze instructies uitzetten voor moderne workloads (zoals games of x264/x265 encoden op de CPU), dan zal de performance ook flink in elkaar storten. Echter deze applicaties zullen de processor optie bits checken of je de benodigde extensies wel hebt, of vanzelf terugvallen op 'legacy' code paths.

Het probleem wat ik schetst is dat doordat dus RISC-V compleet open source is, dat het goed mogelijk is dat fabrikanten afwijkende cores bouwen waarbij de custom features enkel met custom compiler versies kan worden benut, mogelijk met minder toegankelijke documentatie en processor optie bits. Je kan waarschijnlijk dan met de mainstream tools nog steeds wel de meeste software draaien, maar mogelijk laat je dan performance liggen t.o.v. de 'proprietary' builds omdat zij wel hun eigen instructiesets kunnen aanspreken. Zolang elke fabrikant z'n eigen speeltuin mag ontwerpen, is er risico op divergentie verwacht ik (terwijl RISC-V goed is begonnen met de basis ISA op te zetten).
Het is voor mij maar een onderbuik gevoel, en we moeten zien wat de toekomst brengt.

De Coremark benchmark is inderdaad een goede tool om een label te plakken hoe snel een CPU is. Nu is het niet beall&end-all van typische embedded taken (zo leunt die benchmark vrij heftig op integer multipliers danwel barrel shifters), maar het geeft wel een vrij goede indicatie. Je zou zekers moeten kunnen achterhalen of een RISC-V op x MHz goed kan meekomen met een Cortex-m0 of m7 op Y en Z MHz respectievelijk (bijvoorbeeld).

[Reactie gewijzigd door Hans1990 op 25 juli 2024 19:52]

[MrFax]

Stel RISC-V zou de standaard worden in de wereld. Het zou wel lastig voor de normale consument om iets te kiezen die de instructies ondersteund die je voor jouw laptop nodig hebt. Je koopt iets, maar de SoC werkt niet met bepaalde software omdat je instructieset X nodig hebt, maar je SoC deze niet ondersteund.

Het lijkt erop dat PCs steeds specifieker worden en je voor elk doel iets aparts moet gaan kopen. Ik zou dat een beetje tegenstrijdig vinden tegenover onze klimaatdoelstellingen. Je wilt juist dat 1 apparaat zo veel mogelijk kan.

[Reactie gewijzigd door MrFax op 25 juli 2024 19:52]

[rjmno1]

Dus met andere woorden risk v processor hardware is eigenlijk een hardware opensource, zodat je zelf kan kiezen wat je erin wilt hebben.Dit lijkend mij een leuke uitdaging voor de meer gevorderde hobbyisten.
Of zie ik dat verkeerd?

[MSalters]

Je merkt terecht op dat extensies een uitdaging zijn voor de compiler. Maar dat is niet het enige wat je moet aanpassen! Neem een bekende extensie als AVX: dat is een x86 extensie die OS support vereist. Je OS wil namelijk een task switch kunnen uitvoeren naar een ander programma, maar als je terug switched naar het originele programma moet die gewoon door kunnen gaan alsof er niets gebeurd is. Dat moet dus ook als het programma AVX-berekeningen aan het doen was. Het OS moet daarom AVX snappen.

Met deze RISC-V extensies heb je potentieel dus ook kernel extensies nodig.

PS. de kloktik-berekening van een 32 bits add is nog te optimistich: je hebt de Instruction Pointer update vergeten. Dat is een impliciete +1, dus je 32 bits add kost 64 kloktikken.

[lololig]

ARM is ook RISC-based, dus open-source zal inderdaad wel het grootste verschil zijn, er zijn natuurlijk ook verschillen onder de motorkap
https://itdaily.be/blogs/...v-het-verschil-uitgelegd/

[Werelds]

Dat artikel legt het echt heel slecht uit. RISC en CISC zijn geen basis waar je iets op baseert, het zijn ontwerp filosofieën. Zowel ARM als RISC-V, maar ook Power zijn allemaal RISC instructie sets, maar geheel niet compatible met elkaar, even min als x86, de verschillende Motorola ISA's en Alpha dat zijn.

Een verschil tussen RISC-V en ARM is inderdaad dat RISC-V open source is, wat betekent dat je geen royalties hoeft te betalen als je een processor met die instructieset wil maken.

Er zijn verder echter nog veel meer verschillen; in het kort is RISC-V nog veel meer "RISC" dan ARM, in de zin dat er veel meer dingen optioneel zijn (0,0 floating point in de basis set) en dat sommige dingen waar ARM je een keuze geeft in RISC-V vast staan (endianness bijvoorbeeld).

[SG]

Ander groter verschil is dat je RISC-V soft core in FPGA kan implementeren.
Wat met gesloten architecturen o.a ivm blackbox abstractie van bv branch predictor moeilijk of zelfs onmogelijk te implementeren is .

[MSalters]

Hoezo is Floating Point een verschil? ARM in de basis heeft ook geen FP en zelfs geen MMU . Zo'n kale ARM valt dan in de Cortex-M serie. RISC-V heeft (nog) niet zo'n standaard serie-benaming, maar feature-wise hebben beide architecturen weinig absollut verplichte onderdelen.

[Werelds]

Jij hebt het over de CPU architectuur, ik had het over de ISA. Als je een architectural license (dus geen heel CPU ontwerp zoals alle Cortex dingen) bij ARM neemt moet je de volledige ARM ISA implementeren, waar bij mijn weten FP gewoon verplicht is. Wat ARM zelf doet met hun "M" profiel kan niemand anders dan ook doen; even los van dat met de koepelterm "ARM" doorgaans het "A" profiel bedoeld wordt en bij al die ontwerpen is FP een vast onderdeel en moet je de instructie op z'n minst ondersteunen, zelfs wanneer de licentie voor het ontwerp (A53/A55 bijvoorbeeld) toe staat geen FPU te hebben. Dat dan wellicht via integer gaat en dus retetraag is, is dan jouw probleem en iets wat je dan in je eigen documentatie aan kunt geven door bijvoorbeeld te zeggen dat men moet compilen met "+nofp" zodat de compiler afbreekt bij floats.

[MSalters]

Ik heb even bij ARM zelf gekeken:

Is floating point support optional?

No. Support for floating point is mandatory in Armv8-A. The architecture specifies that it is required whenever a rich operating system, such as Linux, is used. You are technically permitted to omit floating point support, if you are running an entirely proprietary software stack. "

Gevalletje "verplicht maar stiekem optioneel".

En er is dus ook een document (publiek beschikbaar) dat beschrijft hoe een M-profile ARM core moet werken, expliciet voor ontwerpers van zo'n core.(Document DDI0553B.r). Als ARM zelf de enige was die dit mocht, dan zou dit publieke document niet deze ontwerpers expliciet noemen in de Intended Audience sectie.

[Reactie gewijzigd door MSalters op 25 juli 2024 19:52]

[Werelds]

Ik heb even bij ARM zelf gekeken:

Ja tuurlijk, als je geen general-purpose product gaat ontwerpen maakt het uiteraard niet uit. Het gaat er om dat als jij een CPU wil gaan maken met de ARM ISA die door iedereen gebruikt kan worden moet je, net zoals dat bijvoorbeeld bij x86 en AMD64 moet, de hele ISA implementeren. Anders kunnen gebruikers er niet van op aan dat software gecompiled voor ARM er ook op kan draaien.

En er is dus ook een document (publiek beschikbaar) dat beschrijft hoe een M-profile ARM core moet werken, expliciet voor ontwerpers van zo'n core.(Document DDI0553B.r). Als ARM zelf de enige was die dit mocht, dan zou dit publieke document niet deze ontwerpers expliciet noemen in de Intended Audience sectie.

Nogmaals, dat gaat over hun CPU architecturen. Je neemt dan een licentie op de CPU architectuur, niet de ISA. Je kunt daar ook niet voor compilen met een normale GCC toolchain, je moet dan hun toolchain gebruiken die een hoop flags toevoegt waarmee delen van ARMv6/7/8 uitgeschakeld worden

Eenvoudigste voorbeeld is waarschijnlijk Go (programmeertaal), omdat dat heel makkelijk te cross-compilen is. Een stuk Go code voor ARM compilen doe je door als doel architectuur arm, arm64 of arm64be aan te geven. Wil jij iets doen voor MacOS met Apple Silicon (zij hebben zo'n architectural license), compile je voor darwin/arm64 en dat werkt zonder problemen. Zelfde geldt eender welk ander OS op de ARM ISA. Compilen voor Cortex-M CPU's? Gaat niet, want die dingen implementeren niet de ARM ISA. Het zijn CPU architecturen van ARM, maar zijn niet compatible met de ARM ISA omdat ze slechts delen daarvan implementeren. Technisch gezien moet je om voor Cortex-M te compilen een hele reeks aan instructiesets gebruiken, wat hun toolchain stilletjes doet. Maar met die toolchain kun je ook niet alles compilen.

Had Apple er voor kunnen kiezen niet de hele ISA te implementeren? Tuurlijk. Maar dan hadden ze de M1 niet in Macs kunnen stoppen. En dat is het punt van jouw quote ook: als je je product de wijde wereld in wil sturen en dat er een RTOS en andere applicaties op draaien, móet je FP implementeren omdat de ISA dat vereist. Wat je binnenshuis doet is jouw zaak, dat kan ARM toch niet controleren.

[Reactie gewijzigd door Werelds op 25 juli 2024 19:52]

[MSalters]

Ik weet niet of je wel eens met een standaard GCC gecompileerd hebt voor embedded toepassingen?

Je claimt dat je een speciale toolchain nodig hebt. Dat is nergens voor nodig; een standaard GCC/ARM AArch64 toolchain snapt "-nofp". Die optie is inmiddels nodig om zonder FP te bouwen, in de 32 bits tijd moest je het impliciet (via -mcpu) of expliciet aanzetten.

Uiteraard is OSX een goed voorbeeld van een niet-embedded, general-purpose systeem. Daar is FP uiteraard verplicht. Niet dat het uitmaakt, uiteraard. Apple heeft zelfs vector extensies, die niet verplicht zijn. Maar een Apple laptop is natuurlijk niet de klassieke embedded toepassing van ARM SoC's.

Overigens: RTOS? Voor real-time systemen heeft ARM een derde ISA, naast AArch64-A en AArch64-M. Die derde is AArch64-R, en ook daar is FP optioneel. En daar heb je niet eens speciale GCC vlaggetjes voor nodig;, dat is simpelweg "-march=armv8-r"

[Werelds]

Als je hun toolchain niet gebruikt (die in feite gewoon CPU profielen toevoegt die op hun beurt een hoop extensies aan/uit zetten) moet jij zelf exact weten welke flags voor welke CPU gebruikt moeten worden; nofp is dan slechts een voorbeeld. Het was iets te cru om te stellen dat dat met een normale GCC toolchain niet kán, maar je zult wel even bezig zijn met alle flags uit te zoeken. Nogmaals: je bent dan voor een specifieke CPU (architectuur) aan het compilen, niet de algehele ISA. Je kunt ook specifiek voor Skylake of Athlon64 of Pentium1 compilen; allemaal x86(-64) met extensies. Maar compile je gewoon x86 zonder CPU arch te specificeren, zal het op eender welke van die producten werken, omdat ze allemaal de x86 ISA implementeren. Met Cortex-M is dat niet het geval, je kunt niet voor "ARM" compilen, je moet voor die specifieke CPU architectuur compilen via march+mtune of mcpu, met als gevolg dat er vooral dingen worden uitgeschakeld (zoals FP). Die dingen implementeren technisch gezien dan ook niet de ARM ISA, maar Thumb-1/Thumb-2. Sterker nog, in hun eigen documentatie geeft ARM zelfs aan dat de M3/M5/M7 Thumb-2 doen zónder ARM instructies

Ik begrijp je punt volledig, maar dit is waar ARM ook gewoon heel verwarrend is. De ARM ISA was al iets heel anders dan de ARM CPU architecturen, met hun profielen geneuzel daar dan nog eens bovenop. Met AArch64 is het er niet makkelijker op geworden. Voor x86(-64) zijn er dan misschien te veel extensies, maar ARM maakt het nog veel lastiger doordat er selectief dingen worden weg gelaten uit de overkoepelende ISA. Dat er in de praktijk nagenoeg geen producten zijn die de ARM ISA as-is implementeren en dat de meeste producten als gespecialiseerd aangemerkt worden, doet niets af aan wat ARM eigenlijk wil dat er gebeurt.

Dat armv8-r in GCC zit wist ik overigens niet, ik doe tegenwoordig niets op dit vlak dus dat is mooi. Hoort daar ook gewoon thuis.

[MSalters]

"Gewoon x86" bestaat inderdaad voor GCC, dat is "-mtune=generic". Maar let op, dat is dus alleen de tuning. Voor de architectuur kun je niet "generiek x86" opgeven.

Als je geen expliciete -march meegeeft tijdens het bouwen van jouw code, dan valt GCC terug op de setting die gebruikt was tijdens het bouwen van GCC zelf. En dat kan nogal varieren. Het is lang "i386" geweest, daarna "i586" aka Pentium (want de 486 had nauwelijks nieuwe instructies). Wat later kreeg je i686+CMOV (conditional move, scheelt conditional branches). En het is dus al behoorlijk lang zo dat je niet standaard een x86 build krijgt die op de Pentium 1 werkt; die had nog geen CMOV .

En dat is dus allemaal voordat je MMX en andere vector extensies kreeg. Kijk je dan ook nog eens naar Atom, dan zie je dat er heel lang x86 chips naast elkaar hebben bestaan met behoorlijk verschillende ISA's. .

[bantoo]

Niet echt. Het is niet als of deze achitectuur inherent een voordeel heeft tegenover ARM oid. Licentieverschil is het enige merkbare en dat is alleen relevant voor chip fabrikanten.
Ik zou als eindgebruiker dit nooit kopen, je verliest een hoop software support voor een paar cent prijsverschil in het beste geval.

[HollowGamer]

Ik hoop juist dat consumenten het kopen, hoe meer opensource, hoe beter voor ons als consument.

Het licentie verschil is gewoon een groot argument. Hetzelfde is dat veel ontwikkelaars liever voor open-source kiezen, dan voor closed. Puur om te kijken hoe het werkt en waar eventueel valkuilen zijn.

[blorf]

Ze gaan vermoedelijk rond de 60 en 80 euro kosten volgens een winkel die ik niet ken met de naam Liliputing. Ik kan er alleen nog niet achter komen wat hier in de eerste instantie op gaat draaien. Van Pine zou je in ieder geval een Linux kernel verwachten, maar ik kan niks vinden.
Als dat geregeld wordt wil ik er wel een om Doom te testen.

[TheVivaldi]

Ze gaan vermoedelijk rond de 60 en 80 euro kosten volgens een winkel die ik niet ken met de naam Liliputing.

Liliputing is geen winkel, maar een nieuwssite.

[blorf]

Ik zie het, toevallig nooit eerder van gehoord. Dat is waar Google iedereen naar toe stuurt die op Star64 zoekt.
Wel karige info en plaatje. Waarom geen klaar product afbeelden? Het SD-slot zit er nog niet op...

[Jerie]

Het is zeer portable en Linux kernel draait allang op RISC-V. Debian ook, het is zelfs een prima port: https://wiki.debian.org/RISC-V ik zou me dan ook om software geen zorgen maken tenzij je binaries wilt gebruiken. Dingen die FOSS zijn gaan gewoon werken.

[bbstreams]

dat is niet hoe opensource werkt, dat werkt gewoon mee met het gross van alle hardware, tenzij jezelf een linus torvald bent dan kun je het overal voor schrijven, maar zelf hij waagt zich niet aan andere zaken zoals drivers en firmware, maar toch gaat het wel langzaamaan die kant op nu er meer SOC's op de markt komen, dan is het uiteindelijk beter om alles in de kernel te bouwen en niet meer te stacken zoals huidige opensource. met andere woorden, verwacht onder ARM/risc juist meer closed sourced hardware. tenzij de overheid wakker wordt en gatekeeper bedrijven als apple verbiedt om hardware aan software te bundelen.

[SG]

Dit is hardware cpu open source dit is open source voor bedrijven die zelf een chip willen ontwikkelen. De grote os makers is zo een niche platform niet interessant.
En ben je afhankelijk van de open source os die wel bereid zijn om vrij tijd besteden voor deze excotische implementaties van riskv en hardware platform.
Dan moet je ook nog app ontwikkelen.
En dus ben je afhankelijk of linux distro dit oppakt.

Dit is nog verder van opensource software.

Dit is voor zeer kleine niche van hardcore opensource nerd die al veel met embedded platformen doen . Voor als je zelf platform ontwikkeld en OS wil verzinnen is volledige beschikbaarheid van hardware documentatie handig ivm driver ontwikkeling os ontwikkeling .
En de consument heeft meer aan windows of linux distro voor gangbare consumenten hardware wat ook goed support wordt door leading OS makers. Maar ook waar meeste gangbare app door grote markt ook voor software voor ontwikkeld wordt.

Ontwikkelaars die voor opensource kiezen zijn prof die in hun vrije tijd bezig zijn met open source projecten.
Als dev brood verdiend moet worden voor gezin en hypotheek. Moet er salaris verdiend worden. En den ontwikkel je voor de markten waar er omzet gehaald kan worden.
Dat Win pc en apple android. Open source hardware is niet interessant want dat is totaal niet relevant. Want gaat om waar je applicaties omzet behaald kan worden en dat zijn de massa platformen.

[_Pussycat_]

Ik geloof dat je compleet het doel mist hier. Niemand gaat (tenminste nu) proberen een office-PC met Risc-V te bouwen en niemand gaat er gewone software voor schrijven. Maar voor controllers, sensoren, embedded hardware is dit heel nuttig. On moderne sensoren zit meestal een microcontroller die met ARM best duur is, met een 8051 erg langzaam is, en als je zelf wat maakt moeilijk te ontwikkelen en te ondersteunen is. Daarvoor is Risc-V prachtig, je hebt compilers etc. klaar en een mooi variabele architectuur.

Jij denkt alleen vanuit het PC- en telefoon-oogpunt waar er inderdaad niemand op zit te wachten.

[blorf]

Het wordt gepresenteerd als "single board computer", maar het is een soort van template printplaat waar nog niks op zit? Hoezo geen eindprodukt?

[PjotterP]

Het gaat niet uitsluitend zozeer om waar het nu staat en het product dat je nu koopt, maar ook om het potentieel voor de toekomst. Als deze architectuur / instructieset succesvol wordt dan breekt dat (in bepaalde opzichten) de markt open omdat partijen geen licentie nodig hebben om voor een - hopelijk ooit breed geadopteerde architectuur - chips te ontwerpen. Bij x86 en ARM ligt dat nu immers anders.

Dat is - uiteindelijk - ook relevant voor eindgebruikers.

Tegelijkertijd kan je zeggen dat het feit dat x86 en ARM license based zijn vooralsnog er niet aan in de weg staan dat zo ongeveer iedereen in de wereld wel een computer kan kopen. En uiteraard is de instructieset maar een deel van de puzzel. Een chip ontwerpen en maken zijn wellicht nog veel wezenlijker.

[Reactie gewijzigd door PjotterP op 25 juli 2024 19:52]

[fgghhf]

Dat is niet 100% correct, bij gebrek aan een licentie of regelgeving staat risc-v international toe dat je de broncode van risc-v of wijzigingen die je daar aan heb gedaan closed-source maakt.


Stel risc-v breekt echt door dan kunnen Intel en amd hun eigen versie/aanpassingen maken en deze vervolgens gesloten houden, zou een Microsoft beslissen dat ze alleen deze twee interpretaties ondersteund dan zijn we gewoon weer waar we vandaag ook zijn.


Oftewel open-source is echt niet de hemel op aarde.

[blorf]

Dus open source heeft beperkt voordelen omdat anderen het weer closed source kunnen maken? Verbeteren door beperken kan niet. MS krijgt er altijd een produkt van dat zichtbaar minder kan dan de oorspronkelijke uitvoering.

[Jerie]

Dit betreft het al oude verschil tussen copyleft en doe er mee wat je wilt. Ofwel GPL (+ alle verwanten) vs MIT of BSD. Deze ISA is meer richting het tweede. Dus je kunt er ook een closed source variant van maken. Het origineel blijft hoe dan ook bestaan. Bedrijven vinden dit soms fijn dan kunnen ze bijvoorbeeld kiezen wat ze zoal wel of niet delen. Het scheelt ze dan een ARM licentie.

[SG]

Ik ben bentoo eens dat vanuit consument gezien dit totaal niet relevant is.
En MS gewoon de leading chips ondersteunen zo was er ook workstation server windows voor paar concurrenten van itanium . De Alfa chips. Etc. En ook itanium zelf.
MS zal 86 ondersteunen niet om dat zo geweldig is maar dat deze chips de markt van pc computing overheersen in office en home en server en laptop space.
Dat ms zelf nu arm hardware maakt is dat een x86 geen SKU heeft voor ipad alternatief wat tablet pc is en de ultra thin mobile surface tablet hybride . Gezien Apple silicon M1 en m2 niet voor concurrenten beschikbaar zijn is er dus vraag naar apple silicon alternatieven voor derden.

En Arm is nu zo geweldig omdat dit door Apple als een van de grootste premium klanten geniet van de leading procede van TSMC je vergelijkt hier een 5nm M1 met intel ULV ultramobile op intel7 wat vroeger 10nm wat grof 7 a 8 nm volgens andere verzonnen procede aan duidingen.

Dat is zoiets als 14nm intel vs 32nm piledriver
X86 AMD zen3 is nu nog TSMC 7 vs M1 en M2 5nm

De toekomst kan zijn dat intel blijft aanmodderen met hun procede en dan gaat het om de volgende gen of 3 dieschrinks bijvoorbeeld intel 3. Zodra intel gelijkwaardige of zelfs betere dan tsmc procede uitrolt en samsung kansen zijn met elke next dieshrink ook niet uitgesloten. Is het niet gegarandeerd dat TSMC met afstand de markt blijft lijden. De kans is groot. Maar de anderen kunnen ook catch up doen. Of er voorbij gaan.

Naast dat er x86 op leading procede kunnen uitkomen en SKU specifiek voor ultra mobile toepassingen zoals tablet pc tot zelfs smartphones zelfs smart watches.
Ontwikkeld kunnen worden.

Wat MS vooral niet doet is onnodig veel flavors van dezelfde instructie set ondersteunen. Dus EPIC itanium architectuur zijn ze wel voor gegaan. AMD64 de 64bit x86 zijn ze ook voor gegaan. Wat eigenlijk itanium de nek omdraaide zoals itanium de meeste andere heavy tin omzeep hielp. Maar Microsoft geen onnodige x86 64 niet compatible AMD64 vezinsel van iNtel gaat ondersteunen. En dat bij intel ook dringend aangekaart hebben.

X86 is zwaar gevestigd en legacy is ook zeer belangrijk punt. En zolang dat sterk is is x86 blijver.

Ook heel belangrijk is applicatie ontwikkeling. Voor store app die op x86 en arm moet kunnen lopen moet app ontwikkeld worden in wpf tool cain. Wat platform abstractie layer heeft. Maar aps die native win api en x86 extenties gebruiken of specifieke exotische win api calls

Denk dat MS de dev community liever ziet dat voor WPF ontwikkeld wordt. Misschien dat in de toekomst buiten de wpf wordt ontmoedigd of geblokkeerd.

Dat nieuwere versies en apps ook op ARM moeten kunnen lopen.
Dat houd niet in dat x86 verdwijnt want dan moet er ARM desktop met ook zooi pci-e sloten waar g-kaart in gestopt kan worden. En ook x86 kwa sales verdringen naast dat dit al vele jaren aan de gang moet zijn dat er minder x86 in gebruik is om ms windows voor x86 te schrappen.
NVidia zou nV “NUC” op hun ARM en RTX basis als Arm in de desktop doorbreken.

En doorbreken op dat niveau houd niet vervangen maar zal naast x86 voor lange tijd lopen. Naast dat iNtel en AMD ook zelf kunnen schuiven naar ARM vooral AMD.
Zij gebruiken x86 in licencie van intel. Dus ARM zal altijd een optie zijn.

Als AMD dat zou doen dan komt dat als extralijn bij x86 en dat is iets dat heel ver in de toekomst zou kunnen gebeuren. Dan heb ik het over 2030.

Voor nu staat x86 heel sterk in de markt geworteld.

[gast128]

RISC-V ondersteunt ook verschillende feature levels waardoor het toepasbaar is van microcontrollers to PC chips. In die laatste categorie heeft het weinig voordeel gezien dat de meeste oppervlakte van die chips voor de cache bestemd is. Verder is een ARM licentie bepaald niet goedkoop.

[SG]

Dan zie je ook wat de target is. Je hebt product concept met hoge niche gehalte waar productie verwachting in de 10000 ipv 10000000 hebt.
Dan is ARM licentie niet te doen.
Ik zou graag een STM32 zien die gangbaar goed verkrijgbaar en op stock is bij mouser en digikey met meer dan 8 uarts.
Zonder dat spi naar uart brdige chips of quad spi to meerdere uart bridgechips. Plus hoop gedoe in embedded software om dat aan te sturen.
Dus native MCU met 16 uarts.
Denk dat meer iets is voor zeer custom niche hardware.
Maar dan is FPGA misschien betere optie

Ik vraag mij toch af wat moet computer gebruiker hier nou mee.
Is dit meer het doorslaan van zeer radicale opensource manie.

Als consument kijk je naar platform met OS en software. En dan de prijs.
En software markt kijk waar de massa van die consumenten kwa platform heeft.

[MSalters]

Voor een bedrijf als STM maakt de ARM licentie niet uit; die is afgekocht. 10.000 devices met 16 uarts kost ze niets extra's qua ARM licentie. Maar voor R&D kosten maakt het nogal een verschil of de STM32-SG_special een ARM danwel een RISC-V is.

Nee, de reden is veel pragmatischer. Die R&D kosten verdien je niet terug met 10.000 chipjes, ongeacht de ISA. En dan hebben we't niet eens over de kosten van voorraad beheer etc.

[beerse]

Opa verteld (mijn zicht op de cpu geschiedenis): Ooit, ergens in de jaren 1980 waren er vanuit de cpu ontwikkelingen 2 paden zichtbaar: Cisc en Risc: Coplex Instruction Set Cpu en Reduced Instruction Set Cpu.

In den beginne moesten cpu-s nog allemaal hun basis functies krijgen (4004, 8008 en zo). Toen ze die een keer hadden (8080, z80, 8086, 6809, 68000 en zo), was er een groep leveranciers die steeds complexere instructies gingen toevoegen omdat die wel handig waren. Maar die complexe instructies hadden ook vaak meerdere cpu-cycles nodig. Maar de functionaliteit was wel nodig en uitgeschreven in 'eenvoudige' instructies duurde ze langer.

Toen kwam er een ontwikkeling om juist minder van die complexe instructies op te nemen in de cpu maar de cpu gewoon sneller te maken. Dat is toen RISC gaan heten. Veel van die cpu-s kregen de term 'risc' in de naam (pa-risc). De andere ontwikkeling noemden ze (retro-fit) CISC.

Aan het begin van deze eeuw is de cpu-ontwikkeling van beide kampen elk hun eigen kant op gegaan, als je dat grafisch en in de tijd uit zou zetten, zie je een best wel brede vork onstaan waar veel cpu-s elk hun eigen mate van complexiteit hebben.

[sympa]

68000 was al heel erg CISC. Eigenlijk bleek het dat de complexiteit van de instructie zelf niet het probleem is. Een "shift 3 keer in de rondte" instructie is zo te implementeren vandaag de dag.
Maar was het probleem vormt zijn memory accesses. Op de 68K kan een add-instructie 2 operanden lezen uit het geheugen en het resultaat weer wegschrijven, en daarbij ook nog indexregisters die het adres aangeven ophogen of verlagen.
Als er een geheugenerror optreedt tijdens zo'n instructie moet de processor hem terugdraaien. Het kan dus dat 1 instructie 3 keer teruggedraaid moet worden. Inclusief het terugzetten van die auto increment.
Bij RISC zijn de geheugeninstructies losgekoppeld van de rekeninstructies. Dus er is steeds 1 load of 1 store, die in zijn eentje teruggedraaid kan worden.

[beerse]

Een mooi voorbeeld dat de meeste lopende processor ontwerpen zich na de introductie van risc zich in het cisc kamp bevonden.

Maar nu, terug kijkend, zijn er altijd cpu-s en/of regeltjes die op zijn minst punt van discussie zijn of ze risc of cisc zijn. Een loop/bulk opdracht, of dat nu een cisc of risc instructie stat voor mij open. Aparte instructie sets zoals de mmx zaken bij de x86 cpu-s zijn voor mij zonder twijfel cisc. Van floating point instructies kan ik mij ook voorstellen dat sommigen vinden dat die cisc zijn, anderen zouden dat wel risc vinden.

[sympa]

Als een MMX/SIMD instructie alleen maar op registers werkt, en niet op data uit RAM/cache, past dat prima in het RISC concept.
Uiteindelijk is een MMX ADD instructie dezelfde adder in de ALU, maar met de carry op 4 plaatsen onderbroken. En een FPU past in RISC. Als je RISC ziet als middel om complexiteit te verminderen.
Bedenk maar hoe je speculatieve programmauitvoering moet maken. Dat knalt uit elkaar als je instructies niet terug kan draaien.
Om die reden zet een x68 de instructies om naar interne RISC instructies. Daarbinnen is het makkelijker om instructies terug te spoelen.
Wikipedia heeft uitleg over Register Renaming een korte uitleg over de Re-order buffer (ROB). Het is interessant, ingewikkeld, en moeilijk om correct te krijgen. Daarom hebben CPUs veel errata.
Bedenk wat er mis kan gaan, bijvoorbeeld een page fault, waar de uitvoer wordt onderbroken, het geheugen wordt bijgeladen (of een page table goed wordt gezet). Dat gebeurt door de CPU, dus die vergeet waar die mee bezig was. Vervolgens moet de uitvoering op het juiste punt doorgaan. Dus instructies in flight moeten worden teruggedraaid, afgemaakt en bewaard, en weer teruggezet.
Hoe meer intrene geneuzel de CPE heeft hoe moeilijker dat wordt om goed te krijgen.
Vergeleken daarmee is het toevoegen wat extra logica aan de ALU eenvoudig, dat is alleen maar extra oppervlak en een ALU kan je makkelijk controleren op correctheid.

[MSalters]

"Dezelfde adder in de ALU" - nou nee. Dat was ook zichbaar aan de snelheid; MMX gebruikte werkelijk 4 adders voor de verschillende delen.

Wat betreft de complexiteit van de page faulting, je hebt gelijk dat het lastig is voor een moderne CPU. CISC is maar een klein deel van de problematiek. Veel erger is de superscalar pipeline en Out-of-Order Execution. Je moet niet alleen de instructie zelf terugdraaien, maar mogelijk ook andere instructies. En bij RISC, met z'n simpele instructies, kunnen dat er veel meer zijn.

[blorf]

Ik denk dat Gates het "gevaar" van RISC heeft gezien. Schaalbare computers was het ergste wat er kon gebeuren. De PC moest een monoliet blijven. Een "micro-LAN onder verschillende delen van de machine is foute boel.
Daarom kijken we nu tegen een MS besturingssysteem aan dat inmiddels richting de TB in omvang gaat en draait op 1 enkele processor die alleen maar doet alsof het er meerdere zijn.

[Reactie gewijzigd door blorf op 25 juli 2024 19:52]

[beerse]

Gates heeft van risk op zich geen gevaar gezien. Gates had het veel meer met Intel op een accoordje gegooid. Gates maakte operatingsystemen voor intel platformen.

Het zal intel zijn die iets tegen risc zou hebben gehad kunnen hebben. Maar ook daar zou ik het zo niet zien: Intel zat, in ieder geval aan de voorkant, tot over haar oren in het cisc kamp. Zij had met de 80186, 80286 en zo laten zien dat zij er vooral veel andere/extra functies in de cpu heeft geplaatst en daarmee de performance van het platform om hoog te tillen. Het cisc was toen 'begonnen' met fpu processoren zoals de x87 varianten die later ook in de cpu zijn gekomen. En daarbij de andere 'instructie sets' voor steeds meer functies.

Intel heeft in de overgang van 32 bits naar 64 bits gekozen voor een nieuw platform itanium, dat zou het moeten gaan worden. Gates was daar geheel in mee, msWindows heeft best lang Itanium als cpu platform ondersteund. Helaas heeft de wereld toen gekozen voor de 64 bits uitbreiding op het x86 platform zoals amd dat maakte. Het itanium platform was wel een aparte in het cisc-risc overzicht. Het was een platform gedragen door Intel en HP, waar Intel uit het cisc kamp kwam en HP met de Pa-Risc processor uit het risc kamp.

[gast128]

Microsoft / Gates zag de opkomst en gevaar van de RISC processoren en ze zijn mede daarom Windows NT begonnen. De oorspronkelijk bouw was voor Intel's i860 maar het OS was bedoeld om overdraagbaar te zijn naar andere processor types (MIPS, i386; later PowerPC en Alpha). Meeste zijn redelijk dood behalve de x86 / x64 lijn.

Bron: Showstopper!

Het hele verschil RICS / CISC is vervaagd. De i486 knipt zijn instructies al op uops.

[SG]

Mijn vermoeden is dat met native cisc implementatie achter elke instructie je ook hardware logic moet implementeren en als nogal wat instructies hebt je nogal wat logic moet implementeren en dan is Cisc opsplitsen in microops handig omdat achter de decoder je stuk minder instructie sets in logic moet implementeren. Mogelijk is dit gevolg van efficienter gebruik maken van diespace. En extenties met hun eigen implementatie zal net als fpu gedeelte uitaard flinke performance boost moeten geven om die diespace daar voor mogen in te nemen.

[sympa]

Omdat je CISC instructies gaat splitsen in aparte load, store en rekeninstructies wordt het moeilijker om de uitvoering te onderbreken bijeen page fault en daarna weer op te pakken. Je gaat dan verder "halverwege" een instructie.
Bij RISC kan je eenvoudiger de registers bewaren, de fault afhandelen, en verder gaan.
Bedenk dat bij een 68000 een enkele instructie 3 of meer geheugenadressen kan raadplegen. Dus je moet dan dezelfde instructie misschien 3 keer opnieuw starten. Ga je dan de toestand van halverwege de instructie opslaan, of start je het hele ding opnieuw?

[Jerie]

Itanium had belabberde performance met backwards compatibility x86-32 terwijl x86-64 (AMD64) nagenoeg 100% performance haalde. Backwards compatibility is belangrijk. Dat weten ze bij Microsoft (kijk maar naar Windows) maar bij Intel blijkbaar niet.

[beerse]

In den beginne had itanium helemaal geen backwards compatibility met pa-risc en x86 cpu's. Dat is bij itanium pas later en/of op software/firmware/microcode basis toegevoegd, vooral omdat de markt er toch wel om vroeg. En ja, alleen maar backwards compatibility naar x86, niet naar pa-risc.

Als je dat nu vergelijkt met hoe Apple met cpu-s om gaat, dan is dat redelijk vergelijkbaar, met het grote verschil dat Apple iets meer controle heeft over de software die op de systemen draait. En ook dat de hardware tegenwoordig iets meer power over heeft om een zekere compatibiliteit te regelen.

Aan de andere kant, heel veel operatingsystemen zijn beschikbaar op een diversiteit aan cpu-s. Zelfs msWindows is tegenwoordig weer beschikbaar op een andere cpu dan de x86-van-dit-moment.

[Jerie]

En toch kon Alpha prima x86-32 emuleren met fx!32, x86-64 prima x86-32, en Rosetta prima PPC op x86-64. Dat is allemaal uit dezelfde tijd. Intel heeft zich enorm verkeken.

Tegenwoordig kun je ook prima x86-64 draaien op M1 ed. met Rosetta 2. Maar dat had Apple met Rosetta 1 ook goed voor elkaar.

En dat is ook de reden dat je minder snel Windows/ARM gaat zien. Software backwards compatibility hebben ze bij MS blijkbaar niet onder controle.

[beerse]

Klopt helemaal als je nu terug kijkt op zaken de wel goed zijn gegaan. Alleen dat Intel zich zou hebben verkeken heb ik iets anders in mijn hoofd zitten. Volgens mij was de ontwikkeling van de itanium cpu heel bewust schoon begonnen met een 64 bits cpu. Of je zou dat 'verkijken' moeten noemen. Naar mijn idee was het gewoon een ontwerp beslissing.

Als je bedenkt welke partijen er toen bij de itanium betrokken waren en van welke cpu-s er kennis en vaardigheid (maar geen compatibiliteit) er in gestoken is, dan durf ik nu te zeggen dat het misschien wel te veel van het goeie was.

[blorf]

RISC ging leiden tot "decentrale" computers. Die waren nu waarschijnlijk in performance schaalbaar geweest per tientje. Een alles omvattend OS op een centrale kern was noodzakelijk om de PC-,markt te handhaven. Het moet een toren zijn...

Op dit moment zien we bij smartphones hetzelfde opnieuw gebeuren (afgelopen +/- 20 jaar.) Zogenaamd een ander type computer, alleen is er niet veel van RISC over. Ze worden voorzien van een "uitgerold" compleet systeen dat langzaam in een reusachtig performance-verslindend gedrocht verandert omdat de toren overeind moet blijven en vooral niet aanpasbaar mag zijn. Ze blijven daardoor permanent langzaam.

[Reactie gewijzigd door blorf op 25 juli 2024 19:52]

[graey]

Wat? Waar haal je dit vandaan en kan je concrete voorbeelden noemen?

[blorf]

Waarvan?

[graey]

Sorry, hoe groot denk je dat Windows is? Dat gaat echt bij lange na niet richting de terabyte. Klok, klepel?

[blorf]

Mijn Windows 10 is 245GB kaal. Zal met 11 wel aardig die kant op gaan, anders worden er geen nieuwe PC's meer verkocht. FreeBSD, wat ik gebruik is compleet met X-desktop minder dan 1,5 GB. Enkel CLI is het +/- 400MB.

[graey]

Dat is redelijk heftig (mijn Windows neemt 30gb in, na een jaar of twee). Maar ook 245gb is nog geen kwart terabyte, natuurlijk

[blorf]

Het is wel een factor 200 van wat nodig is om een computer volledige functioneel te maken.

[graey]

Wat is volledig functioneel? Een terminal? Minix? Of wil je een GUI? Wil je dat het os een stabiele ABI en/of API heeft voor zaken? Of elke update alles hercompileren? Wil je ook zaken als Java, of wil je die buiten beschouwing laten? Vergelijk Windows eens met een standaard gebruikergerichte Linux-distro, en het verschil is een stuk kleiner. Anders moet je Windows wat gaan uitkleden of PE, Embedded of IoT-edities gebruiken. Ik ben geen Windowsfan (arch, manjaro en Debian testing op laptop, desktop en homeserver in die volgorde), maar het is wel een beetje appels en peren. En ik snap nog steeds niet wat het verband is met CPU-architecturen?

[blorf]

Volledig functioneel is alle hardware werkend. Wat zou het anders moeten zijn?

[graey]

Nou ja, vind je je scherm werkend als het scherm aangaat, als alle pixels opgelicht zijn, als het tekst kan weergeven, als er een GUI kan staan... Wat maakt een OS als Windows/Linux/Minix/BSD/OSX anders dan je BIOS of UEFI? Je gooit er nogal wat kritiek op maar het wordt mij niet duidelijk wat er nou beter zou zijn, eerlijk gezegd.

[Ablaze]

Grootste voordeel is waarschijnlijk dat het open source is.
Dat betekent dat kleinere spelers ook processoren kunnen maken (zonder aan licenties vast te zitten) en daardoor ontstaat er meer concurrentie op de markt dan nu, waardoor grote partijen op den duur niet meer achterover kunnen leunen en ontwikkelingen sneller kunnen gaan.

[Reactie gewijzigd door Ablaze op 25 juli 2024 19:52]

[SG]

Ik denk dat dat juist zwaar zal tegen vallen.
De concurrentie nu is de grote platformen en dan met name kip en ei.
Apple en MS en android zijn groot omdat er voor hun grote afzetmarkt is voor hun app stores.

De consument kijkt wat kost en waar de software is wat ze nodig hebben en kiezen dan voor waar de software voor ont wikkeld wordt. En beste toegankelijk is en of save en of betaalbaar , afhankelijk wat consument het belangrijkste vind.

En instructie set soc of cpu is implementatie detail dat ver en heel diep in blackbox wat pc voor hun is.
Draait het vanilla umbunto of andere vanilla popie distro’s.
Kan je daar ook al windows apps en games in emuleren.
En dikke g-kaart in prikken.

[synoniem]

Redelijke performance, 4 GB geheugen en 2 stuks 1 gigabit ethernetpoorten klinkt als een goede kandidaat voor firewall/router als de de prijs een beetje redelijk is.

[The Zep Man]

Grootste obstakel is dat je nog geen kant-en-klare routerdistributies hebt omdat dit een relatief nieuwe architectuur betreft. Als OPNsense/pfSense of OpenWRT images uitkomen wordt het interessant.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 19:52]

[n0np3r50n]

Kan je niet er 1 kiezen en deze distributie zelf compileren?

[SG]

Je hebt compiler nodig die deze instructieset ondersteund.
En in source code mogelijk specifieke low level routines in ifdef else guard path coden.

[n0np3r50n]

Ja iedere chipmaker schrijft zijn eigen extensies toch? Anders kan je geen gebruik maken van de specifieke instructies van de cpu.

[Cergorach]

als de de prijs een beetje redelijk is.

Gezien de prijs van de ontwikkelborden, verwacht ik niet echt lage prijzen...

Bron:
nieuws: SiFive stopt productie HiFive Unmatched-RISC-V-pc, richt zich op nieu...

[TheVivaldi]

Maar die focussen wat meer op high-end (voor zo ver je dat al zo kunt noemen, tenminste). Pine staat juist bekend om hun relatief lage prijzen.

[Reactie gewijzigd door TheVivaldi op 25 juli 2024 19:52]

[fgghhf]

Ik vraag me al een tijdje af in hoeverre het hardware ontwerp van een chip van invloed is op de ISA die je moet gebruiken.

1. zou het technisch(licenties enzo negerend) mogelijk zijn om een ARM chip te laten draaien op de risc-v ISA?? zonder al te veel prestatieverlies??

2. Nog groter, zou het voor apple technisch mogelijk zijn om hun ARM M2 processors te switchen van arm naar risc-v??? met minimaal prestatieverlies.


Niet dat het enige zin/realisme heeft maar ben wel benieuwd naar het technisch antwoord.

[Reactie gewijzigd door fgghhf op 25 juli 2024 19:52]

[sympa]

Bedoel je emulatie? Zoals Apple M2 ook x86-software kan draaien?

[TheVivaldi]

Apple is al bezig met RISC-V: https://www.tomshardware....ng-for-risc-v-programmers

[Reactie gewijzigd door TheVivaldi op 25 juli 2024 19:52]

[graey]

Nee, Apple kan bestaande chips niet omkitten naar een andere ISA. Een nieuwe chip bouwen kan wel, en ze zijn vast aan het spelen met RISC-V. Emulatie beide kanten op moet mogelijk zijn, echter de vraag is hoe performant. Door het specifieke ontwerp van M1 en opvolgers is x86-emulatie niet heel 'duur', het zal afhangen van welke RISC-V-implementatie wordt gekozen om te emuleren. En met welk doel.

[Sharkys]

Prima bericht, toch is het onbekend zijn van de prijs echt een gemis. Alvorens je een prijs kwaliteit afweging kan maken hebben dergelijke artikelen weinig nieuwswaarde.

[Verwijderd]

rond de 60-70 USD, op z'n Amerikaans, dus ex VAT ex shipping

Dus rond de 100 euro in huis in Nederland

[klonic]

Ik vind het wel degelijk waardevol om te weten dat er iets aan komt, ook als ik de prijs later pas te weten komt. Ook niet iedereen die iets leest wil het meteen kopen of het in een commercieel perspectief bekijken.

[pljanson]

Als dadelijk de RISC V linux kernel en omgeving mainline is (en daar helpt een geodkoop beschikbaar board bij), maakt het niet veel uit of het RiscV of ARM is en kan iedere distributie relatief simple geport worden, net zo als nu steeds gebeurt met nieuwe ARM socs (kijk maar naar de gemelde RK3566 die nu meer distros krijgt nu de SOC meer mainline support krijgt).
Maar alle featuures van een nieuwe SOC (en de GFX) in mainline linux (en mesa) krijgen duur toch meetsal wel een tijd.
Dus eerst goedkoop board dan mainlinene en daarna is het pas iteresat voor consumenten (niet limnnux of mesa developers).
Ik hoop op success WANT: een opensourse ISA zorgt datje niet de problemen krijgt zo als met ARM in het verleden dat de android update niet mogelijokl was omdat de SOC leverancier geen nieuwe binairies maakt voor nieuwere versie (zo als bij fairphone was te zien). Maar damn moeten eigenljk alle IP componenten opensource zijn en geen vendor blogs hebben (zoals Wifi BT chips enzo).

[likewise]

Linux kernel heeft al geruime tijd RISC-V mainline toch?

[Verwijderd]

Zeker. Ik draai al een tijdje Armbian/Ubuntu met Linux 5.19 op mijn RISCV boardje.

$ uname -a
Linux nezha 5.19.0-rc1-d1 #trunk Fri Jul 22 12:44:22 MSK 2022 riscv64 GNU/Linux

[Reactie gewijzigd door Verwijderd op 25 juli 2024 19:52]

[likewise]

Precies.

Als dadelijk de RISC V linux kernel en omgeving mainline is

Nu de RISC V linux kernel en omgeving mainline is

[Reactie gewijzigd door likewise op 25 juli 2024 19:52]

[synoniem]

Welk RISCV boardje heb jij en is het enigszins betaalbaar?

[Verwijderd]

Sipeed Lichee RV Dock Allwinner D1 Development Board RISC-V Linux Starter Kit

Destijds 32 euro incl shipping & EU tax. Inmiddels iets duurder

Werkt heel makkelijk & heel goed met https://forum.armbian.com...build-support-for-risc-v/ : image naar sd-kaart schrijven, en booten.

EDIT: snelheid is laag: iets tussen Raspi 1 en Raspi 2 in. Dat Armbian image biedt grafische interfaces (icewm, xfce), maar ik hou het bij command-line.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 19:52]

[Jerie]

Pine64 hintte eerder al op een nieuwe singleboardcomputer, maar geeft nu voor het eerst details over de Star64.

Wat ook in dat nieuwsbericht staat, en waar Tweakers waarschijnlijk geen nieuw item over gaat maken, is het feit dat de Pinecil (soldeerbout met OLED scherm dat draait op RISC-V) aan een tweede iteratie begint, en binnenkort ook weer in stock is.

[n0np3r50n]

Net de community update video bekeken en ik vroeg mij al af wat dat was. Waarom zo'n scherm?

[Azbest]

De Star64 heeft daarnaast een PCI-e-aansluiting

Gelukkig nemen ze I/O eindelijk serieus. Voor mij altijd de reden geweest SBC's nooit als serieuze concurrentie te zien in de desktopmarkt.

[FreeLighting]

Maar er komt 'op een later moment' een goedkopere variant uit die slechts een ethernetpoort heeft.

Deze variant is naar verwachting $5 goedkoper, aldus de update van Pine64:

A version with only one Ethernet port will also be available at a later date, and we expect it to cost $5 less.

[Reactie gewijzigd door FreeLighting op 25 juli 2024 19:52]

[mutley69]

Als de raspberry pi4B met 4GB of meer ram niet snel beschikbaar komt - zie ik deze RiscV implementatie nog met een pak van de markt gaan lopen!

[Jack Flushell]

Wat?

[Amanoo]

RISC V is erg populair aan het worden. Ik zie het steeds meer verschijnen. Sommige ESP32 modellen hebben ook een RISC V coprocessor of zelfs als hoofdprocessor. En je ziet steeds meer andere producten waar RISC V in zit.