Procesy kompilacji. Asemblacja

Hejooo,
Przeglądałem sobie jak wygląda kompilacja i zastanawia mnie teraz kilka rzeczy.
Tak rozumiem w uproszczeniu proces kompilacji :


W momencie gdy kompilator zmienia source file na asemblera, używa asemblera, opierajacego się na poleceniach procesora na którym pracuję tak?
Mam to rozumieć, tak że tam gdzie, inny procesor, tam inaczej się tłumaczy .cpp na asemblera? ;o
Skoro zależnie od procesora mamy inny kod aseemblera, to również kod maszynowy a co za tym idzie inny kod binarny, to dlaczego .exe jest przenośny ?

W dodatku odwołując się do strony
http://faculty.cs.niu.edu/~mcmahon/CS241/Notes/compile.html
Jest tam napisane, iż przy używaniu preprocesora zostają dołączone header files. A ponoć kompilator dołącza tylko te pliki .o, które zawierają potrzebne nam funkcje i dzieje się to na etapie likera. W takim razie co miał na myśli autor tego tekstu ?

Język maszynowy i binarny to jest to samo i jest to program pod postacią 1000100100(w rzeczywistości po otwarciu pliku .exe w np. notatniku nie widzimy zer i jedynek tylko krzaczki, a to dlatego, że odpowiednia liczba oznaczająca rozkaz procesora zostaje zamieniona na znak ASCII, żeby zaoszczędzić miejsce(dużo mniej miejsca zajmuje np. # niż 100011, pierwsze zajmuje w pliku tylko jeden bajt, drugie aż 6 bajtów), ale to i tak jest kod maszynowy, czyli rozkazy pod są pod postacią liczb.

Owszem, inaczej działa kompilator C++ na architekturze x86 a inaczej na ARM. Przez to chcąc przenieść kompilator na inną platformę musimy go przeportować, czyli przerobić tak, żeby działał na innej architekturze, czyli generował kod zgodny z inną architekturą. Potem wchodzi do gry asembler, który tłumaczy kod asemblera na kod maszynowy, i on też musi być oczywiście dostosowany do architektury. Na jednej architekturze np. rozkaz o numerze 123 oznacza instrukcję assemblera mov, podczas gdy na innej ten sam numer oznacza instrukcje add, to tylko przykład jakby co). Skąd pomysł, że EXE jest przenośny? Chodzi ci o to, że możesz go odpalić na innym komputerze z Windows? Używane powszechnie procesory w desktopach są oparte na architekturze x86(coraz częściej jest to x86-64, lecz to jest tylko rozszerzenie architektury x86 o dodatkowe rejestry i rozkazy), procesory różnych firm jeżeli są oparte na tej samej architekturze to są ze sobą zgodne. Czyli AMD Athlon jest zgodny z Intel Celeron(w praktyce zgodność nie jest 100%, bo procesory różnych firm posiadają swoje bajery i rozszerzenia, ale podstawowa zgodność jest zachowana), bo są one oparte na tej samej architekturze, czyli x86, dlatego możesz odpalać EXE skompilowany na jednym komputerze na innym, pod warunkiem, że ma procesor zgodny z tą samą architekturą, na której program był kompilowany. Oczywiście, tego samego exe nie odpalisz już na procesorze zgodnym z architekturą ARM. Co innego program napisany w języku Java, może być odpalany na czym chcesz, ale kod programu nie jest wykonywany przez procesor bezpośrednio, lecz przez maszynę wirtualną(choć istnieją kompilatory Java, które kompilują kod tego języka do kodu maszynowego). Kod assemblera się nie zmienia, zmieniać się mogą rejestry czy inne pomniejsze rzeczy, ale kod zawsze jest ten sam(są dwie różne składnie, Intelowska i AT&T), tylko w zależności od architektury zmieniają się opcody, czyli kod liczbowy(numer) rozkazu.

Ostatniego pytania nie bardzo rozumiem. Za pomocą dyrektywy #include dołączasz tylko nagłówek, a on nie zawiera kodu, tylko jakieś zmienne/stałe i prototypy funkcji. Podczas kompilacji wszystkie pliki z kodem są zamieniane na plik .o(czyli plik obiektowy z kodem maszynowym) a następnie łączone ze sobą.

Czyli w skrócie asembler zależy od architektury np czy 32, czy 64 yep?

Tak, język asemblera to jest nic innego, jak przedstawienie rozkazów procesora w formie słów a nie liczb. Rozkazy są akurat mniej więcej identyczne w asemblerach na różnych platformach(masz 2 składnie asemblera, Intelowska oraz AT&T). To co się zmienia to kod liczbowy rozkazu(tzw. opcode) czyli np. w jednej architekturze instrukcja mov ma numer 123 a w innej 124. Ale procesory jednej architektury są ze sobą zgodne w stopniu podstawowym(w naszym wypadku jest to architektura x86, zwana też 32bitową, architektura 64bitowa, czyli x86-64 to nic innego jak architektura x86 z paroma dodatkowymi rejestrami i rozkazami. Asembler nie jest językiem przenośnym, bo poprostu np. architektura ARM ma inne rejestry, inne przerwania, inaczej się pisze program i przez to program pisany w asemblerze na architekturę x86 nie będzie działał na architekturze ARM, ale będzie działał na procesorach zgodnych z architekturą x86. Podobnie program pisany w asemblerze na Windows nie będzie działał na Linux, bo te dwa systemy mają inne przerwania systemowe. Istnieją przerwania systemowe, które każdy system ma inne(Windows/DOS mają przerwanie int 21h, które nie występuje w systemach Linux). Przez to kod asemblera jest nie tylko nie przenośny na inne architektury, lecz także na inne systemy(no, DOS i Windows mają dużo identycznych przerwań, np. wspomniane 21h), więc asembler nie zależy tylko od architektury, lecz też od systemu. Mam nadzieję, że zbytnio nie pomotałem.

Rozkazy są akurat mniej więcej identyczne w asemblerach na różnych platformach

Jaki jest odpowiednik ldmda z ARM na AVR? Jaki jest odpowiednik arpl z x86 na PowerPC? Jaki jest odpowiednik add (serio, add!) z MIPS na x86?

masz 2 składnie asemblera, Intelowska oraz AT&T

Tylko na x86. Praktycznie każda inna architektura ma jeden styl składni języka asemblera.

np. w jednej architekturze instrukcja mov ma numer 123 a w innej 124

A w innej nie ma wcale, bo instrukcja mov tam nie istnieje. Na przykład na już wspomnianych MIPS i PowerPC nie ma instrukcji mov; move/mr istnieją tam tylko na etapie asemblacji, po niej zostają w tych miejscach add/or.

Windows/DOS mają przerwanie int 21h

Windows ma przerwanie 0x2E, które po pierwsze nie jest udokumentowane, a po drugie jest używane tylko na bardzo starych procesorach, które nie obsługują niczego lepszego niż przerwania, jak sysenter/sysexit lub syscall/sysret.

Alueril:
1. Chodziło mi o sposób pisania programów czy rozkazy. W każdym asemblerze pisze się tak samo, czyli wpisujemy rozkazy. O to mi chodziło.

2. No i chodziło mi o x86. Przecież pisałem o tym w odniesieniu do architektury x86, gdzie ja napisałem, że te składnie są też dla ARM?

3. Czy ja gdziekolwiek powiedziałem o jaką architekturę mi chodzi? Rany, dałem tylko przykład, aby wyjaśnić autorowi jak instrukcje zamieniane są na kod liczbowy, oraz dlaczego binarka nie jest kompatybilna z innymi architekturami. Nie przytoczyłem żadnej konkretnej architektury, to miał być tylko najprostszy przykład.

4. W Windows istnieje przerwanie 21h i jak najbardziej można z niego korzystać.

Z całym szacunkiem nie wiem o co ci chodzi. Parę zdań wyrwałeś z kontekstu, kompletnie nie rozumiesz sensu moich tłumaczeń, jak w punkcie 3 - nie przytoczyłem żadnej konkretnej architektury, to miał być tylko wymyślony przykład obrazujący rzeczywistość, a ty mi mówisz, że instrukcja mov nie istnieje w innej architekturze. Architektur jest mnóstwo, nie tylko x86, ARM czy PowerPC. Pozatym starałem się jak najbardziej to uprościć, żeby autor zrozumiał.

Myślę, że wszystko jest jasne. Wielkie dzięki!

Chodziło mi o sposób pisania programów czy rozkazy. W każdym asemblerze pisze się tak samo, czyli wpisujemy rozkazy.

O to mi chodziło: to jest jasne i nie ma ryzyka, że ktoś zostanie wprowadzony w błąd.

No i chodziło mi o x86. Przecież pisałem o tym w odniesieniu do architektury x86, gdzie ja napisałem, że te składnie są też dla ARM?

Nigdzie, ale też z kontekstu nie było jasne, że chodzi o x86, przez co ktoś mógłby to źle zrozumieć.

W Windows istnieje przerwanie 21h i jak najbardziej można z niego korzystać.

Tylko, jeśli kod działa pod kontrolą NTVDM, którego zadaniem jest udawanie DOSu. W prawdziwym programie dla Windows próba wywołania przerwania 0x21 skończy się co najwyżej wyjątkiem. Zaznaczam, że mówię o Windowsach NT, bo pozostałe raz, że są dziwnymi stworzeniami, a dwa, że w obecnych czasach lepiej już o ich istnieniu zapomnieć.

Parę zdań wyrwałeś z kontekstu, kompletnie nie rozumiesz sensu moich tłumaczeń, jak w punkcie 3 - nie przytoczyłem żadnej konkretnej architektury, to miał być tylko wymyślony przykład obrazujący rzeczywistość. […]Pozatym starałem się jak najbardziej to uprościć, żeby autor zrozumiał.

Wiem, że moje odpowiedzi są wyrwane z kontekstu, ale problem w tym, że kontekst nie był tam do końca jasny. Wiele razy widziałem, jak ktoś doszedł do błędnych wniosków spowodowanych pominięciem rzeczy, które dla osób obeznanych w temacie są oczywiste, ale dla osób z mniejszą wiedzą już nie; więc gdy tylko mogę i mam dobry humor, to staram się ewentualne nieścisłości wyłapywać.