Již v minulém čísle AMIGA Review jste se mohli seznámit s tak dlouho očekávanými kartami od Phase5, které, kromě radosti uživatelů z poměrně slušného výkonu, přinesly sebou i řadu otázek, živých diskusí, ale bohužel i hádek a vzájemného osočování ze strany vývojářů různých firem. A protože se zdají z hardwarového hlediska být PowerUp karty zcela v pořádku, je zřejmé, že konflikt se týkal softwaru, dodávaného k těmto kartám.
Před tím, než se pustím do dané látky, dovolte ještě několik komentářů.
Připadám si totiž úplně stejně, jako když jsem psal článek o výstavě v Kolíně -
spousta různého materiálu na stole, nesouvislého, vzájemně se tématicky
překrývajícího, ale co je ještě horší, a proč zde tuto paralelu uvádím, je fakt,
že „opět nejsem přítomen.“ Chci tím jen říct, že přestože se věnuji
programování, nemám téměř žádné zkušenosti s nižšími jazyky typu assembler či C,
takže prosím o jistou shovívavost ze strany „skutečných“ programátorů. Co se
týče hardwaru jsem na tom samozřejmě podobně.
Takže co že se to vlastně přihodilo? Co znamená první slovo nadpisu? Nebojte se,
všechno se postupně dozvíte, ale musíme začít hezky popořádku a neslušné by bylo
hned na úvod vynechat vlastního výrobce PowerUp karet, společnost Phase5, u
které se chvíli zdržíme....
Phase5
Abych pravdu řekl, mé zkušenosti s Phase5 nejsou velké, ale zato ani příliš
růžové. Nemám nic proti jejich produktům, to ne, koneckonců jsem spokojeným
uživatelem turbokarty Blizzard. Jedná se mi však o přístup této společnosti k
uživatelské základně, popřípadě konkurenčním firmám. Neschopnost navenek
komunikovat, arogance vůči okolnímu světu, téměř pravidelné značné zpoždění
vydání ohlášených produktů, to vše jsou rysy vlastní Phase5. A protože zde nyní
hodlám použít materiály nacházející se na jejich webovské stránce, rád bych
upozornil, abyste je brali střízlivě. Osobně totiž Phase5 neodpustím článek
„Breaking through the barriers“, který s nejčistším svědomím zveřejnila na své
stránce, a který byl pro mě zatím tou největší kachnou, na kterou jsem kdy
naletěl. Ted se však vraťme k vlastním materiálům, protože ty mnohým z nás
přinejmenším názorně přiblíží, jak vlastně karty PowerUp fungují.
Multiprocessing
PowerUp karty a jejich systémový software byly od samého počátku návrhu
vytvářeny s ohledem na schopnosti multiprocessingu. Jsme přesvědčeni, že každý
pokročilý a progresivní OS musí v sobě obsahovat podporu multiprocessingu. A tak
jsme se zaměřili hlavně na tuto oblast.
Již současné PowerUp karty používají oba procesory po vzoru paralelního
multiprocessingu. Ačkoliv oba procesory dynamicky sdílí tutéž sběrnici, je pro
oba zaručen dostatečný přístup do paměti, protože maximální propustnost paměti
je odhadem 200 MB/sec. Dynamické přidělování (alokace) sběrnice znamená, že
pokud kterýkoliv z procesorů požádá o nepřerušený přístup do paměti, má
garantovány čtyři burst cykly přístupu; pokud jeden z procesorů nepotřebuje
momentálně s pamětí pracovat, jsou tyto cykly přiděleny procesoru druhému.
(Pozn.: burst = 4 cyklový přístup do paměti. burst 060: 4^32=16 bajtů, burst
PPC: 4^64=32 bajtů) Logické analyzátory při testech prokázaly, že dokonce při
velké současné zátěži obou procesorů, tyto velmi často uvolňují sběrnici, což
umožňuje připojení i jiných zařízení jako SCSI DMA nebo dalšího CPU. Výpočty
Mandelbrotových množin nebo dekódování MPEG signálu vyžaduje, aby PPC odečítal
velké množství dat pomocí burst přístupů, přičemž během výpočtů zbývá dost času
na to, aby mohla být sběrnice uvolněna pro jiné účely. Tato doba se pak využívá
například pro práci s 68K procesorem, který mezitím může zpracovávat jiné úlohy,
jako jsou například systémová volání, příprava dat pro další PPC task, nebo
zpracování dat navrácených od samotného PPC procesoru.
Abyste však dosáhli maximálního možného výkonu multiprocessingu, musí se
software přizpůsobit hardwarovému řešení. Použitím systému zasílání zpráv
(message system) připraveného pro multiprocessing je možné přidat další
procesor, ale i například speciální GL 3D procesory nebo DSP, nebo mít dokonce
cluster síťových systémů pracujících na jedné konkrétní úloze. Aplikace
používající PowerUp software jsou na toto vše připraveny bez dalších nebo jen s
malými změnami.
Návrh koncepce pro multiprocesorovou PowerUp kartu, která by měla být na trhu
ještě v roce 1998 je již hotov. Tento PowerUp systém bude mít jeden 68040 nebo
68060 procesor, čtyři PPC604e procesory taktované na 200 - 400 MHz a bude rovněž
obsahovat 128 bitové SDRAM. Tento systém, vybavený čtyřmi PPC604e/300 MHz
procesory bude stát přibližně 3 500 - 4 000 USD a dosahovat výkonu přibližně 40
- 50 SpecFP95, což posune 3D aplikace na absolutní úroveň pracovních stanic.
Každá aplikace vyvíjená podle našich doporučení bude ihned schopna využít
možnosti této nové karty. Předpokládáme, že bychom mohli tuto kartu dodat v létě
1998 a již jsme rovněž kontaktovali dodavatele 3D softwaru, kteří se o toto
řešení velmi zajímali.
Udržujeme kontakt s různými výrobci procesorů, a protože jsme podepsali NDA
(pozn.: protokol o nešíření informací), máme přístup k mnoha informacím, takže
považujeme za nutné, aby začal vznikat software připravený pro multiprocessing.
Message system
PowerUp software pracuje na bázi asynchronního systému zasílání zpráv, který
umožňuje zasílat signály a data mezi různými úlohami a nezávisí na tom, na
kterém procesoru daná úloha běží. Tento message systém umožňuje velmi rychlou
výměnu dat mezi různými softwarovými moduly (tasky nebo thready) bez nutnosti
kontextového přepnutí, i když tyto moduly běží na odlišných CPU. Aplikaci je
lhostejné, kolik CPU se nachází v lokálním systému, nebo zdali jsou tyto CPU
přítomny na lokální síti, a dokonce jakého typu dané CPU jsou.
Tento message systém je schopen přenášet signály bez dat za méně než 7
mikrosekund. Přenos uživatelských dat je rovněž velmi rychlý, protože během
přenosu zprávy mezi dvěma úlohami běžícími na dvou odlišných procesorech musí
být z cache procesorů uvolněna pouze přenášená data.
Použitím speciálního message serveru je každá aplikace transparentně připravena
využívat možnosti ochrany paměti, pokud tuto budoucí operační systém nabídne.
Tento server se postará o to, aby k jistým datovým strukturám dostaly přístup
pouze úlohy s příslušným oprávněním. Pokud dojde ke změně operačního systému,
stačí pouze instalovat nový message server bez nutnosti dílčích zásahů do
aplikace.
Současná verze PowerUp vyžaduje méně než 60 milisekund pro přenos 1000 zpráv
včetně 20 - 30 bajtů uživatelských dat, 1000 odezev vyžaduje dalších 7
milisekund. Výsledkem je tedy méně než 70 mikrosekund pro zaslání zprávy včetně
přenosu dat a obdržení odezvy na danou zprávu mezi dvěma thready běžícími na
rozdílných CPU, zatímco tyto CPU pracují stále paralelně.
Doporučení týkající se implementace PPC softwaru pro PowerUp
Aby bylo dosaženo optimálního výkonu, doporučujeme programy modularizovat
použitím subtasků (podúloh), kterým klidně můžeme říkat thready, protože náš
přístup je ekvivalentní skutečnému multithreadingu. Mechanismus multithreadingu
implementovaný v PowerUp softwaru je již připraven pro ochranu paměti, a jakmile
tato bude implementována do OS, aplikace používající PowerUp software budou
automaticky tuto vlastnost využívat.
Programátor si může pro každý thread stanovit, který procesor bude používat.
Vzájemná komunikace je přitom zajištěna asynchronním message systémem. Výhodným
postupem například je vytvořit hlavní task na straně 68K, který například v
současné verzi PowerUp využíváme ke spouštění programu ovládajícího uživatelské
rozhraní a všechna volání OS. Tento hlavní task pak vytváří thready potřebné pro
nejrůznější účely. Asynchronní souborové I/O operace mohou být například
implementovány jako thread na straně 68K, zatímco pro účely různých filtrů pro
24 bitovou grafiku můžeme využít PPC. V našem případě hlavní 68K thread posílá
signál PPC threadu a poté může pokračovat v práci na uživatelském vstupu. PPC
thread pošle zpět signál o ukončení aplikace filtrů a 68K thread pak může
pokračovat ve zpracování takto obdržených výsledků, například kopírováním
grafických dat do oblasti výstupu cílového okna. Samozřejmě, že námi vytvořené
subthready mohou navzájem komunikovat bez intervence rodičovských threadů.
Tato implementace umožňuje jakékoliv aplikaci automaticky využívat
multiprocesorová řešení. Pokud například hlavní thread přikáže subthreadu
pracovat na zpracovávání obrázku po dobu 30 sekund, uživatel nemusí čekat, až
zmizí busy pointer, ale může pokračovat v práci. Navíc si programátor může od
systému vyžádat informaci o počtu dostupných procesorů a následně využít této
informace k vytvoření více identických subthreadů, které jsou PowerUp softwarem
navigovány na různé CPU a všechny vykonávají příslušnou část požadované operace.
To umožňuje programátorům již dnes vytvářet software, který je připraven pro
multitasking, multithreading a multiprocessing.
Toto řešení společně s vlastností multiprocessingu však sebou přináší i možnost
implementace jiných hardwarových řešení, jako například 3D nebo DSP karty na
bázi Zorro III sběrnice. Tato zařízení však mohou pracovat například i na
lokální síti. Vše co potřebujete je definovat message port včetně jeho datové
struktury. Dodavatelé takovýchto hardwarových řešení potřebují pouze znát jméno
message portu, sadu funkcí a typ příslušných zpráv.
ELF formát
Pro PowerUp systém byl zvolen ELF formát jako hlavní formát spustitelných
souborů. Prohlášení, že by tento formát mohl vést vývoj platformy pryč od
principů Amigy, jsou falešná, což dokazuje současná implementace GNU C a SAS -
C.
Pravdou však je, že použití tohoto nového formátu vyžaduje poněkud odlišné a
nové způsoby vývoje. Pravdou již však není, že použitím ELF formátu jako
hlavního linkovacího formátu jsou opouštěny hlavní myšlenky Amigy. ELF formát
například umožňuje použití sdílených knihoven. Navíc je PowerUp software
připraven rovněž pro použití tzv. Mixed Binaries. Není proto potřeba generovat
Mixed Binaries, Fat Binaries (pozn.: termíny vysvětleny později v textu), ani
znovu zavádět programy slinkované ve formátu ELF do paměti. Záleží pouze na
vývojáři aplikace, pro které řešení se rozhodne ...
Tolik tedy k poměrně obsáhlým materiálům zveřejněným na webovské stránce Phase5.
Jistě mnohé z čtenářů nyní napadne otázka, co že je na těchto materiálech
vlastně podivného, ba naopak, pokud vše bude fungovat tak, jak je zde popsáno,
má Amiga pro budoucnost se všemi příznačnými „multi“ vystaráno. Řekněme rovnou -
měla by, protože by to nebyla Amiga, kdyby nenastaly jisté „potíže“. Koncem září
minulého roku se totiž na stránce společnosti Haage & Partner objevily materiály
oznamující dokončení vývoje nového kernelu pro PowerUp karty. Dejme nyní tedy
slovo společnosti Haage & Partner...
Haage & Partner
WarpUp - the real speed is warp speed!
Jako vývojáři vývojového prostředí StormC jsme si vždy kladli za cíl
podporovat všechny významné novinky v oblasti vývoje Amigy. Naší filozofií vždy
bylo poskytnout vývojáři nástroj, který mu umožní dosáhnout nejlepších možných
výsledků s čím jak nejmenším vynaloženým úsilím.
Nejdůležitější stránkou hardwaru pro vývojáře je softwarové řešení, které mu
zaručí, že při dílčích změnách hardwaru nebude muset své produkty těmto řešením
vždy znovu přizpůsobovat. Přesně tuto funkčnost nabízí WarpOS, který byl pro
PowerUp karty vyvinut našimi autory, jimiž jsou - Sam Jordan, Michael Rock a
Jochen Becher.
WarpUp je založen na principu tzv. HAL (Hardware Abstraction Layer - vrstva
abstrahující hardware). HAL zajišťuje správnou činnost aplikací na různých
PowerPC konceptech.
Díky WarpUp je pro Amigu poprvé k dispozici možnost provozování nativních
PowerPC aplikací, ale rovněž aplikací a sdílených knihoven ve formátu mixed a
fat binaries.
Vývojový systém StormC C/C++ umožňuje jednoduše zkompilovat aplikaci do
nativního PowerPC módu pouhým přednastavením vlastností pro kompilátor. Velkou
výhodou pro vývojáře softwaru je, že potřebné přepínání se mezi 68K AmigaOS a
PowerPC funkcemi zajišťuje WarpOS kernel ve WarpUp, a tak i přímým portem
aplikace dosáhneme přijatelného zvýšení výkonu. Koncepční změny v aplikacích
jsou nutné, pouze když nějaká její část bude volat nesystémové funkce.
WarpUp nabízí následující výhody:
- Vysoce výkonné komunikační rozhraní mezi 68K a PowerPC procesory.
- Nativní multitasking, nativní správa paměti, semafory, lisdtag management,
signály, zpracování zpráv.
- Volitelná ochrana paměti: taskům je dána možnost alokace chráněné oblasti
paměti.
- Virtuální signály: ty jsou sdíleny mezi procesory a vždy přesměrovány na
správný CPU.
- Meziprocesorový message systém: mezi procesory je možno zasílat zprávy.
- Optimální využití PPC MMU a PPC cache.
- Podpora MMU a zpracování výjimek pro aplikace.
- PowerSave funkce, která suspenduje PPC, pokud jej žádná aplikace nepoužívá.
- PowerPC Enforcer - chrání první stránku
- Detailní crash-requester, který optimálním způsobem napomáhá vývojáři najít
chyby.
- Integrovaný debugging systém.
- Speciální podpora pro vysoce optimalizovaný software jako jsou hry a dema.
- PowerPC nativní, mixed a fat binary aplikace a sdílené knihovny.
- Použitelné rovněž pro jiné vývojové systémy jako Modula nebo E s PowerPC
podporou, protože objekty nejsou vytvořeny v ELF formátu. Namísto toho je zde
implementován odzkoušený Amiga hunk formát.
- Snadná instalace.
- Nezávislý na hardwaru.
- Optimální vyhlídky pro budoucnost.
- WarpUp je k dispozici zdarma
Jistě si umíte představit, jak se asi tvářila Phase5, když zjistila, že jim
hrozí ztráta kontroly nad vlastním hardwarem. A skutečně - netrvalo dlouho a na
stránce Phase5 se objevil článek s až příliš emotivním názvem „Warning, hackers
kernel!“. Nerad bych zde Phase5 nějakým způsobem svými názory poškodil, ale
musím říct, že článek byl moc i na mě, zvláště když v závěru Phase5 arogantně
ujišťuje společnost Haage & Partner, že jejich software nebude zaručeně při
jejich dalších hardwarových úpravách PowerUp karet funkční. Nemohou se pozbavit
dojmu, že jde o čistý záměr a nějak nápadně mi to připomíná reakce Phase5 na
oznámení společnosti ProDAD, jež chtěla portovat p-OS na ABOX. „Unixovské“
pokusy Phase5 ala ELF formát mi připadají jasnou snahou přetáhnout později
„nenápadně“ uživatele PowerUp karet k ABOXu. Koneckonců se k tomu nakonec Wolf
Dietrich (CEO Phase5) také doznává, ale buďme objektivní a přiznejme si, že
každá společnost má právo si hájit své zájmy. Ale pak má také čtenář časopisu
věnovaného Amize o těchto „zaječích“ úmyslech vědět - proto to zde říkám.
Dokonce jsem na několika místech na Internetu četl názory, že ELF formát je
výhodný proto, že klidně můžete své programy vyvíjet na jiných Unixových
platformách podporujících tento binární formát. Podle informací, které jsem
nelenil o tomto formátu vyhledat, je to pravda asi tak, jak si můžete spustit na
vaší Amize řekněme nějaký .exe soubor z PC, snad jen proto, že má stejnou
příponu. No nemůžete. Existuje zde jistá teoretická možnost a údajně se také na
některých verzích Unixu používá, ale nejsem si jist výhodami takovéhoto vývoje.
Pokud náhodou nějaký opravdový programátor kroutí nevěřícně nad mými názory
hlavou a říká si, : „Co to tady zase mele ...“, za prvé zrovna piji skvělý čaj
značky Earl Grey a za druhé vás mohu ujistit, že na konci tohoto článku vše za
mě napraví člověk na slovo vzatý, bývalý vývojář bývalé AT, nyní programátor na
volné noze, pracující na OS 3.5 - Olaf Barthel.
Vraťme se však k tématu. Na rozdíl od společnosti ProDAD si u Haage & Partner
nenechali všechno líbit a zveřejnili na Internetu celou historii „spolupráce“ s
Phase5. Protože Phase5 tuto výzvu nijak výrazně nekomentovala a navíc se v textu
vyskytuje i několik zajímavých technických detailů, budu se snažit vybrat z
obsáhlého materiálu všechny zajímavé pasáže.
Ring volný - lets fight ...
Haage & Partner x Phase5
Na výstavě Computer 95 v Kolíně oznámila AT nové modely Amigy založené na
procesoru PowerPC. Phase5 rovněž zde oznámila vývoj vlastních PowerPC karet. To
nás přimělo k rozhodnutí, že své aktivity zaměříme z hlediska budoucnosti právě
na tuto platformu.
Vývoj StormC pro PowerPC začal někdy v březnu 1996, ihned po CeBitu. Nastínili
jsme si hlavní koncepty vývoje, abychom se ujistili, že se příliš nevzdalujeme
hlavním rysům AmigaOS. Z tohoto důvodu jsme nikdy ani nepřemýšleli o možném
použití jiného binárního formátu, navíc bez oficiálního rozhodnutí vlastníka
práv AmigaOS. Nakonec se Amiga dostala opět do finančních potíží a situaci se
nezdál vyřešit ani na scénu vstupující VisCorp. My jsme však pokračovali v
práci, protože naše řešení nijak nenabourávalo koncept existujícího OS.
Když Phase5 oznámila, že se rozhodli pro duální procesorové karty, stalo se
nutností, aby naše softwarové řešení podporovalo tzv. Mixed Binaries. Takovýto
typ programu obsahuje 68K i PPC kód v jednom a tomtéž programu. Z hlediska
programátora je zcela lhostejné, která část programuje obsažena v kterém kódu.
Přístup k datům (např. globálním proměnným) je umožněn oběma procesorům a
přepínání mezi procesory se děje plně automaticky, bez nutnosti dalšího
programování. Vše co musí vývojář udělat, je se rozhodnout, která část programu
poběží na PPC a která zůstane na straně 68K. Zde skutečně nezáleží na tom, zdali
se jisté části kódu těsně překrývají. Používáme například společné proměnné a
datové struktury, návratové skoky z jedné části do druhé se dějí skrze tzv.
ukazatele funkcí, atd.
K našemu velkému překvapení se Phase5 rozhodla pro podporu formátu ELF, který
činí generování potřebných Mixed binárních souborů, doporučovaných dokonce
vlastní Phase5, skutečným problémem:
- PPC část programu musí být nahrána manuálně.
- Neumožňuje procesorům sdílet globální proměnné.
- Datové struktury jsou současnými 68K kompilátory interpretovány jinak než
použitím GNU C pro PPC, takže nemohou být sdíleny mezi procesory.
- Návratové skoky skrze ukazatele funkcí a dokonce „běžné“ přepínání mezi
procesory musí být programováno manuálně.
Po téměř 18 měsících vývoje nabízí WarpOS a StormC optimální způsob jak vytvářet
Mixed Binaries. Vývojář si jednoduše zvolí, který z programových modulů by měl
být zkompilován pro který procesor, v nejhorším případě ještě může daný modul
přerozdělit na samostatné moduly a pak již jen stačí program zkompilovat a máme
na světě PowerPC aplikaci. StormC a Storm Link se postarají o zbytek. Díky
sdílenému přístupu ke globálním proměnným a kompatibilní interpretaci datových
struktur nemusí být při této operaci změněn jediný řádek kódu. Kontextové
přepínání mezi procesory se děje zcela automaticky, programátor ani nemusí
vědět, kdy k těmto přepínáním dochází.
V polovině října 96 jsme konečně od Phase5 obdrželi dvě vývojářské verze PowerUp
karet, s jen strohým programovým vybavením. Nicméně již tehdy bylo jasné, že
jsou naše řešení principiálně odlišná a že se tedy musíme vydat vlastní cestou.
Tehdy ještě Phase5 nijak naše řešení nekomentovala.
První výsledky své práce jsme předvedli na výstavě Computer 96. Byly založené na
standardním Amiga hunk formátu a fungovaly bezchybně. V praxi se však ukázalo,
že výkon nebyl tak velký, jak jsme původně očekávali. Pro každé volání funkce
systému je nezbytné provést kontextové přepnutí na stranu 68K procesoru, vykonat
tuto funkci a přepnout se zpět na PPC procesor pomocí dalšího kontextového
přepnutí. Po každém takovémto přepnutí je samozřejmě nutné vyčistit cache, což
samozřejmě zabere nějaký čas. Podle našeho mínění bylo možné toto kontextové
přepínání urychlit hardwarovou úpravou, vlastně nás překvapilo, že to Phase5
neudělala (pozn.: pozor, nemusí již platit, jedná se o rok 96). Požádali jsme
tehdy Phase5 o dodatečné informace o hardwaru, ale byli jsme odmítnutí s tím, že
se ještě může hardware kdykoliv dodatečně změnit, a tak by naše softwarové
řešení stejně nefungovalo. Pro nás, jako softwarové vývojáře to byla velmi
znepokojující odpověď, která jasně dávala najevo, že Phase5 si chce udržet své
monopolní postavení také na straně softwaru pro PowerUp, držet tím konkurenci
stranou, a tak se ani nedivíme výpadům Phase5 vůči WarpUp.
Byl prosinec 96 a náš vývojový tým přišel s řešením, které drasticky urychlilo
kontextové přepínání oproti vlastnímu řešení Phase5. Bylo to 0.5 milisekund
oproti 60-90 milisekundám softwaru Phase5 (pozn.: již neplatí).
Na „Magických Dnech“ v Trieru v dubnu 97 jsme předvedli naše první dema a měli
několik přednášek na téma programování pro PowerUp. Na této show jsme rovněž
hovořili s Wolfem Dietrichem a Geraldem Cardou z Phase5 a vyzvali je k veřejné
diskusi o možném objektovém formátu a koncepci rozhraní pro PowerUp. Tato
myšlenka však byla odmítnuta se slovy: „My jsme se to rozhodli udělat tímto
způsobem a tak to taky bude. Nebudeme o tom diskutovat!“
Těsně po výstavě jsme asi po více než třech měsících obdrželi novější verzi
PPC.library. Jak se dalo očekávat, náš software nefungoval. Změny v koncepci
byly tak zásadní, že dokonce co se zdálo být pro Phase5 před několika měsíci
zcela legálním přístupem, již bylo nyní nepoužitelné.
Abychom zabránili dalším nekompatibilitám se softwarem Phase5, sepsali jsme
seznam požadavků, které by zajistily přístup k PPC.library Amize vlastním
způsobem a společně s Phase5 tak definovali standardní rozhraní pro PPC.library.
Tento seznam byl prodiskutován s Geraldem Cardou, ale zůstalo pouze u slov. Když
jsme Phase5 předvedli své vlastní řešení, byli překvapeni, jak se našim
programátorům povedlo nastřádat potřebné znalosti o PPC.
Asi po čtyřech týdnech jsme obdrželi novou verzi PPC.library, která obsahovala
řadu vlastností, které jsme předvedli Phase5 ve vlastním řešení. Samozřejmě i
tato knihovna byla opět s naším řešením nekompatibilní, což nás už však v
případě Phase5 více nepřekvapuje. Díky neustálé ignoraci ze strany Phase5 jsme
neměli jinou možnost než vytvořit vlastní PPC.library. Tato knihovna byla
dokončena 5. června 97. To však neznamená, že bychom nebyli nadále ochotni s
Phase5 spolupracovat. Až do tohoto data jsme se pořád snažili být kompatibilní s
řešením Phase5, tak, aby to bylo pro ně přijatelné. Do tohoto data jsme rovněž
obdrželi další dvě nové verze PPC.library, každá z nich však opakovaně s naším
softwarem odmítala pracovat. A tak jsme znovu a znovu museli upravovat svůj
software a obejít tak chyby v programování Phase5.
Nemůžeme se zde nezmínit o změnách, které Phase5 v této knihovně udělala koncem
července. Jak všichni víme, PowerUp karty měly být k dispozic již koncem června.
Termín uvedení karet na trh se však neustále opožďoval. Koncem července Phase5
vydala další verzi knihovny, kdy bylo nutné překompilovat všechen software
vytvořený v ELF formátu. Toto jsme opravdu nepochopili, protože karty měly být
na trhu již před měsícem. Mimochodem změny, ke kterým zde došlo, nijak
neovlivnily software vytvořený ve StormC. Museli jsme pouze překompilovat velmi
malou část naší kompatibilní knihovny.
Poslední verzi PPC.library jsme obdrželi přímo s oficiální PowerUp kartou.
Dodávka rovněž zahrnovala první dokumentaci „revolučního“ message systému,
hotového tak sotva z poloviny.
Vývojáři, kteří se rozhodnou vyvíjet pro PowerUp karty za pomocí softwaru Phase5
by si měli být vědomi skutečnosti, že jimi vytvořený software s velkou
pravděpodobností nepoběží na PowerPC hardwarových řešeních jiných firem.
Prohlášení Phase5 o hackerském kernelu nanejvýš ukazují jejich strach z
potencionální konkurence.
Jako paralelu, co se přihodilo, Vám můžeme uvést příklad společnosti ProDAD,
kterou Phase5 odmítla podporovat zhruba před rokem. Phase5 Vám může namítat, že
rovněž ProDAD obdržel vývojářskou verzi PowerUP. Co vám již však Phase5 nepřizná
je fakt, že nikdy žádné společnosti neposkytla hardwarové specifikace, jaksi
nutné k tomu, abyste nad daným hardwarovým řešením mohli vyvíjet operační
systém.
Možná řešení
Z hlediska uživatele nemají tyto diskuse větší význam. Ale my jako
softwarová společnost nemáme ani dostatek času ani prostředků vytvářet nová
softwarová řešení pro každou nově příchozí Amiga platformu. Z tohoto důvodu by
bylo dobré ustanovit nezávislé konsorcium, které by stanovilo nezbytné
standardy. Pokud by se toto konsorcium rozhodlo pro ELF formát, mohli bychom se
přizpůsobit tomuto řešení. Máme ale obavu, že Phase5 si zvolila ELF formát jen
proto, aby si připravila uživatelskou základnu pro ABOX. Mluvit přitom o
průmyslových standardech a seznamu vývojových systémů, které by mohly být
použity na jiných a nákladnějších platformách nepovažujeme za věcné. Podle
našeho názoru by vývoj softwaru pro Amigu měl probíhat na Amize.
Prohlášení Phase5, že jsme vytvořili WarpUp jen proto, aby vývojáři
upřednostňovali StormC jsou falešná! Každý vývojář kompilátoru má možnost tento
přepsat pro PowerPC. Takovýto kompilátor může klidně pracovat dále s Amiga hunk
formátem, tak jak tomu bylo doposud. A protože PowerPC.library (pozn.: náhrada
PPC.library Phase5) je 100% kompatibilní sdílenou knihovnou Amigy, může ji
používat každý. Je dokonce možné použít rozdílné kompilátory pro stranu 68K a
PPC procesoru a vytvořit tak jeden binární soubor typu Mixed Binary. Rádi
pomůžeme kterékoliv společnosti portovat jejich kompilátor pro PowerPC procesor.
Tolik tedy vyčerpávající informace od společnosti Haage & Partner. Nějak se nám
to zamotává, viďte? Ujišťuji vás, že to zdaleka není všechno.
Phase5 x Microcode Solutions
Microcode Solutions zřejmě všichni dobře znáte díky emulátorům Pcx a Fusion.
A tak je také jasné, že pokud chtějí pánové přenést svůj software na platformu
PowerPC, musí se dostat do kontaktu s PowerUP a tedy i s vlastní Phase5.
Nešťastné to setkání.
Nebyl jsem přítomen v diskusní skupině Picasso96, kde údajně vše začalo, vím jen
zhruba, že se Ralph Schmidth z Phase5 ohradil proti výpadům Jima Drew vůči této
společnosti. Vše začalo údajně tak, že Jim Drew požádal Phase5 o bezplatné
zaslání vývojářské karty, protože prý má v rukávu něco převratného. Ve
skutečnosti se jednalo o odstranění chyby přerušení, kterou však později Phase5
ve svém softwaru odstranila také. Drew si stěžoval na typické nedostatky Phase5,
jako je neschopnost odpovídat na dotazy, natož možnost komunikace, a to přestože
má Microcode Solutions registraci na úrovni Copper. Vše se vyhrotilo tak, že
Drew požádal svého kolegu Joye Fentona, aby to s Ralphem Schmidthem vyřídil,
protože se už s ním více nemíní bavit.
Nejprve následuje výměna kousků zdrojových kódů, aby si pánové navzájem
dokázali, kdo z nich je více v obraze, načež to přestane bavit i Fentona a ten
vydává závěrečné stanovisko (pozn.: opět pozor, říjen 97):
OK, nyní se podívejme na „vývojový systém“ Phase5!
PowerUp karta nám byla dodána s jedním 800K floppy diskem a „lite“ verzí GNU,
která by měla produkovat PPC ELF soubory. Tohle je tedy něco. Stroze napsaná
dokumentace doporučuje, že k tomu, abyste dostali funkční kompilátor, musíte si
stáhnout celou sadu ADE GNU někde z webu.
Tento balík prostě nechápe nic o Amize - žádné struktury, prostě nic! Jakýkoliv
PPC kód musí být kompletně neutrální a jakýkoliv pro Amigu specifický kód musí
být odstraněn nebo překódován. Lehce se dalo zjistit, že všechny přibalené
rutiny jsou použitelné pro kterýkoliv jiný systém. Nenajdete zde žádnou aplikaci
„kompletně“ napsanou pro PPC s použitím softwaru Phase5, prostě protože je to
příliš mnoho práce. Všechno co uvidíte jsou plug-in moduly pro 68K programy.
GNU v žádném případě není profesionální vývojový systém! Ten kdo tvrdí opak, by
si měl vyzkoušet CodeWarrior a pak zkusit pracovat s GNU. Ale asi čekám od
někoho jako je Phase5 příliš.
A když tady konečně máme Amigácký vývojový systém a ne nějaké kusy posbíraného
freewarového smetí, všechno co umí Phase5 udělat je, že Vás ujistí, že jejich
příští řešení učiní to Vaše nekompatibilní.
Já nestojím o to, dát svoji vyzkoušenou a skutečnou Amigu všanc nějakému
unix-wanna-be boxu.
Jako perličku na závěr si Fenton připravil petici, která měla být zaslána
Phase5, aby natrvalo vyklidili pole působnosti v oblasti softwaru. Nemáte pocit,
že se nějak přestáváte v dané situaci orientovat? Nebo jste snad nyní nakloněni
více na stranu WarpUp? Nejásejte, ještě tady pro vás mám jedno „malé“ povídání
od Olafa Barthelse, kterého jsem se zeptal:
Který z formátů je pro AmigaOS vhodnější, ELF - používající sdílené knihovny,
nebo klasický Amigahunk formát?
Zdokonalený AmigaOS hunk formát má výhodu toho, že můžete vytvořit tzv. fat
binaries, to znamená, že kód který se nativně provádí na PowerPC a taktéž kód,
který se provádí na 68K procesoru, může být pohromadě v jednom souboru. Vývojáři
softwaru pak mohou distribuovat jednu aplikaci, namísto aplikací dvou. Avšak,
takovéto „tlusté“ binární soubory jsou přesně to, o čem vypovídá už jejich název
- rozsáhlé. Bude trvat delší dobu je zkopírovat a zavést do paměti. Na Macu,
který má rovněž možnost používat tento typ binárních souborů, vyvinuli dokonce
vývojáři speciální nástroje, které umí ze souboru odstranit nepotřebné části
kódu, aby tak ušetřili místo a urychlili proces nahrávání. Osobně mám jisté
pochybnosti o tom, zdali jsou fat binaries, skutečně dobrou myšlenkou. Pokud se
podíváme do historie, programy pro Amigu, jako je třeba „Imagine“, se vždy
dodávaly spíše ve dvou verzích (jedna čistě 68K, další pro 020 + FPU), než verzi
jedné. V dnešní době, kdy jsou hlavním distribučním médiem CD-ROM disky, není
větším problémem dodávat dvě samostatné aplikace a za pomocí instalačního
skriptu se rozhodnout, která z nich bude kopírována na náš systém, spíše než
jednu monolitickou aplikaci.
ELF je průmyslovým standardem na několika platformách. Tak například, Amiga Unix
(SV4R) by mohl používat ELF jako svůj nativní binární formát. Pokud se vrátím
zpět do doby AT, Motorola se snažila prosazovat vlastní xcoff binární formát,
protože téměř každý vývojový systém této společnosti tento formát podporoval
(další průmyslový standard; legrační kolik že jich to vlastně je). Takže když se
na to podíváte blíže, vývojový systém je to, co ovlivňuje volbu binárního
formátu. Pro Motorolu to byl xcoff formát, protože jejich kompilátory
produkovaly xcoff soubory, pro Phase5 to byl ELF, protože kompilátory a
nástroje, které si zvolili, produkovaly ELF soubory, no a pro Haage & Partner to
byl zdokonalený hunk formát, protože mohli jednoduše upravit svůj kompilátor a
linker tak, aby produkoval tento typ souborů. Nepochybuji o tom, že zde byl
jistý záměr zvolit ten či onen binární formát, ale podmínky v praxi mohou
diktovat hodně. Pokud bych byl ve stejné situaci jako Phase5, zvolil bych ELF -
technologie je stabilní a používá se několik let a je zde dostupný kvalitní
volně dostupný kompilátor, který tento typ souborů podporuje - GNU C. Phase5 se
jednoduše nemohla rozhodnout provést nějaké změny v kompilátoru, protože žádný
nevlastní, ale Haage & Partner ano.
Rovněž k tomu, abyste provedli nějaké změny do existujícího AmigaDOS hunk
formátu a abyste jej mohli posvětit jako standard, potřebovali byste svolení
vlastníka OS, který v současné době k není natolik kompetentní, aby rozhodl tak
závažnou záležitost. Když toto všechno zvážíme, byl ELF volbou, která
představovala to nejmenší riziko a pro softwarové inženýry je často tento pohled
zásadní.
Který z těchto formátů je tedy lepší? To záleží také na tom, jaký problém se
snažíte s tímto formátem vyřešit. Z mého pohledu slouží Amiga hunk formát pouze
jako logické rozšíření existující technologie Amigy a jeho jedinou výhodou je,
že umožňuje použití fat binárních souborů. A to není mnoho. ELF nabourává
existující filozofii AmigaOS asi ve stejné míře, jak to činí přechod na nový
procesor. Nevyžaduje žádné změny nebo rozšiřování existujících datových
struktur, a tak snižuje nebo odstraňuje nutnost kontroly správnosti takovýchto
změn. Je definitivně tím nejmenším a nejméně nákladným riskem. Já bych zvolil
ELF.
Trochu pitomá otázka od ne-Amiga programátora: Co je špatného na sdílených
knihovnách? Jaký je zde tedy rozdíl v použití oproti modelu AmigaOS?
Když používáte kompilovaný jazyk, binární soubory, které produkuje kompilátor
musí být zkombinovány do výsledného proveditelného kódu za pomocí nástroje,
kterému se říká linker. Statické linkery kombinují všechny objektové soubory a
knihovny v době finálního vytváření aplikace. U sdílených knihoven, jaké se
používají třeba v Unixu, je tento proces poněkud odlišný. Tam se program
slinkuje se sdílenými knihovnami, až je po jeho spuštění. Zřejmou výhodou je, že
můžete například nahradit knihovny, i když už je program vytvořen. Tyto sdílené
knihovny umožňují několika aplikacím sdílet programové sekce kódu knihovny,
zatímco každý program obdrží vlastní lokální kopii datové sekce knihovny. Takže
tyto sdílené knihovny nemusí být reentrantní a program a knihovna se stávají
jedním celkem.
U sdílených knihoven na Amize, tak jak je vytváří a spravuje exec.library, je
tomu jinak. Programová sekce kódu knihovny zde musí být reentrantní. Data
knihovny musí být read-only, nebo modifikována pouze uvnitř kritických regionů.
Programy, které používají tyto knihovny, je musí volat skrze tabulku skoků dané
knihovny a není zde žádný dodatečný linkovací proces, který by nějakým způsobem
umožnil dynamicky kombinovat vlastní program a knihovny funkcí, když už je
jednou aplikace zavedena do paměti.
Tím křehkým místem sdílených knihoven na Amize je právě ona tabulka skoků.
Velikost každého zápisu v takovéto tabulce je dána architekturou procesoru,
například velikostí instrukce skoku / nepodmíněného větvení. Na 68K procesoru,
zabírá takováto instrukce skoku šest bajtů a umožňuje adresaci kdekoliv uvnitř
32 bitového adresového prostoru. U PowerPC je však situace odlišná; každá
instrukce zde zabírá přesně čtyři bajty a neexistuje zde žádná instrukce pro
skok na specifickou adresu uvnitř 32/64 bitového adresního prostoru. Je zde
pouze instrukce pro nepodmíněné větvení (srovnatelná s BRA.W na 68K
procesorech), která umožňuje, aby provádění kódu pokračovalo na místě relativním
vzhledem k adrese dané instrukce. A přirozeně, toto je omezující faktor pro
velikost tabulky skoků, ale také pro velikost vlastní knihovny. Avšak na druhé
straně, mohou být obě tato řešení překonána rozumným návrhem rozhraní knihoven.
Osobně ve skutečnosti nevidím nic závadného na Amigáckých sdílených knihovnách.
Existují zde pouze jistá omezení z pohledu architektury procesoru, ale tomu se
dá předejít. Tento problém může být vyřešen, když pro to vyvstane konkrétní
potřeba. Avšak pokud jste v pozici jako Phase5, dává větší smysl použít
existující a ověřenou technologii, než investovat čas, úsilí a peníze do
přizpůsobování se jiné technologii, která vám zcela nesedí.
Wolf Dietrich se zmínil o dvou dalších společnostech, pracujících na PowerPC
řešeních, spolupracujících s Phase5. Společnosti „spolupracující“ s Phase5? Tomu
se dá těžko uvěřit...
Tak, a doufám, že jste tam, kde jsem vás chtěl dostat, totiž ve stádiu, kdy
každý z vás bude muset být soudcem i porotou sám za sebe. Pro další informace o
ELF formátu si můžete odskočit na
www.seznam.cz, do sekce
software/operační systémy/ a oddílu „školičky“, dle mého názoru nejlepšího
českého zdroje solidních informací o mnoha jazycích a formátech, se zaměřením
hlavně na Unix. Možná to ale také vůbec nebude zapotřebí. Na podnět několika
vývojářů nyní zahájila pod křídly ICOA činnost další z pracovních skupin,
věnujících se možnosti implementace různých binárních souborů do AmigaOS. Padly
zde zmínky o jistém SDE formátu, tzv. Slim binaries. Nevím sice dodnes o tomto
formátu nic konkrétního, snad jen kromě několika názorů, že pokud by se to
povedlo, měla by Amiga z hlediska technologií zase jistý náskok. Uvidíme. Pro
který formát bych se rozhodl já? To je jednoduché - použil bych formát ALF a
odletěl na Melmeck. Mají tam „rádi“ „kočky“ a nejí se tam špenát...
Long live the Amiga!
PS: děkuji za pomoc při diskusích o této ale i jiných záležitostech následujícím kolegům z IRC: Ivo Janáček, uF0, Shaman, NFW, Lopolo, DNA, Exie, Fatal, Sampl, Andrew, Alien, JayTee, Yan, Atlet, Moth. Zapomněl jsem na někoho, boyzzz?
Pozn.: články boli naskenované ako text a preto obsahujú aj zopár chýb. Taktiež neručíme za zdrojové kódy (Asm, C, Arexx, AmigaGuide, Html) a odkazy na web. Dúfame, že napriek tomu vám táto databáza dobre poslúži.
Žiadna časť nesmie byť reprodukovaná alebo inak šírená bez písomného povolenia vydavatela © ATLANTIDA Publishing