Odp: atari800 v. 2.0.0
pamietaj ze C to wlasciwie tylko nieco bardziej przenosny assembler, tak wiec jesli dobrze zaprojektuje sie kod C - wynik w assemblerze, przy dobrym kopulatorze, niewiele sie bedzie roznil od perfekcyjnie napisanego recznie.
Pamiętam. Jednak podtrzymuję, że zachodzi tu wyjątek, mianowicie w postaci programu, który jest silnikiem emulacji innego CPU. Tutaj C niestety polegnie, bo jest JEDNAK językiem stosunkowo wysokiego (za wysokiego) poziomu.
gcc dla m68k to było kolejno 2.7.2, 2.8.1, 2.95.2. Wszystkie wersje generują dość przyzwoity kod wynikowy, zresztą chyba nie może być inaczej, skoro gcc przeprowadza optymalizację jeszcze na etapie niezależnym od maszyny, a dopiero to co mu wychodzi przekłada na mnemoniki. Podejrzewam, że na innych platformach z jakością kodu jest dokładnie tak samo.
Pytanie jest idiotyczne z dwóch względów:
a) masz wyżej napisane, że silnik asemblerowy jest szybszy od ANALOGICZNEGO kodu w C (czyli: algorytm ten sam)
b) asembler to jednak nie jest C, więc wymyślenie programu w C, a potem przełozenie go ręczne na asembler nie może dawać wyników znacząco lepszych niz w przypadku produktu kompilatora; implementacja algorytmu musi być nie tylko w asemblerze napisana, ale tez w asemblerze wymyślona.
Dla ułatwienia dodam, że ten program chodzi na procesorach od 68020 do 68060 i nie zawiera nieczystych sztuczek w rodzaju samomodyfikującego się kodu (bo to na Motorolach powoduje problemy z cache'em).
Cały program z gcc nie ma nic wspólnego, poza tym, że gcc występuje tu jako wartość porównawcza. Ale twierdzę, że to jest właśnie taki przypadek, gdzie nie tylo gcc, ale dokładnie każdy kompilator zawiedzie. A to z tego powodu, że kompilator jest bezmyślnym automatem. Może optymalizowac znane sobie (czyli swoim twórcom) konstrukcje pod względem formalnym, oraz dokonywac analizy programu na np. częstotliwośc użycia pewnych zmiennych, żeby zdecydować, które zmienne umieścić w rejestrach, które na stosie a które gdzie tam. Oraz dysponuje repertuarem tym podobnych chwytów.
To wszystko jednak nie zmienia faktu, że kompilator nie ma bladego pojęcia, co kompilowany program robi, oraz jak można wykorzystać architekturę danej maszyny do zrobienia tego lepiej. To wie tylko człowiek, bo tylko człowiek jest w stanie zrozumieć algorytm.
Fox: zagadnienie nie ma nic wspólnego z opcjami optymalizacji kompilatora C, a raczej z tym, jak kompilator w ogóle działa, no i jak jest zdefiniowany język C jako taki.
Ostatnio edytowany przez drac030 (2006-01-05 11:34:48)
? HEX$(6670358)