SiFive esitteli seuraavan sukupolven Performance P650 RISC-V-ytimen

[Kaotik]

Kaotik kirjoitti uutisen/artikkelin:
Maailmalla tietokoneet ja puhelimet pyörivät pääasiassa Arm- ja x86-arkkitehtuureihin perustuvilla prosessoreilla. Viime vuosina avoin RISC-V on kuitenkin kehittänyt pöhinää ympärilleen etenkin SiFiven johdolla. Jopa x86-jätti Intel on tarttunut arkkitehtuuriin ja tulee tekemään SiFiven RISC-V-ytimiin perustuvia prosessoreita. Huhujen mukaan Intelin huhuttiin yrittäneen jopa ostaa SiFiven, mutta kaupat eivät ikinä realisoituneet.

Nyt SiFive on julkaissut uuden prosessorin, tai pikemminkin prosessori-IP:n integroitavaksi järjestelmäpiireihin. SiFiven uutuus tottelee nimeä Performance P650 ja se rakentuu parhaimmillaan 16 ytimestä. RISC-V-ydinten arkkitehtuuri perustuu vahvasti edeltävään P550-arkkitehtuuriin, mutta kasvattamalla käskyjaon leveyttä (instruction-issue width) ytimet ovat nyt 40 % nopeampia kellolta kellolle ja muiden arkkitehtuurin viilausten myötä käytännössä 50 % nopeampia.

Yhtiön arvioiden mukaan P650-ydin yltää yli 11 pisteeseen per GHz SPECInt2006-testissä, kun P550-ytimellä päästiin 8,65 pisteeseen per GHz. 16 ytimen voimin P650 sopii yhtiön mukaan nyt high-end luokan laskentatehtäviin ja tukee uutta RISC-V Hypervisor -laajennoksia virtualisointiin.

SiFiven mukaan se tulee aloittamaan Architecture Preview -esittelyt suurimmille asiakkailleen ensi vuoden ensimmäisen neljänneksen aikana. Yleisesti lisensoitavaksi ytimet tulevat vuoden puolivälin tienoilla. Yhtiö tulee kertomaan lisää uusista Performance P650 -ytimistä vielä RISC-V Summit 2021 -tapahtumassa 6.-8. joulukuuta.

Lähde: SiFive, Tom's Hardware

Linkki alkuperäiseen juttuun

 

[hkultala]

... ja ARM Neoverse N1llä jo melkein 3 vuotta sitten 14 specINT20006/GHz.

Aika pahasti on RISC-V ARMia jäljessä. Eikä tule koskaan saavuttamaan, koska standardista RISC-V-käskykannasta puuttuu oleellisia suorituskyvyn kannalta tärkeitä asioita (mm. kunnolliset muistinosoitusmuodot ja ehdolliset siirrot), ja RISC-V-standardointikomitea ei näitä suostu lisäämään koska ne on "monimutkaistavia ja epä-RISCmäisiä". Ja epästandardeille laajennoksille ei saa kunnollista kääntäjätukea.

Ja ehdollista siirtoa vastaava select-käsky meinattin tosiaan lisätä viralliseen B-laajennokseen (bit manipulation), mutta poistettiin siitä viime hetkeltä ennen standardin virallisen release candidaten julkaisua, koska 1980-luvulle jämähtäneen komitean mielestä käsky joka ottaa 3 operaandia on epä-RISC-mäinen)

 

[hkultala]

Ja SiFive itse vertaa tuota mm. yli 4 vuotta vanhaan Cortex A75een ja hypettää kuinka voittaa sen. ARMilta on vaan tullut monta sukupolvea A75sta uudempia ja parempia ytimiä (mm. Cortex A76, A77, A78) jotka eivät kuitenkaan ole merkittävästi isompia.

Kertoo aika paljon siitä kuinka hyvillä pohjilla mennään, kun pitää tehdä näin vinoon meneviä vertailuita.

 

[Nerkoon]

Mikä noiden teho on suhteessa ARM malleihin?

 

[mopnex]

Olisi kiinnostava kyllä silti lukea lisää RISC-V ja yleisesti mikroprosessoriarkkitehtuureista. Tämä kirja on nyt Inside the Machine luettavana, ja hyvin kirjoitettu kirja.

Mikä noiden teho on suhteessa ARM malleihin?

Tuossa ylempänä @hkultala jo vähän antoi osviittaa siitä kategoriasta mihin nuo menevät.

 

[HerraHumppa]

... ja ARM Neoverse N1llä jo melkein 3 vuotta sitten 14 specINT20006/GHz.

Aika pahasti on RISC-V ARMia jäljessä. Eikä tule koskaan saavuttamaan, koska standardista RISC-V-käskykannasta puuttuu oleellisia suorituskyvyn kannalta tärkeitä asioita (mm. kunnolliset muistinosoitusmuodot ja ehdolliset siirrot), ja RISC-V-standardointikomitea ei näitä suostu lisäämään koska ne on "monimutkaistavia ja epä-RISCmäisiä". Ja epästandardeille laajennoksille ei saa kunnollista kääntäjätukea.

Ja ehdollista siirtoa vastaava select-käsky meinattin tosiaan lisätä viralliseen B-laajennokseen (bit manipulation), mutta poistettiin siitä viime hetkeltä ennen standardin virallisen release candidaten julkaisua, koska 1980-luvulle jämähtäneen komitean mielestä käsky joka ottaa 3 operaandia on epä-RISC-mäinen)

Mutta rajoittamalla käskykannan kokoa ja kompleksisuutta saadaan pienemmät ytimet. Miten tuo sitten vaikuttaa energiatehokkuuteen, paraneeko vai huononee? Luulisi että tuo on tärkeä kriteeri jos näitä on suunniteltu tietyt sovelluskohteet mielessä. Pintapuolisesti tarkasteltuna minusta vaikuttaa, että näitä on suunnattu kustannustehokkaisiin ja pieniin laitteisiin, ei niinkään taistelemaan suorituskykykuninkuudesta.

 

[hkultala]

Mutta rajoittamalla käskykannan kokoa ja kompleksisuutta saadaan pienemmät ytimet.

Ei saada, paitsi silloin kun tehdään jotain äärimmäisen yksinkertaisia, pieniä ja hitaita ytimiä. Ja niissä esim. tuki RISC-V:n C-moodille (16-bittiä pitkät käskyt) aiheuttaa helposti paljon enemmän monimutkaistusta kuin ARMv8n muuten rikkaampi käskykanta.

Kun halutaan yhtään kunnollista suorituskykyä, jotta päästäisiin edes lähelle ARMv8ia (ei tasoihin), RISC-V:ssä joudutaan tekemään aggressiivisemmin temppuja kuten käskyfuusio, ja se monimutkaisuus mitä näistä tempuista tulee on paljon suurempi kuin se monimutkaisuus, mikä tulisi siitä että se enemmän tekevä käsky löytyisi suoraan käskykannasta.

Miten tuo sitten vaikuttaa energiatehokkuuteen, paraneeko vai huononee?

Osoitteenlaskenta + lataus joka ARMilla vaatii yhden käskyn ja kirjoittaa tuloksen yhteen rekisteriin ja RISC-Vllä vaatii joko 2 tai 3 käskyä ja kirjoittaa 2-3 rekisteriin vie RISC-V:llä aika paljon enemmän virtaa. Ylimääräisistä kirjoituksista kun ei tule pelkästään sitä itse rekisterin kirjoituksen virrankulutusta, vaan suorituskykyisemmällä ytimellä myös virrankulutus rekisterien uudelleennimeämisen kirjanpitotaulukon päivittämisestä, ja lisäksi saman suorituskykyyn tarvitaan suurempi määrä fyysisiä rekistereitä joihin arkkitehtuurillisia rekistereitä voidaan uudelleennimetä.

Tai toisinpäin, saman kokoisella fyysisellä rekisterifileellä ja samalla määrällä rekisterikirjoituksia ja rekisterien uudelleennimeämisiä ARM tekee enemmän hyödyllistä työtä.


Ja ehdollisten siirtojen/select-käskyn puuttuminen. Kun koodissa pitää valita hyvin satunnaisesti kahden arvon väliltä, ja kääntäjä tietää, että valinta on hyvin satunnainen, ARM-kääntäjä tekee siihen select-käskyn ja prosessori odottelee kunnes ehto lasketaan kunnes suorittaa tämän select-käskyn. (tai no, suorittaa ehkä muita, tästä riippumattomia käskyjä, jtoka piti joka tapaukessa suorittaa)

RISC-V-kääntäjä tekee tästä ehdollisen hypyn ja kaksi erillistä siirtokäskyä. ja kun koodia suoritetaan, haarautumisennennustus yrittää arvata, pitääkö hypätä vai ei, ja jos se arvaa oikein, kaikki sujuu kauniisti ja kivasti. Mutta jos arvataan väärin, prosessorin liukuhihnalle on jo ehditty ladata kymmeniä käskyjä väärästä paikasta ja laskea jotain väärällä tuloksella, ja kaikki tämä (joka on jo kuluttanut selvästi virtaa) pitää heittää menemään ja aloittaa koodin suoritus siitä oikeasta haarasta => paljon turhaa virrankulutusta.

Ja mikäli tämä valinta on todella satunnainen, se haarautumisenennustus ennustaa väärin 50% tapauksista.


Molempien ominaisuuksien suhteen virrankulutusetu on aika selvä prossulle, jossa ilmaisuvoimaisempi käskykanta.

uulisi että tuo on tärkeä kriteeri jos näitä on suunniteltu tietyt sovelluskohteet mielessä. Pintapuolisesti tarkasteltuna minusta vaikuttaa, että näitä on suunnattu kustannustehokkaisiin ja pieniin laitteisiin, ei niinkään taistelemaan suorituskykykuninkuudesta.

RISC-V-käskykanta on suunniteltu yksinkertaiseksi käskykannaksi opetuskäyttöön, ei mihinkään laitteisiin. Se eroaa aiemmista DLXstä yms opetuskäyttöön suunnitelluista lelukäskykannosita lähinnä kahdella tavalla:

1) Se tukee virtuaalimuistia, keskeytyksiä yms. ominaisuuksia että sen päällä voi (lähinnä opetuskäytössä) ajaa todellista käyttöjärjestelmää, sitä voi käyttää muidenkin asioiden opetukseen kuin tietokonearkkitehtuurien perusteiden opetukseen.

2) Siitä on poistettu 1980-luvun RISCien suurimmat typeryydet kuten delay slotit


RISC-V kuitenkin soveltuu kohtalaisen hyvin oikeisiin laitteisiin kun sitä ei käytetä sellaisenaan CPUna vaan sitä käytetään vaan "alustana" jonka päälle tehdään omia laajennoksia erikoistuneita käyttötarkoituksia varten ja tehdään sitten oma kääntäjä joka näitä osaa käyttää. Eli tehdään ASIPeja (Application Specific Instruction-set Processor) eikä CPUita.

 

[hsalonen]

Aika pahasti on RISC-V ARMia jäljessä. Eikä tule koskaan saavuttamaan, koska standardista RISC-V-käskykannasta puuttuu oleellisia suorituskyvyn kannalta tärkeitä asioita (mm. kunnolliset muistinosoitusmuodot ja ehdolliset siirrot), ja RISC-V-standardointikomitea ei näitä suostu lisäämään koska ne on "monimutkaistavia ja epä-RISCmäisiä". Ja epästandardeille laajennoksille ei saa kunnollista kääntäjätukea.

Ja ehdollista siirtoa vastaava select-käsky meinattin tosiaan lisätä viralliseen B-laajennokseen (bit manipulation), mutta poistettiin siitä viime hetkeltä ennen standardin virallisen release candidaten julkaisua, koska 1980-luvulle jämähtäneen komitean mielestä käsky joka ottaa 3 operaandia on epä-RISC-mäinen)

Koko RISC:in idea on olla mahdollisimman yksinkertainen käskyjoukko. Reduced Instruction Set Computer.... "Pienten lisäysten" jälkeen ollaan jo ensimmäisiä x86-arkkitehtuureja vastaavissa käskyjoukoissa.

 

[Dudem]

Katselin tuota heidän kotisivuilla olevaa tarjontaa näistä alustoista ja huomasin, että siellä oli tuommoinen Raspberry Pi:n tapainen alusta tarjolla, mutta tuohan on jo pari vuotta vanha eivätkä ilmeisesti ole sitä päivittäneet näillä uudemmilla ytimillä. Jotenkin kuvittelisin saavan tämän enemmän tekijöitä ja kiinnostusta kun panostaisivat noihin halpoihin alustoihinsa vähän enemmän. Toki RPi:llä on jo tunnettuvuus, softaa ja alustoja reilusti.

 

[hkultala]

Koko RISC:in idea on olla mahdollisimman yksinkertainen käskyjoukko. Reduced Instruction Set Computer....

Tällä ei ole oikeasti mitään tekemistä käskyjen määrän vaan monimutkaisuuden kanssa.

RISCin idea on olla helposti liukuhihnoitettava käskykanta.

Tämä tarkoittaa mm. sitä, että
1) Käskydekoooderi on mahdollisimman yksinkertainen
1.1) Rekisterikentät ja opkoodit on käskykanassa aina mahdollisimman samassa paikassa (mahdollisimman vähän eri käskyformaatteja)
1.2) Ei muuttuvanmittaisia käskyjä (arvaa, kumpi tätä rikkoo, RISC-V tyypillisellä konfiguraatiollaan vai ARMv8?)
2) Sama käsky ei sekä laske että käsittele muistía, vaan lataus ja laskenta tehdään erillisillä käskyillä
3) Mitään käskyjä ei tarvi kierrättää liukuhinan perusosien läpi montaa kertaa

Se, että lisätään käskyjä jotka ottavat operandinsa sisään samassa muodossa kuin muutkin käskyt ja tuottavat yhtä monta tulosta kuin muutkin käskyt eivät tarvi uusia käskyformaatteja, ja ne lisäävät hyvin vähän monimutkaisuutta oleellisiin osiin, ja ne eivät ole millään tavalla RISC-filosofian alkuperäisten ideoiden vastaisia.

Esimerkkejä tällaisista käskyistä olisi esim. logiikkakäskyt, joissa toinen inputti olisi negatoitu, tai min/max-käskyt.


Mutta tosiaan, jo 1990-luvulla opittiin, että monimutkaisematkin käskyt on dekooderissa helppo pilkkoa osiin, joten monimutkaisempiakin käskykantoja saadaan helpolla liukuhihnoitettua, lähinnä hinnaksi tulee ylimääräinen liukuhihnavaihe tai pari ylimääristä liukuhihnavaihetta dekoodereissa. Liian monimutkainen enkoodaus kuitenkin alkaa käymään dekooderille kalliiksi, mikäli halutaan dekoodata montaa käskyä rinnakkain ja mahdollisia eri käskynpituuksia on useita (ei tiedetä, mistä seuraavaa käskyä pitäisi alkaa dekoodaamaan).

"Pienten lisäysten" jälkeen ollaan jo ensimmäisiä x86-arkkitehtuureja vastaavissa käskyjoukoissa.[

Ei todellakaan olla.

Jo alkuperäisessä 8086-käskykannassa on monia kymmeniä eri käskyformaatteja, ja ties mitä desimaaliaritmetiikkaa ja hyvin pitkään ajautuvia erikoiskäskyjä muistin kopioinnille tai muistin alustamiselle vakiolla.

Se, että lisätään järkevät osoitusmuodot sekä select- käsky tai ehdollinen siirto tarkoittaa n. kolmea käskyformaattia lisää kokonaislukupuolelle, ja kun laskee liukulukukäskyt mukaan niin kokonaisuudessaan ehkä n. kuutta.

Toisaalta, RISC-V:n hyvin yleinen C-moodi lisää n. 12 käskyformaattia lisää, eli luokkaa tuplasti enemmän kuin mitä noista suorituskyvyn kannalta oleellisimmista (mutta RISC-V:stä puuttuvista) tulisi.

Että niiden järkevien osoitusmuotojen ja selectin käskykanta monimutkaistava vaikutus on ziljoona kertaa pienempi kuin x86-käskykannan monimutkaistus ja selvästi pienempi kuin RISC-V:n C-moodin käskykantaa monimutkaistava vaikutus.

 

[hsalonen]

@hkultala muistan asiat hieman erilailla, mutta tuo selityksesi on järkeenkäypä ja on myös mahdollista, että ymmärsin ne silloin aikoinaan väärin oppitunneilla (ja meillä oli MIPS ja SPIM, eikä RISC harkkatyössä, eikä Patterson & Hennessy vielä ollut aloittanut tuota "eri arkkitehtuureille eri kirja"-rahastusta).
..mutta tuli taas semmoinen määrä tekstiä, että pitää tarkemmin katsoa paremmalla ajalla viikonloppuna.

 

[Wintermute]

... ja ARM Neoverse N1llä jo melkein 3 vuotta sitten 14 specINT20006/GHz.

Aika pahasti on RISC-V ARMia jäljessä. Eikä tule koskaan saavuttamaan, koska standardista RISC-V-käskykannasta puuttuu oleellisia suorituskyvyn kannalta tärkeitä asioita (mm. kunnolliset muistinosoitusmuodot ja ehdolliset siirrot), ja RISC-V-standardointikomitea ei näitä suostu lisäämään koska ne on "monimutkaistavia ja epä-RISCmäisiä". Ja epästandardeille laajennoksille ei saa kunnollista kääntäjätukea.

Ja ehdollista siirtoa vastaava select-käsky meinattin tosiaan lisätä viralliseen B-laajennokseen (bit manipulation), mutta poistettiin siitä viime hetkeltä ennen standardin virallisen release candidaten julkaisua, koska 1980-luvulle jämähtäneen komitean mielestä käsky joka ottaa 3 operaandia on epä-RISC-mäinen)

Ehkä vähä höhlä kysymys/ajatus, mutta jotenkin pitänyt teikäläisen (@hkultala) jutuista jo murobbs ajoista ja varsinkin et olet _suomalaista_ insightia piirisuunnitteluun tuonut julki. Ei sillään mitään @Diizzel ja @Kaotik vastaan tai oli tällä viikolla todella hyvä tekniikka podcasti tai mikä se nyt onkaan nimeltään, mutta kun alettiin RISC-V uudesta piiristä höpisee nii aika vähäiseksi jutut jäi. Tai olisiko ihan mahdoton ajatus et hkultala haluaisi youtubes/podcastissa vähä ""blastata"" faktoja uutisiin tai tällästä ku mennään syvällisiin aiheisiin? Vai onko tämä sitte vähä sellasta osa-aluetta ettei massoja kiinnosta ja parempi tästä "foorum-mössöstä" syödä? Toki joo jossei herraa itse kiinnosta missä youtubes höhlistä niin ei .

Onkos toi nyt järjetön ongelma et RISC-V on jotain ARM high-endiä jäljessä? Tai etkös jossain Alder lake-uutisessa huudellut et Intelin pitäisi enemmän heittää lastulle gracemont-ytimia ku palvelinympäristössä ehkä olis vähä optimaalisimpaa olla paljon pienempi ytimiä. Varsinki jos jotain kubeklusteria joutuu itse pyörittää "microserviceille" ehkä sopeutuu tohon malliin paremmin, että paljon energiatehokkaita ytimiä. Toki jo ARM64/Armv8 tuki ollut vähä jähmeetä monessa high-end kielessä. Et ei ehkä siinä mielessä RISC-V nappaa ollenkaan. Ja toki tietyillä kuormilla kuten tietokantojen, ML, video-pakkaus/purku tai jossai tälläisessä missä halutaan kenties FP-suorituskykyä tai ihan yhdenki ytiminen suorituskykyä mitä RISC-V ei hetkeen tarjoa, mutta tietyissä käyttötapauksissa ei välttämäti ihan lapanen olisi. Tosi Amazonill se verta kova investointi jo omiin armeihin (Graviton 3 taisi juuri tulla ulos), että tuskin kenelläkään oikein on tuohon skeneen resursseja tuoda mitään RISC-V lastuja ihan hetkeen (toki joo jossai azure/gcn/etc yms IO-piireissä tai missä tahansa saattaa olla jtn customia mutta mitä end-userille tarjolla on lähinnä x86 ja ehkä armv8).

 

[Kaotik]

Ehkä vähä höhlä kysymys/ajatus, mutta jotenkin pitänyt teikäläisen (@hkultala) jutuista jo murobbs ajoista ja varsinkin et olet _suomalaista_ insightia piirisuunnitteluun tuonut julki. Ei sillään mitään @Diizzel ja @Kaotik vastaan tai oli tällä viikolla todella hyvä tekniikka podcasti tai mikä se nyt onkaan nimeltään, mutta kun alettiin RISC-V uudesta piiristä höpisee nii aika vähäiseksi jutut jäi. Tai olisiko ihan mahdoton ajatus et hkultala haluaisi youtubes/podcastissa vähä ""blastata"" faktoja uutisiin tai tällästä ku mennään syvällisiin aiheisiin? Vai onko tämä sitte vähä sellasta osa-aluetta ettei massoja kiinnosta ja parempi tästä "foorum-mössöstä" syödä? Toki joo jossei herraa itse kiinnosta missä youtubes höhlistä niin ei .

RISC-V kuuluu aiheisiin "ei kiinnosta massoja". Puolustuksekseni lisäisin että uskoisin osaavani kertoa hkultalaa syvällisemmin (psykiatrisesta) sairaanhoidosta

 

[finWeazel]

Joissain tapauksissa arm:in lisensointimaksu voi olla hapokkaampi kuin risc-v:n suorituskyky.

 

[Wintermute]

RISC-V kuuluu aiheisiin "ei kiinnosta massoja". Puolustuksekseni lisäisin että uskoisin osaavani kertoa hkultalaa syvällisemmin (psykiatrisesta) sairaanhoidosta

Selvä homma Eiköhän sielläkin kuule kaikenlaista syvällistä tai ehkä en nyt tuollaista tarkoittanut. Ihan kiva silti et uutisissa jaksaa olla vähän teknisempääkin tauhkaa tuotejulkistuksien, huhujen, ajuriuutisisten yms välissä ihan näin etusivullakin. Ja et eräät jaksaa vieläkin sivistää vuosien jälkeen kommenteillaan

 

[jive]

Jo alkuperäisessä 8086-käskykannassa on monia kymmeniä eri käskyformaatteja, ja ties mitä desimaaliaritmetiikkaa ja hyvin pitkään ajautuvia erikoiskäskyjä muistin kopioinnille tai muistin alustamiselle vakiolla.

no tuo on Von Neumann kone, jonka käskykanta tukee sitä että ihminen ohjelmoi sitä suoraan konekielellä. Suhteellisen kaukaa haettu vertaus.
Itseäni kiinnostaa enemmän arkkitehtuurin aito avoimuus ja räätälöintimahdollisuudet.

 

[hkultala]

no tuo on Von Neumann kone, jonka käskykanta tukee sitä että ihminen ohjelmoi sitä suoraan konekielellä. Suhteellisen kaukaa haettu vertaus.
Itseäni kiinnostaa enemmän arkkitehtuurin aito avoimuus ja räätälöintimahdollisuudet.

Mitä ihmettä nyt oikein sekoilet?

Ymmärrätkö yhtään, mitä sana "käskyformaatti" tarkoittaa?

En puhunut mitään vertauksia vaan ihan suoria faktoja RISC-V- ja x86-käskykantojen eroista.

 

[jive]

Mitä ihmettä nyt oikein sekoilet?

Ymmärrätkö yhtään, mitä sana "käskyformaatti" tarkoittaa?

En puhunut mitään vertauksia vaan ihan suoria faktoja RISC-V- ja x86-käskykantojen eroista.

Vaikea sanoa. Yleensä kun yrittää jotain keskustella menee sinun vastauksesi henkilökohtaisuuksiin. Oletan että haet sitä että konekäskyillä on erilaisia osoitusmuotoja ja eri määriä operaation parametrejä. Ei se muuta sitä että ARM ja RISC-V on tehty korkeamman tason kielet mielessä kun taas alkuperäinen x86 kanta suunniteltiin ihmiselle helpoksi mieltää. Vaikka suoraa yhteyttä RISC ja Harward, CISC ja Von Neumann ei olekaan niin usein ISA sitä heijastelee.

Minulle oleellista RISC-V arkkitehtuurissa on riittävä suorituskyky ja mahdollisimman yksinkertainen SoC rakenne nykyään on hyvin vaikea löytää IoT tai teollisuus/ajoneuvokäyttöön soveltuvia piirejä ilman mitään ylimääräisiä oheispiirejä. Toiveissa olisi että tälle alustalle moisia saisi räätälöityä.

 

[hkultala]

Vaikea sanoa. Yleensä kun yrittää jotain keskustella menee sinun vastauksesi henkilökohtaisuuksiin.

Se, että kysyn, oletko ymmärtänyt teknistä termiä oikein ei ole henkilökohtaisuuksiin menoa, kun lauot aivan käsittämättömia aiheeseen täysin liittymättömiä kommentteja.

Oletan että haet sitä että konekäskyillä on erilaisia osoitusmuotoja ja eri määriä operaation parametrejä.

Juu, oikein meni.

Ei se muuta sitä että ARM ja RISC-V on tehty korkeamman tason kielet mielessä kun taas alkuperäinen x86 kanta suunniteltiin ihmiselle helpoksi mieltää. Vaikka suoraa yhteyttä RISC ja Harward, CISC ja Von Neumann ei olekaan niin usein ISA sitä heijastelee.

Tällä käskyformaattien määrällä ei ole mitään tekemistä sen kanssa, miten sitä ohjelmoidaan. Että se, että tuot tähän mukaan jotain "korkeamman tason kieliä" ja "ihmiselle helposti miellettävää" on ihan täyttä sekoilua.

Edes asmia koodaava koodarikaan ei niitä käskyformaatteja näe, koska assembly abstrahoi ne pois, ja asm-koodari joutuu niistä piittaamaan ainoastaan jos alkaa käsin optimoimaan koodin kokoa (eikä suorituskykyä) jolloin se, että siellä on paljon erilaisia käskyformaatteja on vaan hankaloittava tekijä sille asm-koodarille.

Käskyformaatien määrässä kyse ihan täysin siitä,
1) kuinka monimutkainen se prossun käskydekooderi on ja kuinka helpolla tiedetäään mistä seuraavan käskyn dekoodaaminen tai hakeminen pitää aloittaa.
2) kuinka paljon käskymuistia koodi vie.
3) mahdollistaako käskyformaatit tiettyjen käteviä asioita tekevien käskyjen toteutuksen vai joudutaan jotkut kätevät (suorituskykyä parantavat/virrankulutusta pienentävät) käskyt jättämään pois jottei niille tarvi tehdä omaa käskyformaattia.
4) ja RISC-V:n tapauksessa vielä, kuinka helpolta prossun toiminta saadaan näyttämään oppikirjassa.

Verrattuna ARMv8iin, RISC-Vssä on jätetty pois select/cmov sekä järkevät osoitusmuodot ettei niille tarvi tehdä pientä määrää uusia käskyformaatteja, mutta kuitenkin RVC tuo paljon suuremman kasan uusia käskyformaatteja.

Minulle oleellista RISC-V arkkitehtuurissa on riittävä suorituskyky ja mahdollisimman yksinkertainen SoC rakenne nykyään on hyvin vaikea löytää IoT tai teollisuus/ajoneuvokäyttöön soveltuvia piirejä ilman mitään ylimääräisiä oheispiirejä. Toiveissa olisi että tälle alustalle moisia saisi räätälöityä.

Sillä, onko käskykanta RISC-V vai ARM ei ole mitään käytännön vaikutusta siihen, millaisia väyliä sieltä prossulta voidaan vetää ulos, ainakaan RISC-V:lle edulliseen suuntaan. Käytännössä sitten kun mennään debuggauspuoleen jne. niin niille ARMilla on parempi infrastruktuuri kuin RISC-V:lle.

Että se RISC-V CPUna ei ainakaan käytännössä helpota minkään järkevän SoCn tekemistä ARMiin verrattuna. Toki, jos halutaan tehdä kouluprojektina minimibudjetilla joku lelu, eikä haluta maksaa penniäkään lisensimaksuja ARMille, sitten RISC-Vssä on pointtinsa. Rankasti kustomoidun RISC-Vn käyttö pohjana ASIPille onkin sitten jo järkevämpää, mutta silloinkin sinne piirille kannattaa laittaa joku ARM CPU:ksi.

Ja "riittävä suorituskyky" on aika tulkinnavaraista/suhteellista. ARMilla saadaan joko parempi suorituskyky, tai sama suorituskyky pienemmällä virrankulutuksella tai pinta-alalla.

 

[jive]

Tämä on vähän kuin kysyisi mikä on paras fillari. Minua kiinnostaa ohjelmointimalli ja varsinaiset piirit ei RTL tason rakenne. Ihan tietysti kiva että joku jaksaa kirjoittaa pitkät tarina siitä miten liukuhihna toimii, mutta sillä ei ole merkitystä. Olisi paljon mukavampi kuulla ajatuksia siitä mihin RISC-V soveltuu kuin siitä mihin se ei sovellu tai miten suorittimen rakenne ei ole optimaalinen. Ei minulla ole tarpeen tietää fillarin pakan hampaiden kohtaus kulmista tai liukukitkan minimoimisesta kun olin kysymässä mikä työmatkakulkine olisi paras 500€ hintaluokassa.

 

[hkultala]

Tämä on vähän kuin kysyisi mikä on paras fillari. Minua kiinnostaa ohjelmointimalli ja varsinaiset piirit ei RTL tason rakenne. Ihan tietysti kiva että joku jaksaa kirjoittaa pitkät tarina siitä miten liukuhihna toimii, mutta sillä ei ole merkitystä.

Voi huoh.

Sen SoC-piirin käskykanta ei vaikuta sen SoClle koodia kirjoittavan C-koodarin normaaliin työhön käytännössä millään muulla tavalla kuin sillä, mikä parametri sen ristiinkääntäjän target-flagiksi annetaan (tai siis annetaan configure-scriptille, joka kirjoittaa sen makefileeseen). Koska se kuitenkin kirjoittaa C-koodia, ei mitään asmia.

Ohjelmointimalli siten miten se näkyy Ctä koodaaavalle koodarille on täysin identtinen ARMin kanssa.

Että jos tuo on näkökulmasi, niin sinulla ei pitäisi olla mitään kiinnostusta koko käskykantaa kohtaan.

Sen sijaan se käskykanta oikeasti vaikuttaa sen piirin CPUn suorituskykyyn ja koodin kokoon.

Olisi paljon mukavampi kuulla ajatuksia siitä mihin RISC-V soveltuu kuin siitä mihin se ei sovellu tai miten suorittimen rakenne ei ole optimaalinen. Ei minulla ole tarpeen tietää fillarin pakan hampaiden kohtaus kulmista tai liukukitkan minimoimisesta kun olin kysymässä mikä työmatkakulkine olisi paras 500€ hintaluokassa.

RISC-V on CPU-käskykanta. Se soveltuu siihen, että sille käännetään koodia, ja että suunnitellaan mikroarkkitehtuureita, jotka sen toteuttavat. Se on turing-täydellinen, sillä voi suorittaa ihan mitä tahansa koodia, kunhan vaan muisti riittää. Ratkaisevaa on se, että onko se suorituskyvyn kannalta järkevää.

Jos mietitään korkean tason käyttökohteita(mitä ilmeisesti ajat takaa), eivät ne piittaa siitä, mitä käskykantaa kaukana alla olevassa prossussa käytetään, paitsi että sen alla olevan prossun suorituskyky-pitna-ala-energiankulutus-suhde olisi mahdollisiman htvä. Mitä se RISC-Vllä CPU-käytössä ei ole, eikä siihen vaikuta se, onko se piiri autossa, lentokoneessa, pesukoneessa, puhelimessa, läppärissä vai pöytäkoneessa.

 

[jive]

Se, että kysyn, oletko ymmärtänyt teknistä termiä oikein ei ole henkilökohtaisuuksiin menoa, kun lauot aivan käsittämättömia aiheeseen täysin liittymättömiä kommentteja.

kysyä voi monella tapaa. Alkuperäinen kommentti liittyi siihen että 8086 ISA on suunniteltu aivan eri käyttötapaan kuin mitä nykyään pidetään normina. Kovin paljon en x86 assyä ole kirjoittanut mutta riittävästi että se on ainakin itselleni paljon mukavampaa kuin ARMv7 kirjoittaminen.
8086 käyttäminen vertailukohtana on lähinnä alentuvaa alkuperäisen postauksen kirjoittajaa kohtaan.

 

[jive]

Jos mietitään korkean tason käyttökohteita(mitä ilmeisesti ajat takaa), eivät ne piittaa siitä, mitä käskykantaa kaukana alla olevassa prossussa käytetään, paitsi että sen alla olevan prossun suorituskyky-pitna-ala-energiankulutus-suhde olisi mahdollisiman htvä. Mitä se RISC-Vllä CPU-käytössä ei ole, eikä siihen vaikuta se, onko se piiri autossa, lentokoneessa, pesukoneessa, puhelimessa, läppärissä vai pöytäkoneessa.

Kyllä ja sen takia mielenkiintoisempaa olisi vaikka tietää mitkä RTOS alustaa tukevat ja tuleeko SiFive lisäksi muita piirivalmistuttajia. Itse ainakin pidin siitä että voit käydä ruksimassa sivulta halutut ominaisuudet piiriin ja saada juuri sellaisen SoC kun tarttee.
Uutisen oleellinen anti minulle on että uusin ydin 50% nopeampi kuin lutikka joka tuosta kehityskitistä löytyy. Auttaa siinä että pystyy arvioimaan miten kyseinen piiri soveltuu tuotteisiin joita firma suunnittelee julkaisevansa seuraavan kymmenen vuoden aikana.

 

[hkultala]

kysyä voi monella tapaa. Alkuperäinen kommentti liittyi siihen että 8086 ISA on suunniteltu aivan eri käyttötapaan kuin mitä nykyään pidetään normina. Kovin paljon en x86 assyä ole kirjoittanut mutta riittävästi että se on ainakin itselleni paljon mukavampaa kuin ARMv7 kirjoittaminen.

Itse olen kirjoittanut jonkin verran sekä 16-bittistä 80286-assyä että 32-bittistä 386+mmx+3dnow(K6-2)-assyä, ja tuijottanut paljon RISC-V-assyä ja omasta mielestäni se RISC-V -assy on kyllä paljon ymmärrettävämpää/helpompaa kuin x86-assy, vaikka joutuukin saman asian kirjoittamaan suuremmalla käskymäärällä.

Ne muinaiset CISC-käskykannat eivät todellakaan olleet sellaisia mitä ne olivat jonkun "assy-ohjelmoinnin helppouden" takia, vaan ihan tasan sen takia, että säästettiin käskymuistia joka oli kallista.

8086 käyttäminen vertailukohtana on lähinnä alentuvaa alkuperäisen postauksen kirjoittajaa kohtaan.

Ei ole, vaan se on suora vastaus alkuperäiseen kommenttiin:

"Pienten lisäysten" jälkeen ollaan jo ensimmäisiä x86-arkkitehtuureja vastaavissa käskyjoukoissa.

Että melkoista puolestaloukkaantumista/typerää syyttelyä valittaa siitä että vastasin tuohon mahdollisimman suorasti. Boldasin vielä oleelliset sanat.

 

[jive]

Itse olen kirjoittanut jonkin verran sekä 16-bittistä 80286-assyä että 32-bittistä 386+mmx+3dnow(K6-2)-assyä, ja tuijottanut paljon RISC-V-assyä ja omasta mielestäni se RISC-V -assy on kyllä paljon ymmärrettävämpää/helpompaa kuin x86-assy, vaikka joutuukin saman asian kirjoittamaan suuremmalla käskymäärällä.

Tämä on vain pelkästään hyvä tieto. Kiitoksia tästä. Oma kokemus rajoittuu toistaiseksi RISC-V ohjelmoinnin osalta vain C esimerkkeihin.

 

[jive]

Ne muinaiset CISC-käskykannat eivät todellakaan olleet sellaisia mitä ne olivat jonkun "assy-ohjelmoinnin helppouden" takia, vaan ihan tasan sen takia, että säästettiin käskymuistia joka oli kallista.

mielenkiintoinen kulma, varmasti osatekijä. Sinällään Von Neumann koneissa ei erotella käskyjä datasta, joten tarkempi kuvaus lienee ohjelman viemä tila muistista.

 

[jive]

@hkultala muistan asiat hieman erilailla

Joskus linkki vastaa tuhatta sanaa IBM100 - RISC Architecture