An overview of the function of each file in JSMIPS:

  • nomath.js : Non-Overflowing MATH. Implementation of 32-bit integer math primitives for JavaScript? which do not overflow the size of an integer (or, more accurately, overflow from positive to negative and negative to positive, as is expected of hardware integers)
  • vmem.js : Virtual MEMory. Provides an implementation of basic virtual memory and paging.
  • mips.js : Heart of JSMIPS, the MIPS simulator. Includes the MIPS prototype, which contains a run() function which runs some iterations of the MIPS simulation as well as the jitize() function which JITs a particular portion of the MIPS code and loadELF() which loads static ELF binaries into a MIPS object. The MIPS prototype is extended in other .js files. Many core system calls are also implemented in this file, including but not limited to exit(), fork(), getpid(), get[e]{u,g}id() (stubs), sbrk(), and unimpl(), which is simply the stub that unimplemented system calls call to report that they're unimplemented.
  • errno.js : Simply a translation of the E* #defines in errno.h
  • vt100.js : An implementation of a vt100 terminal for JavaScript? originally written by Frank Bi.
  • vtconsole.js : A wrapper around vt100.js to provide I/O functions as expected by JSMIPS.
  • mipsio.js : Basic I/O system calls and functionality, such as read(), write(), pipes, stdin/stdout.
  • termios.js : TERMinal I/O System calls (tcgetattr and tcsetattr)
  • signals.js : Extremely primitive implementation of signals. Really only reliably supports sending SIGCHLD when a child process dies.
  • base64dec.js : A simple base64 decoder, required for filesystem.js 's remote functionality.
  • filesystem.js : Implementation of the filesystem and related system calls, including most importantly open(). This also includes support for on-the-fly remote downloading of files (via XHR/AJAX/Your-Favorite-Web-2.0-Name-Here).
  • server/dir.php : The server-side of the XHR file downloading protocol.

These files are fairly disjunct, so in general you can work on one component without disturbing the others.

The C end is based on the binutils/GCC/newlib toolchain. The patches to binutils and GCC are inconsequential (basically just recognizing JSMIPS as a system), but the patch to newlib is more significant, as it includes the implementation of the C component of all system calls.

The rest of the environment of JSMIPS is generally the heirloom toolchest (as it's fairly easy to compile on wonky systems such as JSMIPS), from  http://heirloom.sourceforge.net/ . The patches to it are basically to extract portions that don't work (yet?) on JSMIPS.