Merkkien määrä (hello.asm)

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."

Näin näyttää olevan, testasin toistamalla tuon tulostamisen kahdesti, ja peräkkäinhän ne meni, jollei tuota yhtä ylimääräistä siihen lisännyt.

%include "io.inc"

section .text
global CMAIN
CMAIN:
mov ebp, esp; for correct debugging
mov edx, 13
mov ecx, msg
mov ebx, 1
mov eax, 4
int 80h
mov eax, 4
int 80h
xor eax, eax
ret

SECTION .data
msg db 'Hello World!', 0Ah

Tuossa uudelleen saman tulostamiseen, riitti kun alusti int 80h kutsun write tehtävälle (mov eax, 4). Jos olisi käyttänyt mov edx, 12, olisivat tekstit menneet peräkkäin.

Anonyymi kirjoitti:

"Jos tarkoitus on myös tulostaa lopussa oleva 0Ah eli rivinvaihto, niin minusta pituuden tulisi tässä olla 30 eikä 29."

Näin näyttää olevan, testasin toistamalla tuon tulostamisen kahdesti, ja peräkkäinhän ne meni, jollei tuota yhtä ylimääräistä siihen lisännyt.

%include "io.inc"

section .text
global CMAIN
CMAIN:
mov ebp, esp; for correct debugging
mov edx, 13
mov ecx, msg
mov ebx, 1
mov eax, 4
int 80h
mov eax, 4
int 80h
xor eax, eax
ret

SECTION .data
msg db 'Hello World!', 0Ah

Tuossa uudelleen saman tulostamiseen, riitti kun alusti int 80h kutsun write tehtävälle (mov eax, 4). Jos olisi käyttänyt mov edx, 12, olisivat tekstit menneet peräkkäin.

Lue lisää

Tuohon dynaamisuutta lisäämällä .dataan msg:n alapuolelle muuttuja pituus:
pituus equ $ - msg

Ja sitten korvaa aikaisemman mov edx:n:
mov edx, pituus

Anonyymi kirjoitti:

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.

%include "/usr/share/sasm/include/io.inc"
section .text
global CMAIN
CMAIN:
mov ebp, esp
mov edx, len
mov ecx, msg
mov ebx, 1
mov eax, 4
int 80h
xor eax, eax
ret

SECTION .data
msg db 'Hello World!', 0Ah
len equ $ - msg

Tässä tämä paranneltu versio, joka toimii hienosti, mutta en saa sitä käännettyä komentotulkissa. Tällä SASM -editorillaan se kyllä kääntyy virheettömästi.

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 ???

-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ä