Man bør vel egentlig sige at assembler-koden og "binary" er på samme niveau: Det er 2 forskellige måder at repræsentere det, der foregår rent elektronisk inde i hardwaren. Og det er de 2 mest oprindelige måder at repræsentere det på. Når du instruerer en assembler-/binary kode så instruerer du direkte til hardwaren, og derefter er der ingen oversættelse efterfølgende.
Derfor giver det udmærket mening at tale om at de højere sprog "oversættes" til assembler/binary. Man skal bare være opmærksom på at assembler og binary også blot er repræsentationer af elektroniske tilstande.
assembler en en textuel representation af binary (og det program som kan konvertere fra den textuelle repraesentation til binary)
nogle compilerere genererer en assembler fil udfra high level language kildeteksten og bruger saa et assembler program til at konvertere assembler filen til binary
andre compilere genererer binary direkte
all der arbejder paa kode genererings delen af en compiler er noedt til at vide en masse om assembler/binary og den CPU arkitektur de genererer kode til
Forkert. Assembly er det en lettere form for computer instruktioner, hvilket er en form for mnemoteknik, for de binære tal. Bedre sagt, Assembly er en mnemoteknik for computer instruktioner, og computer instruktioner er en mnemoteknik for binære tal, hvilke computeren arbejder I og Med.
F.eks.
mov ebp, esp ; Hvilket er Assembly sprog
Denne funktion gemmer stack pointeren i ebp.
En mnemoteknik for dette er i computer instruktioner
8BH ECH ; Hvilket er Computeren måde at gøre det samme som før.
så at sige at Assembly er textuel representation af binary, passer ikke. Det er representation af computer instruktioner. Og computer instruktioner er en representation af binære.
Jamen hov hov du, binær form? Der er vist noget du har gået glip af. Når du skriver en source code file i assmebly, og bruger NASM til at compile den så laver NASM den om til computer instruktioner, der efter skal man compile objekt kode filen til binær. Nu har jeg skrevet assmebly i 4 år, så jeg ved hvad jeg taler om. Assembly repræsenterer IKKE binary instruktioner. Computer instruktioner er det tætteste du kommer på det. Når du har compilet dit program færdigt så er det binære tal, ellers, i assembly er det først Source Code File og så Object code File, derefter Binary file. Hvilket er en exe fil, i denne sammenhæng.
Object filen indeholder præcis den samme binary kode som executablen, bortset fra de referencer som linkeren skal resolve (og så er fil formatet anderledes, fordi meta information linker og image loader er forskelligt).
Det kan du jo sige om alle programmer du skriver min ven. Og for sidste gang, Computer instruktioner, hvilket O. filen indeholder, er IKKE præcis den binære kode. Så kunne du jo, som sagt før, sige det samme om et program i C or Perl. For det første ville den binære kode blive meget længere når den er oversat fra Computer instruktioner til binær. Og nu har jeg også talt med en der har arbejdet med det i 19 år, og han siger at du tager fejl. O. filen indeholder IKKE den præcise binære fil. Det som du siger at ( Object filen indeholder præcis den samme binary kode som executablen ). Så kan du lige så godt sige at en C#, Perl, Python, eller Soure Code file fra Assembly også gør det. FORDI de indeholder de funktioner programmet har og hvad det skal gøre. Så, Computer instruktioner er ikke den præcise binære fil. Nu tror jeg vi stopper det her, fordi når en der har arbejdet med computer i næsten 19 år og har skrevet Assembly i 7 så tror jeg nu nok han ved hvad han siger.
Sorry for de mange posts. Men jeg ved da godt at værdien er det samme, men de ser ikke ens ud. 8BH ECH er jo ikke binære tal, og det er det jeg mener med det at de ikke HELT præcist er ens.
ja men det er jeg jo enig i som jeg også siger. Men det er jo ikke præcist fordi instruktionerne er jo ikke binære. De har den samme funktion og betydning. Men er ikke binære. De betyder det samme men er vist ens for sig selv. Og det er det jeg mener når jeg siger at det ikke er binære tal men det er en anden måde at vise dem på.
Som filosof med computer som område er det en diskussion, jeg synes er spændende. Men jeg håber vi er enige om, at hvis vi siger, at "assembler en en textuel representation af binary" (som blev sagt af Arne i starten af tråden), så er det kun rigtigt for såvidt vi ikke tænker på det binære talsystem. Lige så lidt som der ingen assembler-instruksioner findes inde i computeren, så er der heller ingen tal. Der er en (temmelig stor) række tilstande af tændt/slukket (binære elektriske tilstande). Alt efter hvilke kombinationer af tændt/slukket processoren møder, så gør den nogle bestemte ting.
Så har vi mennesker brug for at kunne huske det på en lidt lettere måde. Til nogle ting er assembler mest nyttigt; til andre ting er binære tal meget nyttige. Men assembler repræsenterer ikke binære tal, eller omvendt. Begge dele peger mod noget tredje: Kombinationer af elektriske tilstande.
Undskyld hvis det er flueknepperi, men jeg tror måske at noget af diskussionen skyldes uklarhed i påstanden...
Lige til at starte med vil jeg lige sige at du ikke bare kan gå direkte fra den ene form til den anden. Ksoren, du ved godt at Source Code filen ikke er binær? Det er ASCII. Men du kan fra .O filen gå direkte til binær, fordi det er det samme bare vist som HEX.
Assembler sprogene er det nederste niveau før maskinkode (hvilket er binært, da CPU'en er opbygget af transistorer som er enten slukket = 0 eller tændt = 1). Den kode du får er en hexadecimal repræsentation(H'et betyder hexadecimal i din kode) af den binære maskinekode. Denne kode bliver så via en linker omdannet til maskinkode, hvorefter dit program kan eksekveres. Så principielt er al programmering jo en repræsentation af binær maskinkode, bare på forskellige abstraktionsniveauer. Object code er resultatet af en kompilering, som kan eksekveres og er altid binær maskinkode. I dit tilfælde får du altså først den hexadecimale værdi af maskinkoden, hvorefter du bruger en linker og så kan eksekvere programmet, da det nu er ren binær maskinkode. En compiler oversætter indholdet af source code filen til et andet sprog, hvilket typisk ville være maskinkode eller assembler(en del lettere!). Den HEX kode du få...r er jo bare intermediary code, som ikke kan eksekveres før du bruger en linker, så vil mene at det er fint nok at sige at .obj filen er binær, da det jo er slut resultatet du er interesseret i. Men dog er de stadig ikke helt ens, da det ene er HEX og andet Binær. Men som sagt, de repræsentere det samme.
Du misser pointen. Hvis vi taler ascii og jeg har tallet 65, så ved jeg det står for A. Hvis jeg har et A, så ved jeg det står for tallet 65. Det betyder det samme.
Det samme gør sig gældende med assembler. Den binære kode er et direkte billede af din kildekode. Det er også derfor, at du får kildekoden tilbage (sådan da), hvis du indlæser den binære fil i en disassembler.
kosren, som jeg nu har sagt for 1000 gange så er jeg enig. Men computer instruktionerne er stadig med HEX og det kan du lige som ikke lige lave om på vel? Derfor er det ikke HELT og ALDELES ens, men som jeg nu også har sagt 1000 gange beskriver/repræsentere det samme. Hvis de var helt og aldeles ens så ville der i .O filen ikke stå 8BH ECH, men 10001011 11101100, forstår du hvad det er jeg prøver at sige her? og jo, Assembler sprogene er det nederste niveau før maskinkode, og hvis du ikke er enig i det så beskriv hvordan det som du nu siger er nederst, fungere? Indirekte har du lige sagt at binary ikke er det nederste, når vi nu taler om computer.
Jo, nu vil jeg så gerne have at du forklare mig hvordan de binære tal fungere? Og nu kan jeg se at vi skal til at tale om ingeniør parten af computeren. Det er jo netop strømmen der er med til at udgøre de binære tal???
For mig ser det ud som om du ikke helt kan svare, men lad mig.
Lad os som sagt antage at du skal skriv et a i word, og du trykker på a på dit tastatur.
Lad os kigge på hvad der sker i dine RAM. Når du trykker på a giver du en impuls til din pc, hvor efter den så ved hvilke transistorer der skal gives strøm til. Det var den meget korte version af hvad der sker i dine ram.
Hvis man skulle forklare det til en nybegynder ville det være bedst sådan. o'erne er transistorer, de streger over dem er impuls pinde, den lange pin der går igennem dem er adresse pinden, de pinde der er under dem er data-pinde. Der er selvfølgelig meget mere i det end som så!
Du er slet ikke med på hvad jeg mener. En ramkreds består ikke af nuller og ettaller. Den består af en masse transistorer, som hver især kan holde en spænding. Spændingsniveauet på den enkelte transistor angiver om det er et 0 eller 1.
Det var det, der var min pointe med analogteknik som værende det nederste niveau.
Hvis du nu gas læse lidt, så kunne du forstå hvad jeg taler om. Og det du siger lige der er det jeg har sagt. 8 transistorer er 8 bits = 1 byte, der med når strømmen går igennem sådan her 01000001 er det et a. Så svært er det ikke at forstå, når jeg lige har forklaret dig det.
Igen sorry for de mange posts. Når jeg siger at strømmen går igennem sådan her 01000001 så betyder det at der hvor der er et 1 tal er transistoren lukket hvilket betyder at der er en gennemgang af strøm. 0 tallene betyder slf at transistorene er åbne og der ikke er en gennemgang af strøm.
Jeg tror egentlig heller ikke I er så uenige. Men Kenneth199 det er altså forkert at sige, at "Men computer instruktionerne er stadig med HEX og det kan du lige som ikke lige lave om på vel" (#30). Det er rigtig at de normalt gengives i Hex, men det er jo bare fordi det er mest pædagogisk.
På samme måde "står" der heller ikke noget i .o-filen. Men når vi har brug for at undersøge den, så er det nemmest at starte med et HEX-dump -- for det kan man forholdsvis nemt afkode, hvis man forstår sig på den slags.
Jeg tænker på, om den fortsatte diskussion skyldes at vi taler om noget forskelligt, når vi taler om assembler. Det er mange år siden, at jeg selv programmerede i assembler, men den gang skelnede man mellem alm. assembler og macro-assembler (hedder nok noget andet i fagsproget i dag). For macro-assembler programmering giver det mening at sige at den er "over" maskinssproget, da den først skulle oversættes, inden den kunne køres. Men for almindelig assembler var der ingen oversættelse nødvendigt. Det var ren maskinkode.
Ejvindh nu sidder jeg og kigger i det 3 bøger jeg har på engelsk om Assembly, og jeg skriver:" The Assembler reads the line from the source code file, and writes the equivalent machine instruction in HEX to an object code file." Det skal så siges at der i alle 3 bøger også står at .O filen inde holder machine instructions i HEX, og med hjælp fra linkeren bliver de omdannet til binære. Det har ikke noget med at det er mest pædagogisk, fordi .O filen er machine instructions skrevet i HEX, grunden til det er at binære, ja som sagt, ville være sværer at læse, men det er HEX den inde holder. Den HEX kode machine instructions er, er jo bare intermediary code, som ikke kan eksekveres før du bruger en linker. Jeg ved ikke om i forstår mig. Du kan, og nu siger jeg det igen, ikke lave om på at når du har brugt NASM til at compile din source code file, og får .O filen, så består den af HEX. Ret mig hvis det jeg skriver fra bøgerne ikke er sandt.
Nu kender jeg ikke NASM personligt, men en søgning på nettet tyder på, at det her drejer sig om det, jeg ovenfor kalder en macro-assembler. Så derfor er det rigtigt at DEN slags assembler kode naturligvis først skal oversættes til maskinkode. Men det er ikke det jeg taler om (og jeg tror heller ikke ksoren).
Angående det med Hex, så må jeg sige, at "det du skriver fra bøgerne" ikke er sandt. Hex er jo et talsystem, og eftersom der ingen tal befinder sig i filerne, så...
Hvis jeg skal se en detaljeret udskrift af en binær fil, vil jeg ofte bede om et hex-dump. Men jeg kunne ligeså godt programmere et fil-dump program, der viste mig indholdet i decimal-tal, binære tal, oktale tal. Når man maskinkoder er Hex bare nemmere at arbejde med, fordi den binære struktur er forholdsvis synlig i de hexadecimale tal (på en overskuelig måde). Og derfor er det nemmere at forstå de binære operationer. Og fordi det er mere indlysende hvorfor bytes-ene går i nul ved 256.
Jeg ved godt at .O filen og den eksekver fil indeholder det samme. Bedre sagt de repræsentere det samme. Men hvis du kigger i en .O fil uden at om-code det, så er det HEX, hvor efter at linkeren skriver det til binary, og lægger programmet de steder det skal.
Når du siger "hvis du kigger i en .O fil uden at om-code det", så vil jeg gerne have, at du spørger dig selv: Hvad er det jeg kigger med?
Mit gæt vil være, at du svarer noget i stil med "jeg kigger med et program". Dette program har du brug for til at omsætte nogle fysiske tilstande på din disk, til noget du som bruger kan forstå. Et program omkoder. Hvis filen havde bestået af Hex-tal, så havde du ikke haft brug for et program, for at se, hvad der er i det.
"Nu tror jeg vi stopper det her, fordi når en der har arbejdet med computer i næsten 19 år og har skrevet Assembly i 7 så tror jeg nu nok han ved hvad han siger."
Antal år man har arbejdet med programmering har aldrig været et kvalitets stempel for god du er, eller hvor godt du har forstået det. Just saying..
Nej, men så må du gerne svare mig. I den ene bog jeg har om Assembly står der f.eks. dette (mov ebp, esp) der står direkte oversat til dansk at assembleren læser linien og skriver den samme kode i computer instruktioner sådan her ( 8BH ECH ). Nu vil jeg så godt vide hvorfor de valgte at vise det i hex og ikke med binære tal når det som du siger er at .O filen er binær. Jeg synes bare det er sjov at der står det, og ikke det som du siger.
madand hvem har skrevet Assembly i 7 år*? ejvindh har nævnt at det er lang tid siden han skrev i det?
Det der irritere mig er så at bogen ikke præcis besriver hvad der sker, altså at den ikke bare siger at NASM assembleren skriver linien om til ( 8BH ECH ) i .O filen, i stedet for at forklare hvad der enlig sker, og hvad .O filen egentlig indeholder.
Nasm skriver source code filen om til object filen, hvilket indeholder maskin koden i binære tal, og så bruger man linkeren til at gøre den eksekver bar.
Men hvis det er rigtigt, så vil jeg da bare sige mange tak for denne diskussion, den har været lære-rig. Lidt skuffende at man ikke helt kan stole på den bog man nu engang har, og har brugt den i et par år....
nåå Casper ja, det havde jeg glemt jeg havde nævnt. Men jeg forstår godt hvad Arne prøvede at fortælle mig. Det som jeg forstod ved min bog var at .O filen kun var i HEX. Men som de andre også siger så er det mere læseligt i HEX end i binær. Så jeg har gået grundt i et par år nu og troede noget andet :S Men det som Casper fortalte mig var at man normalt ville læse det i HEX, men det havde jeg så ikke lige fået helt ind...
Men tak ellers! Man bliver jo klogere som tiden går!
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
