Mitä etuja voidaan saavuttaa assembler-kielen käytöllä c-kielen sijaan?
Assembler vs. C-kieli
esa
33
5177
Vastaukset
- nopeampi
Sovelluksen suoritus on nopeampaa. Tästä ei yleensä kuitenkaan ole suurta hyötyä, koska pienehköt ohjelmat toimivat muutenkin nopeasti. Suuremman ohjelman kirjoittaminen ja varsinkin ylläpitäminen assemblerilla on melko toivotonta.
Sitä paitsi C-kielellä tehdyt ohjelmat toimivat aika nopeasti nekin. Riippuu tietysti paljon toteutustavasta. Jos välttämättä haluat käyttää assembleria, voisi sitä ajatella jonkin nopeuskriittisen osan tekemiseen samalla, kun muu osa ohjelmasta tehdään C:llä.- G-uru-7
Välttämättä c-kielinen ohjelma ei ole hitaampi sillä nykyiset kääntäjät osaavat optimoida käännöksessä koodia varsin lahjakkaasti; assemblerissa joutuu tekemään optimoinnit itse ja monissa tapauksissa kääntäjä tuottaa optimoidumpaa koodia kuin liha.
- testaaitsekin.
Noin 4x nopeampi suoritus kuin optimoidussa C/C koodissa.
- mitattu on ja moneen kertaan. - dfgdgdgdf
testaaitsekin. kirjoitti:
Noin 4x nopeampi suoritus kuin optimoidussa C/C koodissa.
- mitattu on ja moneen kertaan.Täyttä sontaa.
Nykypäivänä kääntäjät tuottavat 95% tapauksista nopeampaa koodia kuin hyvä assembly ohjelmoija pystyy tuottamaan käsin.
Lisäksi kääntäjät tuntevat käyttöalustan huomattavasti paremmin kuin koodaaja itse joten se pystyy optimoimaan eri arkkitehtuureille paremmin.
Tuo käsi asmin nopeus pätee ehkä enää retro tietokoneissa ja skenetouhuissa kun väsätään jotain suorituskyky kriittistä rutiinia tehottomalla alustalla. - dfgdgdgdf
dfgdgdgdf kirjoitti:
Täyttä sontaa.
Nykypäivänä kääntäjät tuottavat 95% tapauksista nopeampaa koodia kuin hyvä assembly ohjelmoija pystyy tuottamaan käsin.
Lisäksi kääntäjät tuntevat käyttöalustan huomattavasti paremmin kuin koodaaja itse joten se pystyy optimoimaan eri arkkitehtuureille paremmin.
Tuo käsi asmin nopeus pätee ehkä enää retro tietokoneissa ja skenetouhuissa kun väsätään jotain suorituskyky kriittistä rutiinia tehottomalla alustalla.>>Nykypäivänä kääntäjät tuottavat 95% tapauksista nopeampaa koodia kuin hyvä assembly ohjelmoija pystyy tuottamaan käsin.
- 342342423423423
dfgdgdgdf kirjoitti:
>>Nykypäivänä kääntäjät tuottavat 95% tapauksista nopeampaa koodia kuin hyvä assembly ohjelmoija pystyy tuottamaan käsin.
Ei se mene näin enää. Kääntäjät osaavat optimoida niin paljon paremmin koodinsa kuin ihminen käsin.
Pientä overheadia tulee tietysti funktiokutsuista yms yms.. mutta jos nyt puhutaan vaikka puhtaasti algoritmeista niin kyllä C:llä saa vähemmällä vaivalla nopeampaa koodia.
Puhtaalla assemblyllä tehty ei kyllä vieä lähellekkään aina pisintä kortta. Pitää nimittäin olla melkoinen alustavirtuoosi että osaa käyttää alustan tarjoaman käskykannan mahdollisimman tehokkaasti. - 453453534534534
342342423423423 kirjoitti:
Ei se mene näin enää. Kääntäjät osaavat optimoida niin paljon paremmin koodinsa kuin ihminen käsin.
Pientä overheadia tulee tietysti funktiokutsuista yms yms.. mutta jos nyt puhutaan vaikka puhtaasti algoritmeista niin kyllä C:llä saa vähemmällä vaivalla nopeampaa koodia.
Puhtaalla assemblyllä tehty ei kyllä vieä lähellekkään aina pisintä kortta. Pitää nimittäin olla melkoinen alustavirtuoosi että osaa käyttää alustan tarjoaman käskykannan mahdollisimman tehokkaasti.>>Puhtaalla assemblyllä tehty ei kyllä vieä lähellekkään aina pisintä kortta. Pitää nimittäin olla melkoinen alustavirtuoosi että osaa käyttää alustan tarjoaman käskykannan mahdollisimman tehokkaasti.
- sdfsdfsfsdf
453453534534534 kirjoitti:
>>Puhtaalla assemblyllä tehty ei kyllä vieä lähellekkään aina pisintä kortta. Pitää nimittäin olla melkoinen alustavirtuoosi että osaa käyttää alustan tarjoaman käskykannan mahdollisimman tehokkaasti.
Enpä tiedä millä esihistoriallisella kääntäjällä olet leikkinyt mutta omien testien mukaan ainakin GCC3 ja GCC4 optimoi moiset pois tiehensä jopa ilman erillisiä optimointi flageja.
- sdfsdfsfsdf
sdfsdfsfsdf kirjoitti:
Enpä tiedä millä esihistoriallisella kääntäjällä olet leikkinyt mutta omien testien mukaan ainakin GCC3 ja GCC4 optimoi moiset pois tiehensä jopa ilman erillisiä optimointi flageja.
Lisätään nyt vielä että mm. GCC optimointi flageilla jauhaa jo käännösvaiheessa mahdolliset laskujen välitulokset valmiiksi jos algoritmi sen sallii.
- 2+7
sdfsdfsfsdf kirjoitti:
Enpä tiedä millä esihistoriallisella kääntäjällä olet leikkinyt mutta omien testien mukaan ainakin GCC3 ja GCC4 optimoi moiset pois tiehensä jopa ilman erillisiä optimointi flageja.
Huoh näitä trolleja. Jätän sinut tänne kinastelemaan keskenäsi niin menen itse ohjelmoimaan. GCC4 käytössä jos satuit ihmettelemään kääntäjävalintaani.
- sdfsdfsfsdfs
2+7 kirjoitti:
Huoh näitä trolleja. Jätän sinut tänne kinastelemaan keskenäsi niin menen itse ohjelmoimaan. GCC4 käytössä jos satuit ihmettelemään kääntäjävalintaani.
No miten voit sitten väittää moista paskaa täällä kirkkain silmin?
- mittalaitteita,
esimerkiksi signaalisuodattimia tai FFT:tä
on aika turha lähteä tekemään C:llä.
Assembler-ohjelman koodin pituus on
suunnilleen kolmasosa C:llä tehdystä
ja nopeus suunnilleen kolminkertainen.- gfsfsf3wrc3r23
Kuinka niin. Oikeastaan kaikki ajateltavissa olevat algoritmit voidaan kirjoittaa C:llä selkeämpään ja ymmärrettävämpään (ylläpidettävämpään) muotoon kuin asmilla.
Loput hommasta hoitaa kääntäjän agressiivinen optimointi.
Lopputulos on todennäköisesti nopeampi tai vähintään yhtä nopea kuin manuaalisesti optimoit assembly versio. - gfsfsf3wrc3r23
gfsfsf3wrc3r23 kirjoitti:
Kuinka niin. Oikeastaan kaikki ajateltavissa olevat algoritmit voidaan kirjoittaa C:llä selkeämpään ja ymmärrettävämpään (ylläpidettävämpään) muotoon kuin asmilla.
Loput hommasta hoitaa kääntäjän agressiivinen optimointi.
Lopputulos on todennäköisesti nopeampi tai vähintään yhtä nopea kuin manuaalisesti optimoit assembly versio.>>Lopputulos on todennäköisesti nopeampi tai vähintään yhtä nopea kuin manuaalisesti optimoit assembly versio.
- sdfsfsdfsdf5435
gfsfsf3wrc3r23 kirjoitti:
>>Lopputulos on todennäköisesti nopeampi tai vähintään yhtä nopea kuin manuaalisesti optimoit assembly versio.
Pitää oikeasti olla virtuoosi ja tuntea alustansa läpikotaisin että nykyään pääsee edes C kääntäjien tasolla.
Tosin sitten voi olla joitakin poikkeuksia joita kääntäjä ei ota huomioon ja on mahdollista käsin puukottamalla kääntäjän aikansaannosta saada vähän lisää suorituskykyä. - jamppa pohjoisesta
gfsfsf3wrc3r23 kirjoitti:
Kuinka niin. Oikeastaan kaikki ajateltavissa olevat algoritmit voidaan kirjoittaa C:llä selkeämpään ja ymmärrettävämpään (ylläpidettävämpään) muotoon kuin asmilla.
Loput hommasta hoitaa kääntäjän agressiivinen optimointi.
Lopputulos on todennäköisesti nopeampi tai vähintään yhtä nopea kuin manuaalisesti optimoit assembly versio.C selkeämpää ja ymmärrettävämpää kuin asm? Puhutko nyt makroassemblystä vai pelkästä assemblystä? Eikö makroassemblyssä voi käyttää aivan samalla tavalla for-silmukoita, if-lauseita, jne muita rakenteisen ohjelmoinnin työkaluja? Ja jos noiden makrojen päälle vielä nakkaa asianmukaisen kommentoinnin, niin onko C:n etu luettavuudessa muka oikeasti niin suuri, että sillä on käytännön merkitystä?
Omaa makroassembleriani kirjoittaessa (virtuaalikoneelle tosin, että saisin oman ohjelmointikielen aikaiseksi) C:llä huomasin usein turvautuvani goto-käskyyn, koska vaikka kuinka yritin faktoroida C-koodia nätimmän näköiseksi label goto -yhdistelmä osoittautui aina luettavammaksi kuin ylimääräisten if-lauseiden ja tilamuuttujien käyttö. Koodin hajauttaminen pikku funktioon per tehtävä juttu olisi tehnyt kokonaisuudesta vielä hankalamman hahmottaa, joten sitäkään en tehnyt. Jos C:ssä vain olisi tiettyjä ominaisuuksia, joihin olen tottunut muissa kielissä, niin kenties C:lläkin olisi homma hoitunut ilman hyppykäskyn ja nimiöiden käyttämistä.
Ja mitä tulee kääntäjien aggressiiviseen optimointiin, niin nehän osaavat optimoida vain sellaisilla tavoilla, jotka ne luoneet ohjelmoijat ovat niille opettaneet. Ja siinähän juuri tuleekin esille ihmisen ja ihmisen rakentaman koneen välinen ero. Ihminen voi vain ottaa kääntäjän tuottaman konekielisen koodin, kääntää sen assemblyksi, optimoida sitä manuaalisesti tavoilla, joita kääntäjän luoda ei kääntäjälle opettanut, ja sitten kääntää koodin takaisin konekielelle niin, että lopputulos on nopeampi kuin kääntäjän tuottama. On loogisesti ja teoreettisesti mahdotonta, että nykyiset koneet (olkoon kyseessä sitten rautana tai softana tehty kone) ymmärtäisi asian paremmin kuin asian parhaiten ymmärtävä asiantuntijajoukko yhteensä). Ja jos joku saataisiinkin oppimaan jotain, mitä ihmiset eivät vielä ole hoksanneet, niin sittenhän se voisi opettaa ihmisiä niin, että oltaisiin taas samalla viivalla.
Mutta se on kyllä totta, että nykyään pitää olla jo aika asiantunteva, että pärjäisi konetta vastaan koodin optimoinnissa, ja hyvin harvalla oikeasti teollisuudessa koodaavalla on aikaa hankkia tuollaista asiantuntijuutta. jamppa pohjoisesta kirjoitti:
C selkeämpää ja ymmärrettävämpää kuin asm? Puhutko nyt makroassemblystä vai pelkästä assemblystä? Eikö makroassemblyssä voi käyttää aivan samalla tavalla for-silmukoita, if-lauseita, jne muita rakenteisen ohjelmoinnin työkaluja? Ja jos noiden makrojen päälle vielä nakkaa asianmukaisen kommentoinnin, niin onko C:n etu luettavuudessa muka oikeasti niin suuri, että sillä on käytännön merkitystä?
Omaa makroassembleriani kirjoittaessa (virtuaalikoneelle tosin, että saisin oman ohjelmointikielen aikaiseksi) C:llä huomasin usein turvautuvani goto-käskyyn, koska vaikka kuinka yritin faktoroida C-koodia nätimmän näköiseksi label goto -yhdistelmä osoittautui aina luettavammaksi kuin ylimääräisten if-lauseiden ja tilamuuttujien käyttö. Koodin hajauttaminen pikku funktioon per tehtävä juttu olisi tehnyt kokonaisuudesta vielä hankalamman hahmottaa, joten sitäkään en tehnyt. Jos C:ssä vain olisi tiettyjä ominaisuuksia, joihin olen tottunut muissa kielissä, niin kenties C:lläkin olisi homma hoitunut ilman hyppykäskyn ja nimiöiden käyttämistä.
Ja mitä tulee kääntäjien aggressiiviseen optimointiin, niin nehän osaavat optimoida vain sellaisilla tavoilla, jotka ne luoneet ohjelmoijat ovat niille opettaneet. Ja siinähän juuri tuleekin esille ihmisen ja ihmisen rakentaman koneen välinen ero. Ihminen voi vain ottaa kääntäjän tuottaman konekielisen koodin, kääntää sen assemblyksi, optimoida sitä manuaalisesti tavoilla, joita kääntäjän luoda ei kääntäjälle opettanut, ja sitten kääntää koodin takaisin konekielelle niin, että lopputulos on nopeampi kuin kääntäjän tuottama. On loogisesti ja teoreettisesti mahdotonta, että nykyiset koneet (olkoon kyseessä sitten rautana tai softana tehty kone) ymmärtäisi asian paremmin kuin asian parhaiten ymmärtävä asiantuntijajoukko yhteensä). Ja jos joku saataisiinkin oppimaan jotain, mitä ihmiset eivät vielä ole hoksanneet, niin sittenhän se voisi opettaa ihmisiä niin, että oltaisiin taas samalla viivalla.
Mutta se on kyllä totta, että nykyään pitää olla jo aika asiantunteva, että pärjäisi konetta vastaan koodin optimoinnissa, ja hyvin harvalla oikeasti teollisuudessa koodaavalla on aikaa hankkia tuollaista asiantuntijuutta."C:llä huomasin usein turvautuvani goto-käskyyn, koska vaikka kuinka yritin faktoroida C-koodia nätimmän näköiseksi label goto -yhdistelmä osoittautui aina luettavammaksi kuin ylimääräisten if-lauseiden ja tilamuuttujien käyttö."
C-kielessä on erilaisia silmukoita ja haaraumia sun muita käyttökelpoisia juttuja jotka sinunkin kannattaisi ajan kanssa opetella. Tässä yksi hyvä nettiopas:
http://www.ohjelmointiputka.net/oppaat/opas.php?tunnus=cohj_1
"Koodin hajauttaminen pikku funktioon per tehtävä juttu olisi tehnyt kokonaisuudesta vielä hankalamman hahmottaa, joten sitäkään en tehnyt. "
Koodin jako aliohjelmiin on varsin yksinkertainen ja tehokas tapa selkiyttää ohjelman rakennetta. C-kielen tapa välittää parametrit ja paluuarvot funktiosta on kyllä hieman mutkikas mutta varsin looginen, tekee kielestä varsin käyttökelpoisen melko laajoissa kokonaisuuksissa.
Ohjelmoinnin eka taso on se että ohjelma saadaan tekemään se minkä sen oli tarkoituskin. Seuraava taso on keskittyä semantiikkaan eli koodin selkeyteen ja luettavuuteen.- Delphiguru
jamppa pohjoisesta kirjoitti:
C selkeämpää ja ymmärrettävämpää kuin asm? Puhutko nyt makroassemblystä vai pelkästä assemblystä? Eikö makroassemblyssä voi käyttää aivan samalla tavalla for-silmukoita, if-lauseita, jne muita rakenteisen ohjelmoinnin työkaluja? Ja jos noiden makrojen päälle vielä nakkaa asianmukaisen kommentoinnin, niin onko C:n etu luettavuudessa muka oikeasti niin suuri, että sillä on käytännön merkitystä?
Omaa makroassembleriani kirjoittaessa (virtuaalikoneelle tosin, että saisin oman ohjelmointikielen aikaiseksi) C:llä huomasin usein turvautuvani goto-käskyyn, koska vaikka kuinka yritin faktoroida C-koodia nätimmän näköiseksi label goto -yhdistelmä osoittautui aina luettavammaksi kuin ylimääräisten if-lauseiden ja tilamuuttujien käyttö. Koodin hajauttaminen pikku funktioon per tehtävä juttu olisi tehnyt kokonaisuudesta vielä hankalamman hahmottaa, joten sitäkään en tehnyt. Jos C:ssä vain olisi tiettyjä ominaisuuksia, joihin olen tottunut muissa kielissä, niin kenties C:lläkin olisi homma hoitunut ilman hyppykäskyn ja nimiöiden käyttämistä.
Ja mitä tulee kääntäjien aggressiiviseen optimointiin, niin nehän osaavat optimoida vain sellaisilla tavoilla, jotka ne luoneet ohjelmoijat ovat niille opettaneet. Ja siinähän juuri tuleekin esille ihmisen ja ihmisen rakentaman koneen välinen ero. Ihminen voi vain ottaa kääntäjän tuottaman konekielisen koodin, kääntää sen assemblyksi, optimoida sitä manuaalisesti tavoilla, joita kääntäjän luoda ei kääntäjälle opettanut, ja sitten kääntää koodin takaisin konekielelle niin, että lopputulos on nopeampi kuin kääntäjän tuottama. On loogisesti ja teoreettisesti mahdotonta, että nykyiset koneet (olkoon kyseessä sitten rautana tai softana tehty kone) ymmärtäisi asian paremmin kuin asian parhaiten ymmärtävä asiantuntijajoukko yhteensä). Ja jos joku saataisiinkin oppimaan jotain, mitä ihmiset eivät vielä ole hoksanneet, niin sittenhän se voisi opettaa ihmisiä niin, että oltaisiin taas samalla viivalla.
Mutta se on kyllä totta, että nykyään pitää olla jo aika asiantunteva, että pärjäisi konetta vastaan koodin optimoinnissa, ja hyvin harvalla oikeasti teollisuudessa koodaavalla on aikaa hankkia tuollaista asiantuntijuutta."Omaa makroassembleriani kirjoittaessa (virtuaalikoneelle tosin, että saisin oman ohjelmointikielen aikaiseksi) C:llä..."
hmmm....
Miksi ihmeessä ihmiset viitsivät käyttää C:tä sellaiseen ohjelmointiin, jossa merkkijonot ovat tärkeitä ? Makroassembleri lienee mainio esimerkki ohjelmasta, jossa merkkijonoja (eli assembly -kielistä lähdekoodia, makroineen) käsitellään paljon.
C:ssähän ei ole oikeita merkkijonoja, vaan niitä simuloidaan merkkitaulukoilla.
Itse olisin ilman muuta koodannut makroassemblerin Delphillä: siinä on aidot merkkijonot, ja toisin kuin C:hen fiksoituneet kuvittelevat, Delphin merkkijonon maksimipituus EI ole 255 merkkiä vaan yli miljardi merkkiä.
Kun vielä Delphin VCL sisältää käteviä luokkia kuten TStrings ja TStringlist, niin noillakin saa aikaan yhtä sun toista hyödyllistä.
Ja koska Delphi on aito objektikieli, kukaan ei kiellä sinua periyttämästä omaa luokkaa, esim näin:
type
TReadOnlyStrings = class(TStrings)
// luokan toteutus tähän
end;
Ja toisin kuin java, joka työntää luokat "väkisin kurkusta alas" (javassa ei ole olemassa irrallisia funktioita, vaan jokainen funktio on jonkun luokan jäsenfunktio), niin Delphissä päätät itse, koodaatko luokan vai irrallisia proseduureja/funktioita.
Eikä se ole joko tai , vaan sekä että. Eli voit laittaa samaan ohjelmaan sekä luokkia että irrallisia aliohjelmia.
Tärkeää tietää Delphistä:
JOS versio on Delphi2009 tai uudempi, silloin Char=WideChar ja SizeOf(char) = 2.
MUTTA jos versio on vanhempi kuin 2009, silloin Char=AnsiChar ja SizeOf(char) = 1.
niin, Delphissähän char, CHAR tai Char (tai miksei vaikka cHAr, ihan sama, toisin kuin C:ssä) on tarkoitettu merkin tallennukseen, ja merkkijonon (String) osanen on char.
Sensijaan C:n tapa käyttää char -nimitystä pienehköille kokonaisluvuille, se taas kulkee delphissä nimellä:
byte (unsigned; 0..255)
Shortint (signed: -128.. 127).
var
A : char;
begin
A := char(65); // eksoottinen tapa asettaa A:n arvoksi iso kirjain 'A'.
A := 'B'; // tämä on toki paljon helpompaa.
end;
yllä myös esimerkki tyyppimuunnoksesta Delphillä.
Miksi ihmeessä moni kuvittelee että valinta olisi tehtävä C:n ja assemlerin välillä kun Delphikin on olemassa?
Ja toki Delphissä voi vaikkapa:
function Add(A,B:Integer)::Integer; register;
asm
add EAX, EDX // palauttaa funktion paluuarvona summan A B.
end;
Miksikö?
No, koska 1. parametri A välittyy EAX -rekisterissä, toinen EDX, ja kolmas (jos on) ECX -rekisterissä, ja funktion paluuarvo on se, mikä funktion päättyessä on EAX -rekisterissä (paitsi Int64 -tyypillä EDX:EAX -rekisteriparissa).
Delphin asm - end -lohkon sisällä voi siis vapaasti käyttää EAX, EDX ja ECX -rekistereitä, mutta jos haluaa käyttää vaikkapa ESI, niin...
PUSH ESI
// käytä ESI -rekisteriä tässä ...
POP ESI
ja ehkä paras juttu merkkijonokäsittelyssä:
var
SL : TStringlist;
S,S2 : String;
begin
SL := TStringlist.Create;
try
SL.Values['nimi'] := 'Kalle';
SL.Values['puhelin'] := '0509876';
// ja nyt...
S := SL.Values['nimi']; // S saa arvon 'Kalle'
S2 := SL.Values['puhelin']; // S2 saa arvon '0509876'
finally
FreeAndNil(SL);
end;
end;
- ja sotket
ASMia tarvittaessa joukkoon.
- apiguru
pääset konkreettisesti käsiksi laitteistoon. voit vaikka poksauttaa näytönohjaimen hajalle ja muuta mukavaa.
lisäksi ohjelman koko on hemmetin pieni, muutaman kilotavun.
assembly - niin, se on assembly ei assembler, assembler on assembly-kääntäjä - ei ole kovin käyttäjäystävällinen kieli ja sillä ei tee nykyään paljon mitään jos ei ole ajureitten kanssa tekemisissä.- Jack H. Carmon
Siihen laitteistoon mitään käsiksi päästään suojatussa tilassa.
Satusetä taas veistelee omiaan. - huonoohjelmoijayritt
Jack H. Carmon kirjoitti:
Siihen laitteistoon mitään käsiksi päästään suojatussa tilassa.
Satusetä taas veistelee omiaan.Assemblyllä pääsee kyllä käsiin heti ring-0:n, jos taito riittää..
- miksuh.
Assembly-kieltä käytetään lähinnä aikakriittisten toimintojen ohjelmointiin, sekä sillon kun muistinkulutus on puristettava mahdolisimman pieneksi. Assembly kieltä käytetään edelleen myös testauksessa ja esim uusien embedded laitteiden kehityksessä sillon kun korkeamman tason kääntäjiä ei vielä ole saatavilla.
Niin ja kielen nimi on siis Assembly, ei Assembler. Assembler on se kääntäjä joka muuttaa mnemonisen Assemblyohjelmakoodin tietokoneen ymmärtämäksi konekieleksi.- kunoletteniinnopeita
Koittakaapa tehdä vaikka Bluray/mkv -purkaja sitten jollain muulla kielellä, vaikka python, kuuluu tietysti toimia AMD Athlon 1000GHz, loppuuko ohjelmointitaito?
- sdfsfsfss
kunoletteniinnopeita kirjoitti:
Koittakaapa tehdä vaikka Bluray/mkv -purkaja sitten jollain muulla kielellä, vaikka python, kuuluu tietysti toimia AMD Athlon 1000GHz, loppuuko ohjelmointitaito?
C:llä onnistuu tietysti fysiikan lakien sallimissa rajoissa. Eikä varmasti lopu taito ennen kuin assembly veistäjältä. Sen verran helpompi C on ylläpitää.
- Mika0800
Assemblerillahan voit toki koodata esim. jonkin aliohjelman. Ja asm -yhteiskäyttö onnistuu muidenkin kielten kuin C/C :n kanssa, kuten esim. Delphin.
Esim Delphissä näin:
function Koe1(x,y,z:Integer):Integer; register; assembler;
asm
// Nyt EAX=x, ECX=y ja EDX=z
add EAX, ECX
add EAX, EDX
// jätä laskun lopputulos EAX -rekisteriin
end;
Delphissä voi myös kirjoittaa funktion Delphillä, ja sitten vain Delphin sisäänrakennetulla debuggerilla askellat koodia haluamaasi kohtaan ja...
View / Debug Windows / CPU ...
... ja nyt pääset katsomaan, minkänäköistä assemblerkoodia Delphi -kääntäjä on tehnyt.
Tarvittaessa voit hieman uudelleenkoodata Delphillä ja tutkia, miten käääntäjän generoima assemblerkoodi muuttuu. Joskus pelkästään tuolla tavallakin voi optimoida merkittävästi, mutta jos ei, niin assemblerilla vain itse koodaamaan.
Delphin yhteydessä kannattaa lukea Delphin oma Help aiheesta (F1), sillä jotkut rekisterit on syytä jättää rauhaan; tai ainakin ensin laittaa ne pinoon (PUSH) ja lopuksi palauttaa sieltä (POP).
assemblerin osaamisesta on muutakin hyötyä: Jos otat muun kuin itse tekemäsi DLL:n käyttöön esim. Delphissä etkä ole 100% varma kutsutavasta (calling convention) niin assemblerkoodilla voit varmistaa, että funktiosi edes palaa oikeaan paikkaan ( että pino siivotaan oikein funktiokutsun jälkeen ).
kutsutavan määritystä varten Delphi tuntee ainakin nämä lisämääreet:
register;
stdcall;
cdecl;
safecall;
ja ainakin Kylix3 myös lisämääreen varargs; (tämä on sitä varten, että voi kutsua .so :sta (vastaa linuxissa windowsin DLL:iä) myös niitä C-funktioita, joissa on vaihteleva argumenttimäärä.- pythonpuhkihahahfads
C:ssä kylläkin käytetään yleensä, varsinkin ring-0 drivereita, jotka ajavat samalla privilege-levelillä kuin järjestelmä, joten kaikki resurssit käytössä..
- opetteleohjelmoimaan
mitäs sinulle sanoo (EE) EAX, ja coren numero samalla numerolla kun 128-bittistä levydeltään koodia
?
- JokuJoskusOhjelmoinu
Osaavissa kasissa:
Ohjelman suorituksen nopeutta voi parantaa. Ohjelman koko saadaan pienemmaksi. Laitelaheisen koodin kirjoittaminen monessa tilanteessa ei vaan onnistu C tai muillakaan kielilla. Virheiden etsinnassa "oikean" koodin tunteminen on monesti avain virheen nopeaan loytymiseen. Ohjelmien krakkays... - jamppa pohjoisesta
C-kääntäjillä on omat sääntönsä siinä, miten ne generoivat konekielistä koodia, esimerkiksi rekisterien käytön suhteen. En muista nähneeni ainoankaan C-kääntäjän dokumentaatiossa sanaakaan siitä, että voisi ohjeista kääntäjää juurikaan sen suhteen, että miten rekistereitä pitäisi käyttää. "register" deklaraatiolla saa ehkä sen pistämään jonkun muuttujan rekisteriin, mutta sekään ei ole varmaa, vaan yleensä kääntäjä pitää tuota vain suosituksena (näin google mulle joskus kertoi).
Jos siis esimerkiksi olet kirjoittamassa Forth-tulkkia C:llä, niin on turha unelmoida siitä, että saisit C-kääntäjän generoimaan Forth-tyylistä kahta rekisteripohjaista pinoa käyttävää konekielistä koodia. C ei yksinkertaisesti vain osaa käyttää kuin vain yhtä pinoa automaattisesti. Toisen pinon käyttöön onnistuisi esimerkiksi niin, että manuaalisesti loisit globaalin muuttujan, jossa pointteri ja yrittäisit saada kääntäjän pitämään sen aina rekisterissä. Makroassemblyllä kahta erillistä pinoa käyttävän koodin generointi on lapsenleikkiä. - AikaWanhaWirtuoosi
Assemblyllä tuli 1981 kirjoitettua taloushallinnon softatkin.
Tuohon aikaan muisti oli kallista ja vähissä kaikissa koneissa.
Koodauskieli on nykyään makuasia, kunhan hommat toimii. Asm on joustavampi kuin C koska asm -kielessä kaikki tehdään alkutekijöistä. Käytännössä tällä on merkitystä varsin harvoissa ja poikkeuksellisissa tapauksissa.
C on varsin käyttäjäystävällinen kieli: vähän tekstiä ja paljon asiaa selkeässä muodossa kun taas asm on päinvastainen tapaus.
Asm on jäänyt vähälle käytölle ohjelmoinnin hitauden vuoksi.
Kaikki mikä on tehty C-kielellä voidaan toki tehdä myös asmilla - teoriassa. Makrojen ja aliohjelmien käyttö toki lisää isohkojen asm-ohjelmien hallittavuutta ja ylläpidettävyyttä kunhan ne ovat kunnolla kapseloituja. Asm-kielellä on tehty mm. 64 kilotavun kokoinen "graaffinen" käyttöjärjestelmä jolla pääsee nettiin.
Käännetyn ohjelmatiedoston koko riippuu suuresti käyttöjärjestelmästä ja tiedostomuodosta. DOS:in com-tiedostot sisältävät pelkän ohjelman käännettynä kun taas monissa muissa tapauksissa kääntäjä lisää mukaan pitkän pätkän muuta tavaraa.- saaollakovakääntäjä
En ole noin hyvää kääntäjää kyllä vielä nähnyt:
Ohjelmoijan taitoonhan tämä kulminoituu aina että on aina jokaisessa koodin tilanteessa kyseisen prosessorin cache-linjojen tilat miten niitä voi kuormittaa, missäkin tilanteessa. L1 ja L2 cachet ja nopeudet pitää olla tiedossa kun kirjoitat ohjelmaa.
Aika kovia kääntäjiä on, ainakaan mikään microsoftin uusin visual studio ei vielä tuota osaa, mutta jos itselläsi on parempi, siitä en tiedä.
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Heikki Silvennoinen petti vaimoaan vuosien ajan
Viiden lapsen isä Heikki kehuu kirjassaan kuinka paljon on pettänyt vaimoaan vuosien varrella.1833228Miksi ihmeessä nainen seurustelit kanssani joskus
Olin ruma silloin ja nykyisin vielä rumempi En voi kuin miettiä että miksi Olitko vain rikki edellisestä suhteesta ja ha242141- 242061
Persut nimittivät kummeli-hahmon valtiosihteeriksi!
Persujen riveistä löytyi taas uusi törkyturpa valtiosihteeriksi! Jutun perusteella järjenjuoksu on kuin sketsihahmolla.901915Onko ministeri Juuso epäkelpo ministerin tehtäviensä hoitamiseen?
Eikö hänellä ole kompetenttia hoitaa sosiaali- ja terveysministetin toimialalle kuuluvia ministerin tehtäviä?701588Sakarjan kirjan 6. luku
Jolla korva on, se kuulkoon. Sain profetian 22.4.2023. Sen sisältö oli seuraava: Suomeen tulee nälänhätä niin, että se241351- 81251
Avaa sydämesi mulle
❤ ❤❤ Tahdon pelkkää hyvää sulle Sillä ilmeisesti puhumalla Avoimesti välillämme Kaikki taas selviää Kerro kaikki, tahdo361247Elia tulee vielä
Johannes Kastaja oli Elia, mutta Jeesus sanoi, että Elia tulee vielä. Malakian kirjan profetia Eliasta toteutuu kokonaan351207Nellietä Emmaa ja Amandaa stressaa
Ukkii minnuu Emmaa ja Amandaa stressaa ihan sikana joten voidaanko me koko kolmikko hypätä ukin kainaloon ja syleilyyn k61198