jor1k - Javascript-ben írt, Linuxot futattó OpenRISC 1000 emulátor

Linux

jor1k: OR1000 Javascript Emulator Running Linux

Az OR1K egy Javascript-ben írt emulátor, amely Linuxot futtat. A GPL alatt terjesztett forráskód elérhető a Github-on.

fbinfo a jor1k-n
fbinfo

Az emulátor online demójának kipróbálásához tippek itt.

( Fisher v | 2013. 06. 27., cs – 14:22 )

Valaki el tudná magyarázni hogy ez hogyan működik úgy, hogy egy óvodás szintjén lévő (én) is megértse? Valahogy nem tudom összeilleszteni a JS szintjét a hw emulátor szintjével.

http://s-macke.github.io/jor1k/js/worker/cpu.js
Ez nem gate level. Innen nezd: 'switch ((ins >> 26)&0x3F)'.
Az OpenRisk projectnek van egy emulatora ami szinten nem gate level.

Az hogy az OpenRisk -nak van verilog kodja egy dolog.
A verilog onmagaban, is magasabb szintu , mint a gate szint ,kozelebb van a register-transfer level-hez, de vannak toolok
amik alacsanyobb szintu dologga alakitjak, (pl.: klassikus logikai aramkori elemek (pl.: szamlalo),
logikai kapuk (pl.: NAND), lekepezes FPGA vagy ASIC elemekre..)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

van egy, a WebGL miatt bevezetett adattípus, az Int32Array (meg talán van Int64Array is).

Ez típusos, ismert méretű és mivel egy emulátornak nem igazán kell foglalkoznia az adat valódi típusával, viszont a fordító (mert a közhiedelemmel ellentétben a JS-be JIT van) is szépen rá tud feküdni, amíg nem lép ki az összeadás-kivonás-shiftelés-szorzás bűvköréből, így effektív kapsz egy C kódot rá.

Nyilván amint vegyes adattípusokkal (pl. HTML DOM node-ok piszkálásával) kell foglalkozni, rögtön esik a teljesítmény, de emulációra tökéletes, és szinte tuti erre épül az Emscripten is, ami az LLVM JS targetje.

( sabe v | 2013. 06. 27., cs – 14:46 )

És lehet rajta javascriptet futtatni amiben indíthatnék egy OpenRisc emulátort...?

( Zahy v | 2013. 06. 27., cs – 15:27 )

Elsőre azt hittem, a forráskód 1K, és csettinteni akartam.

( answ | 2013. 06. 27., cs – 15:54 )

Egy kis teszt:

bc -l
2^10000
quit

bc -l
2^10000

Ekkor:
4.2-4.5 millió IPS Chrome 27
6.5-7.5 millió IPS Opera 12.15
9.1-9.5 millió IPS IE 10
15-15.7 millió IPS Firefox 22

Core i5-2400 @ 3.10 GHz
Windows 7 Professional 64 bit

Probald ki a 'yes' parancsot.

Valoszinuleg, ha nem csinal semmit az kevesebb host CPU orjaelbol meg lehet csinalni.
A kozolra iras mar valami, ami miatt kevesebb ido jut a cpu emulalasara.

Ha dragabban emulalhato utasitasokat hasznalnal az is latszik.

Valoszinuleg intenzivebb memoria kezeles is 'lasit'...

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( artifex | 2013. 07. 01., h – 12:30 )

Ilyet használ valaki? Mert az ilyen böngészőbe bújt emulátorok nagyon jópofák, de érdekelne, hogy használja esetleg valaki-e őket "élesben".

"Belépés díjtalan, kilépés bizonytalan."

( BaT | 2013. 07. 03., sze – 08:17 )

Tetszett az a framebuffer a terminál mellett, de az nem tetszett, hogy az fbinfo-n kívül semmivel nem tudok bele értelmeset rajzolni. Mivel a framebufferre közvetlenül lehet írni a /dev/fb0-n keresztül, úgy döntöttem írok rá egy raytracert shellben. Aztán végül bc-ben írtam, egyedül a text-binary átalakítás hárult a shellre, mivel fogalmam sincs hogyan lehetne bc-ből bináris outputot kicsikarni.

A kód:
bc -lq raytracer.bc | while read line; do printf $line; done > /dev/fb0

Renderelt képet nem adok, akit érdekel futtassa le, pár óra alatt lefut. :)

A következő projekt: animáció dd seek segítségével.

Ppm outputot lehet vele csinálni mindössze két sor átírásával, és akkor megnyitja a display. :)

Egyébként az nekem is probléma volt, hogy nem tudok másolni bele, de muszáj volt élesben is kipróbálnom, szóval végül csak begépeltem. Cat-tel, mert bár van vi, de az kicsit bugzik, meg amúgy se szeretem.

Szerk: oké, csináltam egy valós rendert, kíváncsi voltam pontosan hány óra kell hozzá. Persze a time kevesebbet mutat, kb. 2.23x gyorsabban jár az idő valójában, vagyis a renderhez kicsit több, mint 5 és negyed óra kellett.