1. Onko normaalia toimintaa GNU assemblerilta, että vain .o -tiedostoon menee oikea data, ja .lst -tiedostoon tulee väärää dataa ?
Esim. kun on hyppykäsky tai funktiokutsukäsky (jmp, call, rjmp, rcall), niin käskyn ns. opkoodi on oikein, mutta kohdeosoite on .lst -tiedostossa aina sama, eli jos on 2 eri funktiokutsua, niin .lst -tiedostossa molemmille näkyy sama kohdeosoite, ja relatiivisilla kutsutavoilla kohdeosoite ei ole sama, mutta etäisyys kutsusta kohteeseen on sama (taitaa olla aina 0).
Entä, miten on linkkrin (ld ?) laita ?
JOS gas on saanut .lst -tiedostoon väärän kohdeosoitteen, niin korjautuuko tuo esim. .bin tai .hex -tiedostoon oikeaksi, vai jääkö vääräksi ?
Yritän siis tässä kysellä sitä, että muodostavatko gas ja ld siinä mielessä yhden kokonaisuuden, että .lst -tiedosto ei gas:n tapauksessa ole edes tarkoitus olla absoluuttisesti oikea, vaan vasta linkkeri (ld) korjaa kohdeosoitteet oikeaksi, vai jääkö vääräksi kokonaan ?
Tässä on kyse AVR -mikrokontrollerille kääntävästä (gas) ja linkkaavasta (ld) ohjelmasta - mutta käsittääkseni toimintaperiaatteet ovat gas ja ld osalta samat x86 -versiossa ja AVR -crosscompiler -versiossa. Cross siinä mielessä, että vaikka käännetään AVR:lle, niin kääntäminen tapahtuu Windows -PC:ssä.
Voisi (gas, ld) tietysti teoriassa olla 64 -bittinenkin ohjelma, mutta tästä ei ole käytännössä mitään hyötyä - kun AVR:n muisti lasketaan kilotavuissa, niin 32 -bittisen ohjelman kokorajoituksella ei ole mitään merkitystä.
Vaihtoehto toki olisi käyttää jotain muuta assembleria, siis sellaista, joka osaa itse luoda intel hex -formaattia olevan tiedoston AVR:lle siirtoa varten, jolloin erillistä linkkausvaihetta ei tarvita lainkaan. Mutta gas:n kanssa tarvitaan.
Assemblerin vaihto toiseen vain tässä tarkoittaisi sitä, että joutuisin itse koodaamaan apuohjelman, joka muuntaa gas -syntaksia esim. AVRA:lle sopivaksi.
Esim. kun on hyppykäsky tai funktiokutsukäsky (jmp, call, rjmp, rcall), niin käskyn ns. opkoodi on oikein, mutta kohdeosoite on .lst -tiedostossa aina sama, eli jos on 2 eri funktiokutsua, niin .lst -tiedostossa molemmille näkyy sama kohdeosoite, ja relatiivisilla kutsutavoilla kohdeosoite ei ole sama, mutta etäisyys kutsusta kohteeseen on sama (taitaa olla aina 0).
Entä, miten on linkkrin (ld ?) laita ?
JOS gas on saanut .lst -tiedostoon väärän kohdeosoitteen, niin korjautuuko tuo esim. .bin tai .hex -tiedostoon oikeaksi, vai jääkö vääräksi ?
Yritän siis tässä kysellä sitä, että muodostavatko gas ja ld siinä mielessä yhden kokonaisuuden, että .lst -tiedosto ei gas:n tapauksessa ole edes tarkoitus olla absoluuttisesti oikea, vaan vasta linkkeri (ld) korjaa kohdeosoitteet oikeaksi, vai jääkö vääräksi kokonaan ?
Tässä on kyse AVR -mikrokontrollerille kääntävästä (gas) ja linkkaavasta (ld) ohjelmasta - mutta käsittääkseni toimintaperiaatteet ovat gas ja ld osalta samat x86 -versiossa ja AVR -crosscompiler -versiossa. Cross siinä mielessä, että vaikka käännetään AVR:lle, niin kääntäminen tapahtuu Windows -PC:ssä.
Voisi (gas, ld) tietysti teoriassa olla 64 -bittinenkin ohjelma, mutta tästä ei ole käytännössä mitään hyötyä - kun AVR:n muisti lasketaan kilotavuissa, niin 32 -bittisen ohjelman kokorajoituksella ei ole mitään merkitystä.
Vaihtoehto toki olisi käyttää jotain muuta assembleria, siis sellaista, joka osaa itse luoda intel hex -formaattia olevan tiedoston AVR:lle siirtoa varten, jolloin erillistä linkkausvaihetta ei tarvita lainkaan. Mutta gas:n kanssa tarvitaan.
Assemblerin vaihto toiseen vain tässä tarkoittaisi sitä, että joutuisin itse koodaamaan apuohjelman, joka muuntaa gas -syntaksia esim. AVRA:lle sopivaksi.
Vastaukset 2
Vanhimmat
Saattaa tulla vähän myöhässä vastaus, mutta vastaanpa silti. En ole tarkkaan tutustunut juuri tuohon kuvailemaasi tapaukseen, mutta totta tosiaan linkkeri on osa käännösvaiheiden kokonaisuutta. Se on ensimmäinen apuohjelma, joka käsittelee ohjelmaa yhtenä kokonaisuutena.
Linkkerin tehtävä on sijoitella eri osiot suoritustiedoston imageen (elikkä erilliset muistiavaruudet yhdistyvät yhteen loogiseen avaruuteen), josta syystä tietysti muistiosoitteita sisältävät käskyt pitää käydä korjaamassa, mikä on toinen tehtävä linkkerille. Objektitiedostothan eivät tiedä toisistaan mitään eivätkä tiedä minne ne tullaan sijoittamaan valmiissa suoritustiedostossa. Niissä pitäisi kyllä olla jonkunlainen tietorakenne osoitteista, mitä pitää linkkerin käydä korjaamassa. Lisäksi kolmantena linkkerin tehtävänä olisi löytää ulkoiset symbolit (muuttujat, funktiot esim.), joita ei löydy samasta objektitiedostosta vaan muista linkkerille samassa yhteydessä syötetyistä objektitiedostoista. Näistäkin pitäisi olla joku tietorakenne objektitiedostossa, missä luetellaan omat symbolit ja tavara joka pitäisi löytyä muualta.
Tarkka toimintatapa toki riippuu tietokonearkkitehtuurista ja muista sovituista käytänteistä.
kaikissa muissa assemblereissa EI OLE noin hölmösti!
Esim Turbo Assembler tuottaa sekä .obj että .lst -tiedostoon juuri sitä mitä pitääkin.
Siinä käytetään ORG -ohjauslausetta (jos ei käytetä, se on oletuksena sama kuin ORG 0).
Toki linkkeri voi muuttaa osoitteita jos useita .obj -tiedostoja linkataan yhdeksi kokonaisuudeksi.
Mutta: vaikka joku ei haluaisi käyttää linkkeriä vaan jostain syystä haluaisi tehdä homman manuaalisesti, voisi kullekin .asm -tiedostolle laittaa oman ORG -lauseensa niin, ettei mikään osoite mene päällekkäin - tällöin manuaalisesti yhdistämällä koodia jopa .lst -tiedostosta periaatteessa saisi toimivan ohjelman (jos koodi muuten on kirjoitettu oikein).
huom: tuossa kyllä pitäisi tarkistaa että antaa oikeat komentorivioptiot! .lst tiedosto ei ole alunperin tarkoitettu "manuaaliseen linkkaamiseen" - eli JOS sitä silti siihen käyttää - pitäisi varmistaa että optiot on siten, että .lst -tiedostoon tulee jokainen generoitu tavu eikä mitään jätetä pois esim. liian pitkän rivin takia.
No, Turbo Assembler onkin paremmin tehty kuin gas. mutta valitettavasti Turbo Assembler on vain x86 -Assembler - eli AVR:stä se ei mitään ymmärrä.
mitä kaikkia vaihtoehtoja muuten on AVR:n ohjelmointiin?
gavrasm on sekin 1 - tosin se tuottaa suoraan .hex - se ei osaa tuottaa .o tai .obj -tiedostoja - jos on yhden modulin ohjelma - tuo voi olla jopa etu - mutta monen modulin ohjelmissa tuo on iso haitta - kun ei osata tuottaa .obj --- miten saat kokonaisuuteen yhdistettyä useita moduleja?