Intel on haudannut x86S-suunnitelmat

[Kaotik]

Intel kertoi viime vuonna suunnittelevansa uutta x86S-arkkitehtuuria, joka jättäisi menneiden aikojen haamujen vuoksi ylläpidetyt, ylimääräisiksi todetut ominaisuudet pois rajapinnasta ja keskittyisi nykypäivään.
Nyt yhtiö on varmistanut Tom's Hardwarelle, että nämä suunnitelmat on haudattu.

Lähde: Intel terminates x86S initiative — unilateral quest to de-bloat x86 instruction set comes to an end

 

[DiamondTear]

Onko missään esitetty arvioita siitä, että paljonko nuo vanhat tuet haittaavat uusissa prosessoreissa ja miksi? GPU-piireihin lisätään kaikenlaisia enkoodereita, dekoodereita ja äänikiihdytyksiä, mutta prosessorissa muutama transistori perinteen vuoksi on jotain sellaista, mistä pitää pyrkiä eroon.

 

[zxcv]

Onko missään esitetty arvioita siitä, että paljonko nuo vanhat tuet haittaavat uusissa prosessoreissa ja miksi? GPU-piireihin lisätään kaikenlaisia enkoodereita, dekoodereita ja äänikiihdytyksiä, mutta prosessorissa muutama transistori perinteen vuoksi on jotain sellaista, mistä pitää pyrkiä eroon.

Oma arvaus on että tuon edut liittyy enemmän tietoturvaan kun nopeuteen, eli pääsisi eroon vanhoista "väliaikaisista ratkaisuista" jotka ovat olleet hyviä ideoita 30-40v sitten.

 

[Agent_007]

GPU-piireihin lisätään kaikenlaisia enkoodereita, dekoodereita ja äänikiihdytyksiä

Näytönohjaimissa on se ero, että niitä käytetään ajurien kautta. Eli niissä riittää API-yhteensopivuus. Suorittimissa sen sijaan pitää olla käskykantayhteensopivuus, jos siis haluaa että kaikki aiemmin julkaistut ohjelmat toimivat samalla tavalla.

 

[pomk]

Näytönohjaimissa on se ero, että niitä käytetään ajurien kautta. Eli niissä riittää API-yhteensopivuus. Suorittimissa sen sijaan pitää olla käskykantayhteensopivuus, jos siis haluaa että kaikki aiemmin julkaistut ohjelmat toimivat samalla tavalla.

Tuosta taas päästään eroon käskykantatulkkauksella, kuten vaikkapa apple on näyttänyt todeksi. Luultavasti olisi ihan toimiva ratkaisu joidenkin vähän käytettyjen x86 käskyjen kanssa mitä tästä x86s:stä on karsittu pois. Taitaa jo suurin osa x86 käskyistä olla sellaisia että moderni prosessori mikrokoodilla pyörittää niitä johonkin settiin muita käskyjä ja ns. natiivitukea ei enää ole juuri millekkään roskalle mitä x86 käskykantaan on aikojen saatossa lisäilty. Tämä x86s olisi vaan kätevästi pakottanut tuon muunnoksen pois prossuista, samalla uudistaen jotain patentteja sun muita kivasti.

 

[Tigerou]

Ikävä kyllä x86-koodattuja softia on tehty jo 80-luvulta saakka niin järjettömiä määriä jotta x86s-idea taisi kuolla jo alkuunsa siihen. Onneksi. Kukahan newbie-neropatti Intelillä idean keksikään
Kaikki mikrokontrollerit, teollisuuden ohjaimet jne jne joita on käytössä uskomattomin määrin. Meneppä ehdottamaan kaikkien moisten vaihtamista vaikka kymmenien miljardien liikevaihtoa pyörittäville raaka-aineita tuottaville firmoille? Sekoitat samalla kätevästi miljoonien laitteiden yhteensopivuuden. Nice idea you moron!
Intelin ehdotus sai varmasti kylmää kyytiä niiltä firmoilta jotka oikeasti pyörittävät _fyysistä_ talouttamme. Pieninkin epäyhteensopivuus nykyisten järjestelmien kanssa olisi edellyttänyt merkittävää hyötyä verrattuna aikaisempiin järjestelmiin. Itsekin jo liian pitkään IT-hommia tehneenä "Jos se toimii - älä koske siihen!".

 

[takomo]

Intel kertoi viime vuonna suunnittelevansa uutta x86S-arkkitehtuuria, joka jättäisi menneiden aikojen haamujen vuoksi ylläpidetyt, ylimääräisiksi todetut ominaisuudet pois rajapinnasta ja keskittyisi nykypäivään.
Nyt yhtiö on varmistanut Tom's Hardwarelle, että nämä suunnitelmat on haudattu.

Lähde: Intel terminates x86S initiative — unilateral quest to de-bloat x86 instruction set comes to an end

Mitä vanhoja ominaisuuksia tässä olisi karsittu? Arvaan, että segmentoitu muistinosoitus olisi ollut tulilinjalla. Sitähän ei ole toteutettu 64-bittiseen tilaan oikeastaan lainkaan.

Tietoturva on oikeastaan asia, joka puoltaisi segmentoidun muistiosoituksen säilyttämistä ja laajentamista myös 64-bittiseen tilaan. Sillä voidaan toteuttaa näennäinen Harvard-arkkitehtuuri, jossa prosessien koodi ja data on eri muistiavaruuksissa. Segmentit on alusta pitäen tukeneet segmenttikohtaisia IOPL-oikeustarkistuksia (Ring 0-Ring 3), eli jos prosessi yrittää päästä käsiksi renkaille, joihin sillä ei ole oikeutta, niin yritykseksi jää - rautatasolla. Sivutetulle muistille voi määritellä vastaavaa mutta vain kaksitasoisesti User/System.

 

[Kaotik]

Mitä vanhoja ominaisuuksia tässä olisi karsittu? Arvaan, että segmentoitu muistinosoitus olisi ollut tulilinjalla. Sitähän ei ole toteutettu 64-bittiseen tilaan oikeastaan lainkaan.

Tietoturva on oikeastaan asia, joka puoltaisi segmentoidun muistiosoituksen säilyttämistä ja laajentamista myös 64-bittiseen tilaan. Sillä voidaan toteuttaa näennäinen Harvard-arkkitehtuuri, jossa prosessien koodi ja data on eri muistiavaruuksissa. Segmentit on alusta pitäen tukeneet segmenttikohtaisia IOPL-oikeustarkistuksia (Ring 0-Ring 3), eli jos prosessi yrittää päästä käsiksi renkaille, joihin sillä ei ole oikeutta, niin yritykseksi jää - rautatasolla. Sivutetulle muistille voi määritellä vastaavaa mutta vain kaksitasoisesti User/System.

Linkkejä seuraamalla olisi selvinnyt paljonkin. Suurin idea oli tehdä siitä puhtaasti 64-bittinen, eli 16- ja 32-bit tilat poistettu kokonaan myös käynnistyksestä, Ring 3 32-bit softat toimii, Ring 0 ei.

Envisioning a Simplified Intel® Architecture

Intel investigated architectural enhancements and modifications for a 64-bit mode-only architecture.

www.intel.com

 

[takomo]

Linkkejä seuraamalla olisi selvinnyt paljonkin. Suurin idea oli tehdä siitä puhtaasti 64-bittinen, eli 16- ja 32-bit tilat poistettu kokonaan myös käynnistyksestä, Ring 3 32-bit softat toimii, Ring 0 ei.

Tämä tarkoittaisi mm. kuoliniskua kaikelle vanhalle raudalle, jolle ei ole kirjoitettu 64-bittistä ajuria. Samoin 16-bittisiä legacy-ohjelmia ei voisi enää ajaa edes virtuaalikoneella.

Vanhojen tilojen ylläpito voi toki tuntua turhalta mutta kuluttaako ne oikeasti merkittävästi resursseja? Arkkitehtuuri toteutettiin pitkälti jo 80286:lla ja kokonaan 80386:lla (134k/275k transistoria kaikkeen toiminnallisuuteen).

 

[zxcv]

Samoin 16-bittisiä legacy-ohjelmia ei voisi enää ajaa edes virtuaalikoneella.

Eikö muka tuollasta "sata vuotta" vanhaa 486-rautaa voisi emuloida kokonaisuudessaan tarpeeksi nopeasti jollain QEMU:lla tms. x86S prosessorilla vaikka se itse uusi X86S ei tukisikaan/ymmärtäisi 16 bittisiä osoitteita?

 

[hkultala]

Yli 99%:iin kaikista uusista myydyistä PC:istä ei koskaan asenneta käyttöjärjestelmää, joka mahdollistaisi siirtymisen sellaiseen toimintamoodin, joka ei toimisi x86S:llä:

16-bittinen v86-tila ei ole käytettävissä 64-bittisen käyttiksen päällä, 64-bittisen käyttiksen päällä voi x86S-prossulla ajaa kaikkea samaa kamaa kuin normaalilla x86-64-prossulla.

x86s vaan käytännössä pudottaa pois mahdollisuuden ajaa 16-bittisiä tai 32-bittisiä käyttiksiä.

 

[hkultala]

Tämä tarkoittaisi mm. kuoliniskua kaikelle vanhalle raudalle, jolle ei ole kirjoitettu 64-bittistä ajuria.

Kuten?

Ei 32-bittiset ajurit muutenkaan toimi 64-bittisissä käyttiksissä.

Jos taas se softa mitä kutsut "ajuriksi" ei ole oikea ajuri vaan usermode-softaa , se toimii x86s-prossulla 64-bittisen käyttiksen päällä aivan samalla tavalla kuin normaalilla x86-64-prossulla 64-bittisen käyttiksen päällä.

Ne koneet joissa ajetaan 32-bittistä käyttistä sen takia että jollekin raudalle ei löyty 64-bittistä ajuria on hyvin harvinaisia.
Ne UUDET/uuden prossun sisältävät koneet joissa ajetaan 32-bittistä käyttistä sen takia että jollekin koneen sisältämälle raudalle ei löyty 64-bittistä ajuria on vielä harvinaisempia.

Ainoat merkitykselliset ja potentiaalisesti yleiset yhteensopivuusongelmat mitä keksin on, että
1) BIOSin bootloader-koodi pitää muokata toimimaan kokonaan 64-bittisessä tilassa.
2) joissain koneissa BIOSin päivitys voi vaatia boottausta DOSiin, mutta tämäkin on melko harvinaista, ja tämä ei x86s-prossulla ole mahdollista. Että joku emolevyvalmistaja voi joutua koodaamaan firmwarenpäivityssoftansa uusiksi että saa emolevynsä yhteensopiviksi x86s-prossujen kanssa.

Molemmat on lähinnä että emolevyvalmistajille (kertaluontoisesti) vähän lisätyötä, mutta kun työ on tehty, mitään ongelmia ei näistä ole.

Samoin 16-bittisiä legacy-ohjelmia ei voisi enää ajaa edes virtuaalikoneella.

16-bittisiä legacy-ohjelmia on jo vuosikaudet ajettu Dosbox-softalla, joka on ihan täysi emulaattori, ei virtuaalikone.

Vanhojen tilojen ylläpito voi toki tuntua turhalta mutta kuluttaako ne oikeasti merkittävästi resursseja? Arkkitehtuuri toteutettiin pitkälti jo 80286:lla ja kokonaan 80386:lla (134k/275k transistoria kaikkeen toiminnallisuuteen).

Ei näiden ominaisuuksien tuen hintaa lasketa niinkään transistoreissa vaan piirin kehittämisen monimutkaisuudessa, tuotekehitysajassa, luotettavuudessa ja siinä, millainen suorituskyky siihen uuteen tuotteeseen saadaan.

Kun prossua kehitettäessä pitää huomioida se, että uudenkin ytimen pitää toistaa identtisesti 42 vuotta vanhan prossun muistinosoitusbugi, koska maailmassa on paljon softaa joka väärinkäyttää tätä bugia käyttääkseen suurempaa määrää muistia kuin mitä 42 vuotta vanhalla prossulla muuten voi muuten accessoida, sitä aikaa mikä tähän prossun kehittäjältä menee ei voida käyttää jonkun uuden suorituskykyä parantavan ominaisuuden kehittämiseen ja testaamiseen.

Ja kun sen bugin toistamisen takia ei voida osoitteenlaskentayksikössä käyttää optimaalista yhteenlaskuyksikköä vaan sen sisällä pitää vetää muutama linja hassusti ja tarvitaan niiden valintaan ylimääräinen mux, pahimmillaan tästä voi tulla vaikka kellojakso lisää viivettä joihinkin latausoperaatioihin (ei toki todennäköistä).

 

[hkultala]

Eikö muka tuollasta "sata vuotta" vanhaa 486-rautaa voisi emuloida kokonaisuudessaan tarpeeksi nopeasti jollain QEMU:lla tms. x86S prosessorilla vaikka se itse uusi X86S ei tukisikaan/ymmärtäisi 16 bittisiä osoitteita?

Juuri näin nykyäänkin tehdään; Steamissa on esim, myynnissä ziljoona vanhaa DOS-peliä jotka on paketoitu Dosbox-emulaattorin sisään. Eikä kukaan valita että ne pyörivät liian hitaasti.

 

[Barbarossa]

1) BIOSin bootloader-koodi pitää muokata toimimaan kokonaan 64-bittisessä tilassa.

Voi olla että hallusinoin mutta muistaakseni UEFI ei edes tue 16-bittistä moodia, ilman CSMää tai vastaavaa ei pysty DOSia boottaamaan.

Legacy BIOSia ei toivottavasti ole yhdessäkään x86 laitteessa käytetty hetkeen.

 

[Dudem]

Voisikohan tämä sattumoisin liittyä puolustusteollisuuteen, siellä ei olla vielä valmiita siirtymään tulevaisuuteen. Tai yksinkertaisesti heittivät niin paljon porukkaa pihalle etteipä ole enää riittävästi tekijöitä. Jännä homma kuitenkin.

 

[Tigerou]

Eikö muka tuollasta "sata vuotta" vanhaa 486-rautaa voisi emuloida kokonaisuudessaan tarpeeksi nopeasti jollain QEMU:lla tms. x86S prosessorilla vaikka se itse uusi X86S ei tukisikaan/ymmärtäisi 16 bittisiä osoitteita?

Kaikkea voi varmasti emuloida mutta miksi pitäisi? Jos nykyinen ratkaisu _TOIMII_ niin sen korvaaminen uudemmalla ei monestikaan kannata koskei moisesta ole mitään hyötyä. Valtavassa osassa tuotantojärjestelmissä ei ole mitään *itunkaan hyötyä jostain x86-kannan uudistuksista. Kaikki on jo tehty/optimoitu aikanaan, eikä pikkuruinen uudistus CPU-tasolla tekisi kuin enintään haittaa jo toimiville systeemeille. Teollisuudessa kun onneksi vielä toimii perinteinen "Alä saatana koske siihen jos se toimii."

 

[Tigerou]

Kaikkea voi varmasti emuloida mutta miksi pitäisi? Jos nykyinen ratkaisu _TOIMII_ niin sen korvaaminen uudemmalla ei monestikaan kannata koskei moisesta ole mitään hyötyä. Valtavassa osassa tuotantojärjestelmissä ei ole mitään *itunkaan hyötyä jostain x86-kannan uudistuksista. Kaikki on jo tehty/optimoitu aikanaan, eikä pikkuruinen uudistus CPU-tasolla tekisi kuin enintään haittaa jo toimiville systeemeille. Teollisuudessa kun onneksi vielä toimii perinteinen "Alä saatana koske siihen jos se toimii."

 

[maajussi]

Ikävä kyllä x86-koodattuja softia on tehty jo 80-luvulta saakka niin järjettömiä määriä jotta x86s-idea taisi kuolla jo alkuunsa siihen. Onneksi. Kukahan newbie-neropatti Intelillä idean keksikään
Kaikki mikrokontrollerit, teollisuuden ohjaimet jne jne joita on käytössä uskomattomin määrin. Meneppä ehdottamaan kaikkien moisten vaihtamista vaikka kymmenien miljardien liikevaihtoa pyörittäville raaka-aineita tuottaville firmoille? Sekoitat samalla kätevästi miljoonien laitteiden yhteensopivuuden. Nice idea you moron!
Intelin ehdotus sai varmasti kylmää kyytiä niiltä firmoilta jotka oikeasti pyörittävät _fyysistä_ talouttamme. Pieninkin epäyhteensopivuus nykyisten järjestelmien kanssa olisi edellyttänyt merkittävää hyötyä verrattuna aikaisempiin järjestelmiin. Itsekin jo liian pitkään IT-hommia tehneenä "Jos se toimii - älä koske siihen!".

Tämä tarkoittaisi mm. kuoliniskua kaikelle vanhalle raudalle, jolle ei ole kirjoitettu 64-bittistä ajuria. Samoin 16-bittisiä legacy-ohjelmia ei voisi enää ajaa edes virtuaalikoneella.

Vanhojen tilojen ylläpito voi toki tuntua turhalta mutta kuluttaako ne oikeasti merkittävästi resursseja? Arkkitehtuuri toteutettiin pitkälti jo 80286:lla ja kokonaan 80386:lla (134k/275k transistoria kaikkeen toiminnallisuuteen).

Hkultala jo hyvin vastasikin teille tekniikan osalta.

Ja siis vaikka Intel olisikin tehnyt valmiiksi ja siirtynyt x86S-arkkitehtuuriin, niin eipä se nyt sitä tarkoittaisi että perinteinen x86-sarja lopetettaisiin samantien, varmasti niitä olisi tehty siinä rinnalla vielä vuosikaudet.

 

[hkultala]

Kaikkea voi varmasti emuloida mutta miksi pitäisi? Jos nykyinen ratkaisu _TOIMII_ niin sen korvaaminen uudemmalla ei monestikaan kannata koskei moisesta ole mitään hyötyä. Valtavassa osassa tuotantojärjestelmissä ei ole mitään *itunkaan hyötyä jostain x86-kannan uudistuksista. Kaikki on jo tehty/optimoitu aikanaan, eikä pikkuruinen uudistus CPU-tasolla tekisi kuin enintään haittaa jo toimiville systeemeille. Teollisuudessa kun onneksi vielä toimii perinteinen "Alä saatana koske siihen jos se toimii."

Kaikkea ei todellakaan "ole jo tehty" valmiiksi vaan kaikki se 8086/80286-yhteensopivuuskuona joudutaan tekemään ja verifioimaan uudiksi aina kun suunnitellaan kunnolla uusi mikroarkkitehtuuri. Ja tämä kuona sisältää sellaisia asioita kuten 80286n A20-osoitelinjan bugin duplikoinnin.

Että argumenttisi "kaikki on jo tehty" pätisi ainoastaan tilanteeseen, että päätetään että ei koskaan enää suunnitella enää yhtään uutta x86-mikroarkkitehtuuria vaan mennään nykyisillä zen5lla, Lion Covella ja Skymontilla ikuisuuden tulevaisuuteen.

Sen sijaan se softaemulaattori nimenomaan on asia, joka on jo tehty ja toimii hyvin. Sillä voidaan ajaa 8086-softaa ikuisesti vaikka rauta alta suunnitellaan vaikka kuinka moneen kertaan uusiksi.

 

[jive]

Aika yllättävä veto Inteliltä. Ehkä liittyy säästökuuriin jolle firma on laitettu. Teknistä syytä ei ole miksi ei voitaisi vanhaa PC:tä haudata lopullisesti. Teollisuudesta paine ei tule.

 

[zepi]

Aika yllättävä veto Inteliltä. Ehkä liittyy säästökuuriin jolle firma on laitettu. Teknistä syytä ei ole miksi ei voitaisi vanhaa PC:tä haudata lopullisesti. Teollisuudesta paine ei tule.

Mikään ei myöskään estä jatkamasta jotain vanhan designing embedded prossujen myyntiä teollisuuskäyttöön jos niille jotain kysyntää löytyy.

 

[jive]

Mikään ei myöskään estä jatkamasta jotain vanhan designing embedded prossujen myyntiä teollisuuskäyttöön jos niille jotain kysyntää löytyy.

Ei varmaan teknisesti olisikaan, niin vaan ei tapahdu.

 

[zepi]

Ei varmaan teknisesti olisikaan, niin vaan ei tapahdu.

Miksi ei tapahtuisi jos joku oikeasti tarvitsee ja on valmis maksamaan siitä? Noita jotain Atomeita / mitälie voi printata jollain 14nm prosessilla hamaan ikuisuuteen asiakkaille jotka niitä kaipaavat. Ei niitä mihinkään tarvitse kehittää, porukka joka ajaa jotain 80/90-luvun taitteen x86-koodia ei tarvitse suorituskykyä 386:sta enempää.

 

[jive]

Miksi ei tapahtuisi jos joku oikeasti tarvitsee ja on valmis maksamaan siitä? Noita jotain Atomeita / mitälie voi printata jollain 14nm prosessilla hamaan ikuisuuteen asiakkaille jotka niitä kaipaavat. Ei niitä mihinkään tarvitse kehittää, porukka joka ajaa jotain 80/90-luvun taitteen x86-koodia ei tarvitse suorituskykyä 386:sta enempää.

Räätälöityjä x86 suorittimia pitäisi ostaa sellaisia määriä ettei ole taloudellisesti mahdollista. En tiedä tunteeko historia Intelin kohdalla tällaista tapausta. Ehkä @hkultala muistaa jos moista on koskaan tapahtunut.

 

[hkultala]

Räätälöityjä x86 suorittimia pitäisi ostaa sellaisia määriä ettei ole taloudellisesti mahdollista. En tiedä tunteeko historia Intelin kohdalla tällaista tapausta. Ehkä @hkultala muistaa jos moista on koskaan tapahtunut.

Intelillä oli ainakin 1996-1998 (eli vielä pentium pro:n julkaisun jälkeen) tuotannossa vielä 386n vähävirtainen ja pieni erikoismalli jota nokia käytti 9000 kommunikaattorissaan.

9110ssa (tuli muistaakseni 1998) sitten vaihdettiin AMDn vastaavaan 486een.

En näe mitään oikeaa (teknistä tai taloudellista) ongelmaa siinä että vastaavia voisi tehdä nykyääänkin jostain muutaaman vuoden vanhoista atomeista, jos vaan asiakkaat löytyy.

Sen sijaan typeräksi ongelmaksi voi tulla typerät johtajat joilla välillä on kiima tappaa kaikki sellaiset (voittoakin tuottavat) tuotteet jotka ei ole firman senhetkisen (mutta välillä tuuliviirin tavoin heiluvan) strategian mukaisia.

 

[pomk]

Räätälöityjä x86 suorittimia pitäisi ostaa sellaisia määriä ettei ole taloudellisesti mahdollista. En tiedä tunteeko historia Intelin kohdalla tällaista tapausta. Ehkä @hkultala muistaa jos moista on koskaan tapahtunut.

Intel on ainakin aiemmin tehnyt jotain ihan muinaismuistotason prossuja hyvin pitkään moista käyttöä varten. Esim. 486 prossut oli tuotannossa 1989 - 2007. Nyt on jotain muita LTS suorittimia joita on luvattu pitää markkinoilla vuosikymmen tjsp.

 

[zxcv]

Räätälöityjä x86 suorittimia pitäisi ostaa sellaisia määriä ettei ole taloudellisesti mahdollista. En tiedä tunteeko historia Intelin kohdalla tällaista tapausta. Ehkä @hkultala muistaa jos moista on koskaan tapahtunut.

Eihän tuossa pitäisi edes mitään räätälöidä vaan ostaa jo valmista tuotetta muutaman vuoden takaa

 

[maajussi]

Ja vaikkapa USA:n avaruussukkula oli 70-luvun lopun tekniikkaa ja tietokoneet samalta ajalta sukkulassa ja silti viimeinen sukkulalento tehtiin vuonna 2011. Toki suurin syy sukkulalentojen loppumiseen korkeat kustannukset, mutta yhtenä syynä mainittiin myös että sen tietokoneisiin oli vaikea enää
loppuvaiheessa saada varaosia. Tää nyt vaan esimerkkinä, että 30 vuotta olivat niitä tietokoneen varaosia saaneet siihenkin.

 

[jive]

Ja vaikkapa USA:n avaruussukkula oli 70-luvun lopun tekniikkaa ja tietokoneet samalta ajalta sukkulassa ja silti viimeinen sukkulalento tehtiin vuonna 2011. Toki suurin syy sukkulalentojen loppumiseen korkeat kustannukset, mutta yhtenä syynä mainittiin myös että sen tietokoneisiin oli vaikea enää
loppuvaiheessa saada varaosia. Tää nyt vaan esimerkkinä, että 30 vuotta olivat niitä tietokoneen varaosia saaneet siihenkin.

Meinaat että valmistavan teollisuuden kustannusrakenne kestäisi jotakin tuon kaltaista?

 

[jive]

Eihän tuossa pitäisi edes mitään räätälöidä vaan ostaa jo valmista tuotetta muutaman vuoden takaa

Lasken homman räätälöinniksi jos olemassaoleva piiritoteutus tuotetaan eri linjalta kuin missä se on alunperin ajateltu valmistettavan. Jos homma on noin helppoa niin ota asiasta selvää ja sitten minuun yhteyttä mitä noin 3000 kpl vuosittainen kulutus maksaisi siten että piiri on 30v sama. Ei tartte olla sitä sukkuloiden 50 vuotta edes. Jos pystyt siihen että tuollainen neljän ytimen goldmont olisi SoCna 50€ kpl niin olen enemmän kuin kiinnostunut.

 

[pomk]

Lasken homman räätälöinniksi jos olemassaoleva piiritoteutus tuotetaan eri linjalta kuin missä se on alunperin ajateltu valmistettavan. Jos homma on noin helppoa niin ota asiasta selvää ja sitten minuun yhteyttä mitä noin 3000 kpl vuosittainen kulutus maksaisi siten että piiri on 30v sama. Ei tartte olla sitä sukkuloiden 50 vuotta edes. Jos pystyt siihen että tuollainen neljän ytimen goldmont olisi SoCna 50€ kpl niin olen enemmän kuin kiinnostunut.

Ostat niitä 90000 varastoon ja se siitä.

 

[jak_pdgm]

Mahtaako joku perus x86 prossu olla yleensäkään kovin suuri ongelma siellä teollisuudessa, kun koneet, logiikat, sun muut käyttää joka tapauksessa paljon erikoisempia ja antiikkisempia komponentteja. Töissä on esim. cnc-konetta ohjaamassa muutamaan jääkaapin kokoinen kabinetti, joka sisältää ilmeisesti mm. muutaman kilotavun kuplamuistia. Ellen olisi joskus lukenut aiheesta 80-luvun mikrobitistä, en tietäisi että sellaista on olemassakaan.

 

[jive]

Mahtaako joku perus x86 prossu olla yleensäkään kovin suuri ongelma siellä teollisuudessa, kun koneet, logiikat, sun muut käyttää joka tapauksessa paljon erikoisempia ja antiikkisempia komponentteja. Töissä on esim. cnc-konetta ohjaamassa muutamaan jääkaapin kokoinen kabinetti, joka sisältää ilmeisesti mm. muutaman kilotavun kuplamuistia. Ellen olisi joskus lukenut aiheesta 80-luvun mikrobitistä, en tietäisi että sellaista on olemassakaan.

Puhuin tai ainakin tarkoitin puhua teollisuuslaitoksista ja prosesseista, en niinkään yksittäisistä työkoneista.

 

[jak_pdgm]

Puhuin tai ainakin tarkoitin puhua teollisuuslaitoksista ja prosesseista, en niinkään yksittäisistä työkoneista.

On siellä tietysti myös x86:ia vähintään valvomoissa, mutta veikkaan että vaikka prosessia ohjaavassa pid-säätimessä tai mikä laite onkaan on todennäköisemmin jotain muuta sisällä. Inteliltä ennemmin vaikka 8096 tms.

 

[jive]

On siellä tietysti myös x86:ia vähintään valvomoissa, mutta veikkaan että vaikka prosessia ohjaavassa pid-säätimessä tai mikä laite onkaan on todennäköisemmin jotain muuta sisällä. Inteliltä ennemmin vaikka 8096 tms.

Voin kertoa että et voisi olla enemmän väärässä. Aika iso osa laitekantaa ajaa jopa Microsoftin tuotteita.

 

[jak_pdgm]

Voin kertoa että et voisi olla enemmän väärässä. Aika iso osa laitekantaa ajaa jopa Microsoftin tuotteita.

Juu joskus kesätöissä muovia valmistavaa linjaa ohjattiin sen aikaisella windows pc:llä, mutta se korvattiin myöhemmin linuxilla, kun tukkeutuneen linjan jatkuva putsaaminen vei liikaa aikaa.

 

[takomo]

Kuten?

Ei 32-bittiset ajurit muutenkaan toimi 64-bittisissä käyttiksissä.

Ensinnäkin esim. Debian on saatavilla virallisesti tuettuna x86-versiona, myös ensi vuonna julkaistava "testing"-versio. Sille saa oletettavasti softatukea n. 2035 saakka. Sen jälkeenkin sitä voi käyttää vuosia suljetuissa ympäristöissä. 32-bittisen ajurin ajaminen natiivisti 32-bittisessä käyttöjärjestelmässä ei ole softan puolesta ongelma pitkään aikaan.

Myös 64-bittisessä ympäristössä x86-käyttiksiä pystyy ajamaan virtuaalikoneella mutta käsittääkseni se edellyttää prossun tukevan 32-bittisiä tiloja. Siinä, että saa jonkin rauta-ajurin toimimaan virtuaalikoneella voi toki olla jonkin verran työmaata.

Nämä ongelmat eivät ehkä niinkään kosketa läppäreitä tai työpöytäkoneita vaan sovelluksia, joissa PC on valjastettu valvomaan ja/tai ohjaamaan jotain.

Kun prossua kehitettäessä pitää huomioida se, että uudenkin ytimen pitää toistaa identtisesti 42 vuotta vanhan prossun muistinosoitusbugi, koska maailmassa on paljon softaa joka väärinkäyttää tätä bugia käyttääkseen suurempaa määrää muistia kuin mitä 42 vuotta vanhalla prossulla muuten voi muuten accessoida, sitä aikaa mikä tähän prossun kehittäjältä menee ei voida käyttää jonkun uuden suorituskykyä parantavan ominaisuuden kehittämiseen ja testaamiseen.

Jos jopa 80286:n A20:n replikointi on yhä tärkeää, niin tätä legacy-softaa täytyy olla maailmalla todella paljon ja/tai todella tärkeissä paikoissa.

Intelillä oli ainakin 1996-1998 (eli vielä pentium pro:n julkaisun jälkeen) tuotannossa vielä 386n vähävirtainen ja pieni erikoismalli jota nokia käytti 9000 kommunikaattorissaan.

9110ssa (tuli muistaakseni 1998) sitten vaihdettiin AMDn vastaavaan 486een.

Erilaiset sulautetut järjestelmät ei taida olla ihan pieni markkina varsinkaan kappalemäärissä laskettuna?

Juuri näin nykyäänkin tehdään; Steamissa on esim, myynnissä ziljoona vanhaa DOS-peliä jotka on paketoitu Dosbox-emulaattorin sisään. Eikä kukaan valita että ne pyörivät liian hitaasti.

Muistanko oikein, että juuri Steam kapinoi hiljattain 32-bittisen koodin tuen puolesta? Valtaosa vähänkään vanhemmista peleistä on koodattu 32-bittisinä eikä kukaan tule konvertoimaan niitä 64-bittisiksi.

 

[jive]

hkultala osaa varmasti kertoa faktat mutta olen ymmärtänyt että vanhojen ominaisuuksien säilyttäminen liittyy nimenomaan IBM PC yhteensopivuuteen jonka varaan sekä UEFI että BIOS rakennetaan x86 alustalla sekä Windowsin ABI yhteensopivuus vuosikymmenien ajan.

 

[love_doctor]

Kaikkea voi varmasti emuloida mutta miksi pitäisi? Jos nykyinen ratkaisu _TOIMII_ niin sen korvaaminen uudemmalla ei monestikaan kannata koskei moisesta ole mitään hyötyä. Valtavassa osassa tuotantojärjestelmissä ei ole mitään *itunkaan hyötyä jostain x86-kannan uudistuksista. Kaikki on jo tehty/optimoitu aikanaan, eikä pikkuruinen uudistus CPU-tasolla tekisi kuin enintään haittaa jo toimiville systeemeille. Teollisuudessa kun onneksi vielä toimii perinteinen "Alä saatana koske siihen jos se toimii."

Kuten varmaan olet huomannut viimeisen 70 vuoden ajalta, kehitys ei pysähdy. Esim. vanhat 16-bittiset ohjelmat on pitkälti kirjoitettu aikana kun prosessoreissa ei vielä ollut pakollista L2-cachea ja kellotaajuus < 25 MHz. Tuona aikanakaan ne softat eivät käyttäneet tietenkään kaikkia koneen tehoja, osa on voinut vaatia vain pientä murto-osaa. Softapohjainen emulointi voi maksaa 100x lisälaskentana, mutta ei tunnu missään kun ihan alimman tason i3-koneetkin emuloivat yli 100% nopeudella noita laitteita (per ydin), vaikkei olisi käytössä mitään edistynyttä emulaatiotekniikkaa. Dosboxin tapaisethan ovat jo 25 vuotta sitten emuloineet ihan sujuvasti noita legacy-juttuja. Suurin rajoite on ollut dokumentoinnin puute ja kuten aina, harrasteprojekteissa miestyövoiman vähyys.

Erilaisia nichejä on loputtomiin vuosien varrelta. Tällainen yksi päätös ei vielä vaikuta paljon, mutta kyllä konservatiivinen asenne tässä käytännössä voi jumiuttaa koko alustan kehityksen. Esim. näytönohjainpuolella vähän vastaava voisi olla OpenGL:ään hirttäytyminen. Linux-puolella zink-ajureilla on emuloitu OpenGL:ää Vulkanilla ja emulointiajurit toimivat yllättävänkin vikkelään. Legacy-tukea tarvitsevien osuus myös kutistuu vuosi vuodelta suhteellisesti ja absoluuttisesti. En ota kantaa liiketaloudelliseen puoleen, mutta teknisesti tuossa ei ole mitään järkeä. Enkä edes päässyt esim. tietoturvaan asti.

 

[love_doctor]

Jos jopa 80286:n A20:n replikointi on yhä tärkeää, niin tätä legacy-softaa täytyy olla maailmalla todella paljon ja/tai todella tärkeissä paikoissa.

Erilaiset sulautetut järjestelmät ei taida olla ihan pieni markkina varsinkaan kappalemäärissä laskettuna?

Näissä kai se isoin ongelma on, että ei haluta eriyttää käskykantaa eri käyttökohteisiin.

Eihän jonkun 286-tasoisen ohjauskoneen replikointi / emulointi nykytekniikalla ole temppu eikä mikään. Jos huomioidaan nykyisen valmistustekniikan skaalautuvuus esim. kellotaajuuksien osalta, 286 voitaisiin tehdä alkuperäistä pienemmällä transistorimäärällä ja helpommin, kun ei tarvi kikkailla yhtään. Kyse on yli 40 vuotta vanhasta laitteesta, jossa on reilu 100 000 transistoria. Tuon emulointi softalla on ollut triviaalia jo 25 vuotta.

On vaan laiskuutta, jos tehdään liiketaloudellinen päätös, että kaikilla x86-koneilla 0,1W teollisuus-PC:stä 1000W 512-ytimiseen palvelimeen AVX512-käskyillä pitää tehdä sama 16-bittisyyden tuki näppiskontrollerin kikkaa myöden. Aikaa kun kuluu, pian on 65536-ytimisiä 10 GHz palvelimia ja samat 16-bittiset legacyt siellä kummittelemassa. Tuskin kenellekään tulee edes pahimmissa sienitripeissä mieleen laittaa noita tehokoneita ajamaan dedikoidusti jotain pilipali-koodia 80-luvulta.

Muistanko oikein, että juuri Steam kapinoi hiljattain 32-bittisen koodin tuen puolesta? Valtaosa vähänkään vanhemmista peleistä on koodattu 32-bittisinä eikä kukaan tule konvertoimaan niitä 64-bittisiksi.

Tässä olisi ollut ehkä fiksua eriyttää 16- ja 32-bittiset tilat kun 32-bittisyyttä on tosiaan vielä viime vuosinakin käytetty. Onkohan Steamin käyttöliittymäkään vielä 64-bittinen Linuxilla ainakaan. Itsellä on koneissa niin, että jos ajetaan Steamia / Wineä, kernelistä on 32-bit tuki 64-bittisellä kernelillä, muuten tietoturvasyistä jne. pois käytöstä. UEFI:n CSM on myös pois. Toki 32-bittiselle tarjotaan esim. 64-bittinen aikaleimojen API. 32-bittisessä voisi olla joitain juttuja, joista voisi luopua uusissa prosessoreissa. Esim. PAE lienee tällainen niche taas. Sellaisten sietäisi saada kepistä, jotka ovat 64-bittisyyden ja webbi/pilviohjelmien aikaan kokeneet, että on hyvä idea tehdä oma softa natiivina ja jakaa se 3 gigan kokoisiin prosesseihin, joita on sitten se 20 kpl 64 gigan muistillisessa koneessa (tai ehkä enemmän jos on swappia?).