Kiinalainen Loongson on tullut uutisotsikoissa tutuiksi kenties merkittävimpänä kiinalaisena prosessorivalmistajana. Yhtiön prosessorit eivät käytä muualla maailmassa yleisiä käskykanta-arkkitehtuureja (ISA, Instruction Set Architecture), vaan tähän asti käytössä olleet LoongISA:n eri versiot ovat perustuneet MIPS64:ään ja yhtiön omiin laajennoksiin..
Nyt Loongsonin kerrotaan julkaisseen ensimmäisen täysin oman käskykanta-arkkitehtuurinsa. LoongArchiksi ristityn ISA:n kerrotaan olevan puhtaalta pöydältä suunniteltu eikä sillä olisi mitään tekemistä Kiinan ulkopuolella suunniteltujen arkkitehtuurien kanssa.
LoongArch sisältää lähes 2000 eri käskyä, jotka on jaettu peruskäskyihin sekä erilaisiin laajennoksiin. Tässä vaiheessa mukana on binäärin kääntölaajennokset (LBT), vektorilaajennokset (LSX), kehittyneemmät vektorilaajennokset (LASX) ja virtualisointilaajennokset (LVZ). Käskykannasta on lisäksi raporttien mukaan karsittu kaikki nykytarpeiden näkökulmasta vanhentuneet käskyt ydinten suunnittelun yksinkertaistamiseksi ja tehonkulutuksen pienentämiseksi.
PC Watchin mukaan ensimmäinen uuteen ISA-arkkitehtuuriin perustuva prosessori on ohittanut jo tape-out-vaiheen ja tullaan julkaisemaan myyntiin vielä kuluvan vuoden aikana. Tämän hetkisten tietojen mukaan markkinoille odotetaan ensimmäisinä 4-ytimistä kuluttajakäyttöön tarkoitettua 3A5000-prosessoria ja palvelinkäyttöön tarkoitettua 16-ytimistä 3C5000-prosessoria. Prosessoreiden kerrotaan olevan myös MIPS64-yhteensopivia siinä mielessä, että niille suunniteltu koodi tulee pyörimään myös uusilla prosessoreilla, vaikka alla oleva ISA onkin eri.
Lähteet: PC Watch, Tom’s Hardware
CPUille järkevästi (*)suunnitellut käskykannat eivät millään tavalla ota kantaa liukuhihnan pituuteen, samaa käskykanta-arkkitehtuuria suorittamaan voidaan suunnitella hyvin erilaisia mikroarkkitehtuureita hyvin erilaisilla liukuhihnapituuksilla.
CPUille vähän tyhmemmin suunnitellut käskykanta-arkkitehtuurit voivat suosia tiettyjä liukuhihnanpituuksia, mutta eivät pakota niihin. (eli siis käytännössä: joku 5-vaiheinen liukuhihna voidaan jollekin 1980-luvun risceille tehdä hiukan kätevämmin, mutta temput jotka teki niistä 5-vaiheisista liukuhihnoista kätevämiä, alkavat joissain vaiheessa kääntyä haittaaviksi kun liukuhihnan pituus kasvaa).
Sen sijaan CPU-käyttöön todella huonosti sopivat käskykanta-arkkitehtuurit saattavat pakottaa johonkin liukuhihnnapituuteen (monet DSPt jotka ei yritäkään olla CPUita, tai The Mill joka kuvittelee olevansa CPU, mutta on ihan vaporware-projekti jonka piti olla valmis jo aikoja sitten, eikä tule CPU-käytössä pääsemään lähellekään sitä suorituskykyä mitä tekijänsä kuvittelevat, JOS se joskus valmistuu, sen sijaan DSP-käytössä voisi olla ihan pätevä vempain)
Jos käskykannan nimessä long-sanalla tarkoitettaisiin jotain, sillä viitattaisiin yleensä käskysanan pituuteen, VLIW. Mutta eiköhän se tässä ole vaan ihan puhdasta brändäystä jollain pitkä marssi-viittauksella.
Pikaisesti Loongarchista löytyy seuraavaa tetoa:
Perusperiaatteiltaan se on RISC, jossa (toistaiseksi)(*)kaikki käskyt on 32 bittiä pitkiä, ja siinä on 32 kokonaisluku- ja 32 liukuluku-/vektorirekisteriä. vektorien maksimipituus on 256 bittiä.
Osa käskyistä on suunniteltu nimenomaan sitä slmälläpitäen, että x86- ja MIPS-koodia voidaan binäärikääntää sille. Suurin osa MIPS-koodista voidaan kääntää Loongarchille ihan suoraan yksi MIPS-käsky yhdeksi Loongarch-käskyksi.
Prosessorin mukana tulevalla x86-binäärikääntösysteemillä voidaan ajaa myös windowsia.
如何看待龙芯对外公开的 LoongArch 指令集？ – 知乎
http://www.zhihu.com
(*)Sitä on siis mahdollista laajenaa siten, että käskykannan myöhemmillä versioilla useampi 32-bittinen käskysana muodostaa yhden käsken, eli käskyn pituus voi tulevaisuudessa olla joku suurempi 32 bitin moninkerta.
ARMv8 suunniteltiin käytännössä ihan puhtaalta pöydältä uusiksi joitain vuosia sitten. Ei siinä ole käytännössä mitään vanhempien ARMin painolastia mukana.
Mutta Intelin/ AMD:n X86 prosessoreissa taas aika varmasti on. Kuinkahan paljon tehokkaampia niistä tulisi jos ei tarvitsisi kantaa vanhaa painolastia mukana?
Kyse on käytännössä siitä kuinka kauas taaksepäin halutaan olla yhteensopivia. x86:ssa taidetaan vieläkin olla yhteensopivia ihan alkumetreille asti ja prosessorit jopa käynnistyvät real modessa koska alkuperäiset x86-prossut tekivät niin, protected mode tuli mukaan vasta 286:ssa
Ei tule tapahtumaan, koska taaksepäin yhteensopivuus menee. Tulisi hirveä itku näilläkin palstoilla jos joku prosessori lopettaisi kaikkien vanhempien pelien toimivuuden.
Hyvin voisi pudottaa vanhaa tukea pois millä ei tee mitään kun tehtäisii vaikka 17 core prossu jossa se 1 on vielä vanhaa joka pyörittää vaikka sitä win3:sta ja loput sitten uutta standardia josta pudotettu kaikki turha paino pois.
Yhtiön prosessorit eivät käytä muualla maailmassa yleisiä käskykanta-arkkitehtuureja (ISA, Instruction Set Architecture), mutta yhtiön tähänastiset ISA:t ovat olleet MIPS64-pohjaisia.
En ymmärrä mitä tässä lukee. Voisiko joku suomentaa?
Siinä on ajatus katkennut.
Josko se nyt vastaisi alkuperäistä ajatusta
Ei olisi suuri menetys. Ne vanhimmat pelit eivät toimi niillä muutenkaan kiitos sen, että ne oli sidottu prosessorin kelloon tavalla joka saisi ne pyörimään varmaan tuhat kertaa alkuperäistä nopeammin nykyprossuilla olettaen, että ne edes käynnistyisivät
Ymmärtääkseni käskykannan osuus on pieni osa kokonaisuutta, jota on jo monin paikoin hiottu aika pitkälle, ja x86:n käskykanta ei ole mahdottoman huono esim. kaikkien niiden käskykantojen joukossa, jolle Linuxit ja muut isot käyttikset on portattu. Eli vaihtamalla saadaan jonkin verran lisää tehoja, mutta käskykannan vaihto ei välttämättä avaa mitenkään mullistavia uusia mahdollisuuksia löytää uutta vuosittaista kasvua.
Hieman pidemmillä elinkaarilla säästää pitkän pennin. Meitinkin firma kuluttaa vuodessa nykyisillä uusimispolitiikoilla pyöreät neljä tuhatta läppäriä ja puhelinta vuodessa. Siitä voi sitten ynnäillä paljonko säästettäisiin jos elinkaaren pituus saataisiin esimerkiksi kaksinkertaistettua. Koneiden kirjo on laaja mutta oletettakoon että keskihinta läppärillä on kaksi kiloa ja puhelimelle kaksi sataa.
Intel on 8086n jälkeen suunnitellut täysin tai melkein puhtaalta pöydältä mm.
i860n
i960n
Itaniumin.
AMD on puhtaalta pöydältä suunnitellut mm. Am29000n
Mikään näistä ei pitkän päälle menestynyt,
Piirivalmistajat ei vaan voi alkaa valmistamaan piirejä, jotka käyttävät eri käskykanta-arkkitehtyuuria, ja korvata markkinoilla olevia tuotteita niillä,koska ihmiset haluavat tietokoneita, joilla toimivat heidän vanhat softansa, ilman ylimääräistä säätämistä tai hidastelua ja tietokoneet on helpompi suunnitella kun niiden prosessoreille on kaikki BIOSit jne on ennestään olemassa, minkä takia [t]tietokonevalmistajat halauvat ostaa prosessoreita, jotka ajavat vanhaa, laajalti tuettua käskykantaa[/b]
Motorola on malliesimerkki firmasta, joka ensin yritti suunnitella täysin puhtaalta pöydältä uuden käskykanta-arkitehtuuria (88k) korvaamaan 68000:aa, ja sen jälkeen yritti yhdessä IBMn kanssa tuoda uutta käskykantaa (PPC) korvaamaan 68k:ta, ja ajoi 68k-kehityksen tämän takia käytännössä alas.
Siitä, paljonko ihmisillä nyt on Motorolan prosessoreita uusissa tietokoneissaan, ja mjitä Morotolan puolijohdeyksikölle nykyään kuuluu, näkee, kuinka hyvin tämä toimi.
x86ssa overheadia tulee lähinnä monimutkaisesta käskyenkoodauksesta, lisäksi x87-FPUn tukeminen on rasite. Ne muinaiset käskyt on rasite lähinnä validoinnin suhteen, prosessorin testaaminen vaatii paljon enemmän työtä kun pitää varmistua että kaikki oudot 35 vuotta vanhat ominaisuudet toimii myös kunnolla mutta niidne muinaisten ominaiusuksien toteuttaminen ei tyypillsiesti vaadi paljoa pinta-alaa, eikä kuluta paljoa sähkä, eikä rajoita kellotaajuuksia.
Siinä vaiheessa kun x86-64 toi uuden toimintamoodin, tästä uudesta toimintamoodista pudotettiin joitain vanhoja käskyjä pois. (näitä vanhoja käskykjä pitää silti edelleen tukea 8086- ja 386-moodeissa).
Jonkin verran enemmän käskyjä olisi silloin voitu pudottaa pois, esim. koska kaikissa x64-64-prossuissa on jo kaksoistarkkuuden liukulukuja tukeva SSE2, x87lla olisi voinut heittää vesilintua. ja vapauttaa sen käyttämät käskyenkoodaukset paremaan käyttöön x86-64-moodissa, tietääkseni kaikki kääntäjät kuitenkin käyttävät oletuksena SSE2sta liukulukulaskentaan x86-64lla.
Se, missä voisi olla järkeä olisi, että 8086-tila pudotettaisiin pois, mutta säilytettäisiin yhteensopivuus 386n kanssa; se virtual 8086-tila jolla 32-bittisen windowsin alla voitiin ajaa DOSia (kuten DOS-pelejä) ei muutenkaan enää toimi 64-bittisen käyttiksen alla (sen tilalla on moodi, jolla siellä 64-bittisen käyttiksen alla voidaan ajaa 386-softaa), joten 16-bittistä softaa ollaan joka tapauksessa ajettu emuloimalla jo monen vuoden ajan. Ja UEFI on muutenkin käytännössä jo korvannut perinteisen 16-bittisen BIOSin, joten ei vaadi suuria muutoksai boottaamiseen.
16-bittisen tilan pudottaminen pois yksinketaistaisi käskydekooderia jonkin verran, muttei dramaattisesti.
Mutta taikaisn ketjun aiheeseen, eli Loongarchiin:
Se, että samalla sanotaan, että "suunniteltiin täysin puhtaalta pöydältä" mutta "suunniteltiin sellaiseksi, että sille on helppo binäärikääntää vanhaa koodia arkkitehtuurilta X" on oxymoron, nuo väitteet on ristiriitaisia Se, että lisätään käskyjä tai käskyjen toimintamoodeja vain sen takia, että niiden tarkka semantiikka mätchäisi toisen arkkitehtuurin käskyihin (vaikka enkoodaus olisikin eri) tarkoittaa sitä, että silloin ei suunnitella täysin puhtaalta pöydältä.
Tuossa vaan laitettiin käskyenkoodaus täysin uusiksi MIPSiin verrattuna.
Eikä kukaan ole jäänyt kaipaamaan niitä vanhoja sukupolvia.
(Meiltäkin löytyy kaapin hyllyltä vielä vaimon vanha Powerbook 165 (33 MHz 68030) odottamassa tulevaisuudessa mahdollisesti tapahtuvaa keräilyarvon boostia. Melkoisen paksu möhkäle laite kyllä on).
Jos katsot markkinaosuuksia ja huomioit, että kyseessä on varsin suljettu ekosysteemi jota käytetään vain tietyillä markkinoilla löydät myös syyt miksi se on onnistunut.
Applehan lähti ARM:n tielle ja ei tuo pidemmällä aikavälillä varmastikaan tule olemaan kovin huono veto.
Onkos tää nyt neljäs arkkitehtuuri niillä reilun neljän vuosikymmenen aikana? Ne on jo tottunu romuttamaan sovellushistoriansa määräajoin
Tätä olisi mielenkiintoista kokeilla. Eiköhän tuolle ole jo joku Linux käännetty.
Ei vaan voi mitään, mutta tuosta loong sanasta tulee tämä mieleen:
https://www.youtube.com/watch?v=6-1Ue0FFrHY
Ainakin kovasti Kiinalaiset vakuuttelivat, että tuolle käskykannalle voi kääntää minkä tahansa nykyisen C / C++ kielisen sovelluksen ilman muutoksia kunhan käyttää kyseiselle prosessorille suunniteltua kääntäjää. Tosin ei taida oikeasti olla ihan näin yksinkertaista esim. ajuri ja kernel tuki vaatii ihan varmasti prosessorikohtaista hiomista, että sen saa toimimaan.
Näinpä, jotenkin alkaa olla jo turhankin tutun kuuloinen tämä "voi kääntää ihan helposti mitä vaan tälle arkkitehtuurille". Kai se kysymys on ennemminkin että jaksaako kääntää ja onko sille liiketoiminnallisia perusteita? Vähänkään isompi softa, niin 100% yhteensopivuutta ei kuitenkaan voida taata ja sitten on yksi testitapaus/koodihaara taas lisää. Vie aikaa ja/tai maksaa. Itselle ainakin tullut sellainen fiilis avoimien koodien-projekteista että hyvin usein joku vaan kääntää jonkun softan toiselle alustalle, mutta se on sitten vain forkki eikä varsinaisesti alkuperäisen kehitystiimin varmistama versio. Kaupallisissa tuotteissa olen myös töiden puolesta pannut merkille että eri arkkitehtuurituet ovat pikkuhiljaa vähentyneet koko ajan. Jossain tapauksessa syynä on varmaan jonkun alustan vähentynyt käyttö, mutta mukana on myös ihan toiminnan tehostamista rönsyjä karsimalla. Päälle vielä se että vaikka pysyisikin samalla alustalla, niin muutostahti voi olla sellainen että voi olla melkoisen haastavaa tukea edes sitä yhtä alustaa (vrt. Androidin eri sukupolvet).
Ajatus mitä yritän ajaa takaa on se, että prosessoreissa vähintä mitä uuden kilpailevan tekniikan pitää luvata on juurikin jotain tämänlaista hyvin kattavaa tukea vallalla olevalle tekniikalle. Uuden ratkaisulla pitäisi lisäksi olla vielä jotain selviä kilpailuetuja,minkä takia sillä kannattaisi alkaa vanhaa tekniikkaa korvaamaan. Se että vie vähemmän sähköä, on nopeampi, tai edes näiden prosessorin tärkeimpien kustannuslaskentakomponenttien kombinaatio parempi perf/watt ei välttämättä riitä. Tilannetta on sotkemassa yritysten väliset sopimukset, epäreilut kilpailutaktiikat, infrastruktuureiden muut epäyhteensopivuudet esim. serverifarmien virtualisointisoftat, rautatason hallintasoftat, rakennetut sovellusympäristöt jne. Jopa hyvin alustariippumattomaksi suunnitellut konttiratkaisut eivät ole täysin immuuneja arkkitehtuuridiversiteetille.
Tässä tapauksessa tietysti parempi jos ei loongson pärjäisikään (paha Kiina), mutta AMD:ta seuraamalla näkee kuinka vaikeaa tuollaista monopolifirmaa (Intel) on oikeasti syrjäyttää.
Jaa M1:nhän siis korvaa jatkossa x86:n applella kokonaan, niin mistä/minkä arkkitehtuurista nyt puhut ? Itse puhuin siis rautatason ARM -suorittimesta. Sovellukset (tai apit) pystyy kyllä kääntämään x86 –> ARM yhteensopiviksi melko nopeastikin näemmä mikä on omasta mielestä jonkinmoinen ihme. Luulen että ovat tehneet kääntäjiä jo pitkän aikaa valmiiksi ennen oman suorittimensa julkistamista.
Aluksi Applet tehtiin Motorola 68k prosessoreilla (1984-19926. Sen jälkeen siirryttiin Applen, IBM:n sekä Motorolan suunnittelemiin PowerPC suorittimiin (1995-2003). Kolmantena vuorossa oli suoraan ostettu x86, aluksi 32 bittisenä (2006-2010) ja sittemmin 64bittisenä (2008 – 2019).
Nyt sitten neljäntenä täydellisenä muutoksena tulee sitten ARM prosessorit ja käskykanta muuttuu jälleen.
Ai niin rakensivathan he koko käyttöjärjestelmän uusiksi OS9 ja OSX välillä.
(Mikä oli ihan helvetin hyvä kun ne ei päässy harmaista laatikoista muten irti) molemmat kuvat win xp:n ajalta:
katso liitettä 592503
Rosetta 2 voi kääntää x86-64 ohjelmat, mutta on ne silti emulaattori tuottamaa koodia eikä natiivia koodia. Applen ARM vain on niin nopea, että pystyy jossain tapauksissa ajamaan emuloitunakin ohjelmia nopeammin kuin Intel. Sinällään kyllä sellainen saavutus, että ei oikein löydy syitä miksi Apple palaisi Intelin prossuihin jos emuloitukin koodi pyörii nopeammin ja pienemmällä virrankulutuksella kuin Intelillä.
Tosta on tulossa oma uutisensa eri lähteestä, voivat puhua mitä vaan ryzeneistä ja skylakeista, mutta jos ihan nähtävissä olevilla testituloksilla mennään niin ei näytä ihan tolta. Tää Phoronixin toteamus tiivistänee aika hyvin
Tomshardwaren uutisesta löytyikin, mikä testi kyseessä. Jos osaan oikein vertailla, niin Ryzen 2700X saisi 41,89 pistettä yhden ytimen osalla (GCC) AnandTechin mukaan.