
Applen on jo vuosia huhuttu siirtyvän myös Mac-tietokoneissa Arm-prosessoreiden käyttöön. Nyt tuo hetki alkaa olemaan käsillä, sillä Apple ilmoitti virallisesti tuovansa itse kehittämänsä prosessorit Mac-tietokoneisiin.
Apple ei kertonut toistaiseksi vielä tarkempia yksityiskohtia tulevista Mac-siruistaan, mutta kertoi siirtymän tapahtuman vaiheittain. Ensimmäisen Arm-Macin toimitukset aiotaan aloittaa vielä tänä vuonna ja koko mallisto tulee siirtymään niiden pariin suurin piirtein kahdessa vuodessa. Yhtiö varmisti myös, että se tulee julkaisemaan ainakin toistaiseksi myös Intel-pohjaisia Mac-tietokoneita ja tulee luonnollisesti tukemaan macOS:n x86-versiota hamaan tulevaisuuteen.
Kehittäjät pääsevät työhön niin ikään tänään esitellyn macOS Big Surin kanssa, jonka pariksi on tarjolla A12Z Bionic -järjestelmäpiiriin perustuva Developer Transition Kit. Xcode 12 työkaluineen ja Universal 2 -binäärit mahdollistavat yhtiön mukaan helposti sen talon sisällä kehitettyjen prosessoreiden hyödyntämisen sovelluksissa menettämättä kuitenkaan samalla yhteensopivuutta Intel-Macien kanssa. Lisäksi tarjolla tulee olemaan Rosetta 2, mikä mahdollistaa Intelille suunniteltujen sovellusten ajamisen Arm-prosessorilla vaikkei kehittäjä olisikaan tehnyt siitä natiivia versiota uusille prosessoreille.
Lähde: Apple
ARMissa on jo pitkään ollut NEON-niminen 128-bittinen vektorikäskykanta. Ominaisuuksiltaan ollut jonkin verran SSEtä parempi, mutta vain 128-bittinen kuten SSE.
Pari vuotta sitten julkaistiin SVE ja tänä keväänä SVE2, jotka ovat sitten paljon kehittyneempiä vektorikäskykantoja, SVE(2)ssa vektorin leveys on implementaation päätettävissä, tukee vektoreita jopa 2048 bittiin asti.
Eli itse SVE/SVE2-käskykanta ei lyö lukkoon vektorin pituutta, vaan implementaatio toteuttaa jonkun leveyden sekä mm. käskyt "lisää pointeria vektorin pituuden verran" "lisää laskuria vektorin elementtimäärän verran" "kytke pois päältä vektorilinjat joiden indeksi menee tämän laskuriarvon yli", mikä mahdollistaa sen, että kääntäjä voi autovektoroida melkein minkä tahansa loopin jossa ei datariippuvuuksia, ja se ajautuu oikein (ja optimaalisella nopeudella) riippumatta siitä kuinka leveät vektorit raudala löytyy; Kapeammilla vektooreilla loppia vaan pyöritään useampi kierros.
Erittäin epämääräisiä huhuja:
Mutta Microsoft varmasti haluaa nopean arm prossun Windowsille mahdollisimman nopeasti – pari vuotta viivyttelyä ja game over.
-Applella sen sijaan ei ole niin helppo kysymys kannattaako pelkkien prosessorien myynti – nyt voi käydä niin että Mäcistä tulee ARM-serveripuolen kehitysalusta kun muuta varteenotettavaa ei ole tarjolla.
https://mondaynote.com/apple-silicon-the-passing-of-wintel-79a5ef66ad2b
Mun mielestä kyllä ihan huuhaata. Intelin ongelmana on ollut vanhentunut valmistusprosessi. Se tulee joskus kuntoon, ja vaikka ei tulisi, niin AMD joka tapauksessa valmistaa prosessorit TSMC:n valmistusprosesseilla. Kirjoittaja tuntuu olevan sitä mieltä, että x86 on vain niin huono, että kannattaa vaihtaa. Hän ohittaa kokonaan ne ongelmat, mitkä tulisivat, jos prosessorit vaihtuisivat. Apple on luultavasti tehnyt vuosikausia hommia saadakseen Rosettan toimimaan hyvin.
No x86 on HUONO tätä nykyä. Jotain modernisaatiota kaipaa kun nykynen ISA on suunniteltu 16 bittisille laitteille ja on 40 vuotta vanha, johon lätkitty vaan lisää päälle.Ja kuin kirsikaksi kruunuun se 16 bittinen ISA oli suunniteltu lähdekoodi yhteensopivaksi 50 vuotta vanhan 8-bit vermeille tarkoitetun ISAn päälle.
RISCeillä duunailleena tuntuu nykyään aika tympeältä kun x86 käskyt ei olekkaan ihan niin standardi mittasia vaan siellä voi olla se 1 byte (nop) ja sitten aika helvetin pitkiin olikos nyt 15 tavua pitkiin hirvityksiin
CISCin iloja. Enempi alkaa olemaan rajoitteena jo sekin että siinä missä modernimmissä vermeissä on enempi yleiskäyttösiä rekisterejä niin niiden lukumäärä laahaa x86_64:ssa perässä. Sitä en tiedä miksi aikanaan ei x86_64sen kanssa hypätty suurempaa GPR lukumäärään.
Näitä ongelmia ei valmistusprosessi korjaa :/
Ei ole. x86-64 on toiseksi paras yleisesti käytetty CPU-käskykanta, heti ARMv8n jälkeen.
Se on parempi kuin esim. SPARC, MIPS, PPC, Itanium, RISC-V tai Alpha.
Sitä on modernisoitu vaikka kuinka moneen kertaan:
80386 poisti pakon käyttää segmenttejä mihinkään ja toi modernin ja järkevän muistinhallintayksikön.
P6 toi ehdolliset käskyt (vähensi selvästi haarautumisten tarvetta) sekä laajensi fyysiset osoitteet 36-bittisiksi.
P4 toi SSE2n jonka avulla ei ollut mitään tarvetta enää käyttää x87-FPUsta joka oli hirveä sotku.
K8 laajensi kokonaislukudatapolun 64 bittiin, virtuaaluosoitteet 48 bittin (optiolla laajentaa ne täyteen 64 bittiin asti) ja poisti 64-bittisessä tilassa viimeisetkin jäljet segmenteistä. Ja samalla osa alkuperäisistä opkoodeista uudelleen.
Tällä ei ole mitään merkitystä. Se, että joillekin rekistereille määritellään samat aliakset assemblyyn ei haittaa yhtään mitään.
"tuntuu tympeältä" arvo teknisenä argumentina on puhdas 0.
Keskimääräinen käskynpituus x86lla on lyhempi kuin suurimmalla osalla RISCejä, ja jos verrataan muihin kuin ARMv8iin, saman asian tekemiseen tarvitaan myös vähemmän käskyjä => koodin koko samalle asialle selvästi pienempi, ja tällä saadaan mm. parempi käskyvälimuistien osumatarkkuus.
Ja niitä 15 tavun käskyjä ei käytännössä koskaan näe missään. Se tarkoittanee sitä, että siellä on kaikki erilaiset prefix-tavut ja sitten jostian pitkästä käskystä versiot joissa on pari 64-bittistä immediate -arvoa. Saman asian tekevät RISC-koodi muuten vaatii PALJON ENEMMÄN tavuja, kun esim useimmissa RISCeissä pelkästään YHDEN 64 bitin immediaten siirtämiseenkin tarvitaan 128 bittiä=16 tavua käskyjä.
Ja x86ssa on vaikka kuinka paljon HYÖDYLLISIÄ JÄRKEVÄÄ TYÖTÄ TEKEVIÄ yhden tavun käskyjä. 4 kertaa lyhyempänä kuin useimmissa RISCeissä. Yhden tavcun ksäkyt ei yleensä ole mitään NOPeja, toki on olemaassa myös yhden tavun NOP.
Se, että käskyt on hankalampi dekoodata tuntuu pikkusen, esim siinä että järeimmät x86-prossut dekoodaa vain 4-5 käskyä kellojaksossa (ja yksi vähemän järeä 2*3), ja käskyn dekoodaukseen tarvii pari liukuhihnavaihetta. Ja siihen, että saadaan prossu etupäässä käsiteltyä enemmän kuin 4-5 käskyä kellojaksossa on silti ratkaisu olemassa, mikro-op-välimuisti, joka tallettaa dekoodattuja käskyjä, löytyy Inteliltä P4sta sekä Core-sarjasta Sandy Bridgestä lähtien, ja AMDltä Zenistä lähtien.
Se mikro-op-välimuisti maksaa inasen pinta-alaa, mutta pii-pinta-ala on nykyään älyttömän halpaa. Ja se 1-2 vaihetta pidempi decode-vaihe tuntuu inasen haarautumisenennustushudissa, mutta se, onko se 16,17 vai 18 kellojaksoa ei ole kovin merkityksellistä, kun haarautumisenennustus on kuitenkin todella hyvä, ja huti on joka tapauksessa paha hidastus.
Rekisterien uudelleeniomeäminen on keksitty, ja x86-käskyt voivat lukea operandinsa suoraan muistista. Mitään merkittävää pullonkaulaa rekisterimäärän suhteen ei x86-64ssa ole.
Nykyisissä x86-prossuissa on ~180 yleiskäyttöistä rekisteriä.
Jospa ottaisit selvää, mistä puhut.
x86-64ssa yleiskäyttöisten kokonaislukurekisterien määrä nimenomaan nostettiin kahdeksasta kuuteentoista, koska se 8086n/80386n 8 oli jossain määrin pullonkaula.
Ja syyt miksei sitä lisätty enempä on selvät ja hyvät:
Arkkitehtuurilliset rekisterit näkyy käskyenkoodauksessa. x86-käskyt voivat olla paljon lyhempiä (todella monet yleiset käskyt on 2 tavua, REX-prefixin kanssa 3, tyypillisillä RISCeillä 4 tavua) koska rekistereitä on vähän ja kohderekisterin pitää useimmilla käskyillä olla sama kuin toisen lähderekisterin. Rekisterien tuplaus 8->16 maksoi jo tuon REX-prefix-tavun. Rekisterien määrän laajennus 32 bittiin olisi käytännössä maksanut varmaan toisen tavun, ja poistanut täysin x86n käskyntiheysylivoiman.
Nyt siis x86n koodintiheysetu kapeni selvästi näiden REX-tavujen takia.
Ja hyöty 32 arkkitehtuurillisesta rekisteristä hyvin, hyvin pieni.
Rekistereitä vaatii paljon lähinnä sellaisiin optimointeihin, joita spekulatiivisella out-of-order-prosessorilla ei tarvitse tehdä.
Mutta, tuo tapa miten tuo reksiterien määrän lisäys jouduttiin tekemään tuolla REX-prefixillä on käytännössä melkein AINOA historiapainolasti jota x86-64lla on jäljellä; Jos itse käskykannan olisi pitänyt samana mutta käskyenkoodauksen olisi voinut laittaa täysin uusiksi, samat käskyt olisi menneet keskimäärin hiukan pienempään tilaan, jolloin x86n etumatka käskyenkoodauksen tiheydessä ei olisi kaventunut kuten se nyt kapeni.
Nämä eivät ole mitään ongelmia.
Jospa puhuttaisiin niistä muiden arkkitehtuurien oikeista/suuremmista ongelmista:
* MIPSissä ja SPARCissa on branch delay slot.
Hypyn jälkeinen käsky suoritetaan aina, otettiin hyppy tai ei. Tällä saatiin poistettua stalli 5-vaiheiseltaä liukuhihnalta 35 vuotta sitten.. Nykyisssä prossiossa on n. 12-18-vaiheisia liukuhihnoja ja ne fetchaa 4-8 käskyä kellojaksossa. Delay slotteja tarvittaisiin n. 71-95 kpl että niillä voitaisiion ratkaista tämä ongelma mitä delay sloteilla silloin ratkaistiin => nykyään käytetään haarautumisenennustusta haarautumisenkohdepuskurin kanssa. Se, että meillä on se yksi delay slotti siellä tekee vaan kaikesta hankalampaa, ja välillä pakottaa kääntäjän myös tunkemaan sinne ylimääräisen NOPin.
* MIPSissä on erilliset lo- ja hi-rekisterit kerto- ja jakolaskulle.
Näiden takia kerto- ja jakolaskujen kanssa tarvitaan hirveä ylimääärinen härväys datan siirtämiseksi näihiin tai näistä pois. Vähän samaa ongelmaa kuin mitä oli x87.FPUssa (jota ei enää 18 vuoteen ole tarvinnut käyttää)
* SPARCissa ja Itaniumissa on rekisteri-ikkunat.
Nämä tekevät rekisterien uudelleennimeämisestä paljon vaikeampaa, ja tämän takia Sun teki ensimmäisen käskyjä uudelleenjärjestelevän SPARC-suorittimen n. 16 vuotta muita valmistajia myöhemmin. Ja käskyjen uudelleenjärjestely rekisterien uudelleennimeämisellä on käytännössä elinehto hyvälle tai edes välttävälle yhden säikeen suorituskyvylle tällä vuosituhannella.
* MIPSissä, RISC-Vssä ja Alphassa ei ole muuta muistinosoitussmuotoa kuin [reg+imm].
Eli jos halutaan vaikak tehdän normaalia taulukon käyttämistä, tarvitaan siihen KOLME käskyä (indeksin skaalaus datatyypin kokoiseksi, pointterin ja skaalatun indeksin yhteenlasku, ja iutse muistioiperaatio). x86 ja ARM tekee tämän yhdellä käskyillä. Joissain muissa RISCeissä on [reg+reg] eli sujuu kahdella käskyllä, parempi kuin MIPS, RISC-V ja Alpha, mutta silti huonompi kuin ARM ja x86.
* RISC-V:stä puuttuu kokonaan kaikki muut ehdolliset käskyt kuin hypyt.
Koodiin tarvitaan selvästi enemmän haarautumisia, joka pikkuprossulla tarkoittaa enemmän stalleja, tehokkaalla prossulla tarkoittaa sitä, että haarautumisenennustusyksikön kirjanpidosta loppuu tila aiemmin kesken ja sen osumatarkkuus on huonompi. (eli lopulta myös enemmän stalleja). Ja siinä ei ole ollenkaan nopeaa keinoa suorittaa koodia, jossa on haarautumisia, joita on mahdoton ennustaa, esim hakuja binäärihakupuusta; Tällöin se joutuu aina haarautumaan ja failaamaan ennustuksen (josta seuraa pitkä paha stall ja haaskattua virtaa) 50% tapauksista, siinä missä muilla arkkitehtuureilla voidaan ehdollisilla siirroilla odottaa vaan pari kellojaksoa sitä ehdon laskentaa.
* PPCssä on hyvin monimutkaiset käänteiset hajautustauluun perustuvat sivutaulut, joiden käsittely käyttöjärjestelmän toimesta on todella hankalaa ja hidasta, ja niiden lisäksi käyttis joutuu vielä toteuttamaan omaa kirjanpitoaan jota normaalien hierarkisten risvutaulujen tapauksessa ei tarvita (koska suorana prossun käytössä olevat sivutaulut toimii suoraan myös käyttiksen omana kirjanpitona). Tämä tekee esim. uusien prosessien luonnista sekä prosessien vaihtamisesta PPCllä hitaampaa ja on vaikempaa kirjotitaa käyttiskoodi joka tekee nämä bugittomasti.
* PPC on natiivisti big-endian ja sen lisäksi myös kutsuu suurinta bittiä indeksillä 0, pienintä bittiä indeksillä N-1 missä N on prosessorin bittimääärä. Eli alin bitti on jokko bitti 31 tai bitti 63 riippuen prossun toimintatilasta, samoin se bitti mikä 32-bittisenä on ylin bitti on joko bitti 0 tai bitti 32 riippuen prossun toimintatilasta. Melkoista sillisalaattia.
* Itaniumissa kolme käskyä vie yhteensä 16 tavua tilaa, ja sen lisäksi koodiin tarvitana NOPeja => itanium-koodi vie TODELLA PALJON tilaa => Suuri muistintarve käskyille, käskyvälimuistin huono osumatarkkuus.
* RISC-V:stä puuttuu täysin järkevät "keskiraskaat" SIMD-laajennokset.
Sille on määritelty P-laajennos, joka vain mahdollistaa skaalarireksiterien pätkimisen pienemmiksi laskutoimituksisksi, mutta tämä tarkoittaa sitä että vektorin leveys on 32-bittisellä prossulla 32 bittiä ( 8 kertaa kapeampi kuin AVX) ja 64-bittisellä prossulla 64 bittiä (4 kertaa kapeampi kuin AVX). Näillä ei suurta suorituskykyä saada.
Lisäksi sille ollaan määrittelemässä V-laajennusta joka on ominaisuuksiltaan paljon "parempi," mutta se ihan hirveä overnengineerattu häröpallo, joka ei todennäköisesti monimutkaisuutensa takia tule saamaan kunnollista kääntäjätukea n. 10 vuoteen, eikä sitä varmaan implementoidakaan käytännössä mihinkään koska sen implementointikin on niin hankalaa.
* Alphasta ja SPARCista puuttuu myös kaikki "keskiraskaat" ja järeämmät SIMD-laajennokset. Niissä on vain RISC-V:n P-extension tapainen normaaleita (kapeita) skalaarirekisterejä käyttävä, jolla suoerituskykyä ei saa paljoa.
* Kaikilla muilla arkkitehtuureilla paitsi x86lla ja SPARCilla on löysemmät muistin konsistenttiussäännöt. Koodiin tarvii lisätä ylimääräisiä fence-käskyjä, joiden yli muisitoperaatioita ei saa uudelleenjärjestellä, jos halutaan, että muistioperaatiot näkyy toisille säikeille samassa järjestyksessä. X86 voi kuitenkin todellisuudessa uudelleenjärjestellä muistioperaatiota, kunhan vain pitää kirjaa niiden alkuperäisestä järjestyksestä ja sekä huolehtii järjestyksen näennäisestä säilymisestä säikeen sisällä (mm tarvittaessa forwardoiden arvoja store-puskurista loadeille) että välittää muutokset toisille säikeille konsistenttiussääntöjen mukaisessa järjestyksessä.
Mikäli muista, löysemmät konsistenttiussäännöt omaavista arkkitehtuureista tehdään muistioperaatioita yhtä aggressiivisesti uudelleenjärjesteleviä versiota, ne joutuvat kuitenkin pitämään kirjaa operaatioiden alkuperäisestä järjestyksestä sekä tekemään saman store-to-load-forwardingin yhden säikeen sisällä. Tällöin niistä löysemmistä konsistenttiussäännöistä ei enää hyödytäkään mitään, kun ne kuitenkin feikataan, ja jäljelle jää lähinnä overhead niistä fence-ksäkyistä (jotka pakottaa flushailemaan paljon muutakin kuin oikeasti tarvisi)
* ARMv8lla, SPARCilla, PPCllä ja Alphalla kaikki käskyt on 32 bittiä pitkiä. Erityisesti SPARCilla ja PPCllä tämä tarkoittaa huonohkoä käskytiheyttä => tarvitaan paljon käskymuistia, huonompi osumatarkkuus käskyvalimuistille.
ARMv8ssa on sama ominaisuus, mutta siinä on niin paljon ilmaisuvoimaisempia käskyjä, että se tarvii vähemmän käskyjä saman asian tekemiseen, että siinä tämä ei ole merkittävä huonous, sen koodin tiheys ei silti ole huono. PPC on myös jossain määrin ilmaisuvoimaisempi kuin SPARC eli oikeastaan pahana jää jäljelle vain SPARC:
RISC-V:ssä, MIPSissä ja ARMv7ssa sitten myös 16-bittinen käskyenkoodaus eniten käytetyille käskyille, ja ARMv7/Thumb2lla päästää jopa 386sta tiheämpään koodiin ja MIPS16 ja RISCV-C pääsee lähelle 386sta ja välillä jopa voittaa x86-64n.
* Alphassa ei ole hardware-page walkeria. Mikäli osoitteenmuunnosdataa ei löydy TLBstä, seuraa poikkeus joka lentää PAL-koodilla olevaan käsittelijään, joka lataa sivutaulun hitaasti softalla. Tämä on paljon hitaampaa kuin sivutaulujen hakeminen raudalla.
* MIPS, SPARC, Itanium, Alpha eivät tue alifgnoimattomia muistiaccesseja. RISC-V tukee, mutta ainakin toinen kahdesta yleisimmästä kääntäjästä sille kieltäytyy tekemästä niitä, lähinnä koska niiltä vaaditaan tukea vain user-moodissa ja kääntäjän halutaan toimivan myös kernelille.
Näillä arkkitehtuureilla, jos kääntäjä ei pysty todistamaan, että (muuten laillinen) muistiaccess on alignoitu, se luo hirveän häröpallokoodin jossa muuttaa (mahdollisesti) alignoimattoman muistiaccessin moneksi alignoiduksi muistiaccessiksi. Ja tämä häröpallokoodi on HIDAS.
Ja tosiaan, vaikka itse access olisi oikeatit alignoitu, mutta kääntäjä ei vaan tiedä sitä, tämä häröpallokoodi tehdään.
Arkkitehtuureilla, joissa unaligned accessit on aina tuettuja(ja kääntäjä tietää sen), kääntäjä ei tee mitään häröpallokoodia, ja se muistiaccess saattaa olla esim. yhden kellojakson hitaampi JOS se OIKEASTI sattuu olemaan unaligned.
Häh?
Näitä ARM-läppäreitä on ollut jo tovi:
Lenovo Yoga C630 13,3"e; 2-in-1 (harmaa) – Windows-kannettavat
http://www.gigantti.fi
(myös joku Toshiba Gigantilla oli myynnissä)
Nyt on mennyt vaan Applen propaganda läpi ja "Apple on aina ekana" valheet on uponneet täysin.
https://www.amd.com/en/products/graphics/amd-radeon-rx-5700-xt
"DisplayPort 1.4 with Display Stream Compression is ready to power extreme refresh rates, frame rates, resolution, and color depth for next-generation displays, supporting up to 8K resolution at 60 Hz or 5K at 120 Hz."
Ei pitäisi olla mitään ongelmaa käyttää 5k-resoluutiota.
Ei jos näytöstä löytyisi tuki DSC:lle ja DisplayPort, kumpakaan ei tosin taida olla.
Yes, master.
Olen tietoinen tuosta kyllä että rekisterien määrä nostettiin, mutta olen ihmetellyt että miksi niitä ei nostettu kerralla sitten siihen kolmeenkymmeneen kahteen saakka ? Olisiko siitä ollut x86_64:n tapauksessa merkittävää haittaa ?
Lisäksi onko järkevää raahata enää esimerkiksi Virtual 8086 modea/VME:tä mukana uudemmissa prosessoreissa? Tuskinpa se hirveästi pii pinta-alaa / mikrokoodi tilaa vie, mutta onko sille tänä päivänä hirveästi käyttöä ? Semminkin kun tiedossa että sen implementaatiossa on ongelmia joillain prosessoreilla ? Edelleen, pitääkö ymmärtää niin että kaikki kama mitä joskus on joskus laitettu arkkitehtuuriin mukaan pitää säilyttää hamaan loppuun saakka ?
Edit: ja railakkaasti off-topiccia tän threadin aiheen ulkopuolella, moderaattori voinee halutessaan siirtää oikeaan paikkaan.
Onhan siinä displayport over thunderbolt? Viimeistään jollain adapterilla onnistuu.
Edit: TB3 AIC kahdella dp inputilla riittää. Tai sit suunnilleen mikä vaan läppäri joka tukee näyttöjen ketjutusta TB3 liitännän yli. Passiivisella dp-usb-c kaapelilla toimii kans kuvan siirto OK, mutta mitään näytön asetuksia ei voi tällöin säätää.
Olisi ollut merkittävää haittaa siinä, että
1) käskyt olisivat olleet selvästi pidempiä, huonompi käskyvälimuistin osumatarkkuus ja ohjelmakoodi olisi vienyt enemmän muistia
2) Käskydekooderi joka on muutenkin monimutkainen ja ainoita jäljellä olevia paikkoja missä se painolasti oikeasti pikkusen tuntuu, olisi ollut vielä monimutkaisempi.
Ja: miten olisit ne lisännyt?
Ei käskykannassa näkyvien rekisterien määrässä tällä vuosituhannella ole kyse siitä, kuinka suuri rekisterifile raudalla mahtuu/halutaan laittaa, vaan ainoastaan siitä kuinka ne rekisterit enkoodataan käskyihin
Ja käskyenkoodauksessa ei suoraan ollut tilaa yhdenkään rekisterin lisäämiseen. Käytännössä juuri missään arkkitehtuurissa ei ole.
Se, miten nuo rekisterit tuplattiin 8->16 oli, että yksitavuiset INC- ja DEC-käskyt poistettiin (koska ne voi kuitenkin laskea ADD- ja SUB-käskyillä kahdella tavulla) ja näistä vapautuneet opkoodit määriteltiin REX-prefiksiksi (jolla pystyi olemaan 4 bittiä hyötydataa, koska näillä INC- ja DEC-käskyillä oli yhteensä 16 eri enkoodausta sen mukaan mitä rekisteriä inkrementoidaa/dekrementoidaan).
Näitä neljää bittiä käytettiin sitten siihen, että (seuraava) käsky tulkitaan eri tavalla:
1. bitti määrittelee, että operoidaan 64-bittisellä datalla. Jos se on 0, käytetään default-leveyttä (useimmilla käskyllä 32)
2. bitti määritelee, että modrm.reg-kenttä (yleensä kohderekisterin indeksi) sisältää ylimääräisen ykkösen ylimpänä bittinä (eli voidaan osoittaa rekistereihin numero 8-15)
3. bitti määrittelee, että sib.index (skaalattavan indeksirekisterin kenttä) sisältää ylimääräisen ykkösen ylimpänä bittinä (eli voidaan osoittaa rekistereihin numero 8-15)
4. bitti määrittelee, että joko sib.BASE-kenttä(skaalattavaan indeksirekisteriin lisättävä base) tai MODRM.rm -kenttä (useimpien normaalien käskyjen toinen operandi) sisältää ylimääräisen ykkösen ylimpänä bittinä (eli voidaan osoittaa rekistereihin numero 8-15).
Jos olisi haluttu lisätä rekisterien määrä 32een (mikä ei olisi antanut käytännössä juuri mitään käytännön hyötyjä) olisi pitänyt jostain taikoa vielä 3 bittiä lisää siihen käskyenkoodaukseen.
Tilaa tähän ei käytännössä olisi ollut mitenkään muuten kuin vähintään KAKSITAVUISELLA prefixillä. Ja tämä jos mikä olisi tehnyt siitä käskyenkoodauksesta vielä monimutkaisemman ja koodista paljon enemmän tilaa vievää.
Ja itseasiassa kolmetavuinen VEX/XOP-prefix sitten tuotiin myöhemmin, mutta sitä käytetään vain SIMD-käskyille jotka muutenkin tekee paljon ja jossa käskyn overhead/sen tekemä laskentamäärä on pieni, ja suuri sen takia ne käskyt voi olla sen 15 tavua pitkiä. Oleellinen syy tämän tuomiseen on se, että haluttiin tukea FMA-käskyä jossa on kolme inputtia ja kohderekisteri voi olla eri kuin joku lähderekistereistä, eli rekisterikenttiä tarvitaan 4, ja haluttiin myös erotella eri leveyksiset SIMD-käskyt.
X86-64 Instruction Encoding – OSDev Wiki
wiki.osdev.org
Ainoa oikeasti "ahdas" asia mitä Mooren laki ei "korjaa" on käskyjen enkoodaus. Enempää käskyjä tai niiden parametreja tai suurempia parametreja ei vaan voi millään voi enkoodata pienempään tilaan. RISCit ottivat asenteen että "Kaikki on 32 bittiä" mikä myöhemin todettiin aivan liian harvaksi käskyenkoodaukseksi, joten ARMiin tuli Thumb, MIPSiin MIPS16 ja RISC-V:hen C-extensio.
Ja ainakin Thumbissa ja RISC-V:n C-extensiossa tuettujen rekisterien määrää on monilla käskyillä pudotettu kahdeksaan, vielä vähäisempään kuin x86-64ssa.
Tosin ARMv8sta jätetiin sitten kuitenkin Thumb pois.
VMEstä en osaa sanoa mitään.
Eikä aivan kaikkea tarvi tukea hamaan loppuun saakka, 3dnow! pudotettiin kokonaan pois jo bulldozerissa ja bobcatissä.
Ja 64-bittisestä moodista pudotettiin pois ainakin:
1) Nuo yhden tavun inc/dec-opcodet pudotettiin pois 64-bittisessä moodissa.
2) Segmenttirekisterit CS-ES pudotettiin täysin pois user modesta. FS ja GS jätettiin silti jotta niitä voi käyttää esim. pointtereina thread-local-storageen (koska tällainen pointteri on kätevä olla olemassa)
Hmmm, totta. Seison korjattuna. Jäin miettimään vielä tuota sivukoko juttua että miksi sitä ei ole tehty – siitä kun näyttäisi olevan selkeitä etuja, mutta pitää kertailla lisää x86sen mmu:ta lisää.
Toki ARM-prossuja on myynnissä, tuo tarkoitti että Apple harkitsee omien prosessoriensa myyntiä kolmansille osapuolille. Applen ARM-prossut on paljon tehokkaampia kuin muut mutta Apple on toistaiseksi käyttänyt niitä vain omissa tuotteissaan.
Nythän ARM-puolella kuohuu aika suuresti, ARMin omistava Softbank on nähtävästi pistämässä koko osaston myyntiin ja spekulaatiot on villinä kuka on ostaja. Huawei – Apple -Intel – joku muu – jokatapauksessa ARM:n joutuminen jonkun prosessorivalmistajan haltuun olisi todennäköisesti varsin merkittävä huononnus ARM-markkinoille, mahdollisuushan on että koko vapaasti lisensoitava järjestelmä ajetaan alas.
Tosin nyt kun Apple on hypännyt ARM kelkkaan, niin tuollaisessa tilanteessa voisi olla pakko käyttää sitä valtavaa likviditeettivarantoa ja lyödä sellainen hinta pöytään jolla varmistaa omien suunnitelmien toteutuminen pitkälle tulevaisuuteen.
MacBook ARM prices revealed – and Apple fans are in for a shock
Ihan uskottava heitto. Ainakin alkuvaiheessa markkinaosuuksien kasvattamiseksi olisi järkevää laskea hintoja vähintään säästyneen intelin katteen verran.
Toisena vaihtoehtona on tietenkin yhä sopivan Hackintoshin kasaaminen. Se vain tulee sitten Applen softien suhteen vanhenevan käsiin noin kolmessa vuodessa. Linuxilla voisi sen jälkeen tietenkin jatkaa siitä kohdasta sitten eteenpäin. Kyllähän nämä linuxitkin kolmessa vuodessa taas kehittyvät eteenpäin.
Olen aina ihmetellyt sitä, ettei Apple jotenkin voimakkaammin yritä saada itselleen suurempaa markkinaosuutta. Josko se nyt vaikka tuohon suuntaan jatkossa keikahtaisi, ja laadun ja suorituskyvyn suhde hintaan olisi jatkossa edes tyydyttävällä tasolla.
T -.-
Luulen että katteista on ollut kiinni, eli niistä ei ole haluttu tinkiä. Jos nyt saadaan sama tai parempi suorituskyky halvemmalla, mutta katteista tinkimättä, niin sitten voi tietysti vähän kokeillakin lisätä markkinaosuutta.
Omat SOC:t kehittämällä sen voi tehdä varmaan tarkemmin kuin Intelin CPU:illa, jolloin voi leikkailla juuri niitä asioita joita harva kuluttaja kaipaa, mutta joita ammattilaiset haluavat. Se mahdollistaa hintaluokissa alaspäin tulemisen esim. koululaisille suunnatuilla koneilla, jotka eivät kuitenkaan kannibalisoi ammattikoneiden korkeampia katteita.
Jos pitäisi veikata, niin Apple suunnittelee ainakin 4 eri SOC:ia. Yhden puhelimille, yhden ipadiin / entry-level läppäreihin, yhden high-end läppäreihin / perus-imaceihin ja neljännen sitten johonkin iMac Pro / Mac Pro tyyppisiin käyttökohteisiin.
Eri versiot tietty tulevat ulos eri aikoihin riippuen käytettyjen valmistusprosessien yieldeistä ja Applen omista tuotesykleistä (iphonet pitää aina saada myyntiin syksyllä ennen joulusesonkia, ammattilaiskoneissa ei ole niin väliä jne.)
Applen ARM-prosessoreissa tulee olemaan (tai ilmeisesti on jo jossain malleissa?) erillinen tiukan muistijärjestyksen moodi, jossa pätee samat muistioperaatioiden konsistenttiussäänöt kuin x86lla. Tämä on ilmeisesti ydinkohtainen tilabitti(tai mikäli joskus tulee SMT niin sitten sillä virtuaaliydinkohtainen), eli se kytketään päälle vain niitä x86sta binäärikäännettyjä säikeitä ajaville ytimille.
Ilmeisesti muutama tovi jo suunniteltu vaihtoa omiin prosessoreihin, jos kerran nykyisissä ipadeissa on jo kyseinen ominaisuus mukana. Devkiteissä on siis sama prossu kuin pädeissä.
Noissa FS/GS-rekistereissäkin on mennyt tosi pitkään nyt että esim. Linuxiin saatu Ivy Bridgessä esitelty ominaisuus muuttaa niitä tehokkaasti userspacessa, jos TLS:ää haluaa asettaa uudestaan tms. Arvion mukaan vasta 5.9-kerneliin taitaisi olla aikaisintaan tulossa: A possible end to the FSGSBASE saga [LWN.net]
Report: Super-Lightweight 12-inch MacBook Powered By Apple Silicon to Launch This Year
http://www.macrumors.com
Edit:
Huhu Kiinasta: Applelta tulossa 12 tuuman MacBook omalla ARM-pohjaisella suorittimella ja jopa 15-20 tunnin akunkestolla
mobiili.fi
Edit: Lisätty huhun kuva
En hirveästi sen varaan laskisi, ymmärtääkseni nykyisilläkin mäkeillä on melkoisia ongelmia ajella Linuxia rinnalla
Onko ongelma ainoastaan dualbootin kanssa vai myös ihan puhtaasti päälle asentaessa?
Olinpas epäselvä, tarkoitin siis että jos Linuxia koittaa suoraan uudehkoon mäkkirautaan, oli sitten dualboot tai pelkästään niin saa varautua ongelmiin, kun ytimessä ei taida kaikelle tukea olla + T2-tietoturvapiiri. Tietävämmät korjatkoon.
Todennäköisesti tulee Linux-distribuutioita, jotka toimivat noilla virtuaalikoneessa, mutta en usko että dual-boottina tulee toimimaan, Apple ei halunne päästää mitään "ei-luotettua" koodia ajautumaan sellaisilla käyttooikeuksilla millä suoraan boottaava linux pääsisi ajautumaan joten boottiloader todennäköisesti kieltäytyy boottaamasta muita kuin Applen omia käyttiksiä.
No höh, tuota vähän pelkäsinkin. Toivotaan sitten joltain Samsungilta tai vastaavalta myös halukkuutta alkaa kunnolla laajentua ARM-läppäreihin, jottei tuotteista tarvitse maksaa erityislisää.
Voipi tuo Linux ollakkin tuettuna, sitä eipä vielä voi sanoa. Kuitenkin aiemmin ollut Intelin välissä ja nyt voivat hallita koko palapelia, niin voi olla helpompi lisätä tuki.