Hmm, postaram się odpowiedzieć.
(disc - stosuję w tym poście sporo uproszczeń - głównie po to żeby nie komplikować niepotrzebnie prostych rzeczy)
Zaczynając od początku, czyli procesora. Zadaniem każdego procesora jest wczytywanie strumienia danych z programem do wykonania (chociaż procesor nic nie wie o czymś takim jak program. Dla niego to tylko ciąg instrukcji do bezmyślnego i deterministycznego wykonania).
Językiem natywnym (naturalnym) dla procesora jest asembler. Jest to 'elementarny' język programowania.
Składa się on z prymitywnych (tzn. podstawowych) operacji np. przeniesienie wartości z rejestru procesora do innego, dodanie wartości w rejestrze do innej wartości, pobranie wartości z pamięci (btw. ta część wymaga komunikacji z inną częścią komputera).
Podczas pisania w asemblerze kod (tekst) który napiszesz jest w dość prosty sposób zamieniany na kod binarny - po prostu po kolei każdy opcode jest zamieniany na odpowiadającą mu wartość liczbową (np. op. przeniesienia mogłaby być zapisana jako 0x32) i zapisywany do pliku wynikowego.
Każdy procesor ma własny asembler (!). Ale żeby uniknąć totalnej anarchii wprowadzane są pewne standardy - np. jeśli piszesz z Windowsa to prawie na pewno twój procesor jest zgodny z architekturą x86 jak chyba każdy komputer PC. Ale np. komórki mają zupełnie inne asemblery co sprawia że skompilowany kod działający na twoim komputerze nie może działać na komórce (albo na PSP etc).
Plik wykonywalny (np. .exe) to (w uproszczeniu!!) ciąg instrukcji dla procesora które OS ładuje i przekazuje procesorowi w celu wykonania.
Ważny wniosek z tego - każdy program który skompilujesz można odczytać (z użyciem odpowiedniego softu albo tabelki opkodów procesora jeśli jesteś twardy :) ) jako ciąg instrukcji asemblera.
Wynika z tego również to że skompilowany program nigdy nie zadziała na innej architekturze... Po prostu obcy procesor nie będzie wiedział co oznacza ten ciąg bajtów który dostał jako program (tzn. będzie go prawdopodobnie interpretował jako zupełnie inny program).
Jeszcze jedna uwaga - najczęściej kompilacja wysokopoziomowych języków jak c++ polega na tym że najpierw kod C++ jest konwertowany do kodu asemblera a dopiero następnie kod asemblera jest asemblowany do pliku wykonywalnego.
Języki działające w wirtualnej maszynie (np. Java) to inna para kaloszy. Plik .jar to instrukcje dla maszyny wirtualnej, takie same dla każdej architektury. Dla każdej architektury wystarczy napisać maszynę wirtualną wykonującą kod Javy (i skompilować ją w natywnym dla procesora kodzie) i można uruchomić dowolny program javowy.
Można również plik .jar zapisać do pliku .exe - zazwyczaj sprowadza się to do tego że program .exe zawiera minimalną ilość instrukcji uruchamiającą VM i przekazującą jej kod bajtowy pliku .jar.
Czy istnieje język uniwersalny, i czym nim jest Asembler?
Zdecydowanie nie jest nim asm, powinieneś już rozumieć dlaczego - program w asm będzie działać tylko pod konkretnym modelem procesora, ew modelami z nim zgodnymi,
Dlaczego kompilacja jest różna dla każdego środowiska (Mac, Linux, Windows)?
Dlatego że (jedno z moich uproszczeń, ominąłem to wcześniej) program (np. exe) składa się nie tylko z czystego kodu tak samo jak .bmp nie składa się z samych informacji o kolorach. System operacyjny wymaga określonego formatu od pliku wykonywalnego (odpowiednich nagłówków etc).
Czystym plikiem wykonywalnym były w czasach DOSa np. pliki .com -> składały się jedynie z listy operacji które procesor ma wykonać, bez żadnych dodatkowych nagłówków.
W jakim języku trzeba napisać system operacyjny, lub choć jego rdzeń? Płyta główna czyta to wszystko jak np. pliki binarne (używane przy kodowanie map, dzięków itd., rozszyfrowywane bajtowo)?
Dowolnym. Warunkiem jest to że musi być kompilowany do kodu rozumianego przez procesor ergo asemblera. W praktyce obecne systemy (tzn windows i unix) są napisane w 99% w C/C++, jedynie bootloader i parę najbardziej niskopoziomowych funkcji w asm - tylko dlatego że C daje czasami za mało możliwości (np. nie da się wywołać przerwania albo zmienić wartości rejestru) - gdyby jednak dodać do C te i podobne możliwości to asm nie jest do niczego potrzebny.
PS. ciekawostką jest system tworzony przez Microsoft w większości opierający się na platformie .NET czyli również maszynie wirtualnej. Ale kluczowe partie systemu i tak muszą zostać skompilowane do języka rozpoznawalnego dla procesora.
Czy płyta główna czyta tak samo system operacyjny jak BIOS (według mnie BIOS jest także uruchamiany przez niego)?
BIOS uruchamiany przez system oparacyjny? Nie, zupełnie odwrotnie. BIOS powstaje długo zanim system operacyjny zacznie się ładować do pamięci.
BIOS (Basic Input Output System) to pewna warstwa abstrakcji nad 'bare metal'. Czyli przy programowaniu bardzo niskopoziomowym można z niego skorzystać np. do zmienienia czegoś w pamięci ekranu (np. wyświetlenie napisu).
Czy płyta główna używa tych samych "komend" niezależnie od rodzaju karty graficznej, na przykład rysowanie pikseli na ekranie?
BIOS? Jest taki sam (tzn. udostępnia takie same operacje) dla każdej płyty głównej (zgodnej ze standardem PC bo gdzie indziej BIOS nie występuje). Specyficzne funkcje karty graficznej mogą się już różnić dla różnych modeli.
Czy BIOS posiada swój MBR, który zawsze najpierw czyta płyta główna?
Co do MBR to nie wiem o co Ci chodzi - BIOS wykonuje parę działań mających na celu ustawienie pewnych rzeczy w maszynie (te śmieszne szlaczki przy włączaniu komputera ;) ) i wykonuje MBR - jest to już część systemu operacyjnego (od tego momentu na ekranie widać logo winsystemu operacyjnego).
Czy BIOS ładuje jakieś pliki
przede wszystkim BIOS nie ma pojęcia o czymś takim jak plik - to już sprawa systemu operacyjnego i jego File Systemu.
Uwaga - parę razy użyłeś sformułowania płyta główna czyta itp. Płyta główna nic nie czyta, wszystkie operacje wykonuje procesor. Płyta główna jedynie umożliwia komunikację procesora z innymi częściami komputera (np. dyskiem).
Mam nadzieję że się nie zamotałem za bardzo...
Pozdrawiam...