Lab 1, Compiler

Let’s start with tools that we need to just build the OS for ARM. First clone official inferno os repository from google code repository:

# hg clone

What we need to move further? We need the ARM cross compiler, linker, etc. For this, let’s just compile inferno targeting mac as host (we are on mac now, so we will get hosted inferno for mac as result):

# cd inferno-os/
# INF_ROOT=`pwd` perl -i -pe 's/^ROOT=.*/ROOT=$ENV{INF_ROOT}/m' mkconfig
# perl -i -pe 's/^SYSHOST=.*/SYSHOST=MacOSX/m' mkconfig
# perl -i -pe 's/^OBJTYPE=.*/OBJTYPE=386/m' mkconfig
# sh
# PATH=`pwd`/MacOSX/386/bin:$PATH mk nuke
# PATH=`pwd`/MacOSX/386/bin:$PATH mk install
… waiting just few minutes … 
# ls MacOSX/386/bin/
0a         2l         8l         iar        ksize      ms2        tc
0c         5a         acid       idea       kstrip     ndate      va
0l         5c         asm        inm        limbo      qa         vc
1a         5coff      c2l        iyacc      md5sum     qc         vl
1c         5cv        data2c     ka         mk         ql
1l         5l         data2s     kc    sqz
2a         8a         emu        kl         mkext      srclist
2c         8c         ftl        kprof      mkppcimage styxtest

Yes! Now we have all needed cross-platform tools for building Inferno OS for ARM, see 5c – C compiler, 5a – ARM assembler, 5l – ARM linker.
Let’s check ARM asm generated:

# export PATH=`pwd`/MacOSX/386/bin:$PATH 
# echo "int main() { return 123; }" >tmp.c && 5c -S tmp.c && rm tmp.c
	TEXT	main+0(SB),0,$0
	MOVW	$123,R0
	RET	,
	RET	,
	END	,
This entry was posted in Blog, Inferno OS, Raspberry Pi, Research. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.


  1. Akibo Huang
    Posted January 8, 2014 at 17:49 | Permalink

    If you’re building on Linux/amd64 system, you will require to import this patch to fix a compile error – floating point exception.nn— a/Linux/386/include/fpuctl.htSat Jun 08 13:03:33 2013 +0000n+++ b/Linux/386/include/fpuctl.htSun Jun 30 02:16:23 2013 +0800n -6,12 +6,12 n static voidn setfcr(ulong fcr)n {n-t__asm__(t”xorbt$0x3f, %%al
    “n+t__asm__ volatile(t”xorbt$0x3f, %%al
    “n t”pushwt%%ax
    “n t”fwait
    “n t”fldcwt(%%esp)
    “n t”popwt%%ax
    “n-t: /* no output */n+t: “=a” (fcr)n t: “al” (fcr)n t);n }

  2. yshurik
    Posted January 8, 2014 at 20:52 | Permalink

    Many thanks for the feedback. I will check the patch!

  3. kograt
    Posted December 14, 2015 at 08:47 | Permalink

    patch works fine and needed. Also at least on ubuntu x64 you will have to install libx11-dev:i386 and libxext-dev:i386

    There is a conservation about patch:

    OK according to the gcc folks, the asm constraints are not properly specified which results in the optimiser thinking it can reorder bits of code that end up causing problems.

    They weren’t quite helpful enough to mention which constraint, unfortunately. I *think* I’ve figured it out, see if you think this makes sense:

    static void setfcr(unsigned long fcr) {
    __asm__( “xorb $0x3f, %%alnt”
    “pushw %%axnt”
    “fldcw (%%esp)nt”
    “popw %%axnt”
    : /* no output */
    : “al” (fcr)

    The assembly modifies the al register (via the xor). However, gcc doesn’t know any registers have been modified because there’s no output constraints specified – after the asm is finished it expects al to be unchanged from the fcr value it loaded in.

    Here’s where my theory gets a bit hazy; if I add “=al” as an output constraint[1], I still get the same problem. “=ax” still has the problem, but “=a” works.

    [1] and specify a volatile modifier to prevent gcc from optimising the asm away because the output isn’t used -_-

Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>