Oprócz 64 bitowych PowerPC dla desktopa i 64bit POWER dla serwerów. Ewentualnie SPARC i MIPS. Czy tak jak teraz ARM.

Nie musiało bo nie taki miała ta architektura target. W każdym razie w tamtym momencie. A później? Później też nie musieli wspierać x86 w Itanium, ważne było to by Itanium było konkurencyjne (czyt. oferowało więcej za podobną cenę, lub oferowało tyle samo za niższą). I jedyny karygodny błąd to był fakt, że IA64 nie oferowało niczego lepszego ... Innymi słowy zaprzepaścili całkowicie potencjał architektury wahając się między IA32 a IA64. A gdy AMD pokazało AMD64 i rozwiązanie stało się de facto standardem to już niewiele mieli do powiedzenia, a jednocześnie dogonić AMD w x86 oraz znacząco zmodernizować IA64 zwyczajnie nie potrafili (nie mieli środków). Amerykański team starał się w panice łatać Netbursta, a izraelski tworzył mobilki i zbawcę intela czyli Core 2. Skupić się na Itanium zwyczajnie nie było czasu.

Intelowi Itanium było potrzebne do tego, aby firmy przesiadły się z 32bit x86 na 64bit itanium, i ...... nie mieliby konkurencji.

na szczęście intel popełnił karygodny błąd, itanium nie oferowało trybu zgodności z 32bit x86, co uniemożliwiło miękką przesiadkę. o ile system operacyjny można dostosować bo to był albo HPUX, albo Windows server (o tak, był) albo linux, o tyle przepisanie tysięcy czy milionów aplikacji to już gruba robota.

ostatecznie to wszystko przekreśliło AMD, wypuszczając CPU x86 z rozszerzeniami 64bit, i plan monopolizacji rynku serwerowego legł w gruzach. x86 okazało się tańsze.

obecnie różne elementy architektury Itanium znajdują się w intelowych x86, także tych domowych

Pokaż mi moment w którym x86 zaczęło korzystać z rdzenia RISC No... nic nie jest tłumaczone na żadne RISC. Mikrooperacje są inherently RISC-like. Zawsze były. Czy to dla architektur RISC, VLIW czy CISC. Jedyne 100% pewne konstrukcje tłumaczące 'w locie' na inną architekturę to AMD K5 (wykorzystujące rdzeń z AM29000), Nx586 (tłumaczące na wewnętrzną architekturę nexgena, swoją drogą później wykorzystaną w AMD K6) oraz konstrukcje Transmeta (tutaj wewn. architekturą był VLIW). Cała reszta - nie ma żadnego, absolutnie żadnego dowodu, że rdzeń powstał na bazie RISC.

Współczesne procesory x86-64 tak naprawdę wykonują mikroinstrukcje RISC, gdyż dekoder instrukcji tłumaczy na nie instrukcje CISC. Aby Alpha AXP mogła wykonywać 32-bitowy i 16 bitowy kod x86, wystarczyłoby dobudować do niej analogiczny dekoder instrukcji, który w trybie 64-bitowym RISC byłby pomijany.

NTka to była na 4 platformy
x86
Alpha
MIPS
PowerPC
Ach to były czasy ...
2000 ke kompilowali na Itanium... ale to chyba tylko dla HP

W sumie wszystkie te architektury przerabiałem i jakoś inaczej to pamiętam. AMD64 wygrało bo Microsoft tak powiedział. A konkretnie nie chcieli wspierać dwóch różnych linii 64bitowych procesorów. A AMD64 był łatwiejszy w implementacji i tańszy. Dlatego Intel nie miał specjalnego wyboru. Po prostu przekombinowali. Inna sprawa, że MS jeszcze długo potem wciskał ludziom systemy 32bitowe.
Co d Alphy. Był na to wydany Windows NT i jakaś beta W2000. Gdyby procesor był bardziej popularny to byłaby kontynuacja.

Itanium to takie procesory który były ale w zasadzie nikt nie wie po co (chyba intel też)
Chyba go tylko HP stosowało (bo to taki w sumie pomysł ślepa uliczna pomysłu HP robiona przez Intela)

@Andree - i odpaliłbyś na tym Windowsa? Starsze apki dosowe? Oczywiście bezbłędnie i z rozsądną prędkością? No nie. Itanium celowało w HPC i serwery, tam nawet jako tako początkowo sobie dawało radę, ale to nie była i nie jest architektura dla desktopa. Ostatecznie za drogie, za gorące i za mało popularne. Alpha to też nie procesory dla desktopa, pewnie udałoby się je przeskalować, ale nadal największym wrogiem była kompatybilność wsteczna. Dopóki ktoś nie wymyśli architektury zapewniającej w trybie emulacji choć zbliżoną wydajność do x86 to x86 nadal będzie królować.

Warto przypomnieć smutny los rewolucyjnej jak na lata 90-te 64-bitowej architektury RISC Alpha AXP opracowanej przez Digital Equipment Corporation (DEC).
Przypominam że to były czasy, gdy procesor Pentium 1 był szczytowym osiągnięciem Intela. Tymczasem Alpha AXP miała aż 32 64-bitowe rejestry (w zdecydowanej większości rejestry ogólnego przeznaczenia i służące do przekazywania argumentów do/z funkcji) a każda instrukcja była słowem 32-bitowym, co znakomicie upraszczało dekoder instrukcji!
https://blogs.msdn.microsoft.com/oldnewthi...807-00/?p=96766
Po wykupieniu DEC przez Compaq rozwój architektury Alpha AXP został zakończony a wszystkie prawa do niej sprzedane Intelowi w 2001 r.
Szkoda bo planowane na początek 21 wieku procesory EV8 miały mieć m.in. możliwość współpracy w sieci procesorów typu mesh tworzących superkomputer.
Gdyby Intel postawił na tą architekturę zamiast ładować pieniądze w Itanium, współczesna informatyka mogłaby wyglądać zupełnie inaczej - zamiast licencjonować od AMD x86-64 mógłby w 64-bitowych PC-tach zastosować Alpha AXP z dodatkowym konwerterem 16 i 32-bitowych instrukcji na RISC.

Wracając do Itanium to artykułowi brakuje najważniejszego - wykresów przewidywań analityków

Oczywiście, w drugą stronę jest to samo. Procesory 8 bitowe (Z80, 8080, 6502, 8502) adresują 16bit, a długość słowa to 8 bit. Procesory 32bitowe mogą adresować mniej (np. 68000 ma rejestry 32bit, ALU 16 bit, datapath 16 bit i adresowanie 24bit). Instrukcje AMD64 nie są 64bitowe (tylko) ze względu na teoretycznie ciągły obszar adresowania 64bit (w praktyce jest to 40 lub 48bit - tyle jest wyciągniętych linii adresowych, reszta jest pure virtual) a szerokość rejestrów ogólnego przeznaczenia i ALU. ARM czy to Aarch32 czy Aarch64 ma stałą długość rozkazu tj. 4bajty, w przypadku thumb mogą być to 2 lub 4 bajty. Ale nawet Thumb operuje na 32bitowych rejestrach, po prostu są to bardziej kompaktowe rozkazy. W przypadku x86-64 (uwzględniając x86) rozkazy mogą mieć 1 aż do 15 bajtów długości. To jest horror. Jeszcze dzikie kodowanie przez illegal opcode

Wywiązała się bardzo ładna dyskusja, ludzi obeznanych w dziedzinie miło się czyta. Czy sekcja komentarzy nie może tak wyglądać zawsze?

Pisałem o trybie 32-bitowym i 64-bitowym (czyli oczywiście chodzi o tryb adresowania). Ty w komentarzu #9 zacząłeś pisać o instrukcjach różnej długości. Co to ma wspólnego?

Zmienna długość instrukcji to we współczesnych procesorach tylko i wyłącznie problem dekodera. Dekoder może zamienić instrukcję CISCową na RISCową (chociaż pojęcie RISC jest płynne), a więc zastępuje skomplikowane kodowanie instrukcji prostym kodowaniem, a następnie dalsza część potoku wykonawczego zajmuje się tylko i wyłącznie tymi prostymi w budowie instrukcjami. Z drugiej strony: jak dekoder miałby pozbyć się bitów odpowiedzialnych za predicated/ conditional execution? Zastąpić skokami? Bez sensu. Te bity muszą siedzieć w makro-opach i mikro-opach na całej długości potoku wykonawczego i tym samym zwiększać jego złożoność.

Sama arytmetyka stałoprzecinkowa może też mieć większe rejestry niż zdolność procesora do adresowania. Np:
https://en.wikipedia.org/wiki/IBM_7030_Stretch - 64-bitowe operacje na liczbach całkowitych, adresowanie z użyciem 18-bitów.
https://en.wikipedia.org/wiki/Intel_i860 - procesor 32-bitowy, ale część graficzna obsługuje operacje na 64-bitowych liczbach stałoprzecinkowych

Jestem pewien, nie podam źródła. Po co? To wynika z roli jaką pełnią.
Ale super duper argumentu nie mam, a ty nie masz kontrargumentu.

Jest 1 uops, ale o co chodzi? A chodzi o to by wcześnie połączyć instrukcję ustawiającą flagę z instrukcją skoku warunkowego (i nic poza tym). RISC takie instrukcje ma często w ISA np. BRNE (branch if not equal). x86 musi najpierw porównać, a później w zależności od wyniku skoczyć lub nie. Zatem kolejny raz jest to niejako potwierdzenie RISCowej charakterystyki mikrooperacji.

No to jeszcze raz - zobacz do jakiego fragmentu twojej wypowiedzi się odnosiłem (mieszanie instrukcji 32 i 64bit w aplikacji). Nie co do speculative execution czy czegokolwiek innego. A jedynie mieszania instrukcji różnej długości. I dlatego wspomniałem o Thumb2 i jego zastosowaniu. Jeśli kiedyś potrzebne będą mikrokontrolery 64bitowe (teraz nie są i nie ma większego sensu, korzystają z NEONa, ale po co im operować na 64 bitach i mieć przestrzeń liniową ileś tam petabajtów), ale jeśli by były i miały dość ograniczoną pojemność pamięci to nie ma żadnej pewności, że nie powstałby thumb3 mieszający rozkazy 16, 32 i 64bit.

Promilus mieszał długość instrukcji z trybem adresowania, ty mieszasz długość rejestrów z trybem adresowania.

Pokaż mi działający kod x86 w którym mieszasz 32-bitowe i 64-bitowe adresowanie, np:

Dokładnie. Po minusach widzę, że ci komentujący, którzy nie zajażyli, że ia64 nie ma nic wspólnego z x86-64 dalej tkwią w swojej niewiedzy i robi się zabawnie.

w x86 możesz używać całego zestawu instrukcji w każdym z trybów
czy to trybie rzeczywistym, chronionym czy 'long mode' [jak to się nazywa po polsku?!]
nawet 16 bitowe aplikacje mogą korzystać z 32 i 64 bitowych rejestrów jeśli są dostępne (ale większość takiego oprogramowania z nich nie korzysta)
Format PE dla 32 bitowych programów Windows zawiera stub z dosowym 16 bit kodem https://docs.microsoft.com/en-us/windows/d...stub-image-only
edit:
@up 64 bitowe programy mogą i korzystają z rejestrów 32 bitowych i mniejszych wiec ich również nie uruchomiłbyś
fasmem daje się bez problemu zasemblerować taki kod

wiec można stworzyć 64 bitowy program dla dosa

x86-64 to tryb pracy procesora, w którym możliwe jest adresowanie do 2^64 komórek pamięci (w praktyce procesor nie ma tylu linii adresowych, bo moduły pamięci mają znacznie mniejszą pojemność). Oczywiście można byłoby stworzyć procesor x86-64, którego nie da się przełączyć w tryb Legacy (32-bitowy lub 16-bitowy). Miałoby to niewielkie konsekwencje - nie dałoby się zainstalować 32-bitowego systemu operacyjnego ani uruchomić 16-bitowego kodu boot-loadera zawartego w MBR (Master Boot Record), co uniemożliwiłoby bootowanie nośników (dysków, płyt i pendrive) nie wykorzystujących GPT (GUID Partition Table) i partycji EFI zawierającej 64-bitowy bootloader w pliku /efi/BOOT/BOOTX64.EFI.
Jednak nadal można byłoby uruchamiać 32-bitowe programy za pomocą podystemu WoW64 wykorzystującego tryb kompatybilności w ramach Long mode.
Usunięcie także tego trybu kompatybilności zmusiłoby do programowego emulowania trybu 32-bitowego, z ogromną stratą wydajności, więc wątpię żeby producenci procesorów się na to zdecydowali. A co do całkowitego usunięcia możliwości uruchamiania 32-bitowych programów, to nie stanie się to prędko, gdyż w przypadku wielu mniejszych aplikacji nie przynosi to żadnych korzyści a tylko zwiększa wielkość kodu wykonywalnego i uniemożliwia uruchamianie go na starszych komputerach z 32-bitowymi systemami.
https://en.wikipedia.org/wiki/X86-64#Operating_modes

Zapamiętajcie drogie dzieci tę historię jako przykład triumfu idei powstałej w AMD. Gdyby nie AMD, to do tej pory Intel serwowałby zwykłym uzytkownikom 32-bitowe procki X86, bo wg Intela 64-bit to właśnie Itanium i tylko dla firm.

Jesteś pewien? Podaj źródło. Sandy Bridge ma uop cache dość małej pojemności, więc kompaktowe uopy mogłyby być opłacalne. Zależy od implementacji.


Tego też nie byłbym pewien. W x86 czasami 2 instrukcje = 1 mikroinstrukcja: https://en.wikichip.org/wiki/macro-operation_fusion Zaawansowany ARM może robić coś bardzo podobnego (rozwiązanie od Intela jest opatentowane).


A zobacz co ja zacytowałem:

Przez wyrzucenie problematycznych bitów z opkodów ARM uprościło sobie tworzenie wysokowydajnych czipów. To moim zdaniem jeden z głównych powodów dla których wydajnościowy skok z ARM 32-bit do ARM 64-bit jest duży.

Równe rozmiary instrukcji upraszczają dekoder instrukcji, ale w żaden sposób nie wpływają na ich łączenie, rozbijanie czy wykonywanie po zdekodowaniu.