Macho-ohjelmoijat, rumpumuisti ja rikostekninen analyysi 1960-luvun konekoodista

Todelliset ohjelmoijat eivät käytä PASCALia

Ohjelmoijat rakentavat tänään hajautettuja sovelluksia ja keinotekoisia hermoverkkoja. He käyttävät toiminnallista reaktiivista ohjelmointia, avoimen lähdekoodin verkkokehyksiä ja palvelimettomia ympäristöjä. Petturi-oireyhtymä on kuitenkin todellinen, ja ohjelmoijat kritisoivat toisiaan siitä, etteivät he ole "todellisia ohjelmoijia".

Työskentelin dosenttina Tietokonehistoriamuseossa vuosia. "Todellisen ohjelmoijan" tropiikki on ollut olemassa ohjelmiston alusta lähtien. Ja voin todistaa sen tarinalla.

Tarina alkaa Ed Postin vuonna 1983 kirjoittamalla kirjeellä Real Programmers Don't Use PASCAL. Kirje julkaistiin Datamation-lehdessä, ja siinä käsiteltiin ohjelmoinnin “macho” -puolta. Se vaati niitä, jotka halveksivat korkeamman tason kielenkäyttäjiä, eivät "todellisina ohjelmoijina".

The Story of Mel on online-vastaus kirjeeseen. Ed Nather lähetti sen Usenetiin 21. toukokuuta 1983.

Mel ja Ed olivat kollegoja kirjoituskoneyrityksessä, joka oli haarautunut tietokoneiden rakentamiseen. Heidän menestystarina oli LGP-30: rumpumuistitietokone, jossa oli Flexowriter-näppäimistö ja paperinauhalukija. (Tämän artikkelin otsikkokuva on LGP-30: n kojelauta.) Mel sai tehtävän kirjoittaa uudestaan ​​suosittu ohjelma seuraajatietokoneelle, RPC-4000.

Satama? Mitä tuo tarkoittaa?

Kun Mel lähti yrityksestä, Ed sai tehtävän kirjoittaa osa tästä ohjelmasta. Tarinasta hän löytää koodista loputon silmukka, joka jotenkin ei estä ohjelmaa toimimasta:

Ehkä suurin järkytys tuli, kun löysin viattoman silmukan, jolla ei ollut testiä.

Ei testiä. Ei mitään.

Terve järki sanoi, että sen oli oltava suljettu silmukka, jossa ohjelma kiertää ikuisesti, loputtomasti.

Ohjelman hallinta kulkee kuitenkin suoraan sen läpi ja turvallisesti ulos toiselle puolelle.

Ed huomasi, että suljettu silmukka aiheutti ylivuotoa, joka kirjoitti komentokoodin uudestaan. Ylivuoton tulos oli hyppykäsky , joka siirtää ohjelman hallinnan eri muistipaikkaan.

Se on hieno tarina. Mutta tarkistaakö se?

Rikostekninen analyysi: Onko tarina tarkistettu?

Ensimmäinen askel on etsiä teknisiä yksityiskohtia koneesta, jolle ohjelma on kirjoitettu. Vaikka tarinassa mainitaan laajasti LGP-30, ohjelma oli todella käynnissä RPC-4000: lla. (Muista, että se oli kirjoitettava uudelleen tälle uudelle koneelle.)

Molemmat koneet käyttivät rumpumuistia ohjelmien tallentamiseen. (Hauska tosiasia: nykyaikaisen kiintolevyn karkea ekvivalentti oli rumpumuisti, paperinauha, perforaattikortit tai magneettinauha!) Yksi rivi sähkömagneettisia päätä lukisi / kirjoitti tietoja, kun rumpu pyöri tasaisella nopeudella niiden alla. Tässä on visuaalinen viite:

Tiedot tallennettiin ja haettiin rummun eri sektoreilta ja kappaleilta. Lisätietoja tietojen muodosta saat RPC-4000-ohjelmointioppaasta, jonka archive.org on skannannut ja säilyttänyt verkossa.

Käsikirjan sivulta 20 löytyy seuraava datasanakaavio:

Komentosana jakautuu:

  • 5 bittiä komennolle
  • 13 bittiä operandin raidan / sektorin sijainnille
  • 13 bittiä seuraavan komennon osoitteen raidalle / sektorille

Bitti 31 on hakemistotunniste, joka asetettuaan aktivoi hakemistorekisterin:

[Hakemistorekisteri] antoi ohjelmoijan kirjoittaa ohjelmasilmukan, joka käytti indeksoitua käskyä sisällä; joka kerta hakemistorekisterin numero lisättiin kyseisen käskyn osoitteeseen, joten se viittaa sarjan seuraavaan peruspisteeseen.

Tarinassa mainitaan, että "hakemistobitti" on " bitti, joka on osoitussanan osoitteen ja operaatiokoodin välissä ". Yllä oleva kaavio osoittaa kuitenkin, että hakemistotagibitti on tosiasiassa bitissä 31, ohi komennon ja osoitteet. Henkilökohtaisesti minä arvostan tätä siihen, että kirjoittaja muisti sen väärin vuosina, jolloin hän tarkasteli koodia ja kun tarina tallennettiin.

Onneksi tämä ei vaikuta tarinan ylivuotoon. Koska käskysanaa vedettiin muistiin ja sitä lisättiin, hakemistobitti olisi silti asetettava päälle , jotta lisäys ylittää seuraavan osoitteen .

Luodaksemme käskysanat uudelleen silmukkaan, meidän on tiedettävä enemmän ohjelman toiminnasta. Tässä on lainaus tarinan kriittisestä osasta:

Hän oli löytänyt työskentelemänsä tiedot muistin yläosasta -

suurimmat paikat, joihin ohjeet voisivat puuttua -

joten viimeisen peruspisteen käsittelyn jälkeen käskyosoitteen lisääminen tekisi siitä ylivuotoa.

Siirtäminen lisäisi yhden toimintakoodiin ja muuttaisi sen seuraavaan käskysarjassa: hyppykäsky.

Tosiaan, seuraava ohjelmaohje oli osoitepaikassa nolla, ja ohjelma meni onnellisella tavalla.

Hypoteettinen toteutus: "Näytä minulle palat!"

Tässä on potentiaalinen ohje, joka voi olla hyppykäsky viitattu tarina:

Voimme nähdä, että komentobitit ovat 10111 . Jos haaratoiminto on pois päältä, "seuraava ohje on Seuraava-osoite-kentässä määritetty ohje". Joten yksi hypoteettinen tilanne olisi, että ylivuoton jälkeen rekisteri (jossa käytetään putkia bittikenttien välisten erojen osoittamiseen) kuuluu:

10111 | 0000000 | 0000000 | 0

Ekstrapoloimalla takaisin, ennen kasvua ja ylivuotoa rekisteri olisi lukenut:

10110 | 1111111 | 1111111 | 1

Yksi mielenkiintoinen sivuvaikutus tämän toteutuksen suorittamisessa on, että käytetyllä ohjeella ei ole väliä. Jokainen RPC-4000: n käsky sisältää seuraavan käskyn osoitteen. Hakemistobitin ylivuoto seuraavaan osoitekenttään johtaa hyppäämiseen kyseiseen osoitteeseen komentobiteistä riippumatta.

Epilogi

Mel Kaye (kuvassa seisova, oikeassa reunassa) jatkoi työskentelyään ja lopulta jäi eläkkeelle. Anthony Cuozzo -fani ilmoitti vuonna 2014 yrittäneensä ottaa yhteyttä Meliin:

Pystyin lopulta ottamaan yhteyttä Meliin, mutta peloin hänet valitettavasti pois. Se on tarina toiselle päivälle ...: - / (lähde)

Kunnioittaen Melin yksityisyyttä, en lähetä mitään henkilökohtaisia ​​tietoja ja pidän kiinni ohjelmasta ja tarinasta. Jos joku tietää, mitä Mel ajattelee Internet-maineestaan, haluaisin kuulla sinusta.

En ole pitänyt yhteyttä Meliin, joten en tiedä, antaako hän koskaan periksi muutostulvalle, joka on huuhtonut ohjelmointitekniikat noista kauan menneistä päivistä lähtien. Haluan ajatella, että hän ei. - Ed Nather

Muut lähteet:

  • Wikipedian sivu Melin tarinasta
  • Melin käyttöohje RPC-4000 blackjack -peliin
  • Totuus ei koskaan pääse Jan Howard Brunvandin hyvään tarinaan

Dave työskentelee kehittäjäsuhteiden parissa IBM: llä. Jostain syystä IBM: llä ei ole SDC: tä RPC-4000: lle.