Hænderne op, træd væk fra tastaturet, det der ligner assemblerkode!

En af de klogeste ting der nogensinde er sket i C sproget, var da man introducerede "volatile" til at forklare compilere hvornår ting ikke kan caches.

Groft sagt, betyder "volatile int foo" at små grønne aliens kan finde på at ændre værdien af denne variabel med deres usynlige antistofvåben, mens programmet kører og compileren derfor altid skal sørge for at hente den seneste værdi OG at compileren heller ikke må bortoptimere skrivninger til variablen.

I forhold til det midten af firserne 68k-kode jeg er ved at disassemblere, er moderne compilere rene sataner til at optimere og derfor er det vigtigere end nogen sinde at forhindre dem i det, når man presser performance citronen.

Lige nu sidder jeg og stirrer på en 66 linier lang C funktion, der laver lookup/insert på et critbit træ, og de 476 linier assemblerkode der kommer ud af det, for at finde ud af hvorfor en variabel som jeg er helt sikker på jeg havde klistret til med "volatile" ikke opfører sig som sådan.

Princippet her er, at en lookup kan laves uden lås, fordi alle branch-points er "stable storage" lang tid nok, til at alle er sluppet ud, inden de smides væk. Skal man indsætte eller fjerne et element skal man have låsen, men det er ofte kun 0.1% af trafikken der har brug for det, så der bliver ingen contention og lookups kører uforstyrret videre imens.

En af de ting der kan få unge uerfarne mennesker til at blive helt våde i bukserne, ihvertfald når man taler multiprogrammering, er den slags "lockless datastructures": Det er simpelthen den hellige gral, datalogernes svar på det gnidningsfrie knald: Drømmen om multiprogrammering uden at skulle vente på hinanden og uden fare for deadlock osv.

Problemet er at det er svært at kode rigtigt og vi taler ikke blot almindeligt "to kopper kaffe svært" her, vi taler problemer af en karakter hvor folk ofte skriver prototypen i assembler, for på den måde at udskyde slagsmålet med compileren og "volatile" til senere.

Assembler er i den grad "yt" idag, at vi i FreeBSD projektet i gennemsnit ikke har kunnet mønstre mere end fem personer der var gode til det og det har, langt hen ad vejen, været de samme fem personer i 15 år.

Men nu er der begyndt at dukke nye assemblerprogrammører op og de er faktisk ret gode til det, for de har brugt deres ungdom på at lede efter sikkerhedshuller i Windows, Acrobat og Flash.

Der er ikke mange andre måder at lære assembler på, end at prøve at finde ud af hvad et program gør, ved at følge det instruktion for instruktion[1] og deres motivation er ikke væsentlig anderledes, end da vi andre disassemblerede DOMUS og C-64 ROM'en.

Det der bekymrer mig, er at det allerede er blevet forbudt at eje en erlenmeyerflaske i Texas, fordi den kan bruges til at brygge narko i.

Det kan vi naturligvis godt grine hånligt af, men man kan ikke købe brintoverilte i Danmark mere, selvom det har mange fornuftige anvendelser.

Skulle der være nogen tvivl om at tryghedspolitiet er gået helt i selvsving kan I prøve at overbevise mig om, at Danmarks befolkning for ti år siden ville have fundet sig i at skulle lade sig kropsvisitere barfodet og kun kunne tage 8 skefulde shampoo med, på en flytur til London.

Jeg kan ikke forestille mig andet end at assemblerkode kommer under terrorlovgivningen, hvis tryghedspensionisterne i Folketinget nogensinde fatter hvad jeg taler om her...

Nyd det mens det er lovligt.

phk

[1] Jeg formoder at Peter Naur, Jørn Jensen og de slæng må have lært det på den virkelig hårde måde. Hatten af for det, ikke mindst DASK og GIERs instruktionssæt taget i betragtning.

Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Holm Jensen

---> Jeg kan ikke forestille mig andet end at assemblerkode kommer under terrorlovgivningen, hvis tryghedspensionisterne i Folketinget nogensinde fatter hvad jeg taler om her... <---- men bare rolig, det gør de ikke

mvh Peter

  • 0
  • 0
Mark Ruvald Pedersen

On topic: PHK, kan du ikke single steppe igennem med en debugger og se hvor der brydes med forventet opførsel?

Off topic: Ja assembler til at afvikle asm-shell code, men alle véd da at Google code search er den nemmeste måde at finde sikkerhedshuller med.

Fx: http://www.google.com/codesearch?hl=en&lr=&q=lang:c%2B%2B+for(.%2B;.%2B....;-+[2-9][0-9]*&sbtn=Search

  • 0
  • 0
Claus Jørgensen

Assembler er nu ellers ret almindeligt i dag, men det er mere brugt til DLL injections for at snyde i diverse online-spil og til at fjerne kopibeskyttelser for at lave piratkopier*.

IDA Disassembler er et utrolig populært værktøj.

Men da spilhackning er en skyggeside, kræves det selvfølgelig at man kender til miljøet for at vide hvor stort et omfang Assembler bruges i det.

  • Begge dele er da heldigvis også stadigvæk lovligt ifølge Dansk Lovgivning. (Så længe man ikke videredistribuere noget der er copyrighted.)
  • 0
  • 0
Daniel Madsen

PHK, kan du ikke single steppe igennem med en debugger og se hvor der brydes med forventet opførsel?

Det er uhyre svært at debugge raceconditions ved at single steppe sig igennem i en debugger - i det hele taget virker diverse visuelle debuggers ikke særlig godt til multi-trådet debugging. Et andet problem er at sådanne debuggere normalt arbejder på non-optimized kode og hvis problemet skyldes lidt for smart compiler-optimering, så opdager du det aldrig.

Prøv at implementer en lock-free datastruktur, som PHK omtaler og du får et andet syn på debugging :-)

  • 0
  • 0
Log ind eller Opret konto for at kommentere