Apple siirtyy Arm-arkkitehtuuriin Mac-tietokoneissa

[Kaotik]

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.

 

[jsa]

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.

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.

 

[pomk]

Ei jos näytöstä löytyisi tuki DSC:lle ja DisplayPort, kumpakaan ei tosin taida olla.

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ää.

 

[hkultala]

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 ?

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 paljon myöhemmin (, ja jopa nelitavuinen EVEX vielä myöhemmin, AVX-512ssa), mutta näitä 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 näiden tuomiseen on mm. 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. Ja AVX-512ssa taitaa monet käskyt vaatia vielä predikaattirekisterinkin indeksin (eli jopa 5 kenttää kaikkiaan)

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.

Lisäksi onko järkevää raahata enää esimerkiksi 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 ?

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)

 

[jsa]

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ää.

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ää.

 

[Sami Riitaoja]

Häh?

Näitä ARM-läppäreitä on ollut jo tovi:

Lenovo Yoga C630 13,3" 2-in-1 (harmaa) - Gigantti verkkokauppa

13,3-tuumainen Lenovo Yoga C630 2-in-1 on täysin omanlaisensa kannettava laite. Siinä on uskomaton 25 tunnin akunkesto ja 4G LTE -

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.

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.

 

[weetabix]

Huawei tai joku muu kiinalainen voisi olla aika varteenotettava kun Kiina siirtyy koko ajan pois länsimaisten piirien käytöstä (hallinnossa on jo useita eri prosessorivariantteja, pöytäkoneisiin pääsääntöisesti ja x86 tekniikalla mutta tehottomuus vaivaa) niin lisenssin omistamalla voisivat saada vauhtia omiin piireihin siirtymiseen.

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.

 

[vemkki]

Nyt tuli huhu ekojen ARM-koneiden hinnoista. Hinnat laskisivat selvästi. Saa nähdä, miten käy.
MacBook ARM prices revealed - and Apple fans are in for a shock

 

[pomk]

Nyt tuli huhu ekojen ARM-koneiden hinnoista. Hinnat laskisivat selvästi. Saa nähdä, miten käy.
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.

 

[moukula]

Kun tehdään tämmöinen iso muutos arkkitehtuuriin ja muutos vaatii softien kääntelyä uusiksi, niin pakkohan se on saada heti rutkasti uuden mallista laitetta liikenteeseen vaikka sitten tappiollisesti. Kun sitten vanhan raudan määrä käyttäjillä on riittävän pienessä osassa niin se voidaan hylätä kylmästi ilman liian suurta ulinaa.

 

[tle88]

Näin minäkin olen tuon asian järkeillyt. Uskon alkupään mallien olevan suhteellisen edullisia laatuunsa nähden. Ellei Apple jollain juonikkaalla tavalla oikein pilaamalla nyt pilaa noita omia tuotteitaan, niin jollain Mac Minin uudella arm inkarnaatiolla voisi kerrasta hypätä mukaan tälle uudelle vuosikymmenelle. Se T2 siru vähän huolettaa...

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 -.-

 

[vemkki]

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.

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.

 

[zepi]

Apple tulee harrastamaan jatkossakin tuotesegmentointia jolla se ohjaa "ammattilaiset" ja "enthusiastit" maksamaan extraa niistä featureista mitä he (kuvittelevat) tarvitsevansa.

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.)

 

[hkultala]

Nyt on tullut selvyyttä miten Apple on ratkaisemassa ARM-ja x86-arkkitehtuurien muistikonsistenttiussääntöjen erot binäärikääntäessään x86-koodia ARM-koodiksi:

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.

 

[pomk]

Nyt on tullut selvyyttä miten Apple on ratkaisemassa ARM-ja x86-arkkitehtuurien muistikonsistenttiussääntöjen erot binäärikääntäessään x86-koodia ARM-koodiksi:

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ä.

 

[love_doctor]

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)

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]

 

[user9999]

Jotain huhua, että 12" MacBook tulisi Apple Siliconilla..

Report: Super-Lightweight 12-inch MacBook Powered By Apple Silicon to Launch This Year

Apple has designed a 12-inch MacBook powered by Apple Silicon that weighs less than one kilogram and the company intends to launch it by the end of...

www.macrumors.com

Edit:

Huhu Kiinasta: Applelta tulossa 12 tuuman MacBook omalla ARM-pohjaisella suorittimella ja jopa 15-20 tunnin akunkestolla

Apple ilmoitti kesäkuussa WWDC-kehittäjätapahtumansa yhteydessä myös sen Mac-tietokoneiden siirtymisestä jatkossa Applen omiin suorittimiin. Apple

mobiili.fi

Edit: Lisätty huhun kuva

 

[xcm]

Mikäli Applen suunnitelmana on tosiaan tarjota tuotteitaan alihintaan markkinaosuuden kasvattamiseksi, pitänee tuohon tilaisuuteen tarttua kuluttajana. Voiko Linuxin ARM-versioiden olettaa toimivan noilla?

 

[tatulpin]

Mikäli Applen suunnitelmana on tosiaan tarjota tuotteitaan alihintaan markkinaosuuden kasvattamiseksi, pitänee tuohon tilaisuuteen tarttua kuluttajana. Voiko Linuxin ARM-versioiden olettaa toimivan noilla?

En hirveästi sen varaan laskisi, ymmärtääkseni nykyisilläkin mäkeillä on melkoisia ongelmia ajella Linuxia rinnalla

 

[xcm]

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?

 

[tatulpin]

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.

 

[hkultala]

Mikäli Applen suunnitelmana on tosiaan tarjota tuotteitaan alihintaan markkinaosuuden kasvattamiseksi, pitänee tuohon tilaisuuteen tarttua kuluttajana. Voiko Linuxin ARM-versioiden olettaa toimivan noilla?

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ä.

 

[xcm]

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ää.

 

[Kurk7]

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.