WarpUp your PowerUp?

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?

Vytlačiť článok

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

AMIGA REVIEW

ATLANTIDA NEWS