Πέμπτη, 10 Ιουνίου 2010

Η ιστορία του Mel, ενός Αληθινού Προγραμματιστή!

LGP-30

(Η ιστορία του Mel είναι ένας κλασσικός θρύλος των χάκερ (με την έννοια των πρώτων προγραμματιστών). Τη μεταφράζω εδώ αφού δεν την βρήκα στα Ελληνικά και με την ευκαιρία της αναζήτησής μου για Ελληνικούς προγραμματιστικούς όρους που να είναι δόκιμοι (δηλαδή: α) να είναι κατανοητοί και β) να μην είναι απαίσια κακόηχοι). Προσθέτω και τα σχόλιά μου, για την ευκολότερη κατανόηση του άθλου του Mel- ζητώ συγγνώμη αν τα σχόλια δεν βοηθάνε ιδιαίτερα τον μη-τεχνικά καταρτισμένο αναγνώστη! Σ' αυτόν ή αυτήν, θα πρότεινα να διαβάσει το θρύλο χωρίς να προσπαθεί να καταλάβει, λίγο σαν ένα επικό ποίημα που αναφέρεται σε έναν άγνωστο πολιτισμό, μιας περασμένης εποχής (και λίγο-πολύ αυτό είναι). Τα σχόλιά μου, που είναι τρεις-τέσσερις φορές το μέγεθος της ιστορίας και αναφέρονται στην αρχιτεκτονική των υπολογιστών της ιστορίας και στον προγραμματισμό τους σε επίπεδο συμβολικής γλώσσας, ακολουθούν κάτω από το διαχωριστικό της ανάρτησης- πατήστε στο "(A suivre)" για να τα δείτε.

Η ιστορία του Mel είναι αληθινή, αν και ίσως όχι έτσι ακριβώς όπως τη θυμάται ο αφηγητής (δείτε το τελευταίο μου σχόλιο [42] για λεπτομέρειες). Δημοσιεύτηκε για πρώτη φορά σ' ένα γκρουπ του Usenet, από τον Ed Nather, το Μάη του 1983. Ο πρωταγωνιστής της, ο Mel Kaye είναι υπαρκτό πρόσωπο και δούλευε για την Royal Mac Bee Corporation το 1960. Η υπογραφή του υπάρχει σε σωζόμενα έγγραφα της εταιρίας.

Για ένα σχολιασμό που τουλάχιστον επιχειρεί να είναι πιο κατανοητός στο μέσο αναγνώστη, πατήστε εδωνά (Αγγλική γλώσσα- τα σχόλια είναι πίσω από τον σύνδεσμο με τίτλο Annotations). Το πρωτότυπο της ιστορίας το πήρα από το Jargon File, εδώ).

Διατρητή κάρτα (προς το παρόν αδιάτρητη)

Ένα πρόσφατο άρθρο αφιερωμένο στην macho πλευρά του προγραμματισμού
δήλωνε, λιτά κι απερίφραστα:

Οι Αληθινοί Προγραμματιστές γράφουν σε FORTRAN. [0]

Μπορεί να είναι έτσι σήμερα,
σ' ετούτη την παρακμιακή εποχή,
της λάιτ μπύρας, των αριθμομηχανών τσέπης, και του "φιλικού προς το χρήστη" λογισμικού
στις παλιές καλές εποχές όμως,
όταν ο όρος "software" ακουγόταν αστείος
και υπήρχαν Αληθινοί Υπολογιστές φτιαγμένοι από τύμπανα και λυχνίες,[1]
Αληθινοί Προγραμματιστές έγραφαν σε γλώσσα μηχανής.
Όχι σε FORTRAN. Όχι σε RATFOR. Ούτε καν σε συμβολική γλώσσα. [2]
Σε Γλώσσα Μηχανής.
Σκέτο, απέριττο, αινιγματικό δεκαεξαδικό.
Κατ' ευθείαν.

Για να μην πάει και μια ολόκληρη νέα γενιά προγραμματιστών
μεγαλώσουν στην άγνοια γι' αυτό το ένδοξο παρελθόν,
θεωρώ καθήκον μου να περιγράψω,
όσο καλύτερα μπορώ μέσα από το χάσμα των γενεών,
πώς ένας Αληθινός Προγραμματιστής έγραφε κώδικα.
Θα τον πω Mel,
γιατί αυτό ήταν το όνομά του.

Συνάντησα τον Mel για πρώτη φορά όταν πήγα να δουλέψω για την Royal McBee Computer Corp,
μια θυγατρική της εταιρείας γραφομηχανών, που έχει πια κλείσει.
Η εταιρεία κατασκευάζε το LGP-30, [3]
έναν μικρό, φτηνό (για τα δεδομένα της εποχής)
υπολογιστή με τύμπανο μνήμης,
και μόλις είχε αρχίσει να κατασκευάζει
το RPC-4000[4], ένα πολύ βελτιωμένο,
μεγαλύτερο, καλύτερο, ταχύτερο - υπολογιστή με τύμπανο μνήμης.
Οι μνήμες πυρήνα[5] κοστίζουν πάρα πολύ,
και δεν πρόκειται να κρατήσουν, έτσι κι αλλοιώς.
(Αυτός είναι ο λόγος που δεν έχετε ακουστά την εταιρεία,
ή τον υπολογιστή.)

Τύμπανο μνήμης

Είχα προσληφθεί για να γράψω έναν μεταγλωττιστή[6] FORTRAN
για το νέο αυτό τεχνολογικό θαύμα και ο Mel ήταν ο οδηγός μου στα μυστικά του.
Ο Mel δεν ενέκρινε τους μεταγλωττιστές.

«Αν ένα πρόγραμμα δεν μπορεί να ξαναγράψει τον κώδικα του»,
ρωτούσε, «τί να το κάνεις;» [7]

Ο Mel είχε γράψει,
σε δεκαεξαδικό,
το πιο δημοφιλές πρόγραμμα που ανήκε στην εταιρεία. [8]
Έτρεχε στο LGP-30
και έπαιζε "εικοσιένα" με τους μελλοντικούς πελάτες
στις εκθέσεις υπολογιστών.
Έκανε πάντα τρομερή εντύπωση.
Σε κάθε έκθεση το περίπτερο του LGP-30 ήταν πάντα γεμάτο κόσμο,
και οι πωλητές της IBM στέκαν μονάχοι,
μιλώντας μεταξύ τους.
Το αν μ' όλα αυτά πουλιόντουσαν όντως υπολογιστές
ήταν κάτι που δεν το συζητούσαμε ποτέ.

Η δουλειά του Μελ ήταν να ξαναγράψει
το πρόγραμμα που έπαιζε εικοσιένα για το RPC-4000.
(Μεταφορά;[9] Τι σημαίνει αυτό;)
Ο καινούργιος υπολογιστής είχε διευθύνσεις
σε διάταξη "ένα-συν-ένα"
σύμφωνα με την οποία κάθε οδηγία μηχανής[10],
εκτός από τον κωδικό λειτουργίας [11]
και τη διεύθυνση του αντικειμένου [12]
είχε μια δεύτερη διεύθυνση που υποδείκνυε πού,
στην επιφάνεια του περιστρεφόμενου τύμπανου,
βρισκόταν η επόμενη εντολή. [13]

Με τη σημερινή ορολογία,
μετά από κάθε εντολή ακουλουθούσε ένα GO TO!
Για πες το αυτό στην Pascal να δούμε πώς θα της φανεί! [14]

Ο Mel λάτρευε το RPC-4000
γιατί μπορούσε να βελτιστοποιήσει[15] τον κώδικά του:
δηλαδή, τοποθετούσε τις οδηγίες στο τύμπανο
έτσι ώστε τη στιγμή ακριβώς που η μία τελείωνε την εργασία της,
η επόμενη έφτανε μόλις στην "κεφαλή ανάγνωσης"
έτοιμη για άμεση εκτέλεση. [16]
Υπήρχε ένα πρόγραμμα γι' αυτή τη δουλειά,
ένας "μεταγλωττιστής βελτιστοποίησης", [17]
αλλά ο Mel αρνιόταν να το χρησιμοποιήσει.

«Ποτέ δεν ξέρεις που θα πάει να βάλει τί»,
εξηγούσε, «κι έτσι θα πρέπει να έχεις χωριστές σταθερές».

Πέρασε πολύς καιρός για να καταλάβω αυτό το σχόλιο.
Καθώς ο Mel ήξερε την αριθμητική τιμή
κάθε κωδικού λειτουργίας,
και όριζε μόνος του τις διευθύνσεις στο τύμπανο,
κάθε εντολή που έγραφε μπορούσε την ίδια στιγμή να θεωρηθεί
και σαν μια αριθμητική σταθερά.
Μπορούσε ας πούμε να μαζέψει μια προηγούμενη οδηγία "add"
και να πολαπλασιάσει επί αυτήν,
αν η αριθμητική της τιμή ήταν η κατάλληλη. [18]
Ο κώδικάς του δεν ήταν εύκολο να τροποποιηθεί από τρίτους.

Έκανα σύγκριση ανάμεσα στα προγράμματα του Mel που τα είχε βελτιστοποιήσει με το χέρι
με τον ίδιο κώδικα μετά από τις περιποίησεις του μεταγλωττιστή βελτιστοποίησης,
και τα προγράμματα του Mel έτρεχαν πάντα πιο γρήγορα.
Αυτό ήταν επειδή η «top-down» μέθοδος σχεδιασμού ενός προγράμματος
δεν είχε ακόμη εφευρεθεί,
κι έτσι κι αλλιώς ο Mel δεν θα την είχε χρησιμοποιήσει.
Έγραφε πρώτα τα εσώτερα μέρη των βρόχων [19] στα προγράμματά του,
ώστε να έχουν πρώτη διαλογή
στις βέλτιστες θέσεις διευθύνσεων στο τύμπανο.
Ο μετταγλωτιστής βελτιστοποίησης δεν ήταν αρκετά εξυπνος για να κάνει το ίδιο.

Ο Mel δεν έγραφε επίσης ποτέ βρόχους χρονοκαθυστέρησης, [20]
ακόμα και όταν η πεισματάρικη Flexowriter [21]
απαιτούσε να υπάρχει καθυστέρηση μεταξύ των χαρακτήρων στην έξοδο για να λειτουργήσει σωστά. [22]
Τοποθετούσε απλώς τις οδηγίες στο τύμπανο
έτσι ώστε κάθε διαδοχική εντολή να έχει μόλις περάσει την κεφαλή ανάγνωσης [23]
όταν την χρειαζόταν το πρόγραμμα.
Το τύμπανο έπρεπε να εκτελέσει άλλη μία πλήρη περιστροφή
για να βρει την επόμενη οδηγία.
Είχε επινοήσει έναν αξέχαστο όρο γι' αυτήν τη διαδικασία.
Αν και το «βέλτιστο» είναι υπερθετικός βαθμός, και άρα απόλυτο,
όπως το «μοναδικό», είχε γίνει κοινή λεκτική πρακτική
η σχετικοποίησή του:
«όχι ακριβώς βέλτιστο» ή «λιγότερο βέλτιστο»
ή «μη πλέον βέλτιστο»
Ο Mel αποκαλούσε τις τοποθεσίες με τον μεγαλύτερο χρόνο καθυστέρησης
τις "πλέον χείριστες". [24]

Friden Flexowriter

Αφού τέλειωσε το πρόγραμμα που έπαιζε εικοσιένα
και το έκανε να τρέχει
(«Ακόμη και η προκαταρκτική διαδικασία είναι βελτιστοποιημένη» [25]
είπε με περηφάνεια),
παρέλαβε μια Αίτηση Αλλαγής από το τμήμα πωλήσεων.
Το πρόγραμμα χρησιμοποιούσε μια κομψά σχεδιασμένη (βελτιστοποιημένη) [26]
γεννήτρια τυχαίων αριθμών
για να ανακατεύει τις "κάρτες" και να μοιράζει από την "τράπουλα",
και ορισμένοι από τους πωλητές θεώρησαν ότι παραήταν τίμιο,
καθώς μερικές φορές έχαναν οι πελάτες.
Ήθελαν από τον Μελ να τροποποιήσει το πρόγραμμα
έτσι ωστε, με το πάτημα ενός διακόπτη εισαγωγής[27] στην κονσόλα
να μπορούν να αλλάξουν τις πιθανότητες και να αφήσουν τον πελάτη να κερδίσει.

Ο Μελ ρούτζωσε.
Του φάνηκε οτι κάτι τέτοιο ήταν ολοφάνερα ανέντιμο,
που όντως ήταν,
και οτι προσέβαλε την προσωπική του ακεραιότητα ως προγραμματιστή,
που όντως την προσέβαλε,
κι έτσι αρνήθηκε να το κάνει.
Ο Διευθυντής Πωλήσεων μίλησε στον Mel,
όπως έκανε και το Μεγάλο Αφεντικό και, με την προτροπή του αφεντικού,
κάμποσοι Συνάδελφοι Προγραμματιστές.
Ο Mel τελικά ενέδωσε και έγραψε τον κώδικα,
αλλά ο έλεγχος του βγήκε ανάποδα [28]
και όταν ο διακόπτης εισαγωγής ήταν ενεργοποιημένος,
το πρόγραμμα έκλεβε και κέρδιζε κάθε παρτίδα.
Ο Μελ ενθουσιάστηκε με αυτό το αποτέλεσμα,
ισχυρίστηκε οτι το υποσυνείδητό του ήταν ανεξέλεγκτα ηθικό
και αρνήθηκε πεισματικά να το φτιάξει. [29]

Όταν ο Mel έφυγε απ' την εταιρία για άλλε$ πολιτείε$
το Μεγάλο Αφεντικό μου ζήτησε να κοιτάξω τον κώδικα
και να δω αν μπορούσα να βρω τον έλεγχο και να τον αντιστρέψω.
Κάπως απρόθυμα, συμφώνησα να το κοιτάξω.
Ήταν ολόκληρη περιπέτεια να παρακολουθείς τον κώδικα του Mel. [30]

Συχνά αισθάνομαι ότι ο προγραμματισμός είναι μια μορφή τέχνης,
της οποίας η πραγματική αξία μπορεί να εκτιμηθεί
μόνο από κάποιον άλλο μυημένο στις ίδιες απόκρυφες τέχνες.
Υπάρχουν υπέροχα κοσμήματα και λαμπρά στρατηγήματα
κρυμμένα από την ανθρώπινη ματιά και το θαυμασμό, μερικές φορές για πάντα,
από την ίδια τη φύση της διαδικασίας.
Μπορεί κανείς να μάθει πολλά για ένα άτομο
απλά και μόνο διαβάζοντας τον κώδικά του,
ακόμη και σε δεκαεξαδικό.
Ο Mel ήταν, θαρρώ, μια παραγνωρισμένη ιδιοφυία.

Ίσως το μεγαλύτερο σοκ ήταν
όταν βρήκα έναν αθώο βρόχο που δεν είχε κανέναν έλεγχο στο εσωτερικό του.
Καμμία συνθήκη. Τίποτα.
Η κοινή λογική έλεγε ότι θα έπρεπε να είναι ένας κλειστός βρόχος, [31]
όπου η εκτέλεση του προγράμματος θα επαναλαμβανόταν, για πάντα και για πάντα.
Παρ' όλ' αυτά ο έλεγχος του προγράμματος περνούσε κατευθείαν από μέσα του [32]
κι έβγαινε από την άλλη πλευρά χωρίς πρόβλημα.
Μου πήρε δύο εβδομάδες για να καταλάβω τί γινόταν.

RPC-4000

Το RPC-4000 διέθετε μια πραγματικά σύγχρονη μονάδα
που λέγεται κατάλογος δεικτών. [33]
Αυτή επέτρεπε στον προγραμματιστή να γράψει ένα βροχο
που χρησιμοποιούσε μια καταχωρημένη οδηγία στο εσωτερικό του. [34]
Σε κάθε πέρασμα,
ο αριθμός στον κατάλογο δεικτών
προστίθετο στην διεύθυνση αυτής της οδηγίας,
ωστε να παραπέμπει
στο επόμενο δεδομένο σε μία σειρά.
Το μόνο που είχε να κάνει ήταν να επαυξάνει τον κατάλογο δεικτών
σε κάθε πέρασμα.
Ο Mel δεν το χρησιμοπούσε ποτέ.

Αντί γι' αυτό, τραβούσε την οδηγία σ' έναν από τους καταλόγους μηχανής, [35]
πρόσθετε ένα στη διεύθυνσή της
και την αποθήκευε πάλι στη θέση της.
Κατόπιν, εκτελούσε την τροποποιημένη οδηγία
κατευθείαν από τον κατάλογο. [36]
Ο βρόχος ήταν γραμμένος κατά τέτοιον τρόπο ώστε αυτός ο πρόσθετος χρόνος εκτέλεσης
να λαμβάνεται υπόψη-
ακριβώς τη στιγμή που αυτή η οδηγία τέλειωνε,
η επόμενη βρισκόταν ακριβώς κάτω από την κεφαλή ανάγνωσης του τύμπανου,
έτοιμη να ξεκινήσει.
Ο βρόχος όμως, δεν είχε κανέναν έλεγχο μέσα του.

Ανακάλυψα το στοιχείο-κλειδί όταν πρόσεξα
οτι το bit του κατάλογου δεικτών,
το bit που βρισκόταν ανάμεσα στη διεύθυνση
και τον κώδικα λειτουργίας στην δυαδική λέξη της οδηγίας, [37]
ήταν θετικό-
κι όμως ο Mel δεν χρησιμοποιούσε τον κατάλογο δεικτών,
τον άφηνε συνέχεια στο μηδέν.[38]
Όταν το λαμπάκι άναψε, κόντεψε να με τυφλώσει.

Είχε τοποθετήσει τα δεδομένα πάνω στα οποία δούλευε
κοντά στην κορυφή της μνήμης-
τις υψηλότερες τοποθεσίες στις οποίες μπορούσαν να απευθυνθούν οι οδηγίες- [39]
έτσι, αφού επεξεργαζόταν το τελευταίο δεδομένο,
επαύξανε την διεύθυνση της οδηγίας
κάνοντάς την να υπερχειλίσει. [40]
Το κρατούμενο πρόσθετε ένα
στον κώδικα λειτουργίας, αλλάζοντάς τον στην επόμενη οδηγία στο σύνολο των οδηγιών,
μία οδηγία άλματος. [41]
Και βέβαια, η επόμενη οδηγία του προγράμματος βρισκόταν στην τοποθεσία μηδέν,
και το πρόγραμμα συνέχιζε χαρούμενο την λειτουργία του. [42]

Δεν έχω κρατήσει επαφή με τον Mel,
κι έτσι δεν ξέρω αν υπέκυψε ποτέ στην παλίρροια
της αλλαγής που σάρωσε τις προγραμματιστικές τεχνικές
έκτοτε. Εκείνες οι μέρες οι παλιές έχουνε πια περάσει.
Θέλω να πιστεύω οτι δεν υπέκυψε.
Σε κάθε περίπτωση,
εντυπωσιάστηκα αρκετά ωστε σταμάτησα να ψάχνω
για τον υπαίτιο έλεγχο,
και είπα στο Μεγάλο Αφεντικό οτι δεν μπορούσα να τον βρω.
Δεν έδειξε να εκπλήσσεται.

Όταν έφυγα από την εταιρία,
το πρόγραμμα που έπαιζε εικοσιένα εξακολουθούσε να κλέβει
όταν κατέβαζες το σωστό διακόπτη εισαγωγής,
κι έτσι πιστεύω οτι ήταν το σωστό.
Δεν ένοιωθα άνετα
να χακέψω τον κώδικα ενός Αληθινού Προγραμματιστή.





[0] Αναφέρεται σε μια επιστολή που είχε σταλεί στον εκδότη του περιοδικού "Datamation' στο τεύχος 7, του Ιουλίου 1983 από τον Ed Post της εταιρίας Tectronix. Ο τίτλος της επιστολής παραπέμπει στον τίτλο του βιβλίου του Bruce Feirstein "Real Men Don't Eat Quiche", του 1982, που σατυρίζει τα στερεότυπα της αρρενωπότητας στον Αμερικάνικη κοινωνία. Η επιστολή του Ed Post σατυρίζει την αντιμετώπιση της Pascal ως "εύκολης" γλώσσας σε αντιδιαστολή με την FORTRAN που είναι δύσκολη και γι' αυτό μόνο "για Αληθινούς Προγραμματιστές" (που είναι... μάτσο). Η επιστολή έγινε μιμίδιο (meme) στο ίντερνετ.

Το κείμενο της επιστολής είναι διαθέσιμο εδώ: http://www.pbm.com/~lindahl/real.programmers.html

[1] Drum memory. Μαγνητική συσκευή μνήμης που ήταν σε ευρεία χρήση τις δεκαετίες του 50 και 60. Πρόκειται για έναν περιστρεφόμενο κύλινδρο με επικάλυψη μαγνητικού υλικού. Στην περιφέρειά του υπάρχουν ακίνητες μαγνητικές κεφαλές. Οι κεφαλές μπορούν να μαγνητίσουν ή να απομαγνητίσουν σημεία του κύλινδρου για να αποθηκεύσουν πληροφορία ή να την τροποποιήσουν, ή να ανιχνεύσουν το μαγνητισμό για να διαβάσουν την πληροφορία.

[2] Assembly language.

[3] Librascope General Purpose (αργότερα General Precision) LGP-30, υπολογιστής του 1956, γνωστός επίσης και επειδή τον χρησιμοποίησε ο Edward Lorenz στην έρευνά του για τα κλιματικά συστήματα που οδήγησε στην ανακάλυψη των "παράξενων ελκυστών" (fractals) και του "φαινόμενου της πεταλούδας", δηλαδή των βάσεων της μαθηματικής θεωρίας του χάους.

Λεπτομέρειες για την αρχιτεκτονική και τη λειτουργία του υπολογιστή, μπορείτε να διαβάσετε στο εγχειρίδιό του, που υπάρχει εδώ:

http://ed-thelen.org/comp-hist/lgp-30-man.html

Το εγχειρίδιο περιέχει και τη λίστα με τις οδηγίες του υπολογιστή, και ένα μικρό μάθημα προγραμματισμού στην συμβολική του γλώσσα. Το βρήκα μάλλον προσβάσιμο, για ολη την οικογένεια :)

LGP-30

[4] Royal Precision Computer, RPC-4000, κατασκευάστηκε το 1963. To εγχειρίδιο του RPC-4000 βρίσκεται κι αυτό online, εδώ:

http://www.textfiles.com/bitsavers/pdf/royal/RPC4000PgmMan.pdf

Έχει κι αυτό ένα μικρό μάθημα προγραμματισμού για τον ROAR τον συμβολικό μετταγλωτιστή (assembler) του συστήματος, αλλά προτιμώ το μάθημα στο LGP-30, που είναι πολύ πιο λιτό.

Από το διαφημιστικό της εταιρίας:

COST, PRICE AND RENTAL RATES
Cost of basic system
Computer (including one Tape Typewriter) $87,500
Additional. equipment
Photo Electric Reader 15,000
High Speed Punch 20,000
Tape Typewriter (off line) 5,000
Rental for basic system
Computer (including one Tape Typewriter) $1,750
Rental additional equipment
Photo Electric Reader 300
High Speed Punch 400
Tape Typewriter (off line) 150
Maintenance included in rental; service contract
available for purchasers.


RPC-4000

[5] Παλιός τύπος μαγνητικής μνήμης, που αντικατέστησε τα τύμπανα μνήμης.

[6] Compiler. Υπάρχουν άλλες μεταφράσεις (πχ., "αποδελτιωτής") αλλά νομίζω οτι αυτή αποδίδει ακριβέστερα τη λειτουργία του προγράμματος. Παρ. και το άρθρο της Ελληνόφωνη Βικιπαίδειας.

[7] Self-modifying program. Ένα πρόγραμμα που μπορεί να τροποποιήσει τον αρχικό του κώδικα, όπως αυτό που περιγράφεται σε αυτήν την ιστορία.

H τροποποίηση μπορεί να γίνει στους κωδικούς οδηγιών, ή στις διευθύνσεις των δεδομένων που περιέχουν οι οδηγίες σε ειδικά πεδία. Για παράδειγμα το εγχειρίδιο του LGP-30 που λινκάρω πιο πάνω εξηγεί πώς γράφεται ένας βρόχος για τον υπολογισμό ενός αθροίσματος γινομένων. Ο βρόχος ανατρέχει στη σειρά των συντελεστών με τη συνεχή επαύξηση ενός πεδίου διεύθυνσης που βρίσκεται στο τέλος της δυαδικής λέξη της οδηγίας πρόσθεσης. Δηλαδή, για να βρεις τον επόμενο συντελεστή και να τον προσθέσεις, προσθέτεις ένα στην οδηγία της πρόσθεσης. Καλό ε;

[8] Σημειώστε οτι ο κώδικας ανήκε στην εταιρία και όχι στον προγραμματιστή. Τίποτα ασυνήθιστο, παρατηρώ μόνο οτι εκείνη την εποχή ήταν περίπου άχρηστο να "ανήκει" ο κώδικας σε οποιονδήποτε, ακόμη και τον προγραμματιστή, όταν στην ουσία χρήσιμος κώδικας υπήρχε μόνο στις μνήμες των υπολογιστών, αν και βέβαια ήταν πάντα δυνατή η αποθήκευση και μεταφορά του, με διάτρητες ταινίες ή κάρτες, ή μαγνητικές ταινίες κλπ. Σε καμμία περίπτωση πάντως η μεταφορά και ανταλλαγή κώδικα δεν ήταν τόσο εύκολη όσο σήμερα, ή τέλος πάντων από την έλευση του διαδίκτυο και μετά. Αυτό πιθανόν εξηγεί την απουσία ενός οργανωμένου κινήματος όπως αυτό του ελεύθερου λογισμικού, πριν το '80 (συγκεριμμένα, το 1983 με την ίδρυση του GNU Project απ' τον Richard Stallman).

[9] Port. Μεταφορά του προγράμματος από μία αρχιτεκτονική επεξεργαστή σε μία άλλη.

[10a] Machine instruction. Μεταφράζεται και ως "εντολή", που όμως μπορεί να οδηγήσει σε σύγχιση με τις "εντολές" (commands) γλωσσών προγραμματισμού, όπως η BASIC, το shell script κλπ.

[11] Operation code (και opcode). Για την ακρίβεια, "κώδικας πράξης" αφού "operation" σε σχέση με τους υπολογιστές εννοούμε την αριθμητική ή λογική πράξη. Την ίδια στιγμή όμως, ολοκληρώνεται μια "λειτουργία" των κυκλωμάτων του υπολογιστή και γι' αυτό μάλλον ακούγεται περίεργο να μιλήσει κανείς για "κωδικούς πράξης". Δες και το 10 για το operand.

[12] Operand. Ο ένας από τους δύο όρους μιας αριθμητικής ή λογικής πράξης στην αριθμητική και λογική μονάδα (Arithmetic and Logic Unit, ALU) του επεξεργαστή. Το βρήκα επίσης μεταφρασμένο ως "τελεστέος" και ως "τελεστής". Το πρώτο είναι μεν ακριβές (το αντικείμενο της τέλεσης μίας πράξης) αλλά κακοηχέστατο (έτσι ακριβώς). Ο δε "τελεστής" αναφέρεται σε όρο συνάρτησης, όπως και ο "συντελεστής" (μία εναλλακτική που εξέτασα) αναφέρεται στους όρους του πολλαπλασιασμού. Τελικά θα ήθελα να το μεταφράσω απλά ως "όρο" αλλά υπάρχει ήδη η έννοια του όρου (term) στις γλώσσες προγραμματισμού που ως γενικότερη έχει προτεραιότητα.

Γιατί όμως αντικείμενο; Κάθε ένας από τους όρους μιας πράξης είναι βέβαια και αντικείμενό της, όπως και στη γραμματική τα ρήματα έχουν αντικείμενο. Την ίδια στιγμή, η έννοια του αντικειμένου (object) στον αντικειμενοστραφή προγραμματισμό είναι επίσης σημαντική, κι αυτό ίσως οδηγήσει σε σύγχιση. Προτείνω λοιπόν να γράφεται με κεφαλαίο το Αντικείμενο στον αντικειμενοστραφή προγραμματισμό, κατά την παράδοση της Java κλπ, και με πεζό (ακόμη και στην αρχή της πρότασης) το αντικείμενο μιας αριθμητικής ή λογικής πράξης στην αριθμητική και λογική μονάδα του επεξεργαστή. Φυσικά χρησιμοποιούμε τέτοιες πράξεις και στον προγραμματισμό με γλώσσες υψηλού επιπέδου και η διαφορετική γραφή μπορεί να εφαρμοστεί κι εκεί χωρίς σύγχιση.

[13] Με άλλα λόγια, κάθε κώδικα οδηγίας ακολουθεί μια διεύθυνση στο τύμπανο μνήμης του υπολογιστή, στην οποία βρίσκεται το αντικείμενο της οδηγίας. Σύμφωνα με το manual του RPC-4000, η μορφή μιας δυαδικής λέξης οδηγίας (binary instruction word) είναι η εξής:

Command Operand Address Next Address IR
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 4 5 11 12 17 18 24 25 30 31
Track Sector Track Sector flag

Τα bits από 0-4 είναι ο κωδικός οδηγίας. Από 5-17 είναι η διεύθυνση του αντικειμένου. Από 18-30 είναι η διεύθυνση της επόμενης οδηγίας. Το τελευταίο bit είναι το bit του καταλόγου δεικτών (index register bit), που θα το δούμε κι αργότερα.

Κάθε διεύθυνση αποτελείται από ένα εφταψήφιο δυαδικό αριθμό για τον δίαυλο και ένα εξαψήφιο δυαδικό αριθμό για τον τομέα, στο τύμπανο μνήμης. Το τύμπανο μνήμης είναι ένας περιστρεφόμενος κύλινδρος με μαγνητική επικάλυψη. Η επιφάνειά του είναι χωρισμένη σε 128 κυλινδρικούς δίαυλους, σε καθέναν από τους οποίους αντιστοιχεί (γενικά) μία μαγνητική κεφαλή ανάγνωσης/ γραφής δεδομένων. Κάθε δίαυλος είναι χωρισμένος σε 64 τομείς, ο καθένας από τους οποίους αποτελείται από 32 μαγνητικά σημεία. Κάθε σημείο μπορεί να μαγνητιστεί η να απομαγνητιστεί για να αποθηκεύσει ένα δυαδικό ψηφίο πληροφορίας, με τιμή 0 ή 1 αντίστοιχα. Έτσι, πχ, η διεύθυνση 0011000 001000 αντιστοιχεί στον τομέα 8 του δίαυλου 24.

Διευκρινίζω για τους μη τεχνικά καταρτισμένους αναγνώστες: όπως όλοι οι σύγχρονοι υπολογιστές, το RPC-4000 αποθηκεύει τις οδηγίες που αποτελούν κάθε πρόγραμμα, στη σταθερή του (non-volatile) μνήμη, είναι δηλαδή ένας υπολογιστής αποθηκευμένου προγράμματος. Ένα μεγάλο μέρος της λειτουργίας του υπολογιστή είναι η ανάγνωση από τη μνήμη των οδηγιών αυτών και η μεταφορά τους στον κεντρική μονάδα επεξεργασίας (CPU) όπου εκτελούνται (για παραδειγματισμό) (χα χα). Tο πεδίο "Next Address" στη δυαδική λέξη οδηγίας, κατευθύνει τον επεξεργαστή στην διεύθυνση όπου είναι αποθηκευμένη η επόμενη οδηγία. Κάποιες οδηγίες δουλεύουν αλλοιώς αλλά δεν εμφανίζονται στην ιστορία μας.

[14] Αναφέρεται στην έλλειψη εντολής GOTO από την Pascal. Γενικότερα, η Pascal ακολουθεί τις ιδέες του Edsger Dijkstra για την οργάνωση των προγραμμάτων υπολογιστών, που είναι αντίθετη κι απ' αυτήν της FORTRAN. Από 'κει ξεκινάει η "διαμάχη" που οδήγησε στην επιστολή του Ed Post ("Real Programmers write in FORTRAN") που αναφέρεται στην αρχή της ιστορίας, που με τη σειρά της οδήγησε τον Ed Nather να γράψει το μέηλ με την ιστορία του Mel. Η ιστορία του Mel πρέπει λοιπόν να ενταχθεί στο ιστορικό πλαίσιο της διαφωνίας των προγραμματιστών στο ίντερνετ, για το "σωστό" τρόπο προγραμματισμού, που φυσικά έχει πλέον προχωρήσει πολύ πέρα από την κοντρα Pascal με FORTRAN.

Προσωπικά πιστεύω οτι τη διαμάχη την κέρδισε ο Nather με καθαρό προβάδισμα. Η αντιμετώπιση του Dijkstra είναι ακαδημαϊκή, του Ed Post είναι ειρωνική, ενώ του Nather είναι σχεδόν ποιητική (ίσως γι' αυτό κατέληξε το μέηλ του σε μορφή επικού ποιήματος) ενώ ασχολείται με την καθημερινή δουλειά των προγραμματιστών, αντί με ιδεολογικές φανφάρες. Αυτές ποτέ δεν λύνουν προβλήματα (κι η επίλυση προβλημάτων είναι η δουλειά των προγραμματιστών). Βέβαια, χωρίς τη δουλειά του Dijkstra και άλλων θεωρητικών, τα εργαλεία που έχουνε στη διάθεσή τους οι προγραμματιστές για να κάνουνε τη δουλειά τους δεν θα είχαν προχωρήσει ποτέ από το επίπεδο του δεκαεξαδικού και της συμβολικής γλώσσας- αλλά κι αυτό είναι μια μεγάλη συζήτηση.

Η άποψή του Dijkstra για το GOTO διατυπώνεται σε μια διάσημη επιστολή του, "GOTO Statement Considered Harmful,'' προς την Association for Computing Machinery (την αρχαιότερη επιστημονική οργάνωση πληροφορικής). Το πλήρες κείμενο της επιστολής βρίσκεται εδώ:

http://www.netzmafia.de/service/gotoharmful.html

Και αρχίζει με τη φράση:

"For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce."


(Για χρόνια είχα υπόψη μου την παρατήρηση οτι η ποιότητα των προγραμματιστών είναι αντιστρόφως ανάλογη προς την πυκνότητα των go to εντολών στα προγράμματα που παράγουν).

Ο αναγνώστης καταλαβαίνει οτι ο Dijkstra είχε τουλάχιστον υπόψη του την πιθανότητα στιβαρής αντίστασης στις ιδέες του.

Edsger Dijkstra, 11/5/1930 – 6/8/2002.

[15] Το οptimise.

[16] Οι μαγνητικές κεφαλές ήταν τοποθετημένες σε σταθερά σημεία γύρω από τον περιστρεφόμενο κύλινδρο του τύμπανου μνήμης, άρα για να διαβάσει ο επεξεργαστής μια οδηγία από τη μνήμη (ή να γράψει σε αυτή) έπρεπε να περιμένει να περάσει το σημείο όπου ήταν γραμμένη κάτω από την ανάλογη κεφαλή. Προφανώς, αν κάθε οδηγία ήταν γραμμένη έτσι ωστε όταν η επόμενη εντολή βρισκόταν στη σωστή θέση όταν ακριβώς τελείωνε η εκτέλεση της προηγούμενης, ο χρόνος εκτέλεσης ενός προγράμματος θα εξαρτιόταν πλέον μόνο από την ταχύτητα ανάγνωσης/ γραφής και την ταχύτητα του επεξεργαστή: ergo βελτιστοποίηση (στο χρόνο, τουλάχιστον).

[17] Optimising compiler. Σήμερα βέβαια κανείς δεν βελτιστοποιεί τον κώδικά του με το χέρι.

[18] Αφού κάθε κωδικός οδηγίας είναι μία ακολουθία δυαδικών ψηφίων, δηλαδή ένας δυαδικός αριθμός αποθηκευμένος στην μνήμη του υπολογιστή, μπορεί να χρησιμοποιηθεί σαν όρος μιας αριθμητικής πράξης.

Ένα παράδειγμα. Η οδηγία με κωδικό 11100, ADU (ADD TO UPPER) προσθέτει στο περιεχόμενο του άνω συσσωρυτή (upper accumulator- τα 32 πρώτα bits του συσσωρευτή) το δεδομένο που έχει αποθηκευτεί στη διεύθυνση που ορίζεται στο πεδίο διεύθυνσης αντικειμένου της, και κρατάει το αποτέλεσμα στον άνω συσσωρευτή. Η οδηγία με κωδικό 01110, MPY (MULTIPLY) πολλαπλασιάζει το περιεχόμενο του άνω συσσωρευτή με το περιεχόμενο της διεύθυνσης αντικειμένου της και αποθηκεύει τα 64 bits του αποτελέσματος στον άνω και κάτω συσσωρευτή.

Αν λοιπόν στη διεύθυνση 0000001 000001 (1ος δίαυλος, 1ος τομέας) γράψουμε την οδηγία ADU:

Command: ADU Operand Address Next Address IR
0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 4 5 11 12 17 18 24 25 30 31
Track Sector Track Sector flag

Κι εκτελέσουμε την οδηγία MPY δίνοντας για διεύθυνση αντικείμενου την διεύθυνση της οδηγίας ADU που μόλις γράψαμε:

Command: MPY Operand Address Next Address IR
0 1 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 4 5 11 12 17 18 24 25 30 31
Track Sector Track Sector flag

Ο επεξεργαστής θα πολλαπλασιάσει το περιεχόμενο του συσσωρευτή με το δυαδικό αριθμό που βρίσκεται σ' εκείνη τη διεύθυνση:

0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Δηλαδή τη δυαδική λέξη οδηγίας του ADU.

Ακόμη πιο καλό ε;

[19] Loop. Είπα να μην το πώ "λούπα" και με δείρουνε.

[20] Δηλαδή βρόχους που έχουν κυρίως σκοπό να περάσει ο χρόνος που παίρνει η εκτέλεσή τους, κι άρα μπορούν να είναι και "άδειοι" (απλά να λουπάρουν, χωρίς να κάνουν τίποτα).

[21] Friden Flexowriter, μοντέλο τηλέτυπου που μπορούσε να συνδεθεί σε υπολογιστή ή να δεχθεί οδηγίες από διάτρητη ταινία. Πολύ δημοφιλές στην εποχή του.

[22] Περιφερειακές συσκευές όπως η flexowriter ήταν (και είναι) πολύ αργές σε σχέση με τους μικροεπεξεργαστές των υπολογιστών. Για παράδειγμα, ο επεξεργαστής του RPC-4000 έπαιρνε πολύ λιγότερο χρόνο να στείλει στη flexowriter έναν-έναν τους χαρακτήρες ενός κειμένου που έπρεπε να τυπωθεί, απ' ό,τι μπορούσε το τηλέτυπο να τους τυπώσει. Μια στρατηγική για να συγχρονιστεί μια τέτοια συσκευή με έναν επεξαργαστή είναι να τρέχει κάθε φορά ένας βρόχος χρονοκαθυστέρησης. Σήμερα συνήθως αποθηκεύουμε την πληροφορία σε μια προσωρινή μνήμη (buffer). Αυτό επειδή α) έχουμε μνήμη να φαν' κι οι κότες και β) επειδή οι επεξεργαστές κειμένου, πχ, πρέπει να μπορούν να επικοινωνήσουν με διαφορετικούς εκτυπωτές που έχουν διαφορετικές ταχύτητες. Από μία άποψη, η δυνατότητα να προγραμματίζεις για μια συγκεκριμμένη συσκευή ή διάταξη, όπως ο Mel στην ιστορία, είναι πολυτέλεια.

[23] Άρα για να ξαναβρεθεί η οδηγία κάτω από την κεφαλή και να διαβαστεί, έπρεπε να περάσει ο χρόνος που χρειαζόταν το τύμπανο για να ολοκληρώσει μια ολόκληρη περιστροφή. Στο RPC-4000 αυτός ο χρόνος ήταν 17 μιλισεκόντ.

[24] Στο πρωτότυπο: "most pessimum"!

[25] Ιnitialiser. Κρατήθηκα να μην το μεταφράσω ως "τα προκαταρκτικά" :)

[26] Elegant.

[27] Sense switch. Διακόπτες εισαγωγής που είχαν οι παλιότεροι υπολογιστές. Σε υπολογιστές χωρίς αποθηκευμένο πρόγραμμα χρησιμοποιούνταν για να εισάγουν το πρόγραμμα στον υπολογιστή, αντιστοιχούσαν δηλαδή κατευθείαν στα bits της RAM. Σε υπολογιστές με αποθηκευμένο πρόγραμμα όπως το LGP-30 και το RPC-4000 χρησιμοποιούνταν για να επιλέξουν παράμετρους για κάποιες λειτουργίες, όπως στην ιστορία μας.

Η κονσόλα που αναφέρει είναι χαρακτηριστικό επίσης παλιότερων υπολογιστών, που είχαν ενδείξεις για τη λειτουργία τους σ' έναν πίνακα ελέγχου στο εξωτερικό τους. Το LGP-30 ας πούμε είχε ένα παραθυράκι που έδειχνε το περιεχόμενο των τριών καταλόγων του (του συσσωρευτή, του κατάλογου οδηγιών και του μετρητή προγράμματος).

Η οθόνη προβολής των καταλόγων του LGP-30

[28] Εννοεί τον έλεγχο της θέσης του διακόπτη εισαγωγής.

[29] Το πρόγραμμα ή το υποσυνείδητο άραγε;

[30] Οι Αληθινοί Προγραμματιστές επίσης δεν βάζουν σχόλια στον κώδικά τους (πάντα σύμφωνα με την επιστολή του Ed Post). Εκείνη την εποχή σίγουρα είχαν μια καλή δικαιολογία.

[31] Closed loop ή infinite loop.

[32] Program control.

[33] Index register. Ο "δείκτης" αναφέρεται στον δείκτη (index) μιας σειράς δεδομένων σε διαδοχικές τοποθεσίες στη μνήμη, όπως πχ ενός array (το μεταφράζω συστοιχία που μ' αρέσει, ή θα τσακωθούμε;). Αρχικά ο κατάλογος δεικτών αποθηκεύει την διεύθυνση του πρώτου δεδομένου στη σειρά. Σε κάθε επανάληψη (iteration) του βρόχου, η διεύθυνση αντιγράφεται από τον κατάλογο στο πεδίο με τη διεύθυνση του αντικειμένου, στην οδηγία που τρέχει μέσα στο βρόχο. Έπειτα το περιεχόμενο του καταλόγου δεικτών επαυξάνεται. Έτσι η οδηγία διατρέχει τη σειρά δεδομένων. Αυτή είναι η συνήθης πρακτική σήμερα. Για ένα παράδειγμα του πώς το κάνανε την παλιά καλή εποχή δείτε το μάθημα προγραμματισμού στο εγχειρίδιο του LGP-30, που δεν είχε κατάλογο δεικτών.

[34] Indexed instruction.

[35] Μachine registers.

[36] Αντί για την τοποθεσία στη μνήμη

[37] Binary word. 32 bits στην περίπτωση του RPC-4000

[38] Αυτό το bit λειτουργούσε ως λογικό "σημαιάκι" (Boolean flag) για να δείξει στο πρόγραμμα οτι πρέπει να κοιτάξει στον κατάλογο δεικτών και να χρησιμοποιήσει την πληροφορία που θα έβρισκε εκεί. Αν το bit ήταν 1, το πρόγραμμα έπρεπε να χρησιμοποιήσει την πληροφορία. ΑΝ ήταν 0, το αγνοούσε.

[39] Δηλαδή τις τοποθεσίες με δυαδικές διευθύνσεις που τα περισσότερα ψηφία τους ήταν 1. Πχ, η διεύθυνση του τελευταίου* τομέα στον τελευταίο* δίαυλο είναι 1111 111 (=127) 1111 11 (=63).

*Στην πληροφορική έχουμε ένα βίτσιο: μετράμε πάντα από το 0. Εγώ προσωπικά γουστάρω να μου λένε και βρωμόλογα όταν προγραμματίζω.

[40] Overflow. Η απώλεια πληροφορίας όταν μία αριθμητική πράξη μεταξύ δυαδικών αριθμών έχει αποτέλεσμα που αποτελείται από ν+1 δυαδικά ψηφία, όπου ν είναι η χωρητικότητα σε δυαδικά ψηφία της μνήμης του επεξεργαστή. Το αριστερότερο bit του αποτελέσματος παραπέφτει (ξεχειλίζει) και το αποτέλεσμα είναι λάθος.

[41] Jump instruction. Συγκεκριμμένα, unconditional jump, δηλαδή άλμα χωρίς έλεγχο, απ' αυτά που βδελύσσεται η Pascal.

[42] Με λίγα λόγια, αυτό που έκανε ήταν οτι επαύξανε το περιεχόμενο του πεδίου της επόμενης διεύθυνσης στην οδηγία που έτρεχε ο βρόχος, μέχρι να την αναγκάσει να υπερχειλίσει. Τότε το αριστερότερο δυαδικό ψηφίο της διεύθυνσης έπεφτε στο bit του κατάλογου δεικτών που ήταν 1, υπερχείλιζε ακόμη αριστερότερα, στο πεδίο του κωδικού οδηγίας και του πρόσθετε ένα, μετατρέποντάς τον στον κωδικό οδηγίας του ανεξέλεγκτου άλματος.

Εδώ όμως η αφήγηση του Ed Nather έχει κάποιο λάθος. Σύμφωνα με το εγχειρίδιο του RPC-4000, το bit του καταλόγου δεικτών ήταν στο τέλος της λέξης οδηγίας, όχι στη μέση της: ανάμεσα στον κωδικό οδηγίας και την διεύθυνση αντικειμένου, η λέξη οδηγίας του RPC-4000 δεν έχει τίποτα. Επιπλέον, το RPC-4000 δεν έχει οδηγία ανεξέλεγκτου άλματος στο σύνολο οδηγιών του (instruction set), επειδή δεν την χρειάζεται: είπαμε, κάθε οδηγία έχει ένα δικό της GOTO, στο πεδίο επόμενης διεύθυνσης.

Από την άλλη, το LGP-30, το αρχικό μοντέλο για το οποίο είχε γράψει ο Mel το πρόγραμμά του, έχει οδηγία ανεξέλεγκτου άλματος. Δεν έχει όμως κατάλογο δεικτών κι άρα ούτε bit για σημαιάκι του. Εκείνο που έχει είναι δύο bits ανάμεσα στον κωδικό οδηγίας και την διεύθυνση αντικειμένου.

Οπότε, τί παίχτηκε; Ο Ed Nather μπορεί να έβγαλε την ιστορία τελείως από το μυαλό του όμως ο Mel Kaye είναι υπαρκτό πρόσωπο (ας πούμε, η υπογραφή του υπάρχει σε έγγραφα της Royal MacBee, και αναφέρεται οτι έγραψε το μεγαλύτερο μέρος του εγχειρίδιου του LGP-30 ενώ υπάρχουν προγραμματιστές που θυμούνται να παίζουν εικοσιένα στον υπολογιστή αυτό, στα φοιτητικά τους χρόνια, κλπ).

Ψάχνοντας στο δίκτυο βρήκα μια αναφορά σ' έναν εξομοιωτή της αρχιτεκτονικής του LGP-30 για το RPC-4000, που είχε γραφτεί ειδικά ώστε τα προγράμματα του LGP-30 να τρέχουν στο καινούργιο μηχάνημα χωρίς να χρειαστεί να ξαναγραφτούν από την αρχή:

My name is James William (Bill) Bryner ... In 1960 I was hired by Royal-McBee to write the assembler for the replacement to the LGP-30, the RPC-4000.

Mel Kaye designed the RPC-4000 assembler. It was titled ROAR (Royal-McBee Optimizing Assembler Routine). Edward W. Dubbs and I programmed that assembler. Following that, I wrote an LGP-30 simulator to run on the RPC-4000. This was meant to allow all programs written for the LGP-30 to be executed on the RPC-4000 without further programming. A drum computer simulating a drum computer is agonizingly slow!


(Από εδώ : http://ed-thelen.org/comp-hist/lgp-30.html#Historical%20Notes)

Αυτό που πρέπει να έγινε είναι οτι το πρόγραμμα του Mel έτρεχε στο RPC-4000 χρησιμοποιώντας τον εξομοιωτή, κι ο Ed Nather είδε τον κώδικα του Mel όταν έτρεχε στο RPC-4000, γι' αυτό μπέρδεψε τα στοιχεία των αρχιτεκτονικών των δύο μηχανών.

Ο βρόχος του Mel πρέπει στην αρχή να ήταν γραμμένος για να εκμεταλλευτεί τα δύο δυαδικά ψηφία στη λέξη οδηγίας του LGP-30. Αυτά τα δύο δυαδικά ψηφία δεν είχαν συγκεκριμμένη λειτουργία κι ίσως ο Ed Nather να προσπαθούσε να θυμηθεί τί κάνανε και να έμπλεξε τη θέση τους με το ένα δυαδικό ψηφίο του κατάλογου δεικτών του RPC-4000. Η ιστορία του Mel γράφτηκε το 1983, όταν πια είχαν περάσει είκοσιτρία χρόνια από το γεγονός (η ιστορία δημοσιεύτηκε πρώτη φορά σαν μέηλ σέ ένα γκρουπ του Usenet το 1983). Δικαιολογείται, πιστεύω, ο Nather να τα έχει μπλεγμένα κάπως, μετά από τοσο καιρό (και χωρίς την πολυτέλεια του σημερινού δίκτυου για να φρεσκάρει τη μνήμη του με τα εγχειρίδια των δύο συστημάτων)!

Εκτύπωση από παρτίδα εικοσιένα στο LGP-30, κατά πάσα πιθανότητα με το πρόγραμμα του Mel Kaye.

5 σχόλια:

Ο χρήστης Blogger Αιθεροβάμων είπε...

Χαρά στο κουράγιο σου! Φοβερή δουλειά, ειδικά οι παραπομπές σου... (Μα έκατσες κι έψαξες το instruction set του LGP-30 και του RPC-4000?? Wow...)

Όσο για τη διαμάχη με τις goto, ουσιαστικά βρήκε τη λύση της με το ότι δημιουργήθηκαν οι "υψηλού επιπέδου" γλώσσες, οι οποίες τελικά μεταφράζονται σε κώδικα μηχανής. Οπότε ο Dijkstra "κέρδισε" αυτό για το οποίο κοπτόταν, το ευανάγνωστο φαίνεσθαι του κώδικα (γιατί ουσιαστικά αυτό όριζε ως ποιότητα) - και ευτυχώς που το κέρδισε. Από την άλλη, στον κώδικα μηχανής τα jumps θα είναι πάντα jumps, γιατί πολύ απλά δε γίνεται αλλιώς. Οπότε τελικά...όλοι κέρδισαν.

Η ιστορία του Mel, είναι ενδεικτική του πόσο έχουν αλλάξει γενικά οι ανάγκες και οι συνθήκες στο θέμα του προγραμματισμού. Σήμερα, ο (αποδοτικός για το συγκεκριμένο υπολογιστή) κώδικας του Mel άνετα θα μπορούσε να θεωρηθεί "κακός", επειδή ακριβώς χρησιμοποιεί (με "οριακό" τρόπο, πολλές φορές) τα χαρακτηριστικά της αρχιτεκτονικής και του instruction set ενός συγκεκριμένου υπολογιστή. Τότε, ήταν ευχής έργο να συμβαίνει αυτό, γιατί η απόδοση ήταν η βασική προτεραιότητα και οι πιθανότητες να θελήσει κάποιος να μεταφέρει κώδικα ανάμεσα σε διαφορετικών προδιαγραφών μηχανήματα ήταν πολύ μικρή. Βέβαια από την άλλη, ποιες είναι οι πιθανότητες να γραφόταν τέτοιο πρόγραμμα σε δεκαεξαδικό; Εδώ ακόμα και τα κινητά πλέον φοράνε Windows mobile...

That said, ασχέτως αναγκαιότητας ή μη σήμερα, ανέκαθεν πίστευα (και λογικά θα συνεχίσω να πιστεύω) πως όποιος μπορεί και προγραμματίζει σε δεκαεξαδικό είναι τουλάχιστον ευφυία.

Δευτέρα, 14 Ιουνίου 2010 - 4:56:00 π.μ. EEST  
Ο χρήστης Blogger stassa είπε...

Εγώ χαρά στο κουράγιο μου να κάτσω να κάνω τις παραπομπές, εσύ χαρά στο κουράγιο σου που έκατσες και τις διάβασες :) Τα manuals των παλιών υπολογιστών είναι θησαυροί ανεκτίμητης αξίας, μαθαίνοντας για τις μηχανές των προγόνων μας, μαθαίνουμε πώς να σχεδιάσουμε τις μηχανές του μέλλοντος. Αχ, μου 'ρθαν δάκρυα στα μάτια!!! Τ_Τ

Καλά λες για τον Dijkstra, ο Nather λέω οτι "κέρδισε" τη συζήτηση, επειδή η ιστορία του Μελ μ' άρεσε περισσότερο σαν ιστορία και σαν κείμενο, κι απ' το άρθρο του Dijkstra κι απ' την επιστολή του Ed Post. Αν μη τί άλλο κάνει τους προγραμματιστές πιο συμπαθείς. Χμ, θα μου πεις, έτσι το βλέπω εγώ! Τέλος πάντων, του δίνω experience points για τη συνεισφορά του στο flamewar :)

Εγώ με τη θέση του Dijkstra συμφωνώ. Το θέμα είναι να κάνουμε τη δουλειά μας, όχι να δείξουμε ποιός την έχει πιο μεγάλη (την υπομονή να κάθεται να πολεμάει το μηχάνημα, προφανώς ;) Και γενικώς ο Μελ δούλευε σε μια εποχή με πολύ διαφορετικές προδιαγραφές, όπως αναλύεις πολύ σωστά αγαπητή συνάδελφε :D Πιστεύω πλέον κατορθώματα του τύπου του κώδικα του Μελ συμβαίνουν μόνο στις ταινίες, ή, πιθανόν, στον προγραμματισμό firmware για ηλεκτρικές συσκευές κλπ, αλλά κι εκεί δε φαντάζομαι να γράφει κανείς κατευθείαν σε hex, του κερατά.

προγραμματισμό σε hex δεν έχω κάνει καθόλου, εννοείται, οπότε φαντάσου το σοκ που έπαθα όταν συνειδητοποίησα οτι στο RPC-4000, κάθε δεκαεξαδικός χαρακτήρας δεν αντιστοιχεί απαραίτητα σε ακριβώς ένα δυαδικό πεδίο του instruction word. Δηλ, το opcode είναι πέντε bits, το track address είναι εφτά, το sector address έξι κοκ. Ειλικρινά, ακόμη δεν έχω καταλάβει πώς διάολο προγραμματίζαν έτσι. Εφυΐα σίγουρα, εγώ θα είχα παρανοήσει... >_>

Μωρέ εικόνισμα θα του κάνω του Dijkstra, να του ανάβω το καντηλάκι!

Δευτέρα, 14 Ιουνίου 2010 - 4:15:00 μ.μ. EEST  
Ο χρήστης Blogger Constantine είπε...

Τι είναι αυτές οι φλωριές για δεκαεξαδικά και κώδικα μηχανής;

Οι _πραγματικοί_ προγραμματιστές χρησιμοποιούν μόνο κατσαβίδια και κολλητήρια :)

Τετάρτη, 16 Ιουνίου 2010 - 3:42:00 μ.μ. EEST  
Ο χρήστης Blogger stassa είπε...

Κατσαβίδια και κολλητήρια; Χα! Στον καιρό μου έπρεπε να βιδώνουμε τις βίδες με τα νύχια και να κάνουμε τις κολλήσεις με σάλιο και μίξα! :P

Τετάρτη, 16 Ιουνίου 2010 - 4:32:00 μ.μ. EEST  
Ο χρήστης Anonymous Ανώνυμος είπε...

Do you mind if I quote a couple of your articles as long as I provide
credit and sources back to your website? My website is in
the very same niche as yours and my users would genuinely benefit from a lot of the information you provide here.
Please let me know if this alright with you. Cheers!

Have a look at my website roulette online

Σάββατο, 23 Μαρτίου 2013 - 6:43:00 μ.μ. EET  

Δημοσίευση σχολίου

Εγγραφή σε Σχόλια ανάρτησης [Atom]

Σύνδεσμοι σε αυτήν την ανάρτηση:

Δημιουργία Συνδέσμου

<< Αρχική σελίδα