Copyright © 1998-2025 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2025 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Tam kde jde o peníze, ďábel nemá místo a na barvu košile se nehraje. Výhodné by to bylo pro Intel nejen finančně, ale i marketingově a technologicky. Sice prosakují informace jak Apple přemýšlí o přechodu u některých modelů počítačů (tam kde běží OSX) na architekturu ARM a určitě už takové produkty testuje. Takto by byl Intel ještě lepší partner, určitě by Apple nelezl do zelí a přechod by mohl zrušit nebo odložit.
Cook sa tusim nechal pocut ze zatial oficialne neuvazuju o ARM pre notebooky/desktopy, lebo ARM je sice co do spotreby super, ale vykonovo nestiha. No na druhu stranu, to iste tvrdil aj Jobs 2 roky pred tym ako prisiel na podium s Intel masinou a OS X 10.4....
Pořád se mi moc nezdá, že by Apple dával ARMy do MacBooků a iMaců, přeci jsem jsou tam v současné době poměrně dost výkonné procesory i5 a i7 a to ARM zatím nedá, ten je zatím vhodný spíše tam kde se hraje na spotřebu. Navíc by zahodil veškerou kompatibilitu software, což se při přechodu z PowerPC na Intel do loňska řešilo emulací a fungovalo to. Nicméně emulovat x86 na ARMu zase moc nedává smysl. A teď jde hlavně o profi soft Quark, Adobe atp...
Že by nějaká další generace iPad, iPhone, iPod, i...?
S kompatibilitou SW to nesouvisí, OSX není portován jen na jeden typ instrukční sady. OSX běžel na PowerPC současně s Intel x86, zároveň funguje na ARM (iOS je pouze ořezaná verze OSX s vrstvou Touch). Od NEXT Stepu je to tak poskládané. Zmiňujete Rosetu, což byla vrstva emulace, ale to bylo z důvodu aby instrukce PowerPC ve starých aplikacích korektně fungovali na Intelu (i tehdy, když aplikace hrabe přímo na procesor a nepoužívá služeb systému, což v Carbon aplikacích bylo běžné). Ta emulace neměla nic společného s fungováním systému, ten byl multiplatformní.
Tudíž, když příští rok vydá Apple MB air s ARM a současně OSX, tak vám na tom všechny Intel aplikace budou fungovat (přechod Motorola 68xxx na PowerPC/ PowerPC na intel mají za sebou). To co píšete o výkonu těch procesorů je pravda a proto k tomu zatím nedojde. Ovšem nová rodina 64-bit ARM a využití výkonu grafárny dávají jisté možnosti. Ale zatím je to vše jen vývoj a zkoušení. Uvidíme co nám Jonathan Ive připraví.
Cheš mi říct, že na MacOS už nic neběží nativně, ale běží to ve virtuálním stroji - tedy zcela nezávisle na hardware? To se mi moc nezdá. To, že mají část systému překopanou na ARM šířenou pod jménem iOS je mi známo, ale tamní aplikace přeci nejsou kompatibilní s desktopovým MacOS X.
To jsem asi špatně napsal, ta nejnižší vrstva systému je rozhraní zajišťující funkci na daném procesoru (HW), změna této vrstvy nezmění funkčnost systému samotného. Jednotlivé aplikace můžou sáhnout přímo na procesor a využívat jeho kódu. Ale při klasickém vývoji v Cocoa na něj nesaháte. Proto to Apple již 2x řešil emulátorem zabudovaným do systému (poslední se jmenoval Roseta a umožňoval běh aplikací pro PowerPC na procesorech Intel bez ztráty kytičky, tedy měl jsem 2 aplikace které pak nefungovali). Když systém zjistil že aplikace není Intelredy normálně ji provozoval jen s využitím emulace. To sice běh zpomalil, ale díky většímu výkonu Core2Duo než G5 (ten bohužel neměl AltiVec jako G4) tak uživatel nepoznal nic.
Jinak iOS je jen jiná verze OSX (v tomhle naštěstí Jobse překecali), pro obě platformy je vývojové prostředí XCode, když píši aplikaci, tak si jen na začátku zvolím zda je to pro iOS nebo OSX, XCode mi přizpůsobí GUI ale pak používám ty samé funkce ty samé postupy. (jasně pro OSX nemám Touch, iOS nemám více oken, atakdáleatakdále) Jen bohužel iOS má některé knihovny ořezané, nebo zcela schází a to někdy nesmyslně. Apple má opravdu někdy nasrávací věci, jen jsou to jiné než se obvykle argumentuje na místních webech. Když něco programuji na Win, také občas vyteču, nebo nechápu když to má 100 let Apple, tak proč proboha to v Redmondu neudělali nějak podobně. To že aplikace psaná na iOS neběží na OSX je uděláno programově, prostě OSX si k tomu čuchne, pokrčí čumák a řekne fuj bobek.
Ano, s tím souhlas. Jádro mé původní myšlenky bylo, že z PowerPC se přešlo na výkonnější CPU, takže to, že část aplikací běžela v Rozetě nebyl problém (já to tedy kolikrát ani nepostřehl). Ztímco ARMy, i když jedou s výkonem nahoru, nejsou žádné trhače asfaltu, takže na nich emulovat x86 není žádné terno, počítám.
Leda by měl někdo způsob jak provést emulaci efektivně, třeba že by se relativně jednoduché instrukce RISCového ARMu chovaly jako mikrokód x86. :-) Ale nechytejte mne za slovo, programátor nejsem, assambler neumím.
"Jednotlivé aplikace můžou sáhnout přímo na procesor a využívat jeho kódu. Ale při klasickém vývoji v Cocoa na něj nesaháte."
Cocoa je len API pre tvorbu UI. Pokial je aplikacia v nemanagovanom jazyku (napr C, C++, Objective-C), tak priamo na processor saha, skompiluje sa predsa do nativneho kodu. Ak je dobre navrhnute a spravne pouzivane API, tak staci len prekompilacia na inu architekturu a vsetko ide hned ako ma. Rozhodne vsak nejake API (napr. Cocoa) nezabezpeci to, ze nativny kod pre jeden CPU pojde na inom.
Ine je to s managovanymi a skriptovacimi jazykmi (python, java, c#, js ...) a situaciu este miesaju fat binarky pre 2 a viac platforiem naraz skompilovane.
http://en.wikipedia.org/wiki/Cocoa_(API)
OS moze byt multiplatformny ako chce, nativne app treba mat nativne alebo ich emulovat.
MAC OS X v minulosti jak emuloval, tak aj podporuje fat binaries - app nativne skompilovana pre viac ako jednu architekturu.
zrovna produkty Adobe by na ARM fungovali zcela vpohode, vsechny dosavadni produkry Adove jsou multiplatformni a neni zadnej problem je rozjet treba i na smartphonu s androidem a ARM
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.