I initially used a Macbook Air as my main machine for university work and therefore also for the Operating Systems course. Now, you will probably be aware of this, but the Air is not the fastest laptop in town. Given that it was necessary to run the SWEB, the given operating system via
qemu in a Linux virtual machine, things were already quite slow.
Furthermore, testing my group’s Swapping implementation was one of the slowest things I came across and I desperately wanted to work with a faster setup. I learned that at one point in the past SWEB had been compilable and runable on OS X.
I even stumbled across Stefan‘s build scripts on the SWEB wiki. Those were written for a system that had been migrated from several older versions all the way to OS 10.6. My machine had 10.7 as of the time of my first trials and there was no more Apple provided build of
gcc available since Apple had moved on to use
clang as part of their switch to
Back then I spent two evenings with Thomas trying to get a cross compiler up and running to compile on OS X. We failed on that. Soon after that I spent some time together with Daniel who is the main person responsible for the Operating System practicals and we managed to successfully and reproducably build a working cross compiler. With that, one could build and run SWEB on OS X. Some modifications to the build scripts as well as minor modifications to the code base were necessary, but after writing those patches, one could check out and build the system provided by the IAIK.
And, well… I didn’t take the course that year, the course staff updated things in the code base and nobody bothered to check if the Mac build was indeed still building. Suffice to say another round of small fixes was required and I sat together with Daniel again. He’s the expert, I’m just the motivated Mac guy. I was asked whether I’d finally try the course again, given that I’m preparing the Mac build again. My answer was that I’d do so if we get it working before the term started and we did, so there’s that.
- Xcode command line tools
- git (included in Xcode command line tools)
- homebrew: tap ghostlyrics/homebrew-sweb
- homebrew: packages: cloog, qemu, cmake, sweb-gcc
Feel free to skip ahead to the next section if you know how to install those things.
Download and install Xcode from Apple. If you don’t have differing requirements, the stable version is strongly suggested.
Xcode command line tools
Apple stopped shipping its command line tools by default with Xcode. These are necessary to build things with our third party package manager of choice, homebrew. Install them via the wizard triggered by the following command in Terminal.app.
Unfortunately OS X does not ship with a package manager. Such a program is quite helpful navigating the world of open source software – we use homebrew to install the dependencies of SWEB as well as the cross compiler I have prepared with extensive help from Daniel.
Install homebrew via the instructions at their site - it’s easy. Again, you’re instructed to paste one line into Terminal.app.
Since the main architecture your SWEB runs on is
i686-linux-gnu you will need a toolchain that builds its executables for said architecture.
To activate the package source enter the following command:
brew tap ghostlyrics/homebrew-sweb
Though an interesting experiment, we did not bother using a
clang based toolchain since SWEB does not compile and run well on Linux with clang. Therefore it would’ve been a twofold effort to:
- make SWEB build with
- build a
packages: cloog, qemu, cmake, sweb-gcc
To install the necessary packages enter the following command:
brew install sweb-gcc qemu cmake cloog
The cross-compiler we provide is based on
gcc Version 4.9.1 and precompiled packages are (mostly) available for the current stable version of OS X. Should it be necessary or should you wish to compile it yourself, expect compile times of more than 10 minutes (Model used for measurement: Macbook Pro, 15-inch, Late 2013, 2,3 GHz Intel Core i7, 16 GB 1600 MHz DDR3).
Compiling your first build
You are now ready to compile your first build. Due to problems with in-source builds in the past, SWEB does no longer support those. You will need to build in a different folder, e.g.
git clone https://github.com/iaik/sweb mkdir build cd build cmake ../sweb make make qemu
After running these commands you should see many lines with different colors in your main Terminal and a second window with the
qemu emulator running your SWEB.
Speeding things up
While the way described in the previous section is certainly enough to get you started there a some things you can do to make your workflow speedier.
- Compiling with more threads enabled
- Using one command to do several things in succession
- Chaining your commands
- Using a RAM disk
Compile with more threads
Using a command line option for
make allows you to either specify the amount of threads the program should use for the compilation process or instruct it to be “greedy” and use as many as it sees fit.
make -j OPTIONAL_INTEGER_MAXIMUM_THREAD_NUMBER
The downside to this is that since the process is not threadsafe, your terminal output will be quite messy.
Use one command to do several things
SWEB ships with a very handy
make target called
mrproper. This script deletes your intermediate files and runs
cmake SOURCEFOLDER again. Since you need to run the
cmake command for every new file you want to add, this can save some time.
make mrproper ... [Y/n]
When asked whether you want to really do this, some popular UNIX tools allow you to hit ENTER to accept the suggestion in capital letters; the same behaviour is enabled for this prompt.
Chaining your commands
You probably already know this, but shell commands can be chained. Use
&& to run the next command only if the previous command succeeded and use
; to run the next command in any case.
cmake . && make -j && make qemu make -j && make qemu ; make clean
Using this technique you can simply build and run with two button presses: The arrow key up to jump through your shell history and the ENTER key to accept.
Using a RAM disk
Since you will be writing and reading a lot of small files again and again and again from your disk, it might be beneficial for both performance as well as disk health to have at least your build folder in a virtual disk residing completely in your RAM. Personally I have not done that, but since the course staff recommends that, instructions can be found here.
If you are not sure the performance differs a lot, tekrevue.com has a nice chart buried in their article, graphing the difference between a SSD and a RAM disk. To quote their post:
As you can see, RAM Disks can offer power users an amazing level of performance, but it cannot be stressed enough the dangers of using volatile memory for data storage.
To enable a RAM volume enter the following command:
# NAME: the name you want to assign, SIZE: 2048 * required amount of MegaBytes diskutil erasevolume HFS+ 'NAME' `hdiutil attach -nomount ram://SIZE`
If you prefer a GUI for this task, the original author of this tip offers one free of charge.
Please make sure you always, always commit AND push your work if you’re working in RAM. Changes will be lost on computer shutdown, crash, freeze, etc.
Changes are preserved during sleep and hibernate. ~Daniel
Working on OS X natively when developing SWEB is indeed possible for the usual use case. Developing and testing architectures different from
i686 however, e.g. the 64-bit build or
ARM builds will still require you to use Linux (or asking your group members to work on those parts).
How to SWEB on your Mac with OS X is part 2 of Working on SWEB for the Operating Systems course: