Opetetaanko Assemblya vielä kouluissa tai joissain päin maailmaa
Vieläkö voi hakeutua kursseille jossa opetetaan Assemblyä? Ainakaan Viopessa, Edx, Mooc, eikä ensi vilkaisulla suomen missään koulussa kursseja ollut.
Katsopa jotain 8-bittisiä ympäristöjä, kuten AVR tai PIC prosessoreille. Nuo ovat niin tehottomia C:llä, että monesti tarvitsee sitä assembleria käyttää. Yleensä se tehdään kääntämällä "gcc -c foo.c -o foo.o" asemesta "gcc -S foo.c -o foo.s", jolloin saadaan sen C-koodin ekvivalentti assembler näkyville. Sitä voi sitten muokata. Yleensä muokkaus tehdään inline-assemblerina, koska assembleria halutaan joka tapauksessa koodin sekaan mahdollisimman vähän sen huonon luettavuuden vuoksi. Usein mikrokontrolleri-kursseilla on mahdollista tehdä HW tai SW näkökanta asiaan, jolloin tuo "HW" käytännössä tarkoittaa kolvailua JA assembleria..
Ylläpito on poistanut tästä viestin sääntöjen vastaisena.
Ei taideta opettaa vaikka pitäisi. Perustelen kantaani teknologiayrittäjänä, ja totean, että ASM on hyvin tehokasta koodia ja antaa etua ainakin aika- ja tilakriittisissä sovellutuksissa.
Itse kirjoitetun koodin luettavuus on hyvä - vai mitä sanot tästä:
start
bsf STATUS,PA0 ; selects page 1
movlw b'00110000' ; output GP4,5, input GP0-3 (gp3)
tris GPIO
flash
movlw B'010000'
movwf GPIO
Call delay
movlw B'100000'
movwf GPIO
Call delay
goto flash
delay
clrf dtime ; delay subroutine, 2 ms
loopx
goto $ 1 ; 2c
goto $ 1 ; 2c
decfsz dtime ; 1c, decrement counter
goto loopx ; 2c, back to top of loop
retlw 0x00 ; 2c
END ; directive 'end of program'
Itse kirjoitetun koodin luettavuus on hyvä - vai mitä sanot tästä:
start
bsf STATUS,PA0 ; selects page 1
movlw b'00110000' ; output GP4,5, input GP0-3 (gp3)
tris GPIO
flash
movlw B'010000'
movwf GPIO
Call delay
movlw B'100000'
movwf GPIO
Call delay
goto flash
delay
clrf dtime ; delay subroutine, 2 ms
loopx
goto $ 1 ; 2c
goto $ 1 ; 2c
decfsz dtime ; 1c, decrement counter
goto loopx ; 2c, back to top of loop
retlw 0x00 ; 2c
END ; directive 'end of program'
9 VASTAUSTA:
... ja S24 tuhosi formaatin, eli kannattaa katsoa esimerkkiä jostain muualta...
Assemblerissa on se huono puoli että se on jokaiselle prossuarkkitehtuurille erilainen, en tiedä onko kovin hirveesti (mutua)? Vähä olis hankala kun opiskelisit ensin C-kieltä x86-prossulle ja ARM:lle koodatessa pitäisi opiskella uusi A-kieli ja koodi on huonosti siirrettävissä.
Miksi koodin pitäisi olla siirrettävissä?
Järkevämpää on tehdä tehokasta koodia kuin miettiä miten sen saisi siirrettyä toiseen arkkitehtuuriin.
Järkevämpää on tehdä tehokasta koodia kuin miettiä miten sen saisi siirrettyä toiseen arkkitehtuuriin.
Nimenomaan, koodin suoritusaika, resurssitehokkuus ja toimivuus ovat tärkeämpiä tekijöitä. Se että saa kuraa helposti ei ole minkään arvoista.
Ilman että konteksti on tiedossa on tuo rotla täysin lukukelvotonta. Kontekstin kanssa siitä ehkä pystyisi arvaamaan mitä se yrittää tehdä.
99,999 % tapauksista ei "tehokkuudella" tai "resurssien käytöllä" ole minkään valtakunnan merkitystä, ja niissä jäljelle jääneissä 0,001 % on 99 % kyse siitä, että yritetään (joko pakosta tai huonon suunnittelun vuoksi) tehdä väärillä vehkeillä paskasta konvehtia.
99,999 % tapauksista ei "tehokkuudella" tai "resurssien käytöllä" ole minkään valtakunnan merkitystä, ja niissä jäljelle jääneissä 0,001 % on 99 % kyse siitä, että yritetään (joko pakosta tai huonon suunnittelun vuoksi) tehdä väärillä vehkeillä paskasta konvehtia.
"Perustelen kantaani teknologiayrittäjänä, ja totean, että ASM on hyvin tehokasta koodia ja antaa etua ainakin aika- ja tilakriittisissä sovellutuksissa."
Laitahan vähän esimerkkiä sellaisesta aika- ja tilakriittisestä sovelluksesta.
Jotta saisi vähän perspektiiviä asioihin niin 15€:lla saa jokun quad core tehomyllyn gigan muistilla.
Laitahan vähän esimerkkiä sellaisesta aika- ja tilakriittisestä sovelluksesta.
Jotta saisi vähän perspektiiviä asioihin niin 15€:lla saa jokun quad core tehomyllyn gigan muistilla.
mc68020 kirjoitti: Miksi koodin pitäisi olla siirrettävissä?
Järkevämpää on tehdä tehokasta koodia kuin miettiä miten sen saisi siirrettyä toiseen arkkitehtuuriin.
Koska arkkitehtuurit vaihtuvat vähän väliä mikä on milloinkin järkevää. Se on turhaa työtä tehdä arkkitehtuurista riippuvaista koodia jos sen voi mitenkään välttää kun ne arkkitehtuuririippuvaiset jutut joutuu sitten tekemään uudestaan.
teknologiayrittäjä kirjoitti: Nimenomaan, koodin suoritusaika, resurssitehokkuus ja toimivuus ovat tärkeämpiä tekijöitä. Se että saa kuraa helposti ei ole minkään arvoista.
"Nimenomaan, koodin suoritusaika, resurssitehokkuus ja toimivuus ovat tärkeämpiä tekijöitä. Se että saa kuraa helposti ei ole minkään arvoista."
Suoritusaika on sama vaikka tekisi C:llä koska kääntäjät optimoivat kunnolla ja jos siellä joku kellojakso menisikin laskentaan enemmän niin silläkään ei ole merkitystä suoritusajassa, koska CPU:n cachet ovat niin isoja, että niissä kuitenkin odotetaan muistihakuja. Nopeus on siis täysin sama.
Toimivuus todennäköisesti on huonompi assemberilla hinkatessa koska riski bugeille kasvaa.
Suoritusaika on sama vaikka tekisi C:llä koska kääntäjät optimoivat kunnolla ja jos siellä joku kellojakso menisikin laskentaan enemmän niin silläkään ei ole merkitystä suoritusajassa, koska CPU:n cachet ovat niin isoja, että niissä kuitenkin odotetaan muistihakuja. Nopeus on siis täysin sama.
Toimivuus todennäköisesti on huonompi assemberilla hinkatessa koska riski bugeille kasvaa.
retlw_0x00 kirjoitti: ... ja S24 tuhosi formaatin, eli kannattaa katsoa esimerkkiä jostain muualta...
Tee sisennys s i t o v i l l a välilyönneillä.
Joskus nuo optimoinnit on todella ikäviä, esim. jotkut prosessorit vaatii bittitason operaatioita yhteen rekisteriin alustaessaan tiettyä tilaa tietyssä sekvenssissä - jos kääntäjä optimoi tämän yhdeksi muistivienniksi, homma ei pelaa. Tietysti se on HW:ltä huonoa toimintaa, mutta niin paljon helpompi korjata softaan. Toki nuo optimoinnit saa pois päältä, mutta kääntäjän version muuttuessa pragmat muuttuu - ja yllättäen optimoinnit voi olla taas käännöksen jälkeen päällä - vaikka toisin näyttäisi olevan! Tästä syystä assembler voi olla järkevä vaihtoehto.
Parannamme palvelua
