Instrukcja warunkowa If w języku Go
Instrukcja If w języku Go
Na wstępie należy zaznaczyć, że wybór języka Go wynika z faktu, iż spośród języków nowoczesnych posiada on najbardziej „elegancki” kod asemblerowy, a w porównaniu z językami klasycznymi jego efektywność składniowa bywa wręcz przytłaczająca.
Skoro w poprzednim wykładzie zrozumieliśmy już sposób działania prostego programu w języku Go, przejdźmy bezpośrednio do porównania Go z asemblerem wiersz po wierszu.
Kod źródłowy
Warto zauważyć, że nie tylko w języku Go, ale również w nowoczesnych kompilatorach, w tym GCC, następuje automatyczna optymalizacja instrukcji warunkowych, które nie mają uzasadnienia użycia. Kompilatory języka C, takie jak GCC czy Clang, stosują bardzo agresywną optymalizację przy standardzie branżowym -O2, co oznacza, że era, w której programista mógł w pełni ufać kompilatorowi, ostatecznie zakończyła się pod koniec XX wieku.
W związku z tym, aby uzyskać jakiekolwiek wymierne wyniki, należy narzucić kompilatorowi warunki, których przewidzenie i przekształcenie na inne konstrukcje będzie dla niego utrudnione.
1package main
2
3import (
4 "os"
5 "strconv"
6)
7
8func main() {
9 // Gdybyśmy zastąpili to przewidywalną wartością, taką jak x = 10,
10 // co pozwoliłoby na usunięcie rozgałęzienia,
11 // kompilator zoptymalizowałby kod, usuwając tę instrukcję warunkową.
12 // Aby móc obserwować takie zjawiska bezpośrednio w asemblerze, w języku C stosuje się np. -O0,
13 // lub wymusza się użycie wartości zewnętrznych, których kompilator nie jest w stanie przewidzieć.
14 // Niniejsza sekcja dotyczy programowania nowoczesnego, zatem nie będziemy
15 // wyłączać optymalizacji binarnej w Go.
16 if len(os.Args) < 2 {
17 return
18 }
19 x, _ := strconv.Atoi(os.Args[1])
20
21 if x < 10 {
22 println("X is smaller than 10")
23 } else {
24 println("X is larger or same as 10")
25 }
26}
W tym przypadku, ponieważ kompilator nie jest w stanie przewidzieć danych wejściowych, instrukcja warunkowa zostaje przetłumaczona na kod maszynowy w niezmienionej formie.
Język asemblera
1TEXT main.main(SB) /home/yjlee/introduction-to-golang/learn-golang/if-and-switch/golang-if/main.go
2 main.go:8 0x47a840 493b6610 CMPQ SP, 0x10(R14)
3 main.go:8 0x47a844 7670 JBE 0x47a8b6
4 main.go:8 0x47a846 55 PUSHQ BP
5 main.go:8 0x47a847 4889e5 MOVQ SP, BP
6 main.go:8 0x47a84a 4883ec10 SUBQ $0x10, SP
7 main.go:15 0x47a84e 48833d12fb0a0002 CMPQ os.Args+8(SB), $0x2
8 main.go:15 0x47a856 7c58 JL 0x47a8b0
9 main.go:15 0x47a858 488b0d01fb0a00 MOVQ os.Args(SB), CX
10 main.go:18 0x47a85f 488b4110 MOVQ 0x10(CX), AX
11 main.go:18 0x47a863 488b5918 MOVQ 0x18(CX), BX
12 main.go:18 0x47a867 e834e8ffff CALL strconv.Atoi(SB)
13 main.go:20 0x47a86c 4883f80a CMPQ AX, $0xa
14 main.go:20 0x47a870 7d1d JGE 0x47a88f
15 main.go:21 0x47a872 e809befbff CALL runtime.printlock(SB)
16 main.go:21 0x47a877 488d0519f50100 LEAQ 0x1f519(IP), AX
17 main.go:21 0x47a87e bb15000000 MOVL $0x15, BX
18 main.go:21 0x47a883 e878c6fbff CALL runtime.printstring(SB)
19 main.go:21 0x47a888 e853befbff CALL runtime.printunlock(SB)
20 main.go:21 0x47a88d eb1b JMP 0x47a8aa
21 main.go:23 0x47a88f e8ecbdfbff CALL runtime.printlock(SB)
22 main.go:23 0x47a894 488d05c8040200 LEAQ 0x204c8(IP), AX
23 main.go:23 0x47a89b bb1a000000 MOVL $0x1a, BX
24 main.go:23 0x47a8a0 e85bc6fbff CALL runtime.printstring(SB)
25 main.go:23 0x47a8a5 e836befbff CALL runtime.printunlock(SB)
26 main.go:25 0x47a8aa 4883c410 ADDQ $0x10, SP
27 main.go:25 0x47a8ae 5d POPQ BP
28 main.go:25 0x47a8af c3 RET
29 main.go:16 0x47a8b0 4883c410 ADDQ $0x10, SP
30 main.go:16 0x47a8b4 5d POPQ BP
31 main.go:16 0x47a8b5 c3 RET
32 main.go:8 0x47a8b6 e845f0feff CALL runtime.morestack_noctxt.abi0(SB)
33 main.go:8 0x47a8bb eb83 JMP main.main(SB)
Narzędzie go tool w przystępny sposób wskazuje dopasowanie poszczególnych instrukcji kodu do kodu asemblera.
Ponieważ tematem niniejszego wykładu są instrukcje porównania oraz instrukcje warunkowe if, skupimy się na kilku wybranych liniach.
Instrukcje CMPQ oraz JL
Instrukcja CMPQ służy do porównywania typów danych o rozmiarze 4 bajtów (4 słowa), a jej nazwa pochodzi od CoMPare Quadword.
Pod adresem pamięci 0x47a84e znajduje się instrukcja CMPQ os.Args+8(SB), $0x2.
W tym przypadku program porównuje liczbę otrzymanych argumentów z wartością szesnastkową 0x2 (czyli po prostu 2).
Następnie, za pomocą instrukcji JL, wykonywany jest skok, jeśli liczba argumentów jest mniejsza niż 2 (czyli jeśli program posiada jedynie argument będący jego nazwą). Skrót JL pochodzi od Jump Less than.
Jeśli w wyniku poprzedniej operacji porównania argument był mniejszy od 2, następuje skok pod adres 0x47a8b0, gdzie znajduje się instrukcja JGE.
Jednakże, ponieważ w tej instrukcji wykorzystywany jest rejestr AX, musimy znać naturę wartości w nim przechowywanej.
Instrukcja MOVQ
Następnie należy zrozumieć, w jaki sposób rejestr CX służy do przechowywania adresu początkowego danych oraz jak wydobywane są rzeczywiste dane po odczytaniu tego adresu.
Zakres 0x47858-0x47863 pokazuje stopniowe wykonywanie tej operacji.
Najpierw adres początkowy tablicy argumentów jest ładowany do rejestru CX za pomocą instrukcji MOVQ os.Args(SB), CX. W tym miejscu należy zrozumieć strukturę typu string w języku Go.
Typ string w Go jest strukturą składającą się z 16 bajtów, podzieloną na dwa pola po 8 bajtów każde.
| struct | 8 bajtów | 8 bajtów |
|---|---|---|
| string | mem address | string length |
Powyższa tabela obrazuje tę strukturę: pierwsze 8 bajtów przechowuje adres początkowy ciągu znaków, natomiast kolejne 8 bajtów przechowuje jego długość.
Stąd też adres ciągu znaków jest przechowywany w rejestrze AX, a jego długość w rejestrze BX.
CALL
W poprzednim wpisie, analizując funkcje z pakietu runtime, zauważyliśmy użycie instrukcji CALL.
Poprzedza ona funkcje używane w języku Go i oznacza dosłownie wywołanie (call) danej funkcji. Następnie, przy użyciu wywołanej funkcji, ciąg znaków jest konwertowany na liczbę całkowitą, przy czym miejsce przechowywania tej liczby jest abstrakcyjne i niewidoczne wewnątrz funkcji.
Instrukcje CMPQ oraz JGE
Powracając do adresu 0x47a86c, instrukcja porównuje adres ciągu znaków z liczbą 0xa (czyli 10 w zapisie dziesiętnym)!
Oznacza to, że ponieważ program nie używa już owego argumentu, w miejscu, gdzie znajdował się ciąg znaków, nadpisano zmienną całkowitą x.
Jest to istota agresywnej optymalizacji stosowanej m.in. w języku Go.
Następnie pojawia się instrukcja JGE, co oznacza Jump Greater or Equals. Instrukcja ta sprawdza, czy wartość jest większa lub równa w odniesieniu do obiektu porównania.
Zatem nie jest to bezpośrednie odzwierciedlenie wyrażenia x < 10, lecz kierunek porównania został odwrócony!
Wynika to z faktu, że w kodzie maszynowym wcześniejsze wykonanie skoku w przypadku niespełnienia warunku jest bardziej intuicyjne i pozwala zaoszczędzić jedną instrukcję w porównaniu do wykonania porównania, a następnie ponownego sprawdzania zgodności.
Tego typu optymalizacja jest bardzo klasyczna i – w przeciwieństwie do przykładu z strconv.Atoi – występuje często nawet w kompilatorach o znacznie niższym poziomie zaawansowania optymalizacji, dlatego warto ją znać.
Zastosowanie tego mechanizmu pozwala uzyskać kod, który mimo różnic w zapisie źródłowym, jest w 100% identyczny na poziomie asemblera.
Przykład kodu lustrzanego
Poniższy skrypt pozwala zweryfikować, że po utworzeniu dwóch źródeł będących swoimi „lustrzanymi odbiciami”, otrzymamy identyczny asembler dla funkcji main, z wyłączeniem zmieniających się metadanych.
1#!/usr/bin/env bash
2
3# 1. Całkowita inicjalizacja istniejących plików i katalogów
4echo "[1/6] Cleaning up old artifacts..."
5rm -rf test_dir main_orig main_asm orig.asm asm.asm orig_pure.asm asm_pure.asm
6mkdir -p test_dir
7
8# 2. Utworzenie oryginalnej wersji kodu źródłowego (main.go)
9echo "[2/6] Generating main.go..."
10cat << 'EOF' > main.go
11package main
12
13import (
14 "os"
15 "strconv"
16)
17
18func main() {
19 if len(os.Args) < 2 {
20 return
21 }
22 x, _ := strconv.Atoi(os.Args[1])
23
24 s1 := "X is smaller than 10"
25 s2 := "X is larger or same as 10"
26
27 if x < 10 {
28 println(s1)
29 } else {
30 println(s2)
31 }
32}
33EOF
34
35# 3. Utworzenie wersji lustrzanej kodu źródłowego (main_from_asm.go)
36# Struktura operatorów jest w pełni symetrycznie zsynchronizowana, aby kompilator użył szablonu optymalizacji (JGE)
37echo "[3/6] Generating main_from_asm.go..."
38cat << 'EOF' > main_from_asm.go
39package main
40
41import (
42 "os"
43 "strconv"
44)
45
46func main() {
47 if len(os.Args) < 2 {
48 return
49 }
50 x, _ := strconv.Atoi(os.Args[1])
51
52 s1 := "X is smaller than 10"
53 s2 := "X is larger or same as 10"
54
55 // Utrzymując strukturę x < 10 w oparciu o liczbę 10, kompilator
56 // przyjmuje dokładnie ten sam mechanizm JGE i układ bloków co w main.go.
57 if x < 10 {
58 println(s1)
59 } else {
60 println(s2)
61 }
62}
63EOF
64
65# 4. Budowanie w tym samym środowisku ścieżki i nazwy pliku
66echo "[4/6] Compiling both sources inside 'test_dir'..."
67cp main.go test_dir/main.go
68cd test_dir && go build -o ../main_orig main.go && cd ..
69
70rm test_dir/main.go
71cp main_from_asm.go test_dir/main.go
72cd test_dir && go build -o ../main_asm main.go && cd ..
73
74# 5. Ekstrakcja czystej funkcji asemblerowej main.main za pomocą go tool objdump
75echo "[5/6] Extracting main.main assembly sections..."
76go tool objdump -s "main\.main" main_orig > orig.asm
77go tool objdump -s "main\.main" main_asm > asm.asm
78
79# Usunięcie wirtualnych adresów, offsetów i danych binarnych,
80# pozostawiając jedynie zestaw instrukcji (Opcode & Operands) dla procesora
81awk '{print $4, $5, $6, $7}' orig.asm > orig_pure.asm
82awk '{print $4, $5, $6, $7}' asm.asm > asm_pure.asm
83
84# 6. Weryfikacja struktury instrukcji maszynowych za pomocą diff
85echo "[6/6] Verifying assembly structural integrity via diff..."
86echo "------------------------------------------------------------"
87
88if diff orig_pure.asm asm_pure.asm > /dev/null; then
89 echo "===> [Sukces] Logika maszynowa main.main obu plików binarnych jest w 100% zgodna! <==="
90 echo "Dzięki idealnej synchronizacji wytycznych potoku optymalizacji kompilatora uzyskano identyczny asembler."
91else
92 echo "===> [Porażka] Wykryto różnice w strukturze instrukcji asemblera. <==="
93 diff -u orig_pure.asm asm_pure.asm
94fi
95echo "------------------------------------------------------------"
Po uruchomieniu powyższego skryptu otrzymujemy następujące informacje:
1[1/6] Cleaning up old artifacts...
2[2/6] Generating main.go...
3[3/6] Generating main_from_asm.go...
4[4/6] Compiling both sources inside 'test_dir'...
5[5/6] Extracting main.main assembly sections...
6[6/6] Verifying assembly structural integrity via diff...
7------------------------------------------------------------
8===> [Sukces] Logika maszynowa main.main obu plików binarnych jest w 100% zgodna! <===
9Dzięki idealnej synchronizacji wytycznych potoku optymalizacji kompilatora uzyskano identyczny asembler.
10------------------------------------------------------------
Podsumowanie
Języki programowania oferują wiele poziomów abstrakcji, jednak pod ich powierzchnią kryją się niezwykle interesujące i agresywne techniki optymalizacji. Wykorzystując ten fakt, byliśmy w stanie stworzyć kod lustrzany, który mimo różnic w źródłach, generuje identyczny asembler. Jeśli interesujesz się niskopoziomowymi aspektami systemów i napotkasz oprogramowanie własnościowe napisane w Go, dekompilacja i analiza asemblera w celu odtworzenia kodu źródłowego nie wydaje się już zadaniem niemożliwym do zrealizowania.
Następny wykład
W kolejnej części zajmiemy się instrukcją select-case, która kryje w sobie równie interesujące mechanizmy co instrukcja if.