Onko mikro-ohjelmointi kuollut?

[Jere Sumell]

Katselin tuossa hakukoneella "Microprogramming language 2021" ja "Microprogramming languages 2020" -hakutermeillä, niin ei oikein löytynyt mitään. Käytin Google-hakua noihin.

Lähinnä tuli arkistoista 1973/1980 -luvulta tieteellisiä dokumentteja, ja eräässä koulutushakusivustolla "Best Computer Science Graduates" -sivustolla oli artikkeli, että nykyisin hyvin pitkälle ohjelmointi suoritetaan korkeamman tason kehitetyillä ohjelmointikielillä.

Miten on, ohjelmoidaanko enää käytännössä konekielellä mitään muualla, paitsi tiedeyhteisöissä ehkä, jos poissuljetaan esimerkiksi korkeamman tason kielet, joilla päästään lähemmäksi rautatasoa.

[kamara]

Miten on, ohjelmoidaanko enää käytännössä konekielellä mitään muualla, paitsi tiedeyhteisöissä ehkä, jos poissuljetaan esimerkiksi korkeamman tason kielet, joilla päästään lähemmäksi rautatasoa.

Veikkaisin, että aina uuden tyyppiselle prosessorille ohjelmoidaan konekielellä C-kääntäjä.

Sen jälkeen tuskin halutaan koskea pitkällä tikullakaan Assembleriin.

(Tämä toki on hivenen kärjistäen ilmaistu.)

[_Pete_]

demo-scenessä erittäin ahkerasti.

[Tomin]

Joissain suorituskykykriittisissä paikoissa käytetään assemblyä. Esimerkkinä nyt vaikka x264. Yleisesti optimoivat kääntäjät tekevät riittävän hyvää työtä, joten vähemmän on tarvetta kirjoittaa omia optimointeja symboIisella konekielellä. 

[Jere Sumell]

Miten on, ohjelmoidaanko enää käytännössä konekielellä mitään muualla, paitsi tiedeyhteisöissä ehkä, jos poissuljetaan esimerkiksi korkeamman tason kielet, joilla päästään lähemmäksi rautatasoa.

Veikkaisin, että aina uuden tyyppiselle prosessorille ohjelmoidaan konekielellä C-kääntäjä.

Sen jälkeen tuskin halutaan koskea pitkällä tikullakaan Assembleriin.

(Tämä toki on hivenen kärjistäen ilmaistu.)

Miettinyt tuota, että kun sähkölaitevalmistajan tehtaalla juotetaan ROMmiin konekielistä ohjelmaa, täytyy tehtaalla olla palkattuna joku konekieleltä isännöivä ja hallitseva ohjelmoija, hyvällä palkkauksella, oletukseni.

En sitten tiedä, kun moni esimerkiksi puhelinvalmistaja, ja tietokonevalmistaja, ja muiden sähkölaitteiden valmistajat kokoonpanevat ainoastaan ulkopuolisten alihankkijoiden raaka-aine varastoon toimittamia komponentteja ja ohjelmistoja, niin jos nyt ajatellaan älylaitteen anatomiaa, niin tulee mieleen juuri prosessori, näytönohjain, syöttölaite, tulostuslaite lähinnä rautapuolelta. Nokialla sentään oli 90-luvun lopulla alihankintaverkostokin aika laajasti ainakin monta Suomessa melkein kiinni tehtaassa Salossa fyysisesti sijaiten niistä komponenttivalmistajista ja toimittajista.

Intel, AMD nyt tulee tuosta prosessorista mieleen, siellä on muutama sälli varmaan tekemässä mielettömän hyvää tiliä tuon konekielisen koodauksen parissa. Suomessa ei ole kertaakaan tullut vastaan konekielen ohjelmoijan työpaikka-ilmoitusta. Joskus katsonut Inteliltä työpaikkoja ja yleensä Yhdysvalloista, niin siellä on aika paljonkin ilmoituksissa haetaan konekielen taitajia.

Ei tuo kääntäjän algoritmikään mikään kovin monimutkainen ole, ja C-kieli nyt on hyvä esimerkki, mille kielelle se kääntäjä kannattaa toteuttaa ensimmäisenä.

[Tomin]

Miten on, ohjelmoidaanko enää käytännössä konekielellä mitään muualla, paitsi tiedeyhteisöissä ehkä, jos poissuljetaan esimerkiksi korkeamman tason kielet, joilla päästään lähemmäksi rautatasoa.

Veikkaisin, että aina uuden tyyppiselle prosessorille ohjelmoidaan konekielellä C-kääntäjä.

Tuo taitaa kyllä nykyään mennä niin, että ensin kirjoitetaan ristiinkääntäjä jollekin yleisemmin käytössä olevalle prosessorille (yleensä x86_64) ja sitten tarvittaessa käännetään kääntäjä sille uudelle suorittimelle. Tämäkin oli toki yksinkertaistus.

Linuxissakin on muuten jonkin verran assemblya, vaikka sitäkin on viime vuosin pyritty vähentämään aina kun mahdollista. Sitä tarvitaan kai lähinnä käynnistyksessä ja kaikkein matalimman tason juttuihin. Käynnistyslataajista sitä varmaan edelleen löytyy, vaikka voisin kuvitella, että UEFIn tulo on vähentänyt sitä sielläkin.

Miettinyt tuota, että kun sähkölaitevalmistajan tehtaalla juotetaan ROMmiin konekielistä ohjelmaa, täytyy tehtaalla olla palkattuna joku konekieleltä isännöivä ja hallitseva ohjelmoija, hyvällä palkkauksella, oletukseni.

Ei niitä romiin juotella, eikä nykyään käytetä juurikaan romeja. Flash-piirille kirjoitetaan ihan gcc:llä (tai muulla yleisellä kääntäjällä) ristiinkäännetty binääri, jonka lähdekoodi voi olla vaikka C-kielinen.

[Jere Sumell]

Suljin jo koneen, ja tulin takaisin muuttamaan tuon ROMmiin juottamisen "ROMmiin polttamisen" -ilmaisuun, mutta hienoa moderaattori "Tomin", että olet ajan tasalla pitämässä keskustelua!

Tosiaan, on väärin todeta ROMmiin juotettavan jotain. Read Only Memoryyn poltetaan piirilevyyn tai piiriin kiinni konekielellä ohjelmoitu ohjelma valmistajan tehtaalla, autotallissa, tai mikä tuotantolaitos onkaan kyseessä.

[nm]

Kyllä konekielitason koodia kirjoitetaan edelleen käsin myös sovellusohjelmiin, jos on tarvetta puristaa tehokkuudesta ja suorituskyvystä viimeisetkin löysät pois. Näin on mm. videodekoodereissa ja enkoodereissa, pakkausohjelmissa, kuvan- ja äänenkäsittelysuotimissa ja mahdollisesti joissain pelimoottorien silmukoissa. Käytännössä koodi liittyy yleensä rinnakkaiseen vektorilaskentaan prosessorien SIMD-käskykantaa hyödyntäen. Se ei edelleenkään onnistu kovin hyvin kääntäjien automaattisilla optimoinneilla. Vastaavasti näytönohjaimille kirjoitetaan matalan tason laskentarutiineja erilaisilla GPGPU-kirjastoilla (CUDA, OpenCL) sekä grafiikkarajapintojen shadereilla. Niissä ei tosin mennä ihan konekielitasolle asti, vaan syntaksi on geneerisempää, ja välissä on kääntäjän tekemä muunnos.

Joskus koodi kirjoitetaan C/C++-kääntäjän tukemilla intrinsiceillä, ja joskus suoraan symbolisella konekielellä. Tässä muutama esimerkki:

https://github.com/videolan/x265/tree/master/source/common/x86
https://github.com/AOMediaCodec/SVT-AV1/tree/master/Source/Lib/Encoder/ASM_AVX2
https://github.com/minio/sha256-simd

Agner Fogin oppaat ovat mainioita lähteitä matalan tason optimointiin konekielellä ja C/C++:lla x86-arkkitehtuurin osalta: https://www.agner.org/optimize/

Mobiililaitteet, erilaiset sulautetut järjestelmät ja mikrokontrollerit ovat sitten omia alueitaan, joihin tehdään myös paljon matalan tason koodia.

[Jere Sumell]

"Tomin", kun mainitsit GCC -C-kääntäjän, niin onko sinulla tai jollain muulla tietoa, onko se noista avoimen lähdekoodin C-kääntäjistä muistin osalta kustannustehokkain? Entä verrattuna kaupallisiin C-kääntäjiin, jos jollakulla niistä on kokemusta?

Uskoisin, mitä C-kieli ollut olemassa 1970-luvulta lähtien, että joku olisi konekieltä taitava ohjelmoinut ehkä jopa avoimen ja vapaan kääntäjän, missä käytännössä muistin ja resurssien varaaminen ja muistin käyttö siitä olisi otettu maksimit irti.

C-kääntäjästä, kun tuli tässä ketjussa juttua, Googletin "Open Source C Compiler", niin eräällä sivulla oli listattuna 2021 -vuoden jonkinlainen TOP - 8 -lista, niin siinäkin oli gcc -ykköstilalla.

[nm]

"Tomin", kun mainitsin GCC -C-kääntäjän, niin onko sinulla tai jollain muulla tietoa, onko se noista avoimen lähdekoodin C-kääntäjistä muistin osalta kustannustehokkain? Entä verrattuna kaupallisiin C-kääntäjiin, jos jollakulla niistä on kokemusta?

Tarkoitatko muistinkulutusta kääntämisen aikana vai käännetyn sovelluksen muistinkäyttöä? Kääntämisen aikana kääntäjän muistinkäyttö riippuu pitkälti käännettävästä koodipohjasta ja valituista optimoinneista, joten sitä on hankala verrata. Harvemmin se myöskään muodostuu ongelmaksi, ellei kyseessä ole jokin erityisen kiero templaattipohjainen C++-koodi. Kääntämisen nopeus on yleisempi vertailukohde, mutta sekin riippuu samoista tekijöistä.

Käännetyn sovelluksen muistinkäyttö puolestaan riippuu sovelluksen omasta koodista ja standardikirjastosta, eikä kääntäjä juurikaan vaikuta siihen.

Entä verrattuna kaupallisiin C-kääntäjiin, jos jollakulla niistä on kokemusta?

Clang/LLVM ja GCC ovat pitkälti syrjäyttäneet kaupalliset C/C++-kääntäjät x86-alustalla. Microsoftin Visual C++ vielä sinnittelee Windows-sovellusten kääntämisessä, mutta on pudonnut kelkasta optimointien osalta. Prosessorivalmistajilla on omat optimoivat kääntäjänsä: Intel C++ ja AMD:llä AOCC (joka perustuu LLVM:ään).

Uskoisin, mitä C-kieli ollut olemassa 1970-luvulta lähtien, että joku olisi konekieltä taitava ohjelmoinut ehkä jopa avoimen ja vapaan kääntäjän, missä käytännössä muistin ja resurssien varaaminen ja muistin käyttö siitä olisi otettu maksimit irti.

Tuo on enemmän sellaisten ohjelmointikielten aluetta, joissa muistinhallinta perustuu roskienkeruuseen tai vastaaviin monimutkaisempiin mekanismeihin. C/C++:ssa muistin ja resurssien varaaminen on koodaajan käsissä.

[Jere Sumell]

Joo, kokemusta on Windows 3.0 ja Windows 3.1 mikrokivikaudelta blue screeneistä, ja yksiajo-järjestelmä Mikkiksen Disk Operating Systemsin kaatumisesta, kun Bill Gates tajusi ohjelmoida käyttöjärjestelmän, ja teki lisenssointibisnekset IBM the Evil Guys -tietokonevalmistajan kanssa.

Toi muistin hallinta on juuri yksi niistä asioista itsekin C-ohjelmointiin perehtyneenä, mikä tekee eron taitavan, tai masterbrain C/C++-ohjelmoijan ja vähemmän hyvän ohjelmoijan välillä, jotka sisältävät kaikki niiden ohjelmoijien joukot, joiden sovellukset joko toimivat, toimivat paremmin, tai kaatuvat aika ajoin.

Onhan se noissa roskienkeruu-prosessin omaavissa kielissä jotain tekemistä koodaajalla sen muistin käytön suhteen, joskaan ei niin kriittistä, että ohjelma kaatuisi. Esimerkiksi jos ohjelmoi Javalla, mainitsen nyt Javan, kun siitä on eniten kokemusta koulutuksen osalta, ja siinähän on tuo Garbage Colletor -mekanismi, jota Javan Virtuaalikone ajaa taustalla, niin jos ohjelmoi jotain sellaista ohjelmaa, missä attribuuttina määriteltynä ja alustettuna esimerkiksi kokonaisluku-taulukko, johon tallennetaan kansalaisen ikä ja kengännumero, ja alustusvaiheessa jos varaa taulukolle enemmän tilaa, kuin tuon kahden alkion verran. niin koodaaja minimoidessaan alustusvaiheessa muistinvarauksen, jos ohjelma on laaja, ohjelma voi toimia joissain tapauksissa sujuvammin kun ei ole muistia tuhlailtu, tai roskienkeruu ei tee 100% suoritusajasta taustaprosessina aktiivisesti töitä, vaikka se siellä 100% ajasta onkin käynnissä.

En muista, onko C# -kielessä Garbage Collector, mutta tosiaan, kun "nm" -mainitsit, C ja C++ muistin käyttö on tosiaan ohjelmoijan harteilla, ja sitten helposti laajoissa kokonaisuuksissa voi saada päänsäryn, tai pahimmassa tapauksessa ohjelma kaatuu. On niitä Amerikassa avaruuslentojakin, joihin on investoitu kymmeniä miljardeja, kaatunut ohjelmistovirheen takia alkumetreillä.

[Jere Sumell]

Tuo on enemmän sellaisten ohjelmointikielten aluetta, joissa muistinhallinta perustuu roskienkeruuseen tai vastaaviin monimutkaisempiin mekanismeihin. C/C++:ssa muistin ja resurssien varaaminen on koodaajan käsissä.

Tuosta roskien keruusta tuli mieleen kysymys, jonka kysyin Google-haulta, että onko kaikissa nyky-aikaisissa korkean-tason ohjelmointikielissä Garbage Collector, niin selvisi, että C ja C++ -kieleenkin saa ulkoisen kirjaston kautta tuon roskienkeruu ominaisuuden. Itselläni tosin ei ole niistä kokemusta, ja kun ottaa uutta kieltä haltuun, koulutusmielessä on järkevämpää olla käyttämättä niitä, että mahdollisesti tulee kantapään kautta muistin resurssointiongelmat vastaan, tosin muussa koodausmielessä saattaa olla järkeä.

Et C/C++ -ulkoisista GC -kirjastoista  omaa, "nm", kokemusta? Miten tehokkaita ne mahtaa olla.

Lähteeni
https://www.freecodecamp.org/news/a-guide-to-garbage-collection-in-programming/

[nm]

Et C/C++ -ulkoisista GC -kirjastoista  omaa, "nm", kokemusta? Miten tehokkaita ne mahtaa olla.

Minulla ei ole niistä kokemusta, mutta ilmeisesti Chromium/Blink -pohjaisissa selaimissa on tuollainen toteutus laajamittaisessa käytössä:

https://v8.dev/blog/high-performance-cpp-gc
https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/platform/heap/BlinkGCAPIReference.md

[Jere Sumell]

palaan vielä tähän aiheeseen, kun oli lukukauden viimeisimmässä lopputentissä aineopintokurssilla esseevastauksessa nostin esiin tuon prosessorin valmistajan tehtaalla poltetun mikro-ohjelmoidun kääntäjän tai tulkin esille, kun vastauksessa etsittiin kääntäjän ja tulkin toimintaperiaatteita.

Nokian 90-luvun lopun Salon tehtaat tulikin jo mainituksi aiemmin insinoorin tyopaikkana, mutta onko tällä palstalla tietoa, miten nyt kun Varsinais Suomessa Turun näkovinkkelistä suuri tyollistaja on Uudenkaupungin autotehdas, valmistaako se sähkoautoja, ja voisi kuvitella että jos valmistaa, niin Uudenkaupungin autotehtaalla olisi myos matalamman tason ohjelmia hallitseville mikro-ohjelmoijille kysyntää, vai olenko väärässä.

Sattuuko joku palstalainen muuten olemaan autotehtaalla toissa Uudessa Kaupungissa, niin ainakin osaisi vastata.

[JaniAlander]

Yksi tuttuni on Uudessakaupungissa töissä. Ne tekee kokoonpanoa siellä, ts. käytännössä kaikki osat tulevat valmiina, ja niistä kasataan auto. Ts. veikkaanpa ettei matalan tason ohjelmoijalle ole siellä kysyntää.

[qwertyy]

...voisi kuvitella että jos valmistaa, niin Uudenkaupungin autotehtaalla olisi myos matalamman tason ohjelmia hallitseville mikro-ohjelmoijille kysyntää, vai olenko väärässä.

En nyt mitenkään varmaksi sano, mutta kyllä nuo hommat keskittyy varmaan lähinnä Bosch:n yms. komponenttitoimittajien ja räätälöijien juttuihin, sekä suoraan valmistajien päämajoihin. Eli kyseinen putiikki varmaankin tekee puhtaasti kokoonpanohommia kuten Jani mainitsi. Automaatioinsinööreille siellä lähes varmasti olisi paljonkin hommia. Eli robottiohjelmointia yms. siellä lähes varmasti tehdään paljonkin.

BRP voisi ehkä olla sellainen firma, jossa ehkä voisi olla kyseisen tyyppistä ohjelmointia? Tosin villi veikkaus, että heillekin tulee ns. valmiit alustat, jotka räätälöidään omiin tarpeisiin tai teetättävät hommat jo aiemmin toimitusketjussa. En osaa sanoa. Piti mielenkiinnosta vilkaista, niin diagnostiikkatyökaluissa harvinaisemmin vaikuttaisi olevan kielenä myös suomi, mikä ei kovin yleistä kyllä ole kyseisissä työkaluissa.

Off-topicina tuli mieleen, että olisi mielenkiintoinen tietää miten "uusi" ja RMK (=Verge) hoitaa sähkö- ja ohjelmapuolen suunnittelua prätkäänsä.

[AimoE]

Sellainen mielukuva minulle ji kun olin jossain vaiheessa Nokialla töissä, että kännyn tekoon tarvittiin tuhansia sw-inssejä, satoja mekaniikkainssejä, muutaman kymmentä asic-ohjelmoijaa ja vielä vähemmän hw-inssejä. Minulle ei kylläkään ollut näkyvyyttä alihankkijoiden työntekijämääriin, joten käsitys voi olla vinoutunut.

Evoluutio kumminkin on sellainen että arkeeinen, yksisoluinen elämä selviää DNA:lla jossa on lähes pelkästään "oikeita" geenejä, eli niitä jotka koodaavat jotain proetiinia. Monisoluisilla eliöillä näiden proteiinia koodaavien DNA-jaksojen määrä vähenee ja vähenee mitä midemmälle eliöt kehittyvät tai siis muuntuvat, mikä nyt sitten lienee oikea termi. Tosin suhdeluku vaihtelee aika paljon. Ihmisellä on hyvin pieni osa DNA:sta niitä "oikeita" geenejä. Tekisi mieli sanoa häviävän pieni.

[JaniAlander]

Sellainen mielukuva minulle ji kun olin jossain vaiheessa Nokialla töissä, että kännyn tekoon tarvittiin tuhansia sw-inssejä, satoja mekaniikkainssejä, muutaman kymmentä asic-ohjelmoijaa ja vielä vähemmän hw-inssejä. Minulle ei kylläkään ollut näkyvyyttä alihankkijoiden työntekijämääriin, joten käsitys voi olla vinoutunut.

Evoluutio kumminkin on sellainen että arkeeinen, yksisoluinen elämä selviää DNA:lla jossa on lähes pelkästään "oikeita" geenejä, eli niitä jotka koodaavat jotain proetiinia. Monisoluisilla eliöillä näiden proteiinia koodaavien DNA-jaksojen määrä vähenee ja vähenee mitä midemmälle eliöt kehittyvät tai siis muuntuvat, mikä nyt sitten lienee oikea termi. Tosin suhdeluku vaihtelee aika paljon. Ihmisellä on hyvin pieni osa DNA:sta niitä "oikeita" geenejä. Tekisi mieli sanoa häviävän pieni.

Ehkä "hiukan" aiheen ohi, vaikka ohjelmakoodiahan se dna:kin on. Ymmärtääkseni nykykäsitys on, että sillä proteiineja suoraan koodaamattomalla DNA:lla on jotain tekemistä prosessin ohjauksen kanssa. Ts. joka solulla on sinänsä sama dna-koodi, mutta jokin määrää sen, mistä solusta tulee vaikkapa lihassolu, mistä vaikkapa maksan solu, ja mistä esim. aivosolu, ja se "jokin" on todennäköisesti siellä proteiineja koodaamattomassa osassa. Mitä monimutkaisempi otus, sen enemmän tälläista ohjausta tarvitaan. Sitten päälle tulee vielä kaikenlaista ryönää, esim. vanhoja viruksen jämiä jne. (Viruksen geenien kantilta tämähän on lottovoitto, geenit pääsevät periytymään automaattisesti, ilman että tarvitaan mitään erityistä levitysmekanismia...)

[AimoE]

Ehkä "hiukan" aiheen ohi, vaikka ohjelmakoodiahan se dna:kin on.

Eihän tässä ohjelmakoodista ollut puhe vaan softan ja kovon suhteesta. Ja sitähän sinä itsekin tässä kuvailet, vai mitä?

[JaniAlander]

Ehkä "hiukan" aiheen ohi, vaikka ohjelmakoodiahan se dna:kin on.

Eihän tässä ohjelmakoodista ollut puhe vaan softan ja kovon suhteesta. Ja sitähän sinä itsekin tässä kuvailet, vai mitä?

Ei siinä mitään, kiinnostava aihehan tuo on.