Original: Kom i gang på monteringsspråk. Del 1
Forfatter: Mike Saunders
Publiseringsdato: 30. oktober 2015
Oversettelse: A. Panin
Overføringsdato: 10. november 2015

Del 1: Å overvinne begrensningene ved programmeringsspråk på høyt nivå og forstå hvordan CPUen faktisk fungerer.

Hva er den til?

• For å forstå hvordan kompilatorer fungerer.
• For å forstå instruksjonene til CPUen.
• For å optimalisere koden for ytelse.

De fleste mennesker tror at monteringsspråk ikke er mye forskjellig fra svart magi og er en del av en mørk og skummel verden som bare 0,01% av de beste utviklerne risikerer å komme inn på programvare... Men faktisk er det vakkert og veldig tilgjengelig språk programmering. Du bør studere det grunnleggende i det minste for å bedre forstå mekanismen for kodegenerering av kompilatorer, prinsippet om drift av sentrale prosessorer, og også for å bedre forstå prinsippet om drift av datamaskiner. Monteringsspråk er egentlig en tekstlig fremstilling av instruksjoner som sentralprosessoren utfører, med noen tilleggsfunksjoner som forenkler programmeringsprosessen.

I dag ville ingen med sitt rette sinn utvikle et kraftig skrivebordsprogram på monteringsspråk. Tross alt vil koden til et slikt program være for forvirrende, prosessen med feilsøking av applikasjonen vil være mye mer komplisert, i tillegg vil det ta enorme anstrengelser å portere dette programmet for å jobbe med andre CPU-arkitekturer. Men samtidig brukes forsamlingsspråk fortsatt til forskjellige formål: mange drivere fra Linux-kjernen inneholder fragmenter av kode på monteringsspråk, som brukes både fordi det er det beste programmeringsspråket for direkte samhandling med maskinvaren, og av grunner for å øke hastigheten til sjåførene. I noen tilfeller kan kode skrevet for hånd på forsamlingsspråk også fungere raskere enn kode generert av kompilatoren.

Gjennom hele denne serien vil vi utforske verden av monteringsspråk i detalj. I denne artikkelen vil vi bare vurdere grunnleggende programmeringsteknikker, i en artikkel fra neste utgave av tidsskriftet vil vi håndtere mer vanskelige problemer Etter det avslutter vi diskusjonen om monteringsspråk ved å skrive et enkelt oppstartbart operativsystem - det vil ikke være i stand til å gjøre noe nyttig arbeid, men det vil være basert på koden din og jobbe direkte med maskinvaren uten å måtte last inn et hvilket som helst tredjeparts OS. Høres bra ut, ikke sant? la oss begynne

Ditt første språkprogram for montering

Mange programmeringsguider for monteringsspråk starter med lange, kronglete og kjedelige seksjoner som går uendelig med spørsmål om binær aritmetikk og CPU-designteori, uten noen ekte kode. Jeg tror at slike materialer negerer leserens interesse, så vi begynner direkte med å se på koden. ekte program... Etter det vil vi se på hver av kodelinjene i dette programmet, slik at du forstår hvordan montøren fungerer basert på et praktisk eksempel.

Noen tekstredigerere, for eksempel Vim, gir syntaksutheving for forspråkssamling (prøv å bruke angi kommando syn = nasm)

Kopier følgende kode i hvilken som helst tekstboks tekstredigerer og lagre den i en fil som heter myfirst.asm i hjemmekatalogen din:

Seksjon .text global _start _start: mov ecx, melding mov edx, lengde mov ebx, 1 mov eax, 4 int 0x80 mov eax, 1 int 0x80 seksjon. Data melding db "Assembly rules!", 10 lengde ekv $ - melding

(Merk: Du kan bruke både mellomrom og faner til å kutte inn koden din - det spiller ingen rolle.) Dette programmet skriver bare ut strengen "Assembly rules!" på skjermen og går ut.

Verktøyet vi skal bruke til å konvertere denne samlingsspråkkoden til en kjørbar binær, har et ganske morsomt navn "assembler". Det er mange forskjellige montører der ute, men min favorittmontør er NASM; den ligger i programvarepakkedepotet til nesten hvilken som helst distribusjon, slik at du kan installere den ved hjelp av en programvarepakkebehandling med grafisk grensesnitt, yum install nasm, apt-get install nasm, eller en hvilken som helst annen kommando som er relevant for distribusjonen din.

Åpne nå et terminalemulatorvindu og skriv inn følgende kommandoer:

Nasm -f alf -o myfirst.o myfirst.asm ld -m elf_i386 -o myfirst myfirst.o

Den første kommandoen er at NASM skal generere en (kjørbar) objektkodefil med navnet myfirst.o i ELF-format (Linux-kjørbart filformat). Du kan spørre: "Hva genereres objektkodefilen, siden det er mer logisk å generere en fil med instruksjoner fra sentralprosessoren som den skal utføre?" Vel, du kan bruke en kjørbar med CPU-instruksjoner i 80-tallet operativsystemer, men moderne operativsystemer har flere krav til kjørbare filer. ELF-binærfiler inkluderer feilsøkingsinformasjon, de lar deg skille kode og data ved å ha separate seksjoner, som forhindrer overskriving av data i disse seksjonene.

Senere, i ferd med å se på hvordan vi kan skrive kode for å fungere direkte med maskinvare (for vårt minimalistiske operativsystem) i denne artikelserien, vil vi også ta hensyn til slike binærfiler med instruksjoner for sentralprosessoren.

Et blikk inn i fortiden

På dette øyeblikket vi har til rådighet filen myfirst.o med den kjørbare koden til programmet vårt. I dette tilfellet er prosessen med å bygge programmet ennå ikke fullført; ved hjelp av ld linker, må vi koble koden fra denne filen med den spesielle systemkoden for å starte programmer (dvs. malkode som utføres når hvert program startes) for å generere kjørbar fil kalt min første. (Parameteren elf_i386 beskriver typen binært format - i denne saken Dette betyr at du kan bruke 32-biters samlingskode selv om du bruker en 64-biters distribusjon.)

Hvis byggeprosessen programmene vil finne sted vellykket, bør du kunne utføre programmet ditt med følgende kommando:

Som et resultat bør du se utdataene: "Monteringsregler!". Dette betyr at du har nådd målet ditt - du har opprettet et fullverdig uavhengig program for Linux, hvis kode er skrevet helt på monteringsspråk. Selvfølgelig dette programmet oppfyller ingen nyttige handlinger, men samtidig er det et utmerket eksempel som demonstrerer strukturen til et program på monteringsspråk og lar deg spore konverteringsprosessen kildekode til en binær fil.

Før vi dykker inn i koden dypere, vil det være lurt å vite størrelsen på programmets binære. Etter å ha kjørt kommandoen ls -l myfirst, vil du se at størrelsen på den binære filen er omtrent 670 byte. La oss nå estimere størrelsen på det tilsvarende C-programmet:

#inkludere int main () (puts ("Assembly rules!");)

Hvis du lagrer denne koden i en fil som heter test.c, kompilerer den (gcc -o test test.c) og ser på parametrene til den resulterende binære kalt test, vil du oppdage at denne filen er mye større - 8,4k. Du kan fjerne feilsøkingsinformasjon fra denne filen (strip -s test), men selv etter det vil størrelsen bli redusert litt, bare til 6 k. Dette er fordi GCC-kompilatoren legger til mye av ovennevnte kode for å starte og stoppe applikasjonen, og også koble applikasjonen til C-biblioteket. stor størrelse... Takket være dette eksemplet er det lett å konkludere med at monteringsspråk er det beste programmeringsspråket for å utvikle applikasjoner designet for å fungere under forhold med et svært begrenset lagringsmedium.

Det skal nevnes at mange utviklingssamlingsutviklere mottar gode lønninger for å utvikle kode for ressursbegrensede innebygde enheter, og det er derfor monteringsspråk er det eneste. reelt alternativ for å utvikle spill for gamle 8-biters konsoller og hjemme-datamaskiner.

Demontering av kode

Det er morsomt å utvikle ny kode, men å undersøke andres arbeid kan være enda morsommere. Takket være et verktøy som heter objdump (fra Binutils-pakken), kan du "demontere" en kjørbar fil, nemlig konvertere CPU-instruksjoner til deres tekstekvivalenter. Prøv å bruke dette verktøyet i forhold til den myfirst binære vi jobbet med i denne håndboken, på følgende måte:

Objdump -d -M intel myfirst

Du vil se en liste over instruksjoner fra kodeseksjonen i binærprogrammet. For eksempel ser den første instruksjonen som vi legger strenginformasjonen vår til i ecx-registeret slik:

Mov ecx, 0x80490a0

Under montering erstattet NASM "melding" -etiketten med en numerisk verdi som tilsvarer plasseringen av denne linjen i dataseksjonen i den binære filen. Så resultatene av demontering av binærfiler er mindre nyttige enn deres original kode fordi de mangler ting som kommentarer og linjer, men de kan fortsatt være nyttige for å lære om implementeringer av tidskritiske funksjoner eller bryte applikasjonssikkerhetssystemer. For eksempel brukte mange utviklere på 1980- og 1990-tallet verktøy for demontering av programvare for å identifisere og nøytralisere beskyttelsessystemer for spill.

Du kan også demontere programmer som er utviklet med andre programmeringsspråk, men de resulterende demonteringsresultatene kan være betydelig kompliserte. For eksempel kan du kjøre ovennevnte objdump-kommando mot binær / bin / ls og evaluere tusenvis av linjer med kodeseksjonen selv, generert av kompilatoren fra den opprinnelige C-kildekoden til verktøyet.

Kodeanalyse

La oss nå diskutere formålet med hver av kodelinjene i programmet vårt. La oss starte med disse to linjene:

Seksjon .text global _start

Dette er ikke CPU-instruksjoner, men monteringsdirektiver NASM; det første direktivet sier at koden nedenfor skal være plassert i "tekst" -delen av den endelige kjørbare filen. Litt uopplagt er det faktum at seksjonen kalt "tekst" ikke inneholder ordinære tekstdata (for eksempel vår streng "Assembly rules!"), Men kjørbar kode, dvs. instruksjoner fra sentralprosessoren. Deretter er det globale _start-direktivet, som forteller ld-linkeren hvor du skal begynne å utføre koden fra filen vår. Dette direktivet kan være spesielt nyttig hvis vi ikke vil starte kodekjøring ikke helt fra begynnelsen av kodeseksjonen, men fra noen settpunkt... Den globale parameteren gjør at dette direktivet kan leses ikke bare av samleren, men også av andre verktøy, så det behandles av ld linker.

Som nevnt ovenfor, må kodeutførelse starte fra _start-posisjonen. I lys av dette angir vi eksplisitt riktig posisjon i koden vår:

Enkeltord med kolontegn på slutten kalles etiketter og er ment å indikere posisjoner i koden vi kan hoppe til (mer om dette i neste artikkel i serien). Dermed starter gjennomføringen av programmet fra denne linjen! I tillegg har vi endelig nådd den første virkelige CPU-instruksjonen:

Mov ecx, melding

Monteringsspråk er egentlig et sett med minnesmerker for instruksjoner for sentral prosesseringsenhet (eller maskinkode). I dette tilfellet er mov en av slike instruksjoner - den kan også skrives i et binært format som er forståelig for sentralprosessoren, som 10001011. Men å jobbe med binære data kan bli et mareritt for oss, vanlige folk så vi vil bruke disse mer lesbare alternativene. Assembler bare konverterer tekstinstruksjoner til deres binære ekvivalenter - selv om det kan gjøre mer arbeid, noe vi vil snakke om i de neste artiklene i serien.

For å forstå formålet med denne kodelinjen, må vi uansett forstå begrepet registre. Sentrale prosessorer utfører ikke spesielt kompliserte operasjoner - de flytter bare data i minnet, bruker det til å utføre beregninger og utfører andre operasjoner avhengig av resultatene. CPU har ingen anelse om hva en skjerm, mus eller skriver er. Den flytter bare data og utfører flere typer beregninger.

For øyeblikket er hovedlagringen for dataene som brukes av sentralprosessoren RAM-minnene dine. Men på grunn av at RAM-en er utenfor sentralprosessoren, tar det mye tid å få tilgang til den. For å fremskynde og forenkle den beskrevne prosessen inneholder den sentrale prosessoren sin egen lille gruppe minneceller kalt register. CPU-instruksjonene kan bruke disse registerene direkte, og i denne kodelinjen bruker vi et register som heter ecx.

Det er et 32-biters register (dermed kan det lagre tall fra 0 til 4 294 967 295). Ved å revidere følgende linjer kode vil du se at vi også jobber med edx-, ebx- og eax-registerene - dette er generelle formålsregistre som kan brukes til å utføre en hvilken som helst oppgave, i motsetning til de spesialiserte registerene som vi vil bli kjent med i neste måned... Og dette er en liten forklaring for de som er opptatt av å finne ut om opprinnelsen til registernavn: ecx-registeret ble kalt c på tidspunktet for utgivelsen av 8 bitprosessorer, hvoretter den ble omdøpt til cx for lagring av 16-biters verdier og ecx for lagring av 32-biters verdier. Så mens registernavnene ser litt rart ut i dag, brukte utviklere de generiske registerene med de forskjellige navnene a, b, c og d tilbake i dagene til de eldre CPUene.

Når du begynner å jobbe, vil du ikke kunne slutte

Et av problemene vi skal se på neste måned er bruk av stabler, så vi forbereder deg på å ta tak i det akkurat nå. Stabelen er et minneområde der midlertidige verdier kan lagres når registre må frigjøres til andre formål. Men den viktigste funksjonen i stakken er hvordan data lagres i den: du vil "skyve" verdier på stakken og "pope" dem fra den. Bunken bruker LIFO-prinsippet (sist inn, først ut - først inn, sist ut), derfor vil den siste verdien som legges til stabelen være den første som poppes fra den.

Tenk deg at du for eksempel har en tom pakke med Pringles-chips, og du legger ting i den i følgende rekkefølge: en to-lags cracker, et Alpha-token og en GameCube-plate. Hvis du begynner å trekke ut disse tingene, vil du fjerne platen fra GameCube først, deretter symbolet med tegnet "Alpha" og så videre. Når du arbeider med monteringsspråk, brukes stakken som følger:

Trykk 2 trykk 5 trykk 10 pop eax pop ebx pop ecx

Etter å ha utført disse seks instruksjonene, vil eax-registeret inneholde verdien 10, ebx-registeret vil inneholde verdien 5, og ecx-registeret vil inneholde verdien 2. Dermed er bruken av stakken på en flott måte midlertidig frigjøring av registre; hvis for eksempel eax- og ebx-registerene inneholder viktige verdier men du må gjøre det gjeldende arbeidet før du behandler dem, du kan skyve disse verdiene på bunken, gjøre det gjeldende arbeidet og skyve dem av bunken, og gå tilbake til forrige status for registrene.

I tillegg brukes stakken når du ringer til underrutiner for å lagre returadressen til hovedkoden. Av denne grunn må du være ekstra forsiktig når du arbeider med stakken. Hvis du overskriver dataene som er lagret i den, kan du ikke gå tilbake til en tidligere posisjon i hovedapplikasjonskoden og gå en vei mot applikasjonen som krasjer!

Går videre

Tilbake til koden flytter mov-instruksjonen (faktisk kopierer) et nummer fra ett sted til et annet, fra høyre til venstre. Dermed sier vi i dette tilfellet: "du bør legge inn melding i ecx-registeret". Men hva er "melding"? Det er ikke et annet register, det er en peker til plasseringen av dataene. Mot slutten av koden, i "data" -delen av dataene, kan du finne en meldingsetikett etterfulgt av en db-parameter som indikerer at noen få byte skal plasseres i koden i stedet for meldingsetiketten. Dette er veldig praktisk siden vi ikke trenger å finne ut den nøyaktige plasseringen av "monteringsreglene!" i dataseksjonen - vi kan ganske enkelt henvise til den ved hjelp av meldingstaggen. (Tallet 10 etter linjen vår er bare en overgang til ny linje, lik tegnet \ n lagt til strenger i C-programmeringsspråket).

Dermed legger vi dataene om plasseringen av strengen i ecx-registeret. Men det vi gjør videre er spesielt interessant. Som nevnt tidligere har ikke CPU noe egentlig konsept med maskinvareenheter - for å kunne vise noe på skjermen, må du sende data til skjermkortet eller flytte data til RAM på skjermkortet. Men vi har ikke noen informasjon om plasseringen av dette skjermkortet RAM, i tillegg bruker alle forskjellige skjermkort, vindusystem X serveralternativer, vindusadministratorer osv. Basert på dette er direkte utgang av noe til skjermen ved hjelp av et lite program i vårt tilfelle praktisk talt umulig.

Derfor vil vi be OS-kjernen om å gjøre dette for oss. Linux-kjernen gir applikasjoner på lavt nivå et stort nummer av systemanrop, gjennom hvilke applikasjoner kan starte kjøringen av forskjellige operasjoner på kjernenivå. En av disse systemanropene er for visning av en tekststreng. Etter å ha brukt dette systemanropet, kjører OS-kjernen alt nødvendig arbeid- og selvfølgelig gir det et enda dypere abstraksjonsnivå, der en linje kan skrives ut ved hjelp av en vanlig tekstterminal, terminalemulatoren til X-vindussystemet, eller til og med skrives til en fil som tidligere ble åpnet.

Før vi informerer OS-kjernen om behovet for å sende en tekststreng, må vi imidlertid gi den ytterligere informasjon, i tillegg til informasjon om plasseringen av strengen som allerede er i ecx-registeret. Vi må også fortelle ham hvor mange tegn som må skrives ut, slik at utgangen på linjen ikke fortsetter etter at den er avsluttet. Dette er nøyaktig hva linjen fra dataseksjonen nær slutten av applikasjonskoden brukes til:

Lengde tilsvarer $ - melding

Denne linjen bruker en annen etikettlengde, men i stedet for db-parameteren for å binde denne etiketten til noen data, bruker vi parameteren equ for å indikere at den gitte etiketten tilsvarer noe (dette er litt som #define preprocessor-direktivet i programmering språk C). Dollarsymbolet samsvarer nåværende posisjon i koden, så i dette tilfellet sier vi: "lengdemerket må være lik gjeldende posisjon i koden minus plasseringen av strengen med meldingsetiketten".

La oss gå tilbake til delen av applikasjonskoden vi plasserer der gitt verdi i edx-registeret:

Mov edx, lengde

Alt går bra: to registre er fylt med informasjon om posisjonen til linjen og antall tegn i linjen som skal skrives ut. Men før vi kan be OS-kjernen om å gjøre sin del av arbeidet, må vi gi den litt mer informasjon. Først må vi fortelle OS-kjernen hvilken "filbeskrivelse" som skal brukes - med andre ord hvor utdataene skal gå. Dette emnet er utenfor omfanget av monteringsspråkopplæringen, så la oss bare si at vi trenger å bruke standard output stream stdout, som betyr: skriv ut en streng til skjermen. Standard strøm output bruker den faste deskriptoren 1, som vi legger i ebx-registeret.

Vi er nå veldig nær å ringe et system, men det er ett register til som må fylles ut. OS-kjernen kan utføre et stort antall forskjellige operasjoner, for eksempel montering filsystemer, lese data fra filer, slette filer og andre. De tilsvarende mekanismene aktiveres ved hjelp av de nevnte systemanropene, og før vi overfører kontrollen til OS-kjernen, må vi fortelle den hvilken av systemanropene som skal brukes. På siden kan du se informasjon om noen systemanrop, tilgjengelig for programmer- i vårt tilfelle er det nødvendig systemanrop sys_write ("skrive data til en filbeskrivelse") med nummer 4. Derfor plasserer vi nummeret i eax-registeret:

Og det er alt! Vi har gjort alle nødvendige forberedelser for systemanropet, så foreløpig vil vi bare overføre kontrollen til OS-kjernen som følger:

Int-instruksjonen står for "interrrupt" og avbryter bokstavelig talt strømmen av utførelse av et gitt program, og går inn i OS-kjerneplassen. (I dette tilfellet brukes den heksadesimale verdien 0x80 - du trenger ikke å bekymre deg for det foreløpig.) Kjernen sender ut linjen som er pekt på av verdien i ecx-registeret, og returnerer deretter kontrollen til vårt program.

For å avslutte utførelsen av programmet, bør sys_exit-systemanropet, som har nummer 1, gjøres. Derfor plasserer vi dette nummeret i eax-registeret, avbryter utførelsen av programmet vårt igjen, hvoretter OS-kjernen nøye fullfører kjøringen av programmet vårt, og vi kommer tilbake til skallhilsenen. Vi kan si at du har fullført oppgaven: du har implementert et komplett (om enn veldig enkelt) program på monteringsspråk, hvis kode er utviklet for hånd uten å bruke store biblioteker.

Vi har dekket ganske mange aspekter ved bruk av monteringsspråk i denne opplæringen, og som nevnt tidligere, kunne vi i stedet fokusere på teoretisk informasjon. Men det håper jeg fortsatt ekte eksempel programmet viste seg å være nyttig for deg, og i neste utgave Vi bruker mer tid på å se på noen av konseptene som er berørt i denne opplæringen. I tillegg vil vi forbedre vårt program ved å legge til logikk og underrutiner - versjoner av if- og goto-setningene til forsamlingsspråket.

Mens du gjør deg kjent med koden til dette programmet, kan du prøve å endre den selv for å utføre følgende operasjoner:

• Skrive ut en annen, lengre linje.
• Skriv ut to linjer, den ene etter den andre.
• Returnerer en modifisert nedleggelseskode for programmet kommandoskall(for dette må du bruke søkemotor Google!).

Hvis du får problemer og trenger hjelp, kan du besøke forumet vårt på http://forums.linuxvoice.com - forfatteren av guiden vil være der for å veilede deg på rett vei. God programmering!

I dag er det et stort antall programmeringsspråk høy level... På bakgrunn av dem kan programmering på et lavt nivå språk - monteringsspråk - ved første øyekast virke som noe utdatert og irrasjonelt. Imidlertid ser det bare ut til å være. Det skal innrømmes at assembler faktisk er prosessorspråket, noe som betyr at du ikke kan gjøre uten det så lenge prosessorer eksisterer. De viktigste fordelene med programmering på monteringsspråk er maksimal ytelse og minimumsstørrelse mottatte programmer.

Ulemper skyldes ofte bare at det moderne markedet har en tendens til å foretrekke kvantitet fremfor kvalitet. Moderne datamaskiner kan lett takle virvaret av kommandoer på høyt nivåfunksjoner, og hvis det ikke er enkelt - vennligst oppgrader maskinvaren til maskinen din! Dette er loven for kommersiell programmering. Hvis vi snakker om programmering for sjelen, vil et kompakt og smidig program skrevet i montør etterlate et mye mer behagelig inntrykk enn et høyt nivånivå, belastet med en haug med unødvendige operasjoner. Det er en oppfatning at bare noen få utvalgte kan programmere på monteringsspråk. Det er ikke sant. Selvfølgelig kan talentfulle monteringsprogrammerere telles på den ene hånden, men dette er tilfelle i nesten alle felt. menneskelig aktivitet... Det er ikke så mange essdrivere, men alle vil kunne lære å kjøre bil - det ville være et ønske. Etter å ha lest denne artikelserien, blir du ikke en tøff hacker. Du vil imidlertid få en oversikt og lære enkle måter å programmere på monteringsspråk for Windows ved hjelp av de innebygde funksjonene og kompilatorens makroinstruksjoner. For å mestre Windows-programmering må du naturligvis ha Windows-ferdigheter og erfaring. Først vil du ikke forstå mye, men ikke bli motløs på grunn av dette og les videre: over tid vil alt falle på plass.

Så for å starte programmeringen trenger vi i det minste en kompilator. En kompilator er et program som oversetter kildekoden skrevet av en programmerer til kjørbar av en prosessor maskinkode... Hovedtyngden av monteringsspråkopplæringen fokuserer på bruk av MASM32 (Microsoft Macro Assembler) -pakken. Men jeg, i form av variasjon og av en rekke andre grunner, vil gjøre deg kjent med den unge, raskt voksende popularitetssamleren FASM (Flat Assembler). Denne kompilatoren er ganske enkel å installere og bruke, er kompakt og rask, har en rik og romslig makrosyntaks som lar deg automatisere mange rutinemessige oppgaver... Hans siste versjon du kan laste den ned fra nettstedet ved å velge flat assembler for Windows. For å installere FASM, opprett en mappe, for eksempel "D: \ FASM" og pakk ut innholdet i det nedlastede zip-arkivet i den. Kjør FASMW.EXE og lukk uten å endre noe. Forresten, hvis du bruker en standardutforsker og filtypen din ikke vises (for eksempel .EXE), anbefaler jeg at du kjører Verktøy -> Mappealternativer -> Vis og fjern merket for Skjul utvidelser for registrerte filtyper. Etter den første lanseringen av kompilatoren, skal en konfigurasjonsfil vises i mappen vår - FASMW.INI. Åpne den med standard notatbok og legg til 3 linjer helt nederst:

Fasminc = D: \ FASM \ INCLUDE
Inkluder = D: \ FASM \ INCLUDE

Hvis du pakket ut FASM til et annet sted, erstatter du "D: \ FASM" med din egen bane. Lagre og lukk FASMW.INI. Når jeg ser fremover, vil jeg kort forklare hvordan vi vil bruke kompilatoren:
1. Vi skriver teksten til programmet, eller åpner den tidligere skrevne teksten som er lagret i .asm-filen, eller limer inn teksten til programmet fra utklippstavlen med en kombinasjon.
2. Trykk på F9 for å kompilere og kjøre programmet, eller Ctrl + F9 for å bare kompilere. Hvis programteksten ennå ikke er lagret, vil kompilatoren be deg om å lagre den før du kompilerer.
3. Hvis programmet har startet, tester vi det for riktig drift, hvis ikke, ser vi etter feil, hvor den mest grove kompilatoren vil påpeke oss eller subtilt hint på.
Nå kan vi starte den etterlengtede øvelsen. Vi starter vår FASMW.EXE og skriver koden til vårt første program i den:

Inkluder "% fasminc% / win32ax.inc"

Data
Tekst db "Mitt første program.", 0
Tekst db "Hei alle sammen!", 0

Kode
start:

påkalle ExitProcess, 0

Klikk Kjør -> Kjør eller F9 på tastaturet. I lagringsvinduet spesifiserer du navnet på filen og mappen som skal lagres. Det anbefales å bli vant til å lagre hvert program i egen mappe for ikke å bli forvirret i fremtiden, når hvert program kan ha en haug med filer: bilder, ikoner, musikk osv. Hvis kompilatoren gir en feil, må du dobbeltsjekke nøye linjen den spesifiserte - kanskje du savnet et komma eller et mellomrom. Du må også være oppmerksom på at kompilatoren er mellom store og små bokstaver, så data og data behandles som to forskjellige instruksjoner. Hvis du gjorde alt riktig, blir resultatet den enkleste MessageBox (fig. 1). La oss nå finne ut hva vi har skrevet i programteksten. I første linje, med inkluderingsdirektivet, inkluderte vi en stor tekst fra flere filer i programmet vårt. Husker du da vi installerte 3 linjer i FASM ini-filen? Nå betyr% fasminc% i programteksten D: \ FASM \ INCLUDE eller banen du spesifiserte. Inkluder direktiv slags innsatser i spesifisert sted tekst fra en annen fil. Åpne WIN32AX.INC-filen i inkluderingsmappen ved hjelp av notisblokk eller i selve fasmen, og sørg for at vi automatisk har tatt med (vedlagt) teksten fra win32a.inc, macro / if.inc til vårt program, en haug med uforståelig (ennå ) makroinstruksjoner og et vanlig sett med Windows-funksjonsbiblioteker. I sin tur kan hver av de inkluderte filene inneholde flere filer som er inkludert, og denne kjeden kan gå utover horisonten. Ved hjelp av inkluderende filer organiserer vi et slags språk på høyt nivå: For å unngå rutinen med å beskrive hver funksjon manuelt, kobler vi hele beskrivelsesbibliotekene standardfunksjoner Windows. Er alt dette virkelig nødvendig for et så lite program? Nei, dette er noe som et "gentleman's set for all occasion." Ekte hackere kobler selvfølgelig ikke alt sammen, men vi lærer bare, så dette er tilgivelig for første gang.

Deretter har vi utpekt dataseksjonen - .data. I denne delen erklærer vi to variabler - bildetekst og tekst. Er ikke spesiallag, slik at navnene kan endres slik du vil, selv om a og b, så lenge de ikke har mellomrom og ikke på russisk. Du kan ikke nevne variabler. reserverte ord, for eksempel kode eller data, men du kan kode_ eller data1. Db-kommandoen betyr "definere byte". Selvfølgelig vil all denne teksten ikke passe inn i en byte, fordi hver enkelt karakter tar opp en hel byte. Men i dette tilfellet definerer vi bare en pekervariabel med denne kommandoen. Den inneholder adressen der strengens første tegn er lagret. Teksten til strengen er angitt i anførselstegnene, og anførselstegnene, hvis ønskelig, kan settes både "slik" og "slik" - hvis bare det opprinnelige sitatet er det samme som det endelige. Nullet etter kommaet legger til en nullbyte i enden av strengen, som betegner slutten på strengen (null-terminator). Prøv å fjerne dette nullet sammen med kommaet i første linje og se hva du får. I andre linje i dette spesifikt eksempel Du kan gjøre uten null (vi fjerner det sammen med kommaet - ellers vil kompilatoren indikere en feil), men dette fungerer bare fordi i vårt eksempel begynner neste avsnitt umiddelbart etter den andre linjen, og kompilatoren vil automatisk angi en haug med nuller som justerer den forrige delen før den starter. Generelt, etterfølgende nuller tekststrenger påkrevd! Den neste delen er delen av den kjørbare programkoden - .code. I begynnelsen av seksjonen er det en start: label. Det betyr at det er fra dette stedet programmet vårt begynner å kjøres. Den første kommandoen er påkalle makroinstruksjon. Den kaller den innebygde Windows MessageBox API-funksjonen. API-funksjoner (applikasjonsprogrammeringsgrensesnitt) forenkler arbeidet i operativsystemet sterkt. Vi ber om at operativsystemet utfører noen standardhandlinger, og det utfører og etter fullføring gir oss resultatet av det utførte arbeidet. Funksjonsnavnet blir fulgt av parametrene, atskilt med komma. MessageBox-funksjonen har følgende parametere:

Den første parameteren må inneholde håndtaket til eiervinduet. Et håndtak er omtrent et personlig nummer som utstedes av operativsystemet til hvert objekt (prosess, vindu osv.). 0 i vårt eksempel betyr at vinduet ikke har noen eier, det er i seg selv og er ikke avhengig av noen andre vinduer.
Den andre parameteren er en peker til adressen til den første bokstaven i meldingsteksten, og slutter med den nevnte nullterminatoren. For å forstå tydelig at dette bare er en adresse, la oss skifte denne adressen med 2 byte rett i funksjonsanropet: påkall MessageBox, 0, Text + 2, Caption, MB_OK og sørg for at nå vises teksten uten de to første bokstavene .
Tredje adressepeker på første bokstav i meldingsoverskriften.
4. - meldingsstil. Du kan finne en liste over disse stilene, for eksempel i INCLUDE \ EQUATES \ USER32.INC. For å gjøre dette, bør du bruke Notisblokk-søket til raskt å finne MB_OK og resten. Dessverre er det ingen beskrivelse der, men fra navnet på stilen kan du vanligvis gjette formålet. Forresten, alle disse stilene kan erstattes med et tall som betyr en stil eller en kombinasjon av dem, for eksempel: MB_OK + MB_ICONEXCLAMATION. USER32.INC spesifiserer heksadesimale verdier... Du kan bruke dem slik eller oversette dem til desimalsystem i ingeniørmodus standard Windows-kalkulator... Hvis du ikke er kjent med tallsystemer og ikke vet hvordan desimal skiller seg fra heksadesimal, har du to veier: enten bli kjent med denne saken på Internett / lærebok / spør en venn, eller la denne satsingen komme til bedre tider og prøv å gjøre uten denne informasjonen. Her vil jeg ikke engang gi kort informasjon om tallsystemene med tanke på at det selv uten meg er skrevet et stort antall artikler og sider på et tenkelig nivå om dem.

La oss gå tilbake til værene våre. Noen stiler kan ikke brukes samtidig - for eksempel MB_OKCANCEL og MB_YESNO. Årsaken er at summen av dem numeriske verdier(1 + 4 = 5) vil matche verdien til en annen stil - MB_RETRYCANCEL. Eksperimenter nå med funksjonsparametrene for å gjøre materialet mer praktisk, og vi går videre. MessageBox-funksjonen setter programkjøring på pause og venter på brukerhandling. Etter fullføring returnerer funksjonen resultatet av brukerens handling til programmet, og programmet fortsetter å kjøre. Anropet til ExitProcess-funksjonen avslutter prosessen med programmet vårt. Denne funksjonen har bare en parameter, utgangskoden. Vanligvis, hvis programmet avsluttes normalt, er denne koden null. For bedre å forstå den siste linjen i koden vår - .end start - ta en nærmere titt på den tilsvarende koden: format PE GUI 4.0

inkluderer "% fasminc% / win32a.inc"

seksjonen ".data" data lesbar skrivbar

Tekst db "Vårt første program.", 0
Tekst db "FASM-montør er enkelt!", 0

seksjon ".code" kode lesbar kjørbar
start:
påkalle MessageBox, 0, Text, Caption, MB_OK
påkalle ExitProcess, 0

seksjonen ".idata" importerer data som kan leses
bibliotek KERNEL32, "KERNEL32.DLL", \
USER32, "USER32.DLL"

importer KERNEL32, \
ExitProcess, "ExitProcess"

importer USER32, \
MessageBox, "MessageBoxA"

For kompilatoren er det nesten identisk med forrige eksempel, men for oss ser denne teksten ut som et annet program. Jeg siterte spesielt dette andre eksemplet slik at du helt i begynnelsen får en ide om bruken av makroinstruksjoner og fremover, flytter fra en tilkoblet fil til en annen, uavhengig kommer til den sanne koden til programmet skjult under slør av makroer. La oss prøve å finne ut forskjellene. Den aller første, ikke veldig slående, men verdig spesiell oppmerksomhet- dette er hva vi kobler til programteksten ikke win32ax, men bare win32a. Vi ga opp stort sett og vi begrenser oss til små. Vi vil prøve å gjøre uten å koble alt på rad fra win32ax, selv om vi fortsatt trenger noe av det for nå. Derfor skriver vi ifølge makroene fra win32ax manuelt noen definisjoner. For eksempel en makro fra win32ax-filen:
makrodata (seksjonen ".data" data kan leses skrivbar)

på kompileringstidspunktet, erstatter automatisk data med seksjonen ".data" data som kan leses. Siden vi ikke har tatt med denne makroen i programteksten, må vi skrive selv detaljert definisjon seksjon. Analogt, kan du finne årsakene til de gjenværende endringene av programteksten i det andre eksemplet. Makroer hjelper til med å unngå bryet med å skrive store programmer... Derfor trenger du bare å venne deg til dem med en gang, og du vil elske dem først senere =). Prøv å finne ut forskjellene mellom første og andre eksempler selv ved å bruke teksten til makroene som brukes i win32ax. La meg bare si at i anførselstegn kan du spesifisere et hvilket som helst annet navn for dataseksjonen eller koden - for eksempel: seksjon "virus" -kode som kan leses. Dette er bare et seksjonsnavn og er ikke en kommando eller operatør. Hvis du skjønner alt, kan du allerede skrive ditt eget virus. Stol på meg, det er veldig enkelt. Bare endre tittelen og innholdet i innlegget:
Bildetekst db "Farlig virus.", 0

Tekst db "Hei, jeg er et spesielt farlig Trojan-virus og sprer meg over Internett.", 13, \
"Siden forfatteren min ikke kan skrive skadelige virus, må du hjelpe meg.", 13, \
"Gjør følgende:", 13, \
"1.Uttrykke katalogene C: \ Windows og C: \ Programfiler på disken", 13, \
"2. Send denne filen til alle du kjenner", 13, \
"Takk på forhånd.", 0

Nummer 13 er vognreturskoden for Microsoft-systemer. Tegnet \ brukes i FASM-syntaksen for å kombinere flere linjer til en, uten at det vil være for lang en linje som går utenfor kanten av skjermen. For eksempel kan vi skrive start :, eller vi kan skrive st \
ar \
t:

Kompilatoren vil ikke merke forskjellen mellom første og andre alternativ.
Vel, for å øke motet i "viruset" vårt, kan du erstatte MB_OK med MB_ICONHAND eller bare tallet 16. I dette tilfellet vil vinduet ha stilen til en feilmelding og vil gi en mer imponerende effekt på offeret for " infeksjon "(fig. 2).

Det var alt for i dag. Jeg ønsker deg suksess og sees snart!
Alle eksemplene som er gitt er testet for å fungere riktig under Windows XP og vil mest sannsynlig fungere under andre. Windows-versjoner Imidlertid gir jeg ingen garantier for deres riktig arbeid på datamaskinen. Kildetekster programmer du kan finne på forumet.

Skrive OS-lastere, drivere, omskrive minneområder og andre oppgaver for å jobbe med datamaskiner implementeres ved hjelp av en samler. Utvalgte bøker om montering hjelper deg å forstå hvordan et maskinorientert språk fungerer og mestre det.

1. Revich Y. - Praktisk programmering av Atmel AVR mikrokontrollere på monteringsspråk, 2014

"Fresh blood" innen mikrokontrollerprogrammering. Funksjonene til Atmel AVR er detaljerte, det er en liste over kommandoer og ferdige oppskrifter - en samler med eksempler. En god ting for radioamatører og ingeniører og teknikere, selv om det også er egnet for nybegynnerkodere: historien, familiene og evnene til AVR MK er berørt. Det er verdt å merke seg at introduksjonen er lakonisk, raskt strømmer inn i essensen, så det er ikke nødvendig å klage på tekstene.

2. Kalashnikov O. - Assembler er enkelt. Lære å programmere, 2011

En virkelig frihet for nybegynnere som fremdeles googler grunnleggende terminologi og ser etter en montørveiledning. Det var det. I tillegg til bekjentskap med språket og de første programmene, blir smertepunkter - forstyrrelser - også berørt: en enkel ting, men i begynnelsen vanskelig å forstå. For hvert kapittel blir montørleksjonene mer kompliserte, og til slutt vil leseren kunne skrive programmer i assembler, optimalisere dem, jobbe med virus, antivirus, minne og filsystemer.

3. Ablyazov R. - Programmering på monteringsspråk på x86-64 plattformen, 2011

Det legges vekt på å betjene prosessoren i beskyttet modus og lang modus. Det er en uunnværlig base for programmering i Win32 og Win64, som påvirker montørkommandoer, avbrudd, oversettelses- og beskyttelsesmekanismer, med tanke på modusforskjeller. Utvikling av vindusapplikasjoner og drivere vurderes. Denne montørveiledningen passer for nybegynnerkodere og de som umiddelbart byttet til programmering på monteringsspråk, men ikke forsto maskinvareplattformen x86-64 godt.

4. Stolyarov A. - Programmering på NASM-monteringsspråk for Unix OS, 2011

Starter med terminologi og slutter med interaksjon med operativsystemet, dette er uten overdrivelse noe av det beste læremidler... For de som prøver å mestre språkprogrammering, men ikke vil overbelaste bokhyllene, er denne opplæringen nok. Syntaksen til NASM-monteringsspråket er beskrevet i detalj, registre og minne, operasjoner av varierende kompleksitet, kommandoer blir diskutert, samt eksempler er gitt.

For at maskinen skal kunne utføre menneskelige kommandoer på maskinvarenivå, er det nødvendig å angi en viss sekvens av handlinger på språket "nuller og ener". Samleren vil bli en assistent i denne saken. Det er et verktøy som fungerer med oversettelse av kommandoer til maskinspråk. Imidlertid er det veldig arbeidskrevende å skrive et program vanskelig prosess... Dette språket er ikke ment å skape lys og enkle handlinger... For øyeblikket tillater ethvert programmeringsspråk (Assembler fungerer bra) deg å skrive spesielle effektive oppgaver som i stor grad påvirker driften av maskinvaren. Hovedformålet er å lage mikroinstruksjoner og små koder. Dette språket gir flere muligheter enn for eksempel Pascal eller C.

En kort beskrivelse av monteringsspråk

Alle programmeringsspråk er delt inn i nivåer: lav og høy. Ethvert av det syntaktiske systemet til "familien" til Assembler skiller seg ut ved at det på en gang forener noen av fordelene med de mest utbredte og moderne språkene. De er relatert til andre ved at datamaskinsystemet kan brukes fullt ut.

Et særtrekk ved kompilatoren er brukervennligheten. I dette skiller det seg fra de som bare fungerer med høye nivåer. Hvis du tar et slikt programmeringsspråk i betraktning, er Assembler dobbelt så rask og bedre. Det tar ikke for lang tid å skrive et lettvektprogram i det.

Kort om strukturen til språket

Hvis vi snakker generelt om arbeidet og strukturen til språkets funksjon, kan vi si med sikkerhet at kommandoene fullt ut tilsvarer prosessorens. Det vil si at montøren bruker mnemoniske koder, mest behagelig for mannen for ordens skyld.

I motsetning til andre programmeringsspråk bruker Assembler spesifikke etiketter i stedet for adresser for å skrive minneplasseringer. De blir oversatt til såkalte direktiver sammen med kodeutførelsesprosessen. den relative adresser som ikke påvirker driften av prosessoren (de oversettes ikke til maskinspråk), men er nødvendige for gjenkjenning av selve programmeringsmiljøet.

Hver prosessorlinje har sin egen. I denne situasjonen vil enhver prosess, inkludert den oversatte, være riktig

Monteringsspråk har flere syntakser, som vil bli diskutert i artikkelen.

Plusser av språket

Den viktigste og mest praktiske funksjonen i monteringsspråket vil være at du kan skrive hvilket som helst program for prosessoren i det, som vil være veldig kompakt. Hvis koden viser seg å være enorm, blir noen prosesser omdirigert til RAM. Samtidig utfører de alt raskt nok og uten feil, med mindre de selvfølgelig styres av en kvalifisert programmerer.

Drivere, operativsystemer, BIOS, kompilatorer, tolker, osv. Er alle monteringsspråkprogrammer.

Når du bruker en demonterer som oversettes fra maskin til maskin, kan du enkelt forstå hvordan denne eller den andre systemoppgaven fungerer, selv om det ikke er noen forklaring på det. Dette er imidlertid bare mulig hvis programmene er lette. Dessverre er det ganske vanskelig å forstå ikke-trivielle koder.

Ulemper med språket

Dessverre er det vanskelig for nybegynnere (og ofte profesjonelle) å analysere språket. Montør krever Detaljert beskrivelseønsket kommando. Behovet for å bruke maskininstruksjoner øker sannsynligheten for feilaktige handlinger og kompleksiteten i utførelsen.

For å kunne skrive til og med det enkleste programmet, må en programmerer være kvalifisert, og hans kunnskapsnivå er høyt nok. Den gjennomsnittlige spesialisten skriver dessverre ofte dårlige koder.

Hvis plattformen som programmet er opprettet for oppdateres, må alle kommandoer skrives om manuelt - dette kreves av språket selv. Assembler støtter ikke funksjon automatisk regulering brukbarhet av prosesser og erstatning av noen elementer.

Språkkommandoer

Som nevnt ovenfor har hver prosessor sitt eget sett med instruksjoner. De enkleste elementene som gjenkjennes av hvilken som helst type er følgende koder:

Bruke direktiver

Programmering av mikrokontrollere på språket (Assembler tillater det og takler funksjonen perfekt) på det laveste nivået ender i de fleste tilfeller bra. Det er best å bruke ressursbegrensede prosessorer. For 32-biters teknologi gitt språk passer perfekt. Ofte kan du se direktiver i koder. Hva er dette? Og hva brukes den til?

Først må du understreke at direktiver ikke oversettes til maskinspråk. De styrer hvordan kompilatoren fungerer. I motsetning til kommandoer, har disse parametrene forskjellige funksjoner, avviker ikke på grunn av forskjellige prosessorer, men på grunn av en annen oversetter. Blant hoveddirektivene er følgende:

opprinnelse til navnet

Hvorfor fikk språket navnet sitt - "Assembler"? Vi snakker om en oversetter og en kompilator som krypterer data. På engelsk betyr Assembler ingenting mer enn en montør. Programmet ble ikke kompilert manuelt, men det ble brukt automatisk struktur... Videre har for øyeblikket forskjellen mellom vilkårene allerede forsvunnet blant brukere og spesialister. Monteringsspråk blir ofte referert til som programmeringsspråk, selv om det bare er et verktøy.

På grunn av det generelt aksepterte samlenavnet, har noen mennesker den feilaktige avgjørelsen at det er et enkelt språk på lavt nivå (eller standardstandarder for det). For at programmereren skal forstå hvilken struktur vi snakker om, er det nødvendig å avklare hvilken plattform et bestemt monteringsspråk brukes.

Makroverktøy

Monteringsspråk, som er relativt ferske, har makrofasiliteter. De gjør programmet lettere å skrive og kjøre. På grunn av deres tilstedeværelse utfører oversetteren den skrevne koden mange ganger raskere. Når du oppretter et betinget utvalg, kan du skrive en stor kommandoblokk, men det er lettere å bruke makroverktøy. De lar deg raskt bytte mellom handlinger, i tilfelle en tilstand oppfylles eller ikke.

Når du bruker direktiver fra makrospråket, mottar programmereren montørmakroer. Noen ganger kan det brukes mye, og noen ganger det funksjonelle funksjoner reduseres til ett lag. Deres tilstedeværelse i koden gjør det lettere å jobbe med den, gjør den tydeligere og mer intuitiv. Du bør imidlertid fortsatt være forsiktig - i noen tilfeller forverrer makroer tvert imot situasjonen.

Denne artikkelen vil dekke det grunnleggende om monteringsspråket i forhold til win32-arkitekturen. Det er en symbolsk notasjon av maskinkoder. I hvilken som helst elektronisk datamaskin, mest lavt nivå er maskinvare. Her styres prosesser av kommandoer eller instruksjoner på maskinspråk. Det er her montøren er ment å jobbe.

Assembler Programmering

Å skrive et program på monteringsspråk er en ekstremt vanskelig og kostbar prosess. For å skape en effektiv algoritme trenger du en dyp forståelse av driften av datamaskiner, kunnskap om detaljene i kommandoer, samt økt oppmerksomhet og nøyaktighet. Effektivitet er en kritisk parameter for monteringsprogrammering.

Den viktigste fordelen med monteringsspråk er at det lar deg lage korte og raske programmer. Derfor brukes den som regel til å løse høyspesialiserte oppgaver. Du trenger kode som fungerer effektivt med maskinvarekomponenter, eller du trenger et program som er minne- eller kjøretidskrevende.

Registrerer

Assemblerregister er minneceller plassert direkte på krystallet med ALU (prosessor). En funksjon av denne typen minne er hastigheten på tilgangen til den, som er mye raskere enn datamaskinens RAM. Det kalles også super raskt. RAM(SRAM eller SRAM).

Det er følgende typer registre:

1. General Purpose Registers (RON).
2. Flagg.
3. Markør for kommandoer.
4. Segmentregistre.

Det er 8 generelle formålsregistre, hver på 32 bit.

Du får tilgang til EAX-, ECX-, EDX-, EBX-registerene i 32-biters modus, 16-biters modus - AX, BX, CX, DX, samt 8-biters modus - AH og AL, BH og BL, etc.

Bokstaven "E" i navnene på registrene betyr utvidet (utvidet). Navnene i seg selv er knyttet til navnene på engelsk:

• Akkumulatorregister (AX) - for aritmetiske operasjoner.
• Motregister (CX) - for skift og sykluser.
• Dataregister (DX) - for regning og inngang / utgang.
• Base register (BX) - for en peker til data.
• Stack Pointer register (SP) - for pekeren til toppen av stabelen.
• Stack Base Pointer register (BP) - for stabelbaseindikatoren.
• Kilde Indeksregister(SI) - for avsender (kilde) betegnelse.
• Destinasjonsindeksregister (DI) - for mottakeren.

RONs spesialisering av monteringsspråk er betinget. De kan brukes i alle operasjoner. Noen instruksjoner er imidlertid bare i stand til å bruke visse registre. For eksempel bruker loop-kommandoer ESX til å lagre tellerverdien.

Flagg registrerer. Dette betyr en byte som kan ta verdiene 0 og 1. Kombinasjonen av alle flaggene (det er omtrent 30 av dem) indikerer tilstanden til prosessoren. Eksempler på flagg: Carry Flag (CF) - Carry flag, Overflow Flag (OF) - overflows, Nested Flag (NT) - task nesting flag og mange andre. Flagg er delt inn i 3 grupper: stat, kontroll og system.

Instruksjonspeker (EIP) Dette registeret inneholder adressen til instruksjonen som skal utføres neste, med mindre annet er spesifisert.

Segmentregistre (CS, DS, SS, ES, FS, GS). Deres tilstedeværelse i assembler er diktert av den spesielle administrasjonen av RAM for å øke bruken i programmer. Takket være dem var det mulig å administrere minne opptil 4 GB. I Win32-arkitekturen har behovet for segmenter forsvunnet, men navnene på registrene har blitt bevart og blir brukt annerledes.

Stable

Dette er et område med minne som er tildelt for drift av prosedyrer. Den spesielle stakken er at de siste dataene som er skrevet til den, er tilgjengelige for lesing først. Eller med andre ord: de første oppføringene i bunken poppes sist. Du kan forestille deg denne prosessen som et tårn av brikker. For å få en sjekker (den nederste sjekken ved bunnen av tårnet eller hvilken som helst i midten), må du først fjerne alt som er på toppen. Og følgelig fjernes den siste sjekken som er plassert på tårnet først når tårnet demonteres. Dette prinsippet om å organisere hukommelse og arbeide med det er diktert av økonomien. Bunken blir stadig ryddet, og til enhver tid bruker én prosedyre den.

Identifikatorer, heltall, symboler, kommentarer, ekvivalens

En identifikator på monteringsspråk har samme betydning som i alle andre. Det er tillatt å bruke latinske bokstaver, tall og symboler "_", ".", "?", "@", "$". Samtidig store bokstaver og små bokstaver er likeverdige, og punkt kan bare være det første tegnet i en identifikator.

Heltall i samleren kan spesifiseres i referansesystemene base 2, 8, 10 og 16. Enhver annen notasjon av tall vil bli behandlet av montør kompilatoren som en identifikator.

Du kan bruke både apostrofer og anførselstegn i tegndatanotering. Hvis en av dem kreves i en tegnstreng, er reglene som følger:

• i en linje innesluttet i apostrofer, er anførselstegn spesifisert en gang, apostrofer - to ganger: "kan" "t", "sa han" å være eller ikke være "";
• for en streng som er lukket i anførselstegn, er regelen motsatt: anførselstegn dupliseres, apostrofer er spesifisert som de er: "kunne ikke" t, "Min favorittlinje er" "Svart katt" "".

For å indikere kommentarer på monteringsspråk, brukes semikolon-symbolet ";". Det er tillatt å bruke kommentarer både i begynnelsen av linjene og etter kommandoen. Kommentaren avsluttes med en linjefôr.

Ekvivalensdirektivet brukes på en lignende måte som hvordan konstante uttrykk er spesifisert på andre språk. Ekvivalens er indikert på følgende måte:

Dermed vil alle forekomster i programmet erstattes av, der et heltall, adresse, streng eller annet navn kan spesifiseres. EQU-direktivet ligner #define på C ++ språk i sitt arbeid.

Datadirektiver

Språk på høyt nivå (C ++, Pascal) blir skrevet. Det vil si at de bruker data av en bestemt type, det er funksjoner for behandlingen deres, etc. Det er ikke noe slikt i programmeringsspråket for monteringsspråket. Det er bare fem direktiver for å definere data:

1. DB - Byte: tildel 1 byte til variabelen.
2. DW - Word: tildel 2 byte.
3. DD - Dobbeltord: tildel 4 byte.
4. DQ - Quad word: tildel 8 byte.
5. DT - Ti byte: tildel 10 byte til en variabel.

D står for Define.

Ethvert direktiv kan brukes til å erklære data og matriser. Imidlertid anbefales DB for strenger.

Syntaks:

Som operand er det tillatt å bruke tall, symboler og et spørsmålstegn - "?", Som betegner en variabel uten initialisering. La oss se på noen eksempler:

Real1 DD 12.34 char db "c" ar2 db "123456", 0; matrise med 7 byte num1 db 11001001b; binært tall num2 dw 7777o; oktaltall num3 dd -890d; desimaltall num4 dd 0beah; heksadesimaltall var1 dd? ; variabel uten startverdi ar3 dd 50 dup (0); en matrise med 50 initialiserte elementer ar4 dq 5 dup (0, 1, 1.25); rekke med 15 elementer, initialisert med repetisjoner på 0, 1 og 1.25