Assembler programmering

Det forekommer mig at assemblerprogrammering nedprioriteres på ingeniørstudiet ?! Det kan da ikke passe at hele industrien er gået over til C/C++ og andre højniveau sprog ?

Jeg har personligt altid skrevet min kode i assembler da jeg græmmer mig ved al den ekstra kode der genereres ved brug af compilere. Når man har programmeret i længere tid opbygger man sig et bibliotek over kode man kan genbruge og det bliver faktisk ligeså nemt at programmere i assembler som i højniveausprog. Endelig kan man selvfølgelig anvende macroer...de er tit hurtigere at anvende end subrutinekald....

Det forekommer mig at være en trist udvikling at industrien er så fokuseret på at få tingene færdige i en fart (man antager at det er hurtigere at programmere i højniveausprog end i assembler)...er det mon et spørgsmål om at der mangler kompetence blandt udviklerne udi assemblerprogrammering ?

Reply to
Jan Pedersen
Loading thread data ...

Det tager længere tid at skrive assembler programmer end hvis du bruger højniveau sprog. Overskueligheden er mindre, osv.

Med de størrelser maskiner vi har idag er det ikke et reelt problem.

Det samme gør man med objektorienterede sprog.

Jeg vil til enhver tid foretrække en compiler der beslutter om det kan svare sig at inline koden.

Kan du modbevise at det ikke er hurtigere ?

Jeg er selv uddannet ingeniør, og har programmeret i 22 år, selv startet som assembler udvikler. Men efter jeg lærte C indså jeg hurtigt at der kom mere kode igennem af samme kvalitet som ved assembler.

Det eneste tidspunkt jeg idag anvender assembler er i tidskritiske interrupt metoder, eller i extremt små systemmer hvor hver eneste byte tæller. Ud over disse situationer ser jeg højniveau sprog som en klar fordel.

Jeg ser frem til at se dine argumenter for at bruge assembler, altså ud over at du bedre kan lide det.

p.s. På mit studie havde vi assembler af 80c535 og DSP cpu'er

--
Med venlig hilsen
Søren Reinke   Fjern det åbenlyse ved email svar
 Click to see the full signature
Reply to
Søren Reinke

Hej Jan

I dag er de fleste ordentlige C compilere så gode til at optimere at jeg vil våge den påstand at man ikke kan skrive det bedre selv.

Kun kritiske punkter så som interrupts osv som søren nævner kan måske være gunstigt at lave i Assembler og så alligevel ikke ...

M.v.h. lasse

Reply to
Lasse Madsen

Nemt:

- Koden fylder mindre (optimeret)

- Afvikles hurtigere

Selv anvendte jeg også 80c535 på elektroniktekniker studiet og vi programmerede både i assembler , c og pascal. Jeg kan nu se at vi på ingeniør studiet kun skal have lidt DSP assembler programmering og meget meget lidt om 80x86/pentium :(

Men ok..jeg ved det at det er nemmere at genbruge højniveausprog rutiner og det er nemmere at portere disse til andre platforme...ligesom det er surt for en person der har programmeret en slags cpu i mange år i assembler hvis hans/hendes firma pludselig går fra disse og over til en anden type med anden cpu kerne ....så bliver det en stejl indlæringskurve :(

Ja ja heldigvis kan jeg på hobbybasis programmere alt det jeg vil i assembler :)

Reply to
Jan Pedersen

Ikke enig ... der er jo ikke så mange måder at gøre to ting af samme sag på... jeg vil våge den påstand at en IAR compiler til enhver tid skriver mere kompakt kode (eller samme) som du vil kunne gøre i assembler.

M.v.h. Lasse

Reply to
Lasse Madsen

I begge tilfælde vil jeg påstå compileren er bedre til at optimere end du er, da den kender platformen meget bedre.

F.eks. på CPU'er med pipelining, betyder det utroligt meget hvilken rækkefølge instruktionerne kommer i for at opnå bedste mulig hastighed.

Som ingeniør er du ikke uddannet til at kende en speciel platform dybt (80x86), men derimod uddannet til at kende metoder, principper og være flexibel osv.

Så sandt så sandt.

Tro mig jeg var selv vild modstander af det højniveaus pjat da jeg startede på ingeniør uddannelse, men i dag bruger jeg kun assembler hvis det absolut er nødvendigt.

Det har du så sandelig ret i :-)

p.s. Held og lykke på studiet :-)

--
Med venlig hilsen
Søren Reinke   Fjern det åbenlyse ved email svar
 Click to see the full signature
Reply to
Søren Reinke

Hej Jan,

Pas nu på, du rører et emne der kommer ind under religion for mange og som enhver med blot moderat indsigt erkender... Folk der ikke ved at assembler er det optimale er bare religiøse fanatikere og dem kommer der ikke noget godt ud af at diskutere med ;)

--
Venlig hilsen,
Søren
 Click to see the full signature
Reply to
Søren

Jan pas på dette er flamebait af den værste skuffe.

Reply to
Søren Reinke

Et af de tungtvejende argumenter for ikke at bruge assembler til andet end små driverfunktioner er, at kode skrevet i et hølniveausprog kan porteres til flere processorfamilier. Hvis du har brugt flere mandeår på at udvikle en applikation i assembler til én processor, er du stavnsbundet til at benytte den i hele applikationens levetid. Selv ved opgraderinger idndenfor samme familie kan der opstå inkompabiliteter.

Reply to
Torsten Lund

Hvor lang tid tager det dig så at optimere til en ny processorfamilie eller måske portere til en helt anden platform?

Man skal være helt ekstremt dygtig for at skrive assemblerkode der er bedre end den en god compiler kan lave til en moderne CPU. En moderne DSP har f.eks. typisk 12 pipeline niveauer, og det er tæt på umuligt at holde styr på ved gammeldags assemblerprogrammering.

Kritiske loops kan man måske skrive i assembler, men resten kan ikke betale sig.

signing off.. Martin Sørensen

Reply to
Martin Sørensen

Det vil jeg ikke helt give dig ret i! Det gælder ihvertfald ikke for c compileren til Analog Devices DSP familie. Ved implementation af et FIR filter i C kunne jeg højst opnå en orden på 190. Ved at skrive det i den tilhørende asm. kunne der laves filtre med orden på de ønskede 400. Så asm. til den pågældende platform er da altid godt at mestre!

Men til ikke tid/plads-krævende aplikationer ser jeg da ingen grund til at skrive sin software i asm.

-- morten

Reply to
Morten Jørgensen

"Martin Sørensen" skrev i en meddelelse

betale

er det ikke snare sådan at man skriver et program der køre sideløbende (resident) sammen med den kode man er ved at udvikle i et højniveausprog , dette program måler så hvor CPU bruger mest tid henne ,der efter går man ind og optimere netop det sted i koden med assembler ?

nu er jeg ikke selv ngeniør eller programør for den sags skyld , men jeg har da lavet kode i assembler i de gamle dag som nogle mener var så gode (Z80, 6502 TMS9900

68000 68030 ) men det var jo på hjemme computere og dengang var det lige som af nød at vi brugte en assembler (bortset fra der heller ikke var plads i RAM til både en interpreter og en compiler) man kunne simpelt hen ikke "nå" diverse registre på anden måde,(nogen der husker Peek og Poke) interrupt var en anden ting der var det "maskinkoden" ( det kaldte man det den gang) der var bedst fordi der skulle så fandens meget hastighed til , også fordi at hardwaren var så forbandet grafik orienteret , den der kunne lave den bedste assembler kode havde også den bedste (hurtigste) grafik,

jeg havde faktisk en basiccompiler skrevet til en basicinterpreter der så compilerede sig selv, så den var lidt hurtiger om at compiler :)

--
Venlig Hilsen
Michael Meidahl Jensen
 Click to see the full signature
Reply to
Michael Meidahl Jensen

Hvis du nu skal flytte det samme FIR filter til en DSP fra en helt anden producent, hvor lang tid ville det tage dig med assembler ?

p.s. Din c-compiler er åbenbart bare ikke god nok.

--
Med venlig hilsen
Søren Reinke   Fjern det åbenlyse ved email svar
 Click to see the full signature
Reply to
Søren Reinke

DSP processorer er et særligt problem pga. pipelining arkitekturen. Dem tog jeg ligesom heller ikke med i min betragtning da jeg aldrig håber at skulle beskæftige mig med disse udover på mit ingeniør studie. Min interesse ligger i områder som styring, regulering mv. Og her taler vi ikke PID regulering og den slags :) da denne slags regulering med fordel kan implementeres i en DSP processor.

Assembloer programmering bliver selvfølgelig ved med at eksistere som anvendt programmeringssprog : nogen skal jo lave compilerne :)

Reply to
Jan Pedersen

Hej Søren,

Absolut ikke !

Som Piet Hein udtrykte det:

Den der kun ta'r spøg for spøg Og alvor kun alvorligt Han og Hun har faktisk fattet Begge dele dårligt

Så kald det hellere en humoristisk måde at beskrive min _enighed_ med Jan i spørgsmåle om at smede direkte på jernet (som jeg i øvrigt har udtrykt ofte nok her i gruppen og hver gang med en røvfuld "religiøse" flames til følge, hvilket det var en reference til - godt at man er asbest-coated :)

--
Venlig hilsen,
Søren
 Click to see the full signature
Reply to
Søren

Hej Jan,

Man kan altid håbe, men de skriver jo også compilere i HLL's nu om dage.

--
Venlig hilsen,
Søren
 Click to see the full signature
Reply to
Søren

Jeg er selv midt i en ing uddannelse(i Århus) og kan fortælle dig at vi har haft masser og masser af assembler programmering. Især programmering på små single board computere, programmering af eks vis PEEL kredse samt en masse hardcore DSP programmering !

Reply to
Brian 8700

har

Hold lige programmerbar logik udenfor assemblerprogrammering.

En computer (fra den mindste 4 bit til den største 64bit) AFVIKLER instruktioner. Bisse instruktioner har et bitmønster. En assembler oversætter en sproglig forståelig linje tekst til een binær instruktion.

Det gør en PEEL ikke. Den er et netværk af gates og FF'er, der kan sammenkobles med nogle fuses. Nogle logikfamilier bruger RAM, andre EEprom og endnu anfre flash elementer som fuses. Den slags kan programmeres i forskellige sprog, hvoraf VHDL og Verilog er de mest produktive og mest udbredte. Af andre sprog kan nævnes PALASM, og beslægtede antikverede sprog, hvor man angiver logiske ligninger.

Bo //

Reply to
Bo Bjerre

Hmm. Nu er jeg ikke ingenør, men datalog fra Københavns Universitet.

Og, der tror jeg man droppede assembler for noget der mindede om 20 år siden - undtagen til en enkelt opgave i løbet af studiet.

MAO: Diskussionen har været ført før - og med undtagen af nogen få specialiserede situationer, vinder højniveausprog. Jeg kan indskyde at jeg selv ligger og roder med et mikroos med sensorsupport, multihopnetværk over en bitlevel radio, osv, der skrives i en slags C (med objekter), og oversætter til < 256 bytes ram og < 4KiB rom. Kun de allermest hardwarenære ting, som nanosleep, opsætning af ADC, portretninger, den slags, er i assembler (inlinet, faktisk. Vi har ingen "assembler filer"). Formentlig mindre end 5%. Og, du vil få ganske svært ved at optimere den assembler oversætteren laver. Både i størrelse og hastighed. Men, det skyldes formentlig at vores oversætter system laver en statisk analyse af _hele_ kildetræet på een gang under oversættelse og derfor kan lave nogen meget aggresive optimimeringer. Et sådan system får vi langt mere ud af, end at forsøge at optimere selv.

Derimod tager det kun meget kort tid at flytte dette system til f.eks. en anden CPU.

Mads

P.S. Bare så du ikke tror jeg er ude efter assembler programmører, så skal du vide at jeg stadig beundrer Mel:

formatting link
... men jeg ville ønske at skulle rette hans kode...

--
Mads Bondo Dydensborg.                                madsdyd@challenge.dk
Visit http://www.sexuallymutilatedchild.org/ a day when you feel strong
Reply to
Mads Bondo Dydensborg

til

Jo. enkelte interrupt rutiner og enkelte dele af realtime kerne laves i asm, men ellers er C vejen frem.

ved

som

Moderne compilere er meget gode, tag fx. Keil compileren, den kan lave LST filer hvor man kan se asm koden og det er meget godt det den laver.

fokuseret

Det tror jeg ikke, men udviklingstiden betyder meget.

--
mvh/rg. Christian
I would have to ask the questioner. I haven't had a chance to ask
 Click to see the full signature
Reply to
Christian B. Andresen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.