Macho-programmører, trommehukommelse og en retsmedicinsk analyse af maskinkoden fra 1960'erne

Ægte programmører bruger ikke PASCAL

Programmører bygger i dag distribuerede applikationer og kunstige neurale netværk. De bruger funktionel reaktiv programmering, open source web-rammer og serverløse miljøer. Alligevel er bedragersyndrom reelt, og programmører kritiserer stadig hinanden for ikke at være "rigtige programmører."

Jeg arbejdede som docent for Computer History Museum i årevis. Tropen af ​​en “rigtig programmør” har eksisteret siden starten af ​​software. Og jeg kan bevise det med en historie.

Historien starter med et brev fra 1983, Real Programmers Don't Use PASCAL, skrevet af Ed Post. Brevet blev offentliggjort i Datamation og diskuterede “macho” siden af ​​programmering. Det nålede dem, der skænker sprogbrugere på højere niveau som ikke "rigtige programmører."

Historien om Mel er et online svar på dette brev. Det blev sendt til Usenet den 21. maj 1983 af Ed Nather.

Mel og Ed var kolleger hos et skrivemaskinefirma, der havde forgrenet sig i at bygge computere. Deres breakout-succes var LGP-30: en trommehukommelsescomputer med et Flexowriter-tastatur og en papirbåndlæser. (Overskriftsbilledet i denne artikel er instrumentbrættet på en LGP-30.) Mel fik til opgave at omskrive et populært program til den efterfølgende computer, RPC-4000.

Havn? Hvad betyder det?

Efter at Mel forlod virksomheden, fik Ed til opgave at omskrive en del af dette program. I historien opdager han en uendelig løkke i koden, som på en eller anden måde ikke forhindrer programmet i at fungere:

Måske kom mit største chok, da jeg fandt en uskyldig løkke, der ikke havde nogen test i den.

Ingen test. Ingen.

Sund fornuft sagde, at det skulle være en lukket sløjfe, hvor programmet ville cirkulere for evigt, uendeligt.

Programkontrol gik dog igennem det og sikkert ud på den anden side.

Ed opdagede, at den lukkede sløjfe forårsagede et overløb, der omskrev instruktionskoden. Resultatet af overløbet var en springinstruktion , der flyttede kontrol over programmet til et andet hukommelsessted.

Det er en fantastisk historie. Men tjekker det ud?

Retsmedicinsk analyse: Kontrollerer historien?

Vores første skridt er at lede efter tekniske detaljer om den maskine, programmet blev skrevet til. Mens historien nævner omfattende LGP-30, kørte programmet faktisk på en RPC-4000. (Husk, det skulle skrives om til denne nye maskine.)

Begge maskiner brugte trommelhukommelse til programlagring. (Sjov kendsgerning: den grove ækvivalent af din moderne harddisk var tromlehukommelse, papirbånd, stansekort eller magnetbånd!) En enkelt linje af elektromagnetiske hoveder ville læse / skrive data, når tromlen drejes med en konstant hastighed under dem. Her er en visuel reference:

Data blev gemt og hentet fra de forskellige sektorer og spor på tromlen. For at finde ud af mere om formatet på dataene kan vi se RPC-4000 programmeringsmanualen, som archive.org har scannet og bevaret online.

På side 20 i manualen finder vi følgende dataorddiagram:

Kommandoordet opdeles i:

  • 5 bit til kommandoen
  • 13 bit til spor / sektor placering af operanden
  • 13 bits til sporet / sektoren for den næste kommandos adresse

Bit 31 er det indeksmærke, der, når det er indstillet, aktiverede indeksregistret:

[Indeksregisteret] tillod programmøren at skrive en programsløjfe, der brugte en indekseret instruktion indeni; hver gang igennem blev nummeret i indeksregistret føjet til adressen på denne instruktion, så det ville henvise til det næste henføringspunkt i en serie.

Historien nævner, at "indeksbit" er " den bit, der ligger mellem adressen og operationskoden i instruktionsordet ." Alligevel viser diagrammet ovenfor, at indeksmærkebiten faktisk er ved bit 31, forbi kommandoen og adresserne. Personligt kritiserer jeg dette op til misforståelse fra forfatteren i årene mellem da han gennemgik koden, og da historien blev indspillet.

Heldigvis påvirker dette ikke overløbsaspektet af historien. Siden instruktion ord blev trukket ind i hukommelsen og øges, vil indekset bit stadig nødt til at være indstillet , for at tilvækst til overflow Næste adresse .

For at genskabe instruktionsordene i sløjfen skal vi vide mere om, hvordan programmet fungerede. Her er et citat fra den kritiske del af historien:

Han havde fundet de data, han arbejdede med nær toppen af ​​hukommelsen -

de største placeringer, som instruktionerne kunne adressere -

så efter at det sidste datum blev håndteret, ville stigning i instruktionsadressen få det til at løbe over.

Bæret ville tilføje en til operationskoden og ændre den til den næste i instruktionssættet: en springinstruktion.

Sikker nok var den næste programinstruktion på adresseplacering nul, og programmet gik lykkeligt på vej.

Hypotetisk implementering: "Vis mig bitene!"

Her er en potentiel instruktion, der kan være springinstruktionen, der henvises til i historien:

Vi kan se kommandobitene er 10111 . Hvis afdelingskontrol er slået fra, er "den næste instruktion den, der er angivet i feltet Næste adresse." Så en hypotetisk situation ville være, at registeret (ved hjælp af rør til at betegne adskillelser mellem bitfelter) efter overløbet lyder:

10111 | 0000000 | 0000000 | 0

Ekstrapolering tilbage, før forøgelsen og overløbet, ville registret have læst:

10110 | 1111111 | 1111111 | 1

En interessant bivirkning ved at arbejde igennem denne implementering er, at den anvendte instruktion ikke betyder noget. Hver instruktion i RPC-4000 inkluderer adressen på den næste instruktion. Et overløb i indeksbitten til det næste adressefelt vil resultere i et spring til den adresse uanset kommandobit.

Epilog

Mel Kaye (afbildet stående, yderst til højre) fortsatte med at arbejde og sluttede til sidst. En fan ved navn Anthony Cuozzo skrev i 2014, at han forsøgte at komme i kontakt med Mel:

Det lykkedes mig til sidst at komme i kontakt med Mel, men jeg skræmte ham desværre væk. Det er en historie for en anden dag ...: - / (kilde)

Af respekt for Mels privatliv vil jeg ikke sende nogen personlige oplysninger og holde mig til programmet og historien. Hvis nogen ved, hvordan Mel har det med sin internetberømmelse, vil jeg meget gerne høre fra dig.

Jeg har ikke holdt kontakten med Mel, så jeg ved ikke, om han nogensinde gav efter for strømmen af ​​forandring, der har skyllet over programmeringsteknikker siden de langt væk dage. Jeg kan godt lide at tro, at han ikke gjorde det. - Ed Nather

Yderligere kilder:

  • Wikipedia's side om historien om Mel
  • Mel's manual til RPC-4000 blackjack-spillet
  • Sandheden kommer aldrig i vejen for en god historie af Jan Howard Brunvand

Dave arbejder udviklerrelationer hos IBM. Af en eller anden grund har IBM ikke en SDK til RPC-4000.