Komentowana treść: vlink 0.15b
[#1] Re: vlink 0.15b
W praktyce stare GCC 2.95 wciąż wygrywa jakością kodu. VBCC jest może odrobinę szybszy i potrzebuje nieco mniej pamięci do kompilacji, ale to są różnice rzędu 10%.
[#2] Re: vlink 0.15b

@Krashan, post #1

Tak sobie pomyślałem, że kompilator języka Amiga E produkuje na pewno kod dla MC680x0 bardzo wysokiej jakości. Być może deklasuje w tym GCC.
[#3] Re: vlink 0.15b

@Hexmage960, post #2

Ale masz na to jakieś dowody, czy tylko tak sobie pomyślałeś?
[#4] Re: vlink 0.15b

@Krashan, post #3

Tylko sobie pomyślałem, bo kompilator E jest napisany w asm. A na jakiej podstawie oceniasz, że kod GCC jest lepszy niż VBCC? Na podstawie deasemblacji jakichś przykładów?
[#5] Re: vlink 0.15b

@Hexmage960, post #4

A jakie ma znaczenie w czym jest napisany kompilator? Zrozumiałbym, że może mieć to wpływ na szybkość działania kompilatora, czyli że kompilator języka X napisany w asemblerze mógłby kompilować szybciej niż kompilator języka X napisany np. basic-u. Ale dlaczego niby jakość/szybkość skompilowanego kodu miała by być lepsza?
[#6] Re: vlink 0.15b

@sando, post #5

Bo

"programista piszący w assemblerze" = "programista piszący w czym innym"^2


pomysł
[#7] Re: vlink 0.15b

@sando, post #5

Ano dlatego, że kompilator Amiga E jest zaprojektowany wyłącznie dla Amigi i 68k. Pozwala miksować kod E i asemblera w razie potrzeby. 68k to tylko jeden z "targetów" GCC, czy VBCC, zatem te kompilatory nie są zaprojektowane z myślą o tej rodzinie procesorów.

Można by porównać kod generowany przez Amiga E i GCC. Pytanie na jakich przykładach to sprawdzić, by móc coś wywnioskować. Stąd moje pytanie w poprzedniej wypowiedzi.
[#8] Re: vlink 0.15b

@Hexmage960, post #7

Na moje pytanie ("A jakie ma znaczenie w czym jest napisany kompilator?") udzieliłeś odpowiedzi nie związanych z pytaniem

Co więcej te odpowiedzi to wciąż tylko teoretyzowanie. Bo może się okazać, że pomimo, że 68k był tylko jednym z wielu celów dla GCC to i tak generuje on lepszy kod niż E (może nad tą jedną odnogą kompilatora pracowało więcej osób albo zdolniejsi ludzie niż nad całym E i zrobili to lepiej?). No i inne języki też pozwalają miksować swój kod z assemblerem.

PS.
Jak chcesz porównać generowany kod, to najlepiej skompilować taki sam program tymi kompilatorami i sprawdzić który kod działa szybciej.
[#9] Re: vlink 0.15b

@sando, post #8

Myślałem, że oczywiste jest, że fakt napisania kompilatora E, który jest bardzo złożonym programem w asemblerze przez jedną osobę dowodzi, że ta osoba zna się wyśmienicie na asemblerze 68k i w konsekwencji można zakładać, że generowany kod asm również jest bardzo wysokiej jakości. Być może lepszy niż GCC. Mam nadzieję, że teraz odpowiedziałem na Twoje pytanie.

Moim zdaniem fakt, że E jest dedykowany Amidze ma również decydujące znaczenie, jak również to, że kompilator E działa błyskawicznie.

No i inne języki też pozwalają miksować swój kod z assemblerem.

One pozwalają linkować kod asemblera i danego języka. W E dodajesz kod asm bezpośrednio do kodu źródłowego programu.

Jak chcesz porównać generowany kod, to najlepiej skompilować taki sam program tymi kompilatorami i sprawdzić który kod działa szybciej.

OK, o benchmarkach nie myślałem.

Ostatnia aktualizacja: 03.10.2016 16:47:45 przez Hexmage960
[#10] Re: vlink 0.15b

@Hexmage960, post #9

Myślałem, że oczywiste jest, że fakt napisania kompilatora E, który jest bardzo złożonym programem w asemblerze przez jedną osobę dowodzi, że ta osoba zna się wyśmienicie na asemblerze 68k i w konsekwencji można zakładać, że generowany kod asm również jest bardzo wysokiej jakości. Być może lepszy niż GCC. Mam nadzieję, że teraz odpowiedziałem na Twoje pytanie.

Teraz tak Bardzo dobra znajomość assemblera 68K na pewno jest argumentem "za".

Moim zdaniem fakt, że E jest dedykowany Amidze ma również decydujące znaczenie, jak również to, że kompilator E działa błyskawicznie.

Jeśli kompilator działa szybko to, wręcz przeciwnie, może oznaczać, że skompilowany kod nie będzie dobrze zoptymalizowany. Aby wygenerować coraz lepszy kod maszynowy, kompilatory przeprowadzają coraz bardziej zaawansowane analizy i optymalizacje kodu źródłowego, a to przecież wymaga coraz więcej mocy procesora.

One pozwalają linkować kod asemblera i danego języka. W E dodajesz kod asm bezpośrednio do kodu źródłowego programu.

Aż sobie sprawdziłem jak to jest w E, no i muszę przyznać, że wygląda to zgrabnie.
Z tego co wiem, to w C też można wstawiać kod assemblera w źródle programu, ale nie wygląda to tak przejrzyście.
[#11] Re: vlink 0.15b

@Hexmage960, post #4

A na jakiej podstawie oceniasz, że kod GCC jest lepszy niż VBCC? Na podstawie deasemblacji jakichś przykładów?
Dokładnie tak. Oraz na podstawie pomiarów szybkości wykonywania kodu skompilowanego oboma kompilatorami.
[#12] Re: vlink 0.15b

@Hexmage960, post #9

One pozwalają linkować kod asemblera i danego języka. W E dodajesz kod asm bezpośrednio do kodu źródłowego programu.
Nie tylko. GCC pozwala na wstawianie kodu w asemblerze bezpośrednio do źródla w C i do tego odwoływanie się z takich asemblerowych wstawek do zmiennych C.
[#13] Re: vlink 0.15b

@Krashan, post #12

A E czegoś takiego nie umożliwia?

http://cshandley.co.uk/JasonHulance/beginner_106.html

More powerfully, you can use E variables as part of the mnemonics, so you can really mix Assembly statements with normal E statements.
[#14] Re: vlink 0.15b

@Hexmage960, post #13

A E czegoś takiego nie umożliwia?
A co to ma do rzeczy? Błędnie napisałeś, że w C jest to niemożliwe, więc Cię wyprowadziłem z tego błędu.
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem