{"id":19415726,"url":"https://github.com/shivansh/nachos-implementation","last_synced_at":"2026-06-17T17:32:21.191Z","repository":{"id":67090503,"uuid":"102327927","full_name":"shivansh/NachOS-implementation","owner":"shivansh","description":"Operating System CS330A assignments based on NachOS","archived":false,"fork":false,"pushed_at":"2017-11-15T17:10:36.000Z","size":1193,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":3,"default_branch":"assignment2","last_synced_at":"2025-02-25T03:14:45.848Z","etag":null,"topics":["nachos","operating-system"],"latest_commit_sha":null,"homepage":null,"language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/shivansh.png","metadata":{"files":{"readme":"README","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-09-04T06:46:34.000Z","updated_at":"2017-12-08T15:28:28.000Z","dependencies_parsed_at":"2023-05-06T05:16:51.497Z","dependency_job_id":null,"html_url":"https://github.com/shivansh/NachOS-implementation","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/shivansh/NachOS-implementation","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/shivansh%2FNachOS-implementation","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/shivansh%2FNachOS-implementation/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/shivansh%2FNachOS-implementation/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/shivansh%2FNachOS-implementation/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/shivansh","download_url":"https://codeload.github.com/shivansh/NachOS-implementation/tar.gz/refs/heads/assignment2","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/shivansh%2FNachOS-implementation/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34459430,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-17T02:00:05.408Z","response_time":127,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["nachos","operating-system"],"created_at":"2024-11-10T12:44:24.649Z","updated_at":"2026-06-17T17:32:21.168Z","avatar_url":"https://github.com/shivansh.png","language":"C++","funding_links":[],"categories":[],"sub_categories":[],"readme":"This README file describes the Nachos release.  Comments, questions,\nand bug reports are always welcome, and can be directed to \nnachos@cs.berkeley.edu (for now, an alias to just me, Tom Anderson), or \nto the alt.os.nachos newsgroup.\n\nNachos is instructional software for teaching undergraduate, and potentially\ngraduate, level operating systems courses.  The Nachos distribution\ncomes with: \n\n   an overview paper\n   simple baseline code for a working operating system\n   a simulator for a generic personal computer/workstation\n   sample assignments\n   a C++ primer (Nachos is written in an easy-to-learn subset of C++, \n     and the primer helps teach C programmers our subset)\n\nThe assignments illustrate and explore all areas of modern operating\nsystems, including threads and concurrency, multiprogramming, \nsystem calls, virtual memory, software-loaded TLB's, file systems, \nnetwork protocols, remote procedure call, and distributed systems.\n\nThe most up to date version of nachos is linked to the file called, \nnachos.tar.Z.  On Jan. 20, 1993, this version was nachos-3.1.tar.Z,\nbut it will be periodically updated as bugs are fixed and features added.\nREMEMBER TO TURN BINARY MODE ON WHEN RETRIEVING .Z FILES.\n\nTo get started, you should:\n  1. use ftp to fetch the nachos.tar.Z file (turning on binary mode first)\n  2. uncompress nachos.tar.Z\n  3. tar -xf nachos.tar\n  4. lpr nachos.ps  -- print out the paper describing nachos\n  5. lpr doc/*.ps  -- print out the sample assignments\n  6. cd code; make print -- print out the nachos source code\n  7. cd code/c++example; lpr *.ps *.h *.cc -- print out C++ primer\n  8. if you have no DEC MIPS workstations available at your site, you \n      will need to install the gcc cross-compiler on your system.  See\n      the instructions at the end of this file.\n  9. edit code/Makefile.dep to specify host machine type \n     if cross-compiling (cf. step 8) you also need to:\n        edit code/test/Makefile and code/bin/Makefile\n  10. cd code; make all -- compile nachos source code\n\nVersion 3 has been used for a semester at Berkeley by over a \nhundred students, so most of the bugs are out of the system.\nHowever, there are likely to be some remaining problems; if you\nfind these, please send e-mail to nachos@cs.berkeley.edu (particularly\nif you have a fix :-).\n\nAt present, Nachos runs on several platforms, including: \n  DEC MIPS, running Ultrix\n  SUN SPARCstations (only tested on SunOS, not Solaris, though)\n  HP PA-RISC, running HP-UX\n  386 boxes, running 386BSD UNIX or FreeBSD\n\nNotably we do not currently support:\n  PC Windows \n  Macintosh\n  non-SPARC SUN workstations\nHowever, PC and Macintosh support is under development.  The main change\nthat you need to make to support another platform is an implementation\nof the low-level machine-dependent context switch code, in threads/switch.s.\nSeveral example architectures are now supported in switch.s.\n\nThe basic Nachos system was written for a MIPS workstation.  It has\nbeen ported to other platforms, but as of now, there are a few gotchas.\nThe Nachos kernel and machine simulator run directly on the host machine,\nbut user-level programs running on top of Nachos are simulated instruction-by-\ninstruction.  The simulator assumes MIPS object code, in little endian format.\nIt would take much more work to complete the port and change the CPU \nsimulator to simulate other instruction sets (although this is under\ninvestigation).  Keeping the MIPS CPU causes a few problems:\n\n1) You have to generate user-level code for the simulated machine.\nIf you have a heterogeneous environment with some MIPS and non-MIPS \nworkstations, this isn't so hard -- students only need to compile a few \nsmall user programs.  But if you only have non-MIPS machines, you need to \nget gcc to cross-compile to the DEC MIPS.  Gcc only recently has been fixed \nto support this, and the instructions for how to do this are listed below.\nIf you are unable to get the cross-compiler to work, do not despair.\nThe distribution comes with a few simple user programs (pre-compiled to\nMIPS object code) that students can use to test out Nachos kernel services.\n\n2) The Nachos kernel runs runs native mode while the user programs\nruns on the simulated CPU.  This is a little weird on the non-MIPS workstations\nbecause the user programs are using little endian (typically) and the kernel is\nusing big endian.  Some information (such as the argv[] array) that\nis passed between the kernel and the user though user memory must be\nbyte swapped.  (Unfortunately, this isn't as easy to fix as simply\ncross-compiling to the SGI MIPS, which is big endian; in a few places,\nthe simulation assumes little endian format.  We're working on fixing this.) \n\nThe end of this file contains the procedure for constructing a cross-compiler\nto the MIPS, using the gcc toolkit.\n\nVersion 3.1 Release Notes\n--------------------------\n\nPrimarily, fixed up problems with cross-compiled environment.\n\n\nVersion 3 Release Notes\n-----------------------\n\nNote that version 2 is still available, in \n  ftp.cs.berkeley.edu:ucb/nachos/version2\n\n\nThere are several major changes for version 3, relative to earlier versions:\n\n1. Extensive comments.  All procedures and data structures now have\n  commented explanations.  Hopefully, this will help make it easier for\n  students (and professors) to read and understand the baseline system.\n  In writing the comments, I realized that we continue to lack an \"overall\" \n  roadmap to the system; Nachos deals with conceptually hard issues\n  in a bunch of places in the code, and I think students would find a roadmap\n  helpful.  I am plotting how to do this; for now, my apologies for \n  anything that seems unduly complex and opaque.  Any suggestions\n  for places that need better explanations are welcome.\n\n2. Modifications to improve portability, along with ports to several more\n  platforms.  All machine dependencies are now isolated into only a few \n  locations (primarily, switch.h/switch.s, and sysdep.h/sysdep.cc), making\n  it much easier to port Nachos to new platforms.  This is evidenced by\n  the fact that the HP PA-RISC and 386UNIX ports were each completed in a\n  few days worth of concentrated effort.  There is now a common code base,\n  so the separate code base for SPARCs in Version 2 is no longer needed.\n\n3. The directory structure has been simplified and made more generic.\n  Instead of directories named for the assignments that I give, I have\n  named them after topic areas: threads, userprog, vm, filesys, and network.\n  Each represents a single assignment, but there is a large amount\n  of flexibility now in choosing the order to cover these topics.\n  Here is the dependency graph:\n\n  threads -\u003e userprog -\u003e vm\n\t  -\u003e filesys\n\t  -\u003e network\n\n  In other words, all other assignments rely on you covering threads first, \n  but the next assignment after that could be either multiprogramming,\n  the file system, or network support.  The only other constraint is that\n  the virtual memory stuff relies on the user programming assignment\n  being completed [NOTE however that we provide no code for the virtual\n  memory assignment, so it could be easily folded into the userprog \n  assignment.]\n\n  Also, the userprog and vm assignments rely on there being a file system\n  to fetch executables and to serve as backing store for virtual memory pages.\n  A \"stub\" version of the file system is provided to allow these assignments\n  to be done first; the stub version is not needed if file systems\n  are covered before user programming and virtual memory.\n\n4. More extensive options with respect to the sample assignments.\n  I have now three semesters of experience in teaching with Nachos.\n  My assignments have varied slightly from semester to semester, and\n  I have now compiled all of these versions into the sample assignments\n  [with comments as to which portions I assigned in any given semester].\n  The expectation is that you will subset the portion that you find most\n  interesting; if you have suggestions for what I might include in the\n  sample assignments, I would be happy to hear them.  Hopefully, from \n  this point on, any changes to the sample assignments will only be to add \n  further options.\n\n  Over the long term, it seems to me we will each need to vary the\n  assignments, to prevent widespread sharing of solution sets.\n\n5. Support for a software-loaded Translation Lookaside Buffer.  This\n  can be disabled (turning the machine simulation back to using simple\n  linear page tables) for those who want to avoid the added complexity,\n  but it is a feature of many modern architectures, and I think it\n  is a good illustration of caching issues.  This is the only substantive\n  change for this version.\n\n  One advantage is that it allows a *lot* more flexibility in the \n  VM assignment -- for instance, a student could build a flat one-level \n  page table, segmentation plus paging, an inverted page table, etc.  \n  This is all without modifying the hardware emulation.  Also, this could \n  also lead to issues such as shared memory segments between address spaces,\n  which couldn't be supported in the current model.\n\n  One consequence is that there are now a new object code format for\n  Nachos user programs.  The standard UNIX format, COFF, is way too \n  complicated.  I have a simplified format, NOFF (Nachos Object Format),\n  which simply identifies the code, data, and bss segments.  By default, \n  these segments are concatenated together (as in earlier versions of\n  Nachos), beginning at location 0, but with the software loaded TLB,\n  you have the flexibility to do something smarter.\n\n  The converter from COFF to NOFF has been ported to run on all of the\n  supported machines.\n\n\nFuture plans:\n\n1. Known bugs \n    a. Nachos has a memory leak that causes it to increase its \n       virtual memory size over time, even if Nachos is not doing anything. \n\n2. Planned ports (other suggestions welcome):\n    a. M/S Windows (somewhere between Jan and June 94)\n    b. Macintosh (ditto)\n    c. DEC Alpha (as soon as it gets a reliable g++)\n\n3. Nachos user's guide and roadmap (not under development yet, so \n     definite target date.  Maybe end of summer 94)\n  This would come in two parts -- first, a student guide that\n  would walk students through the baseline code, explaining how\n  the system works, and also to explain a bit of the underlying machine \n  emulation.  At Berkeley, we devote about an hour per week in section \n  to going through the code, but it would be helpful (particularly for \n  those schools without discussion sections) to have this written down.\n  I've found in all three semesters I've taught the course that students really \n  do end up repeating many of the same questions.\n\n  The second part would be an instructor's guide -- how do you\n  get Nachos up and running on various systems, how the internals\n  of the machine emulation work, how much time each of the assignments\n  takes, etc.  \n\n  The result would replace the existing sample assignments with \n  something more helpful. \n  (The downside is that some parts of Nachos build on other parts,\n  so I have to be clear about these dependencies.)\n\n4. New development -- this is in semi-priority order.\n\na. Modify the network simulation to be performance accurate, by\n   using Chandy-Misra conservative simulation techniques to\n   keep the clocks on each simulated Nachos machine in sync.  \n   I have a prototype implementation of this, so this isn't all that \n   difficult.  I'll make sure to leave an option to disable this, to go back\n   to the way the simulation works now, for backward compatibility.\n\nb. Modify the file system to do write ahead logging for reliability.\n   I talk about transactions in my class, and having example code\n   would be really useful, at least for me.  Again, I have a prototype \n   implementation of this, and I'll make sure that it can be disabled.\n\nc. Write an RPC stub generator (actually, simplify the one used in Mach,\n   and convert it to generate Nachos network messages).  I think\n   the students would get a lot out of seeing a working RPC system,\n   and I think I can do this in a way that would be simple enough\n   for most students to easily understand.  As it stands, I have\n   the feeling most of my students don't understand the mechanics of\n   setting up an RPC connection, which at present, I can only describe\n   verbally.\n\n   At first, I'm likely to do only a C-to-C stub generator, rather\n   than a C++ stub generator.  Although the latter would obviously fit \n   into Nachos better, it's also harder!\n\nd. Modify Nachos to insert interrupts at arbitrary points in the code.\n   Currently, interrupts (such as timer expiring) only occur when \n   Nachos is executing user-level code, or when the Nachos kernel calls\n   the enable interrupt routine.  A different (better?) approach would\n   be to check for interrupts on every procedure entry within the Nachos\n   kernel; we could do this by modifying the compiler-inserted \"mcount\" \n   routine for performance profiling.\n\nAgain, comments on how to improve Nachos are always welcome.\n\nTom Anderson\ntea@cs.berkeley.edu\nnachos@cs.berkeley.edu\n\n\n\nBuilding a gcc cross-compiler\n-----------------------------\nThe gcc distribution has fairly good documentation on how to do this,\nbut since I walked through it, I figured I would just give you a recipe.\nThe following works from the SPARC to the DEC MIPS; if you want a \ncross-compiler to a different platform (eg, the HP Snakes), you'll need\nto just alter this procedure slightly.\n\nNOTE: we don't need the full cross-compiled environment.  In particular,\nNachos user programs include none of the standard UNIX library or system\ncall stubs, and it assumes its own crt.s (assembly language assist for\nstarting a program running).  This makes this significantly simpler,\nand it vastly reduces the size of (and overall simplifies) the resulting \nobject code.\n\n# To build a cross-compiler using the gnu tools:\n\n# grab the tools via anonymous ftp\n% ftp prep.ai.mit.edu\n\n ftp\u003e cd /pub/gnu\n# REMEMBER TO SET BINARY MODE\n ftp\u003e binary\n# get gcc, binutils, gas -- these or later versions\n ftp\u003e get gcc-2.4.5.tar.gz\t\n ftp\u003e get binutils-2.2.1.tar.gz\n ftp\u003e get gas-2.1.1.tar.gz\n ftp\u003e quit\n\n# gunzip decompresses the tar files\n# you can also get gunzip from prep.ai.mit.edu\n% gunzip *\n\n# where the executables are to go, usually /usr/local\n% setenv gccLocal /usr/local \t\n\n# de-tar the files\n% tar -xf gas-2.1.1.tar\n% tar -xf binutils-2.2.1.tar\n% tar -xf gcc-2.4.5.tar\n% mkdir tar\n% mv *.tar tar\n\n# build gas and binutils first\n% cd gas* \n\n% ./configure --host=sparc-sun-sunos4.1.3 --target=decstation-ultrix \n\t--prefix $gccLocal\n\n% make\n\n% make install\n\n% cd ../bin* \n\n% ./configure --host=sparc-sun-sunos4.1.3 --target=decstation-ultrix \n\t--prefix $gccLocal\n\n% make\n\n% make install\n\n% cd ../gcc*\n\n% ./configure --host=sparc-sun-sunos4.1.3 --target=decstation-ultrix\n\t--with-gnu-as --with-gnu-ld --prefix $gccLocal\n   \t--local-prefix $gccLocal\n\n# Afer building the cross-compiler, the Makefile is going to try to\n# use it to build a set of libraries, and a couple test cases.\n# Unfortunately, the libraries depend on UNIX headers (such as stdio.h).\n#\n# Since Nachos user programs don't need these headers (they'd be\n# wrong anyway, since Nachos doesn't support the standard UNIX syscall\n# interface), we need to fake out the Makefile.\n\n# create a dummy lib files, to keep make happy \n% ar r libgcc.a /dev/null\n% ar r libgcc2.a /dev/null\n\n# Delete the following lines from the Makefile\n#     ENQUIRE = enquire\n#     CROSS_TEST = cross-test\n% vi Makefile\n\n% make LANGUAGES=c\n\n# at this point you may get an error building libgcc2; ignore it and proceed.\n\n% make install LANGUAGES=c\n\n# at this point, the cross-compiler and subsidiary tools\n# are now installed, in $gccLocal/decstation-ultrix/bin\n\n# one last thing --\n#   you need to edit nachos/code/test/Makefile to use the\n#   gcc cross-compilation tools you have just built, instead of using \n#   normal gcc.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fshivansh%2Fnachos-implementation","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fshivansh%2Fnachos-implementation","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fshivansh%2Fnachos-implementation/lists"}