Nastal čas na kakao – s Intelem, s Intelem, jedeme do... - MujMAC.cz - Apple, Mac OS X, Apple iPod

16. června 2005, 00.00 | ... budoucnosti. A co to znamená pro programátory v Cocoa? Inu, vlastně nic, až na několik skutečných výjimek, na něž se podíváme blíže.

... budoucnosti. A co to znamená pro programátory v Cocoa? Inu, vlastně nic: vývojové prostředí Cocoa – tedy, přesněji řečeno, OpenStep, jenž byl jeho přímým předchůdcem a oproti němuž Cocoa přináší pouze nové služby, ale žádné koncepční změny – bylo od samého začátku navrženo jako plně portabilní. A nejen navrženo; také v praxi mnohokrát vyzkoušeno: aplikace, psané v OpenStepu, zcela běžně podporovaly tzv. "fat binaries" (což je totéž, jako dnešní "universal binary"), a zcela běžně pracovaly na čtyřech různých architekturách: Motorola 68K, Sun SPARC, HP PA-RISC, a také, pro současné Macy nejzajímavější, Intel x86.

Z hlediska Cocoa se tedy dá říci nihil novi sub sole, a skutečně jediné, co naprostá většina aplikací bude pro podporu budoucích strojů, založených na architektuře Intel, potřebovat, je nový překlad.

Co je to "universal binary"?

Je to jednoduché: formát Mach-O, standardně v Mac OS X užívaný pro jakékoli spustitelné soubory, odjakživa podporuje tzv. "fat binaries", v současnosti přejmenované na "universal binaries" (čert a Jobs vědí proč, snad kvůli politické korektnosti). Jde prostě o to, že jeden jediný soubor ve formátu Mach-O může obsahovat libovolně mnoho "vložených souborů", každý z nich vhodný pro jinou architekturu.

Pro ty, kdo se nebojí Terminalu, je v Mac OS X standardně k dispozici prostředek, který umožňuje práci s "fat binaries"; jmenuje se lipo. Tiger využívá "fat binaries" již v současnosti pro alternativní podporu dvaatřiceti- a čtyřiašedesátibitového prostředí:

122 /usr/lib> cd
123 ~> cd /usr/lib                              
124 /usr/lib> lipo -detailed_info libstdc++.6.0.3.dylib
Fat header in: libstdc++.6.0.3.dylib
fat_magic 0xcafebabe
nfat_arch 2
architecture ppc64
    cputype CPU_TYPE_POWERPC64
    cpusubtype CPU_SUBTYPE_POWERPC_ALL
    offset 4096
    size 1143544
    align 2^12 (4096)
architecture ppc
    cputype CPU_TYPE_POWERPC
    cpusubtype CPU_SUBTYPE_POWERPC_ALL
    offset 1163264
    size 1103912
    align 2^14 (16384)
125 /usr/lib> 

Co bude zapotřebí pro Intel?

Pro tvorbu "universal binaries" je, zjednodušeně řečeno, zapotřebí Xcode 2.1 – update, který již v současnosti je k dispozici prostřednictvím ADC. (Xcode 2.1 obsahuje i další novinky, kupříkladu dosti zásadně mění formát samotného projektu; kromobyčejně zajímavé je i to, že nyní jsou standardní a nedílnou součástí distribuce Xcode bez jakékoli licence také WebObjects; na to se ale podíváme až jindy.)

Ačkoli sestavovat "universal binaries" bychom mohli i bez Xcode 2.1 (ostatně, jak víme z minulého odstavce, ti, kdo používají podporu čtyřiašedesáti bitů na G5, už to dělají); nezbuildujeme si ale bez něj intelovský kód. To proto, že součástí Xcode 2.1 je i nová verse překladače GCC 4; ta z 2.0 podporu pro Intel neobsahuje:

131 /tmp> cc q.m -arch i386
cc: installation problem, cannot exec 'i686-apple-darwin8-gcc-4.0.0': No such file or directory
132 /tmp> 

Opravdu žádné změny v kódu?

Opravdu – pokud původní kód neobsahoval tak trochu prasárny, jako třeba závislost na tom, zda se jednotlivé části vícebytových hodnot ukládají "zdola" nebo "shora" (little/big endian), nebo zda jste třeba nedělili nulou. I těchto potenciálních problémů je však dost málo:

Pořadí bytů

Vzhledem k tomu, že Objective C je nadstavba C, můžeme narazit na několik typicky "céčkových" problémů: především jde o pořadí bytů ve vícebytových hodnotách, a také (okrajově související) ukládání dat do struktur/unií a bitových polí.

Procesory PowerPC (v počítačích Apple a v Mac OS X) využívají tzv. "big-endian" přístupu; při něm se nejvýznamnější byte vícebytové hodnoty ukládá na nejnižší adresu. U procesorů Intel je tomu právě naopak: na nejnižší adrese je nejméně významný byte.

Používáme-li pro práci s vícebytovými hodnotami důsledně služby Cocoa, žádný problém nenastane: kupříkladu DO při předávání dat mezi procesy na různých počítačích, nebo třídy NSCoder (a její podtřídy) při archivaci objektů se automaticky postarají o převádění pořadí bytů podle potřeby (vyjma případu, kdy byly archivovány struktury obsahující bitová pole – u nich je třeba převrátit pořadí polí); tím spíše to platí pro přístup k datům na ještě vyšší úrovni (CoreData, WebObjects).

Problém ovšem může nastat, pokud užíváme ukazatelů a měníme velikost dat, na něž ukazatel odkazuje, nebo pokud načítáme data ze souborů prostřednictvím služeb nízké úrovně (NSFileHandle, NSData). Práci s ukazateli musíme ošetřit ručně; pro převody mezi různým pořadím bytů ve zbývajících případech Mac OS X nabízí velmi bohatou skupinu funkcí NSSwap... ve Foundation Kitu.

Funkce mají obecná jména NSSwapXxxYyyToHost a NSSwapHostToXxxYyy, kde Xxx je specifikace pořadí bytů ("Big" pro big-endian, jako PowerPC, nebo "Little" pro little-endian, jako Intel), a Yyy je požadovaný typ. "Host" samozřejmě znamená architekturu, na níž právě teď program běží. Máme-li tedy kupříkladu soubor, o němž víme, že obsahuje čísla int uložená v "powerpcovském" formátu big-endian, můžeme je spolehlivě načítat pomocí kódu

NSData *d=[NSData dataWithContentsOfFile:filename options:0 error:&err];
...
unsigned u=NSSwapBigIntToHost(*(unsigned*)[d bytes]);

Aritmetika

Procesory Intel neumějí počítat (jak je ostatně jejich tradicí už od dob prvního Pentia, jež se proslavilo tím, že počítalo velmi rychle, ale chybně ☺). Při programování v Cocoa opět můžeme narazit na problémy, pokud používáme výpočty na úrovni jazyka C a jeho standardních datových typů. Jde o čtyři "finty": převody příliš velkých desetinných čísel na celá čísla, porovnávání neceločíselných hodnot, velikost typu long double, a dělení nulou.

• převádíme-li neceločíselnou hodnotu (float, double) na celé číslo, pak se samozřejmě může stát, že hodnota je větší, než maximální přípustná hodnota pro celé číslo. PowerPC v takovém případě automaticky použije nejvyšší možnou celočíselnou hodnotu, MAXINT, Intel ovšem naopak použije hodnotu nejmenší možnou, totiž MININT ☺;
• čísla typu long double jsou na obou architekturách šestnáctibytová; zabírají tedy 128 bitů. Intel však třetinu ignoruje – na něm je významných pouze 80 bitů;
• pokusíme-li se dělit (v celočíselné aritmetice) nulou, ať již jde o klasické dělení (/) nebo získání zbytku (%), PowerPC vrátí nulu; Intel "shodí" proces (uznávám, v tomto případě je Intelovské řešení patrně korektnější ☺);
• vzájemně porovnávat neceločíselné hodnoty je vždy nebezpečné (vinou zaokrouhlovacích chyb a binárního kódování se snadno může stát, že 0.2 se liší od 0.2 ☺). Pokud to někdo přesto dělá a má štěstí, že to na PowerPC náhodou funguje, pak jeho štěstí skončí s příchodem Intelu: oba procesory zpracovávají neceločíselné hodnoty trochu jinak, takže jejich porovnání funguje také odlišně.

Zprávy posílané nil

Víme, že můžeme v Objective C bezpečně posílat zprávy příjemci, jehož hodnota je nil, pokud je návratová hodnota zprávy nevyužita, nebo pokud je to id či celočíselná hodnota. To samozřejmě platí nadále bez problémů na PowerPC i na Intelu.

Dokumentace Apple varuje, že se runtime pro PowerPC a pro Intel chová odlišně v případě, že návratová hodnota zprávy je float či double. To je ovšem v pořádku, neboť v takovémto případě nebylo posílání zpráv příjemci nil korektní nikdy ☺.

A to je vše!

Mezi architekturami PowerPC a x86 samozřejmě jsou i další rozdíly (nejvýznamnější patrně bude ten, že x86 nabízí jen velmi ubohou náhradu Velocity Engine, a liší se také některé typy, jež Objective C neužívá, např. bool); ty už ale z hlediska programování v Cocoa nehrají roli.