V9@Web (STILL UNDER ACTIVE DEVELOPMENT)

What is this?

An in-browser operating system learning platform!

Not really production-ready yet. But stay tuned, we'll launch it before November.

But why?

It can be tedious to set up a local environment for toying with operating systems. For example, you need qemu, gcc-multilib, and many other tools. Therefore we aim to provide an in-browser experience for all those interested in learning operating systems.

Even if you manage to set up a proper environment. Chances are that the operating systems you are learning are built for real-life hardwares like x86. As a result, you will be wasting much time dealing with dirty hardware details. Though it can be beneficial, it is daunting especially for beginners. Hence we aim to also use a much more simplified simulated hardware.

Basic Usage

The Step button is for single stepping. Continue button is for running until encountering a breakpoint. Run is similar to Continue, but ignores breakpoints. The three can be used in a mixed way. And yes, you can set breakpoints while it is running.

You can go to Terminal panel to interact with it while it is running.

Demo

Choose your target lab.

Browse files of your Lab.

Run your lab: xv6 or ucore.

Run your lab until a break point.

Single step your lab.

Inspect variable values at runtime.

Save all your hard work.

Continue your work next time.

Want to Create a New Lab? Write a Config File for Your Sources!

Development

How is the simulator implemented?

The JavaScript-implemented hardware simulator is manually translated from its C-implemented origin at swieros. The reason we don't use tools such as Emscripten for this is that we find that Emscripten-converted code cannot fully interact with users. Though the reason is unclear.

And it also becomes much easier for us to add dubegging support once we have implemented our own JavaScript version.

How is the debugger implemented?

This is documented in debugger.md.

Related Work

• The JavaScript-implemented hardware simulator is manually translated from its C-implemented origin at swieros.
• The C compiler is also based on that of swieros.
• The simplified xv6 operating system is again from swieros.
• Emscripten is used for converting the C-implemented C compiler to a JavaScript one.
• The C preprocessor is from acgessler.
• The ucore operating system is ported by Leonard Xu and Xu Han, see v9-ucore.
• In fact, we have a second backend that uses a LLVM-based C compiler. See Alex Wang's work.
• For this second backend, a different instruction set and hardware simulator is used. These are done by Paul Zhu.
• We use CodeMirror as an editor. JSZip and FileSaver.js for saving files.

Future Work

The C Preprocessor

Currently, variadic macros, __line__, and __file___ are not supported. But don't worry, we are working on them.

The C Compiler

Error messages from the C compiler of swieros are usually quite useless. And it also lack support of some ANSI C features. Although our other LLVM-based backend can overcome these issues, it turns out that the other backend requires much work from a server.

We plan to overcoem these by either:

• Improve the existing C compiler from swieros.
• Or port Tiny C Compiler to our platform, and put it at the front end.

Reliability

The ucore system is recently added, and hasn't been thoroughly tested yet. As a result, we are afraid that there might be some bugs in our hardware simulator and the ported system.