Kompilator Go

Zastanawiam się czy od czasu http://www.secnews.pl/2014/09/05/technologiczna-bieda-kompilatora-go/ coś się zmieniło

Podejrzewam, że mogło się troszkę zmienić, bo od wersji 1.5 kompilator Go jest napisany w czystym Go. Sam jestem ciekawy, ale assembler to nie jest moja mocna strona

Widać poprawę w generowanym kodzie, bo spojrzałem na najnowszą wersję, jednak zdarzają się kwiatki jak:

1. Bezsensowe wymiany rejestrów

.text:0048B721                 xchg    ebx, esi
.text:0048B723                 neg     ebx
.text:0048B725                 xchg    ebx, esi

2. To jest dobre:

.text:0048A617                 mov     [esp+0A8h+arg_8], esi
.text:0048A61E                 mov     [esp+0A8h+arg_C], edi
.text:0048A625                 mov     [esp+0A8h+arg_10], 214h
.text:0048A630                 mov     [esp+0A8h+arg_14], eax
.text:0048A637                 mov     [esp+0A8h+arg_18], ecx
.text:0048A63E                 add     esp, 0A8h
.text:0048A644                 retn

Zapisuje lokalne parametry na stosie funkcji po czym z niej wychodzi  

3. Posługiwanie się 8 bitowymi rejestrami, gdy można skorzystać z 32 bitowych

.text:0048A3F3                 movzx   ebx, [esp+0A8h+var_98]
.text:0048A3F8                 cmp     bl, 0
.text:0048A3FB                 jz      short loc_48A455

4. Jako jedyny kompilator na świecie sprawdza czy rejestr jest zerowy używając cmp zamiast test

.text:0048A412                 cmp     ecx, 0
.text:0048A415                 jz      short loc_48A419

5. Używa niepotrzebnie instrukcji CLD oraz barier UD2 po wywołaniu wyjątku

.text:00423350                 mov     ecx, large fs:14h
.text:00423357                 mov     ecx, [ecx+0]
.text:0042335D                 cmp     esp, [ecx+8]
.text:00423360                 jbe     short loc_423395
.text:00423362                 sub     esp, 10h
.text:00423365                 mov     ebx, runtime_sliceError.tab
.text:0042336B                 mov     [esp+10h+i.tab], ebx ; i
.text:0042336E                 mov     ebx, runtime_sliceError.data
.text:00423374                 mov     [esp+10h+i.data], ebx
.text:00423378                 call    runtime_convI2E
.text:0042337D                 lea     ebx, [esp+10h+var_8]
.text:00423381                 cld
.text:00423382                 mov     ecx, [ebx]
.text:00423384                 mov     [esp+10h+i.tab], ecx ; e
.text:00423387                 mov     ecx, [ebx+4]
.text:0042338A                 mov     [esp+10h+i.data], ecx
.text:0042338E                 call    runtime_gopanic
.text:00423393                 ud2

6. Nie potrafi wykorzystać wyników operacji logicznych do sprawdzania stanu rejestru (0 czy nie)

.text:004020A9                 mov     ebx, ebp
.text:004020AB                 and     ebx, 20h
.text:004020AE                 cmp     bl, 0
.text:004020B1                 jnz     short loc_402116

Tutaj zbędna jest operacja cmp.

Nie jest to kompilator najwyższych lotów i brakuje mu lata świetlne do LLVM i Intel-a.

4 godziny temu, Bartosz Wójcik napisał:

brakuje mu lata świetlne do LLVM i Intel-a.

To akurat nie jest dziwne, Go to relatywnie młody język
Wiele z rzeczy o których wspomniałeś jest w planach do poprawki w wersji 1.6 - link.
Najważniejsze, że programy pisane w Go są wydajne, a samo pisanie w tym - niesamowicie przyjemne i proste :)

Programy, w których kompilator generuje niewydajny kod nie mogą być uznawane za wydajne, to wbrew logice , potwierdzi to każdy benchmark jeśli postawisz obok siebie ten sam algorytm skompilowany w Go i kompilatorach z VC++ i Intela.

A jednak Go daje radę już teraz :) Miejmy nadzieję, że w przyszłości poprawią jakość kompilatora i będzie całkiem super.

pytanie za 100 punktów , jaki najmniejszy plik exe można wygenerować tym kompilatorem ?

Dnia 23.12.2015 at 23:11, A.S.L napisał:

pytanie za 100 punktów , jaki najmniejszy plik exe można wygenerować tym kompilatorem ?

Spróbuj, podziel się efektami

słabo to wygląda , po skompilowaniu tego :
 

package main

import "fmt"

func main() {
    fmt.Println("Hello, World")
}

plik exe ma 1.5 MB

:-)

go version go1.4.2 windows/386