Intel suunnittelee uutta x86S-arkkitehtuuria

[Kaotik]

Intel on kertonut suunnitelleensa uutta x86S-arkkitehtuuria, joka jättäisi taakseen 32- ja 16-bittiset tilat ja rutkasti muuta menneiden aikojen painolastia nykyisestä x86:sta laajennoksineen.
Yhtiön mukaan nykyiset virtualisointimahdollisuudet riittävät jo vanhojen käyttöjärjestelmien ja ohjelmien ajoon sillä varmuudella, ettei natiivia tukea tarvittaisi.
Palaamme asiaan tarkemmin, mikäli se kehittyy ajatusta pidemmälle.

Lähde: Envisioning a Simplified Intel Architecture for the Future,

 

[moukula]

Jännästi muotoiltu lause tuolla:
" Since its introduction over 20 years ago, the Intel® 64 architecture became the dominant operating mode. "

Eikös se nyt kuitenkin ole AMD:n kehittämä x86-64 tai AMD64, josta Intel otti käyttöön oman yhteensopivan versionsa. Intel kehitti samoihin aikoihin omaa IA64-käskykantaansa Itanium-prosessoreille, joka jäi flopiksi. Toki tietäjät tietää ja ykät muistaa, mutta vähän hanurista tuommoinen että muotoillaan historiaa uusiksi ikään kuin tämä olisi Intelin omaa keksintöä ja tuotantoa.

 

[Moilaps]

Onkohan tuolla painolastilla loppujen hirveästi väliä. Vaikea kuvitella että niiden pitäminen ainakaan hirveästi pii tilaa tai suorituskykyä vie. Toki itse suunnitelu ja testaus maksaa. Aina sanotaan että arm on tehokkaampi ja virtapihimpi kuin x86 koska se on paljon tuoreempi, mutta toisaalta vanhemman isan on ollut pakkokin olla tehokas koska cput oli niin hitaita silloin vuoisia sitten.

 

[Kaotik]

Jännästi muotoiltu lause tuolla:
" Since its introduction over 20 years ago, the Intel® 64 architecture became the dominant operating mode. "

Eikös se nyt kuitenkin ole AMD:n kehittämä x86-64 tai AMD64, josta Intel otti käyttöön oman yhteensopivan versionsa. Intel kehitti samoihin aikoihin omaa IA64-käskykantaansa Itanium-prosessoreille, joka jäi flopiksi. Toki tietäjät tietää ja ykät muistaa, mutta vähän hanurista tuommoinen että muotoillaan historiaa uusiksi ikään kuin tämä olisi Intelin omaa keksintöä ja tuotantoa.

Kyllä ja ei. Nykyään meillä on AMD64 joka oli aiemmin x86-64 ja Intel 64 joka oli aiemmin IA-32e (IA-32 = x86 siihen aikaan) ja sen jälkeen EM64T ennen nykyistä nimeä. Kaikki ovat enemmän tai vähemmän sama asia mtuta AMD64:n ja Intel 64:n välillä on pieniä eroja, spoilerissa Googlella löydettyä (EM64T = Intel 64)

Spoileri

• EM64T’s BSF and BSR instructions act differently when the source is 0 and the operand size is 32 bits. The processor sets the zero flag and leaves the upper 32 bits of the destination undefined.
• AMD64 supports 3DNow! instructions. This includes prefetch with the opcode 0x0F 0x0D and PREFETCHW, which are useful for hiding memory latency.
• EM64T lacks the ability to save and restore a reduced (and thus faster) version of the floating-point state (involving the FXSAVE and FXRSTOR instructions).
• EM64T lacks some model-specific registers that are considered architectural to AMD64. These include SYSCFG, TOP_MEM, and TOP_MEM2.
• EM64T supports microcode update as in 32-bit mode, whereas AMD64 processors use a different microcode update format and control MSRs.
• EM64T’s CPUID instruction is very vendor-specific, as is normal for x86-style processors.
• EM64T supports the MONITOR and MWAIT instructions, used by operating systems to better deal with Hyper-threading.
• AMD64 systems allow the use of the AGP aperture as an IO-MMU. Operating systems can take advantage of this to let normal PCI devices DMA to memory above 4 GiB. EM64T systems require the use of bounce buffers, which are slower.
• SYSCALL and SYSRET are also only supported in IA-32e mode (not in compatibility mode) on EM64T. SYSENTER and SYSEXIT are supported in both modes.
• Near branches with the 0×66 (operand size) prefix behave differently. One type of CPU clears only the top 32 bits, while the other type clears the top 48 bits.

 

[Admiral General Aladeen]

Ei riitä oma ymmärrys että miten nuo 16, 32 ja 64 bittiset prosessoinnnit toimii tällä tasolla. Käskykannasta on siis kyse, mikä on aika paljon rautaa, eli ehkä siinä suunnittelu yksinkertaistuu. Mutta mitä se prosessorilla oleva mikrokoodi (softa?) ohjaa?

 

[Kaotik]

Ei riitä oma ymmärrys että miten nuo 16, 32 ja 64 bittiset prosessoinnnit toimii tällä tasolla. Käskykannasta on siis kyse, mikä on aika paljon rautaa, eli ehkä siinä suunnittelu yksinkertaistuu. Mutta mitä se prosessorilla oleva mikrokoodi (softa?) ohjaa?

Mikrokoodi yleisellä tasolla on kerros raudan ja ohjelmoijalle näkyvän käskykannan välissä. Se siis varsinaisesti käskyttää sitä itse rautaa.

 

[Jarnis]

Varsinkin testauksen ja validoinnin osalta ymmärtää kyllä halun päästä noista legacy-ihmeistä arkkitehtuurissa eroon. En näkisi tätä hirveänä ongelmana jos ylemmällä tasolla edelleen emuloitaisiin tarvittavat asiat jotta vanhojen ohjelmien ajaminen olisi edelleen tästä huolimatta mahdollista, jolloin käytännössä ongelmia tulisi vain museotason käyttöjärjestelmien kanssa - ja niitä voisi edelleen ajaa virtuaalikoneissa niin paljon kuin sielu sietää.

Ja ne jotka jostain syystä tarvitsevat tuota tukea rautatasolla niin äkkiä vaan legacy-kamaa varastoon talteen. Väittäisin että maailmassa on niin paljon museotason tietokonerautaa helposti saatavilla että ne muutamat erikoistapaukset jossa halutaan ajaa jotain tiettyä museotavaraa eikä VM kelpaa voidaan hanskata olemassaolevilla "varastoilla" ja jos markkina sanoo että kysyntää vielä tällaiselle tuelle on, eiköhän valmistajat jatka jonkun legacy-mallin valmistusta niin kauan kuin ostajia on. Vertailukohtana, jos haluat kotimikrojen aamunkoiton nurkilta MOS 6502-prosessorin niin niitä saa edelleen uutena...

 

[amblik]

Kyllä ja ei. Nykyään meillä on AMD64 joka oli aiemmin x86-64 ja Intel 64 joka oli aiemmin IA-32e (IA-32 = x86 siihen aikaan) ja sen jälkeen EM64T ennen nykyistä nimeä. Kaikki ovat enemmän tai vähemmän sama asia mtuta AMD64:n ja Intel 64:n välillä on pieniä eroja, spoilerissa Googlella löydettyä (EM64T = Intel 64)

Spoileri

• EM64T’s BSF and BSR instructions act differently when the source is 0 and the operand size is 32 bits. The processor sets the zero flag and leaves the upper 32 bits of the destination undefined.
• AMD64 supports 3DNow! instructions. This includes prefetch with the opcode 0x0F 0x0D and PREFETCHW, which are useful for hiding memory latency.
• EM64T lacks the ability to save and restore a reduced (and thus faster) version of the floating-point state (involving the FXSAVE and FXRSTOR instructions).
• EM64T lacks some model-specific registers that are considered architectural to AMD64. These include SYSCFG, TOP_MEM, and TOP_MEM2.
• EM64T supports microcode update as in 32-bit mode, whereas AMD64 processors use a different microcode update format and control MSRs.
• EM64T’s CPUID instruction is very vendor-specific, as is normal for x86-style processors.
• EM64T supports the MONITOR and MWAIT instructions, used by operating systems to better deal with Hyper-threading.
• AMD64 systems allow the use of the AGP aperture as an IO-MMU. Operating systems can take advantage of this to let normal PCI devices DMA to memory above 4 GiB. EM64T systems require the use of bounce buffers, which are slower.
• SYSCALL and SYSRET are also only supported in IA-32e mode (not in compatibility mode) on EM64T. SYSENTER and SYSEXIT are supported in both modes.
• Near branches with the 0×66 (operand size) prefix behave differently. One type of CPU clears only the top 32 bits, while the other type clears the top 48 bits.

Tottakai pieniä eroja varmasti voi olla, onhan näitä muitakin laajennuksia jne. jotka voi perusluonteeltaan yhteensopivissa prosessoreissa olla saatavilla vain joissain malleissa... mutta pohjimmiltaan kyse taitaa kuitenkin olla tosiaan siitä että Intelin täytyi toteuttaa AMD:n suunnittelema käskykanta ja keksivät sitten näitä muita nimiä ettei olisi tarvinnut viitata AMD:n nimeen.

 

[hsalonen]

Onkohan tuolla painolastilla loppujen hirveästi väliä. Vaikea kuvitella että niiden pitäminen ainakaan hirveästi pii tilaa tai suorituskykyä vie. Toki itse suunnitelu ja testaus maksaa. Aina sanotaan että arm on tehokkaampi ja virtapihimpi kuin x86 koska se on paljon tuoreempi, mutta toisaalta vanhemman isan on ollut pakkokin olla tehokas koska cput oli niin hitaita silloin vuoisia sitten.

Tämä on nyt eri asia, kuin vaikka MMX. Siellä voi jonkun osan piilastusta sille allokoida ja/tai toteuttaa ne mikrokoodilla. ARM on kai RISC, ja sen takia sitä pidetään tehokkaampana, mutta ei se nyt niin paljon tehokkaampaa ole. Ongelmaksi muodostuu ainakin OoOE, jossa käskyjä suoritetaan niin monimutkaisten algoritmien kautta , että sinne syntyy bugeja, joka kaataa koko p**kan ja ominaisuuksia joudutaan kytkemään pois päältä tai mitigoimaan muulla suorituskyvyn romauttavalla tavalla: katso vaikka Spectre ja Meltdown.
Tuo 16- ja 32- bittisten sovellusten tuki tarkoittaa, että meillä on käskyjä, jotka operoivat nyt 64-bittisten rekistereiden alimpia bittejä. Sitten niiden yläosissa voi olla mitä vaan ja tämmöinen koodi on testaajan painajainen. Lisäksi kun asiat ei toimi lineaarisesti järjestyksessä ja myös skeduleri voi pallotella koodia ytimien välillä. Halutaan vaan päästä siitä skenaariosta, jossa tulee tilanne, että ajamalla tietyn pätkän 16-bittistä koodia, saadaan taas tietoturvamurto tehtyä. Tai ajatusleikkinä prosessori käyttäytymään väärin, jolloin sovellukset ei toimi oikein, jota tuskin tapahtuu, kun kääntäjät tuskin sellaista koodia tuottaisivat.

 

[ZarekX]

Eikö olisi aika siirtyä 128 bitiseen OS jo.

 

[Admiral General Aladeen]

Eikö olisi aika siirtyä 128 bitiseen OS jo.

64bit riitää yli 10 miljoonan TB muistiosoitteisiin, joten ehkä ei ihan heti tarvetta

 

[mRkukov]

Eikös ryzenien julkaisussa 16bit tuki ollut alkujaan rikki ja meni melkein vuosi että kukaan sitä huomasi. Kertoo hyvin siitä että nuo on 99.999999% pelkkää painolastia.

 

[LaDeX]

16 bittisyydestä luopumisen ymmärrän kun ei niitä 16bit softia ole 64bit Windowsilla tähänkään asti pystynyt ajamaan mutta 32bit softaa ja pelejä on vielä reippaasti käytössä.

 

[teemz]

Itse pidän peukkuja tälle. Kilpailu tekee aina hyvää, ja tuolla ässällä Intelillä voisi olla paremmat mahdollisuudet kilpailla Armin nousua vastaan. Serveri- ja mobiilipuolella tuollaisella yksinkertaistuksella voisi hyvinkin saada parannusta 99+ prosentille käyttäjistä. Se yksi prosentti voi tarvita jotain legacy-kamaa, ja siihen Intelillä on varmasti omat vaihtoehtonsa tulevaisuudessakin.

 

[BNo1]

Itse pidän peukkuja tälle. Kilpailu tekee aina hyvää, ja tuolla ässällä Intelillä voisi olla paremmat mahdollisuudet kilpailla Armin nousua vastaan. Serveri- ja mobiilipuolella tuollaisella yksinkertaistuksella voisi hyvinkin saada parannusta 99+ prosentille käyttäjistä. Se yksi prosentti voi tarvita jotain legacy-kamaa, ja siihen Intelillä on varmasti omat vaihtoehtonsa tulevaisuudessakin.

Todellisuushan on että legacya käytetään koska ei jakseta/viitsitä/haluta päivittää systeemejä.

 

[zepi]

Todellisuushan on että legacya käytetään koska ei jakseta/viitsitä/haluta päivittää systeemejä.

Usein se päivitys on myös aikalailla mahdotonta sen loppukäyttäjän puolesta.

Sulla on joku teollisuusautomaatiopaske jonka koodia ei ole olemassa ja sen tuottanutta firmaakaan ei ole olemassa, mutta se nyt vaan pyörittää ihan toimivasti jotain teollisuussirkkelin ohjausta.

 

[kurkimies]

Usein se päivitys on myös aikalailla mahdotonta sen loppukäyttäjän puolesta.

Sulla on joku teollisuusautomaatiopaske jonka koodia ei ole olemassa ja sen tuottanutta firmaakaan ei ole olemassa, mutta se nyt vaan pyörittää ihan toimivasti jotain teollisuussirkkelin ohjausta.

Tuosta tulikin mieleen, että esim. Forsassa on osa liikennevalojen ohjauskorteista niin vanhoja, ettei niihin löydy kertakaikkiaan varaosia. Nehän metsästi ja eikä edes löytäneet pidemmältä vaikka kyselivät muilta paikkakunnilta. Todennäköisesti vanhat varastot on tyhjennetty aikapäivää sitten ja niiden korttien tilaaminen olisi maksanut paljon (liikuttiin väh. tuhansissa euroissa jos ei sitten kymmenissä tuhansissa eli joutuvat teettämään ohjainkortit pelkästään tuota varten) ennen isompaa remonttia.

Jossain vaiheessa menivät uusiksi joka tapuksessa, kun tekevät tieremonttia yms...

Ikäloput liikennevalot ehkä historiaan Forssassa

 

[Jurppis]

Odotinkin, että tällainen uutinen nähtäisiin ennen pitkää. 32-bittiset pelit taitaa jo nykyisellään olla aika hillittyjä laitevaatimuksiltaan ja lukuisat pikkuohjelmat joita taustalla pyörii ovat nekin lähes kaikki 64-bittisiä. Suurin huolen aihe on, että siihen mennessä kun kuluttujaprosessoreista alkaa tippua 32-bittinen tuki, tarvitsisi perus-Windowseissa olla luotettava ja helppokäyttöinen emulointi 32-bittisille ohjelmille.

 

[Desgorr]

Odotinkin, että tällainen uutinen nähtäisiin ennen pitkää. 32-bittiset pelit taitaa jo nykyisellään olla aika hillittyjä laitevaatimuksiltaan ja lukuisat pikkuohjelmat joita taustalla pyörii ovat nekin lähes kaikki 64-bittisiä. Suurin huolen aihe on, että siihen mennessä kun kuluttujaprosessoreista alkaa tippua 32-bittinen tuki, tarvitsisi perus-Windowseissa olla luotettava ja helppokäyttöinen emulointi 32-bittisille ohjelmille.

Periaatteessa Windowsissa on jo moinen. WoW64

WoW64 - Wikipedia

en.wikipedia.org

 

[kurkimies]

Odotinkin, että tällainen uutinen nähtäisiin ennen pitkää. 32-bittiset pelit taitaa jo nykyisellään olla aika hillittyjä laitevaatimuksiltaan ja lukuisat pikkuohjelmat joita taustalla pyörii ovat nekin lähes kaikki 64-bittisiä. Suurin huolen aihe on, että siihen mennessä kun kuluttujaprosessoreista alkaa tippua 32-bittinen tuki, tarvitsisi perus-Windowseissa olla luotettava ja helppokäyttöinen emulointi 32-bittisille ohjelmille.

Ja onhan tuo puhelinmaailmassa nähty eli Applella prossut ovat olleet pitkään 64-bittisiä ja Google tulee vaatimaan 2023 lähtien pelkästään 64-bittisiä prossuja eli tulevaisuudessa on helppo tiputtaa 32-bittinen tuki kokonaan ohjelmista/peleistä.

ARM:in mobiiliprosessorit siirtyvät pelkästään 64-bittiseen aikaan vuonna 2023 - io-tech.fi

 

[jive]

Sillä ei ole juurikaan merkitystä sovellusten kannalta mikä raudan käskykanta oikeasti on. Ongelmat alkavat itse käyttöjärjestelmässä ja ajureissa ja muissa järjestelmätason palikoissa kuten protokollissa. Tehokkaan emuloinnin toteutus ei ole ihan triviaalia mutta ei se tekemätön paikka ole.
Vanha x86 käskykanta tehtiin ihmisen assembly -ohjelmoitavaksi eikä se ole sen takia ihan tehokkain tapa tehdä asioita mutta isompi haaste tulee CPU rekistereistä ja niiden käytöstä joita on rajallisesti käytössä 16 ja 32 bit tiloissa.

 

[LaDeX]

Sillä ei ole juurikaan merkitystä sovellusten kannalta mikä raudan käskykanta oikeasti on. Ongelmat alkavat itse käyttöjärjestelmässä ja ajureissa ja muissa järjestelmätason palikoissa kuten protokollissa. Tehokkaan emuloinnin toteutus ei ole ihan triviaalia mutta ei se tekemätön paikka ole.
Vanha x86 käskykanta tehtiin ihmisen assembly -ohjelmoitavaksi eikä se ole sen takia ihan tehokkain tapa tehdä asioita mutta isompi haaste tulee CPU rekistereistä ja niiden käytöstä joita on rajallisesti käytössä 16 ja 32 bit tiloissa.

Emuloisivat sitten nyt edes ne 16 bittiset jo....

 

[Timo 2]

Emuloisivat sitten nyt edes ne 16 bittiset jo....

Jep. Mulla on joku wanha peli, joka ei toimi 64 bittisessä windowsissa, mutta 32 bittisessä toimii...

Taitaa taustalla olla 16 bittisyyden puute.

 

[jive]

Jep. Mulla on joku wanha peli, joka ei toimi 64 bittisessä windowsissa, mutta 32 bittisessä toimii...

Taitaa taustalla olla 16 bittisyyden puute.

DOSBox, an x86 emulator with DOS

www.dosbox.com

 

[Timo 2]

DOSBox, an x86 emulator with DOS

www.dosbox.com

Tiedän tuon, mutta jaksa alkaa joka kerta kirjoittamaan mout c d: ja pelin kansion alikansion alikansio peli.exe

 

[ghuru]

Tiedän tuon, mutta jaksa alkaa joka kerta kirjoittamaan mout c d: ja pelin kansion alikansion alikansio peli.exe

Dosboxiin pystyt tekee BAT scriptin että se suosikki peli aukee heti.

 

[Timo 2]

Dosboxiin pystyt tekee BAT scriptin että se suosikki peli aukee heti.

Niin uskomattomalta, kun se tietoteknikkafoorumilla kuulostaakin, niin pitäisi ekana opetella koodaamaan. Ja ylipäätään haluaisi lähtökohtaisesti avata pelit pikakuvakkeesta, joka on kansiossa muiden pelien pikakuvakkeiden kanssa.

Dossia/komentokehoitetta pystyn käyttää, jos on tarve, mutta tällöin mulla on ohje apuna sille spesifille jutulle, joka tarvii tehdä.

 

[moukula]

Tiedän tuon, mutta jaksa alkaa joka kerta kirjoittamaan mout c d: ja pelin kansion alikansion alikansio peli.exe

Tämä dosboxin conffin loppuun niin jos sulla on C:\DOS -kansioon asennettu dos-pelit niin dosboxin käynnistyttyä pääset suoraan listaamaan pelikansiot.

[autoexec]
# Lines in this section will be run at startup.
# You can put your MOUNT lines here.
mount c c:\DOS\
C:\
cls

 

[Kaotik]

Niin uskomattomalta, kun se tietoteknikkafoorumilla kuulostaakin, niin pitäisi ekana opetella koodaamaan. Ja ylipäätään haluaisi lähtökohtaisesti avata pelit pikakuvakkeesta, joka on kansiossa muiden pelien pikakuvakkeiden kanssa.

Ei tarvitse opetella koodamaan. Pitää osata pari DOS-komentoa, jos se on liikaa ei tartte pelata sen aikaisia pelejä.

 

[jive]

Niin uskomattomalta, kun se tietoteknikkafoorumilla kuulostaakin, niin pitäisi ekana opetella koodaamaan. Ja ylipäätään haluaisi lähtökohtaisesti avata pelit pikakuvakkeesta, joka on kansiossa muiden pelien pikakuvakkeiden kanssa.

Alkuperäinen pointti nyt kuitenkin oli ettei se nykyrauta näyttele 30 vuotta vanhan teknologian pyörittämisessä isoa roolia. Homman saa hoidettua ohjelmistollisesti. Jos Windows ei suoraan pakkauksesta nyt satu jotain tukemaan niin siihen on ihan muut kuin tekniset syyt.

 

[hkultala]

Intel on kertonut suunnitelleensa uutta x86S-arkkitehtuuria, joka jättäisi taakseen 32- ja 16-bittiset tilat ja rutkasti muuta menneiden aikojen painolastia nykyisestä x86:sta laajennoksineen.
Lähde: Envisioning a Simplified Intel Architecture for the Future,

Mikäli tulkitsen tuota oikein, tuo jättäisi kokonaan pois tuen 16-bittiseltä tilalta sekä 32-bittisten käyttöjärjestelmien tuen.

32-bittiset ohjelmat olisivat kuitenkin edelleen tuettuja 64-bittisen käyttöjärjestelmän alla.

 

[hkultala]

64bit riitää yli 10 miljoonan TB muistiosoitteisiin, joten ehkä ei ihan heti tarvetta

... ja tosiaan x86-64-arkkitehtuurin mikään nykyversio ei tue edes 64-bittisiä osoitteita, vaan alun perin virtuaaliosoitteet x64-64ssa oli 48-bittisiä (256 teratavua) ja vasta ihan viime vuosina ne on pidennetty joissain uusissa prossuissa 57 bittiin (128 petatavua) kun tuli uusi 5-tasoisten sivutaulujen moodi.

Ja fyysiset osoitteet on vielä lyhempiä, mutta niiden pituus on mikroarkkitehtuurin eikä käskykanta-arkkitehtuurin ominaisuus, fyysisten osoitteiden pituus voi vaihdella prossumallien välillä vapaasti.

 

[Timo 2]

Tämä dosboxin conffin loppuun niin jos sulla on C:\DOS -kansioon asennettu dos-pelit niin dosboxin käynnistyttyä pääset suoraan listaamaan pelikansiot.

[autoexec]
# Lines in this section will be run at startup.
# You can put your MOUNT lines here.
mount c c:\DOS\
C:\
cls

Kiitoksia. Tämä auttaa hieman vanhojen pelien kohdalla, vaikkakaan ei ole sama asia, kuin käynnistää pikakuvakkeesta.

DOSBox, an x86 emulator with DOS

www.dosbox.com

Itseasiassa juuri kun testasin tuota peliä, niin eipä muuten toimi dosboxdissa, vaan vaatii windowssin, eikä muuten toimi suoraan 64 bittisessä windows 10:ssä ja muistaakseni toimi 32 bittisessä.

 

[hkultala]

Tämä on nyt eri asia, kuin vaikka MMX. Siellä voi jonkun osan piilastusta sille allokoida ja/tai toteuttaa ne mikrokoodilla. ARM on kai RISC, ja sen takia sitä pidetään tehokkaampana, mutta ei se nyt niin paljon tehokkaampaa ole. Ongelmaksi muodostuu ainakin OoOE, jossa käskyjä suoritetaan niin monimutkaisten algoritmien kautta , että sinne syntyy bugeja, joka kaataa koko p**kan ja ominaisuuksia joudutaan kytkemään pois päältä tai mitigoimaan muulla suorituskyvyn romauttavalla tavalla: katso vaikka Spectre ja Meltdown.

Spectrellä ja meltdownilla ei ollut mitään tekemistä RISCin vs CISCin kanssa. Meltdown oli seurausta siitä, että muistinsuojaus toteutettiin tavalla, joka oli yksinkertaisin ja suorituskyvyn kannalta tehokkain, mutta energiatehokkuuden kannalta ei niin tehokas eikä ottanut huomioon sivukanavahyökkäyksiä. AMD ehkä Ryzenissä välttyi Meltdownilta koska optimoi hiukan enemmän energiatehokkuutta. Ja tosiaan osa RISC-prossuista toimi tämän suhteen ihan samalla tavalla kuin Intelin prossut ja oli Meltdown-alttiita.

Tuo 16- ja 32- bittisten sovellusten tuki tarkoittaa, että meillä on käskyjä, jotka operoivat nyt 64-bittisten rekistereiden alimpia bittejä. Sitten niiden yläosissa voi olla mitä vaan ja tämmöinen koodi on testaajan painajainen.

Tässä vaan ei poisteta tukea 32-bittisiltä softilta, vaan vain 32-bittisiltä käyttiksiltä.

Ja oleellista on muistinosoitusmuodot ja virtuaalimuistin rakenne, ei rekisterien bittimäärä.

Eli esim. tuo alkuperäinen 8086-moodin segmentointi jossa segmenttiosoitetta shiftattiin 4 bittiä ja lisättiin toiseen rekisteriin voidaan nyt pudottaa kokonaan pois.

Samoin voidaan pudottaa pois 286-malliset segment descriptorit, ja tarvii tukea vain 386-mallisia segment descriptoreita.
Koko segmentoinnin poistaminen olisi ollut kiva asia, mutta siihen ei vielä kuitenkaan päästy. Mutta neljästä eri segmentointimoodista (3 varsinaista moodia + ei käytössä) kahteen (1 moodi + ei käytössä) siirtyminen kuitenkin yksinkertaistaa.

Lisäksi toimintatilat ring 1 ja ring 2 voidaan poistaa kokonaan. Nämä olivat normaalin käyttäjätilan ja käyttöjärjestelmätilan välissä olevia toimintatiloja, joita hyvin harvoin käytettiin.


Ja sitten prossun käskydekooderi helpottuu hiukan kun voi pudottaa muinaisia vain 16-bittisessä tilassa olevia enkoodaussääntöjä pois. Valitettavasti vaan 386n user-modessa on tuettu melkein kaikki 8086n käskyt joten tämä yksinkertaistus jää melko pieneksi. x86-64ssa on sitten pudotettu enemmän legacy-tauhkaa pois, esim. BCD-käskyt (binary coded decimal), jotka on aivan älytöntä 1970-luvun roskaa joilla operoidaan datatyypeillä joita ei käytetä missään muussa kuin jossain (yli) 50 vuotta sitten koodatussa COBOL-koodissa.

 

[hkultala]

16 bittisyydestä luopumisen ymmärrän kun ei niitä 16bit softia ole 64bit Windowsilla tähänkään asti pystynyt ajamaan mutta 32bit softaa ja pelejä on vielä reippaasti käytössä.

Odotinkin, että tällainen uutinen nähtäisiin ennen pitkää. 32-bittiset pelit taitaa jo nykyisellään olla aika hillittyjä laitevaatimuksiltaan ja lukuisat pikkuohjelmat joita taustalla pyörii ovat nekin lähes kaikki 64-bittisiä. Suurin huolen aihe on, että siihen mennessä kun kuluttujaprosessoreista alkaa tippua 32-bittinen tuki, tarvitsisi perus-Windowseissa olla luotettava ja helppokäyttöinen emulointi 32-bittisille ohjelmille.

Tämä x86s ei vaikuta mitenkään niiden 32-bittisten softien toimivuuteen 64-bittisellä käyttiksellä.

Ne toimii ihan samalla tavalla kuin nykyäänkin 64-bittisellä käyttiksellä.

Poistuu vain mahdollisuus
1) Ajaa 16-bittisiä softia 16-bittisellä käyttiksellä
2) Ajaa 16-bittisiä softia 32-bitisen käyttiksen päällä
3) Ajaa 32-bittisiä softia 32-bittisellä käyttiksellä.

 

[hsalonen]

Spectrellä ja meltdownilla ei ollut mitään tekemistä RISCin vs CISCin kanssa. Meltdown oli seurausta siitä, että muistinsuojaus toteutettiin tavalla, joka oli yksinkertaisin ja suorituskyvyn kannalta tehokkain, mutta energiatehokkuuden kannalta ei niin tehokas eikä ottanut huomioon sivukanavahyökkäyksiä. AMD ehkä Ryzenissä välttyi Meltdownilta koska optimoi hiukan enemmän energiatehokkuutta. Ja tosiaan osa RISC-prossuista toimi tämän suhteen ihan samalla tavalla kuin Intelin prossut ja oli Meltdown-alttiita.

Tässä oli nyt minulla monta asiaa yhdessä kappaleessa, niin tuo on otettu pois siitä OOOE:n vierestä, missä sen pitäisi olla. En verrannut sitä RISC:iin, kunhan vastasin erittelemättä asioita. Olisi ollut selkeämpi yksi asia / yksi kappale, mutta nyt meni näin.

Tässä vaan ei poisteta tukea 32-bittisiltä softilta, vaan vain 32-bittisiltä käyttiksiltä.

Tässä minulla kyllä meni puurot ja vellit sekaisin. No, onneksi en ole tehdasautomaation puolella, johon tämä iskee pahimmin.

 

[Admiral General Aladeen]

Kiitoksia. Tämä auttaa hieman vanhojen pelien kohdalla, vaikkakaan ei ole sama asia, kuin käynnistää pikakuvakkeesta.

DOSBoxShortcuts - DOSBoxWiki

www.dosbox.com

Näyttää siltä, ettei edes tarvii autoexec batteja, vaan muokkaat dosboxin pikakuvaketta:

Itseasiassa juuri kun testasin tuota peliä, niin eipä muuten toimi dosboxdissa, vaan vaatii windowssin, eikä muuten toimi suoraan 64 bittisessä windows 10:ssä ja muistaakseni toimi 32 bittisessä.

Dos pelit toimii yleisesti tosi hyvin DOSBoxissa, mutta Win16 ohjelmat ja pelit vaativat Windowsin. Voit toki asentaa Win3.11 ja Win95:n DOSBoxiin, tai jollain paremmalla emulaattorilla pyörittää noita vanhoja Windowseja ja sitten ajaa Win16 ohjelmia sieltä.

Suurempi haaste onkin ensimmäiset Win95/98 aikakauden 3D pelit, jotka ei toimi uudemmilla Windowseilla, mutta sitä 3D kiihdytystä et helposti toteuta emulaattoreissa. Muistelen lukeneeni että on emulaattoreita jotka emuloivat Voodoo-3D kortteja, mutta ne toimii hitaasti vaikka oma rauta olisi kohtuu nopeaa.

 

[pq]

Odotinkin, että tällainen uutinen nähtäisiin ennen pitkää. 32-bittiset pelit taitaa jo nykyisellään olla aika hillittyjä laitevaatimuksiltaan ja lukuisat pikkuohjelmat joita taustalla pyörii ovat nekin lähes kaikki 64-bittisiä. Suurin huolen aihe on, että siihen mennessä kun kuluttujaprosessoreista alkaa tippua 32-bittinen tuki, tarvitsisi perus-Windowseissa olla luotettava ja helppokäyttöinen emulointi 32-bittisille ohjelmille.

Nojaa... omasta Windows myllystä löytyy Program Files (x86) kansion alta mm. seuraavat:
AMD:n ajureihin liittyvää sälää
Battle.net launcher
Bethesda.net launcher
EasyAntiCheat
VirtualCloneDrive
Epic Games Launcher
GOG Galaxy
Mozilla Maintenance Service
MSI Afterburner
Nvidian ajureihin liittyvää sälää
RivaTuner Statistics Server
Rockstar Games (launcher?)
Steam
Ubisoft Game Launcher
Windowssiin liittyvää sälää (Defender ym. "turhaketta")

 

[Jarnis]

Näistä suurin osa on siellä koska on haluttu yhteensopivus 32bit windowsin kanssa. Sinä päivänä kun se yhteensopivuus halutaan heittää mäkeen, ne voivat sieltä poistua.

Mutta realistisesti tähän on vielä matkaa vuosia. Toisaalta niin varmasti on ennenkuin Intelin uusi keitos pääsee lopulliseen kuluttajatuotteeseen asti. Näistä suunnitelmista on vain hyvä kertoa hyvissä ajoin että softakehittäjätkin tajuavat että muutoksia on horisontissa.

 

[user9999]

Aika paljon on Windowssissa tavaraa Program Files (x86) kansiossa. Aikamoinen huuto syntyisi jos tekisi Applet

32-bit app compatibility with macOS High Sierra 10.13.4 and later

About the transition to 64-bit technology and how it affects 32-bit apps.

support.apple.com

 

[Jarnis]

Kyllä sekin päivä joskus vielä tulee, mutta ennustaisin että puhutaan 5-10 vuodesta ainakin ja sen jälkeenkin saattaa winkku tarjota jonkun compatibility fallback moden. Apple vaan toteaa "fiksatkaa ohjelmanne tai eivät toimi uudella käyttiksellä, #dealwithit" ja jostain syystä Apple-käyttäjät ja devaajat tämän ovat hyväksyneet.

Ennustan että Windows menee tämän kaavalla:

- Päivänä X uuden Windows version uusissa asennuksissa 32bit softat ei enää asennu. Tulee sen sijaan viesti että kysy softan tekijöiltä uutta versiota.
- Tämän voi jollain asetuksella tai registry-muutoksella vielä muuttaa takaisin

Sitten odotellaan muutama vuosi ja vipu poistetaan ja myös Windows upgrade-asennukset tekevät saman tempun. Tämän jälkeen todennäköisesti tarvitaan jo epävirallisia puukotuksia että pyörii vielä. Toisaalta tässä vaiheessa kaikki relevantit ohjelmat on todennäköisesti päivitetty ja sitä vanhemmat voit sitten ajaa virtuaalikoneessa.

 

[mRkukov]

Siinä kohtaa kun x86S prossuja alkaa markkinoille tulla niin voisin vaikka lyödä vetoa että ne olisi hyvin houkuttelevia monille käyttäjille. Aika harvassa on ne jotka tarvitsee vanhoja tiloja vaikka huudon perusteella voisi jotain muuta kuvitella. Varmaan 99% kelpuuttaisi ihan sen perus x86S jossa pyörii kaikki uudehkot pelit, softat ja joka on nopeampi kuin mikään aikaisempi, mahdollisesti hieman edullisemmin.

Ei maailmasta ihan hetkeen x86 prossut silti katoaisi. Jos nyt alettaisiin myymään pelkkää x86S niin menisi 10+ vuotta että x86 prossuista alkaisi olla pulaa. Ei tietenkään uusia nopeuksia ja uusia ominaisuuksia, mutta täälläkin nyt ihmetellään miten DOS komennot toimii. Ne jotka haluaa harrastella löytäisivät varmasti sopivaa rautaa. Kyllähän sitten 20 vuotta sen muutoksen jälkeen voisi olla vaikeampaa jo löytää legacy prossuja, mutta voi voi. Eikö historiasta opita ikinä mitään? Ne jotka tietää tarvitsevansa, voisi ostaa kontillisen osia SER jätteestä.

 

[Jarnis]

Eikä tuo ole ongelma koska kysyntä tippuu paljon enemmän kuin mitä on SER-kamaa nurkissa. Haluatko kasata oman "upouuden" Commodore 64n? Onnistuu, moderneja emoja saa ja lähes kaikki piirit ovat edelleen joko valmistuksessa, tai niitä on tarpeeksi tarjolla. Vain SID ja VicII alkavat olla kiven alla, ja niille on tehty moderneja FPGA-pohjaisia korvikkeitakin... Tähän verrattuna erilaisia x86-prossuja on tehty aivan uskomattomia määriä ja niitä löytyy varastojen perukoilta, ihan new-old-stock -kunnossa vielä pitkään. Jos haluaa se Kaikkein Nopeimman Koskaan Tehdyn Prossun ennenkuin joku muutos meni sisään, sitten kannattanee hamstrata varastoa ennenkuin loppuvat, mutta jos vain kaipaat jotain hetkeä X vanhempaa yhteensopivaa, ne eivät tältä pallolta lopu sinun elinaikanasi...

Ja jos jostain syystä kysyntää vanhan liiton malleille on markkinoilla, Intel ja AMD jatkavat Special Snowflake Modelin tarjoamista jossain jäteprossujen seassa jossa featurena on "ja hei tukee vielä 16bit jätteitä". Niitä on ihan tarpeeksi jo validoituina olemassa ja voidaan jauhaa linjoilta vuosikausia kunhan mallia ei tarvitse muuttaa.

 

[LaDeX]

Mutta milläpä asennat siihen vanhaan koneeseen sen aikaisen Steamin jolta todennäköisesti on pudotettu tämän hullutuksen myötä tuki sille vanhalle alustalle. Ja ne pelit on siellä Steamissa.

 

[Ctzn_no7]

Todellisuushan on että legacya käytetään koska ei jakseta/viitsitä/haluta päivittää systeemejä.

ja niistäkin varmasti suurin osa saatais 2020-luvulle kun joku jaksais uhrata viikonlopun ja tekis softan toiminnallisuuden uudelleen jollain low-code työkalulla

Jonkun se päätös pitää tehdä milloin lopetataan vanhan tekniikan kanssa sählääminen, ja mitä nopeammin se tehdään sen parempi kaikille koska lopullinen siirtymäaika on varmasti +20vuotta

 

[Jarnis]

Mutta milläpä asennat siihen vanhaan koneeseen sen aikaisen Steamin jolta todennäköisesti on pudotettu tämän hullutuksen myötä tuki sille vanhalle alustalle. Ja ne pelit on siellä Steamissa.

Ennustan että Valve jatkaa 32bit yhteensopivan Steam-installerin jakoa pitkään jos se tuki poistetaan normiversiosta, juuri tämän vuoksi. Eli ne jotka ajavat museorautaa museokäyttiksellä jotta voivat ajaa museopelejä, voivat ajaa museo-Steamia. Sitten seurataan sen käyttömääriä ja kun viimeinen mohikaani on kuollut pois niin voidaan hiljaa disabloida

 

[LaDeX]

Ennustan että Valve jatkaa 32bit yhteensopivan Steam-installerin jakoa pitkään jos se tuki poistetaan normiversiosta, juuri tämän vuoksi. Eli ne jotka ajavat museorautaa museokäyttiksellä jotta voivat ajaa museopelejä, voivat ajaa museo-Steamia. Sitten seurataan sen käyttömääriä ja kun viimeinen mohikaani on kuollut pois niin voidaan hiljaa disabloida

Steamissa on nytkin myynnissä pelejä jotka ei enää nyky-Windowsilla toimi ainakaan suoraan.