SiFive esitteli seuraavan sukupolven Performance P650 RISC-V-ytimen

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
21 449


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
 
Liittynyt
22.10.2016
Viestejä
11 030
... 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)
 
Viimeksi muokattu:
Liittynyt
22.10.2016
Viestejä
11 030
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

Se ainoa oikea
Platinum-jäsen
Liittynyt
18.10.2016
Viestejä
5 625
Mikä noiden teho on suhteessa ARM malleihin?
 
Liittynyt
05.02.2017
Viestejä
176
... 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.
 
Liittynyt
22.10.2016
Viestejä
11 030
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.
 
Viimeksi muokattu:
Liittynyt
17.10.2016
Viestejä
21 885
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.
 
Liittynyt
17.10.2016
Viestejä
1 837
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.
 
Liittynyt
22.10.2016
Viestejä
11 030
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).


hsalonen sanoi:
"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.
 
Viimeksi muokattu:
Liittynyt
17.10.2016
Viestejä
21 885
@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.
 
Liittynyt
18.10.2016
Viestejä
2
... 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

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
21 449
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 :interested:
 

finWeazel

Chief Karpfen
Liittynyt
15.12.2019
Viestejä
7 811
Joissain tapauksissa arm:in lisensointimaksu voi olla hapokkaampi kuin risc-v:n suorituskyky.
 
Liittynyt
18.10.2016
Viestejä
2
RISC-V kuuluu aiheisiin "ei kiinnosta massoja". Puolustuksekseni lisäisin että uskoisin osaavani kertoa hkultalaa syvällisemmin (psykiatrisesta) sairaanhoidosta :interested:
Selvä homma :D 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
 
Liittynyt
27.12.2016
Viestejä
1 837
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.
 
Liittynyt
22.10.2016
Viestejä
11 030
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.
 
Viimeksi muokattu:
Liittynyt
27.12.2016
Viestejä
1 837
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ä.
 
Liittynyt
22.10.2016
Viestejä
11 030
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.
 
Viimeksi muokattu:
Liittynyt
27.12.2016
Viestejä
1 837
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.
 
Liittynyt
22.10.2016
Viestejä
11 030
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.
 
Viimeksi muokattu:
Liittynyt
27.12.2016
Viestejä
1 837
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.
 
Liittynyt
27.12.2016
Viestejä
1 837
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.
 
Liittynyt
22.10.2016
Viestejä
11 030
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:

hsalonen sanoi:
"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.
 
Liittynyt
27.12.2016
Viestejä
1 837
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.
 
Liittynyt
27.12.2016
Viestejä
1 837
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.
 
Toggle Sidebar

Statistiikka

Viestiketjut
237 473
Viestejä
4 163 431
Jäsenet
70 414
Uusin jäsen
O&G

Hinta.fi

Ylös Bottom