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