Delphi 64bit aneb nový kompilátor

vložil Radek Červinka 5. srpna 2010 23:09

S příchodem 64bit Windows se objevil i požadavek na 64 bit kompilátor Delphi, který byl až do příchodu Embarcadera na scénu ignorován.

32 a 64 bit

Nyní (polovina roku 2010) je nový kompilátor již třetím rokem vyvíjen s tím, že začátkem příštího roku bude k dispozici preview kompilátoru. Zkusím o něm (a příbuzných tématech) napsal pár poznámek.

Proč je vlastně v budoucnu nutný 64bit kompilátor?

V současné době se lze na platformě Windows setkat se dvěma typy 64 bit procesorů:

Itanium

Itanium od Intelu (neboli IA-64) je nyní chápán jako slepá větev. Bývá osazen prakticky jen v serverech (a navíc často jen od HP a navíc s HP-UX jako OS). V současné době ho i MS přestal podporovat, tj. nemá cenu se jím zabývat. Např. Visual Studio 2010 je poslední verzí s podporou Itanium (to se hlavně týká těch, kdo píší serverové aplikace pro .NET – jsem zvědav jak to budou v budoucnu řešit).

Ohledně 32bit aplikací - 32bit kód se provádí jen díky emulaci – tj. pomalu. Tento typ procesoru klidně můžeme ignorovat - v praxi se s ním pravděpodobně ani nesetkáme.

x86-64

Procesory s podporou x86-64, tj. 64bit rozšíření, které je plně zpětně kompatibilní s klasickou 32bit architekturou. Původně vytvořeno AMD (nyní pod obchodním názvem AMD64) jako odezva na Itanium, později akceptováno Intelem (prakticky bez výrazných změn pod názvem EM64T) nebo firmou VIA a dalšími. Značka x86-64 je používána jako neutrální název. Prakticky každý procesor nyní prodávaný je této architektury.

Důležité je, že 32 bit aplikace na této platformě běží beze ztráty rychlosti, často rychleji než na 32bit procesorech.

Tím je snad i vyjasněn běh 32bit programů na 64bit procesorech.

Příchod Windows 64bit

S příchodem Windows 64bit vzniká problém s během 32bit programů na této platformě. Pro bezproblémový běh 32bit aplikací na těchto nových Windows tak vznikl WOW64 (Windows on Windows) subsystém, který zprostředkovává rozhraní např. k 64bit jádru nebo přístup k registrům. V podstatě se jedná o lehkou vrstvu, která přístupy na určitá místa (některé části registru nebo souborového systému) přesměrovává jinam, přičemž lze ale přistoupit i na "opravdové místo" pokud člověk chce.

Obecně většina typů aplikací tj. konzolové, GUI i service aplikace jsou podporovány, viz. MSDN ohledně běhu 32bit procesů na 64bit Windows (zde jsou i informace o přesměrování registrů a souborového systému). Většina (dejme tomu 95% aplikací) se o to vůbec nemusí zajímat.

Ohledně rychlosti běhu 32bit aplikací na 64bit Windows via WoW64 - ve zkratce: běh na x86-64 procesorech je ekvivalentní běhu na 32bit procesorech (píši x86-64).

No, ale jak zjistit, že běžíme ve WoW64? Jednoduše zavoláme IsWow64Process, IsWow64Process pro Delphi.

Jaké jsou tedy nevýhody 32 bit programů ve Windows 64?

Základním problémem je, že 64bit proces může zavádět jen 64bit knihovny (neplatí pro resource DLL). To mimochodem znamená, že jelikož je Windows Shell takový proces, nelze psát jeho rozšíření (tj. např. integrace do průzkumníka). Částečně to lze obejít přes registry.

S tím souvisí, že pokud máte 64bit MS Office, tak 32bit rozšíření nepůjdou zavést (nejčastěji se to týká Outlooku). Naštěstí sám MS je zatím s doporučováním 64bit office opatrný, což dává EMBT určitý čas.

Ohledně IE (Internet Exploreru): v systému jsou dvě verze - jedna 32bit, jedna 64bit - kvůli tomu, že některé ActiveX jsou 32bit, tak se použije 32bit verze IE.

Dále může být problémem, pokud se chce Váš program hlouběji rýpat v systému, někdy to jde obejít, někdy ne.

Jaké jsou výhody 64bit programů proti 32bit programům

  • Bezproblémový běh na 64bit Windows a spolupráce s 64bit aplikacemi.
  • Větší adresový prostor. Normálně má 32bit process 2GB, pokud nastavíte PE flag IMAGE_FILE_LARGE_ADDRESS_AWARE, tak se situace trochu zlepší, ale definitivní řešení je 64bit ukazatel, kdy je adresní prostor prakticky neomezený.
  • V případě memory mapped souborů nejste limitováni velikostí 4GB (32bit integer).
  • V podstatě obecně žádné limity. Nevýhodou je o trošku větší paměťová náročnost.

Co dál?

Autoři si uvědomují, že nelze neustále upravovat stávající kompilátor. Z toho důvodu se dospělo k rozhodnutí upravit stávající kompilátor, tak aby byl více modulární. Jak to tedy je v současnosti a jak to vypadá do budoucnosti?

Stávající Delphi

Delphi samozřejmě není jen kompilátor, ale je to souhrn několik částí (kompilátor, linker, RTL, VCL a IDE).

Samotný kompilátor (a linker) je psaný v C - s tím, že se postupně upravuje na C++ (resp. to byl záměr – viz Barry Kelly na stackoverflow - velmi zajímavé). Mimochodem v tom dotazu Barry píše, že počet změněných nebo přidaných řádků proti nezměněným je cca 30% za rok, což je docela síla (při velikosti 300K řádků). S tím, že testy kompilátoru jsou budovány cca 20 let. Mimochodem třeba kompilátor FreePascalu je celý psán ve FreePascalu a je sám sebou přeložitelný.

Ale zpět: zbytek je psaný (tj. včetně IDE) v Delphi, resp. Object Pascalu.

V současnosti je výsledkem 32bit kód (jak pro Win32, Linux nebo Mac OSX) – o optimalizacích jsem něco psal, přičemž šablony generátoru (codegen) jsou ručně laděny pro dobré plánování instrukcí v moderních procesorech.

Zjednodušeně: kompilátor při kompilaci zpracuje vstupní .pas soubor a celý stav kompilátoru je uložen do souboru .dcu. Toto umožňuje kdykoliv příště načíst soubor z disku a pokračovat v kompilaci. Nevýhodou je, že dcu je závislé na verzi kompilátoru a prakticky s každou verzí se liší (snad vyjma D2006 a D2007). Výhodou je velmi rychlá kompilace, kdy se kompiluje jen co je třeba a zbytek je použit z předchozí kompilace bez velkého zdržení. Výsledek kompilace je předhozen linkeru.

Nový kompilátor Delphi

Následující informace jsou takové spíše střípky.

Kompilátor pro 64bit by měl být první instancí vylepšeného kompilátoru, s tím, že se kompilátor rozdělí na frontend kompilátoru (tj. asi parser a spol.), který zůstane stejný a backend (tj. codegen pro konkrétní procesor), který bude variabilní.

Sem tam prosakuje, že by nový kompilátor měl umět i nový dcu formát, který by nezávisel na verzi Delphi (tj. asi nějaký mezikód generovaný frontend částí). Všechno toto jsou tak spíše naznačované informace, uvidíme snad v první polovině roku 2011.

Ale zaujala mne odpověď David I v konferenci (tj. jednoho z nejvýše postavených lidí ve firmě):

|Yes, of course. I am just wondering whether EMBT think that x86 and
|x64 is all or whether they are planning on compilers for other
|architectures.

With a back end compiler architecture - we are not limited to just
Intel (x86, x64) only. It will be possible to plug in any number of
optimizers and code emitters - whether this work is done by Embarcadero
engineers, chip manufacturers or other engineers and community members.

Což zní velmi zajímavě – ale uvidíme.

S tím totiž možná souvisí i naznačovaní zvažované podpory ARM procesorů (což by bylo moc prima), ale není tak jednoduché, jelikož ARM má několik módu, kdy i třeba FPC podporuje jen základní a nepodporuje THUMB MODE; mně osobně to ale nevadilo, když jsem zkoušel programovat ve freepascalu pro Nintendo DS (mimochodem geniální HW na programování).

Určitě jsem na něco zapomněl, neváhejte mne doplnit x opravit v diskuzi.

Tagy: , , ,

Delphi

Komentáře

6.8.2010 10:21:19 #

pepak

Osobně si myslím, že celý WOW64 subsystém představuje to nejhorší ze všech možných řešení, jak spojit 32bitové aplikace s 64bitovým systémem, ale s tím už dneska nic nenaděláme a můžeme se jen přizpůsobit. Ani Delphi 64bit s tím nic nenadělají. Já akorát doufám, že Embarcadero k tomuhle dopuštění nepřidá tím, že zprasí datové typy. Článeček o celočíselných typech, který jsi napsal dříve, mě docela děsí (změna významu Integer a Longint a nekonzistentní chování NativeInt). Jako kdyby se nešlo poučit z minulosti, když ve verzi 2 přišly dlouhé stringy a uživatel si mohl vybrat, jaké chování ve své aplikaci preferuje...

A když už se rozděluje kompilátor na části - možná by už bylo na čase, zavést do Delphi aspoň základní preprocesor s podporou maker. (Případně i možnost mít přiřazení jako výraz, ale to už bych asi chtěl moc.)

pepak

6.8.2010 10:43:52 #

radekc

S tim NativeInt je to problem, bylo to pro delphi 2007 označeno jako chyba.

Delphi 64bit nemají s WoW64 nic do činění - WoW64 je pro 32bit aplikace

Jak by podle tebe tebe měla být velikost celočíselních typů pro 64bit? Podle mne určitě sizeof(NativeInt) = sizeof(Pointer) a u zbytku težko říct. Snad jen, že Longint by mohl podle mne být 8byte.

Třeba v C platí sizeof(short int) <=sizeof(int) <=sizeof(long int) .

radekc

6.8.2010 17:55:47 #

pepak

Velikost celočíselných typů bych chtěl vidět takovou, aby dodržovala stejná pravidla jako při přechodu z 16 bitů na 32: Integer je procesorově závislý o délce stejné jako velikost offsetu adresy (tedy to, co měl dělat NativeInt), Longint procesorově nezávislý o délce 32 bitů. Ostatní stejně velké, jako ve 32 bitech.

Uvědomuju si, že to je utopie, protože strašná spousta programů je napsaná blbě a navzdory historické zkušenosti očekává, že Integer má vždy stejnou velikost, místo aby na místech, kde na velikosti záleží, použila typ definovaný konkrétní velikostí.

pepak

6.8.2010 18:35:40 #

radekc

Nikdy a nikde nebude sizeof(integer) > sizeof(logint) - už z definice je LongInt větší než Integer , schválně jsem si to ještě ověřoval, třeba - http://en.wikipedia.org/wiki/Long_integer

long integer is a data type that can represent a whole number whose range is greater than or equal to that of a standard integer on the same machine

radekc

6.8.2010 19:15:19 #

pepak

Rozdíl mezi naším přístupem je, že já nevidím longint jako ekvivalent ani analogii k Cčkovému long int.

pepak

Komentování ukončeno

Naše nabídka

MVP
Ing. Radek Červinka - Embarcadero MVP
profil na linkedin, Twitter:@delphicz

Nabízím placené poradenství a konzultace v oblasti programování a vývoje SW.
Dále nabízíme i vývoj speciálního software na zakázku.

Neváhejte nás kontaktovat (i ohledně reklamy).

love Delphi

O Delphi.cz

Delphi je moderní RAD nástroj podporující tvorbu nativních aplikací pro platformu Win32, Win64, Mac OSX, Linux a na iPhone a Android.

Delphi.cz je nezávislý portál pro uživatele Delphi. Portál není koncipován pro úplné začátečníky, i když i ti se zde nebudou nudit, ale spíše na programátory, kteří již něco znají a chtějí své znalosti dále rozvíjet a sledovat novinky.

Poslední komentáře

Comment RSS

Dle měsíců