Avataanpa keskustelu aiheesta. Toisessa ketjussa totesin että

Toisaalta PIC-asm on primitiivisen arkkitehtuurinsa takia niin älyttömän vaikea kokonaisuus (ei pinoa, hankala rekisterien pankitushässäkkä eikä varsinaisesti RAMiakaan) ihmisen hallittavaksi vähänkään mutkikkaammassa softassa, toisin kuin C:n kanssa jossa kääntäjä huolehtii näistä perusasioista ja aikaa jää tuottavampaan koodailuun.

Täsmennetään vielä että tarkoitan pinolla sellaista yleiskäyttöistä pinoa jota voidaan osoittaa epäsuoralla muistiosoituksella. Tuo pinon puute aiheuttaa em. PICeissä sen, ettei ohjelmakoodi ole re-entranttia, eli samaa funktiota ei voi kutsua pääohjelmasta samaan aikaan kuin keskeytyksestä, tai käyttää rekursiivisia funktioita.

Itse olen henkilökohtaisesti koodaillut takavuosina ehkä luokkaa 10-20 erilaista enemmän tai vähemmän laajaa sovellusta asmilla piceille ja joka kerta kiroillut tuota arkkitehtuurin alkeellisuutta sekä sitä että siinä jää mahdollisuus ampua itseään jalkaan niin helposti verrattuna vaikkapa M68k-ASMiin (jolla tuli aikanaan tehtyä yhtä sun toista Amiga-aikoina) joka on suorastaan kaunista ortogonaalisine käskykantoineen. Niinkin yksinkertainen perusoperaatio kuin kahden 16-bittisen etumerkillisen luvun vertailu (>, <, >=, <=) keskenään on PIC-asmilla ihan hetken pähkäilyn vaativa juttu (C:llä triviaalia, no 18F picissä vähän helpompaa). Samoin rekisterien käytöstä kirjanpito eri funktioiden välillä on ihan tuskaa kun ei voi tehdä paikallista pinokehystä, joten joutuu venyttämään mielikuvitusta niiden nimeämisessä vähän liiankin kanssa ja tulee käytettyä "varmuuden vuoksi" eri rekistereitä. Ja jos johonkin väliin lisää jotain tai vaihtaa suoritusjärjestystä niin sillä voi olla arvaamattomia sivuvaikutuksia josta seuraa hankalasti löydettäviä bugeja. Sitten vielä kun itse varsinkin haluaisin että ohjelmakoodi itsessään on niin selkeää ettei siihen tarvitse kirjoittaa mitään romaania kommenteiksi. Poislukien yleinen algoritmin selvennys yms. jos tarvitaan.

Vaikka em. kokemusten karkoittamana olenkin siirtynyt käyttämään kehittyneempiä prossuja (lähinnä MSP430 ja ARM) niin nyt kuitenkin hiljattain innostuin kokeilemaan minkälaista jälkeä Hi-Tech C:llä saa tuolle mainitulle 16F-PICille. Vaikuttaa siltä että generoitu koodi on ihan kelvollista, eikä käsin koodaukseen nähden tule juurikaan takkiin. Etuja sen sijaan on aika runsaasti, kuten se, ettei pankituksen tai sivutuksen kanssa tarvitse lainkaan pähkäillä kun kääntäjä hoitaa asian. Tietenkin arkkitehtuurin primitiivisyydestä seuraa joitain rajoitteita mutta ei mitään dramaattista. Sittenkin kääntäjä varoittaa asiasta.

Näin ollen tulee mieleen kysyä että onko kellään olemassa mitään hyvää perustelua sille, miksi kukaan käyttäisi C:n sijasta puhdasta asmia koko sovelluksen koodaukseen, mainituilla PICeilä tai muillakaan prossuilla? Joskus kun sovelluksen koko kasvaa niin kaipaisi jopa C++:n ominaisuuksia. Tietenkin jos jossain kohti tarvitaan suorittaa aivan tietty konekoodisekvenssi niin C:n sekaan voi laittaa inline-assembleria mutta tähänkään en ole havainnut olevan tarvetta juurikaan.

Ainut mieleen tuleva järkevä perustelu on se, että laadukkaasta C-kääntäjästä noille pienemmille PICeille joutuu maksamaan rahaa. SDCC:tä en ole tosin kokeillut. Kehittyneemmillä arkkitehtuureilla (esim. MSP430, ARMit, AVR jne) C:n käyttö on aivan itsestäänselvää. Samoin reilun 10-vuotisen työurani aikana yhdessä suomen suurimmista sulautettujan suunnittelupalveluja tarjoavista yrityksistä en ole nähnyt kenenkään koodaavan mitään asmilla ainakaan työkseen (toisaalta en tiedä kuin 2 projektia joissa on käytetty piccejä ja olen nähnyt niitä "monta").

Tietenkin assemblerin tuntemus ylipäätään on hyödyllistä jos pitää arvoida onko kääntäjän tuottama koodi järkevää.

t. Janne

jahonen kirjoitti:Näin ollen tulee mieleen kysyä että onko kellään olemassa mitään hyvää perustelua sille, miksi kukaan käyttäisi C:n sijasta puhdasta asmia koko sovelluksen koodaukseen

No ekana tulee mieleen, ettei osaa käyttää C kieltä. Ja hirveen huonosti tuntuu enää näin vanhana päähän tarttuvankaan. Pitäis varmaan yrittää uudestaan.

Kääntäjien hintahan se monella on varmaankin esteenä, tosin nykyään ilmaisversiotkin on jo todella päteviä.
Enpä kyllä mitään fiksua syytä keksi, itsekin suurimman osan teen nykyään ceellä. Männävuosina tuli taas käytettyä asmia, koska vielä joku viitisen vuotta sitten picille saatavat c-kääntäjät olivat todella huonoja imo, tekivät todella paljon tilaa vievää koodia ja ongelmatkaan kääntäjien kanssa eivät olleet mitenkään harvinaisia.

Se on kyllä totta, että jos pic-asmin kirjoitus on vaikeaa, niin jonkun muun kirjoittaman asmin lukeminen on vielä vaikeampaa.

Joo, itselläkin oli suht kauan rimakauhua tuohon C:n käyttöön sulautettujen kanssa, vaikkakin PC-ympäristöstä syntaksi ja rakenteet olivatkin kyllä tuttuja. Joskus 2005 sitten kokeilin MSPGCC-kääntäjää MSP430:lle ja lyhyillä esimerkeillä pääsin siitä suht äkkiä jyvälle. Näin jälkeenpäin voi sanoa että tuo vaivannäkö kyllä kannatti ja ne aikaisemmat asm-ohjelmointikokemukset nykyään lähinnä puistattaa En tiedä sitten onko tuo miten paljon muistamiskysymys, kun C-kieli on sanastoltaan varmaan yksi suppeimpia ohjelmointikieliä, poislukien kirjastofunktiot ja niiden nimet (jotka eivät sinänsä kuulu kieleen). Eri asia jossain VHDL:ssä jossa tarinaa pitää kirjoittaa huomattavasti enemmän. Ohjelmoijan hyvyys on kyllä kaikkea muuta kuin sitä että miten hyvin jonkun kielen syntaksin muistaa.

En välttämättä ihmettele tuota kääntäjien huonoutta/bugisuutta kun nuo 8-bittiset picit eivät ole mitenkään helppo alusta tehdä toimivaa C-kääntäjää.

C-ohjelmien porttaus prossujen välilläkin on parhaimmillaan helppoa, samat tietotyypit ja syntaksi toimii. Siinä missä picin C:ssä sanoo että PORTB = 0xA5; niin MSP430:ssä se onkin P2OUT = 0xA5;

Tietenkin oheislaitteet ja keskeytykset ovat kovastikin erilaisia mutta jos on kerran opetellut C:n yhdellä prossulla niin toinenkaan ei useimmiten ole kovin vaikea. Lähinnä oheislaitteiden alustukset ja joskus ARMien kanssa kellotussysteemin (PLL etc.) alustus aiheuttaa päänvaivaa, mutta siihenkin löytyy useimmiten esimerkkejä josta voi ottaa mallia.

t. Janne

jahonen kirjoitti:onko kellään olemassa mitään hyvää perustelua sille, miksi kukaan käyttäisi C:n sijasta puhdasta asmia koko sovelluksen koodaukseen

Riippuu siitä, mitä on tekemässä. Esimerkiksi tässä sovelluksessa on hyvät perusteet käyttää pelkkää asmia: http://www.youtube.com/watch?v=sNCqrylNY-0

JKN kirjoitti:

jahonen kirjoitti:onko kellään olemassa mitään hyvää perustelua sille, miksi kukaan käyttäisi C:n sijasta puhdasta asmia koko sovelluksen koodaukseen

Riippuu siitä, mitä on tekemässä. Esimerkiksi tässä sovelluksessa on hyvät perusteet käyttää pelkkää asmia: http://www.youtube.com/watch?v=sNCqrylNY-0

Jep, mutta tuossakaan ei ollutkaan käytetty PIC-asmia vaan AVR-asmia joka on hivenen inhimillisempää Tuon kaltainen demokoodailu on varmaan ainuita sovelluksia joissa siitä on hyötyä. C64:ssä ainakin kun kuvan piirron ja prosessorin kellotaajuudella on hyvinkin kiinteä yhteys, joka vaakajuovalle on 64 kellojaksoa mutta joka 8. vaakajuovalla videopiiri vie niistä enemmän. Olkoonkin että helpompiakin tapoja generoida kuva on olemassa. Lähinnä tässä hain tavanomaisia ei-aikakriittisiä sovelluksia joita varmasti suurin osa on.

t. Janne

Olet jahonen ilmeisesti paljon käyttänyt tuota MSP430-kontrolleria, mitä sanoisit sen eduiksi verrattuna esim. samantasoisiin picceihin taikka atmelin vastaaviin? Olen huomannut että noita käytetään melko paljon nykyään. Tilasin itselleni rannekellon missä on tuo, mutten ole saanut vielä aikaiseksi kokeilla sen ohjelmointia.
Kyseinen kello on siis ihan MSP430:n kehitysalustaksi tarkoitettukin...

L18 kirjoitti:Olet jahonen ilmeisesti paljon käyttänyt tuota MSP430-kontrolleria, mitä sanoisit sen eduiksi verrattuna esim. samantasoisiin picceihin taikka atmelin vastaaviin? Olen huomannut että noita käytetään melko paljon nykyään. Tilasin itselleni rannekellon missä on tuo, mutten ole saanut vielä aikaiseksi kokeilla sen ohjelmointia.
Kyseinen kello on siis ihan MSP430:n kehitysalustaksi tarkoitettukin...

Piceistä pitäisi varmaan verrata 24F:iin, joista ei kyllä ole kokemusta. Pikaiseen katsottuna näyttävät kyllä aika samankaltaisilta kuin dsPICit, joista on hivenen kokemusta. Mutta MSP430:tä PIC16F:ään nähden etuna on kyllä kehittyneemmät oheislaitteet ja arkkitehtuuri yleensä. Kunnollinen vapaa C-kääntäjä löytyy myös (MSPGCC). Samoin MSP:ssä on monissa 12-bittinen ADC joka ei ole kovin tavanomaista. Oheislaitteiden kellotusta saa myös MSP:ssä säädettyä aika joustavasti.

t. Janne

jahonen kirjoitti:

JKN kirjoitti:

jahonen kirjoitti:onko kellään olemassa mitään hyvää perustelua sille, miksi kukaan käyttäisi C:n sijasta puhdasta asmia koko sovelluksen koodaukseen

Riippuu siitä, mitä on tekemässä. Esimerkiksi tässä sovelluksessa on hyvät perusteet käyttää pelkkää asmia: http://www.youtube.com/watch?v=sNCqrylNY-0

Jep, mutta tuossakaan ei ollutkaan käytetty PIC-asmia vaan AVR-asmia joka on hivenen inhimillisempää Tuon kaltainen demokoodailu on varmaan ainuita sovelluksia joissa siitä on hyötyä.

t. Janne

Jaa sanot että AVR-asm on hivenen inhimillisempää kuin PIC-asm? Ainakin mun mielestä noilla on eroa melkein yhtä paljon kuin yöllä ja päivällä. AVR-assembleria vielä koodailee lähes mielellään jos on pakko mutta nykyään en enää PIC-assembleriin varmaan koskisi pitkällä tikullakaan, sen verran harmaita hiuksia se aikanaan aiheutti. Tupakkaa meni paljon, muutama olutkin siinä ohessa ja lukuisia kirosanoja lenteli ilmassa kun joskus vuosituhannen vaihteessa erästä PIC-projektia assemblerilla koodailin ja välillä tuntui ettei vikaa löydy mistään mutta kun jonkun asian teki toisella tavalla niin homma yhtäkkiä lähtikin toimimaan (mutta joku muu juttu samalla meni rikki). Saman projektin koodaisin nykyään varmaan parissa-kolmessa tunnissa AVR-assemblerilla ihan näin kylmiltäänkin vaikka viimeksi AVR-asmiakin on tullut kirjoitettua ehkä puolitoista vuotta sitten (ja sama sujuisi varmaan reilussa puolessa tunnissa AVR C:llä).

Tosin, on ne kääntäjät, työkalut sun muutkin kokemuksen ohella vuosien varrella kehittyneet mutta silti tuo AVR-asm on vaan monta kertaa helpompaa koodattavaa kuin PICin vastaava. Mutta harvemmin nykyään tarvitsee suoraan assembleria koodata ellei ole ihan pakko olla varma ohjelman toiminnasta kellojakson tarkkuudella, C:llä saa monin verroin pienemmällä vaivalla saman asian tehtyä ja kääntäjätkin tekevät käytännössä lähes yhtä hyvää työtä kuin käsin asmin kirjoittamalla.

Itseasiassa olen koodaillut softaa AVR:lle jopa BASICilla ja Pascalilla, molemmille kun löytyy ilmaiset kääntäjät. Tosin noissa ilmaisissa kääntäjissä taisi olla jotain rajoituksia. Nuo vaan olivat tapauksia joissa oli valmis toimiva ohjelma PC:lle ja se piti saada käännettyä AVR:lle joten saman kielen käyttö oli nopein ja helpoin tapa.

No ehkä tuo "hivenen" on vähän lievä ilmaus mutta kuitenkin. AVR:llä ei ole koskaan tullut tehtyä mitään, vaikka kerran olikin aika lähellä. Työni piirissä C käsitetään matalan tason kieleksi, mitä se kyllä on, monet rakenteet toteuttavat aika suoraan tietyn konekielisen käskyn. Sinänsä huvittavaa että VHDL mikä käsitetään yleensä ihan täysin rautakuvauskieleksi jolla tehdään pelkkää logiikkaa tai vaikka prosessorikin, on usein helpommin hallittavaa kuin monet assembler-murteet.

Ideana oli sanoa että korkeamman tason kielillä pääsee monesti huomattavasti helpommalla kun vehkeissä on vähän pelivaraa. Eli ei ole väliä miten iso osa käytettävissä olevista resursseista (muistitila ja suoritusaika) on käytetty kunhan ne vaan ylipäätään riittävät. Suoritusaika on monesti sopimuskysymys.

Esimerkiksi jos vaikka jonkun PID-säädön suoritusväliaika on luokkaa sekunti niin ihan sama onko siinä PID-säädön laskennassa käytetty liukulukuja vaiko jotain viilattua kiinteän pilkun aritmetiikkaa (skaalattuja kokonaislukuja). Samoin jos ohjelmakooditila ja suoritusaika antaa myöten niin ihan sama käyttää sitä (s)printf()-funktiota tulostuksen muotoiluun, pääsee maaliin helpommalla. Kuka ikinä on käyttänyt noita skaalattuja kokonaislukuja voinee vahvistaa asian, ettei niiden kanssa pelaaminen ole aina kovinkaan miellyttävää varsinkin jos systeemin "dynamiikka" on suuri.

t. Janne

StiNgeR kirjoitti:...kääntäjätkin tekevät käytännössä lähes yhtä hyvää työtä kuin käsin asmin kirjoittamalla.

Tuota en kyllä ihan allekirjoita. Minulla on paha tapa lueskella kääntäjän tuottamia assembly-listauksia, ja siellä on välillä sellaista lusikalla ojan kaivamista, että ei tiedä, pitäisikö itkeä vai nauraa. Omien kokemusten mukaan open source -työkalut ja kalliit kaupalliset kääntäjät eivät tässä suhteessa niin hirveästi eroa toisistaan, vaikka myyntimiehet toista väittääkin.

Mutta totta on, että nykyään pienissäkin kontrollereissa löytyy sen verran puhtia, että ei tuosta useimmissa tapauksissa tarvitse välittää. Jää se silti harmittamaan, ihan periaatteessa.