--- id: 04e03e046bb46ab34aaeeed79279923b author: Lee Yunjin title: Go-voorwaardelijke instructies (if) in AMD64-assemblercodegeneratie en analyse van branch-instructies description: De Go-compiler vertaalt if-else-voorwaardelijke instructies naar AMD64-machinecodetakinstructies zoals CMPQ, JGE en JMP, en vergelijkt dit proces met de takcodegeneratie van de C-compiler (-O2). language: nl date: 2026-05-17T12:00:00Z path: /blog/posts/go-if-statement-analysis-3012d30c category: lowlevel --- ## If-statements in Go Allereerst is de reden dat we voor Go hebben gekozen dat Go onder de moderne talen de meest 'elegante' assembly oplevert, en dat de efficiëntie van de syntaxis zelfs in vergelijking met klassieke talen soms overweldigend is. Nu we in de vorige les het gedrag van een eenvoudig Go-programma hebben begrepen, gaan we Go en Assembly meteen regel voor regel met elkaar vergelijken. ### Broncode Allereerst optimaliseren moderne compilers, en dat geldt niet alleen voor Go maar ook voor compilers zoals GCC, automatisch vertakkingen die geen nut hebben. Ook C-compilers zoals GCC en Clang voeren bij de industriestandaard -O2 zeer agressieve optimalisaties uit, waardoor de tijd waarin programmeurs de compiler niet volledig konden vertrouwen, in feite al aan het einde van de twintigste eeuw voorbij was. Daarom heeft het alleen zin om voorwaarden te gebruiken die voor de compiler moeilijk te voorspellen zijn en daardoor niet eenvoudig door een andere constructie vervangen kunnen worden. ```go package main import ( "os" "strconv" ) func main() { // Als we dit vervangen door iets voorspelbaars zoals x = 10, waarbij de vertakking verwijderd kan worden, // dan verwijdert de compiler de vertakking door optimalisatie. // Om dit daarom zelf als assembly te bekijken, zet men in C bijvoorbeeld -O0 aan, of laat men // de compiler een externe waarde gebruiken die niet voorspeld kan worden, // maar deze sectie behandelt modern programmeren, dus de methode waarbij de binaire optimalisatie van Go // wordt uitgeschakeld, wordt niet gebruikt. if len(os.Args) < 2 { return } x, _ := strconv.Atoi(os.Args[1]) if x < 10 { println("X is smaller than 10") } else { println("X is larger or same as 10") } } ``` In dit geval kan de compiler de invoer niet voorspellen, dus de vertakking wordt zonder wijzigingen naar machinecode vertaald. ### Assembly ```asm TEXT main.main(SB) /home/yjlee/introduction-to-golang/learn-golang/if-and-switch/golang-if/main.go main.go:8 0x47a840 493b6610 CMPQ SP, 0x10(R14) main.go:8 0x47a844 7670 JBE 0x47a8b6 main.go:8 0x47a846 55 PUSHQ BP main.go:8 0x47a847 4889e5 MOVQ SP, BP main.go:8 0x47a84a 4883ec10 SUBQ $0x10, SP main.go:15 0x47a84e 48833d12fb0a0002 CMPQ os.Args+8(SB), $0x2 main.go:15 0x47a856 7c58 JL 0x47a8b0 main.go:15 0x47a858 488b0d01fb0a00 MOVQ os.Args(SB), CX main.go:18 0x47a85f 488b4110 MOVQ 0x10(CX), AX main.go:18 0x47a863 488b5918 MOVQ 0x18(CX), BX main.go:18 0x47a867 e834e8ffff CALL strconv.Atoi(SB) main.go:20 0x47a86c 4883f80a CMPQ AX, $0xa main.go:20 0x47a870 7d1d JGE 0x47a88f main.go:21 0x47a872 e809befbff CALL runtime.printlock(SB) main.go:21 0x47a877 488d0519f50100 LEAQ 0x1f519(IP), AX main.go:21 0x47a87e bb15000000 MOVL $0x15, BX main.go:21 0x47a883 e878c6fbff CALL runtime.printstring(SB) main.go:21 0x47a888 e853befbff CALL runtime.printunlock(SB) main.go:21 0x47a88d eb1b JMP 0x47a8aa main.go:23 0x47a88f e8ecbdfbff CALL runtime.printlock(SB) main.go:23 0x47a894 488d05c8040200 LEAQ 0x204c8(IP), AX main.go:23 0x47a89b bb1a000000 MOVL $0x1a, BX main.go:23 0x47a8a0 e85bc6fbff CALL runtime.printstring(SB) main.go:23 0x47a8a5 e836befbff CALL runtime.printunlock(SB) main.go:25 0x47a8aa 4883c410 ADDQ $0x10, SP main.go:25 0x47a8ae 5d POPQ BP main.go:25 0x47a8af c3 RET main.go:16 0x47a8b0 4883c410 ADDQ $0x10, SP main.go:16 0x47a8b4 5d POPQ BP main.go:16 0x47a8b5 c3 RET main.go:8 0x47a8b6 e845f0feff CALL runtime.morestack_noctxt.abi0(SB) main.go:8 0x47a8bb eb83 JMP main.main(SB) ``` Met het go tool-commando krijg je op een handige manier te zien welke broncoderegel overeenkomt met welke assembly-instructie. Omdat we nu vergelijkingen en if-vertakkingen gaan leren, hoeven we alleen een paar regels in de gaten te houden. ### CMPQ-instructie & JL-instructie De instructie `CMPQ` is bedoeld om gegevens van het type 4 bytes (4 woorden) te vergelijken, en de naam is afgeleid van **C**o**MP**are**Q**uadword, afgekort tot **CMPQ**. Bij het geheugenadres `0x47a84e` staat de instructie `CMPQ os.Args+8(SB), $0x2`. In dit geval wordt het aantal ontvangen argumenten van het programma vergeleken met het hexadecimale getal `0x2` (dat wil zeggen gewoon 2). Vervolgens wordt via `JL` na de vergelijking een sprong uitgevoerd als het aantal argumenten kleiner is dan 2 (dat wil zeggen als het programma alleen zijn eigen naam als argument heeft). Dit is de afkorting van **J**ump, **L**ess than', dus **JL**. Als het aantal argumenten bij de voorgaande vergelijking kleiner was dan 2, springt het programma naar adres `0x47a8b0`, en daar staat een `JGE`. Maar omdat deze instructie het `AX`-register gebruikt, moet men weten welke waarde in dat register is opgeslagen. ### MOVQ-instructie Daarna moet men begrijpen hoe het register 'CX' wordt gebruikt om het startadres van de gegevens op te slaan, en hoe de werkelijke gegevens na het lezen van dat adres worden geëxtraheerd. In het bereik `0x47858`-`0x47863` zie je dat deze bewerking stap voor stap wordt uitgevoerd. Eerst wordt het startadres van de argumentenarray met de instructie `MOVQ os.Args(SB), CX` in het register CX geplaatst. Hierbij moet men het stringtype van Go begrijpen. Een `string` in Go is een struct, en deze struct bestaat uit twee gegevens van 8 bytes, dus in totaal 16 bytes. | struct | 8 byte | 8 byte | | ------ | ----------- | ------------- | | string | geheugenadres | stringlengte | Visueel ziet dit er zo uit als hierboven: de eerste 8 bytes bevatten het startadres van de string en de laatste 8 bytes bevatten de lengte van de string. Daarom wordt het adres van de string in het register AX opgeslagen, en de lengte van de string in het register BX. ### CALL Ook in het vorige bericht, toen we de functies uit het `runtime`-pakket bekeken, stond de instructie CALL ervoor. Deze staat voor de functies die in Go worden gebruikt, en betekent letterlijk dat een functie wordt **aangeroepen**, vandaar de naam CALL. Vervolgens wordt met een CALL-functie de string omgezet naar een geheel getal, en waar dit gehele getal wordt opgeslagen, _is niet zichtbaar omdat dit in de functie is geabstraheerd._ ### CMPQ-instructie & JGE-instructie Als we terugkeren naar het eerdere adres `0x47a86c`, dan vergelijkt de instructie **het adres van de string met het getal `0xa` (decimaal 10)!** Dit betekent dat, omdat het programma dit argument niet meer gebruikt, **de variabele `x` van het type geheel getal is gemaakt door de plaats van de string te overschrijven.** Dit is de werkelijke aard van de agressieve optimalisatie die in talen zoals Go wordt toegepast. Vervolgens verschijnt de instructie `JGE`, een afkorting van **J**ump, **G**reater or **E**quals. Deze instructie vraagt dus of de waarde groter is dan of gelijk is aan de vergelijkingswaarde. Dus de code is niet precies gelijk aan `x < 10`, maar `x < 10` is als vergelijking gebruikt met de **vergelijkingsrichting omgekeerd!** In machinecode is dit zo omdat het vooraf overslaan van de code wanneer de voorwaarde niet geldt, **intuïtiever is en één instructie bespaart**, vergeleken met eerst de vergelijking uitvoeren wanneer de voorwaarde wel geldt en daarna opnieuw controleren of deze niet overeenkomt. Deze optimalisatie is zeer klassiek, en in tegenstelling tot het eerder besproken voorbeeld met `strconv.Atoi` is het een patroon dat ook vaak voorkomt bij compilers met een relatief lage optimalisatiegraad, dus het is nuttig om dit te weten. Door dit toe te passen kan men dus broncode verkrijgen die verschilt, maar op assemblyniveau voor 100% overeenkomt. ### Spiegelbeeldcode-voorbeeld Met het onderstaande script kan worden geverifieerd dat het bash-script twee broncodes van 100% spiegelbeeld maakt en dat, wanneer men alleen `main` bekijkt en de metadata die per keer verschilt buiten beschouwing laat, exact dezelfde assembly wordt verkregen. ```bash #!/usr/bin/env bash # 1. Volledig opschonen van bestaande resterende bestanden en mappen echo "[1/6] Cleaning up old artifacts..." rm -rf test_dir main_orig main_asm orig.asm asm.asm orig_pure.asm asm_pure.asm mkdir -p test_dir # 2. Schrijf de broncode van de originele versie (main.go) echo "[2/6] Generating main.go..." cat << 'EOF' > main.go package main import ( "os" "strconv" ) func main() { if len(os.Args) < 2 { return } x, _ := strconv.Atoi(os.Args[1]) s1 := "X is smaller than 10" s2 := "X is larger or same as 10" if x < 10 { println(s1) } else { println(s2) } } EOF # 3. Schrijf de broncode van de spiegelbeeldversie (main_from_asm.go) # De operatorstructuur wordt volledig symmetrisch gesynchroniseerd, zodat de compiler het optimalisatiesjabloon (JGE) ongewijzigd gebruikt echo "[3/6] Generating main_from_asm.go..." cat << 'EOF' > main_from_asm.go package main import ( "os" "strconv" ) func main() { if len(os.Args) < 2 { return } x, _ := strconv.Atoi(os.Args[1]) s1 := "X is smaller than 10" s2 := "X is larger or same as 10" // Door 10 als referentie te nemen en de structuur x < 10 te behouden, kiest de compiler // exact hetzelfde JGE-mechanisme en dezelfde blokindeling als main.go. switch { case x < 10: println(s1) default: println(s2) } } EOF # 4. Bouw beide in dezelfde mappad- en bestandsnaamomgeving echo "[4/6] Compiling both sources inside 'test_dir'..." cp main.go test_dir/main.go cd test_dir && go build -o ../main_orig main.go && cd .. rm test_dir/main.go cp main_from_asm.go test_dir/main.go cd test_dir && go build -o ../main_asm main.go && cd .. # 5. Haal de pure main.main-assemblyfunctie op met go tool objdump echo "[5/6] Extracting main.main assembly sections..." go tool objdump -s "main\.main" main_orig > orig.asm go tool objdump -s "main\.main" main_asm > asm.asm # Verwijder de virtuele adressen, offsets en machinecode-bytetekst # en filter alleen de velden met de zuivere instructieset die de CPU zal uitvoeren (Opcode & Operands) awk '{print $4, $5, $6, $7}' orig.asm > orig_pure.asm awk '{print $4, $5, $6, $7}' asm.asm > asm_pure.asm # 6. Verifieer de machinecode-instructiestructuur van beide met diff echo "[6/6] Verifying assembly structural integrity via diff..." echo "------------------------------------------------------------" if diff orig_pure.asm asm_pure.asm > /dev/null; then echo "===> [성공] 두 바이너리의 main.main 기계어 로직이 100% 일치합니다! <===" echo "컴파일러의 최적화 파이프라인 가이드라인을 완벽하게 동기화하여 동일한 어셈블리를 얻었습니다." else echo "===> [실패] 어셈블리 명령어 구조에 차이점이 발견되었습니다. <===" diff -u orig_pure.asm asm_pure.asm fi echo "------------------------------------------------------------" ``` Wanneer je het bronprogramma daadwerkelijk uitvoert, krijg je onderstaande informatie. ```text [1/6] Cleaning up old artifacts... [2/6] Generating main.go... [3/6] Generating main_from_asm.go... [4/6] Compiling both sources inside 'test_dir'... [5/6] Extracting main.main assembly sections... [6/6] Verifying assembly structural integrity via diff... ------------------------------------------------------------ ===> [성공] 두 바이너리의 main.main 기계어 로직이 100% 일치합니다! <=== 컴파일러의 최적화 파이프라인 가이드라인을 완벽하게 동기화하여 동일한 어셈블리를 얻었습니다. ------------------------------------------------------------ ``` ### Conclusie Programmeertalen bieden veel abstractie, maar achter die abstractie schuilen zeer interessante en agressieve optimalisaties. Door dit om te keren, konden we ook spiegelbeeldcode maken die verschilt in broncode maar identieke assembly oplevert. Als je geïnteresseerd bent in laag-niveau programmeren en je komt proprietaire software in Go tegen, lijkt het niet onmogelijk om de assembly zelf te ontleden en zo de broncode te reconstrueren. ## Volgende les In de volgende les bekijken we, naast if-statements, ook de `select-case`-instructie, die eveneens interessant is.