Best å hardkode i assembly ?

[Force]

Hei alle sammen!

 

Akkurat nå undersøker jeg om det er best å hardkode direkte i maskinvaren enn å programmere i C++. Jeg skal bygge en hjemme cockpit der de fleste instrumenter er analoge, en bitte liten del av den er digital. Denne flytypen jeg vil lage kopi er Ilyushin 62 (Ikke 62M forbedringer). Jeg har funnet ut hvis jeg programmere den i vanlig integer, da står det meste av RAM ubrukt fordi hver integer tar opp en bestemt mengde addressering som kanskje bruker en brøkdel. Eller jeg kan bruke mange forskjellige bits chip og hardkode den. til hver instrument som beveger seg. Noen bruker 12 bits, noen bruker 16 bits, noen bruker 17 bits, noen bruker 8 bits, noen bruker 4 bits, etc. Så jeg vil ikke sløse med RAM forbruk og CPU forbruk.

 

Hva tenker dere om det ?

Endret 15. april 2014 av Force

[etse]

Jeg ser ikke helt hvordan du mener assembly skal løse det problemet du har? Om du ikke ønsker å bruke integer kan du bruke Chars og short ints? (1 byte). Man kan jo og enkelt brukte bits via via bit-masking om man ønsker.

[Araho]

Du trenger da ikke bruke assembly for å bruke forskjellige bitlengder på variabeltyper?

Dessuten, hvilken CPU/maskin skal dette kjøre på? Overheaden ved å bruke integer er ikke særlig stor for en moderne prosessor, spesielt ikke sammenlignet med float-beregninger. Dessuten kan det ofte være en fordel å ha variablene av samme type og bitlengde, slik at det blir myyye enklere og kjappere å gjøre beregninger på sensordataene.

Selv hvis dette skal kjøres på en embedded prosessor tror jeg nok jeg ville forholdt meg til standard variabeltyper som passer til det som skal registreres, uintN_t etc. Da funker C (/C++) fortsatt bedre enn assembler til de vanligste oppgavene. Enkelte høyytelseselementer og rutiner som kjøres _veldig_ ofte kan fortsatt lønne seg å skrive i assembler.

[Force]

32 bits betyr 32 binær digital valg som resulterer 2^32, og det er ikke mye hvis en har 32 bits prosessor med lav hastighet. Hvis en har 2^32, da blir det litt under 4.3 millioner forskjellige valgmuligheter.

 

La oss tenke først èn fuel måleinstrument som tar kansje 1024 oppløsning i presisjon for å rotere èn 360 grader, altså 3 steg hver 1 grad av 360 grader sirkel, og med forskjellig hastighet. Da blir det enormt regnekraft.

 

Bare X-Plane motor tar litt under 4 GB RAM for å simulere ALT; det vil si høydemåler som tar kanskje 256MB for å simulere hver 1 desimal for hvert fot opp til ca 65.000 fot høyde som tar 64MB ram. Eller simulere hver 4 bits for hver 0,x, 0-9, 10, 10, 10, 10 opp til hundre tusen fot, da blir det 16*6, da blir det 7 bits som er 128, eller 6 bits hvis 10*6 = ca 64.

 

Skjønner dere nå hva jeg tenker?

Endret 15. april 2014 av Force

[slacky]

32 bits betyr 32 binær digital valg som resulterer 2^32, og det er ikke mye hvis en har 32 bits prosessor med lav hastighet. Hvis en har 2^32, da blir det litt under 4.3 millioner forskjellige valgmuligheter.

- 4.29 milliarder. Ikke millioner.

 

[Gavekort]

Hei alle sammen!

 

Akkurat nå undersøker jeg om det er best å hardkode direkte i maskinvaren enn å programmere i C++. Jeg skal bygge en hjemme cockpit der de fleste instrumenter er analoge, en bitte liten del av den er digital. Denne flytypen jeg vil lage kopi er Ilyushin 62 (Ikke 62M forbedringer). Jeg har funnet ut hvis jeg programmere den i vanlig integer, da står det meste av RAM ubrukt fordi hver integer tar opp en bestemt mengde addressering som kanskje bruker en brøkdel. Eller jeg kan bruke mange forskjellige bits chip og hardkode den. til hver instrument som beveger seg. Noen bruker 12 bits, noen bruker 16 bits, noen bruker 17 bits, noen bruker 8 bits, noen bruker 4 bits, etc. Så jeg vil ikke sløse med RAM forbruk og CPU forbruk.

 

Hva tenker dere om det ?

 

Nei. C++ kompilatoren gjør optimaliseringer som selv en dyktig programmerer aldri kunne klart å utføre. Om du absolutt skal optimalisere koden din til "bare bones" så vil jeg anbefale deg å programmere i C fremfor C++ og deretter prøve deg på å modifisere assembly-koden som kompilatoren utfører.

 

Men hvorfor ikke programmere i C og bruke primitiver som uint4, uint8, o.l? Det vil spare deg mer minne, tid og sykluser enn å rote rundt med asm.

Endret 15. april 2014 av Gavekort

[Lycantrophe]

Det er ingen grunn til å bruke assembly for dette.

[GeirGrusom]

 Eller jeg kan bruke mange forskjellige bits chip og hardkode den. til hver instrument som beveger seg. Noen bruker 12 bits, noen bruker 16 bits, noen bruker 17 bits, noen bruker 8 bits, noen bruker 4 bits, etc.

#include <stdio.h>


typedef struct

{

    unsigned value : 4; // Definer et 4-bit usignert felt i strukturen.

} myValue_t;


main()

{

    const myValue_t myValue = { 15 };


    printf("%d", myValue.value);

}

Fordelen med C også er at koden er portabel på tvers av prosessorer, noe assembly av natur ikke er. Det er også langt enklere å vedlikeholde.

[torbjørn marø]

Fikk lyst å dele et sitat jeg kom over for litt siden med dere:

 

People who use assembly code are - if not in an actual minority - considered somewhat archaic or old-fashioned.

 

Det morsomme er at jeg fant dette i en bok som ble skrevet i 1967. Selv om assembly ble brukt så var det allerede den gang gammeldags.

[kyrsjo]

Med mindre du skal skrive for en veeeldig liten mikro-kontroller eller noen fryktelig spesialiserte greier (innerløkka i en video-dekoder eller noe slikt), glem det, da er ikke ASM i nærheten av verd bryet i praktiske aplikasjoner.

EDIT: Men, det kan selvsagt være gøy og nyttig å lære for læringens og forståelsens skyld!

Endret 7. oktober 2014 av kyrsjo

[Mr Burns]

Kan du fortelle litt mer om hvordan dette skal implementeres? Hvordan skal instrumenter simuleres?

 

Uansett, i de aller fleste tilfeller er kompilatorer laget av veldig flinke folk, og dermed er resultatet bedre enn de fleste klarer aa lage selv i assembler. Jeg anbefaler hoeynivaaspraak, og saa sjekke om det er noe som ikke kjoerer raskt nok.