Assembly: Lære assembly sier du ? Hvorfor ?

[nuxofa]

Hei du... Ja du ja...

Har du virkelig tenkt å lære deg assembly ?

 

Hvorfor ?

 

Du sitter sikkert og argumenterer for deg selv med følgende argumenter:

 

- Raske programmer

- Små filer

- Full kontroll over maskinen

- Guru på debugging

- Hacker status / høy nerdefaktor

- Designe drivere til hardware

- Lage ditt eget OS

- Vil vite alt som foregår i maskinen

- Vil ha evnen til å analysere virus...

- Cracke spill og programmer

- Skrive shellcode til exploits

- Skrive "proffe" virus...

( ikke sånne script kiddie virus som melissa )

- Ego boost

 

La meg kommentere disse argumentene...

 

- Raskere programmer

 

Joda.. Det er sant.. programmene er som regel raskere... Dette fordi de kan ta seg friheten å hoppe over en del "overhead" kode som eksempelvis C kompilere legger inn... Men er denne koden uinteressant ? Som regel er dette kode som sikrer stabilitet og sikkerhet... Er du sikker på at du vil fjerne denne også ?

 

Dessuten er det ikke sikkert at du er så god til å optimalisere koden som en kompiler er... Faktisk så er de fleste C kompilere MEGET effektive, og det kreves utrolig mye av en programmerer for å kunne optimalisere koden like bra.

 

- Små filer

 

Joda... I og med at man skriver prosessor instruksjonene direkte inn i programmene, blir filene som regel små... meget små.. Skriver man for eksempel et program av type "Hello world!", ser man fort at filen som er laget i assembly kan komme ned i størrelser på 100 byte... Sammenligner man dette med tilsvarende program i C vil man nok slite med å få programmet mindre enn 2kb.

 

Dersom du nå tenker "wow... assemblyprogram blir 1/20,48 av hva de blir i C!!", må jeg nok dessverre skuffe og si at filstørrelsene på ingen måte kan forventes å være proposjonale. Det som tar 99% av plassen i de fleste programmer er dataen, og ikke program koden. Har du forresten tenkt på hva den koden som blir utelatt i assembly versjonen gjør ? Som regel er dette kode som sikrer programmet mot feil!!!

 

Forøvrig er det også nevneverdig at programmer på 200b fortsatt opptar ca 4-64kb når det er lagret på disk, så de eneste som virkelig har nytte av denne optimaliseringen, er de som fortsatt bruker 2400 bauds modem ( eller ja... de som har behov for å dytte inn kode i andre programmer, eksempelvis shellkode programmerere, crackere og virus programmerere ).

 

 

- Full kontroll over maskinen

 

Full kontroll... hva innebærer det ? Jo... Det innebærer at du faktisk må gjøre ALT... Ta for eksempel et program på 1mb... Dersom dette programmet ikke inneholder data ( bilder, musikk, ikoner, tekst etc. ) betyr det faktisk at programmet inneholder ca 262144 linjer med assembly kode ( dette er tallet baseres på at programmet har et gjennomsnitt på 4 byte pr. instruksjon, som ikke vil være langt fra sannheten ).

 

Dersom du skrev med en hastighet på en linje kode i minuttet, ville du sitte og skrive dette programmet i mer enn 182 døgn i strekk.

 

- Guru på debugging

 

Joda... sant nok det, men hvor lang tid tar det å debugge programmer i assembly? Spesielt hvis programmene er skrevet i Java osv... I realiteten er det få som vil betale for den tidsbruken.

 

- Hacker status / høy nerdefaktor...

 

Hehe.. Dette er faktisk en av de argumentene som det er mest hold i... Gutta og jentene i "scenen" ( hei Tone ) setter assembly kunnskaper høyt, men er du sikker på at det ikke finnes bedre veier til status ?? Tilgang til kjappe datalinjer bruker å være den raskeste veien inn i scenen :wink:. Husk også at heltestatus er noe du får basert på dine handlinger, og ikke din kunnskap.

 

- Designe drivere til hardware

 

Nok et godt argument, men er du sikker på at driveren ikke kan skrives i andre språk ?

 

- Lage ditt eget OS

 

Se forrige argument... se også "Full kontroll over maskinen..."

 

- Vil vite alt som foregår i maskinen

 

Dette er etter min mening det desidert beste argumentet for å lære seg assembly... Men ikke glem at det tar lang tid... Ny teknologi kommer dessuten hele tiden... Om ikke så alt for lenge skifter vi til en annen prosessorteknologi, og da er det meste du kan om assembly, totalt verdiløst.

 

- Vil ha evnen til å analysere virus...

 

Ser ikke mange som utlyser stillinger for antivirus spesialister, men hvem vet... kansje Norman en dag har tenkt å utvide... Det å jobbe for et utenlandsk firma... Det er ikke umulig, men tradisjonellt er norsk ekspertise dyrt, og kan for eksempel kjøpes langt billigere fra land som India og Russland etc.

 

- Cracke spill og programmer

 

FYYY!!!! Slem gutt / jente...

 

- Skrive shellcode til exploits

 

FYYY!!!! Slem gutt / jente...

 

- Skrive "proffe" virus...

( ikke slike "script kiddie" virus som melissa )

 

FYYY!!!! Slem gutt / jente...

 

- Ego boost

 

Det å vite at man kan "alt" om noe er meget tilfredsstillende... men vær klar over at crackmes og lignende fort mister effekten... Overgangen til kopibeskyttelser, hacking av .gov servere og virus programmering frister veldig fort...

 

Personlig tror jeg i bunn og grunn at 90% av alle hackere, crackere og virus programmerere gjør det ene og alene for å bevise for seg selv og andre at ingen ting kan stoppe dem... Dette gir en solid ego boost. Den varer dog ikke lenge, og nye utfordringer må overvinnes for at de skal holde seg ovenpå. Jo mindre man lykkes i andre situasjoner, jo mer avhengig er man av å bevise "sitt overlegne intellekt"...

 

Dersom du fortsatt er hellig overbevist om at assembly er tingen for deg, vil jeg ønske deg lykke til!

 

- Nuxofa

 

 

Ps. Tro det eller ei, men assembly språket er faktisk av de enkleste å lære da det kun er et fåtall instruksjoner. Det som er komplekst er systemene man programmerer.

[tivolieselet]

ehh.. jo da det var da volsomt til en artikkel da!!!

 

btw: er ikke største delen av qnx skrevet i asmb. da??

[pegg]

hmm nå fikk jeg jo nesten lyst til å lære meg litt assembly

[Langbein]

Quote:

Den 2002-10-02 23:44, skrev nuxofa: Joda.. Det er sant.. programmene er som regel raskere... Dette fordi de kan ta seg friheten å hoppe over en del "overhead" kode som eksempelvis C kompilere legger inn... Men er denne koden uinteressant ? Som regel er dette kode som sikrer stabilitet og sikkerhet... Er du sikker på at du vil fjerne denne også ? Dessuten er det ikke sikkert at du er så god til å optimalisere koden som en kompiler er... Faktisk så er de fleste C kompilere MEGET effektive, og det kreves utrolig mye av en programmerer for å kunne optimalisere koden like bra.

Er ikke rare beskyttelsen i C, er det det? Sjekker ikke array-grenser og diverse andre ting som kan gjøre debugging til et *******.

 

Assembler-programmer blir likevel mindre fordi de bare inneholder det du har bedt om (eller rettere sagt kodet). Kan ikke se noe galt i det så lenge man bruker assembler til det det var ment for. Lager man komplette systemer for atomreaktorer eller flykontroll-systemer i assembler kan det nok bli trøbbel :smile:

 

Quote:

Forøvrig er det også nevneverdig at programmer på 200b fortsatt opptar ca 4-64kb når det er lagret på disk, så de eneste som virkelig har nytte av denne optimaliseringen, er de som fortsatt bruker 2400 bauds modem

Ikke hos meg da jeg bruker ReiserFS nesten overalt. Selv om block-størrelsen er 4Kb (kan velges) er den såpass lur at den selv kombinerer flere små filer i én block. Helt transparent selvsagt.

 

Men for alle stakkars Windows-brukere der ute (tenker da særlig på win9x-folket) så er jo dette et greit poeng.

 

En annen ting er jo at harddisker har blitt så store at folk flest (dessverre) ikke bryr seg om et program er på 100Kb eller 100MB. Men hva men utvikling for andre plattformer som PDA'er og mobiltelefoner? Driver selv og koder litt bla. for iPAQ og der er det greit å unngå bloatware :smile:

Quote:

Joda... sant nok det, men hvor lang tid tar det å debugge programmer i assembly? Spesielt hvis programmene er skrevet i Java osv... I realiteten er det få som vil betale for den tidsbruken.

Hva mener du? Man debugger da aldri Java-programmer på den måten. Java blir jo ikke kompilert til maskinkode, men snarere til plattform-uavhengig byte-kode. Altså får man ikke noe assembler-kode man kan debugge. Å debugge byte-koden for hånd kan man jo gjøre (hvis man er supernørd), men hva er poenget??

 

Quote:

men er du sikker på at driveren ikke kan skrives i andre språk ? - Lage ditt eget OS Se forrige argument... se også "Full kontroll over maskinen..."

Hvis du klarer å lage et OS uten bruk av assembler må jeg bare gratulere! Det er nemlig komplett umulig.

 

Det er endel misforståelser ute og går her. Mange har sikkert hørt at Unix ble skrevet i C, men hverken Linux eller andre *nix-varianter er ren C. Mesteparten er C men noe assembler må også til, spesielt på den mest low-level funksjonaliteten. Man prøver selvsagt å begrense bruken av assembler pga portability. C er jo ikke akkurat det beste språket på porting men ihvertfall bedre enn assembler. Forøvrig er det ingen andre språk (som jeg vet om) som kan matche kraften i C.

 

Drivere må også normalt inneholde assembler, avhengig av hva slags hardware det er snakk om og OS.

 

Quote:

Ny teknologi kommer dessuten hele tiden... Om ikke så alt for lenge skifter vi til en annen prosessorteknologi, og da er det meste du kan om assembly, totalt verdiløst.

Lære alt på nytt? Ikke min erfaring ihvertfall, og jeg har kodet assembler på diverse arkitekturer, både RISC og CISC. Grunnprinsippene er de samme selv om instruksjonsnavnene er forskjellige.

 

Quote:

Dersom du fortsatt er hellig overbevist om at assembly er tingen for deg, vil jeg ønske deg lykke til! ... Ps. Tro det eller ei, men assembly språket er faktisk av de enkleste å lære da det kun er et fåtall instruksjoner. Det som er komplekst er systemene man programmerer.

 

Jo takk! Syns det var veldig interessant å lære assembler selv om det ikke er det nyttigste "språket" for meg.

 

Virker som du legger litt for mye i dette med å lære assembler. Er jo tross alt ikke nødt til å kode alt i asm. Selv kan jeg både en haug med programmeringsspråk og asm til noen forskjellige arkitekturer. Jeg bruker alt til sitt bruk for å si det enkelt. Fins sikkert noen av disse nerde-folka du beskriver også, men er de noe verre enn andre nerder (f.eks spill-nerder, casemod-nerder eller til og med font-nerder :smile: )

 

En annen ting: man koder normalt ikke hele programmer i asm, men bruker C med inline-assembly der det trengs (og ja jeg gjentar: endel ting lar seg ikke gjøre selv i C) eller for å speede opp kode. Vi har jo 10/90-regelen eller hva den het. 10% av koden bilr eksekvert 90% av tiden, og det kan derfor være nyttig å skrive om utvalgte rutiner i asm.

 

PS. x86-arkitekturer (og andre CISC-prosessorer) har forresten ikke et fåtall instruksjoner. Til enkelt bruk må man selvsagt ikke lære alt, men hvis man skal gå grundig til verks er det langt mer å sette seg inn i enn i mange høynivå-språk

 

 

[ Denne Melding var redigert av: Langbein på 2002-10-03 02:27 ]

[nuxofa]

Quote:

Den 2002-10-03 02:24, skrev Langbein: Er ikke rare beskyttelsen i C, er det det? Sjekker ikke array-grenser og diverse andre ting som kan gjøre debugging til et *******.

 

Vet... men det er fortsatt kvalitets sikring den ekstra koden blir benyttet til... Selv om det er minimalt av den.

 

Quote:

Assembler-programmer blir likevel mindre fordi de bare inneholder det du har bedt om (eller rettere sagt kodet). Kan ikke se noe galt i det så lenge man bruker assembler til det det var ment for. Lager man komplette systemer for atomreaktorer eller flykontroll-systemer i assembler kan det nok bli trøbbel :smile:

 

*kremt* "Det det var ment for" ?? Assembly er et nødvendig "onde"... Dette kommer av at man i bunn og grunn må oversette alt til et språk som prosessoren forstår... Jeg sier ikke at jeg ønsker ren C/java hardware i maskinen, men alle programmeringsspråk er ment å lette byrden slik at man ikke skal være avhengig av å måtte skrive alt i ASM. Men jeg er helt enig med deg... Assembly bør være det språket man lærer seg når man behersker andre spåk som C, og man finner ut at enkelte rutiner bør skrives i ASM.

 

Quote:

En annen ting er jo at harddisker har blitt så store at folk flest (dessverre) ikke bryr seg om et program er på 100Kb eller 100MB. Men hva men utvikling for andre plattformer som PDA'er og mobiltelefoner? Driver selv og koder litt bla. for iPAQ og der er det greit å unngå bloatware :smile:

 

Enig i at assembly har mere for seg på PDA enheter da de har veldig lav lagrings kapasitet... Hva bloatware angår, bør man keller se på kompresjonsrutiner på vedlagt data enn å skifte til assembly. Slik real-time komprimering var det Amiga programmererne var mye flinkere til enn PC programmerene, og det gjorde ofte at Amiga programmer var mye mer kompakte og ofte mer effektive enn tilsvarende program på PC.

 

 

Quote:

Hva mener du? Man debugger da aldri Java-programmer på den måten. Java blir jo ikke kompilert til maskinkode, men snarere til plattform-uavhengig byte-kode. Altså får man ikke noe assembler-kode man kan debugge. Å debugge byte-koden for hånd kan man jo gjøre (hvis man er supernørd), men hva er poenget??

 

Vel... I den grad man lager .exe filer av java kode, kan man disassemble dem, men det er ikke gøy... Jeg er ingen ekspert i java, men jeg har vært borte i et par tilfeller hvor vi har vært avhengige av å debugge kode som har vært generert ut fra java kode... uansett er dette kun et argument dersom man ikke har tilgang til kildekoden, og dermed lite relevant... uansett så var java et dårlig eksempel... enig i det.

 

 

Quote:

Hvis du klarer å lage et OS uten bruk av assembler må jeg bare gratulere! Det er nemlig komplett umulig.

 

Det er faktisk mulig så lenge man har en kompiler som støtter det... man kan for eksempel benytte C til å lage bootsectors etc. ( ikke at jeg kan det eller at jeg vil anbefale noen å gjøre det... ).

 

Quote:

Det er endel misforståelser ute og går her. Mange har sikkert hørt at Unix ble skrevet i C, men hverken Linux eller andre *nix-varianter er ren C. Mesteparten er C men noe assembler må også til, spesielt på den mest low-level funksjonaliteten. Man prøver selvsagt å begrense bruken av assembler pga portability. C er jo ikke akkurat det beste språket på porting men ihvertfall bedre enn assembler. Forøvrig er det ingen andre språk (som jeg vet om) som kan matche kraften i C.

 

Jeg er fullstendig klar over at bootloadere og mesteparten av hardware relatert kode i *nix er skrevet i assembly. Argumentet mitt bygger på at man ikke nødvendigvis trenger å kunne alle detaljene rundt assembly for å lage ett OS.

 

Quote:

Lære alt på nytt? Ikke min erfaring ihvertfall, og jeg har kodet assembler på diverse arkitekturer, både RISC og CISC. Grunnprinsippene er de samme selv om instruksjonsnavnene er forskjellige.

 

Jeg har også skrevet assembly på flere forskjellige hardware platformer... henholdsvis MC6502/MC6510 ( c64 og emma trainere :wink:... MC68000 serien i Amiga... X86 teknologi i dagens pc (hvilket forøvrig er den som er vanskeligst å jobbe med av disse... savner alle registerne i MC68k serien :wink: )... pluss at jeg har skrevet noen linjer kode for andre systemer.

 

Selv om grunnprinsippet er det samme, er det ikke selve instruksjonene som tar lang tid å lære, men de forskjellige systemene. Se bare på skjerm og nettverkskort... Dersom man skal skrive software til disse enhetene uten å ha mulighet til å bruke underliggende API (eksempelvis fra DOS), er det faktisk veldig stor forskjell fra produsent til produsent selv om man bruker samme instruksjons sett og samme hardware i bunnen.

 

 

Uansett... denne teksten var skrevet for å advare de som ikke vet forskjellen på de forskjellige programmerings språkene... Assembly er ikke det beste språket å starte med med mindre man ønsker å bruke all sin fritid, eller man har litt mer fetish/sm aktige behov som for eksempel å modifisere andres kode.

 

Mens vi er inne på fetish kan jeg nevne en kuriositet... det er en stor overvekt av assembly programmerere (i forhold til andre typer programmerere) som til tider blir observert mens de sitter og skriver kode med nesa :wink:... Man kan jo lure på om dette har en sammenheng med kulturen eller om det rett og slett kreves en egen rase folk for å skrive assembly programmer *s*

 

- Nux

[Ola PeK]

Brife-innlegg.....

[nuxofa]

Quote:

Den 2002-10-03 14:13, skrev Ola PeK: Brife-innlegg.....

 

Kun svar på tiltale, men kall det hva du vil... I don't care...

[DigitalErr0r]

Vel, Assembly er da veldig nyttig når du f.eks skal lage sub-prosedyrer, hvem har sagt at en må kode hele programmet i asm? Du kan f.eks kode "mainloopen" til ett grafikkprog. f.eks, og resten av prosedyrene kan du bruke C/C++. Jeg bruker ofte asm i denne situasjonen, spes. når jeg koder software rendered gfx.

[TLZ]

Bare nykjerrig: Går det an å programere ein OS i Java, C# eller andre høgnivå's språk? Med hjelp fra asm og c for runtime....

Hmm.... har forstått rett så er vel dette umuligt...

 

spm:Ettersom C# er ein ECMA standar kan hvem som helst lage kompilator til den, noen som vet om en Binary Kompilator for C#?

[mister_pingla]

Et råd til folk som vil begynne med programmering: IKKE begynn med assembly!!

 

Grunnen er rett og slett at man ikke trenger det i dag. Pga en del ting som maskin spec har gått i taket samt vi har fått Objekt-Orienterte programmer.

 

Eneste du trenger assembly for i dag, er hvis du må ned på lavnivå )som assembly er) for å tweake eller gjøre ting som det ikke finnes klasser for og som API'n ikke støtter.

 

Hvis du er interessert i å skrive windows programmer, spill osv, så begynn med C++ eller java. Grunnen er at de blir såpass store at de blir mer effektive enn rein assembly.

 

Tingen er nemlig at med assembly så klarer man bare å holde oversikten til et gitt punkt, og dermed blir det ueffektivt iforhold til oo, hvor compileren gjør det for deg.

 

Kun hvis du skal skrive og selge 3d spill som krever mye av maskinen kan det være forsvarlig å sette seg ned med assembly. Men til og med er ikke vits den dag i dag, fordi grafikk pakkene er blitt så optimalisert at man trolig ikke klarer å tvinge noe mer ut av de.

 

Hvis noen som tror at Blizzard, Codemasters, Microsoft sitter å gnikker på assembly nivå når man lager spill, så får man tro om igjen.

 

Da man skrev Doom, Quake osv så brukte man fortsatt assembly, men den tiden er forbi nå.

 

Men jeg sier ikke at man IKKE skal lære seg assembly. Tvert imot. Det er et svært nyttig språk i den forstand at man forstår litt mer om hva som foregår. Dessuten er det av og til man må bruke assembly for å få til ting som sagt.

[TLZ]

Hvis noen som tror at Blizzard, Codemasters, Microsoft sitter å gnikker på assembly nivå når man lager spill, så får man tro om igjen

Tror faktisk det er et fåtall som begynner å skrive spill i C#/VB.NET med DX9 Managed. C# er Just in time compiling akkurat som Java. Nå sliker språk kan produsere spill uten problemer så er det heelt sikkert at assembler er unødvendig.

btw. Ingen som vet om Binary compiler til C#?

[nuxofa]

Ok...

Advarselen var egentlig ment for at folk skulle stille seg noen spørsmål om hvorfor i all verden de ønsket å begynne med assembly. Assembly er ikke det beste språket å starte med... Det tar lang tid, er tungt, og de fleste som prøver gir gjerne opp ganske fort.

 

For de som virkelig ønsker å temme datamskinen, vil jeg anbefale dem følgende:

 

Begynn med å lær deg C++ og Assembly.

De aller fleste programmeringsspråk benytter de samme API kallene, og dette kan gjøres nesten like lett fra Assembly. Da de fleste bøker som vil gi deg en god systemforståelse benytter C, er det viktig å kunne forstå C slik at man kan følge kurs og litteratur.

 

Her er et lite utsnitt av en helt vanlig windows rutine... Som du ser ( hvis du har programmert litt i C etc. så er det meste bare API kall uansett. Ikke så ulikt C osv.

 

...



WinMain proc hInst_WinMain:DWORD, hPrevInst:DWORD, CmdLine:DWORD, CmdShow:DWORD

LOCAL msg:MSG

invoke Win_Init,hInst



   MsgLoop:

invoke GetMessage,ADDR msg,NULL,0,0

cmp eax, 0

je ExitMsgLoop

invoke TranslateMessage, ADDR msg

invoke DispatchMessage,  ADDR msg

jmp MsgLoop

   ExitMsgLoop:

return msg.wParam

WinMain endp





WndProc	proc hWin:DWORD, uMsg:DWORD, wParam:DWORD, lParam:DWORD

LOCAL pt:POINT

   .if uMsg == WM_COMMAND



.if wParam == IDOK



.elseif wParam == IDM_EXIT

 invoke SendMessage,hWin,WM_SYSCOMMAND,SC_CLOSE,NULL

.endif





   .elseif uMsg == WM_CREATE

.if HookActive==FALSE 

          invoke InstallHook,hWin

             .if eax!=NULL 

                mov HookActive,TRUE 

             .else 

                mov HookActive,FALSE

             .endif 

       .endif

...

 

Inspirasjon...

Dersom du er glad i å spille spill, og samtidig ønsker å være litt neo/matrix aktig, så er en av de beste motivasjons faktorene faktisk det å traine spill... Da trenger man ikke skrive mye kode... 100 linjer holder som regel til det formålet man har, men man lærer utrolig mye om hvordan ting fungerer.

 

Man lærer også å skrive effektiv kode da man som regel må skrive sin egen kode inn i minneområdene til spillene ( der det som regel er ganske trangt om plassen ).

 

For mer info om dette, anbefaler jeg at du tar en titt på FHCF sine sider, www.fhcf.net eller rusler innom #cracking.no neste gang du er på EFNET

 

For info om Assembly programmering under windows....

Les http://win32asm.cjb.net da dette er den desidert beste kilden på nettet til Assembly programmering under windows.

 

 

Lykke til....

 

-Nux

[abcd423417984]

imponerende, rett og slett

[GeirGrusom]

Joda.. Det er sant.. programmene er som regel raskere... Dette fordi de kan ta seg friheten å hoppe over en del "overhead" kode som eksempelvis C kompilere legger inn... Men er denne koden uinteressant ? Som regel er dette kode som sikrer stabilitet og sikkerhet... Er du sikker på at du vil fjerne denne også ?

delvis tøys, dette er kode som er lagt der fordi kompilatoren i bunn og grunn klipper og limer fra biblioteker. Den må gjøre dette fordi den ikke er "lur" nok til å flette dette sammen som et menneske ville gjort for å spare klokke pulser.

 

ull kontroll... hva innebærer det ? Jo... Det innebærer at du faktisk må gjøre ALT... Ta for eksempel et program på 1mb... Dersom dette programmet ikke inneholder data ( bilder, musikk, ikoner, tekst etc. ) betyr det faktisk at programmet inneholder ca 262144 linjer med assembly kode ( dette er tallet baseres på at programmet har et gjennomsnitt på 4 byte pr. instruksjon, som ikke vil være langt fra sannheten )

Du har ikke full kontroll i Windows programmering, så dette er ikke et argument lenger. Assembly programmering i dag ligner veldig på C.

 

Hehe.. Dette er faktisk en av de argumentene som det er mest hold i... Gutta og jentene i "scenen" ( hei Tone ) setter assembly kunnskaper høyt, men er du sikker på at det ikke finnes bedre veier til status ?? Tilgang til kjappe datalinjer bruker å være den raskeste veien inn i scenen . Husk også at heltestatus er noe du får basert på dine handlinger, og ikke din kunnskap.

Du kan ikke legge inn C/C++ kode inn i en binær fil, Ihvertfall ikke få det ut som C/C++.

 

Nok et godt argument, men er du sikker på at driveren ikke kan skrives i andre språk ?

Drivere skal kunne lese og skrive til maskinporter i et høyt tempo, men det er som du sier, de skrives faktisk ofte i C.

 

Lage OS:

Se forrige argument... se også "Full kontroll over maskinen..."

Unix kjernen er skrevet i C (Linux er mer eller mindre en kopi(klipp og lim) av den orginale Unix koden som ble utgitt(gratis) på 70-tallet, så hvorfor Linus Thorvalds får så mye av æren bak linux, forundrer meg) det var en vanlig oppfattelse at OS måtte skrives i Assembly på den tiden.

 

Ps. Tro det eller ei, men assembly språket er faktisk av de enkleste å lære da det kun er et fåtall instruksjoner. Det som er komplekst er systemene man programmerer.

Nei nei, hvor finner du informasjonen din? det over 140 forskjellige instruksjoner i intel 386+ prosessorene, faktisk er det over 200 på Intel Pentium 4

Men det er bare rundt 20-40 instruksjoner en vanligvis bruker.

Det som er noe dritt i Assembly er at det er veldig uoversiktlig, det er veldig vanskelig å vite hva et assembly program gjør ved å bare se på koden.

[_W_]

Nå er det jo slik at en hvis type personer faktisk liker å lære ting og finne ut av hvordan ting fungerer ikke for å imponere andre, men for sin egen skyld. For å virkelig forstå hva en moderne prosessor gjør er det ingen vei utenom assembler. Vel, ingen lett vei. Er noen som liker å pugge opkoder óg...

 

Og med så mye snakk om hvor bra dagens kompilatorer er, overser du jo glatt det faktum at noen må lage disse kompilatorene

 

 

 

 

Kan nevne at mitt andre programeringsspråk (etter C64 basic) var C64 assembler, og hvis jeg kunne skrudd tiden tilbake hadde jeg hoppet over all puslingen jeg gjorde med basic før jeg fant ut at du fikk dobbelt så mye minne ledig hvis du slettet basic-tolkeren og brukte maskinkode

[[kami]]

Og med så mye snakk om hvor bra dagens kompilatorer er, overser du jo glatt det faktum at noen må lage disse kompilatorene

 

Nå er jo dagens kompilatorer stort sett skrevet i det språket dem skal kompilere for. (c++ kompilator er skrevet i c++, c kompilator i c.. etc)

[GeirGrusom]

Nå er jo dagens kompilatorer stort sett skrevet i det språket dem skal kompilere for. (c++ kompilator er skrevet i c++, c kompilator i c.. etc)

 

Hva er dette for noe tøys? Det har INGEN betydning hvilket språk du skriver en kompilator i, og den første kompilatoren som ble skrevet var nok en Assembløy kompilator, som ble skrevet i ren maskinkode, Deretter kom C kompilatoren som mest sannsynlig ble skrevet i Assembly.

Det er ikke noe problem å skrive en C++ kompilator i Visual Basic eller Turbo Pascal, for det er kun snakk om oversettelser, du skal oversette

int x = 4;

til

DB X

XOR X, X

ADD 4, X

Eller ikke akkurat slik, men til maskinkode, og det trenger du ikke å skrive i C, Assembly eller maskinkode, du kan skrive det rett i QB.

[GenericName]

...

Endret 12. januar 2011 av Token

[GeirGrusom]

Du taler tull,

Visual Basic kode blir gjort om til Assembly kode når du starter/kompilerer programmet!

 

Du kan lage programmeringsspråk i Visual Basic, jeg har gjort det flere ganger (eller script ihvertfall)

 

Jeg blir litt sliten nå; men kan du VB burde du vite hvordan programmering fungerer; noe du åpenbart ikke gjør.

 

Når jeg skriver bare C++ eller Visual Basic mener jeg kompilator til det språket.

 

Visual Basic er skrevet i C(eller C++)

C var opprinnelig skrevet i Assembly, samme med C++, men en C++ kompilator lar seg gjøre å skrive i Visual Basic, En assembler lar seg gjøre å skrive i Visual Basic (faktisk mye letter en C++ kompilator)

 

Ble det litt klarere nå? flott.

Endret 29. juli 2004 av GeirGrusom

[GenericName]

...

Endret 12. januar 2011 av Token