Komentarze
Komentarzy na stronę
1 2
cichy45 (2019.02.01, 16:45)
Ocena: 16
#2

0%
Wydaje mi się że x86_64 to tylko rozszerzenie x86 więc jako tako bez niech chyba działać nie będzie. Ktoś może napisać czy jest to możliwe?
Namonaki (2019.02.01, 17:13)
Ocena: 19
#4

0%
x86_64 bez x86 to absurd
@up dobrze Ci się wydaje
przecież nawet rejestry 32 bitowe są nisza częścią rejestrów 64 bitowych tak jak to jest z eax i rax
do tej pory nie zrezygnowano z 16 bitowych instrukcji i rejestrów (są częścią 32 bitowych); ax jest częścią eax
a instrukcje operujące na tych rejestrach są nadal 16 i 32 bit
mov rax, 0 //to instrukcja x86_64 (64bit)
mov r8, 0 //również x86_64
mov eax, 0 // instrukcja x86 (32bit)
mov ax, 0 // 16 bitowa (286)
mov ah, 0
[każda z tych instrukcji ustawia dany rejestr na 0]

dodatkówo rejestry SSE są niższa częścią rejestrów AVX

nawet ARM64 jest rozszerzeniem ARM w analogiczny sposób

wracając do IA-64 ostatnimi laty linia Itanium 9700 dogorywała
intel wydał w niej procki o 100 MHz szybsze w nie zmienionej litografi
Itanium przegrało z AMD64 przez kompletną zmianę architektury.
Promilus1984 (2019.02.01, 18:57)
Ocena: 3
#5

0%
Itanium przegrało bo było drogie i niewygodne (jeszcze mocniej zależne od optymalizacji kompilatora niż x86). Gdyby intel mógł się skupić nad dopracowaniem tej architektury to jakaś szansa była, ale okazało się, że do starego dobrego x86 wystarczyło dodać szersze rejestry i nagle tanim kosztem uzyskać to co w pocie czoła osiągnęła ekipa od IA64. A niemożliwe było jednocześnie wspierać rozwój IA64 oraz z zadowalającą prędkością (czyt. przynajmniej porównywalną do konkurencji z x86-64) wykonywać kod x86. Innymi słowy to musiało w końcu umrzeć, szczególnie gdy Intel zaczął znów pompować x86, bo samo AMD tego wózka by nie uciągnęło, nie z Phenomami i Bulldozerami.
Wibowit (2019.02.01, 19:00)
Ocena: 4
#6

0%
nawet ARM64 jest rozszerzeniem ARM w analogiczny sposób

Akurat w ARM przy przejściu na 64-bit coś pozmieniali. ARM wyrzuciło z opkodów bity odpowiedzialne za conditional/ predicated execution. Jest to bardzo znacząca zmiana.

ARMv8 Instruction Set Overview:
The A64 instruction set does not include the concept of predicated or conditional execution. Benchmarking shows that modern branch predictors work well enough that predicated execution of instructions does not offer sufficient benefit to justify its significant use of opcode space, and its implementation cost in advanced implementations.
Promilus1984 (2019.02.01, 19:40)
Ocena: 6
#7

0%
ARM wyrzuciło z opkodów bity odpowiedzialne za conditional/ predicated execution. Jest to bardzo znacząca zmiana

Zupełnie nieznacząca. Aplikacja nie może naraz korzystać z instrukcji 32 i 64bit. Czyli wersja 64bitowa musi być skompilowana na nowo. Zmiana ta w żaden sposób więc nie dotyka developerów, kompilator sam zadba by pojawiła się odpowiadająca temu sekwencja rozkazów maszynowych.
Wibowit (2019.02.01, 20:11)
Ocena: 3
#8

0%
Promilus1984 @ 2019.02.01 19:40  Post: 1187176
ARM wyrzuciło z opkodów bity odpowiedzialne za conditional/ predicated execution. Jest to bardzo znacząca zmiana

Zupełnie nieznacząca. Aplikacja nie może naraz korzystać z instrukcji 32 i 64bit. Czyli wersja 64bitowa musi być skompilowana na nowo. Zmiana ta w żaden sposób więc nie dotyka developerów, kompilator sam zadba by pojawiła się odpowiadająca temu sekwencja rozkazów maszynowych.

Przecież w żadnym wypadku aplikacja nie może być w trybie 32-bitowym i 64-bitowym jednocześnie, obojętnie czy to na ARMie czy x86, MIPSie czy czymkolwiek innym. Stąd z twojego stwierdzenia wynika iż każda zmiana przy przechodzeniu z 32 bitów na 64 bity jest nieznacząca.

Mi chodziło o znaczną zmianę w konstrukcji procesora i kompilatora. Conditional execution w praktyce stoi w opozycji do speculative execution. Łączenie ich utrudnia ich optymalne wykorzystanie w kompilatorze, który musi zdecydować się którego rodzaju mechanizmu użyć. Podobnie procesor musi sobie zdecydować czy napotykając warunkową instrukcję wykonać ją spekulatywnie czy nie. Wszelakie procki x86 nie używają spekulatywnego wykonywania przy wykonywaniu warunkowym czegokolwiek innego niż skoku. Tzn jak mamy np `movbe eax, ebx` to procek zaczeka, aż najpierw flagi zostaną policzone, ale przy skoku, np `jbe cel` procek już wykorzystuje wykonywanie spekulatywne i nie czeka na liczenie flag. Wykorzystywałem ten fakt nieraz, np jak programowałem w czystym asemblerze x86.
Edytowane przez autora (2019.02.01, 20:14)
Promilus1984 (2019.02.01, 20:20)
Ocena: 0
#9

0%
Przecież w żadnym wypadku aplikacja nie może być w trybie 32-bitowym i 64-bitowym jednocześnie, obojętnie czy to na ARMie czy x86, MIPSie czy czymkolwiek innym

Tak, ale gdybyś spojrzał szerzej na ARM to zauważyłbyś, że jest taki zestaw instrukcji Thumb2, który pozwala mieszać instrukcje 16 i 32bit. I nie ma żadnego przeciwwskazania by tak samo nie mogło to działać z 32 + 64bit, po prostu nie jest to potrzebne. Thumb2 służy zbalansowaniu gęstości kodu i jego wydajności (i jest z tego powodu głównie wykorzystywany w mikrokontrolerach gdzie jest dość ograniczona ilość pamięci). Na komputerach kod nie musi być wcale kompaktowy. Od bardzo dawna nie jest.
A co do Aarch64 to jakoś mam wrażenie, że (pewnie ze względu na już większą dojrzałość aplikacji dostosowanych do 64bit) wniosło to więcej wydajności do ARM niż ARM64 dla x86.
Wibowit (2019.02.01, 20:39)
Ocena: 0
#10

0%
W x86 pojedyncza instrukcja może mieć od jednego bajta do kilkunastu bajtów. Nie bardzo widzę jak różna długość instrukcji ma wpływać na konstrukcję kompilatora bądź spekulatywne wykonywanie instrukcji.
Promilus1984 (2019.02.01, 20:41)
Ocena: 0
#11

0%
W x86 pojedyncza instrukcja może mieć od jednego bajta do kilkunastu bajtów

I jest tłumaczona na mikroinstrukcje o stałej długości ... a w RISC nie, bo zazwyczaj 1 instrukcja = 1 mikroinstrukcja. To raz. A dwa - zobacz czego dotyczył wpis, przecież zacytowałem konkretnie.
Edytowane przez autora (2019.02.01, 20:41)
Wibowit (2019.02.01, 20:55)
Ocena: -2
#12

0%
I jest tłumaczona na mikroinstrukcje o stałej długości

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.

a w RISC nie, bo zazwyczaj 1 instrukcja = 1 mikroinstrukcja

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).

To raz. A dwa - zobacz czego dotyczył wpis, przecież zacytowałem konkretnie.

A zobacz co ja zacytowałem:
The A64 instruction set does not include the concept of predicated or conditional execution. Benchmarking shows that modern branch predictors work well enough that predicated execution of instructions does not offer sufficient benefit to justify its significant use of opcode space, and its implementation cost in advanced implementations.

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.
Edytowane przez autora (2019.02.01, 21:06)
StymulatorPlazmowy (2019.02.01, 21:04)
Ocena: 7
#13

0%
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.
Andree (2019.02.01, 22:47)
Ocena: 2
#14

0%
cichy45 @ 2019.02.01 16:45  Post: 1187160
Wydaje mi się że x86_64 to tylko rozszerzenie x86 więc jako tako bez niech chyba działać nie będzie. Ktoś może napisać czy jest to możliwe?

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
Namonaki (2019.02.01, 23:13)
Ocena: 1
#15

0%
Wibowit @ 2019.02.01 20:11  Post: 1187180

Przecież w żadnym wypadku aplikacja nie może być w trybie 32-bitowym i 64-bitowym jednocześnie, obojętnie czy to na ARMie czy x86, MIPSie czy czymkolwiek innym.

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
format MZ
use64
start:
mov ax, 0
mov eax, 0
mov rax,0
ret

wiec można stworzyć 64 bitowy program dla dosa :D
Edytowane przez autora (2019.02.02, 00:04)
anemus (2019.02.02, 01:28)
Ocena: 3
#16

0%
Centronix @ 2019.02.01 16:50  Post: 1187161
Epic fail ;)
https://en.m.wikipedia.org/wiki/Explicitly...ction_computing
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.
;-)
Edytowane przez autora (2019.02.02, 01:29)
Wibowit (2019.02.02, 03:04)
Ocena: -2
#17

0%
Namonaki @ 2019.02.01 23:13  Post: 1187205
Wibowit @ 2019.02.01 20:11  Post: 1187180

Przecież w żadnym wypadku aplikacja nie może być w trybie 32-bitowym i 64-bitowym jednocześnie, obojętnie czy to na ARMie czy x86, MIPSie czy czymkolwiek innym.

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)

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:

mov ax,[rbx] // 64-bitowe adresowanie
mov ax,[ebp] // 32-bitowe adresowanie
Promilus1984 (2019.02.02, 07:25)
Ocena: 1
#18

0%
Jesteś pewien? Podaj źródło

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.
Tego też nie byłbym pewien. W x86 czasami 2 instrukcje = 1 mikroinstrukcja:

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.
A zobacz co ja zacytowałem

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.
Wibowit (2019.02.02, 11:34)
Ocena: 0
#19

0%
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.

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
Edytowane przez autora (2019.02.02, 12:07)
cichy45 (2019.02.02, 12:14)
Ocena: 1
#20

0%
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? :)
Zaloguj się, by móc komentować
Aktualności
Facebook
Ostatnio komentowane