Esély, hogy FPGA-ba behúzható, nyílt változata lesz valamikor?
Nagyon faja lenne, ha elterjedhetne. Micsoda jövő, amikor már nem csak a szoftvered szabad, hanem a hardvered is!
Persze ehhez majd kell egy olyan board is, amin megfelelő csatlakozók vannak és elérhető árú, tehát nem 3000$

Bélabá

Remek hír, csak legyen is belôle vmi belátható idôn belül!

[link]
Úgy nézem, lehet fpga optimalizált verilog kódot generáltatni, ami elég fasza.

Köszi, ez eléggé felvidított: The fpga-zynq repository contains infrastructure for implementing Rocket cores on Zynq FPGAs, like the Zybo and ZedBoard.
ZedBoard: 475 USD, ezért van benne HDMI, giga Ethernet, USB, 512 DDR3, SD slot hang és ami a legfontosabb: ugyan device-locked, de Vivaldo Design suite (na meg 2 hard IP A9 ARM mag)

Zybo: 189 USD, egyetemi kedvezménnyel még kevesebb, ugyan 20$ hozzá a Vivaldo licensz, SD kártya és táp, de 512 MB DDR3, GbE, USB, HDMI, hang.
Sajnos megint megvan, mire fog elmenni a nem létező szabadidőm és spórolásom

Bélabá

"Ezután az ARM került reflektorfénybe, amely reálisabb alapnak tűnt, de így is túl komplexnek ítélték, így végül ezt sem licencelte az egyetem. Az informatikai tudományos csoport ezután kezdett dolgozni egy alapjaiban új utasításarchitektúrán.

Az első specifikáció 2014-ben elkészült és ilyenkor kapta meg a projekt a RISC-V nevet."

Az ARM ugyebár RISC, sőt, maga az ARM-ban az R is a RISC-et fedi. De ez nem ARM, viszont RISC-V nevet választottak neki... Nincs elég betű az ABC-ben, hogy valami más nevet találjanak ki, amivel nem fogja a fél világ össze-vissza keverni ezeket?

Fotóim és kalandjaim a világ körül: https://www.facebook.com/fmartinphoto/

Mivel ez csak egy alap, elég valószínű, hogy mindenki fog magának brandelni sajátot (apple A*, Samsung Exynos, Qualcom Snapdragon mintájára), és ennél a névnél tovább nem lát az átlag felhasználó, jó esetben a rootoló power user, de még az átlagos szoftverfejlesztő sem. (ennek meg is van a hátránya, de az másik történet)
A felhasználó továbbra is iPhonet/iPadet, Androidos vagy Windowsos telefont/tabletet fog venni. Kérdezd meg a felhasználókat, mi különbség van a "nyolcmagos processzor" (jobb esetben Cortex A57 is szerepel a leírásban) és az Atom Z3735 között. Köpni-nyelni nem tudna.

Bélabá

De, az x86 tényleg nem 100%-osan CISC. De ez nem számít, mert ahogyan a cikk is írja, a Berkeley-nek azért nem felelt meg, mert nagyon bonyolultak az utasítások és még fizetni is kellett volna érte. Az x86 nagyon elavult már - igaz, hogy sokat finomítottak rajta, de még a Skylake is visszavezethető egészen a 8086-ig. Ők pedig ezt a RISC-V-ot szándékosan futureproof-ra tervezték, lásd 128 bites címzés.

Amúgy erről a lowRISC-ről olvastam néhány hónapja, tudtam, hogy ez nagy dolog lesz. Kellemes meglepetés, hogy prohardveres cikk is megjelent róla.

Erről jut eszembe. Ez a RISC-V tudna esetleg használható sebességgel hardware-esen emulálni x86-ot? Tehát elvben meg lehet csinálni, hogy fokozatosan átálljon rá a desktop PC is, ha valamiért úgy alakulna, vagy ilyenkor az OS kernelnek kéne emulálni (vagy persze a fordítóknak, csak honnan veszünk forráskódot a magannyi zárt forrású régi programunkhoz, amit már nem fejlesztenek tovább...), utóbbi esetben kb. milyen lehetne a hatékonyság?

[ Szerkesztve ]

TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

2010 óta használják a RISC-V nevet.
Eredetileg oktatási, kutatási célra találták ki, egy egyszerű utasításkészletű ISA-t könnyebb szemléltetésre használni, illetve implementálni.
Korábban MIPS architektúrát használtak az oktatás során. Szóba jöhetett volna az OpenRISC, ami nem volt megfelelő, illetve az ARM és az x86, de azok túl bonyolultak.

(#5) .mf
A Berkeley Egyetemen találták ki a RISC kifejezést, a RISC-I és a RISC-II processzorokat (1980-84) és ebből született a SPARC architektúra. Ezzel egy időben a szomszéd Stanford Egyetemen a MIPS-et fejlesztették. És csak utána jöttek a többiek.

Az x86 egy híbrid módosított harvard architektúra.

Úgy szokták jellemezni hogy az x86 utasításkészlet CISC de az architektúra meg belül RISC.
x86 egy utasításkészlet, akkor minek az architektúrájáról beszélünk?

1. A cache a programozó szempontjából transzparens, nem feltétlen kell neked tudnod róla, hogy az L1 szinten külön van. A programozó számára látható memóriában pedig adat és utasítás is egyaránt van. Ez az besorolósdi egyébként kapufa.

2. Az x86 utasításkészletre szerintem tévedés mondani, hogy RISC (hibrid vagy akármi). Az utasításkészlet CISC (változó hosszúságú utasítások, sokféle címzés stb).
Az más kérdés, hogy az x86-os utasításkészletű processzorok úgy vannak megvalósítva, hogy a bonyolult utasításokat RISC elvű, egyszerűbb utasításokra bontják, és úgy hajtják végre, de ennek az x86-os ISA-hoz nincs köze, ez már implementációs kérdés.

[ Szerkesztve ]

Ígéretes cuccnak tűnik, 128 bites float (végre már), 128 bites integer, decimal float, stb. támogatás. Viszont ezt valaki nálam hozzábbértő megszakérthetné:
"RISC-V intentionally lacks condition codes, and even lacks a carry bit.[3] The designers claim that this can simplify CPU designs by minimizing interactions between instructions.[3] Instead RISC-V builds comparison operations into its conditional-jumps.[3] Use of comparisons may slightly increase its power usage in some applications. The lack of a carry bit complicates multiple-precision arithmetic." [link]

Mennyire lehet problémás ezzel az ISA-vel az arbitrary prec? Mert a dokumentáció szerint elérhető RISC-V-re is a GMP, MPC, MPFR. [link], [link]

Egyébként nem csak a Google/HP/Oracle, hanem a Microsoft, a DARPA/AFRL, a Samsung, az Intel és az Nv is támogatja valamilyen szinten.

[ Szerkesztve ]

"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari

Na várj, 128 bites ALU, vagy 128 bites címtér? Nekem az jött le, hogy az utóbbi!

Ha nincs carry bit, akkor valami egyéb módon kell jelezni, ha carry keletkezett. Hogy ez miként lesz megoldva, kérdéses (komplett regisztert használni erre például)

Bélabá

Egyszerű, 64 bites regiszterekbe 32 bites számokat töltünk be és azokat adjuk össze, az eredmény 32. bitje a carry bit.

Nekem meg az, hogy mindkettő. A 128 bites integer regiszterek is támogatottak: 81. oldal (Chapter 17, RV128I Base Integer Instruction Set)

(#19) namaste:

Tehát akkor nem túl bonyolult a megoldás.

[ Szerkesztve ]

"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari