Assembly: Assembly fremfor C++?

[Dead_Rabbit]

Jeg driver og lærer meg C++ nå( og er veldig fornøyd med språket så jeg kommer ihvertfall ikke til å skifte med det første)

men hva er fordelen med å lære seg assemly fremfor C++?(hvis det er noen da )

 

EDTI: kunne bare ha sett noen linjer ned så ville jeg ha funnet det jeg lette etter.

Endret 21. mai 2004 av zirener

[abcd423417984]

jeg mener det kommer helt ann på hva du skal bruke det til. Jeg tør å påstå at assembly vil gi deg et raskere resultat, men er mer jobb.

[Dead_Rabbit]

jeg mener det kommer helt ann på hva du skal bruke det til. Jeg tør å påstå at assembly vil gi deg et raskere resultat, men er mer jobb.

Da mener du hurtighet på programmet?

For det går da raskere å skrive et program i C++ enn i assembler?

EDIT:Det gjør det helt sikkert

Endret 18. mars 2004 av zirener

[TitanKvad]

Vel...

 

C / C++ har jo de fordelene at de går mye kjappere å kode da, som gjør dem mer aktuelle for software utvikler kompanier som ikke vil betale for lenger arbeid. Og så er C / C++ mindre arbeid å porte, siden man ikke trenger å bekymre seg for varierende instruksjons navn og lignende mellom platformer som gjerne bruker prosessorer med andre instruksjonssett.

Og så er vel C / C++ litt mer på 'moten' enn assembler da.

 

Men for dem av oss som gjerne driver med programmering på fritiden, har en del fritid å sløse med, er interissert i å lære mer i detalj hvordan ting hvirkelig fungerer, og ikke minst vil vite mer nøyaktig hva koden faktisk gjør, og gjerne er interisserte i mindre og raskere programmer, så er jo assembler ypperlig.

Og så har jo assembler en litt større l33t faktor over seg da. hehe

 

Om du ikke er interisert i å mekke hele driten i assembler, kan du jo også fint heller bare bruke det inline da.

 

Jeg digger det iaf og vil gjerne anbefale det

[Dead_Rabbit]

Vel...

 

C / C++ har jo de fordelene at de går mye kjappere å kode da, som gjør dem mer aktuelle for software utvikler kompanier som ikke vil betale for lenger arbeid. Og så er C / C++ mindre arbeid å porte, siden man ikke trenger å bekymre seg for varierende instruksjons navn og lignende mellom platformer som gjerne bruker prosessorer med andre instruksjonssett.

Og så er vel C / C++ litt mer på 'moten' enn assembler da.

 

Men for dem av oss som gjerne driver med programmering på fritiden, har en del fritid å sløse med, er interissert i å lære mer i detalj hvordan ting hvirkelig fungerer, og ikke minst vil vite mer nøyaktig hva koden faktisk gjør, og gjerne er interisserte i mindre og raskere programmer, så er jo assembler ypperlig.

Og så har jo assembler en litt større l33t faktor over seg da. hehe

 

Om du ikke er interisert i å mekke hele driten i assembler, kan du jo også fint heller bare bruke det inline da.

 

Jeg digger det iaf og vil gjerne anbefale det

Ok takk...

Men jeg har hørt så mye... om assebler, det er vel ikke så vansklig som folk sier eller?

[abcd423417984]

assembler ER vanskelig, men da det kommer til bruk av biblioteker (f.eks. windows programmering) er kallene de samme. Er bare litt mer tunvtvint å bruke dem.

[Alexen]

Assembly egner seg vel helst til å lage kjappe rutiner som f.eks kan legges i dll-filer og kalles fra andre programmer(c++/vb f.eks), tror ikke det er så mange som skriver hele programmer i assembly idag. En av grunnene til å lære seg assembly tror jeg vil være at man kanskje får en bedre forståelse av hvordan de andre språkene fungerer. Kjekt for den som har tid til det

[Dead_Rabbit]

Ok takker for alle svarene

[Maarud]

Du har ikke tiilgang til så mange biblioteker i assembly som i andre språk siden det er så grunnleggende..

Assembly brukes mest for og optimalisere tunge prosesser i spillmotorer og tunge applikasjoner.

Men mest av alt brukes det i mikrokontrollere... ( Det er digg )

Jeg selv har eget kit for programering av ATMEL sine mikrokontrollere og det er morro og sysle med. Dette er absolutt og annbefale...

[Tr1llobite]

Du kan jo bruke assembler til dll'er og lignende som du trenger mer kontroll over,

også bruker du C++ / Delphi (jeg gir meg ALDRI med å anbefale Delphi!) til alt annet.

[XPUserz]

Her er en bit fra .NET assembler (fra en MS-press bok jeg har)

 

//----------- Program header
.assembly extern mscorlib { }
.assembly OddOrEven  { }
.module OddOrEven.exe
//----------- Class declaration
.namespace Odd.or {
   .class public auto ansi Even extends [mscorlib]System.Object {
//----------- Field declaration
       .field public static int32 val
//----------- Method declaration
       .method public static void check( ) cil managed {
           .entrypoint
           .locals init (int32 Retval)
       AskForNumber:
           ldstr "Enter a number"
           call void [mscorlib]System.Console::WriteLine(string)
           call string [mscorlib]System.Console::ReadLine()
           ldstr "%d" // CHANGE!
           ldsflda int32 Odd.or.Even::val
           call vararg int32 sscanf(string,string,...,int32*) // CHANGE!
           stloc.0 // CHANGE!
           ldloc.0 // CHANGE!
           brfalse.s Error  // CHANGE!
           ldsfld int32 Odd.or.Even::val
           ldc.i4.1  // CHANGE!
           and
           brfalse.s ItsEven  // CHANGE!
           ldstr "odd!"
           br.s PrintAndReturn  // CHANGE!
       ItsEven:
           ldstr "even!"
           br.s PrintAndReturn  // CHANGE!
       Error:
           ldstr "How rude!"
       PrintAndReturn:
           call void [mscorlib]System.Console::WriteLine(string)
           ldloc.0  // CHANGE!
           brtrue.s AskForNumber  // CHANGE!
           ret
       } // End of method
   } // End of class
} // End of namespace
//----------- Calling unmanaged code
.method public static pinvokeimpl("msvcrt.dll" cdecl) 
   vararg int32 sscanf(string,string) cil managed { }

[Tr1llobite]

Jeg kan ikke si det lignet noe serlig på TASM'en som jeg bruker

når jeg skriver inline i Delphi!

push SM_CXSCREEN
call GetSystemMetrics
mov XX, eax
shr XX, 1
sub XX, 160
push SM_CYSCREEN
call GetSystemMetrics
mov YY, eax
shr YY, 1
sub YY, 120

 

EDIT: .NET har vel aldri vært "real programming" anyways

Dessuten finnes det jo mangen forskjellige assemblere

Endret 20. juni 2004 av kr1570ffz0r

[GeirGrusom]

Det kalles CLR, og er slik fordi det skal la seg kompilere på alle prosessorer (med .NET Framework installert selvsagt)

Ganske lurt egentlig, litt bedre(raskere) en Java Virtual Machine, siden programmet til slutt blir kompilert til native code.

[Frank2004]

Det kalles CLR, og er slik fordi det skal la seg kompilere på alle prosessorer (med .NET Framework installert selvsagt)

Ganske lurt egentlig, litt bedre(raskere) en Java Virtual Machine, siden programmet til slutt blir kompilert til native code.

[drall]

I de fleste tilfeller vil en moderne c/c++-kompiltor klare å optimalisere like bra som du klarer i assembly.

[GeirGrusom]

Nei.

[Tr1llobite]

Nei.

Spre budskapet. C/C++ vil aldri bli raskere.

Det er en grunn til at jeg kan lage programmer på 2 byte (som ikke gjør serlig mye, se signaturen min, kopier den inn i en fil og kompiler den med en assembler, husk at det må være 16 bits dos program... Ellers blir filen 1 kb...)

 

EDIT: Editer signaturen min litt...

 

EDIT2: MASM funker ikke til det. Bruk nasm (16 bits versjonen).

Endret 29. juni 2004 av kr1570ffz0r

[Frank2004]

Spre budskapet. C/C++ vil aldri bli raskere.

Det er en grunn til at jeg kan lage programmer på 2 byte (som ikke gjør serlig mye, se signaturen min, kopier den inn i en fil og kompiler den med en assembler, husk at det må være 16 bits dos program... Ellers blir filen 1 kb...)

 

EDIT: Editer signaturen min litt...

 

EDIT2: MASM funker ikke til det. Bruk nasm (16 bits versjonen).

Kodestørrelse har ikke så mye å si for hastigheten.

 

Det som er viktig er at instruksjonene ligger i riktig rekkefølge for å bruke alle pipelines optimalt, at du unngår branch mispredictions, og at dataene du jobber med ligger i cache. (Stort sett i motsatt rekkefølge av den jeg listet de opp i nå om dagen, tror jeg..?)

 

De to første der regner jeg med at alle nyere kompilatorer får til rimelig bra, sikkert en god del bedre enn den jevne asm-noob, og du har vel like god kontroll over minne-layout med C/C++.

Om du tar skrittet opp til Java, så får du t.o.m. run-time profilering og optimalisering av programmet for akkurat din cpu, selv om arkitekturen ikke en gang eksisterte når programmet opprinnelig ble kompilert.

 

Selvsagt kan du ta enkelte snarveier i asm, da du som regel vet mer om algoritmen og dataene dine enn du klarer å uttrykke i C++, men med tanke på hvor ressurskrevende det er å skrive maskinkode i forhold, og at 90% av koden din overhodet ikke spiller inn på ytelsen til programmet, så er det galskap å sitte og skrive all kode i assembly.

Dessuten er det jo som regel mye mer å tjene på optimaliseringer på algoritme-nivå enn å sitte og skrive om alt til asm.

 

Nå har jo maskinkode absolutt sin plass fortsatt, f.eks. i embedded programmering, håndkoding av algoritmer for vector/simd -enheter, kritiske kodeseksjoner o.l., men gå for Java om dere vil lære å programmere for 'fun' folkens.

Endret 29. juni 2004 av Frank2004

[Frank2004]

Og jeg vil gjerne vite hva .NET runtimen gjør med MSIL som en JVM ikke klarer å gjøre med bytecode, GG.

[Tr1llobite]

Nei du hare et poeng der, og jeg er klar over det.

MEN små (og da mener jeg SMÅ) programmer er kjappere enn f.eks. en 24 kb tom exe-fil fra MSVC. Små filer har mindre instruksjoner, men det kommer jo virkelig an på hvilke instruksjoner det er hvis det skal være raskere. Saken er den at C++ compilere legger til ting i begynnelsen av koden. Noen mener det er viktig, men det gjør ikke jeg.