Miksi SASM assembler esimerkki koodissa EDX -rekisteriin sijoitetaan 29, vaikka tulostettava merkkijono on vain 25 merkkiä pitkä.
%include "io.inc"
section .text
global CMAIN
CMAIN:
mov ebp, esp; for correct debugging
mov edx, 29
mov ecx, msg
mov ebx, 1
mov eax, 4
int 80h
xor eax, eax
ret
SECTION .data
msg db 'Hello World! Minä täällä.', 0Ah
%include "io.inc"
section .text
global CMAIN
CMAIN:
mov ebp, esp; for correct debugging
mov edx, 29
mov ecx, msg
mov ebx, 1
mov eax, 4
int 80h
xor eax, eax
ret
SECTION .data
msg db 'Hello World! Minä täällä.', 0Ah
Vastaukset 13
Vanhimmat
En tiedä mitä merkistöä tässä käytetään, mutta esimerkiksi UTF-8:ssa merkki 'ä' vie kaksi tavua.
Jos tässä esimerkissä 'ä' vie kaksi tavua niin merkkijonon pituus on 25 4=29 tavua koska 'ä' kirjaimia on neljä ja loput ovat perus ASCII kirjaimia jotka vievät vain yhden tavun jokainen.
Jos tarkoitus on myös tulostaa lopussa oleva 0Ah eli rivinvaihto, niin minusta pituuden tulisi tässä olla 30 eikä 29.
No voi herran pieksut, siinähän se oli, kiitän.
"Jos+tarkoitus+on+myös+tulostaa+lopussa+oleva+0Ah+eli+rivinvaihto,+niin+minusta+pituuden+tulisi+tässä+olla+30+eikä+29."
Tuohon dynaamisuutta lisäämällä .dataan msg:n alapuolelle muuttuja pituus:
pituus equ $ - msg
Ja sitten korvaa aikaisemman mov edx:n:
mov edx, pituus
Joo,+tuo+tekee+vaihtelevan+pituisten+merkkijonojen+käsittelyn+helpommaksi.
JOS kyse on linux -käyttöjärjestelmästä (mitä aloittaja ei viitsinyt mainita, vaikka se on olennainen tieto !), niin malaire (23.10.2020) on oikeassa.
Windowsissa taas asia EI OLE näin.
Linuxissa oletusmerkkikoodaus on UTF-8 (tosin hyvin vanhoissa linuxeissa, kuten Debian Sarge, näin ei ole, vaan niissä se voi olla esim. ISO-8859-1, joka on Windows-1252:n osajoukko).
Windowsissa tilanne on monimutkaisempi:
Graafisissa sovelluksissa oletusmerkkikoodaus on Windows-1252 (USA:ssa, Suomessa, ja monessa muussakin Euroopan maassa). Toki esim. Venäjällä ja Thaimaassa oletusmerkkikoodaus on maan oman standardin mukainen, ja nuo maakohtaiset standardit on yleensä laadittu siten, että koodit 0..127 ovat samat kuin jenkki-ASCIIssa, ja koodit 128..255 ovat maan paikallisen kielen kirjoitusmerkkejä.
Toki Graafisissa sovelluksissa voi vaihtoehtoisesti käyttää UTF16LE -koodattua UNICODEa, jos käyttää aina W -loppuisia API -kutsuja A-loppuisten sijasta. Huomaa, että tässä tapauksessa BMP:hen (Basic Multilingual Page) kuuluvat merkit koodataan yhdellä enkoodausyksiköllä eli 16 bitillä, muut merkit kahdella enkoodausyksiköllä eli yhteensä 32 bitillä.
Windowsin komentorivisovelluksissa oletus on yleensä OEM-850 (voi olla myös OEM-437, riippuen COUNTRY -asetuksesta). Tämä on ilmeisesti MS-DOSin peruja ja on sieltä tullut käytännöksi myös windowsiin.
em. syistä Windowsissa on siis Graafisissa sovelluksissa ja komentorivisovelluksissa eri koodaustapa, jenkki-ASCIIn osalta ovat samoja, mutta jos ei koodata oikein, niin suomalainen käyttäjä huomaa väärän koodauksen siitä, että Ä ja Ö -kirjaimet korvautuvat roskalla.
malaireon oikeassa.
koodissa oleva int80h viittaa linuxiin.
Windowsissahan käytetään DLL:ä, ja ms-dosissa vastaava oli int 21h.
Nyky -linuxeissa oletuskoodaus on tosiaankin UTF-8 -enkoodattu unicode.
Vai onko?
Onkohan edes linux kernelissä homma koodattu oikein ?
Kun linuxin eräissä muissa kirjastoissa (olisiko libiconv ?) tai joku muu vastaava, liittyy eri merkkikoodausten väliseen konvertointiin, niin siellä on ollut jo vuosia vakava bugi, eikä tekijöitä pätkääkään kiinnosta korjata huonoa ja väärin toimivaa koodiaan.
Kyse siis siitä, että unicode consortiumin mukaan on vain 1 ainoa UTF-8 -koodaus, eikä ole olemassa mitään vaihtoehtoista UTF-8 koodaustapaa.
Mutta linuxin eräs tunnetuimmista kirjastoista koskien merkkikoodausmuunnoksia on jo vuosia toiminut väärin !
Eli KUN on kyse BMP:n (Basic Multilingual page) ulkopuolisista merkeistä, eli U+10000 koodista eteenpäin (ei siis koske koodeja U+0000 - U+ FFFF), niin nuo kaikki, aina U+10FFFF saakka, kuuluu koodata UTF-8 koodauksella enintään 4:llä tavulla!
Mutta tämä linuxin pellekirjasto enkoodaa ne 6 tavulla, koodaamalla UTF-16 -esitysmuodon HIGH ja LOW -surrogaten kummankin erikseen 3-tavuisella UTF-8 esityksellä, eli 1 merkki = yhteensä 6 tavuinen sekopää-utf-8 -enkoodattu esitys. Ja tämä on unicode consortiumin sääntöjen vastaista.
Saavatkohan ikinä korjattua ???
Nämäpä olivatkin hankalia kääntää komentokehotteesta käsin. Pitkän rupeaman hain ohjetta, löytämättä sellaista, joka olisi virheettömästi käännöksen tehnyt.
Assembler on tietokoneen ohjelmointikieli, jonka opettelusta ei ole mitään hyötyä.
-kääntäjän virheellisen toiminnan selvittäminen vaatii toisinaan assembler-taitoja
-core dumpista voi nähdä, jos virheen on aiheuttanut esim. muistin virheily eikä kyseessä ole ohjelmointivirhe
-koodin optimointien ymmärtäminen vaatii assembler-taitoja sulautetuissa, esim. koodin voi joutua optimoimaan kääntäjäparametrilla, mutta rikkinäisen kääntäjän/alustan rajoitteiden tai uutuuden takia käännöksen assembleriin on tehtävä käsin muutoksia, jotta koodi toimisi tai käyttäisi kääntäjästä puuttuvaa - vielä tehokkaampaa mnemonic:ia.
-sanoisin, että monet selviävät ilman assemblerin opettelua, mutta ilman assembleria ei pysty rakentamaan esim. toimivia kääntäjiä
-assemblerin opettelusta on se hyöty, että voi alkaa ymmärtää, miksi korkeamman tason kielissä jotkin asiat toimivat hitaasti väärin toteutettuina ja miksi kääntäjäoptimoinnit voivat rikkoa koodia mm. sulautetuissa ja muodostuva assembler pitää toisinaan tietää.
-ja syitä on paljon muitakin, mm. debuggerit usein näyttää koodisekvenssit ja usein se auttaa hahmottamaan koodin toiminnan ts. miksi koodi on virheellistä
itseasiassa voisin heittää koodin pätkää on Star Generator 3.0.
Olen paloillanin en hati löäytäyt tuo tku 534983
joudutte tyytymään johonkin itren moduuleihin eli siis Pythön tai joku muukin pelkle
Sorry
https://www.cs.virginia.edu/~evans/cs216/guides/vsasm.html
helppo joku opeyud jossa ei mennä sitten mihinkääö grtagiikkakiihdyttimeni muistin lukitsemiseneeen jen.
oikeasti ovat device-driver-ohjelmoijia jotka käyttävät, eli boot-koodi normia jne..
Mitä haluasit tehdä assembyllä oikeasti sitten vaikka piirtää kirjaimia ruudulleP?=