ΕΛ/ΛΑΚ | creativecommons.gr | mycontent.ellak.gr |
freedom

Νέα από τον πλανήτη… planet.ellak.gr: Εισαγωγή στην RISC-V: Ο Νίκος Κοσσυφίδης μας μυεί στον κόσμο της νέας ανοικτής αρχιτεκτονικής επεξεργαστών

by: Linux Insider

Μια ομιλία που μας άρεσε πολύ στο πολύ πετυχημένο FOSSCOMM 2018, ήταν του Νίκου Κοσσυφίδη για την RISC-V, την ανοικτή και δωρεάν αρχιτεκτονική για υλοποίηση απλών και λιγότερο ενεργοβόρων επεξεργαστών που θα τρέχουν από μικρούς υπολογιστές μέχρι το cloud. Μια και πρόκειται για κάτι που δεν είναι ευρύτερα γνωστό, και επιπλέον είναι στα σπάργανα ακόμα η υποστήριξη του στο Linux, ζητήσαμε από τον Νίκο να μας απαντήσει σε μερικές ερωτήσεις για να καταλάβουμε περί τίνος πρόκειται αλλά και να διαδώσουμε αυτήν την ανοικτή αρχιτεκτονική. Προτείνουμε να διαβάσετε και να μοιραστείτε το κείμενο ακόμα και αν δεν σας απασχολούν οι μικροεπεξεργαστές, από τις απαντήσεις του Nick μαθαίνεις πολλά πράγματα για το πως λειτουργούν στην καρδιά τους οι υπολογιστές μας. Και που ξέρεις, ίσως κάποιοι/ες από εσάς να αποφασίσουν να σηκώσουν τα μανίκια και να παίξουν με το RISC-V...

LI: Νίκο, κατ’ αρχάς πες μας δυο λόγια για το τι είναι αυτό το RISC-V. Κι αν θες, μια και μας διαβάζουν νεοφώτιστοι, να μας έκανες ταληράκια τι σημαίνει αυτό το ISA που άκουσα πολύ στην παρουσίασή σου στο FOSSCOMM.

NK: Κάθε επεξεργαστής έχει ένα μοντέλο λειτουργίας, που περιλαμβάνει τις διάφορες εντολές που καταλαβαίνει (την assembly του αν θες), τους τύπους δεδομένων που χειρίζεται (ακέραιους, δεκαδικούς, doubles, vectors κλπ), τους καταχωρητές του και τι κάνει ο καθένας τους, το μοντέλο πρόσβασης στη μνήμη, το χειρισμό των interrupts (π.χ. των timers) και των traps (π.χ. πως αναφέρει ένα segfault ή μια λανθασμένη εντολή) και άλλα πολλά. Αυτό το μοντέλο λειτουργίας το λέμε αρχιτεκτονική συνόλου εντολών ή Instruction Set Architecture (ISA). Όταν λέμε πως το σύστημά μας είναι x86, amd64, arm64, mips, powerpc κλπ, στην ουσία λέμε πως ο επεξεργαστής στο οποίο τρέχουμε ακολουθεί το αντίστοιχο μοντέλο λειτουργίας.

Το  RISC-V είναι ένα τέτοιο μοντέλο λειτουργίας, αφορά -για την ώρα- επεξεργαστές 32 και 64bit που μπορούν να είναι είτε ειδικού σκοπού (βλ. μικροελεγκτές στυλ Arduino) είτε γενικής χρήσης όπως οι επεξεργαστές που έχουμε στους υπολογιστές και τα smartphones μας. Λέω για την ώρα γιατί υπάρχει και πλάνο για 128bit αλλά αυτό είναι μια άλλη ιστορία.

 

LI: Αρα, δεν μιλάμε για ένα μόνο chip αλλά για ένα “πρότυπο” με βάση το οποίο μπορούν να σχεδιαστούν και να κατασκευαστούν πολλοί επεξεργαστές για διάφορες χρήσεις και συσκευές, σωστά;

NK: Σωστά, σκέψου το σαν την περιγραφή ενός επεξεργαστή, βάση της οποίας γίνεται η υλοποίηση του hardware. Το κείμενο που θα δώσουμε στο μηχανικό για να τον φτιαξει. Για παράδειγμα οι AMD και οι Intel επεξεργαστές που έχουμε συνήθως στους υπολογιστές μας ακολουθούν την ίδια αρχιτεκτονική (x86_64, επίσης γνωστή ως amd64) αλλά ως υλοποιήσεις διαφέρουν σημαντικά. Ομοίως και τα κινητά τηλέφωνα π.χ. έχουν συνήθως επεξεργαστές που ακολουθούν την αρχιτεκτονική arm64 αλλά ως υλοποιήσεις διαφέρουν αρκετά μεταξύ κατασκευαστών (π.χ. mediatek, huawei, samsung, qualcomm, apple κλπ). Έτσι όταν τρέχουμε android π.χ. στο κινητό μας, δεν έχει σημασία η υλοποίηση του κατασκευαστή αλλά ότι ο επεξεργαστής του ακολουθεί την αρχιτεκτονική arm64, ομοίως και στον υπολογιστή μας, όταν τρέχουμε π.χ. Debian για amd64 δεν έχει σημασία για τα προγράμματα  αν τα τρέχουμε σε Intel ή σε AMD επεξεργαστή.

 

LI: Από που προέρχεται αυτή η αρχιτεκτονική; Το -V σημαίνει ότι υπήρξαν κι άλλα 4 iterations πιο πριν ή κάνω λάθος;

NK: Παλιά που η μνήμη ήταν πολύ ακριβή και οι compilers δεν ήταν τόσο ώριμοι (οπότε δεν μπορούσαν να μεταφράσουν τόσο αποδοτικά τον κώδικα σε assembly), οι επεξεργαστές σχεδιάζονταν στη λογική να κάνουν όλη τη δουλειά στο hardware, κάνοντας πιο απλό και φθηνό για τους προγραμματιστές (και τους compilers) να γράφουν assembly γιατί έκαναν τη δουλειά τους σε μερικές εντολές. Τα μοντέλα λειτουργίας που βασίζονται σε αυτή τη λογική τα λέμε Complex Instruction Sets ή CISC. Στον αντίποδα αυτής της λογικής, οι επεξεργαστές υλοποιούν λίγες απλές εντολές τις οποίες και εκτελούν συνήθως σε ένα κύκλο του ρολογιού, και το software αναλαμβάνει με αυτές τις βασικές εντολές να “χτίσει” όλα τα υπόλοιπα. Από εκεί βγαίνει το RISC που σημαίνει Reduced Instruction Set CPU και μια πρώτη υλοποίηση έγινε από το πανεπιστήμιο του Berkeley και τον κο. Μ. Κατεβαίνη, του οποίου την ομιλία είχαμε την τύχη να παρακολουθήσουμε στο φετινό FOSSCOMM, όπου και μας παρουσίασε την όλη ιστορία του εγχειρήματος. Μετά τον πρώτο RISC που σχεδιάστηκε σε χρόνο ρεκόρ, ήρθε ο RISC-II (1981) βάσει του οποίου υλοποιήθηκαν οι SPARC επεξεργαστές της Sun. Μετέπειτα ερευνητικές προσπάθειες στο Berkeley, γνωστές ως SOAR (1984) και SPUR (1988), θεωρούνται η συνέχεια του RISC και ονομάστηκαν αργότερα RISC-III και RISC-IV αντίστοιχα. Το 2011 μετά από αρκετές αρχιτεκτονικές που ακολούθησαν το μοντέλο του RISC, το Berkeley και η ομάδα του επανήλθαν με τον RISC-V.

Ενδιαφέρον κείμενο για την γενεολογία των RISC εδώ

LI: Γιατί είναι τόσο σημαντική αυτή η αρχιτεκτονική σε σχέση με τις υπάρχουσες, π.χ. με την x86 κλπ;

NK: Η ιστορία έδειξε πως η προσέγγιση των RISC ήταν πιο σωστή, στην εποχή του ο RISC-II αποδείχθηκε πολύ γρηγορότερος απ’ τους υπόλοιπους επεξεργαστές, “ρίχνοντας” στον VAX και στον M68K κάτι της τάξης του 200% σε ορισμένες λειτουργίες ! Μετέπειτα επεξεργαστές επηρεάστηκαν αρκετά από τις ιδέες των RISC και πλέον οι περισσότερες αρχιτεκτονικές που έχουν επιβιώσει είναι RISC. Παραδείγματα όπως οι ARM (Advanced RISC Machine) που έχουμε στα smartphones μας και τα περισσότερα SBC και περιφερειακά μας, οι MIPS που έχουμε σε αρκετούς Routers, οι Power που έχουμε σε HPC συστήματα (και μέχρι πριν μερικά χρόνια στα Macbooks), καθώς και μερικοί υπερ-υπολογιστές που έχουν παρελάσει κατά καιρούς απ’ την κορυφή της κατηγορίας τους, επιβεβαιώνουν τον κανόνα (ρίξτε μια ματιά εδώ).Τρανταχτή εξαίρεση σε αυτό το κανόνα είναι οι x86/x86_64,  δηλαδή οι επεξεργαστές που χρησιμοποιούμε κατά κόρον στους υπολογιστές μας, και ο λόγος είναι πως η συγκεκριμένη αρχιτεκτονική είναι του 1978 (καλά διάβασες) και εξ’ αιτίας της δημοφιλίας της και της ποσότητας του software που έχει γραφτεί γι’ αυτή, κρατιέται ζωντανή με νύχια και με δόντια μέχρι σήμερα.

 

Η πλάκα είναι πως η Intel δεν περίμενε αυτή την επιτυχία ήταν βασικά θέμα τύχης, θα μπορούσε την τύχη του x86 να την είχε ο Z80 ή κάποιος άλλος επεξεργαστής της εποχής αλλά η επιλογή της IBM να βάλει Intel επεξεργαστές στα PC ήταν το καθοριστικό σημείο. Η Intel έχει προσπαθήσει να λανσάρει καινούριες αρχιτεκτονικές όπως ο Itanium για να αντικαταστήσει τον x86 και ακόμα και αυτή δεν τα κατάφερε ! Εν το μεταξύ τόσο η Intel όσο και η AMD έχουν “απογειώσει” τις υλοποιησεις τους σε βαθμό που η αρχιτεκτονική να μας είναι πλέον σε μεγάλο βαθμό αδιάφορη. Mε απλά λόγια ακόμα και με μια πολύπλοκη αρχιτεκτονική με εκατοντάδες εντολές και πάμπολα “μπαλώματα” όλα αυτά τα χρόνια ύπαρξής της, οι σύγχρονες υλοποιήσεις των επεξεργαστών της Intel και της AMD είναι τόσο εξελιγμένες σε όλους τους υπόλοιπους τομείς, που σε συνδυασμό και με τους σύγχρονους compilers και λογισμικό, ξεχνάμε τι γίνεται “από κάτω”. Ενδιαφέρον επίσης έχει το γεγονός πως εσωτερικά οι x86 τρέχουν microcode, τα πολύπλοκα δηλαδή assembly instructions του x86/x86_64 ISA μεταφράζονται απ’ τον επεξεργαστή σε μικρές απλές εντολές on-the-fly και τρέχουν έτσι εσωτερικά, είναι δηλαδή στο εσωτερικό τους RISC !

Αυτό που δεν μπορούμε να ξεχάσουμε όμως είναι η απόδοσή τους. Μαζί με τη πολυπλοκότητα έρχεται και η αυξημένη κατανάλωση σε ενέργεια και μπορεί αυτό να μη μας πολυενδιαφέρει για την ώρα στους προσωπικούς μας υπολογιστές, αλλά μας ενδιαφέρει ιδιαίτερα τόσο σε smartphones και συσκευές που έχουν πολύ ιδιαίτερες ανάγκες σε ενέργεια (βλ. IoT), όσο και σε μεγάλα data centers και High Performance Computing (HPC) clusters, όπου είναι τόσο μεγάλο το πλήθος των επεξεργαστών όπου κάθε milliwatt ανα επεξεργαστή μετράει. Κάποια στιγμή δε θα φτάσουμε στα όρια των υλικών και δε θα μπορούμε να μικρύνουμε και να “πυκνώσουμε” άλλο τους επεξεργαστές, ή να ανεβάσουμε τα ρολόγια τους (θυμήσου πόσο γρήγορα πήγαμε απ’ το 1 στα 3GHz και σε τι συχνότητες δουλεύουμε ακόμα σήμερα). Σε κάθε περίπτωση μια “καθαρή” και απλή αρχιτεκτονική κάνει τη διαφορά σε θέματα απόδοσης, ένα μάθημα που πήρε η Intel όταν πήγε να μπει στην αγορά των κινητών τηλεφώνων και δεν τα κατάφερε.

 

Πέρα από τη γενική σύγκριση CISC vs RISC (που θυμίζει λίγο KDE vs Gnome κλπ) ή την θεωρητικά καλύτερη απόδοση των  RISC επεξεργαστών, το “ζουμί” είναι αλλού. Η αρχιτεκτονική RISC-V είναι σύγχρονη, ανοιχτή αρχιτεκτονική, φτιαγμένη σε πολύ καλή βάση από ένα δυνατό group μηχανικών. Στη διαμόρφωσή της συμμετέχουν μερικές απ’ τις μεγαλύτερες εταιρείες του χώρου και μερικά απ’ τα σημαντικότερα Πανεπιστήμια/ερευνητικά κέντρα στο κόσμο (και για να ευλογήσω και τα γένια μας, το ΙΤΕ συμμετέχει και αυτό στην τεχνική επιτροπή και μάλιστα ενεργά). Υπήρξαν και άλλες ανοιχτές αρχιτεκτονικές στο παρελθόν (π.χ. OpenRISC, SPARC) αλλά το timing στη περίπτωση του RISC-V και η δυναμική που έχει αναπτυχθεί είναι κάτι καινούργιο και συναρπαστικό ! Μπορεί ο καθένας να συμμετάσχει στην τεχνική επιτροπή και ουσιαστικά πρόκειται για ένα σχετικά μεγάλο open source project με αρκετά sub-projects που αφορούν τόσο τμήματα του hardware όσο και υποστήριξη του software, δημιουργία εργαλείων κλπ. Αν όλα πάνε καλά μιλάμε για το Linux των αρχιτεκτονικών ! Μπορεί ο κάθε κατασκευαστής να χρησιμοποιήσει την αρχιτεκτονική στα chip του χωρίς κόστος για άδειες χρήσης (royalty free), ενώ η αρχιτεκτονική προβλέπει και την δημιουργία επεκτάσεων (στο ISA δηλαδή ορίζεται η μέθοδος για να προσθέσει κάποιος επεκτάσεις σύμφωνα “με το νόμο” και όχι ως hackιά), οπότε μπορείς να έχεις έναν επεξεργαστή που να είναι RISC-V αλλά να κάνει π.χ. και DSP ή κάποια άλλη custom/vendor-specific λειτουργία, κάτι ασυνήθιστο στις υπάρχουσες αρχιτεκτονικές που είναι κλειστές και “κλειδωμένες” απ’ τους δημιουργούς τους. Σκέψου π.χ. να θες να στήσεις ένα chip για router και να θες να κάνεις crypto acceleration ή network acceleration και να μη χρειάζεται να χρησιμοποιήσεις extra chipάκι, ή να θες να κάνεις video decoding και αντι να βάζεις από δίπλα ολόκληρη GPU να βάζεις στη CPU το κομμάτι που σε ενδιαφέρει. Αντίστοιχα μπορείς να χρησιμοποιήσεις ποιο light εκδόσεις του επεξεργαστή, όπου κάποιες βαριές επεκτάσεις, που δε χρειάζονται για τη δουλειά που τον θές, μπορείς να τις βγάλεις, επιτυγχάνοντας έτσι μικρότερη πολυπλοκότητα, κατανάλωση σε ρεύμα κλπ.

Για την ακρίβεια και το ίδιο το ISA ορίζεται πρακτικά ως ένα set από standard επεκτάσεις, ξεκινώντας απ’ τη βασική επέκταση RV32/RV64/RV128I για ακέραιους και “χτίζοντας” εκεί πάνω. Η διαφορά είναι πως εκεί οι κανόνες είναι συγκεκριμένοι και ορίζονται απ’ την τεχνική επιτροπή, αλλιώς θα έκανε ο καθένας ότι να ‘ναι και θα έλεγε πως είναι RISC-V, κάπου πρέπει να υπάρχει standardization. Εξ’ άλλου και στο Linux, commit access έχουν πολύ λίγοι, οι developers στέλνουν τις αλλαγές τους σε mailing lists και από εκεί καταλήγουν μετά από review στον πυρήνα, κάπως έτσι δουλεύει και το RISC-V με την τεχνική επιτροπή και το RISC-V foundation να είναι ουσιαστικά οι θεματοφύλακες του ISA. Για περισσότερες πληροφορίες δες https://riscv.org/.

Αυτή η ιδέα του modularity που εισάγει η αρχιτεκτονική RISC-V θεωρώ πως έχει πολύ μέλλον. Θα βρει δε εφαρμογή σε πολύ μεγάλη γκάμα υλοποιήσεων/εφαρμογών, από κινητά και HTPC/set top boxes, μέχρι router/firewall appliances, automotive, HPC systems  κλπ.

 

Ποιες είναι οι επεκτάσεις του RISC-V;

NK: Οι standard επεκτάσεις που έχουμε μέχρι στιγμής είναι:

  • I(ntegers):  Βασικές πράξεις με ακέραιους (βλ. and/or/xor/add/sub/load/store κλπ) και control flow (jumps κλπ)
  • Μ(ultiplication):  Πολλαπλασιασμός και διαίρεση (που θεωρείται πολλαπλασιασμός με κλάσμα, γι’ αυτό δε φαίνεται στο όνομα) για ακέραιους
  • A(tomics): Διαδικασίες που αφορούν εντολές load/store στη μνήμη κατά τρόπο που να είναι “σύγχρονες” μεταξύ των διαφορετικών πυρήνων/threads (να γίνονται “με τη μία”).
  • F(loats): Πράξεις με δεκαδικούς 32bit - single precision (add/sub/multiply/divide/compare κλπ)
  • D(ouble): Πράξεις με δεκαδικούς 64bit - double precision
  • Q(uad): Πράξεις με δεκαδικούς 128bit - quad precision
  • C(ompressed): Υποστήριξη για “συντομεύσεις” εντολών με σκοπό την ελάττωση του μεγέθους παραγόμενου κώδικα (αντί να γράφουμε όλη την εντολή, γράφουμε μια πιο συμπτυγμένη -16bit- εκδοχή της -με κάποιες συμβάσεις όπως το ποιοι καταχωρητές χρησιμοποιούνται-).

Οι standard επεκτάσεις που είναι υπό συζήτηση/ανάπτυξη αφορούν λειτουργίες που θα βρείτε στους περισσότερους επεξεργαστές όπως bit manipulation (B) και vectors (V), πιο ενδιαφέρουσες ιδέες όπως acceleration των JIT γλωσσών (J) και αρκετές ακόμα.

Για να τρέξει ένας επεξεργαστής ένα πλήρες λειτουργικό χρειάζεται να υλοποιεί κατ’ ελάχιστον τις επεκτάσεις IMAFD, καθώς και το privilege spec, όπου ορίζει τον διαχωρισμό των διαφόρων επιπέδων προστασίας στον επεξεργαστή, τη διαχείριση της εικονικής μνήμης κλπ, για το οποίο είχαμε επίσης μια ομιλία στο FOSSCOMM 2018 απ’ τον Νίκο Παπαδόπουλο. Το σετ αυτό το λέμε πιο σύντομα G(eneric), οπότε αν δείτε έναν επεξεργαστή να λέει πως είναι rv64gc π.χ. σημαίνει πως υλοποιεί τις επεκτάσεις IMAFDC.

Αν όμως κάποιος δε θέλει έναν επεξεργαστή που να τρέχει Linux αλλά κάτι σαν το Arduino μπορεί να φτιάξει ένα RISC-V  που να είναι RV32I π.χ., ή μπορεί να θέλει να παίζει με ακέραιους αλλά με 64bit ακρίβεια και τίποτε άλλο οπότε θα φτιάξει ένα RV64I, ή μπορεί να θέλει ένα βασικό RV32I που να έχει όμως και πάνω κάποια δικά του vendor-specific extensions. Με αυτή την ιστορία με τις επεκτάσεις το παιχνίδια αλλάζει αρκετά. Σκέψου πως θα έχουν όλοι αυτοί τον ίδιο compiler π.χ., τα ίδια εργαλεία ανάπτυξης και debugging κλπ. Γεννιέται ένα οικοσύστημα για τους hardware developers το οποίο μέχρι τώρα δεν είχαν καν φανταστεί !

Το HiFive Unleashed είναι RISC-V development board για Linux με το 64μπιτο FU540
Το HiFive Unleashed είναι RISC-V development board για Linux με το 64μπιτο FU540 και 8GB DDR4 ECC. Κοστίζει κάπως ακριβά βέβαια...

LI: Ωραία όλα αυτά, αλλά τι σημαίνει για τους τελικούς χρήστες υπολογιστών το γεγονός ότι η RISC-V είναι “ανοικτή”;  Γνωρίζοντας τα security θέματα που μας τάραξαν σε x86 επεξεργαστές (Meltdown and Spectre), θα μπορούσε μια open architecture να αποφύγει τέτοια προβλήματα;

NK: Όσοι περισσότεροι ασχολούνται με την ανάπτυξη της αρχιτεκτονικής και όσο πιο ανοιχτή είναι η διαδικασία διαμόρφωσής της, τόσο περισσότερο peer review γίνεται, και κατά συνέπεια η πιθανότητα να βρουμε κάποιο bug είναι μεγαλύτερη. Αν και η ίδια η αρχιτεκτονική έχει προβλέψεις για security features όπως το Physical Memory Protection (PMP), privilege modes κλπ, το μεγαλύτερο βάρος ή “παγίδα” αν θες είναι στην υλοποίηση. Το spectre και το meltdown π.χ. δεν είναι θέμα της αρχιτεκτονικής αλλά της υλοποίησης, γι αυτό π.χ. οι επεξεργαστές της AMD δεν επηρεάζονται απ’ το meltdown σε αντίθεση με αυτούς της Intel. Η αρχιτεκτονική σου λέει με ποιες εντολές π.χ. θα γράφεις και θα διαβάζεις τη μνήμη και ποιο θα είναι το μοντέλο πρόσβασης γενικότερα. Δε σου λέει πώς θα το υλοποιήσεις, το αν θα έχεις cache π.χ. ή όχι ή το αν θα κάνεις out of order execution / speculation / branch prediction κλπ. Όλα αυτά που όπως είπα παραπάνω “απογείωσαν” τις υλοποιήσεις των x86/amd64 δεν ορίζονται στην αρχιτεκτονική.

Όσον αφορά το RISC-V, στο θέμα της ασφάλειας έχει δοθεί ιδιαίτερη σημασία και μπορώ να στο πω και από πρώτο χέρι καθότι συμμετέχω ενεργά στη συγκεκριμένη ομάδα, και ειδικότερα στην ομάδα που ασχολείται με το Trusted Execution Environment. Δεν μπορώ να πω λεπτομέρειες για την ώρα (θα έχω μια σχετική ομιλία στη FOSDEM φέτος)  αλλά μπορώ να πω πως γίνεται σοβαρή δουλειά, υπάρχει πολύ καλό κλίμα, και πως πολύ συχνά έχουμε meetings στα οποία καλούμε και ερευνητές του χώρου για brainstorming. Μέλη της ομάδας που βρήκαν το Spectre και το Meltdown π.χ. συμμετέχουν και αυτοί στην όλη προσπάθεια και έχουν γίνει αρκετές προτάσεις για το πώς να προστατευτούμε σε επίπεδο αρχιτεκτονικής από αντίστοιχα προβλήματα.  Όταν το project είναι ανοιχτό, όπως συμβαίνει σε αυτή τη περίπτωση, έχει και κίνητρο ο κόσμος να συμβάλει, δεν μπαίνει στη μέση ο ανταγωνισμός για το κέρδος κλπ, όλοι έχουν συμφέρον να το βελτιώσουν γιατί στο τέλος οι ίδιοι είναι που θα το χρησιμοποιήσουν. Σε κάποια φάση π.χ. βρέθηκε σε επίπεδο αρχιτεκτονικής ένα πρόβλημα με το memory model από μερικούς expert του είδους απ’ το Princeton, ε μπήκε στην τεχνική επιτροπή ένας από αυτούς και το έφτιαξε ο ίδιος!

Η ποιότητα της δουλειάς που γίνεται, είναι αξιοσημείωτη και στους υπόλοιπους τομείς, αυτό οφείλεται κυρίως κατά τη γνώμη μου στην ομάδα του Berkeley που σχεδίασαν την αρχιτεκτονική και είναι πάντοτε παρόντες, “τραβάνε κουπί” και προτείνουν λύσεις. Είναι σαν τον Linus στο Linux. Εκτός δε από την αρχική ομάδα, υπάρχουν όπως σου είπα στην τεχνική επιτροπή αρκετοί μηχανικοί από διαφορετικές εταιρείες και ιδρύματα, με διαφορετικό background και εξειδίκευση, που καλύπτουν τεράστιο φάσμα τόσο σε επίπεδο εμπειρίας και γνώσης, όσο και σε επίπεδο ιδεών. Δε θα μπορούσε να γίνει κάτι τέτοιο αν η αρχιτεκτονική σχεδιαζόταν από μια εταιρία, δε θα είχες π.χ. τους ανθρώπους της Google που ασχολούνται με το AI μαζί με τους ανθρώπους της Nvidia που φτιάχνουν π.χ. Cuda cores, τους τεχνικούς της Samsung, της Qualcomm, της Micron, της Western digital κλπ, και από δίπλα από αυτούς άλλα τόσα πανεπιστήμια και ερευνητικά κέντρα. Είναι μεγάλη υπόθεση να δουλεύουμε όλοι παρέα και να φέρνει ο καθένας κάτι στο τραπέζι. Για να πάρεις μια ιδέα, δες εδώ: https://riscv.org/members-at-a-glance/. Θεωρώ πως το αποτέλεσμα θα είναι πολύ καλύτερο απ’ ότι έχουμε δει μέχρι σήμερα και νομίζω το ίδιο πιστεύουν όλοι όσοι συμμετέχουν στη προσπάθεια.

 

Τα μέλη του RISC-V, και αυξάνονται συνεχώς! (φωτό Nick Kossifidis)

 

LI: Θα είναι το κόστος ένα ακόμα συγκριτικό πλεονέκτημα για τους τελικούς καταναλωτές; Θέλω να πω, με δεδομένο ότι η RISC-V είναι open source architecture, δεν θα είναι μικρότερο το κόστος ανάπτυξης ενός νέου επεξεργαστή π.χ. για μια εξειδικευμένη δουλειά;

NK: Η διαφορά κόστους θα είναι σημαντική ! Για να έχεις εικόνα, αν θέλει κάποιος σήμερα να φτιάξει ένα SoC π.χ. για κινητά, για να βάλει μέσα έναν επεξεργαστή ARM π.χ. πρέπει να πληρώσει κάμποσα (δεκάδες) εκατομμύρια για την άδεια χρήσης της αρχιτεκτονικής. Εδώ το κόστος για τη χρήση της αρχιτεκτονικής (με τη προϋπόθεση να ακολουθεί κάποιος σωστά το  ISA και να μη κάνει του κεφαλιού του) είναι τίποτα ! Ποιο “καραμπινάτο” παράδειγμα είναι αν κάποιος θέλει να φτιάξει έναν επεξεργαστή που να υλοποιεί το x86_64 πρέπει να πληρώσει μερικές δεκάδες εκατομμύρια και στην Intel (για το x86 κομμάτι) και στην AMD (για το amd64 κομμάτι), που είναι και ο λόγος που δεν το κάνει κανείς ! Πριν π.χ. που είχαμε μόνο το x86 και πλήρωναν μόνο την Intel υπήρχε και η Via και η Transmeta και άλλες εταιρίες που έφτιαχναν x86. Πλέον δεν συμφέρει κανέναν και έχουμε το δίπολο Intel - AMD απ’ το οποίο και εξαρτάται μια ολόκληρη αγορά ! Είναι ουσιαστικά ολιγοπώλιο και δε συμφέρει κανένα μας. Με το RISC-V που είναι ανοιχτή αρχιτεκτονική δεν κινδυνεύουμε από κάτι τέτοιο. Αυτή την υπεροχή του RISC-V πρόσφατα την κατάλαβε τόσο η ARM όπου έβγαλε τους Cortex-M με δωρεάν license , όσο και η MIPS που έγινε open source, άργησαν όμως θεωρώ και υστερούν σημαντικά σε δυναμική και ενδιαφέρον.

LI: Για να κάνω το δικηγόρο του διαβόλου, είναι η RISC-V πανάκεια; Με βάση το γεγονός ότι η αρχιτεκτονική είναι BSD licensed, δεν θα μπορούσαμε να έχουμε πάλι παρόμοια security προβλήματα; Π.χ. μπορεί μια εταιρεία να φτιάξει ένα προϊόν RISC-V στα μέτρα της και κρατήσει “κρυφά” κάποια κομμάτια της υλοποίησης όπου και πάλι δεν θα ξέρουμε τι γίνεται εκεί και τι πιθανά προβλήματα υπάρχουν;

NK: Απ’ τη στιγμή που υλοποιείς το spec και όποια standard extensions θες, μπορείς να κάνεις ότι θες από εκεί και πέρα, να βάλεις δικά σου extensions, να κάνεις διάφορα tweaks σε επίπεδο υλοποίησης κλπ. Ο μόνος περιορισμός είναι να ακολουθείς το spec, δεν σε υποχρεώνει κανείς να βγάλεις την υλοποίησή σου open ή τα custom extensions σου. Απλά θα πρέπει να αναλάβεις και το κόστος συντήρησης του αντίστοιχου software, συμπεριλαμβανομένου και του firmware αν κάνεις κάτι που δεν υποστηρίζεται απ’ το υπάρχον stack. Κατά συνέπεια φυσικά και θα υπάρξουν διάφοροι που θα κάνουν τα δικά τους και φυσικά και θα γίνουν και λάθη όπως γίνονται και τώρα, όπως και καινούργιες ιδέες προς το καλύτερο. Δεν υπάρχει τίποτα που να είναι bug free και αν κάποιος μηχανικός ισχυριστεί το αντίθετο, μάλλον ζει σε κάποιο παράλληλο σύμπαν. Αυτό που μπορούμε να πούμε είναι πως σε επίπεδο spec και recommendations θα κάνουμε το καλύτερο που μπορούμε για να προλάβουμε τέτοια λάθη και να τα μαζέψουμε, βασισμένοι ο καθένας/μία στην εμπειρία μας και κρατώντας το spec όσο πιο απλό και καθαρό γίνεται. Προφανώς ο καθένας είναι υπεύθυνος/η για την υλοποίησή του/της από εκεί και πέρα.

 

LI: Υπάρχουν υλοποιήσεις RISC-V αυτή τη στιγμή ή μιλάμε για επεξεργαστές που θα  κυκλοφορήσουν στο... μέλλον κάποια στιγμή; Μπορεί π.χ. στο άμεσο μέλλον να δούμε τέτοια chips και στους home υπολογιστές μας;  

NK: Αν χρησιμοποιείς κάρτες γραφικών της NVIDIA έχεις ήδη ένα RISC-V microcontroller μέσα στη GPU σου, ομοίως αν χρησιμοποιείς σκληρούς δίσκους της Western Digital, ενώ απ’ το Pixel 2 και μετά η Google έχει ένα RISC-V core στο Visual core της. Γενικά παίζουν ήδη αρκετά chipάκια εκεί έξω που ήδη είναι βασισμένα στο RISC-V και αναμένονται και άλλα. Μπορείς να δεις μια λίστα με τα γνωστά open/closed cores εδώ ενώ μπορείς και να “σχεδιάσεις” και cores βασισμένα στα designs της SiFive απ’ το site τους (και στο μέλλον θα μπορείς και να παραγγείλεις από αυτούς έτοιμο SoC σε ASIC το οποίο είναι επαναστατικό θεωρώ): https://www.sifive.com/core-designer .

Linux desktop on RISC-V ! (φωτό Nick Kossifidis)

 

LI: Υπάρχει στην αγορά καποιο developer board για να το πάρει κάποιος που ενδιαφέρεται και να παίξει μαζί του; Αν ναι, τι κόστος έχει;

NK: Αν θες να παίξεις με ένα Linux-capable board το HiFive Unleashed για την ώρα είναι το μόνο που παίζει και στο ΙΤΕ είχαμε την τύχη να πάρουμε ένα απ’ τα πρώτα 200. Αναμένεται να βγουν και άλλα, ενώ αναμένεται και καινούριο SoC απ’ την εταιρία που το κατασκευάζει, που θα είναι και γρηγορότερο (ακόμα όμως μιλάμε για in-order επεξεργαστές, οπότε μην περιμένεις κάτι τρελό, θα ανταγωνίζεται τον ARMv8 A55 περίπου, που βέβαια αν σκεφτείς σε πόσο καιρό έφτασε ο RISC-V εκεί, θα διαπιστώσεις πως είναι σοβαρό κατόρθωμα).

Αν θες να παίξεις με κάτι arduino like υπάρχουν διάφορα boardάκια. Απ’ το VEGA board (open-isa.org) και το GAPUino, μέχρι και FPGA based όπως τα boardάκια της Microsemi. Είχαμε την τύχη στο FOSSCOMM 2018 να μοιράσουμε μερικά από αυτά σε κόσμο και περιμένουμε να δούμε projectάκια. Τέλος ένα ωραίο board για τους κάπως πιο μυημένους είναι το Avalanche από την Future Electronics το οποίο είναι όλο FPGA-based (δλδ δεν έχει core επάνω, του περνάς εσύ ένα softcore στην FPGA). Το χαρακτηριστικό του είναι πως στη τιμή που το παίρνεις σου δίνει 300kluts που είναι αρκετός χώρος για να στήσεις ακόμα και Linux-capable core επάνω. Στο RISC-V Summit πριν καμια βδομάδα είχαμε την τύχη να δούμε μια σχετική παρουσίαση.

To Avalanche board δίνει 300kluts για 180$ (φωτό: Nick Kossifidis)

 

LI: Σε τι φάση βρίσκεται αυτή τη στιγμή η υποστήριξη της RISC-V από τον πυρήνα Linux; Από ότι κατάλαβα στην παρουσίαση είμαστε σε σχεδόν εμβρυικό στάδιο, σωστά;

NK: Είναι μοναδική ευκαιρία για όποιον/α θέλει να συμμετέχει στην ανάπτυξη του πυρήνα για RISC-V ! Δεν είναι κάθε μέρα που μια καινούρια αρχιτεκτονική μπαίνει στον πυρήνα και μάλιστα με τόσα πολλά ενδιαφέροντα features. Υπάρχουν πολλά ανοιχτά θέματα που έχουμε να λύσουμε, τόσο σε επίπεδο βασικών λειτουργιών και frameworks στον πυρήνα, όσο και σε επίπεδο drivers για τα διάφορα board που φτιάχνονται.  Γενικά δουλεύουν αρκετά πράγματα, τα περισσότερα features που λείπουν δεν είναι και πολύ ορατά στον τελικό χρήστη, πέρα απ’ το performance. Πιο εμφανές είναι π.χ. που δεν έχουμε ακόμα πλήρες support για τον LLVM ή για Java/JavaScript -είναι όλο σε software και ο browser σέρνεται- για τον τελικό χρήστη, παρά τα διάφορα “κόλπα” που γίνονται στον πυρήνα όπως τα hugepages ή το μοντέλο διάσπαρτης μνήμης (sparsemem). Οι προγραμματιστές απ’ την άλλη θα έχουν διάφορα θέματα, ειδικά αν κάνουν δουλειά στον πυρήνα, όπου θα διαπιστώσουν πως λείπει το support για πολλά και διάφορα features.

 

LI: Πόσο χρόνο πιστεύεις θα χρειαστεί για να φτάσουμε στο σημείο υποστήριξης που βρίσκεται η x86 στο Linux; Μήνες, χρόνια; Υπάρχει κάποιο ορόσημο που χρειάζεται να φτάσουμε για να πούμε ότι “ΟΚ, αυτό τρέχει καλά πλέον ακόμα και για απλούς χρήστες”;

NK: Αν κρίνω απ’ το πόσο καιρό έχει πάρει στον ARM και τον ARM64 να φτάσουν στο σημείο που βρίσκονται σήμερα θα έλεγα περίπου στο μισό χρόνο, καθότι σε μεγάλο βαθμό παίρνουμε αρκετά πράγματα έτοιμα, και το οικοσύστημα στον πυρήνα για την εισαγωγή νέων αρχιτεκτονικών και συστημάτων έχει βελτιωθεί πολύ. Η εκτίμησή μου είναι πως με τους ρυθμούς που πάμε τώρα στα επόμενα 4-5 χρόνια θα είμαστε σε πολύ καλό επίπεδο.

 

LI: Τι χρειάζεται να ξέρει κανείς για να ασχοληθεί με το θέμα “RISC-V στο Linux“ και ποιες ειναι οι προοπτικές του μετά;.

NK: Σαν χρήστης μπορεί να αρχίσει να πειραματίζεται με τις διάφορες διανομές για την ώρα και να βοηθήσει με το testing και το bug reporting. Δεν χρειάζεται να ξέρεις πολλά γι’ αυτό, ούτε να έχεις και κάποιο board, μπορείς π.χ. με τον QEMU πλέον να τρέξεις ένα κανονικό RISC-V περιβάλλον, να δοκιμάσεις να δεις πώς συμπεριφέρονται τα διάφορα προγράμματα που σε ενδιαφέρουν και να το αναφέρεις στους προγραμματιστές ή στους package maintainers της διανομής σου. Μια προσπάθεια έχει ξεκινήσει στο https://riscv.ics.forth.gr (το οποίο κάποια στιγμή ενδεχομένως να μεταφερθεί στο wiki.kernel.org), όπου μπορούν τόσο οι χρήστες όσο και οι προγραμματιστές να βρουν πληροφορίες για να ξεκινήσουν να παίζουν, φυσικά έχει ακόμα πολύ περιθώριο βελτίωσης. Ο καθένας/μια μπορεί να βοηθήσει όπως μπορεί, και μόνο να παίξετε και να βοηθήσετε άλλους να παίξουν είναι σημαντικό ! Στην αρχή θα χρειαστεί αρκετό ψάξιμο / διάβασμα και είναι λογικό, είναι κάτι καινούριο για όλους μας. Τα οφέλη όμως θεωρώ πως θα είναι σημαντικά, τόσο σε επίπεδο γνώσεων και χαβαλέ, όσο και σε επαγγελματικό επίπεδο, γενικά το “ταξίδι” δε θα σας απογοητεύσει πιστεύω. Πρόσφατα ανέβασα και κάποια scriptάκια που ενδεχομένως να βοηθίσουν κάποιον/α που ξεκινάει, βλ. https://github.com/mickflemm/yarvt .

 

LI: Τέλος, ποια κομμάτια της υποστήριξης RISC-V από το Linux είναι αυτά που θα πρότεινες σε κάποιον να κοιτάξει πρώτα; Π.χ. υπάρχει κάποιο σημείο που είναι πιο critical και υπάρχει άμεση ανάγκη;

NK: Δύσκολη ερώτηση, οι ανάγκες που έχουμε είναι σε διάφορα σημεία και ο καθένας/μια το βλέπει απ’ τη δικιά του σκοπιά. Προσωπικά με ενδιαφέρει π.χ. το memory hot-plugging και το kexec support, άλλον τον ενδιαφέρει το 32bit support γιατί υλοποιεί 32bit cores, άλλον το FPU emulation ή το setup χωρίς MMU γιατί παίζει σε περισσότερο embedded περιβάλλοντα, άλλον οι drivers για κάποιο απ’ τα υπάρχοντα boards κλπ. Έχουμε πολλά ανοιχτά προβλήματα που τρέχουν οπότε θα έλεγα ξεκίνα με αυτό που σε ενδιαφέρει περισσότερο, στο wiki (βλ. παραπάνω) έχουμε μια λίστα που κατά καιρούς θα ανανεώνεται αν χρειάζεσαι “έμπνευση”.

Μια άλλη ιδέα είναι να ξεκινήσεις από κάτι απλό που όμως κανείς δε θέλει να πιάσει. Για παράδειγμα πήγα πριν κάποιο καιρό να “στρώσω” λίγο το κομμάτι που αφορά τη γραμμή εντολών του πυρήνα. Ο πυρήνας όπως ίσως ξέρεις μπορεί να πάρει διάφορες παραμέτρους απ’ τον boot loader όπως το root partition (root=...), το init (init=...) κλπ. Στον RISC-V (και στον ARM64 καθώς και σε άλλες αρχιτεκτονικές) τις παραμέτρους αυτές τις παίρνουμε απ’ το device tree (το οποίο μπορεί και να “συμπληρώσει” ο boot loader δυναμικά), ενώ υπάρχει και η δυνατότητα να “καρφώσουμε” αυτές τις παραμέτρους στον πυρήνα όταν τον κάνουμε compile. Ε αν δεις πώς υλοποιείται αυτό το feature θα τραβας τα μαλλιά σου ! Κάθε αρχιτεκτονική κάνει τα δικά της, έχουμε code duplication σε διάφορα σημεία, ενώ ο κοινός κώδικας που υπάρχει για την υλοποίηση των “καρφωτών” παραμέτρων όταν χρησιμοποιούμε device tree έχει ένα bug το οποίο όταν πάμε να το φτιάξουμε “σκάνε” μερικές πλατφόρμες MIPS... Κάθησε λοιπόν κάποιος να μαζέψει το χάος και έστειλε μια σειρά από patches που καθάριζαν τον κώδικα και τον συμμάζευαν αλλά η προσπάθεια δεν προχώρησε. Ο κώδικας είναι πραγματικά πολύ απλός, κάποιος που ξέρει τα βασικά από C μπορεί να τον καταλάβει και να τον διορθώσει, ο λόγος είναι πως θέλει πολύ  χρόνο και υπομονή, είναι αυτό που λέμε “λάτζα” και όλοι βαριόμαστε να τη κάνουμε. Τέτοια όμως προβλήματα “λάτζας” θα έλεγα πως είναι “πεδίο δόξης λαμπρό” για κάποιον που ξεκινάει, είναι πολύ εκπαιδευτικά γιατί πιάνεις ένα πρόβλημα που είναι αρκετά απλό να λυθεί από πλευράς κώδικα αλλά αρκετά δύσκολο να λυθεί σωστά για όλους και πρέπει να αλληλεπιδράσεις με όλους όσους αυτός ο κώδικας επηρεάζει. Μαθαίνεις πολλά στη πορεία, καταλαβαίνεις γιατί ο καθένας ακολούθησε την εκάστοτε προσέγγιση, και βλέπεις πώς σκέφτονται και οι υπόλοιποι, γενικά ανοίγει το μυαλό σου (και όχι απ’ το κοπάνημα του κεφαλιού σου στον τοίχο που δε το γλυτώνεις). Άσε που μετά σε κερνάνε μπύρες στα διάφορα meetings οπότε έχεις επιπλέον κίνητρο!

Δείτε περισσότερα:

RISC-V Specifications: https://riscv.org/specifications/

Διαβάστε ακόμα:

Οι οpen-source επεξεργαστές RISC-V έρχονται!

 

Πηγή άρθρου: https://planet.ellak.gr/    https://www.linuxinsider.gr/

Leave a Comment