Assembly: Hvordan begynne i Assembly?

[glucchip]

link Se der... det hjelper. !

6894515[/snapback]

haha

Takk skal du ha

[Gjakmarrja]

Viktig å lære å bruke google effektivt i sammenheng med programmering!

 

De fleste spørsmål har blitt spurt før, hvis ikke sjekk ut IRC!

[lnostdal]

Du er ute etter denne: http://download.savannah.gnu.org/releases/...-0-booksize.pdf

 

Den tar deg fra bunnen og videre oppover til høynivåspråk som f.eks. Python.

[Emancipate]

http://www.flatassembler.net

http://decard.net/article.php

http://www.wizardsolutionsusa.com/forum/showthread.php?t=388

Endret 20. september 2006 av tsg1zzn

[Kizzaz]

Jeg har faget Mikroprosessorer og digitale kretser, her skal vi drive med assemblyprogrammering for mikrochiper, vi skal bruker AVR studio 4

[Zethyr]

Hva vil du egentlig bruke assembly til? Det er faktisk en del enklere å begynne å lage små programmer osv. i assembly om du har litt kjennskap til et annet programmeringsspråk som f.eks. c++ eller liknende.

 

Jeg har lært alt det jeg kan av assembly gjennom reversing/cracking, selv om jeg enda er en nybegynner. Det jeg merker tydelig er at det er en del forskjeller på assembly-koding med hensikt å skrive egne programmer, og det å forstå andres disassemblede programmer.

 

Om du har til hensikt å lære deg reverse engineering kan jeg sikkert prøve å være til hjelp, og da kommer du borti store deler av assembly gjennom at du må lese en del dis-assemblet kode bl.a. Om du ønsker å lære deg å skrive dine egne programmer gjennom assemblykode kan jeg dessverre bistå deg enda mindre, for det er ikke noe jeg har drevet med i det hele tatt omtrent.

[Jaffe]

Såklart bør man kunne en eller annen form for programmering før en prøver seg på assembly...

[Okawari]

Jeg legger meg på denne tråden som en som har lyst å lære litt assembly.

Jeg vil gjerne legge min koding til en NES/6502?

[Jaffe]

Jeg antar du har sett her https://www.diskusjon.no/index.php?showtopic=519922

[tommen]

Assembler for pc'er er tricky da du via OS'er som Windows ikke får direkte tilgang til hardware som er plugga i (Skjermkort/lydkort t.eks). Så du er avhengig av å bruke biblioteker (eller lage dine egne) for å accessere hardwaren som er plugga i PC'en din via driverne. Dette er fordi at pc'ene i dag har så jævlig masse forskjellige typer hardware og det ville være upraktisk å skrive drivere i din software for å dekke alt sammen. I tilegg får du ikke lov til dette av sikkerhetsmessige grunner.

 

MEN det du kan gjøre er en av to ting. Skaff deg en gammel traver fra fortiden (f.eks. ei commodore 64 eller ei amiga) og lær deg assembler der. Prinsippene er i utgangspunktet det samme, flytte og behandle data for å oppnå det du ønsker. Og her kan du skrive direkte til hardware. Her kan du bruke emulatorer for å kjøre disse maskinene på PC på lik linje som om at du hadde en virkelig maskin. Men best er originalene seff^^

 

Det andre du kan gjøre er å bruke et "høynivå språk" som innpakning til de assembler rutinene du ønsker å skrive på pc. Her anbefaler jeg freebasic som er enkelt å bruke og lar deg bruke in-line assembler samt kalle opp bibliotek filer. Har også et bra forum der du kan få hjelp.

 

Morfaren din har sikkert skillz til begge disse alternativene, og hvis ikke så er det tonnevis av materiale online.

[Geek_Master]

Assembler for pc'er er tricky da du via OS'er som Windows ikke får direkte tilgang til hardware som er plugga i (Skjermkort/lydkort t.eks). Så du er avhengig av å bruke biblioteker (eller lage dine egne) for å accessere hardwaren som er plugga i PC'en din via driverne. Dette er fordi at pc'ene i dag har så jævlig masse forskjellige typer hardware og det ville være upraktisk å skrive drivere i din software for å dekke alt sammen. I tilegg får du ikke lov til dette av sikkerhetsmessige grunner.

 

MEN det du kan gjøre er en av to ting. Skaff deg en gammel traver fra fortiden (f.eks. ei commodore 64 eller ei amiga) og lær deg assembler der. Prinsippene er i utgangspunktet det samme, flytte og behandle data for å oppnå det du ønsker. Og her kan du skrive direkte til hardware. Her kan du bruke emulatorer for å kjøre disse maskinene på PC på lik linje som om at du hadde en virkelig maskin. Men best er originalene seff^^

 

Det andre du kan gjøre er å bruke et "høynivå språk" som innpakning til de assembler rutinene du ønsker å skrive på pc. Her anbefaler jeg freebasic som er enkelt å bruke og lar deg bruke in-line assembler samt kalle opp bibliotek filer. Har også et bra forum der du kan få hjelp.

 

Morfaren din har sikkert skillz til begge disse alternativene, og hvis ikke så er det tonnevis av materiale online.

 

Hvorfor bumper du en 2 år gammel tråd?

[tommen]

Hvorfor bumper du en 2 år gammel tråd?

 

Er det noe i veien med å svare på en thread som en ikke har sett før?

[Hayer]

nyttig tråd dette da

 

Hvordan fungerer egentlig en assembler, forsto ikke helt google treffene sine definisjon og forklaring :/

[tommen]

nyttig tråd dette da

 

Hvordan fungerer egentlig en assembler, forsto ikke helt google treffene sine definisjon og forklaring :/

 

Assembler er et såkallt "low-level" programmeringsspråk. Dvs at prosessoren kan kjøre koden du skriver direkte uten å gå via en line interpreter eller kompilere et høy-nivå språk (f.eks. C++).

 

Fordelen med assembler er at den koden du skriver går dritkjappt (med mindre du er helt narr og forelsker deg i interne looper osv), ulempen er at det er tidkrevende å skrive større prosjekt. I dag er det vanskelig å skrive assembler (maskin code) pga. at OS'et ikke tilater deg å skrive direkte til Hardware. Dette har selfølgelig noe med sikkerheten å gjøre. Derfor har du drivere som skal gjøre dette for deg. Så egentlig den bruken du kan ha for assembler i dag er enten hvis du skal skrive virus kode og slikt mannskjit eller optimalisering av rutiner i høy-nivå språk (ved bruk av in-line assembler). Den siste muligheten er selfølgelig hvis du er spik spenna gærn og liker å kode...

[Gjest Slettet+9871234]

1. Det burde være lett å finne gode eldre bøker om assembler via http://www.bookfinder4u.com/ Der er noen veldig gode i ZEN serien (mener at jeg har samtlige 5? bøker et sted):

 

http://www.amazon.com/Zen-Assembly-Languag...3625&sr=8-1

 

Ser et tilgjengelig eksemplar til 100 $ + frakt på amazon. Den er nok verdt prisen. Tar deg steg for steg til større og større forståelse. Den gang jeg leste om dette fant jeg også artikler om OOP Assembly. Søk:

 

object orented assembly

 

samt

 

len dorfman object oriented assembly

 

2. Selv lærte jeg meg ASM for 15 / 20 år siden ved å skrive avskrift av et assembler program på mange sider som jeg faktisk fikk til å fungere.

 

3. Merk at eldre utgaver av Borland C++ compilatoeren tillot inline assembler kode i C++:

 

ASM { Assembler kode her }

 

Vet ikke om siste etterfølger C++Builder 2009 Professional gjør det. Har ikke prøvd når denne posten skrives.

 

4. ASM er raskere enn C som igjen er raskere enn C++. Selv har jeg sett eksempler på fraktaler kjøre 100 ganger raskere i ASM enn i C. Se for eksempel artikkelen i Micro Cornucopia #43 Sept-Oct 1988 side 22-> "Fast fractals". Noe å tenke på for dem som alltid skal ha nye maskiner med de raskeste prosessorene. Bruker du gode algoritmer kombinert med ASM kode, er det vanskelig å slå en 386 makin på tallknusing selv med dagen multicore GHz maskiner.

 

5. En god bok for de som er interessert i tallknusing med ASM algoritmer:

 

Don Morgan (1992) Numerical Methods, Real Time and Embedded Systems Programming

M&T Books ISBN 1-55851-232-2

 

6. Disassembelring kan man lære mye av. Jeg har selv VCommunications disassembler. Ved hjep av den var det meget lett å finne at et program var virusinfisert. Sammenlignet bare assembler koden til programmet på original disketten med det som var installert på PC'en :-)

 

KBleivik

Endret 23. mai 2009 av Slettet+9871234

[Sokkalf™]

4. ASM er raskere enn C som igjen er raskere enn C++. Selv har jeg sett eksempler på fraktaler kjøre 100 ganger raskere i ASM enn i C. Se for eksempel artikkelen i Micro Cornucopia #43 Sept-Oct 1988 side 22-> "Fast fractals". Noe å tenke på for dem som alltid skal ha nye maskiner med de raskeste prosessorene. Bruker du gode algoritmer kombinert med ASM kode, er det vanskelig å slå en 386 makin på tallknusing selv med dagen multicore GHz maskiner.

 

Bullshit! Spesielt den siste setningen er langt på viddene.

 

Dette var kanskje delvis korrekt i 1988, men med dagens optimaliserende kompilatorer, vil kompilert C-kode i mange tilfeller være raskere enn "håndlagd" assembly. Dette fordi kompilatoren vet om en god del "snarveier" som ikke uten videre henger på greip logisk sett for noen som skriver "ren og pen" assembly-kode.

Klart, er du ekspert på både assembly og prosessorarkitekturen du koder for, kan du muligens hente inn noen clock cycles her og der, men det er svært få tilfeller hvor koding i assembly lar seg rettferdiggjøre overfor koding i C, spesielt pga. utviklingstid.

[Gjest Slettet+9871234]

Bullshit! Spesielt den siste setningen er langt på viddene.

Du kan umulig kunne mye om algoritmer: Stikkord

 

Fibonacci tallene:

- Rekursive funskjonskall

- Dynamisk programmering.

 

En nybegynner kan gjerne benytte rekursive funksjonskall. Da vil det ikke gå lang tid før stacken er fullt opp og maskinen venter i en evighet på neste trinn i beregningen. En erfaren programmerer vil benytte dynamisk programmering. Det er i seg selv nok til at du med en gammel 386 maskin kan kjøre i løkke rundt en av dagens multicore maskiner.

 

Dernest, så vidt jeg vet må C og C++ oversettes til ASM. Så vidt jeg vet er der også (en tilnærmet - fantes noen få unntak for intelprosessoren om jeg husker riktig) 1-1 relasjon mellom assembler og binærkode. Jeg antar at en god assembler programmerer vil kunne slå en dum prosessor som kun gjør det den blir bedt om. Naivt eksempel: Hva gjør en C rutine som dividerer eller multipliserer med potenser av 2? Laster inn en rutine som utføres i datamaskinens minne? Poenget er at ASM arbeider direkte på prosessorens registre.

 

Kanskje du skulle lete opp den artikkelen før du er så bastant i uttalelsene dine.

 

Klart, er du ekspert på både assembly og prosessorarkitekturen du koder for, kan du muligens hente inn noen clock cycles her og der, men det er svært få tilfeller hvor koding i assembly lar seg rettferdiggjøre overfor koding i C, spesielt pga. utviklingstid..

Personlig har jeg ingen ambisjoner om å synge i et orkester, dirigere det eller komponere musikken orkesteret spiller. Noen komponerer imidlertid den musikken.

 

Jeg har heller ingen ambisjoner om å bli en ekspert på assembly. Det forhindrer ikke at jeg håper jeg kan gi et bidrag til at andre blir det.

 

Jeg er ikke interessert i en lengre diskusjon om dette da JavaScript (DOM), PHP og C++Builder 2009 professional med innebygd reverse engineering funksjonalitet holder lenge for meg personlig.

 

hente inn noen clock cycles her og der

 

Jeg har imidlertid skrevet en hovedoppgave i matematikk på 295 sider levert på UIO om ulineær, kaotisk og fraktal matematikk. En klokkesykle spart per node kan bli tid om man har billioner av noder.

 

De som arbeider med klimasimulering i Sørishavet har ikke kraftige nok datamaskiner. Dimensjonen er for høy og kompleksiteten er for stor. Google:

 

ultra computer solve global environmental problems

 

Der man trenger tallknusing, kan sparte klokkesykler i slike systemer være forskjellen på suksess og fiasko (dvs. om simuleringen lykkes eller ikke). Noen må også komponere musikken.

 

Til slutt:

 

En som er interessert i å lære seg assembler vil sikkert også kunne finne og installere en unix (linux) dialekt som er sterkere intergrert mot assembler samt prosessoren enn andre operativsystemer. Signaturen din tyder på at du kan langt mer om unix og linux enn meg. For å si det enkelt. Raskhet er viktigere enn sikkerhet.

 

Håper at jeg gav et bidrag om litteratur til den opprinnelige posteren.

Endret 2. juni 2009 av Slettet+9871234

[Sokkalf™]

Du har rett, jeg har ikke mye peiling på algoritmer. Jeg mener dog fortsatt at du kraftig undervurderer C-kompilatorer.

 

Naivt eksempel: Hva gjør en C rutine som dividerer eller multipliserer med potenser av 2? Laster inn en rutine som utføres i datamaskinens minne? Poenget er at ASM arbeider direkte på prosessorens registre.

 

En C-rutine med optimalisering eksplisitt skrudd av gjør som du beskriver. gcc med optimalisering opererer direkte på registre med en bitwise shift left/right, som er den mest effektive måten å gjøre slik multiplikasjon/divisjon på (ihvertfall på x86).

 

Uansett er det ingenting som stopper deg fra å bruke bitshift direkte i C, eller fra å bruke vanlig "treg" multiply i assembly. Driver du med assembly må du vite om disse "snarveiene". Driver du med C, trenger du bare å tenke a = b * 2, som er logisk, og ikke a = b << 1 (som også er logisk, men på et annet nivå). Resultatet blir nøyaktig det samme, siden kompilatoren genererer like opcodes.

 

Noen algoritmer kan sikkert optimaliseres ytterligere av et menneske, men kompilatorene utvikler seg stadig, og idag er det ganske få tilfeller hvor håndkodet assembly er hensiktsmessig (annet enn for å lære seg det, som jo kan være nyttig i seg selv).

Endret 3. juni 2009 av Sokkalf^

[Gjest Slettet+9871234]

Jeg mener dog fortsatt at du kraftig undervurderer C-kompilatorer.

På ingen måte. C er kompakt og raskt til sitt formål som jeg mener primært er tallknusing.

 

Du kan kompilere (og blande) C (og C++) kode med C++Builder 2009.

 

Noen hevder: "Livet er for kort til å lære seg assembler."

 

http://www.amazon.com/Nortons-Assembly-Lan...n/dp/0136624537

 

Peter Norton's Assembly Language Book for the IBM PC var den boken jeg lærte meg litt om assembler.

 

Skrev som sagt avskrift av et program (på var det 30 sider?) og fikk det til å fungere. Lærte ganske mye av den boken da Peter Norton er enormt strukturert i sin programmering. Det er enda viktigere enn i C hvor man kan ende opp med dinglende pekere ("dangling pointers") som "peker i tomme luften." I ASM, når du åpner en rutine, må du for all del ikke glemme å lukke den. Peter Norton lærer deg det. Den boken kan også anbefales på det varmeste.

 

Selv mener jeg at studie av algoritmer er noe av det viktigste studie en dataingeniør kan benytte tiden til. Selv har jeg sett eksperter på JavaScript / DOM scripting som bruker boblesortering:

 

http://www.kjellbleivik.com/Books/

 

(Du vil finne noen assembler rutiner nederst på den siden.)

 

MERK:

Dette materialet og kildekoden er kun til utdannelse og skal ikke selges eller videredistribueres med profittformål.

 

Bla ned til lenken: Cameron Adams et. al.: The art & science of Java Script.

 

I kapittel 1 vil du finne kildekoden til en boble sorterings algoritme.

 

Boble sortering er den minst effektive av alle sorteringsalgoritmer og går i kvadratisk tid. Quick Sort, Heap Sort samt Merge Sort går in n Log(n) tid om jeg husker riktig, mens radix og telle sortering så vidt jeg husker går i lineær tid. For de som driver med sortering i store databaser kan dette være meget viktig.

 

Her

 

http://www.kloth.net/internet/bottrap.php

 

er et av mange eksempler på at C++Builder er god nok for meg så langt:

 

Sitat

 

Originally, the Indy Library is a programming library which is available at http://www.nevrona.com/Indy or http://indy.torry.net under an Open Source license. This library is included with Borland Delphi 6, 7, C++Builder 6, plus all of the Kylix versions.

 

Godt svar forresten.

Endret 3. juni 2009 av Slettet+9871234

[tommen]

En kompilator finner ikke på smarte look-up table trix og loop-unrolling trix som en coder gjør.... Glem hele denne diskusjonen!

 

en coder kan "fixe" 3d-algoritmer på snau hardware mens en kompilator har ikke nubbesjans til å gjøre det samme. Den er alt for generic i forhold til det. Registerbruk framfor minnebruk er "lesson #1" for en assembler programmerer...