RISC-V

RISC-V er en gratis maskinvareinstruksjonssettarkitektur (ISA) basert på en RISC -type (redusert instruksjonssett) .

I motsetning til de fleste instruksjonssett, er RISC -V instruksjonssettet gratis og åpent og kan brukes royaltyfritt til ethvert formål, slik at alle kan designe, bygge og selge RISC-V-brikker og programvare. Selv om det ikke er den første åpne arkitektur-ISA, er det viktig ved at det er designet for å være nyttig på tvers av et bredt spekter av enheter. Instruksjonssettet har også en betydelig mengde støtteprogramvare, som unngår en vanlig svakhet ved nye instruksjonssett.

Prosjektet startet i 2010 ved University of California, Berkeley , men mange bidragsytere er frivillige og industriarbeidere utenfor universitetet.

Instruksjonssettet er designet med tanke på små, raske og laveffektsimplementeringer i den virkelige verden, [ 1 ] ​[ 2 ]​ men uten overdreven overkonstruksjon for en bestemt mikroarkitektur . [ 3 ]​ [ 4 ]

Fra mai 2017 ble versjon 2.2 av brukerromsinstruksjonssettet stengt. Det privilegerte instruksjonssettet var tilgjengelig som et utkast i versjon 1.10.

Viktighet

Forfatterne av RISC-V har til hensikt å tilby ulike fritt tilgjengelige CPU -design under BSD-lisensene , som tillater avledede verk som RISC-V-brikkedesign å være åpne og gratis, omtrent som RISC-V, eller lukket og gratis eksklusiv eiendom.

Derimot krever kommersielle brikkeleverandører som ARM Holdings og MIPS Technologies betydelige lisensavgifter for bruken av patentene deres. [ 5 ] [ 6 ] De krever også taushetserklæringer før de publiserer dokumenter som beskriver fordelene med deres design og instruksjonssett. Hemmeligheten forhindrer sikkerhetsrevisjon. [ referanse nødvendig ]

Å utvikle en CPU krever designekspertise innen flere spesialiteter: elektronisk digital logikk , kompilatorer og operativsystemer . Det er sjelden å finne dette utenfor et profesjonelt ingeniørteam. Resultatet er at moderne, generelle, høykvalitets datamaskininstruksjonssett ikke har vært allment tilgjengelige noe sted, eller til og med forklart, bortsett fra i akademiske omgivelser. På grunn av dette ser mange RISC-V-bidragsytere det som en samlet fellesskapsinnsats. Dette behovet for en stor bidragsyterbase er en del av grunnen til at RISC-V ble designet for å passe så mange bruksområder.

RISC-V forfattere har også betydelig forskning og brukererfaring som validerer designene deres innen silisium og simulering. RISC-V ISA er en direkte utvikling av en serie akademiske datadesignprosjekter. Det oppsto delvis for å hjelpe slike prosjekter.

Historie

Forgjengere

Begrepet RISC stammer fra rundt 1980. Før dette var det en viss kunnskap om at enklere datamaskiner kunne være effektive, men designprinsippene ble ikke mye beskrevet. Enkle og effektive datamaskiner har alltid vært av akademisk interesse.

Akademikere skapte RISC DLX-instruksjonssettet for den første utgaven av Computer Architecture: A Quantitative Approach i 1990. David Patterson var forfatter, og gikk senere på RISC-V. DLX var for pedagogisk bruk. Akademikere og hobbyister implementerte det ved å bruke feltprogrammerbare portarrayer. Det var ingen kommersiell suksess.

ARM CPUer, versjon 2 og tidligere, hadde et offentlig domene instruksjonssett, og det støttes fortsatt av GNU Compiler Collection ( GCC ), en populær gratis programvarekompilator. Det er tre åpen kildekode-kjerner for denne ISA-en, men de har ikke blitt produsert.

OpenRISC er en åpen kildekode-ISA basert på DLX , med tilhørende RISC-design. Den er fullt kompatibel med GCC- og Linux-implementeringer. Den har imidlertid få kommersielle implementeringer.

Foundation

Krste Asanović ved University of California, Berkeley fant mange bruksområder for et datasystem med åpen kildekode. I 2010 bestemte han seg for å utvikle og publisere en i et "kort tre måneders prosjekt over sommeren." Planen var å hjelpe både akademiske og industrielle brukere. [10] David Patterson på Berkeley hjalp også til i innsatsen. Han identifiserte opprinnelig egenskapene til Berkeley RISC, [11] og RISC-V er et av hans lange rekke samarbeidende RISC-forskningsprosjekter. De første midlene var fra DARPA.

En delvis liste over organisasjoner som støtter RISC-V Foundation inkluderer: AMD , [14] Andes Technology, [15] BAE Systems , Berkeley Architecture Research, Bluespec, Inc., Cortus, Google , GreenWaves Technologies, Hewlett Packard Enterprise, Huawei , IBM , Imperas Software, Institute of Computing Technology (ICT) Chinese Academy of Sciences, IIT Madras, Lattice Semiconductor, Mellanox Technologies, Microsemi, Micron Technologies, Nvidia , NXP , Oracle , Qualcomm , Rambus Cryptography Research, Western Digital , SiFive og Raspberry Pi Stiftelse . [ 7 ]​ [ 8 ]​ [ 9 ]​ [ 10 ]

Priser

Motivasjonskrav

Designere sier at instruksjonssettet er hovedgrensesnittet i en datamaskin, fordi det sitter mellom maskinvaren og programvaren. Hvis et godt sett med instruksjoner er åpent, tilgjengelig for alle å bruke, bør det drastisk redusere kostnadene for programvare ved å la den gjenbrukes mye mer. Det bør også øke konkurransen blant maskinvareleverandører, som kan bruke mer ressurser til design og mindre til programvarestøtte.

Designerne sier at nye prinsipper blir stadig mer sjeldne i instruksjonssettdesign, ettersom de mest vellykkede designene de siste førti årene har blitt stadig mer like. Av de som mislyktes, gjorde de fleste det fordi sponsorselskapene deres mislyktes kommersielt, ikke fordi instruksjonssettene var teknisk mangelfulle. Derfor bør et godt utformet, åpent sett med instruksjoner med veletablerte prinsipper tiltrekke langsiktig støtte fra mange leverandører.

De fleste åpne ISA-er brukte GNU General Public License (GPL), og oppmuntret brukere til å åpne sine implementeringer for andre å kopiere og bruke.

I motsetning til andre akademiske design som kun er optimalisert for enkel utstilling, hevder designerne at RISC-V instruksjonssettet er for praktiske datamaskiner. Det sies å ha funksjoner for å øke datamaskinens hastighet, men likevel redusere kostnadene og strømforbruket. Disse inkluderer en last- og lagringsarkitektur, bitmønstre for å forenkle multipleksere på en CPU, forenklet standardbasert flytende punkt, et design som er arkitektonisk nøytralt og plasserer de viktigste bitene på et fast sted for å øke hastigheten på skiltutvidelsen. Det sies at forlengelsen av signalet ofte er i den kritiske tidsstien.

Instruksjonssettet er designet for et bredt spekter av bruksområder. Den støtter tre ordbredder, 32, 64 og 128 biter, og en rekke undersett. Definisjonene av hver delmengde varierer litt for de tre ordbreddene. Underenhetene støtter små innebygde systemer, personlige datamaskiner, superdatamaskiner med vektorprosessorer og rackmonterte parallelle datamaskiner i lagerskala.

Instruksjonssettet er variabel bredde og kan utvides, så flere biter av koding kan alltid legges til. Plass ble reservert for den 128-bits utvidede versjonen av ISA, ettersom 60 års bransjeerfaring har vist at den mest fatale feilen i instruksjonssettdesign er mangel på minneadresseplass. Fra og med 2016 forblir 128-biters ISA med vilje udefinert, fordi det fortsatt er svært lite praktisk erfaring med så store minnesystemer.

Imidlertid støtter RISC-V også akademisk bruk av designere. Enkelheten til heltallsdelsettet tillater grunnleggende elevøvelser. Integer Subset er en enkel ISA-programvare som lar deg kontrollere forskningsmaskiner. ISA med variabel lengde tillater utvidelser for både studentøvelser og forskning. Det separate privilegerte instruksjonssettet tillater forskning på operativsystemstøtte, uten å redesigne kompilatorer. RISC-Vs åpne åndsverk gjør at designene kan publiseres, gjenbrukes og endres.

Programvare

Et normalt problem for et nytt instruksjonssett er mangelen på CPU-design og programvare.

RISC-V-nettstedet har en spesifikasjon for brukermodusinstruksjoner og en foreløpig spesifikasjon for et generellt privilegert instruksjonssett for å støtte operativsystemer. [ 12 ]

Det er flere åpen kildekode CPU-design, inkludert 64-bit Berkeley Machine Out of Order (BOOM), [21] 64-bit Rocket, [22] fem Berkeley 32-bit Sodor CPU-design, [23] picorv32 av Clifford Wolf, scr1 fra Syntacore, PULPino (Riscy and Zero-Riscy) fra ETH Zürich / University of Bologna. [ 13 ]​ [ 14 ]​ [ 15 ]​ [ 16 ]​ og andre. Tre-trinns Sodor CPU ser ut til å være tilstrekkelig for en liten innebygd CPU. Rocket kan tilpasses kompakte og laveffekts mellomdatamaskiner, for eksempel personlige enheter. BOOM bruker mye av infrastrukturen bygget for Rocket, og kan brukes til personlige datamaskiner, superdatamaskiner og lagerdatamaskiner. Både picorv og scr1 er 32-bits mikrokontroller (MCU) klasse RV32IMC implementeringer i Verilog. Kjernene i PULPino implementerer enten en enkel RV32IMC ISA for mikrokontrollere (Zero-Riscy) eller en kraftigere RV32IMFC ISA med tilpassede DSP-utvidelser for innebygd signalbehandling.

Designprogramvaren inkluderer en designkompilator, Chisel, som kan redusere design til Verilog for bruk i enheter. Nettstedet inneholder verifikasjonsdata for testing av større implementeringer. [ 17 ]

Tilgjengelige RISC-V-programvareverktøy inkluderer en GNU Compiler Collection (GCC)-verktøykjede (med GDB, feilsøkeren), en LLVM-verktøykjede, OVPsim-simulatoren (og biblioteket med raske RISC-V-prosessormodeller). V), Spike-simulatoren, og en simulator i QEMU.

Det er OS-støtte for Linux-kjernen, FreeBSD og NetBSD, men veiledermodusinstruksjoner er ikke standardiserte fra og med 10. november 2016, så denne støtten er foreløpig. FreeBSD Preview-porten for RISC-V-arkitekturen ble oppdatert i februar 2016 og sendt i FreeBSD 11.0. Debian [ 18 ] og Fedora [ 19 ] -porter stabiliseres. En havn i Das U-Boot eksisterer. [ 20 ] UEFI Spec v2.7 har definert RISC-V-koblingen og en port av thianocore er utført av HPE-ingeniører og forventes å bli oppdatert. Det er en foreløpig port for seL4 mikrokjernen. [ 21 ] [ 22 ]​ Det finnes en simulator for å kjøre et RISC-V Linux-system i en nettleser med Javascript . Almaty, Hesham. heshamelmatary . GitHub . Hentet 13. juli 2018 . 

CREATOR-simulatoren [ 23 ]​ [ 24 ]​ [ 25 ]​ [ 26 ]​ er bærbar og lar deg lære ulike assembly-språk for forskjellige prosessorer (CREATOR har eksempler med implementering av RISC-V- og MIPS32-instruksjonene).

WepSIM pedagogisk simulator [ 27 ]​ [ 28 ]​ implementerer et undersett av RISC-V-instruksjoner på en mikroprogrammert måte (RV32I + M) og gjør det mulig å utføre eksempler på underrutiner i montering. WepSIM-simulatoren kan brukes fra en nettleser, og gjør det enkelt å lære ulike aspekter av hvordan en CPU fungerer ( mikroprogrammering, avbrudd, systemanrop, etc.) ved hjelp av RISC-V assembler.


Brukere

Reklame

Under utvikling

Design

ISA Base og utvidelser

RISC-V har en modulær design, bestående av alternative basisdeler, med tilleggsutstyr. ISA-basen og dens utvidelser er utviklet i en felles innsats mellom industri, forskningsmiljø og utdanningsinstitusjoner. Basen spesifiserer instruksjonene (og deres koding), kontrollflyten, registrene (og deres størrelser), minnet og adresseringen, den logiske manipulasjonen (dvs. heltallet) og hjelperne. Bare basen kan implementere en forenklet datamaskin for generell bruk, med full programvarestøtte, inkludert en kompilator for generell bruk.

Standard plugins er spesifisert for å fungere med alle standard databaser og med hverandre uten konflikt.

Mange RISC-V-datamaskiner kan implementere den kompakte utvidelsen for å redusere strømforbruk, kodestørrelse og minnebruk. Det er også fremtidige planer for å støtte hypervisorer og virtualisering. [19] Sammen med en supervisor instruksjonssett-utvidelse, S, definerer en RVGC alle instruksjonene som er nødvendige for å praktisk støtte et Unix-stil, Portable Operating System Interface (POSIX) operativsystem.

ISA base og utvidelser
Navn Beskrivelse Versjon Status[laveste-alfa 1]
Utgangspunkt
RV32I Base heltall instruksjonssett, 32-bit 2.0 Ja Lukket
RV32E Heltallsbasisinstruksjonssett (innebygd), 32-bit, 16 registre 1.9 Nei åpen
RV64I Heltallsbasisinstruksjonssett, 64-bit 2.0 [ 45 ]
RV128I Heltallsbasisinstruksjonssett, 128-bit 1,7 [ 46 ]
Utvidelse
M Standard utvidelse for heltalls multiplikasjon og divisjon 2.0 Ja Lukket
EN Standardutvidelse for Atomic Instructions 2.0 Nei åpen
F Standard forlengelse for enkelt presisjons flytepunkt 2.0 Ja Lukket
D Standard forlengelse for dobbel presisjons flytepunkt 2.0 Nei åpen
G Forkortelse for base og tidligere utvidelser
Q Standard forlengelse for firedobbel presisjonsflytepunkt 2.0 Ja Lukket
L Standard forlengelse for desimal flyttall 0,0 Ja Lukket
C Standard utvidelse for komprimerte instruksjoner 2.0
B. Standard forlengelse for bitsmanipulering 0,36
J Standardutvidelse for dynamisk oversatte språk 0,0 Ja Lukket
T Standard utvidelse for transaksjonsminne 0,0 Nei åpen
P Standardutvidelse for Pakket SIMD-instruksjoner 0,1 Ja Lukket
v Standardutvidelse for vektoroperasjoner 0,2 Nei åpen
N Standard utvidelse for avbrudd på brukernivå 1.1 Nei åpen

For å mestre kombinasjonene av funksjonalitet som kan implementeres, er en nomenklatur definert for å spesifisere dem. [4] Instruksjonssettbasen spesifiseres først, kodingen for RISC-V, registerbitbredden og varianten; for eksempel RV64I eller RV32E. Deretter følger bokstavene som spesifiserer utvidelser implementert i kanonisk rekkefølge (som ovenfor). Basen, utvidede heltall og flytende kommaberegninger, og synkroniseringsprimitivene for multicore databehandling, MAFD-basen og utvidelser, anses som nødvendige for generell beregning, og har derfor stenografien G.

En liten 32-bits datamaskin for et innebygd system kan være RV32EC. En 64-bit stor datamaskin kan være RV64GC; dvs. stenografi for RV64IMAFDC.

Et navneskjema med Zxxx for standardutvidelser og Yxxx for ikke-standard (leverandørspesifikke) utvidelser er foreslått. For eksempel er Ztso-utvidelsen for total butikkbestilling, en alternativ minnekonsistensmodell for svak minnebestilling, under diskusjon. [ 47 ]

Rekordsett

RISC-V har 32 (eller 16 i den innebygde varianten) heltallsregistre og, når flyttallutvidelsen er implementert, 32 flyttallsregistre. Med unntak av instruksjoner for minnetilgang, refererer instruksjonene kun til registre.

Det første heltallsregisteret er et nullregister, og resten er registre for generelle formål. En skriving til registernull har ingen effekt, og en lesing returnerer alltid 0. Å bruke registernull som plassholder gjør instruksjonssettet enklere. For eksempel move rx to ryblir det add r0 to rx and store in ry.

Det finnes kontroll- og statusregistre, men brukermodusprogrammer kan bare få tilgang til de som brukes til ytelsesmåling og flyttallstyring.

Det er ingen instruksjoner for å lagre og gjenopprette flere poster. De ble antatt å være unødvendige, for komplekse og kanskje for trege.

Minnetilgang

Som mange RISC-design, er RISC-V en last-og-lagre-arkitektur: instruksjoner går kun til registre, med laste- og lagreinstruksjoner som overføres til og fra minnet.

Minne består av og behandles som 8-bits byte, med ordene i liten-endian- rekkefølge . Ord, opp til registerstørrelse, kan nås med laste- og lagreinstruksjoner.

Tilgang til minneadresser trenger ikke være ordbreddejustert, men justert adressetilgang vil alltid være raskest. Som for eksempel kan enkle prosessorer implementere ujusterte tilganger med langsom programvareemulering basert på et justeringsfeilavbrudd.

RISC-V administrerer minnesystemer som deles mellom CPUer eller tråder ved å sikre at en utførelsestråd alltid ser minneoperasjonene i den planlagte rekkefølgen. Men mellom tråder og I/O-enheter holder RISC-V det enkelt: Det garanterer ikke rekkefølgen på minneoperasjoner, bortsett fra spesifikke instruksjoner, for eksempel fence.

En instruksjon fencegaranterer at resultatene av forgjengeroperasjoner er synlige for påfølgende operasjoner av andre tråder eller I/O-enheter. Den fencekan garantere rekkefølgen av kombinasjoner av minne og minnetilordnede I/O-operasjoner. Du kan for eksempel skille minnelese- og skriveoperasjoner uten å påvirke I/O-operasjoner. Eller hvis et system kan drive I/O-enheter parallelt med minne, fencetvinger det dem ikke til å vente på hverandre. En CPU med én tråd kan dekode instruksjonen fencesom nop.

Som mange RISC-instruksjonssett (og noen komplekse instruksjonssett-datamaskiner (CISC) instruksjonssett, for eksempel x86- og IBM System/360 - familiene ), mangler RISC-V adressemoduser som skriver til registre. For eksempel økes den ikke automatisk.

RISC-V ligner lite på andre vellykkede familiedatamaskiner, for eksempel x86 . Dette reduserer også CPU-kompleksiteten og kostnadene litt fordi den leser alle ordstørrelser i samme rekkefølge. For eksempel dekodes RISC-V-instruksjonssettet med start ved den laveste adresserte byten i instruksjonen. Spesifikasjonen åpner muligheten for ikke-standard big-endian eller bi-endian systemer.

Noen RISC CPUer (som MIPS , PowerPC , DLX og Berkeleys RISC-I) setter 16-bits forskyvninger på belastninger og lagre. De setter de øverste 16 bitene ved å bruke en last øvre ord -instruksjon . Dette gjør at øvre halve ord-verdier enkelt kan settes, uten å endre bitene. Imidlertid bruker de fleste øvre halvord-instruksjoner 32-bits konstanter, for eksempel adresser. RISC-V bruker en SPARC -lignende kombinasjon av 12-bits forskyvninger og 20-bits øvre oppsettinstruksjoner . Den mindre 12-bits forskyvningen hjelper 32-biters kompaktering, lasting og lagring av instruksjoner med å velge to av de 32 registrene, men har fortsatt nok biter til å støtte RISC-Vs instruksjonskoding med variabel lengde.

Umiddelbar

RISC-V håndterer 32-bits konstanter og adresser med instruksjoner som setter de øvre 20 bitene i et 32-bits register. Last øyeblikkelig topp-instruksjonen laster lui20 biter inn i bitene 31 til 12. En annen instruksjon auipcgenererer de samme topp 20 adressebitene ved å legge til en offset til programtelleren og lagre resultatet i et basisregister. Dette gjør at posisjonsuavhengig kode kan ha 32-biters adresser i forhold til programtelleren. Basisregisteret kan brukes som det er med 12-bits offsetene fra lastene og lagrene. Om nødvendig addikan du angi de nederste 12 bitene i et register. I 64-bit ISA, luiog auipcutvide tegnet av resultatet til 64 biter.

Noen raske CPUer kan tolke kombinasjoner av instruksjoner som enkle smeltede instruksjoner. luieller auipcde kan være gode kandidater for sammenslåing med last eller lager.

Subrutineanrop, hopp og grener.

RISC-V subrutineanrop jal(hopp og bind) plasserer returadressen i et register. Dette er raskere i mange datamaskindesigner, fordi det sparer én minnetilgang sammenlignet med systemer som skyver en returadresse direkte på en stabel i minnet. Instruksjonen jalhar en signert 20-bits offset (2s komplement). Forskyvningen multipliseres med 2 og legges deretter til PC-en for å generere en adresse i forhold til en 32-bits instruksjon. Hvis resultatet ikke er på en 32-biters adresse (det vil si jevnt delelig med 4), kan CPU-en tvinge frem et unntak .

RISC-V-CPU-er hopper til beregnede adresser ved å bruke et hopp- og koblingsregister med instruksjonen jalr. Instruksjonen jalrligner på jal, men den får sin destinasjonsadresse ved å legge til en 12-bits offset til et basisregister. (Derimot jallegger den til en større 20-bits offset til PC.)

For jalrbitformatet er det som laster og lagrer i forhold til registeret. I likhet med dem kan jalrde brukes med instruksjoner som setter de 20 øverste bitene i et basisregister til å lage 32-bits grener, enten til en absolutt adresse (ved hjelp av lui) eller en PC-relativ (bruker auipcfor posisjonsuavhengig kode). (Hvis du bruker en konstant nullbasert adresse, kan enkeltinstruksjonsanrop utføres til en liten (offset), fast positiv eller negativ adresse.)

RISC-V resirkulerer jaly jalrfor PC-relative 20-bits ubetingede hopp og registerbaserte 12-bits ubetingede hopp. Hopp fører bare til at register 0 bindes, så ingen returadresse lagres.

RISC-V resirkulerer også jalrfor å returnere fra en subrutine: For å gjøre dette jalrsettes basisregisteret som bindingsregisteret lagret av jaleller jalr. I jalroffset er null og bindingsregisteret er null, så det er ingen offset og ingen returadresse er lagret.

Som mange RISC-designer, i et subrutineanrop, må en RISC-V-kompilator bruke individuelle instruksjoner for å lagre registre i stabelen ved oppstart og deretter gjenopprette dem fra stabelen ved utgang. RISC-V har ikke flere instruksjoner for lagring eller gjenoppretting av multilogger . Dette ble antatt å gjøre CPU-en for kompleks og muligens treg. Dette kan ta mer kodeplass. Designerne planla å redusere størrelsen på koden med biblioteksrutiner for lagring og gjenoppretting av registre.

RISC-V har ikke noe tilstandskoderegister og ingen bærebit. Designerne mente at tilstandskoder gjør raske CPUer mer komplekse ved å tvinge frem interaksjoner mellom instruksjoner på forskjellige stadier av utførelse. Dette valget gjør aritmetikk med flere presisjoner mer kompleks. Noen numeriske oppgaver trenger også mer energi.

I stedet har RISC-V korte grener som utfører sammenligninger: lik, ikke lik, mindre enn, ikke mindre enn fortegn, større enn eller lik, og ikke større enn eller lik fortegn. Ti grensammenligningsoperasjoner er implementert med bare seks instruksjoner, omvendt rekkefølgen til operandene i assembleren . For eksempel forgrening hvis større enn det kan gjøres med mindre enn med en omvendt rekkefølge av operander.

Sammenlign-grenene har en signert rekkevidde på tolv biter og hopper i forhold til PC-en.

RISC-V ISA krever standard grenprediksjoner for CPUer: betingede bakovergrener bør forutsies. Forover betingede grener forutsi ikke tatt . Forutsigelsene er enkle å dekode på en pipelinet CPU: grenadressene er signerte numre som legges til PC-en. Bakgrener har negative tos komplementadresser og har derfor en i den mest signifikante delen av adressen. Ledende grener har en null. Den viktigste biten er på en fast plassering i op-koden for å få fart på rørledningen. Komplekse CPUer kan legge til grenprediktorer for å fungere godt selv med uvanlige data eller situasjoner.

ISA-manualen anbefaler at programvaren optimaliseres for å unngå grenavbrudd ved å bruke standard grenprediksjoner. Dette gjenbruker den mest signifikante biten av den signerte relative adressen som en hintbit for å indikere hvorvidt den betingede grenen vil bli tatt eller ikke. Derfor er det ikke nødvendig med andre hintbiter i RISC-V-grenopkodene. Dette gjør flere biter tilgjengelige i grenopkodene. Enkle og billige CPUer kan bare følge standardspådommene og fortsatt fungere fint med kompilatoroptimalisering. Kompilatorer kan fortsatt utføre statistisk baneoptimalisering, hvis ønskelig.

For å unngå unødvendig belastning på grenprediksjonselektronikken (og dermed unødvendige rørledningsstopp), bør sammenligningsgrenkoder aldri brukes for ubetingede hopp.

RISC-V støtter ikke predikasjon (betinget utførelse av instruksjoner) fordi designere hevder at CPUer uten prediksjon er lettere å designe, og optimalisering av kompilatorer er mindre sannsynlig å bruke predikasjon der det ikke bør brukes. Designerne hevder at svært raske ut-av-ordre CPU-design gjør prediksjon uansett, ved å gjøre sammenligningsgrenen og betinget kode parallelt, og deretter forkaste effekten av den ubrukte banen. De sier også at selv på enklere CPUer, er prediksjon mindre verdifull enn grenprediksjon , som kan unngå de fleste vranglåsene knyttet til betingede grener. Kode uten prediksjon er større, med flere gafler, men de hevder også at et komprimert instruksjonssett (som RISC-Vs C -sett ) løser det problemet i de fleste tilfeller.

Mange RISC-design har inkludert et grenforsinkelsesspor , en posisjon etter en greninstruksjon som kan fullføres med en instruksjon som utføres uavhengig av grenen som tas. Denne funksjonen kan forbedre ytelsen til pipelinede CPUer ved å absorbere noe av tiden som går tapt hvis en CPU feilaktig forutsier driften av en betinget gren og CPU-pipelinen stopper. RISC-V utelater et grenforsinkelsesspor fordi det kompliserer flersyklus-CPUer, superskalare CPUer og lange rørledninger. Dynamiske grenprediktorer har vært vellykkede nok til å redusere behovet for forsinkede grener.

Aritmetiske og logiske sett

RISC-V segregerer matematikk til et minimalt heltallsinstruksjonssett ( I set ) med addisjon, subtrahering, shift, bitlogikk og sammenlign grener. Disse kan simulere de fleste andre RISC-V instruksjonssett med programvare. (Atominstruksjoner er et bemerkelsesverdig unntak.) RISC-V mangler for øyeblikket nulltelling og bitfeltoperasjoner som normalt brukes for å øke hastigheten på programvarens flytepunkt i en ren heltallsprosessor.

Heltalls multiplikasjonsinstruksjoner (sett M ) inkluderer multiplikasjon og divisjon med og uten fortegn. Heltall med dobbel presisjon er inkludert og delt, som multiplisert og delt som produserer det høye ordet i resultatet. ISA-dokumentet anbefaler at CPU-implementere og kompilatorer slår sammen en standardisert sekvens av høye og lave multiplikasjoner og deler instruksjoner i én operasjon hvis mulig.

Flytende punktinstruksjoner (sett F ) inkluderer enkeltpresisjonsaritmetikk og også sammenligningsgrener som ligner på heltallsaritmetikk. Krever et ekstra sett med 32 flyttallregistre. Disse er atskilt fra hele postene. Dobbelpresisjon flytepunktinstruksjoner (sett D ) antar generelt at flytepunktregistrene er 64-bit (dvs. dobbel bredde), og delsett F koordinerer med sett D. En ISA ( Q ) firedobbel presisjon 128-bit flytende punkt. RISC-V-datamaskiner som ikke har flytende punkt kan bruke et flytende-punkt-programvarebibliotek.

RISC-V forårsaker ikke unntak for aritmetiske feil, inkludert overløp, underflyt, undernormal og divisjon med null. I stedet produserer både heltalls- og flyttallsaritmetikk rimelige standardverdier og angi statusbiter. Divisjon med null kan oppdages av en gren etter divisjon. Statusbiter kan testes av et operativsystem eller et periodisk avbrudd.

Atomminneoperasjoner

RISC-V støtter datamaskiner som deler minne mellom flere CPUer og tråder . RISC-Vs standard minnekonsistensmodell er versjonskonsistens. Det vil si at laster og lagre generelt kan omorganiseres, men noen laster kan bli utpekt som get-operasjoner som må gå foran påfølgende minnetilganger, og noen lagre kan utpekes som utgivelsesoperasjoner som må følge minnetilganger.

Basisinstruksjonssettet inkluderer minimal støtte i form av en fenceinstruksjon for å håndheve minnebestilling. Selv om dette er tilstrekkelig ( fence r, rwgir anskaffelse og frigjøring ), kan de kombinerte operasjonene være mer effektive. fence rw, w

Utvidelsen for atomminnedrift støtter to typer atomminneoperasjoner for versjonskonsistens. For det første gir den generelle lr reservertelr og betingede butikkinstruksjoner sc . lrutfører en opplasting og prøver å reservere den adressen for tråden. En betinget etterfølgende lagring scDen reserverte adressen vil bare bli laget hvis reservasjonen ikke blir avbrutt av en mellombutikk fra en annen kilde. Hvis butikken lykkes, settes en null i et register. Hvis det mislykkes, indikerer en verdi som ikke er null at programvaren bør prøve operasjonen på nytt. I begge tilfeller frigjøres reserven.

Den andre gruppen av atominstruksjoner utfører les-modifiser-skriv-sekvenser: en belastning (som eventuelt er en belastningsinnhenting) på et destinasjonsregister, deretter en operasjon mellom den innlastede verdien og et kilderegister, deretter en lagring av resultatet. ( som eventuelt kan være en butikkutgivelse). Ved å gjøre minnebarrierene valgfrie kan du kombinere operasjonene. De valgfrie operasjonene aktiveres av innhentings- og frigjøringsbitene som finnes i hver atominstruksjon. RISC-V definerer ni mulige operasjoner: utveksling (bruk verdien av kilderegisteret direkte); Legge til; bitvis og, eller, og eksklusive -o; og minimum og maksimum signert og usignert.

Et systemdesign kan optimalisere disse kombinerte operasjonene mer enn lrog sc. For eksempel, hvis destinasjonsregisteret for en swap er konstant null, kan belastningen hoppes over. Hvis den lagrede verdien er uendret siden belastningen, kan lagret hoppes over.

IBM System/370 og dets etterfølgere, inkludert z/Architecture, og x86 , implementerer et sammenligning-og-bytt- instruksjonssystem ( cas), som tester og betinget oppdaterer en plassering i minnet: hvis plasseringen inneholder en verdi som forventes gammel, caserstattes den med en ny gitt verdi; den returnerer deretter en indikasjon på om den har gjort endringen. Imidlertid utføres vanligvis en enkel belastningstype før for caså hente den gamle verdien. Det klassiske problemet er at hvis en tråd leser (laster) en verdi A , beregner en ny verdi C og deretter bruker ( cas) for å erstatte A med C , har den ingen måte å vite om samtidig aktivitet i en annen tråd erstattet A med noe annet .verdi B og deretter gjenopprettet A i midten. I noen algoritmer (for eksempel de der verdiene i minnet er pekere til dynamisk tildelte blokker), kan dette ABA-problemet føre til feil resultater. Den vanligste løsningen bruker en casdobbel bredde. casinstruksjoner for å oppdatere både pekeren og en tilstøtende teller; Dessverre krever en slik instruksjon et spesielt instruksjonsformat for å spesifisere flere registre, utfører flere lesinger og skriver, og kan ha kompleks bussoperasjon.

Alternativet lr/ scer mer effektivt. Det krever vanligvis bare en mengde minne, og det er ønskelig å minimere langsomme minneoperasjoner. Det er også nøyaktig: det kontrollerer all tilgang til minnecellen, i stedet for bare å sikre et bitmønster. Men i motsetning til cas cas, kan den tillate Livelock , der to eller flere tråder gjentatte ganger fører til at hverandres instruksjoner mislykkes. RISC-V garanterer fremdrift (ikke Livelock) hvis koden følger reglene om timing og instruksjonssekvens: 1) Den må kun bruke delsett I. 2) For å unngå gjentatte cache-misser, må koden (inkludert prøvesyklusen) ikke oppta mer enn 16 påfølgende instruksjoner. 3) Må ikke inkludere system- eller gjerdeinstruksjoner, eller grener tatt bakover mellom lrog sc. 4) Forgreningen tilbake til prøvesløyfen må være tilbake til den opprinnelige sekvensen.

Spesifikasjonen gir eksempler på hvordan du bruker dette undersettet til å låse en datastruktur.

Komprimert delsett

RISC-V ISA-standarden spesifiserer at alle instruksjoner er 32-biters. Dette gir en spesielt enkel implementering, men som andre RISC-prosessorer med slik instruksjonskoding, resulterer det i en større kodestørrelse enn andre instruksjonssett. For å kompensere er RISC-Vs 32-biters instruksjoner faktisk 30 biter; 3/4 av opkodeplassen er reservert for et valgfritt (men anbefalt) komprimert instruksjonssett med variabel lengde , RVC, som inkluderer 16-biters instruksjoner. I likhet med ARMs Thumb og MIPS16, er de komprimerte instruksjonene ganske enkelt aliaser for en undergruppe av de større instruksjonene. I motsetning til ARMs Thumb eller MIPS komprimerte sett, ble plass reservert fra starten, så det er ingen egen driftsmodus. Standard og komprimerte instruksjoner kan blandes fritt. (bokstav C )

Fordi (som Thumb-1 og MIPS16) komprimerte instruksjoner ganske enkelt er alternative kodinger (aliaser) for et valgt delsett av større instruksjoner, kan komprimering implementeres i assembleren, og det er ikke avgjørende at kompilatoren vet om det.

En RVC-prototype ble testet i 2011. Prototypekoden var 20 % mindre enn x86 PC- og MIPS -komprimert kode , og 2 % større enn ARM Thumb-2- koden . Det reduserte også betydelig både det nødvendige hurtigbufferminnet og det estimerte strømforbruket til minnesystemet.

Forskeren hadde til hensikt å redusere den binære størrelsen på kode for små datamaskiner, spesielt innebygde datasystemer . Prototypen inkluderte 33 av de mest brukte instruksjonene, omkodet som kompakte 16-bits formater ved å bruke opkoder som tidligere var reservert for det komprimerte settet. Komprimeringen ble utført i assembler , uten endringer i kompilatoren. Komprimerte utsagn hoppet over felt som ofte er null, brukte små umiddelbare verdier eller fikk tilgang til delsett (16 eller 8) av postene. addiDet er veldig vanlig og ofte komprimerbart.

Mye av størrelsesforskjellen sammenlignet med Arm Thumb-monteringen skjedde fordi RISC-V, og prototypen, ikke har instruksjoner for å lagre og gjenopprette flere registre. I stedet genererte kompilatoren konvensjonelle instruksjoner som får tilgang til stabelen. RVC assembler-prototypen konverterte dem ofte til komprimerte former som var halve størrelsen. Imidlertid tok dette fortsatt mer kodeplass enn ARM-instruksjoner som lagrer og gjenoppretter flere registre. Forskeren foreslo å modifisere kompilatoren til å kalle bibliotekrutiner for å lagre og gjenopprette poster. Disse rutinene har en tendens til å forbli i en kodebuffer og kjøres derfor raskt, men sannsynligvis ikke like raskt som en save-many-setning.

Innebygd delsett

Et instruksjonssett for de mindre innebygde CPUene (E-sett) reduseres på andre måter: bare 16 av 32-bits heltallsregistre støttes. Flytepunktinstruksjoner bør ikke støttes (forbudt av spesifikasjonen som uøkonomiske), så et flytende kommabibliotek bør brukes. Det komprimerte C -settet anbefales . Det privilegerte instruksjonssettet støtter bare maskinmodus, brukermodus og minneskjemaer som bruker flytting av base og grenseadresse.

Det har vært diskusjoner om en mikrokontrollerprofil for RISC-V, for å lette utviklingen av dypt integrerte systemer . Den fokuserer på raskere og enklere C-språkstøtte for avbrudd, forenklede sikkerhetsmoduser og et forenklet POSIX -applikasjons binært grensesnitt . [ 48 ]

Korrespondenter har også foreslått mindre, ikke-standardiserte 16-biters ISA RV16E : 16 × 16-biters heltallsregistre vil bli brukt, ved bruk av standard EIMC ISA-er (inkludert 32-biters instruksjoner). ) [ 49 ] Et annet forslag ville bare bruke 16-bit C -instruksjonene med 8 × 16-bits registre. En full RV16EG ble sagt å være mulig med en fullstendig omkodet ISA. [ 50 ]

Privilegert instruksjonssett

RISC-V ISA inkluderer en separat spesifikasjon for privilegert instruksjonssett. Fra juli 2017 til 07 til 2017 07 til 2017 07 er det foreløpig.

  1. Systemer som bare har maskinmodus , kanskje for innebygde systemer ,
  2. Systemer med maskinmodus (for veileder) og brukermodus, kanskje for å implementere Linux .
  3. Systemer med maskinmodus, hypervisorer , flere supervisorer og brukermoduser under hver supervisor.

Disse tilsvarer omtrent systemer med opptil fire ringer med privilegier og sikkerhet, på det meste: maskin, hypervisor, supervisor og bruker. Hvert lag forventes også å ha et tynt lag med standardisert støtteprogramvare som kommuniserer med et mer privilegert lag eller maskinvare.

Den generelle planen for denne ISA er å gjøre hypervisormodus ortogonal til bruker- og supervisormodus. [ 51 ] Den grunnleggende funksjonen er en konfigurasjonsbit som lar kode på supervisornivå få tilgang til hypervisorregistre eller forårsake pausetilganger. Denne biten lar supervisor-modus direkte håndtere maskinvaren som trengs av en hypervisor. Dette forenkler en type 2 hypervisor, hostet av et operativsystem. Dette er en populær måte å kjøre datamaskiner i lagerskala. For å støtte type 1 hypervisorer, kan den upubliserte biten føre til at disse tilgangene til en hypervisor blir ødelagt. Biten forenkler hypervisor-nesting, der én hypervisor kjører under én hypervisor. Det sies også å forenkle veilederkode ved å la kjernen bruke sine egne hypervisorfunksjoner med sin egen kjernekode. Som et resultat støtter hypervisorformen til ISA fem moduser: maskin, supervisor, bruker, supervisor under hypervisor og bruker under hypervisor.

Spesifikasjonen for privilegert instruksjonssett definerer eksplisitt maskinvaretråder eller harts . Flere maskinvaretråder er vanlig praksis på større, kraftigere datamaskiner. Når en tråd stopper og venter på minne, kan andre fortsette. Maskinvaretråder kan bidra til å utnytte det store antallet registre og utførelsesenheter på store CPUer bedre. Til slutt kan maskinvaretråder være en enkel og kraftig måte å håndtere avbrudd på  : ingen grunn til å lagre eller gjenopprette registre, bare kjøre en annen maskinvaretråd. Den eneste maskinvaretråden som kreves i en RISC-V-datamaskin er tråd null.

Eksisterende status- og kontrollregisterdefinisjoner støtter RISC-V-feil- og minneunntak, og et lite antall avbrudd. For større systemer definerer spesifikasjonen også en avbruddsbehandler. Avbrudd starter alltid på maskinnivået med høyest rettighet, og hvert nivås kontrollregistre har eksplisitte videresendingsbiter for å rute avbrudd til mindre privilegert kode. For eksempel trenger ikke hypervisoren å inkludere programvare som kjører på hvert avbrudd for å videresende et avbrudd til et operativsystem. I stedet, i konfigurasjonen, kan du angi biter for å videresende avbruddet.

Ulike minnesystemer støttes av spesifikasjonen. Physical er kun egnet for de minste innebygde systemene . Det er også tre virtuelle minnesystemer i UNIX - stil for hurtigbufring i masselagringssystemer. Virtuelle minnesystemer har tre størrelser, med adresser på 32, 39 og 48 biter. Alle virtuelle minnesystemer støtter 4. KiB-sider, sidetabelltrær på flere nivåer og bruker svært like algoritmer for å krysse sidetabelltrær. De er alle designet for maskinvare- eller programvaresidetabeller. For å eventuelt redusere kostnadene for sidetabellvandringer, kan store sider være bladsider på høyere nivåer av et systems sidetabelltre. SV32 har et to-lags sidetabelltre og støtter 4 mib SuperPages SV39 har en tre-lags sidetabell som støtter 2 mib Superpages og 1 GiB gigapages. SV48 kreves for å støtte SV39. Den har også en 4-nivå sidetabell og støtter 2 MiB Superpages, 1 GiB Gigapages og 512 GiB terapages. Supersider justeres etter sidegrensene for neste mindre sidestørrelse.

Bitmanipulasjon

Betydelig arbeid ble gjort for å produsere en foreløpig (selv om ikke godkjent) ISA for bitmanipulasjon (B) for RISC-V. Gjort riktig kan et undersett av bitmanipulering hjelpe kryptografiske, grafiske og matematiske operasjoner. Inklusjonskriteriene som ble dokumentert i utkastet var overholdelse av RV5-filosofier og ISA-formater, betydelige forbedringer i kodetetthet eller hastighet (dvs. minst en instruksjonsreduksjon på 3 ganger 1) og betydelige applikasjoner i koden. Den virkelige verden, inkludert før -Eksisterende kompilatorstøtte. Versjon 0.36 inkluderte [ 52 ]​ ukontroversielle instruksjoner for å telle innledende nuller, telle én bit, gjøre andmed komplement, skifte enere, rotere, generalisert invertert og tilfeldig bit, bytebytte, bitutdrag og buckets, og noen manipulasjonstilføyelser av biter for komprimert sett ( not, negog reverse). Det inkluderer også et kontroversielt forslag for bitfeltbitfeltutvinning og plassering, ved bruk av et ikke-standard 48-bits instruksjonsformat.

SIMD-emballasje

For enkle, rimelige RISC-V-systemer er det et forslag om å bruke bitene i flytepunktregistrene for å utføre den parallelle enkle instruksjonen, multiple data ( SIMD ) aritmetiske underordsinstruksjoner . Dette er mye brukt for å øke hastigheten på multimedia og annen digital signalbehandling . Fra 2016 TIL 2016 er denne ISA udefinert, men kan se ut som PA-RISCs Multimedia Instructions: Multimedia Acceleration Extensions. I tillegg til sin opprinnelige 64-bits matematikk, kunne PA-RISC MAX2 CPU gjøre aritmetikk på fire 16-bits underpunkter samtidig, med forskjellige overløpsmetoder. Du kan også flytte underord til forskjellige posisjoner. PA-RISC MAX2 ble med vilje forenklet. Den manglet støtte for 8-biters eller 32-biters underord. 16-bits undersettstørrelsen ble valgt for å støtte de fleste digitale signalbehandlingsoppgaver. Disse instruksjonene var rimelige å designe og bygge. Imidlertid økte de CPU-ytelsen i digitale signalbehandlingsoppgaver med 48 ganger eller mer, noe som muliggjorde opprettelsen av sanntids videokodeker i 1995. [ 53 ] [ 54 ]

Vektorsett

Det foreslåtte vektorbehandlingsinstruksjonssettet kan gjøre den pakkede SIMD-pakken foreldet. Designerne håper å ha nok fleksibilitet til at en CPU kan implementere vektorinstruksjoner i registrene til en standard prosessor. Dette vil tillate minimale implementeringer med ytelse som ligner på en Multimedia ISA, som nevnt ovenfor. Imidlertid kan en ekte vektor-koprosessor utføre den samme koden med høyere ytelse. [ 55 ]

Fra 29. juni til 2015 29. juni til 2015. 29. juni til 2015. 29. juni til 2015. 29. juni til juni 2015 29, er vektorbehandlingsforslaget en konservativ og fleksibel utforming av en prosessor for generell bruk blandet , egnet for å kjøre databehandling kjerner. Koden kan enkelt overføres på tvers av CPUer med forskjellige vektorlengder, ideelt sett uten å rekompilere.

I kontrast er korte vektor SIMD-utvidelser mindre praktiske. Disse brukes på x86 , ARM og PA-RISC . I disse tvinger en endring i ordbredden en endring i instruksjonssettet for å utvide vektorregistrene (i tilfellet med x86, fra 64-bits MMX -registre til 128-bits Streaming SIMD Extensions (SSE), til 256 bits Advanced) Vector Utvidelser (AVX) og AVX-512). Resultatet er et voksende instruksjonssett og behovet for å tilpasse arbeidskoden til de nye instruksjonene.

I RISC-V ISA-vektoren, i stedet for å fikse lengden på vektoren i arkitekturen, er en instruksjon ( setvltilgjengelig, som tar en forespurt størrelse og setter lengden på vektoren til minimum av maskinvaregrensen og den forespurte størrelsen. For Dermed er RISC-V-forslaget mer likt Crays det vil si at hver vektor i opptil 32 vektorer har samme lengde.

Applikasjonen spesifiserer den totale bredden på vektoren som den krever, og prosessoren bestemmer lengden på vektoren som den kan gi med ressursene som er tilgjengelige på brikken. Dette tar form av en setning ( vsetcfg) med fire umiddelbare operander, som spesifiserer antall vektorregistre for hver tilgjengelig bredde som trengs. Totalen bør ikke være større enn den adresserbare grensen på 32, men kan være mindre hvis søknaden ikke krever alle. Lengden på vektoren er begrenset av tilgjengelig lagring på brikken delt på antall byte lagring som trengs for hver oppføring. (Ytterligere maskinvaregrenser kan også eksistere, som igjen kan tillate implementeringer i SIMD-stil.)

Utenfor vektorløkker kan applikasjonen be om nullvektorposter, noe som sparer operativsystemet bryet med å bevare dem på tvers av kontekstbrytere .

Lengden på vektoren er ikke bare arkitektonisk variabel, den er også designet for å variere under kjøring. For å oppnå denne fleksibiliteten vil instruksjonssettet sannsynligvis bruke databaner med variabel bredde og operasjoner av variabeltype som bruker polymorf overbelastning. Planen er at disse kan redusere størrelsen og kompleksiteten til ISA og kompilatoren.

Nyere eksperimentelle vektorprosessorer med databaner med variabel bredde viser også lønnsomme økninger i operasjoner per sekund (hastighet), areal (lavere kostnad) og watt (lengre batterilevetid). [ 56 ]

I motsetning til en typisk moderne grafikkbehandlingsenhet , er det ingen planer om å tilby spesiell maskinvare for å støtte grenprediksjon. I stedet vil en kompilatorbasert prediksjon med lavere kostnader bli brukt. [ 57 ]

Eksternt feilsøkingssystem

Det er en foreløpig spesifikasjon for RISC-V maskinvareassistert debugger . Debuggeren vil bruke et transportsystem som Joint Test Action Group ( JTAG ) eller Universal Serial Bus ( USB ) for å få tilgang til feilsøkingslogger. Et standard maskinvarefeilsøkingsgrensesnitt kan støtte et standardisert abstrakt grensesnitt eller instruksjonsmating . [ 58 ]​ [ 59 ]

Fra januar 2017 01 2017 01 2017 01 forblir den eksakte formen til det abstrakte grensesnittet udefinert, men forslagene inkluderer et minnetilordnet system med standardiserte adresser for feilsøkingsenhetsregistre eller et feilsøkingsregister, kommando- og dataregister tilgjengelig for kommunikasjonssystemet. Korrespondenter oppgir at Freescales Background Debugging Mode (BDM) grensesnitt bruker lignende systemer for noen Aeroflex CPUer, ARM , OpenRISC og LEON .

På instruksjonsfeed vil CPU behandle et feilsøkingsunntak for å utføre individuelle instruksjoner skrevet til et register. Dette kan suppleres med et dataoverføringsregister og en modul for direkte minnetilgang. Instruksjonsmating lar feilsøkeren få tilgang til datamaskinen nøyaktig slik programvare ville gjort. Den minimerer også CPU-endringer og har plass til mange typer CPUer. Dette ble sagt å være spesielt egnet for RISC-V fordi det er designet eksplisitt for mange typer datamaskiner. Dataoverføringsregisteret lar en debugger skrive en databevegelsesløkke til RAM, og deretter utføre løkken for å flytte dataene inn eller ut av datamaskinen med en hastighet nær den maksimale hastigheten til systemets datakanal. Korrespondenter sier at lignende systemer brukes av MIPS Technologies MIPS , Intel Quark, Tensilicas Xtensa og av Freescale CPU Powers grensesnitt for bakgrunnsfeilsøkingsmodus (BDM).

Se også

Referanser

  1. Siter feil: Ugyldig tag <ref>; innholdet i de kalte referansene er ikke definertrocketsspeed2
  2. Siter feil: Ugyldig tag <ref>; innholdet i de kalte referansene er ikke definertisa2
  3. Celia, Christopher. «ucb-bar/riscv-sodor» . GitHub Inc. Regents of University of California . Hentet 12. februar 2015 . 
  4. Celia, Christopher. "CS 152 Laboratorieøvelse 3" . UC Berkeley . Regents of University of California . Hentet 12. februar 2015 . 
  5. Demerjian, Chuck (7. august 2013). "En lang titt på hvordan ARM lisensierer brikker: Del 1" . Seminøyaktig. 
  6. Demerjian, Chuck (8. august 2013). "Hvordan ARM lisensierer sin IP for produksjon: Del 2" . Seminøyaktig. 
  7. Finley, Klint (21. mars 2018). "Turing-prisvinnere banet vei til smarttelefonbrikker" . Wired.com . 
  8. ^ "AndeStar-arkitektur" . Andes teknologi . «Andes er et grunnleggende medlem av RISC-V Foundation. » 
  9. Merritt, Rick. "Google, Oracle og HP blir med i RISC-V" . EE Times . UBM . Hentet 11. februar 2016 . 
  10. ^ "Medlemmer på et øyeblikk" . riscv.org . Hentet 2. januar 2018 . 
  11. ^ "The Linley Group kunngjør vinnere av årlige analytikeres valgpriser" . Linley-gruppen. 12. januar 2017 . Hentet 21. januar 2018 . 
  12. ^ "RISC-V Det frie og åpne instruksjonssettet" . RISC-V Foundation . Hentet 11. november 2016 . 
  13. Celia, Christopher. "riscv-boom" . GitHub . Regents of University of California . Hentet 11. november 2016 . 
  14. Asanović, Krste . rakettbrikke . GitHub . RISC-V Foundation . Hentet 11. november 2016 . 
  15. Celia, Christopher. "riscv-sodor" . GitHub . Regents of University of California . Hentet 11. november 2016 . 
  16. Traber, Andreas. "PULP: Parallell Ultra Low Power" . ETH Zürich, Universitetet i Bologna . Hentet 5. august 2016 . 
  17. ^ "Meisel: Konstruere maskinvare i et Scala Embedded Language" . UC Berkeley . Regents of University of California . Hentet 12. februar 2015 . 
  18. Montezelo, Manuel. "Debian GNU/Linux-port for RISC-V 64" . Google-grupper . Google . Hentet 19. juli 2018 . 
  19. ^ "Arkitekturer/RISC-V" . FedoraWiki . RedHat . Hentet 26. september 2016 . 
  20. Begari, Padmarao. "U-Boot-port på RISC-V 32-bit er tilgjengelig" . Google-grupper . Mikrosemi . Hentet 15. februar 2017 . 
  21. Almaty, Hesham. "RISC-V, seL4" . seL4 dokumentasjon . Commonwealth Scientific and Industrial Research Organization (CSIRO) . Hentet 13. juli 2018 . 
  22. Almaty, Hesham. heshamelmatary . GitHub . Hentet 13. juli 2018 . 
  23. https://zenodo.org/record/5130302#.YVSL23UzZNg
  24. https://doi.org/10.1109/CLEI53233.2021.9640144
  25. CREATOR Web med RISC-V eksempel: https://creatorsim.github.io/creator/?example_set=default_rv&example=e12
  26. CREATOR kildekode på GitHub: https://github.com/creatorsim/creator
  27. WepSIM Web med RISC-V_im eksempel: https://wepsim.github.io/wepsim/ws_dist/wepsim-classic.html?mode=ep&examples_set=Default-RISCV&example=9&simulator=assembly:registers¬ify=false
  28. WepSIM kildekode på GitHub: https://github.com/wepsim/wepsim
  29. ^ "HiFive1" . JaFem . Hentet 10. juli 2018 . 
  30. SiFive. "Hi-Five1: Arduino-kompatibelt utviklingssett med åpen kildekode" . CrowdSupply . Hentet 2. desember 2016 . og overflødig ( hjelp )  |autor=|apellido=
  31. "FU540 SoC CPU" . JaFem . Hentet 24. oktober 2018 . 
  32. ^ "RISC-V-verkstedsprosedyrer" . Hentet 11. desember 2018 . 
  33. Manners, David. "Codasip og UltraSoC kombineres på RISC-V" . Electronics Weekly . Metropolis International Group , Ltd. Hentet 23. november 2016 . 
  34. ^ "GreenWaves GAP8 er en laveffekts RISC-V IoT-prosessor optimalisert for kunstig intelligensapplikasjoner" . CNXSoft: Embedded Systems News . Hentet 4. mars 2018 . 
  35. ^ "AI kommer til sensorenheter" . 26. februar 2018 . Hentet 10. juli 2018 . 
  36. ^ "GreenWaves Technologies kunngjør tilgjengeligheten av GAP8 Software Development Kit og GAPuino Development Board" . 22. mai 2018. 
  37. "Hex Five Security legger til MultiZone Trusted Execution Environment til SiFive Software Ecosystem" . Hex Five Security . Hentet 13. september 2018 . 
  38. ^ "CloudBEAR" . Hentet 16. oktober 2018 . 
  39. https://www.youtube.com/watch?v=gg1lISJfJI0 . mangler ( hjelp )   |título=
  40. Ashenden, Peter (9. november 2016), " Re: [isa-dev RISC V ISA for innebygde systemer]", Google , https://groups.google.com/a/groups.riscv.org/d/ msg /isa-dev/j2okI7akT74/BQdUwjMRAgAJ , hentet 10. nov 2016 , "På ASTC (www.astc-design.com) har vi en implementering av RV32EC som en syntetiserbar IP-kjerne beregnet for små innebygde applikasjoner, som for eksempel smarte sensorer og IOT ." 
  41. ^ "PULPino GitHub-prosjekt" . GitHub . Hentet 2. februar 2018 . 
  42. ^ "PULP-plattform" . PULP-plattform . Hentet 2. februar 2018 . 
  43. ^ "Western Digital for å akselerere fremtiden til neste generasjons dataarkitekturer for big data og raske datamiljøer" . WesternDigital. 28. november 2017. 
  44. ^ "Esperanto går ut av stealth-modus, sikter mot AI med et 4096 kjerner 7nm RISC-V-monster" . wikichip.org (på amerikansk engelsk) . Hentet 2. januar 2018 . 
  45. Waterman, Andrew; Lee, Yunsup; Avizienas, Rim; Patterson, David ; Asanović, Krste . "Utkast til Privileged ISA-spesifikasjon 1.9" . RISC-V . RISC-V Foundation . Hentet 30. august 2016 . 
  46. Frosne deler forventes å ha sine endelige funksjoner og kun motta avklaringer før de blir ratifisert.
  47. https://www.youtube.com/watch?v=PE3pFZm2OA0 . mangler ( hjelp )   |título=
  48. Ionescu, Liviu. "RISC-V-mikrokontrollerprofilen" . Github . Hentet 5. april 2018 . 
  49. Barros, Cesar. "Forslag: RV16E" . Google Groups, RISC-V ISA Dev . Google . Hentet 2. april 2018 . 
  50. Brussee, Roger. "Forslag: Xcondensed, [a] ... Kompakt ... 16-biters frittstående G-ISA" . RISC-V ISA MailServer . Google-grupper . Hentet 10. november 2016 . 
  51. Bonzini, Paolo. "Forslag til virtualisering uten H-modus" . Google Groups, RISC-V ISA Dev . RISC-V Foundation . Hentet 24. februar 2017 . 
  52. Wolf, Clifford. "Bitmanipulasjon for RISC-V, utkast" . Github . Clifford Wolf. 
  53. ^ "64-biters og multimedieutvidelser i PA-RISC 2.0-arkitekturen" . Proceedings of Compon 96 : 152-160. 25. februar 1996 . Hentet 2014-09-21 . 
  54. ^ "Akselerere multimedia med forbedrede mikroprosessorer" . IEEE Micro 15 (2): 22-32. april 1995. doi : 10.1109/40.372347 . Hentet 2014-09-21 . 
  55. Schmidt, Colin. "RISC-V vektorutvidelsesforslag" . RISC-V . Regents of University of California . Hentet 14. mars 2016 . 
  56. Å, Albert. "Et tilfelle for MVP-er: Vektorprosessorer med blandet presisjon" . UC Berkeley EECS . Regents of University of California. Arkivert fra originalen 15. mars 2016 . Hentet 14. mars 2016 . 
  57. Lee, Yunsup. "Utforsking av designrommet til SPMD Divergence Management på dataparallelle arkitekturer" . Berkeleys EECS-side . Regents of University of California. Arkivert fra originalen 14. november 2014 . Hentet 14. mars 2016 . 
  58. Bradbury, Alex. "RISC-V RunControlDebug" . Google Dokumenter . RISC-V Foundation . Hentet 20. januar 2017 . 
  59. Newsom, Tim. "RISC-V Debug Group > avstemningsresultater" . Google Groups, RISC-V Debug Group . RISC-V Foundation . Hentet 20. januar 2017 . 

Siter feil: Tag <ref>definert i <references>navngitt "bidragsytere" brukes ikke i tidligere tekst.
Siter feil: Tag <ref>definert i <references>kalt "isa" brukes ikke i tidligere tekst.
Siter feil: Tag <ref>definert i <references>kalt "isacompressed" brukes ikke i tidligere tekst.
Siter feil: Tag <ref>definert i <references>kalt "riscstart" brukes ikke i tidligere tekst.
Siter feil: Tag <ref>definert med <references>navnet "rav" brukes ikke i tidligere tekst.
Siter feil: Tag <ref>definert i <references>kalt "arm4u" brukes ikke i tidligere tekst.
Siter feil: Tag <ref>definert i <references>med navnet "rocketsspeed" brukes ikke i tidligere tekst.
Sitat feil: Tag <ref>definert i <references>kalt "riscvc" brukes ikke i tidligere tekst.
Siter feil: Tag <ref>definert i <references>kalt "shakti" brukes ikke i tidligere tekst.
Siter feil: Tag <ref>definert i <references>kalt "iitmadrasospp" brukes ikke i tidligere tekst.
Siter feil: Tag <ref>definert i <references>med navnet "lowrisc" brukes ikke i tidligere tekst.
Siter feil: Tag <ref>definert i <references>kalt "freebsdriscv-committed" brukes ikke i tidligere tekst.

Siter feil: Tag <ref>definert i <references>kalt "freebsdriscv" brukes ikke i tidligere tekst.

Bibliografi

hjemmeside avtalenettadresserhttps://riscv.org/wp-content/uploads/2015/11/riscv-compressed-spec-v1.9.pdfTittelRISC-V Compressed Instruction Set Manual versjon 1.9 (utkast)etternavnVannmannfornavnAndrewkildedato5. november 2015

Eksterne lenker

hjemmeside avtalenettadresserhttps://www.eetimes.com/author.asp?doc_id=1323406TittelRISC-V: En åpen standard for SoCs: Saken for en åpen ISAkildedato8. juli 2014nettstedEETimes hjemmeside avtalenettadresserhttps://www.extremetech.com/computing/188405-risc-rides-again-new-risc-v-architecture-hopes-to-battle-arm-and-x86-by-being-totally-open-sourceTittelRISC rir igjen: Ny RISC-V-arkitektur håper å kjempe mot ARM og x86 ved å være helt åpen kildekodeetternavnHruskafornavnJoelkildedato21. august 2014forleggerExtremeTech hjemmeside avtalenettadresserhttp://www.adapteva.com/andreas-blog/analyzing-the-risc-v-instruction-set-architecture/TittelAnalyse av RISC-V-instruksjonssettarkitekturenkildedato11. august 2014nettstedadapteva hjemmeside avtalenettadresserhttps://scholar.google.com.au/scholar?q=%22RISC-V%22&btnG=&hl=en&as_sdt=0%2C5&as_ylo=2013Tittelsøk: RISC-V siden 2013nettstedGoogle Scholar