Porting ZeOS to RISC-V

id189097   PORTING ZEOS TO RISC-V XAVIER BARRETO TOMEO Director/a JUANJOSÉCOSTAPRATS(Departamentd'ArquitecturadeComputadors) Codirector/a JORDIFORNESDEJUAN(Departamentd'ArquitecturadeComputadors) Titulació GrauenEnginyeriaInformàtica(Tecnologiesdelainformació) Memòria del treball de fi de grau Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech 26/06/2024  2 Resum Aquest projecte elabora un port de ZeOS, un sistema operatiu monol´ıtic originalment desenvolupat per a l’arquitectura Intel 80386, cap a l’arquitectura RISC-V. ZeOS, originalment implementa, funcionalitats de gesti´o de processos, gesti´o de mem`oria, interrupcions i nivells de privilegi. L’arquitectura RISC-V ofereix una flexibilitat, extensibilitat i modularitat significativa, convertint-la en un candidat ideal per a fins educatius i experimentals. Aquest projecte no nom´es contribueix a la comprensi´o i utilitzaci´o de l’arquitectura RISC-V sin´o que tamb´e potencia els recursos educatius disponibles per als estudiants que estudien sistemes operatius a la FIB. L’`exit del port de ZeOS a RISC-V podria aplanar el cam´ı per a futurs desenvolupaments i aplicacions tant en entorns acad`emics com professionals. Resumen Este proyecto realiza un portar ZeOS, un un sistema operativo monol´ıtico originalmente desarrollado para la arquitectura Intel 80386, a la arquitectura RISC-V. ZeOS, soporta diversas funcionalidades como gesti´on de procesos, gesti´on de memoria, las interrupciones y los niveles de privilegio. La arquitectura RISC-V, una arquitectura de conjunto de instrucciones (ISA) de c´odigo abierto, ofrece una gran flexibilidad, extensibilidad y modularidad, lo que la convierte en un candidato ideal para fines educativos y experimentales. Este proyecto no s´olo contribuye a la comprensi´on y utilizaci´on de la arquitectura RISC-V, sino que tambi´en mejora los recursos educativos disponibles para los estudiantes de sistemas operativos en la FIB. El ´exito de la adaptaci´on de ZeOS a RISC-V podr´ıa allanar el camino para futuros desarrollos y aplicaciones tanto en el ´ambito acad´emico como profesional. 3 Abstract This project makes a port of ZeOS, a monolithic operating system developed for the Intel 80386 architecture, to the RISC-V arquitecture. ZeOs finds implemented, among others, functionalities such as process management, memory management, interruptions and levels of privilege. The RISC-V architecture offers significant flexibility, extensibility and modularity, making it an ideal candidate for educational and experimental purposes. This project not only contributes to the understanding and utilization of the RISC-V architecture but also enhances the educational resources available to students studying operating systems at FIB. The successful port of ZeOS to RISC-V could pave the way for further developments and applications in both academic and professional settings. ´ Index 1. Introducci´o, Justificaci´o i Context 7 1.1. Justificaci´o.................................. 7 1.2. Contextualitzaci´o.............................. 8 1.2.1. Actorsimplicats........................... 8 1.3. Definici´o de conceptes . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3.1. Sistemes Operatius . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3.2. ZeOS................................. 10 1.3.3. RISC-V ............................... 10 2. Abast 12 2.1. Objectiu................................... 12 2.2. Obstaclesiriscos .............................. 13 3. Metodologia 14 3.1. Metodologia de treball . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Planificaci´o 16 4.1. Descripci´o de tasques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.1. Gesti´o del Projecte . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. DiagramadeGantt............................. 22 4.3. Gesti´odeRisc................................ 24 5. Gesti´o econ`omica del Projecte 25 5.1. Pressupost.................................. 25 5.1.1. RecursosHumans.......................... 25 5.1.2. Recursosf´ısics............................ 27 5.1.3. Recursos de software ........................ 27 5.1.4. Altres tipus de Recursos . . . . . . . . . . . . . . . . . . . . . . 27 5.1.5. Recursos per Imprevists . . . . . . . . . . . . . . . . . . . . . . 28 5.1.6. Total................................. 29 5.2. ControldeGesti´o.............................. 29 4 ´ INDEX 5 6. Sostenibilitat del Projecte 31 6.1. Autoavaluaci´o................................ 31 6.2. Dimensi´oEcon`omica ............................ 32 6.3. Dimensi´osocial ............................... 32 6.4. Dimensi´o Ambiental . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. Seguiment 33 7.1. Metodologiairigor ............................. 35 7.2. Pressupost.................................. 35 7.3. Aspectes legals, lleis i regulacions . . . . . . . . . . . . . . . . . . . . . 36 7.3.1. Lleis ................................. 36 7.3.2. Llicencies .............................. 37 8. Disseny 38 8.1. NaturalesadeRISC-V ........................... 38 8.1.1. Filosofia de RISC-V . . . . . . . . . . . . . . . . . . . . . . . . 39 8.1.2. Registres............................... 40 8.1.3. Nivell de privilegis . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.1.4. Interrupcions ............................ 42 8.1.5. Registres de control i estat . . . . . . . . . . . . . . . . . . . . . 42 8.2. Decisions d’arquitectura presses . . . . . . . . . . . . . . . . . . . . . . 47 8.2.1. Dimensi´o d’adreces . . . . . . . . . . . . . . . . . . . . . . . . . 47 8.2.2. Set d’instruccions . . . . . . . . . . . . . . . . . . . . . . . . . . 48 8.2.3. Mida mem`oria virtual . . . . . . . . . . . . . . . . . . . . . . . 49 8.2.4. Gesti´o de permisos . . . . . . . . . . . . . . . . . . . . . . . . . 50 8.2.5. Servei de Virtualitzaci´o QEMU . . . . . . . . . . . . . . . . . . 50 9. Implementaci´o 52 9.1. Organitzaci´o del codi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 9.2. Sistema de c`arrega del SO . . . . . . . . . . . . . . . . . . . . . . . . . 53 9.3. Mecanismes d’entrada i sortida i gesti´o d’interrupcions . . . . . . . . . 56 9.3.1. Mecanisme d’escriptura . . . . . . . . . . . . . . . . . . . . . . . 56 9.3.2. Configuraci´o i gesti´o d’interrupcions . . . . . . . . . . . . . . . . 57 9.4. Mecanismes de gesti´o de mem`oria . . . . . . . . . . . . . . . . . . . . . 59 9.5. Mecanismes de gesti´o de processos . . . . . . . . . . . . . . . . . . . . . 63 10.Conclusi´o i treball futur 65 10.1.Conclusi´o .................................. 65 10.2.Treballfutur................................. 66 Refer`encies 69 ´ Index de figures 4.1. Taula d’hores per tasca. Font: Elaboraci´o pr`opia ............. 21 4.2. Gantt del projecte. Font: Elaboraci´o pr`opia ............... 23 5.1. Sou per hora dels treballadors del projecte. Font: Elaboraci´o pr`opia . . 26 5.2. Cost econ`omic per tasca i subdivisi´o. Font: Elaboraci´o pr`opia ..... 26 5.3. Taula de Costos i Amortitzacions. Font: Elaboraci´o pr`opia ....... 27 5.4. Taula de Costos i Amortitzacions d’altres tipus de recursos. Font: Elaboraci´o pr`opia ................................ 28 7.1. Taula d’hores per tasca actualitzada. Font: Elaboraci´o pr`opia ..... 34 7.2. Cost econ`omic per tasca i subdivisi´o actualitzat. Font: Elaboraci´o pr`opia 35 8.1. Nivells de privilegis de RISC-V [25]. .................... 41 8.2. Machine-mode status register[25]. ..................... 43 8.3. Supervisor-mode status register[25]. .................... 43 8.4. Supervisor address translation and protection[25]. ............ 44 8.5. Machine Interrupt Pending[25]. ...................... 45 8.6. Machine Interrupt Enable[25]. ....................... 45 8.7. Supervisor Interrupt Pending[25]. ..................... 45 8.8. Supervisor Interrupt Enable[25]. ...................... 45 8.9. Machine Cause Register[25]. ........................ 46 8.10. Supervisor Cause Register[25]. ....................... 47 9.1. Contingut del fitxer zeosV. Font: Elaboraci´o pr`opia ........... 54 9.2. Adre¸ca f´ısica en sv39[25]. .......................... 59 9.3. Adre¸ca virtual en sv39[25]. ......................... 60 9.4. Entrada de taula de p`agina[25]. ...................... 61 9.5. Espai de mem`oria f´ısica i virtual. Font: Elaboraci´o pr`opia ....... 63 6 Cap´ıtol 1 Introducci´o, Justificaci´o i Context 1.1. Justificaci´o La idea d’aquest treball ´es adaptar un sistema operatiu nadiu de la Facultat d’Inform`atica de Barcelona (FIB), el ZeOS, a una arquitectura anomenada RISC-V que ha despertat molt inter`es en la ind´ustria del hardware.[1] El focus principal del treball de fi de grau ´es l’`ambit acad`emic i educatiu. L’objecte d’estudi sobre el qual es treballa de base, el ZeOS, ´es un sistema operatiu senzill creat per l’arquitectura x86 de 32 bits d’instrucci´o basat en el kernel de Linux 2.4. Aquest SO es fa servir durant el proc´es d’aprenentatge i familiaritzaci´o dels conceptes b`asics del tema en les assignatures Sistemes Operatius 2 (SO2)[2] i Sistemes Operatius Avan¸cats (SOA)[3] de la FIB. RISC-V ´es una arquitectura de conjunt d’instruccions (ISA) de codi obert nascuda el 2010 durant un projecte de la Universitat de Calif`ornia. Aquesta arquitectura destaca perqu`e per fer-ne ´us no cal comprar els drets de propietat intel·lectual, i a m´es fomenta la investigaci´o i el desenvolupament d’eines pr`opies. Aquest fet la diferencia de la resta d’arquitectures.RISC-V t´e suport tant institucional, la Comissi´o Europea, com acad`emic per convertir-se en el dominador de les tend`encies i estrat`egies de futur en l’`ambit d’arquitectura de microxips.[4] La motivaci´o del projecte ´es aconseguir adaptar el sistema operatiu docent ZeOS a l’arquitectura RISC-V d’una manera `optima i eficient basant-nos en el codi existent. Posteriorment, i en cas d’un assoliment notable, una de les possibles aplicacions d’aquest projecte podria ser la utilitzaci´o per l’aprenentatge tant de sistemes operatius com de l’arquitectura RISC-V per a futurs alumnes de la Facultat d’Inform`atica de Barcelona (FIB). 7 8CAP´ ITOL 1. INTRODUCCI ´ O, JUSTIFICACI ´ O I CONTEXT 1.2. Contextualitzaci´o “Porting ZeOS to RISC-V ” ´es el Treball de Final de Grau d’Enginyeria Inform`atica especialitzat en Tecnologies de la Informaci´o. El grau s’imparteix a la Universitat Polit`ecnica de Catalunya, a la Facultat d’Inform`atica de Barcelona. Dins l’especialitat de Tecnologies de la Informaci´o (TI) podem destacar diverses branques de coneixement com poden ser sistemes distribu¨ıts, sistemes operatius, llenguatges de programaci´o, coneixements de maquinari, protocols de comunicacions i arquitectures de sistemes.[5] Cal destacar que no hi ha cap projecte que hagi complert la mateixa tasca exactament, per`o s´ı que hi ha hagut diversos durant els anys anteriors que han realitzat adaptacions del sistema ZeOS a altres arquitectures com pot ser el treball d’en Albert Segura Salvador.[6] N’Albert Segura va fer un port del ZeOS a l’arquitectura ARM utilitzada en les plaques Raspberry Pi.[7] Tamb´e dins de l’`ambit acad`emic, per`o en aquest cas fora del nostre pa´ıs, cal fer una menci´o al projecte dut a terme per Frans Kaashoek, Robert Morris i Russ Cox, professors de la universitat MIT (Massachusetts Institute of Technology) qui varen realitzar un port d’un sistema operatiu propi basat en l’arquitectura x86 a l’arquitectura RISC-V anomenat xv6.[8] Xv6 s´ı que t´e la mateixa base i finalitat que aquest projecte, per`o cal indicar que el sistema operatiu sobre el qual es treballar`a ´es diferent, aix´ı doncs en cap cas es podria considerar el mateix projecte. 1.2.1. Actors implicats El principal actor implicat i que trobar`a un benefici directe a causa de la realitzaci´o del projecte ´es qui el desenvolupa. ´ Es a dir, gr`acies a la realitzaci´o del treball obtindr´e un coneixement extens en l’`ambit d’arquitectura de sistemes operatius, m´es espec´ıficament en RISC-V, fet que pot obrir portes en un futur pr`oxim. Tamb´e estendre els coneixements en programaci´o, gesti´o de programaci´o i aprenentatge aut`onom, eines importants pel desenvolupament professional. A causa de la finalitat d’aquest projecte podem agrupar les persones a les quals pot anar dirigit el projecte en dos grans grups segons l’`ambit: l’educatiu i el professional. Quan parlem de l’`ambit educatiu fem refer`encia a tots els alumnes de la FIB que cursen les assignatures anteriorment indicades, SOA i SO2. Als quals se’ls pot oferir 1.3. DEFINICI ´ O DE CONCEPTES 9 una manera diferent d’aprenentatge dels coneixements, obrint el paradigma d’una nova arquitectura. Fins al moment un alumne d’aquestes assignatures no obt´e cap mena de coneixement espec´ıfic sobre l’arquitectura RISC-V. Per`o en cas d’assolir un resultat positiu, l’alumnat podria obtenir un coneixement nou, innovador i emergent. Per tant, aquest podria ser considerat l’`ambit amb una major possibilitat de benefici directe en respecte el projecte. En canvi, dins l’`ambit professional podem trobar algun cas pr`actic on el port de ZeOS compleixi amb els requisits que un projecte necessita per treballar amb l’arquitectura RISC-V. A causa de la seva simplicitat i ser un treball de codi obert, pot ser que algun petit projecte tri¨ı aquest treball. Encara que pot semblar una opci´o complexa pel fet que les funcionalitats esperades s´on b`asiques, no cal descartar aquesta opci´o com una possible via de negoci i finan¸cament del projecte. 1.3. Definici´o de conceptes En aquest apartat es definiran de forma breu els conceptes te`orics m´es directes relacionats amb el treball. 1.3.1. Sistemes Operatius Els sistemes operatius s´on els programes encarregats d’administrar i gestionar tots els recursos d’un dispositiu, com pot ser un ordinador, de manera eficient. ´ Es essencial en tots els processos del dispositiu i la seva funcionalitat comen¸ca des del moment en qu`e encenem la nostra m`aquina. Qualsevol mena de dispositiu que tingui un processador ha de tenir un sistema operatiu, per tant, hi ha de molts tipus especialitzats en les necessitats i capacitats de cada dispositiu. Des d’un ordinador fins a un televisor passant per un cotxe, un m`obil, un rellotge intel·ligent o un caixer autom`atic han de disposar d’un sistema operatiu per tal de poder operar i implementar funcions sobre ells. En tots els casos, la funcionalitat ´es la mateixa: oferir a l’usuari una interf´ıcie amb la qual es pugui comunicar i interactuar amb el software i el hardware, perqu`e el dispositiu faci les tasques intencionades. Internament, tamb´e s’encarrega de feines com la gesti´o de recursos, fitxers o tasques de suport, com poden ser l’actualitzaci´o de programari, Cap´ıtol 4 Planificaci´o En aquest apartat del projecte s’especificar`a la planificaci´o del temps realitzada per completar les tasques proposades durant el treball de fi de grau. El projecte t´e una durada estimada de 540h establertes per la Facultat d’Inform`atica de Barcelona, que ´es on es duu a terme. Compren des del dia 19 de febrer de 2024 fins al dia 28 de juny, ambd´os inclosos. Per tant, podem deduir que es tracta d’un projecte de disset setmanes dedicades a la realitzaci´o de la mem`oria i el seu contingut fora d’aquesta, ja que t´e com a data d’entrega el 17 de juny. Tamb´e caldr`a dedicar un temps en preparar la defensa d’aquest i dur-la a terme. El projecte, fora de casos excepcionals, t´e una data m`axima de finalitzaci´o de 28 de juny. S’estima, per tant, una dedicat`oria d’aproximadament 32 hores setmanals que si les repartim equitativament, fet poc probable per possibles compromisos diversos o problemes, estipula la dedicaci´o en 4,5 hores per dia. 4.1. Descripci´o de tasques A continuaci´o, es descriuran detalladament cadascuna de les tasques que es duran a terme per tal de complir amb l’objectiu marcat del projecte. Aquestes es trobaran subdividides segons l’`ambit en qu`e es trobin per la seva correcta comprensi´o. La subdivisi´o est`a feta en 3 blocs que s´on: Gesti´o del Projecte, Aprenentatge i familiaritzaci´o amb l’entorn i Implementaci´o de ZeOS en RISC-V. Encara que siguin de tasques diferents cal esmentar que totes tenen factors i elements comuns: 16 4.1. DESCRIPCI ´ O DE TASQUES 17 Recursos Material: Totes les tasques es realitzaran des del mateix entorn de treball i amb el mateix ordinador. Espai de Treball: Totes les tasques es realitzaran des de la mateixa localitzaci´o f´ısica. Recursos Humans: Totes les tasques, a excepci´o d’una, seran realitzades per la mateixa persona. L’´unica tasca que no realitzar`a ´unicament la persona que desenvolupa el projecte ´es la tasca 1.6. Reunions amb el director i codirector, en la que com indica el seu nom tamb´e participaran el director o codirector. 4.1.1. Gesti´o del Projecte En aquesta subdivisi´o del projecte es troben totes aquelles tasques que interfereixen la correcta gesti´o del projecte. Com poden ser la gesti´o de la temporitzaci´o, del coneixement o de la comunicaci´o entre els participants. Aquestes tasques s´on essencials per un correcte desenvolupament del treball, ja que ens permetran orquestrar correctament tot el que l’entorna. Les tasques es basen en la gesti´o de la documentaci´o, de la mem`oria del projecte. Aquesta gesti´o s’ha de realitzar de manera continuada al llarg del projecte, per`o cal anotar que tindr`a dos moments en qu`e la dedicaci´o ser`a major, al principi pel fet que s’haur`a de realitzar contingut per les entregues del GEP i al final per tal de la revisi´o completa i l’enllestiment dels detalls per l’entrega de la mem`oria. Per tant, es calculen 237 hores repartides en les seg¨uents subtasques. Contextualitzaci´o i Abast Aquesta ´es la tasca amb qu`e s’inicia el projecte, a m´es de contextualitza i descriure’l. Gr`acies a aquesta tasca es pot definir de manera excel·lent el marc del projecte, una breu descripci´o del projecte a resoldre, els recursos pertinents per aconseguir-ho i la metodologia de treball, entre altres. Aquesta tasca es realitza alhora que l’entrega n´umero 1 del GEP i es troba estipulada en una dedicaci´o de 25 hores de treball Planificaci´o Aquesta ´es la segona tasca que es realitzar`a pel correcte desenvolupament del projecte. En aquesta s’especificar`a una estimaci´o de les dates establertes per la realitzaci´o 18 CAP´ ITOL 4. PLANIFICACI ´ O i la dedicaci´o hor`aria per cadascuna de les tasques del projecte. Ser`a de molta utilitat per tal de poder portar un control sobre l’avan¸c i el compliment dels objectius marcats gr`acies en part al Gantt que es duu a terme durant aquesta. Aquesta tasca ´es du a terme alhora que l’entrega n´umero 2 del GEP i es troba estipulada en una dedicaci´o de 15 hores de treball. Pressupost i sostenibilitat Aquesta tercera tasca es realitzar`a per ser conscients de l’impacte del treball en vers al medi en qu`e vivim i tamb´e, la despesa econ`omica que aquest generar`a. Es descriur`a l’impacte econ`omic, social i mediambiental del treball “Porting ZeOS to RISC-V ”. Aquesta tasca es du a terme alhora que l’entrega n´umero 3 del GEP i es troba estipulada en una dedicaci´o de 12 hores de treball. Entrega Final GEP Aquesta tasca correspon a la creaci´o d’un document final per la seva entrega en el termini establert pel GEP. Aquesta entrega es correspondr`a del contingut creat en les tasques anteriorment explicades. Tamb´e es considera part d’aquesta tasca tota la feina de modificaci´o i millora sobre el contingut anteriorment creat en les tres tasques anteriors. Aquesta modificaci´o ser`a basada en els comentaris rebuts per part del tutor del GEP, Joaquim Deulofeu, qui haur`a anat avaluant i comentant les diverses entregues anteriors. Aquesta tasca es du a terme al mateix temps que l’entrega n´umero 4 del GEP i es troba estipulada en 25 hores de treball. Mem`oria Aquesta tasca consisteix en la redacci´o i correcci´o de la mem`oria a entregar al final del projecte. ´ Es una tasca que es duu a terme durant tota l’extensi´o del treball i cada vegada que hi hagi algun tipus de dada o informaci´o a afegir a la mem`oria es realitzar`a dins d’aquesta tasca. Aquesta tasca es troba estipulada en 70 hores de treball. 4.1. DESCRIPCI ´ O DE TASQUES 19 Reunions amb el director i codirector Les reunions s´on una part essencial pel correcte desenvolupament del treball. ´es faran de forma peri`odica cada setmana i excepcionalment es podran realitzar algunes extres. Es calcula que es realitzar`a una trucada de dues hores cada dues setmanes pel seguiment, a m´es es reserva una bossa de 22 hores per tal de fer-les servir en reunions excepcionals. Per tant, per aquesta tasca es troben estipulades 40 hores de treball. Defensa del treball Aquesta tasca ´es amb la qual es completa el treball, es fa al final i descriu la preparaci´o del contingut per la presentaci´o de la defensa del treball davant del tribunal. Es calcula una dedicaci´o de 50 hores de treball. Aprenentatge i familiaritzaci´o amb l’entorn Per tal de poder portar a cap mena de feina sobre el sistema operatiu ZeOS i la seva adaptaci´o a l’arquitectura RISC-V, cal obtenir un coneixement amb un nivell de precisi´o molt alt. ´ Es per aix`o que aquesta subdivisi´o del projecte envolta tota la fase de lectura d’aprenentatge aut`onom requerida per tal de poder comen¸car a executar les tasques proposades. Es basa en dos grans subapartats i t´e una dedicaci´o establerta de 100 hores de treball. ZeOS Per tal d’aprendre sobre el sistema operatiu es planteja la lectura de la documentaci´o que es disposa sobre el tema i tamb´e, una part de programaci´o sobre l’arquitectura actual de ZeOS, x86, per comprovar el coneixement assolit. Tamb´e es posa en consideraci´o la possibilitat de fer consultes a les persones encarregades del desenvolupament del ZeOS en cas de dubtes. Per tant, es calcula unes 35 hores de treball. RISC-V Per al RISC-V la fase d’aprenentatge ha de ser major en comparaci´o amb el ZeOS, a causa del fet que el coneixement base en menor, pr`acticament s’haur`a de comen¸car a descobrir l’arquitectura des de zero nom´es basant-nos en el coneixement anterior en altres arquitectures. Aix`o es far`a gr`acies a documentaci´o p´ublica que s’aconseguir`a per 20 CAP´ ITOL 4. PLANIFICACI ´ O Internet. Dins d’aquesta tasca tamb´e cal considerar l’aprenentatge del coneixement requerit per la correcta virtualitzaci´o del projecte, ´es a dir, aprendre el funcionament de QEMU i com fer que el treball que tenim sigui funcional en aquest software. Es calculen unes 65 hores de treball. Plantejament i programaci´o de solucions En aquesta subdivisi´o del projecte, ´es on troba el contingut en qu`e es basa el treball. Envolta totes les implementacions i adaptacions proposades. ´ Es per aix`o que ´es la subdivisi´o a la qual se li dedicar`a un nombre major d’hores, fins a 200 hores. Aquesta subdivisi´o es pot dividir en 4 grans subtasques. Creaci´o i adaptaci´o del sistema de c`arrega del SO En aquesta tasca s’abra¸ca tot el que tingui a veure amb la implementaci´o correcta i les adaptacions necess`aries per a fer que el sistema operatiu ZeOS que ja tenim funcioni. ´ Es per aix`o que fent una previsi´o dels possibles problemes que trobarem es calcula que la dedicaci´o ser`a de 40 hores de treball. Creaci´o i adaptaci´o dels mecanismes d’entrada i sortida Per aquesta tasca trobarem les implementacions dels mecanismes de gesti´o d’excepcions, interrupcions de hardware i la gesti´o de crides a sistema o syscalls. ´ Es una tasca d’una extensi´o considerable pel fet que s´on diverses coses a implementar i la forma de comprovar-les no ser`a gaire senzilla. Es calculen 60 hores de treball. Creaci´o i adaptaci´o dels mecanismes de gesti´o de mem`oria En aquesta tasca es realitzen totes els processos requerits per l’adaptaci´o dels sistemes de mem`oria com pot ser la gesti´o de la paginaci´o o l’assignaci´o de privilegis. ´ Es un tema molt extens on hi ha diverses coses a implementar i tamb´e cal considerar que ´es un tema el qual es for¸ca dif´ıcil de comprovar si s’ha implementat totalment de forma correcta fet que requerir`a m´es temps. 4.1. DESCRIPCI ´ O DE TASQUES 21 ´ Es per aix`o que es calculen unes 50 hores de treball. Creaci´o i adaptaci´o dels mecanismes de gesti´o de processos Aquesta ´es l’´ultima tasca de programaci´o que trobem i s’ubica al final del projecte, descriu tot el que ajusta la gesti´o de processos com b´e indica el seu nom, ´es a dir, implementar que es pugui crear, destruir i identificar un proc´es entre altres coses. Com a tasca final se li dedicar`a un considerable volum de treball, 50 hores de treball. Figura 4.1: Taula d’hores per tasca. Font: Elaboraci´o pr`opia 22 CAP´ ITOL 4. PLANIFICACI ´ O 4.2. Diagrama de Gantt El diagrama de Gantt del projecte ´es creat segons la justificaci´o de les hores realitzada amb anterioritat, en aquest es pot veure com hi ha tasques que tenen una depend`encia directa entre elles i altres que no. Tamb´e es pot apreciar com hi ha diverses que es porten a cap durant tota l’extensi´o del projecte. Figura 4.2: Gantt del projecte. Font: Elaboraci´o pr`opia 24 CAP´ ITOL 4. PLANIFICACI ´ O 4.3. Gesti´o de Risc El risc ´es una part important a tenir en compte en qualsevol projecte, cal tenir en compte qualsevol classe de possible obstacle a trobar-nos durant el cam´ı per tal de tenir sempre altres formes d’actuar i aix´ı no paralitzar el projecte en cas que succeeixi qualsevol imprevist. Cal tenir en compte la naturalesa del nostre treball per poder trobar els obstacles. El treball es pot considerar que cont´e molta c`arrega d’obtenci´o de coneixement i tamb´e de programaci´o, per tant, podem definir els dos principals obstacles i les seves solucions com: Problema en l’assoliment dels coneixements: Aquest obstacle el trobem quan volem obtenir coneixements en alguna branca del nostre treball, per`o no podem trobar la informaci´o que necessitem o no l’entenem amb un alt grau de certesa. En aquest cas es recorrer`a a la redacci´o d’un correu electr`onic per tal de transmetre els dubtes al director i codirector i trobar la manera de comunicar-nos per solucionar-ho. Problema en la resoluci´o d’una tasca de programaci´o: Aquest obstacle el trobem quan ens paralitzem en mig d’una tasca, ja que no som capa¸cos de trobar una soluci´o o sortida al problema amb el codi que tenim. La forma de resoldre-ho ´es la mateixa que amb l’obstacle anterior: la redacci´o d’un correu electr`onic per tal de transmetre els dubtes al director i codirector i trobar la manera de comunicar-nos per solucionar-ho. P`erdua del contingut de la mem`oria: Tal com s’ha esmentat abans, la realitzaci´o i l’emmagatzemament de la mem`oria es far`a a la plataforma Overleaf. Aix´ı doncs, aquest problema sorgeix pel fet que per algun cas les dades de la mem`oria, ´es a dir el contingut, desapareixes o s’elimin´es per problemes externs. Per evitar que succeeixi el procediment a seguir ser`a que cada cop que es realitza un avan¸c en la mem`oria es descarregar`a el fitxer i es penjar`a al n´uvol. P`erdua dels fitxers de programaci´o: Tal com tamb´e s’ha esmentat abans els fitxers amb el codi del treball es trobaran tant en local com tamb´e a Github. Cal considerar tamb´e la possibilitat de no complir amb les temporitzacions marcades, en aquest cas perqu`e el treball no t´e camp, obligaci´o d’entrega a tercers, es dedicaran les hores establertes i concatenant tasques. Aix`o vol dir que, si en una tasca es dediquen 20 hores i hi havia 15 previstes, de la tasca seg¨uent s’haur`a de reduir l’extensi´o. Es continuar`a amb aquest proc´es i si cal s’aniran eliminant les tasques del final a causa del fet que estan ordenades segons la prioritat corresponent. Cap´ıtol 5 Gesti´o econ`omica del Projecte Com qualsevol altre, aquest projecte necessita un pressupost per poder tenir en compte tots els costos econ`omics que tinguin a veure amb ell mateix. Per tant, en aquest apartat s’identificaran tots els recursos econ`omics de qualsevol `ambit que es facin servir durant el projecte. 5.1. Pressupost Per realitzar correctament el pressupost cal tenir en compte el tipus de projecte que estem realitzant, ja que per cada tipus ´es diferent. En el cas del treball “Porting ZeOS to RISC-V ” ens trobem on el principal recurs que es fa servir ´es hum`a, una persona o diverses dedicant temps, tamb´e es fan servir recursos materials i energ`etics com poden ser l’ordinador i la llum. 5.1.1. Recursos Humans Podem definir aquest apartat com les despeses generades pels salaris de les persones envoltes en el treball. En aquest cas nom´es hi treballa directament una persona, no comptabilitzarem les possibles ajudes externes per part del director o codirector del treball. Per fer el c`alcul del salari caldr`a posar preu a l’hora de la persona treballant. Com la persona que fa el treball no ´es titulat en el grau d’Enginyeria Inform`atica sin´o que es troba en proc´es, comptabilitzarem com a cost per hora el preu establert per la Facultat d’Inform`atica de Barcelona per un contracte de pr`actiques, ´es a dir, 10 euros bruts l’hora.[16] A partir del salari brut per hora i multiplicant per 1,3 per fer un c`alcul de les des25 32 CAP´ ITOL 6. SOSTENIBILITAT DEL PROJECTE gr`acies a l’educaci´o rebuda moltes d’aquestes coses ja es realitzen o es consideren quan es pren una decisi´o sense haver-hi de pensar expl´ıcitament. 6.2. Dimensi´o Econ`omica Aquest aspecte s’ha tingut en compte durant tota la realitzaci´o del projecte, s’ha creat un pressupost que embarca tota l’extensi´o d’aquest. En el pressupost s’ha tractat de tenir les m´ınimes despeses econ`omiques possibles i optimitzar al m`axim els recursos humans garantint el compliment dels objectius. Per tal d’aconseguir aix`o nom´es s’han incl`os dins del pressupost les coses essencials i marcant les partides econ`omiques m´ınimes possibles. En alguna ocasi´o com per exemple quan es va haver d’escollir un software de gesti´o de projectes es van descartar altres deguts a qu`e tenien un preu d’utilitzaci´o i es va considerar que els avantatges no justificaven la inversi´o. 6.3. Dimensi´o social Dins la dimensi´o social m’agradaria destacar tot el que m’ha aportat el projecte, m’ha dotat de coneixements que no disposava, m’ha ensenyat a gestionar un projecte de majors dimensions, a treballar amb unes hores per tasca marcades, amb unes dates d’entregues fixes i moltes altres coses que m’han fet cr´eixer tan personal com professionalment. Pensant m´es en l’impacte social del projecte m’agradaria que aquest tingues conseq¨u`encies positives sobre els altres. Com b´e s’havia comentat la intenci´o era que si la soluci´o obtinguda al final del problema era bona fer-la servir en el projecte educatiu de la Facultat d’Inform`atica de Barcelona. M’agradaria pensar que s’ha aconseguit aix`o i que els nous alumnes de la carrera aprendran nous conceptes i d’una forma m´es pr`actica gr`acies a l’adaptaci´o del ZeOS a RISC-V. 6.4. Dimensi´o Ambiental S’ha estimat que l’impacte ambiental del projecte ser`a m´ınim perqu`e no generar`a cap mena de residu de forma directa. A m´es, els ´unics recursos que es faran servir ja es trobaven en ´us abans del projecte i dins la seva vida ´util. ´ Es dif´ıcil pensar en un plantejament de treball que generi menys impacte ambiental, per tant, aquest camp est`a correctament assolit. Cap´ıtol 7 Seguiment Tenint en compte la planificaci´o inicial establerta abans de comen¸car el projecte podem fer una comparaci´o de l’estat final en comparaci´o al planificat. A l’inici es va establir una planificaci´o inicial on es marcaven clarament unes dates d’inici i fi de les diverses tasques preestablertes. Per diversos motius l’estat en el qual es troba el projecte no ´es l’indicat al Gant inicial. El projecte s’ha hagut de finalitzar en la tasca de creaci´o i adaptaci´o dels mecanismes de gesti´o de mem`oria. Aix`o ´es a causa que aquesta tasca ha requerit m´es temps del pressupostat. Respecte a la primera tasca d’implementaci´o el temps establert a l’inici del projecte ha descrit perfectament la seva duraci´o, d’igual manera que les dues tasques de recerca de coneixement sobre ZeOS i RISC-V. ´ Es a dir no ´es necessari realitzar cap modificaci´o. Les tasques que han portat m´es temps de l’estimat han estat la n´umero 2 i 3 de la part d’implementaci´o de ZeOS en RISC-V. La tasca “Creaci´o i adaptaci´o dels mecanismes d’entrada i sortida”, la n´umero 2, es definia com la implementaci´o dels mecanismes de gesti´o d’excepcions, interrupcions de hardware i la gesti´o de crides a sistema o syscalls. Durant la realitzaci´o d’aquesta tasca el principal problema que ens hem trobat i que ha influ¨ıt en l’augment d’hores destinades a estat la falta d’informaci´o sobre el tema. Per implementar-la s’han fet servir eines com el circuit integrat UART que t´e una escassa documentaci´o, fet que ha dificultat molt l’aprenentatge i l’aplicaci´o d’aquest. Tamb´e sobre les interrupcions hi ha hagut diversos contratemps, ja que el coneixement que tenia sobre el tema no era del tot prec´ıs i va caler dedicar for¸ca temps a mirar 33 34 CAP´ ITOL 7. SEGUIMENT exactament quin bit faltava pel seu correcte funcionament. Tot el comentat anteriorment ha fet que el temps hagi passat de les 60 hores preestablertes, a les 80 hores que han resultat ser definitivament. Respecte a la tasca n´umero 3, “Creaci´o i adaptaci´o dels mecanismes de gesti´o de mem`oria” ´es on es troba el projecte finalment. L’augment de les hores ve justificat pel nivell de la tasca, m´es alt del que pr`eviament es plantejava. Aquest augment ha estat de les 50 pressupostades a les 80 finals. En aquesta nova taula es veu definida la planificaci´o final del treball de recerca. Figura 7.1: Taula d’hores per tasca actualitzada. Font: Elaboraci´o pr`opia Com podem veure clarament, el temps de dedicaci´o establert per la tasca n´umero 4 d’implementaci´o de ZeOS en RISC-V s’ha quedat redu¨ıt a 0. ´ Es per aix`o que, encara que la intenci´o era completar la tasca acomplint les mateixes funcions definides anteriorment no s’ha aconseguit. 7.1. METODOLOGIA I RIGOR 35 7.1. Metodologia i rigor En relaci´o amb la manera de treballar no hi ha hagut cap canvi respecte a la forma plantejada a l’inici del projecte. Inicialment, es va considerar necess`aria una gran part de formaci´o i d’obtenci´o de coneixements generals per poder embarcar-nos en el projecte. Posteriorment, tamb´e com s’havia comentat a les tasques d’implementaci´o directes sempre comencen amb un rep`as dels continguts i una recerca per internet de webs contrastades on poder ampliar el coneixement. 7.2. Pressupost Si ve no trobem cap modificaci´o en el pressupost total del projecte s´ı que podem trobar modificacions en el pressupost dedicat a cada tasca. A causa directa de les modificacions en el temps dedicat a diverses tasques el cost d’aquestes es veu augmentat o disminu¨ıt tal com s’indica en la figura 7.2. Figura 7.2: Cost econ`omic per tasca i subdivisi´o actualitzat. Font: Elaboraci´o pr`opia A part d’aquesta incid`encia cal remarcar que durant el transcurs del projecte no ens hem trobat amb cap mena de problema pressupostari que no s’hagu´es tingut en compte abans. Tampoc s’ha hagut de fer servir el fons per imprevistos. 36 CAP´ ITOL 7. SEGUIMENT 7.3. Aspectes legals, lleis i regulacions 7.3.1. Lleis Un cop ja encaminat el projecte cal analitzar quines lleis i regulacions cal complir per no tenir cap classe de problema legal durant i al final del projecte. A causa de la naturalesa del nostre projecte podem veure clarament com una de les lleis que m´es influencia pot tenir sobre un projecte no ens afecta. Parlem de la Llei Org`anica de protecci´o de dades de car`acter personal o LOPD que defensa la intimitat i la privadesa personal de les dades. En el nostre cas al no tenir cap mena dades de car`acter sensible ens trobem exempts d’aquesta regulaci´o. Propietat intel·lectual Respecte a la propietat del projecte, ens trobem abra¸cats per la normativa del treball de final de grau de la Universitat Polit`ecnica de Catalunya: “La propietat industrial i intel·lectual dels TFG de modalitat A est`a regulada per la normativa aprovada pel Consell de Govern (10/10/2008) per la qual s’aprova la confidencialitat, responsabilitat patrimonial i propietat industrial i intel·lectual a la Universitat Polit`ecnica de Catalunya. D’aquesta normativa destaquem els par`agrafs seg¨uents relatius a les invencions i les obres dels estudiants dirigides o coordinades pel professorat de la UPC: — . . . correspondr`a a la UPC la titularitat sobre les invencions desenvolupades exclusivament pels estudiants si s’ha desenvolupat en el marc d’una activitat acad`emica que hagi estat dirigida i/o coordinada pel professorat de la UPC. — En el cas que el desenvolupament de l’obra intel·lectual hagi estat dirigida i/o coordinada pel professorat de la UPC, correspondr`a a la UPC la titularitat dels drets d’explotaci´o sobre aquesta obra i l’estudiant i el professor seran considerats coautors de la mateixa. — En cas d’explotaci´o de l’obra per part de la UPC que li suposi un benefici econ`omic, l’autor o conjunt d’autors tindran dret a una participaci´o del 50% dels beneficis nets obtinguts.”[21] Aix´ı doncs, queda definit clarament la propietat del projecte i els drets tant per part 7.3. ASPECTES LEGALS, LLEIS I REGULACIONS 37 del creador com de la universitat sobre possibles beneficis. 7.3.2. Llicencies El treball fa servir diverses aplicacions que poden tenir requisits de llic`encies d’´us, per`o mai en la utilitzaci´o per finalitats acad`emiques com ´es el cas nostre. Per tant respecte la possibilitat de llic`encies de tercers interposant-se en el nostre projecte queda descartada. Respecte a la llic`encia que descriur`a el nostre projecte s’ha acordat amb el tutor que ser`a una llic`encia de codi obert per tal que qualsevol persona pugui agafar el nostre treball i fer-lo servir per a qualsevol fi. Com la intencionalitat des del principi del projecte ha estat fer una base perqu`e futurs alumnes o persones interessades en la mat`eria puguin aprendre no tindria cap sentit fer servir un altre que no sigui aquesta. La decisi´o de la llic`encia fomenta la contribuci´o de m´es persones, garanteix transpar`encia i fomenta el lliure acc´es al coneixement. Cap´ıtol 8 Disseny Per tal de poder explicar el procediment i les solucions proposades als reptes marcats a l’inici del projecte cal tenir en compte les caracter´ıstiques del sistema operatiu. 8.1. Naturalesa de RISC-V En aquest subapartat s’explicaran detalladament les caracter´ıstiques t`ecniques de l’arquitectura que defineix el projecte. Com s’ha esmentat anteriorment, RISC-V ´es una arquitectura que va concloure el seu proc´es de disseny el 2010 i va realitzar el seu public release el 2011. Va ser creada amb l’objectiu de desenvolupar una ISA (Industry Standard Architecture) de codi obert, permetent que qualsevol persona pugui accedir al seu coneixement i fer implementaci´o sobre ella. Altres arquitectures a tenir en compte per comparar poden ser: x86/x86-64.´ Es l’arquitectura utilitzada en tots els processadors Intel i AMD. Va sortir al mercat amb una versi´o de 16 bits i no va ser fins a 1999 quan va sortir la versi´o de 64 bits. ´ Es l’arquitectura m´es comuna avui en dia. Est`a desenvolupada per l’empresa Intel. Per utilitzar-la cal pagar una llic`encia d’´us[22]. ARM.´ Es l’arquitectura majorit`aria en dispositius m`obils, tauletes i servidors. Est`a desenvolupada per l’empresa ARM Holdings. La seva primera versi´o va sortir l’any 1985 i es continua actualitzant. Per utilitzar-la cal pagar una llic`encia d’´us. PIC.´ Es l’arquitectura utilitzada en la gran majoria de microcontroladors i tamb´e en sistemes embeguts (embedded systems). La seva primera versi´o va sortir l’any 38 8.1. NATURALESA DE RISC-V 39 1975 i tenia 16 bits d’instrucci´o.Actualment, tenim moltes versions segons el tipus de necessitats que requereixi el sistema. Est`a desenvolupada per l’empresa Microchip Technology Inc. Per utilitzar-la cal pagar una llic`encia d’us[23]. Com ja hem pogut veure, en comparaci´o amb els seus possibles comparadors, RISC-V ´es una arquitectura jove i que presenta un gran canvi en el paradigma a causa de la seva naturalesa open source. 8.1.1. Filosofia de RISC-V Una de les seves caracter´ıstiques principals ´es el seu concepte. RISC-V s´on les sigles de Reduced Instruction Set Computing, que vol dir “c`alcul de conjunts d’instruccions redu¨ıts”. Encara que el seu nom pot no ser clar, aquest indica que es basa en la simplicitat i l’efici`encia. Aix`o ho aconsegueix fent servir un petit nombre d’instruccions que efectuen cada operaci´o. Aix`o contrasta radicalment amb la fil`osofa d’altres arquitectures del mercat, com x86 o ARM, que s´on majorit`ariament CISC. CISC, o Complex Instruction Set Computing, defineix un gran nombre d’instruccions que ens facilita realitzar m´es d’una operaci´o per instrucci´o. Aquesta difer`encia es tradueix en diverses caracter´ıstiques a l’hora d’executar codi. En el cas de les arquitectures amb filosofia RISC trobar´ıem majorit`ariament una instrucci´o per cicle. Aix`o ´es degut al fet que les instruccions s´on simples, la qual cosa requereix m´es mem`oria, perqu`e es necessiten m´es instruccions per realitzar la mateixa funcionalitat. A m´es, necessita m´es RAM[22]. En canvi, les arquitectures amb filosofia CISC tenen un nombre d’instruccions per cicle m´es variable, amb instruccions m´es complexes. A conseq¨u`encia, s´on m´es eficients en termes de mem`oria, ja que ocupen menys espai i utilitzen la RAM de manera m´es eficient[24]. Una altra caracter´ıstica, encara que no s’explora dins del projecte, ´es la possibilitat de crear instruccions dins l’arquitectura sense modificar la base. Les instruccions estan organitzades en diferents components, una base essencial que inclou totes les instruccions m´es comunes i altres extensions m´es espec´ıfiques que permeten incorporar noves funcionalitats. Aix´ı doncs, el que ofereix RISC-V ´es la possibilitat de crear instruccions de f`acil integraci´o que ofereixin finalitats m´es espec´ıfiques no incloses per defecte. Aquest punt ´es diferencial gr`acies al fet que permet escalar de petits microcontroladors 40 CAP´ ITOL 8. DISSENY a supercomputadors, gr`acies a la possibilitat d’estendre el conjunt d’instruccions. 8.1.2. Registres Un altre component important de l’arquitectura ´es com s’emmagatzema i es tracta la informaci´o. A RISC-V trobem diversos registres diferents segons la seva finalitat. Podem trobar 32 registres d’enters i 32 de coma flotant. Dins d’aquests 32 registres d’enters trobem: x0: Registre codificat sempre a 0 ra: Return address register. En aquest registre es trobar`a la direcci´o de tornada establerta per la funci´o que fa la crida. sp: Stack pointer register. En aquest registre trobarem un punter a la pila de dades. gp: Global pointer register. Aquest registre es fa servir per accedir a variables globals, serveix com a refer`encia per accedir a dades globals amb un petit despla¸cament. tp: Thread pointer register. Aquest registre es fa servir per accedir a variables d’un mateix thread, d’un mateix fil en un entorn amb m´es d’un fil d’execuci´o. t0-t6: Temporary registers. S´on registres temporals que serveixen per gestionar valors. a0-a7: Argument registers. Registres que es fan servir per passar par`ametres entre funcions. s0-s11: Saved registers. Registres per guardar dades entre crides a funcions, no es poden modificar dins de crides i en cas que es modifiquin s’ha de restaurar el seu contingut. Tamb´e disposem de 32 variables de tipus coma flotant, perqu`e com s’explicar`a m´es endavant, dins del projecte trobem l’extensi´o F que inclou aquestes variables. Trobem aquest tipus de variables de coma flotant: ft0-ft11: Temporary registres. Registres temporals de coma flotant. fs0-fs11: Argument registers. Registres que es fan servir per passar par`ametres en coma flotant. 8.1. NATURALESA DE RISC-V 41 fa0-fa7: Saved registers. Registres per guardar dades en coma flotant entre crides a funcions, no es poden modificar dins de les crides i en cas que es modifiquin s’ha de restaurar el seu contingut. Cal destacar que durant el projecte no s’utilitzen dades en format coma flotant, tot i que ´es una caracter´ıstica integrada al sistema operatiu. 8.1.3. Nivell de privilegis Una caracter´ıstica pr`opia de cada arquitectura ´es la gesti´o dels recursos i dels permisos per garantir la seguretat del sistema. En RISC-V, quan un codi est`a en execuci´o, t´e definit en un nivell de privilegi segons s’hagi establert. Els nivells de privilegis i la seva codificaci´o es mostren a la figura 8.1. Aquests nivells serveixen per limitar en tot moment les funcions que un proc´es pot executar. Figura 8.1: Nivells de privilegis de RISC-V [25]. El nivell m´es alt ´es el machine. Aquest mode s’utilitza principalment per a l’arrancada del sistema i les configuracions inicials, com en el nostre cas, ja que es recomana fer-ne el m´ınim ´us possible a causa que posseeix tots els permisos. El nivell supervisor ´es on normalment s’executa tot el sistema operatiu i finalment, al nivell m´es baix trobem el d’usuari on trobem processos finals sense privilegis. Dins de l’arquitectura tamb´e trobem un altre nivell que es diu Hypervisor. S’utilitza en l’entorn de la virtualitzaci´o, permetent que diversos sistemes operatius s’executin de forma concurrent dins d’una mateixa m`aquina f´ısica. 48 CAP´ ITOL 8. DISSENY En aquest aspecte RISC-V ofereix tres opcions: Instruccions de 32 bits Instruccions de 64 bits Instruccions de 128 bits Des del principi, l’opci´o de 128 bits per instrucci´o va quedar descartada, ja que no es troba gaire estesa dins del m´on de les arquitectures d’ordinadors. Per tant, la decisi´o es trobava entre 32 i 64 bits. Inicialment, es va considerar l’opci´o de fer servir l’arquitectura de 32 bits perqu`e implicada un nivell de simplicitat superior, per`o aquest motiu no es va considerar prou determinant. Per prendre la decisi´o final, es van tenir en compte dos factors: quina ´es la mida m´es estesa entre la gran majoria d’ordinadors del mercat i quina mida utilitza ZeOS per implementar la seva versi´o en x86. La resposta a tots dos plantejaments indicava 64 bits per instrucci´o, i aix´ı es va definir. 8.2.2. Set d’instruccions Quan vam decidir la mida d’instrucci´o, la seg¨uent decisi´o a prendre era quin conjunt d’instruccions escollir. Com s’ha comentat anteriorment, una de les caracter´ıstiques que ofereix RISC-V ´es la seva modularitat. Ofereix un conjunt d’instruccions que consideren b`asiques per qualsevol ISA, per`o tamb´e ofereixen paquets d’instruccions que cada usuari pot escollir si vol afegir-les a la seva implementaci´o. Tot i ser una decisi´o presa a l’inici del projecte, es va considerar en agafar un conjunt d’instruccions for¸ca ampli perqu`e en cap cas ens limites en un futur. Aix´ı doncs, dins dels paquets d’instruccions de RISC-V que ofereix, es va decidir agafar el paquet G. Aquest paquet amb el nom RV64G surt de combinar diversos conjunts diferents entre els quals destacar´ıem: RV64I, Base Integer Instruction Set Aquest conjunt d’instruccions implementa operacions entre enters, operacions de c`arrega i emmagatzemat de valors i la interacci´o amb registres de control. RV64M, Standard Extension for Integer Multiplication and Division Aquest conjunt d’instruccions implementa funcions de multiplicaci´o i divisi´o entre registres. 8.2. DECISIONS D’ARQUITECTURA PRESSES 49 RV64A, Standard Extension for Atomic Instructions Aquest conjunt d’instruccions implementa operacions de mem`oria at`omica. RV64F Standard Extension for Single-Precision Floating-Point Aquest conjunt d’instruccions implementa funcions amb registres de coma flotant. RV64D Standard Extension for Double-Precision Floating-Point Aquest conjunt d’instruccions implementa funcions amb registres de doble precisi´o de coma flotant. D’aquesta manera, es va considerar que, amb aquestes noves implementacions afegides a les ja ofertes per defecte per l’arquitectura RISC-V, es podria implementar el treball sense cap limitaci´o t`ecnica. 8.2.3. Mida mem`oria virtual Un dels objectius del projecte des del seu inici ´es implementar un sistema de mem`oria virtual funcional. Per tant, es va haver de decidir quines caracter´ıstiques tindria i com es podria implementar segons els m`etodes de RISC-V. Com s’ha comentat anteriorment, es treballar`a amb una arquitectura de 64 bits. Dins d’aquesta arquitectura RISC-V ens ofereix diversos tipus de formats de mem`oria virtual: Sv39: Page-Based 39-bit Virtual-Memory System Sv48: Page-Based 48-bit Virtual-Memory System Sv57: Page-Based 57-bit Virtual-Memory System La difer`encia entre cadascuna d’aquestes opcions ofertes ´es el nombre de bits que tenen les instruccions virtuals i, a conseq¨u`encia, l’espai de mem`oria que es pot fer utilitzar. Per exemple, sv39 ofereix adreces de fins a 39 bits i, per tant, t´e un espai de mem`oria de fins a 512 gigabytes. Les altres opcions nom´es es diferencien de sv39 pel nombre de bits d’adre¸ca virtual. Per tant, tenint en compte la naturalesa i la finalitat del projecte, afegir nombre de bits per adre¸ca virtual i de l’espai virtual no aportava cap avantatge significatiu al projecte. Aix´ı doncs, la decisi´o escollida va ser implementar mem`oria virtual sv39. 50 CAP´ ITOL 8. DISSENY 8.2.4. Gesti´o de permisos Una altra decisi´o que es va haver de prendre ´es quins nivells de privilegis es fan servir i perqu`e s’utilitzaran. En el cas de ZeOS-V, es faran servir tres nivells de prioritats: el nivell machine, supervisor i usuari, cadascun amb funcionalitats determinades. El nivell machine s’utilitzar`a per realitzar el proc´es d’arrancada i la configuraci´o inicial; el nivell supervisor es far`a servir per al sistema operatiu; i, finalment el nivell usuari ser`a per les futures aplicacions que tingui el programa. El nivell hypervisor que ofereix RISC-V s’ha decidit no fer servir en cap moment, ja que no s’implementa cap d’eina de virtualitzaci´o. 8.2.5. Servei de Virtualitzaci´o QEMU L’´ultima decisi´o a prendre era com executar el nostre codi. Com no tenim cap mena de hardware f´ısic pressupostat per executar el programa, es va haver d’analitzar quina opci´o de virtualitzaci´o seria la millor. Despr´es d’una cerca, es van trobar les seg¨uents opcions: QEMU ´ Es un simulador per excel·l`encia de RISC-V. Pot simular CPUs de 32 o 64 bits, ofereix diferents tipus de plaques segons les necessitats de cada projecte. Tamb´e ofereix un firmware que realitza el proc´es d’arrancada sense interacci´o de l’usuari, anomenat OpenSBI[26]. Spike ´ Es un programari de desenvolupament dissenyat per provar aplicacions Linux. Amb el seu ´us es pot configurar plaques virtuals simulant el m´on real i ofereix moltes personalitzacions per assemblar-se a aquest. Ofereix un servei d’implementaci´o de noves instruccions i registres de control[27]. Renode ´ Es un emulador d’entorns virtuals per a sistemes amb capacitat per emular un entorn productiu de RISC-V. Proporciona eines per seleccionar quina ISA es vol fer servir i facilita la creaci´o de noves instruccions i registres de control[28]. Donades aquestes opcions i analitzant els avantatges i inconvenients, es va decidir fer servir l’aplicaci´o QEMU com a emulador d’una placa f´ısica on s’execut´es el programa. Les caracter´ıstiques que m´es destaquen de QEMU poden ser el gran nombre d’usuaris i contribu¨ıdors actius, la seva alta capacitat de configuraci´o per permetre la personalitzaci´o de l’entorn, la compatibilitat amb el debbuger GDB per poder inspeccionar 8.2. DECISIONS D’ARQUITECTURA PRESSES 51 i analitzar l’estat del programa en qualsevol moment, entre d’altres. Tamb´e cal destacar, que un dels principals avantatges competitius dels altres dos software era els mecanismes que oferien per crear noves instruccions o registres de control i aquesta funcionalitat s’allunya de la finalitat del projecte. Cap´ıtol 9 Implementaci´o El codi de ZeOS-V est`a dividit en dues seccions: una primera on s’implementen totes les funcionalitats del sistema i una altra secci´o on es troba el codi a nivell d’usuari. Aquesta divisi´o ´es necess`aria per poder identificar on es troba el nostre codi d’usuari, ja que ´es essencial saber quina ´es la seva ubicaci´o en la mem`oria, per m´es endavant fer servir aquest coneixement durant la configuraci´o de la mem`oria virtual. En aquest apartat s’explicaran i justificaran totes les implementacions que de codi que s’han realitzat durant el projecte. 9.1. Organitzaci´o del codi Les solucions es troben implementades en fitxers de codi. Aquest codi es troba en dos llenguatges de programaci´o diferents. Trobem fitxers en llenguatge C per a codi d’alt nivell i fitxers en llenguatge assembler que serveixen per efectuar operacions directament connectades amb el hardware. La descripci´o de cada fitxer es mostra resumida a la taula 9.1 A m´es dels fitxers de codi, tamb´e trobem fitxers d’enlla¸c que serveixen per definir l’organitzaci´o de l’espai de mem`oria segons les nostres necessitats. Com tenim dos executables inicialment independents entre si, hi ha dos fitxers d’enlla¸c: bootsectV.ld on es descriu l’espai de mem`oria del codi de sistema, i userV.ld, on es descriu l’espai de mem`oria del codi d’usuari. 52 9.2. SISTEMA DE C ` ARREGA DEL SO 53 Fitxer Descripci´o/Funci´o bootsectV.ld Script d’enlla¸c a nivell de sistema. bootsectV.S Fitxer d’arrancada del sistema. build.c Codi que ajunta la part de sistema amb la part d’usuari. interruptHandler.c Implementaci´o les interrupcions. interrupt.S Gesti´o d’interrupcions. main.c Fitxer a nivell usuari. Makefile Script de compilaci´o. gestiodememoria.c Gesti´o i implementaci´o d’eines de mem`oria. memoriavirtual.c Gesti´o i implementaci´o de funcions de mem`oria virtual. privileges.S Funcions de canvi de privilegis. systemV.c Fitxer on s’inicialitzen totes les funcions de ZeoS. uart.S Codi on s’implementa l’escriptura per consola. userV.ld Script d’enlla¸c a nivell d’usuari. utils.c Fitxer on es troben diverses funcions ´utils. Taula 9.1: Taula de fitxers. Font: elaboraci´o pr`opia 9.2. Sistema de c`arrega del SO Tal com es va definir a l’inici, aquesta tasca embarca la implementaci´o correcta i les adaptacions necess`aries per fer que el sistema operatiu arranqui. A l’inici del projecte es generen els dos fitxers executables amb nom bootsecV iuserV. Aquests fitxers, que representen les dues parts del projecte, es generen amb dues etapes: la compilaci´o i l’enlla¸c. En primer lloc, es compilen. En segon lloc, es vinculen amb el fitxer d’enlla¸c i finalment, es creen els fitxers binaris. La creaci´o de dos fitxers en lloc d’un sol es deu a la manca d’un sistema de fitxers implementat en ZeOS-V. Aix`o implica que ´es necessari carregar ambd´os binaris a mem`oria per poder-los executar m´es tard. Aquest enfocament permet la transici´o del binari de sistema al binari d’usuari. En abs`encia d’un sistema de fitxers, el proc´es d’arrencada del sistema operatiu ZeOS-V es veu obligat a carregar inicialment el fitxer del sistema. Aquest fitxer del sistema cont´e els components essencials per a l’inici del sistema operatiu. No obstant aix`o, sense la c`arrega pr`evia del fitxer d’usuari a mem`oria, el sistema operatiu no tindria manera de localitzar i executar aquest segon binari, el qual cont´e les aplicacions i serveis destinats a l’usuari final. 54 CAP´ ITOL 9. IMPLEMENTACI ´ O El proc´es d’ajuntar el fitxer de sistema amb el fitxer d’usuari ´es molt similar a com ho feia ZeOS, utilitzant el codi de build.c, per`o en aquest cas adaptat a les nostres necessitats. En el cas del ZeOS, combinava en un sol executable un fitxer d’arrencada, el fitxer de sistema i el fitxer d’usuari. En el cas de ZeOS-V, les funcions del fitxer d’arrancada pr`opies de x86 no s´on necess`aries en RISC-V, per tant, es poden ometre. Resumint, el fitxer build.c rep com a par`ametres els noms dels dos fitxers executables creats anteriorment. Aquest els obre, mostra la mida per consola i despr´es escriu aquesta informaci´o a l’inici d’un nou fitxer. Aquest nou fitxer estar`a format pel contingut dels dos executables anteriors combinats i s’anomenar`a ZeOS-V. Aix´ı doncs, despr´es de la creaci´o del fitxer final, la distribuci´o del fitxer resultant quedaria segons la figura 9.1: Figura 9.1: Contingut del fitxer zeosV. Font: Elaboraci´o pr`opia Un cop creat el fitxer, podem procedir a executar-lo. Com ja s’ha justificat, utilitzem l’eina de virtualitzaci´o QEMU. Aquesta eina s’encarrega del proc´es d’inicialitzaci´o del sistema, emula l’entorn d’una placa amb l’arquitectura RISC-V i comen¸ca 9.2. SISTEMA DE C ` ARREGA DEL SO 55 a executar el codi que trobi a l’adre¸ca de mem`oria f´ısica 0x80000000. Previ al fitxer bootsectorV.ld, hem definit que l’entrada al sistema es far`a en l’etiqueta entry. Aquest fitxer, que forma part del proc´es de c`arrega del sistema operatiu, cont´e les instruccions a nivell d’assemblador necess`aries per inicialitzar correctament el sistema. Quan s’executa el fitxer ZeOS-V i arrenca el sistema, aquest s’inicialitza a nivell m`aquina, salta a l’etiqueta entry i el primer que fa ´es avan¸car dues posicions de mem`oria. Aix`o ´es a causa que, en aquelles posicions, durant l’execuci´o de build.c, s’ha escrit la mida de la mem`oria del sistema i de l’usuari. Posteriorment, assigna l’adre¸ca de mem`oria a la qual apuntar`a el stack pointer. Aquesta adre¸ca est`a definida en el fitxer systemV.c i est`a alineada a nivell de p`agina. _entry: j _realentry header: nop nop _realentry: la sp, stack li a2, 1024*4 add sp, sp, a2 #sp apunta al final del stack A continuaci´o, es desactiva la mem`oria virtual fins que es configuri i es realitzin les configuracions necess`aries per a les interrupcions. Un altre pas essencial, abans de canviar de nivell ´es assignar el nivell de protecci´o de la mem`oria. Per defecte, en RISC-V, la mem`oria est`a protegida de manera que nom´es es pot utilitzar en nivell machine. No obstant aix`o, gr`acies als registres pmpcfg ipmpaddr, podem modificar aix`o i permetre l’´us de mem`oria en nivell supervisor. li a0, 0x0 csrw satp, a0 #desactivem la paginacio li a0, 0x3fffffffffffff csrw pmpaddr0, a0 #asignem tot el rang d’adreces al grup 0 li a0, 0x0f csrw pmpcfg0, a0 #asignem els permisos NAPOT RWX El proc´es per saltar del nivell m`aquina al nivell supervisor ´es el seg¨uent: al registre de control mepc se li assigna l’adre¸ca de mem`oria on es troba la primera instrucci´o que volem que s’executi en nivell supervisor. Escrivim el canvi de nivell activant diversos bits 56 CAP´ ITOL 9. IMPLEMENTACI ´ O al registre d’estat mstatus i confirmem el salt a supervisor executant la instrucci´o mret. Els bits que cal activar del registre d’estat mstatus s´on els bits MPP. Aquests bits indiquen a quin nivell de prioritat saltara quan abandoni el nivell machine. Aix´ı doncs, assignem a MPP el valor 01 que ´es la codificaci´o de supervisor com es mostra a la taula 8.1. Per completar el salt executem la comanda mret que actualitza l’estat del programa amb el valor contingut a MPP. li t0, 0x1800 csrc mstatus, t0 #netejem els bits MPP li t0, 0x800 csrw mstatus, t0 #definim els bits MPP amb nivell supervisor la t0, start_kernel csrw mepc, t0 #li diem on vol que salti al mret Finalitzada aquesta tasca, ens trobem amb un sistema que engega, inicialitza el stack i salta a nivell supervisor. ´ Es en aquest moment quan el programa salta a la funci´o indicada pel CSR mepc. Aquesta funci´o s’encarrega d’inicialitzar totes les tasques del sistema operatiu. Trobem la rutina d’inicialitzaci´o de la mem`oria virtual amb les seves crides respectives i, tamb´e, l’activaci´o d’aquesta. Com a punt final, en el fitxer podem trobar la funci´o usermode, que en cas de completar la tasca de mem`oria virtual, est`a preparada per saltar a nivell usuari en cridar-la. 9.3. Mecanismes d’entrada i sortida i gesti´o d’interrupcions En aquest apartat s’explica com es realitza l’escriptura per consola i com es gestionen les interrupcions. 9.3.1. Mecanisme d’escriptura El mecanisme d’escriptura es troba basat en UART, que s´on les sigles d’Universal Asynchronous Receiver-Transmitter. Segons la seva definici´o, UART ´es un protocol hardware que fa servir comunicaci´o serial as´ıncrona amb una velocitat d’enviament de 9.3. MECANISMES D’ENTRADA I SORTIDA I GESTI ´ O D’INTERRUPCIONS 57 dades configurable. El fet que sigui as´ıncrona implica que no necessita cap senyal de rellotge per sincronitzar la sortida amb l’entrada a l’altre dispositiu[29]. En el cas del projecte s’ha activat l’escriptura de manera as´ıncrona, escrivint el valor que volem mostrar per pantalla a la posici´o 0x10000000L. Aquesta posici´o ´es on es troba la base de UART i, en escriure contingut en aquesta posici´o de mem`oria, es mostra per consola. Aix´ı doncs, gr`acies al codi de la funci´o print al fitxer uart.S podem realitzar escriptures. Aquestes es realitzen a nivell de car`acter, si volem escriure algun car`acter num`eric s’haur`a de traduir. Per realitzar la traducci´o trobem la funci´o itoahex del fitxer utils.c. 9.3.2. Configuraci´o i gesti´o d’interrupcions RISC-V t´e les interrupcions desactivades per defecte i, quan s’activen es troben gestionades pel nivell m´es alt de privilegis. Per activar les interrupcions, cal fer-ho en el nivell que volem que succeeixin i, s´ı aquest no ´es nivell machine delegar-la. Aix´ı doncs, al fitxer bootsectV.S delegem totes les interrupcions a nivell supervisor, excepte la timer interrupt i activem aquesta ´ultima a nivell machine, escrivint el registre de control mie. Posteriorment, activem la interrupci´o de software i l’externa a nivell supervisor, activant els bits al registre de control sie. li t0, 0x80 #activem les interrupcions de csrw mie, t0 #rellotge a nivell machine li a0, 0x0ff #definim la delegacio csrw mideleg, a0 #d’interrupcions i excepcions li a0, 0xffff csrw medeleg, a0 li t0, 0x022 #activem la external csrw sie,t0 #i software interrupt Les interrupcions es delegen perqu`e volem que el tractament d’aquestes el realitzi el sistema operatiu que es troba en nivell supervisor. La interrupci´o de temps, en canvi, per la naturalesa del sistema, ja que nom´es t´e variables de tipus machine, com s´on mtime i mtimecmp, sempre salta en tipus machine. Per aix`o cal enviar una software interrupt a nivell supervisor perqu`e la gestioni el sistema operatiu. 64 CAP´ ITOL 9. IMPLEMENTACI ´ O Primer caldria implementar una funci´o que crees un proc´es diferent del que est`a corrents, inicialitzes una taula de p`agines i li dones un espai de mem`oria entre d’altres. Posteriorment per poder canviar de processos caldria implementar una funci´o que guardes l’estat del proc´es actual, canvies la taula de p`agines per la pr`opia del proc´es i quan es realitzessin els canvis saltes a l’adre¸ca indicada. Cap´ıtol 10 Conclusi´o i treball futur En aquest apartat es resumiran els resultats i la feina feta durant el treball de fi de grau. 10.1. Conclusi´o En aquest projecte es pretenia implementar els seg¨uents aspectes en l’arquitectura RISC-V Durant la durada d’aquest projecte s’ha aconseguit obtenir i implementar de la forma esperada el sistema de c`arrega i els mecanismes d’entrada i sortida i excepcions. No obstant aix`o, la implementaci´o dels mecanismes de gesti´o de mem`oria no s’ha pogut completar totalment, i a conseq¨u`encia els mecanismes de gesti´o de processos tampoc. La tasca del sistema de c`arrega es considera totalment assolida, trobem un sistema operatiu que engega, inicialitza diferents camps pel seu correcte funcionament i salta al sistema operatiu. Per tant, aquest objectiu ha estat completament realitzat. Pel que fa als mecanismes d’entrada, s’ha implementat el protocol UART, que permet escriure contingut per consola, facilitant aix´ı la comunicaci´o del sistema operatiu amb l’usuari final. Les interrupcions tamb´e s’han aconseguit inicialitzar, definir el seu tractament i gestionar tal com es va proposar. Per tant, aquest objectiu es pot considerar complert. Els mecanismes de gesti´o de mem`oria involucraven la inicialitzaci´o i posada en funcionament de la mem`oria virtual. Aquesta tasca ha estat m´es complexa del que es va preveure a l’inici del projecte i ha necessitat una dedicaci´o major de la pressupostada. Encara, tot i aix`o, no s’ha aconseguit finalitzar tot el proc´es i no funciona de la manera esperada. 65 66 CAP´ ITOL 10. CONCLUSI ´ O I TREBALL FUTUR Aquest situaci´o ha desencadenat en qu`e no fos possible dedicar el temps necessari per desenvolupar els mecanismes de gesti´o de processos. Es va decidir que fins que no es complet´es la tasca anterior, no es comen¸caria la seg¨uent. Aix´ı doncs, encara la gesti´o de processos no dep`en de la mem`oria virtual, no s’ha pogut dedicar temps i, per tant, no est`a inicialitzada. Fora d’aquests objectius t`ecnics el projecte tamb´e tenia marcat la finalitat d’aconseguir un treball amb un codi llegible i una mem`oria d’on es pogu´es aprendre i fomentar el coneixement. Considero que aquest objectiu s’ha aconseguit d’una forma notable, ja que s’han dedicat molts esfor¸cos, i aix´ı es veu reflectit. D’aquesta manera es pot considerar que ZeOS-V ´es una base sobre la qual ´es relativament senzill treballar i que disposa d’una bona documentaci´o que l’acompanya. Tot i aquests contratemps, es pot considerar que la valoraci´o final del projecte ”Porting ZeOS to RISC-V ”´es positiva. Durant aquest projecte s’ha aconseguit fer un port funcional que pot ser la base a millorar perqu`e esdevingui una eina educativa. Personalment, valoro molt positivament el resultat del treball, ja que aquest m’ha obligat a aprendre i trobar solucions a problemes cada dia, i m’ha for¸cat adquirir un coneixement molt extens no nom´es de l’arquitectura RISC-V que no disposava a l’inici d’aquest. 10.2. Treball futur Com en tot projecte, ZeOS-V t´e la possibilitat de continuar creixent, i per aix`o es poden definir diverses branques cap on continuar al futur. El cam´ı m´es l`ogic ´es finalitzar les tasques proposades que, per diverses limitacions de temps no s’han pogut completar. Els primers passos serien finalitzar la implementaci´o de la mem`oria virtual i aconseguir implementar tots els mecanismes de gesti´o de processos que s’havien plantejat inicialment. En aconseguir aquestes bases, s’assoliria l’objectiu final del projecte: proporcionar una eina que faciliti l’aprenentatge de sistemes operatius i la seva arquitectura per als alumnes de la Facultat d’Inform`atica de Barcelona. Altres possibles l´ınies de treball sobre ZeOS-V inclouen la creaci´o d’un sistema de fitxers, la implementaci´o de crides al sistema o ecalls i la implementaci´o d’eines com fork per permetre l’execuci´o simult`ania de diversos processos. Bibliografia [1] Javier Marquez. RISC-V acaba de conseguir el apoyo de cinco empresas de primer nivel para competir con ARM: este es el... 14 d’ag. de 2023. url:https:// www.xataka.com/componentes/riscvacabaconseguirapoyocincoempresas-primer-nivel-para-competir-arm-este-plan (cons. 05-03-2024). [2] Juan Jos´e Costa Prats. Sistemes Operatius 2. 2023. url:https://docencia. ac.upc.edu/FIB/grau/SO2/ (cons. 27-02-2024). [3] Alex Pajuelo i Juanjo Costa. Sistemes Operatius Avan¸cats. 2023. url:https: //docencia.ac.upc.edu/FIB/grau/SOA/ (cons. 27-02-2024). [4] Daniel Arg¨uello, Higinio Facchini i Santiago P´erez. An´alisis y Simulaci´on de procesadores RISC-V en plataforma ISA abierta. Abr. de 2021. (Cons. 05-03-2024). [5] Tecnologies de la informaci´o.url:https://www.fib.upc.edu/ca/estudis/ graus/grau-en-enginyeria-informatica/pla-destudis/especialitats/ tecnologies-de-la-informacio (cons. 05-03-2024). [6] Albert Segura Salvador. “Port de zeOS a arquitectura ARM: Raspberry pi”. Tesi doct. UPC, Facultat d’Inform`atica de Barcelona, juny de 2014. url:http: //hdl.handle.net/2099.1/23494. [7] ARM/RaspberryPi - Ubuntu Wiki.url:https : / / wiki . ubuntu . com / ARM / RaspberryPi (cons. 07-03-2024). [8] “XV6: a simple, unix-like teaching operating system”. A: pdos.csail.mit. (31 d’ag. de 2020). url:https://pdos.csail.mit.edu/6.S081/2020/xv6/book-riscvrev1.pdf. [9] Yolanda Becerra, Juan Jos´e Costa i Alex Pajuelo. Zeos. 2023. url:https : / / docencia . ac . upc . edu / FIB / grau / SOA / documents / Zeos . pdf (cons. 27-02-2024). [10] Shreyas Sharma. RISC-V Architecture: A Comprehensive Guide to the OpenSource ISA. 6 de mar¸c de 2024. url:https://www.wevolver.com/article/ risc-v-architecture-a-comprehensive-guide-to-the-open-source-isa. 67 68 BIBLIOGRAFIA [11] RISC-V, c´odigo abierto para transformar radicalmente la industria de los chips. 27 de gen. de 2023. url:https://www.technologyreview.es/s/15050/riscv-codigo-abierto-para-transformar-radicalmente-la-industria-delos-chips (cons. 27-02-2024). [12] Welcome to QEMU’s documentation! — QEMU documentation.url:https: //www.qemu.org/docs/master/ (cons. 18-03-2024). [13] Alba Ortiz. Monday: ¿qu´e es y para qu´e sirve? 12 d’abr. de 2023. url:https: //www.inboundcycle.com/blog-de-inbound-marketing/monday-que-espara-que-sirve (cons. 07-03-2024). [14] Frankier Flores. Qu´e es Visual Studio Code y qu´e ventajas ofrece. 13 d’abr. de 2023. url:https://openwebinars.net/blog/que-es-visual-studiocode-y-que-ventajas-ofrece/ (cons. 07-03-2024). [15] Y´ubal Fern´andez. Qu´e es Github y qu´e es lo que le ofrece a los desarrolladores. url:https://www.xataka.com/basics/que-github-que-que-le-ofrece-adesarrolladores (cons. 07-03-2024). [16] Pr`actiques en empresa.url:https : / / www . fib . upc . edu / ca / empresa / practiques-en-empresa (cons. 06-03-2024). [17] Gr`affica i Gr`affica. ¿Cu´anto dura realmente tu ordenador? Claves para maximizar su vida ´util por Jordi Garc´ıa de Kingston. 16 de nov. de 2023. url: https://graffica.info/cuanto-dura-realmente-tu-ordenador-clavespara-maximizar-su-vidautil-porjordi-garcia-de-kingston/ (cons. 11-03-2024). [18] Concha Molina. ¿Cu´anto Consumo el Ordenador? Sal de dudas. 13 de des. de 2023. url:https : / / ganaenergia . com / blog / cuanto - consume - un - ordenador/ (cons. 11-03-2024). [19] Espa˜na - Precios de la electricidad de los hogares 2023.url:https://datosmacro. expansion.com/energia-y-medio-ambiente/electricidad-precio-hogares/ espana (cons. 11-03-2024). [20] EDINSOST, projecte dinnovaci´o educativa.url:https://is.upc.edu/ca/ noticies/edinsost-projecte-dinnovacio-educativa (cons. 10-03-2024). [21] Normativa TFG FIB. 29 de gen. de 2020. url:https://www.fib.upc.edu/ sites/fib/files/documents/estudis/normativa-tfg-mencio-addicionalgei.pdf (cons. 23-05-2024). [22] Gavin Wright. X86-64. 13 de nov. de 2023. url:https://www.techtarget. com/whatis/definition/x86-64 (cons. 01-06-2024). [23] Mark Reynolds. 8-bit PIC®MCUs - Developer Help.url:https://developerhelp. microchip . com / xwiki / bin / view / products / mcu - mpu / 8bit - pic/ (cons. 02-06-2024). BIBLIOGRAFIA 69 [24] GeeksforGeeks. RISC and CISC in computer organization. 13 de mar¸c de 2024. url:https://www.geeksforgeeks.org/computer-organization-risc-andcisc/ (cons. 01-06-2024). [25] The RISC-V Instruction Set Manual, Volume II: Privileged Architecture, Document version 20211203. Vol. 2. Andrew Waterman, Krste Asanovi´c, i John Hauser, des. de 2021. url:https : / / tools . cloudbear . ru / docs / riscv - privileged-1.12-20211203.pdf. [26] RISC-V System emulator — QEMU documentation.url:https://www.qemu. org/docs/master/system/target-riscv.html (cons. 12-06-2024). [27] 1.1. RISC-V Customization — RISC-V Spike SDK latest documentation.url: https://rssdoc.readthedocs.io/en/latest/Customization/RISCVCustomization.html (cons. 12-06-2024). [28] Configuring a RISC-V CPU - Renode - documentation.url:https://renode. readthedocs.io/en/latest/basic/configuring-a-risc-v-cpu.html (cons. 12-06-2024). [29] Pe˜na. “UART: A Hardware Communication Protocol Understanding Universal Asynchronous Receiver/Transmitter”. A: Analog 54 (des. de 2020). url:https: //www.analog.com/media/en/analog-dialogue/volume-54/number-4/uarta-hardware-communication-protocol.pdf.