Psellos Blog

When iOS Simulator Apps Go AWOL

2012-11-15T11:00:00-08:00

November 15, 2012

I’ve just finished work on version 2.0 of runsim, a small shell script that installs and runs apps in the iOS Simulator. For this version I added the ability to start apps in the simulator automatically from the command line. I also separated out the different functions, so you can install, uninstall, list, and run apps as separate operations.

You can read the full details on Run iOS Simulator from the Command Line.

You can also download runsim from the following link:

runsim — run app in iOS Simulator from command line

Before using it, however, I suggest you read the full description linked above. There are some complexities in using the automatic start-up facility that you want to understand beforehand.

The new automatic start-up uses instruments, the command-line version of the Xcode Instruments tool. While getting it working I had one persistent problem: Instruments kept reporting that the monitored app had gone AWOL. For the benefit of other folks working from the command line, I’ll show how to elicit this legendary error and what I did to correct it.

To keep the example simple, I’ll use Psi, an iOS app I wrote to be be as small as possible and to require no supporting files. (Get the source from Tiny iOS App in One Source File.)

Every app in the Apple universe has an Info.plist file that describes its basic attributes. The core of the AWOL app problem is that Xcode has begun to add internal attributes to this file behind the scenes. You can see why Apple would do things this way, but it makes it a little more difficult for “enthusiasts” to do new things with the tools.

Here is an Info.plist file for Psi as it is presented to users of Xcode:

&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;
&lt;plist version="1.0"&gt;
&lt;dict&gt;
        &lt;key&gt;CFBundleDevelopmentRegion&lt;/key&gt;
        &lt;string&gt;English&lt;/string&gt;
        &lt;key&gt;CFBundleDisplayName&lt;/key&gt;
        &lt;string&gt;Psi&lt;/string&gt;
        &lt;key&gt;CFBundleExecutable&lt;/key&gt;
        &lt;string&gt;Psi&lt;/string&gt;
        &lt;key&gt;CFBundleIconFile&lt;/key&gt;
        &lt;string&gt;Icon.png&lt;/string&gt;
        &lt;key&gt;CFBundleIcons&lt;/key&gt;
        &lt;dict&gt;
                &lt;key&gt;CFBundlePrimaryIcon&lt;/key&gt;
                &lt;dict&gt;
                        &lt;key&gt;CFBundleIconFiles&lt;/key&gt;
                        &lt;array&gt;
                                &lt;string&gt;Icon.png&lt;/string&gt;
                        &lt;/array&gt;
                &lt;/dict&gt;
        &lt;/dict&gt;
        &lt;key&gt;CFBundleIdentifier&lt;/key&gt;
        &lt;string&gt;com.psellos.Psi&lt;/string&gt;
        &lt;key&gt;CFBundleInfoDictionaryVersion&lt;/key&gt;
        &lt;string&gt;6.0&lt;/string&gt;
        &lt;key&gt;CFBundleName&lt;/key&gt;
        &lt;string&gt;Psi&lt;/string&gt;
        &lt;key&gt;CFBundlePackageType&lt;/key&gt;
        &lt;string&gt;APPL&lt;/string&gt;
        &lt;key&gt;CFBundleSignature&lt;/key&gt;
        &lt;string&gt;????&lt;/string&gt;
        &lt;key&gt;CFBundleShortVersionString&lt;/key&gt;
        &lt;string&gt;1.0&lt;/string&gt;
        &lt;key&gt;CFBundleVersion&lt;/key&gt;
        &lt;string&gt;1.0.1&lt;/string&gt;
        &lt;key&gt;UIStatusBarStyle&lt;/key&gt;
        &lt;string&gt;UIStatusBarStyleBlackOpaque&lt;/string&gt;
        &lt;key&gt;LSRequiresIPhoneOS&lt;/key&gt;
        &lt;true/&gt;
&lt;/dict&gt;
&lt;/plist&gt;

If you try to start up Psi with this exact Info.plist, however, instruments reports that the app has gone AWOL:

$ PSID="$HOME/Library/Application Support/iPhone Simulator/6.0/Applications/72002825-3566-4EF2-B87B-872836AD29C6/Psi.app"
$ TRC=/Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate
$ instruments instruments -t "$TRC" "$PSID"
2012-11-15 12:32:51.586 instruments[56628:1207] Automation Instrument ran into an exception while trying to run the script. UIATargetHasGoneAWOLException
2012-11-15 20:32:51 +0000 Fail: An error occurred while trying to run the script.

If you let Xcode install the app, it modifies Info.plist internally to include the following extra attributes:

        &lt;key&gt;CFBundleSupportedPlatforms&lt;/key&gt;
        &lt;array&gt;
                &lt;string&gt;iPhoneSimulator&lt;/string&gt;
        &lt;/array&gt;
        &lt;key&gt;DTPlatformName&lt;/key&gt;
        &lt;string&gt;iphonesimulator&lt;/string&gt;
        &lt;key&gt;DTSDKName&lt;/key&gt;
        &lt;string&gt;iphonesimulator6.0&lt;/string&gt;
        &lt;key&gt;UIDeviceFamily&lt;/key&gt;
        &lt;array&gt;
                &lt;integer&gt;1&lt;/integer&gt;
        &lt;/array&gt;

In essence, these are device attributes for the iOS Simulator’s iPhone simulation. If you add these attributes to the Info.plist file, instruments runs as expected. It starts up the iPhone Simulator and then starts up Psi in the simulator.

Inside runsim 2.0 there’s a little Python script that adds these attributes to an Info.plist file. If you’re encountering the AWOL problem, maybe this little script will help. (You can download runsum from the link above.)

If you have any comments, corrections, or suggestions, leave them below or email me at jeffsco@psellos.com.

Posted by: Jeffrey

OCamlXSim 3.1 for Mountain Lion

2012-10-23T11:00:00-08:00

October 23, 2012

For those interested in building iOS Simulator apps in OCaml 4, I’ve just revamped OCamlXSim 3.1 for the latest OS X release, OS X 10.8 (Mountain Lion). The only difference is in the default iOS SDK, which I changed from iOS 5.1 to iOS 6.0. Otherwise, this was just a recompile.

You can get binary releases of OCamlXSim here:

For information on how to build from sources and how to test an installation, see the updated version of Compile OCaml for iOS Simulator.

If you’re new to this site, you might also be interested in OCamlXARM, a modified version of OCaml 4.00.0 that builds iOS apps. I also revamped it recently to work under Mountain Lion. You can read about it on Compile OCaml for iOS

OCaml Cross Compilation Build Howto

OCamlXSim and OCamlXARM are both cross compilers, and they’re built using exactly the same approach. I think the strategy could be useful for building other OCaml cross compilers, so I thought I’d explain how the build process works in some detail. I’m not claiming that the method is original; however, I did develop it independently and it works for my host and targets.

Since the stock version of OCaml doesn’t want to be a cross compiler, the overall goal is to beguile it into being one without disrupting the build process too much. To keep things simple for now, I build a bytecode cross compiler that generates native code for the target; i.e., a cross-compiling version of ocamlopt. The approach requires that OCaml already supports the host system with at least a bytecode implementation, and the target system with a native code implementation.

Building the equivalent “optimized” cross compiler (ocamlopt.opt) doesn’t seem too much harder, given a native OCaml compiler for the host system. I’d like to get this working at some point.

Compiler Source Changes

This note just describes the commands I use to build the cross compilers. It doesn’t describe the changes to the compiler source itself. These will vary a lot depending on the target and the differences between the host and the target.

There are no source changes for OCamlXSIM when building a 32-bit OS X host executable, because the host and target have virtually identical properties. Even for a 64-bit OS X executable, the changes are minimal, because the host and target are quite similar. There is one change in asmrun/signals_osdep.h, which must be modified to include the proper signal handling code in a cross-compiling environment (when the host and the target architectures are different). Another change in the code generator makes sure that emitted native int values don’t exceed 32 bits.

The compiler source changes for OCamlXARM are much more extensive, because the iOS target isn’t directly supported in the stock OCaml release. The same signal-handling change was required, and many (reasonably straightforward) changes were required in the emission of assembly code to allow for the particular syntax of the iOS assembler.

In cases where the host and target machines are very different, it may be necessary to make significant changes to the architecture-dependent code that emits instructions and data.

If you’re interested in the exact compiler changes for OCamlXSim or OCamlXARM, see their associated pages (linked above) for a description of how to retrieve the patches.

Ordinary OCaml Build

As a starting point for the build process, consider the ordinary OCaml build process:

$ ./configure
$ make world
$ make opt

The configure step does many things:

Guess the CPU type and operating system of the host.
Find a C compiler and associated assembler and linker.
Determine properties of the machine (integer sizes, endianness).
Determine properties of the system (available system calls and libraries).

Since OCaml sees itself as a native compiler, all these configuration properties are assumed to apply both to the compiler itself and to the programs it generates. This isn’t the case for a cross compiler, and the key undertaking is to separate the two.

The make world step builds the bytecode compiler (ocamlc) and bytecode runtime. The bytecode runtime consists of a native-code program named ocamlrun and a set of dynamically loadable executables for extra libraries. ocamlrun, in turn, consists of a bytecode interpreter and native-code primitives. Each dynamic library contains bytecode plus extra native-code primitives.

The make opt step builds the native code compiler (ocamlopt) and a native runtime. The native runtime consists of a set of native libraries, very similar to the bytecode runtime minus the interpreter.

When you do an ordinary compile of an OCaml program with ocamlopt, ocamlopt itself uses the bytecode runtime created in the make world step. The compiled program links against the native runtime created in the make opt step.

Cross Compiling Requirements

To get a cross compiler using the same build system requires a reconsideration of the configuration properties:

The CPU type is used to select the correct native code generator. So the CPU type of the host isn’t so interesting. We want to specify the CPU type of the target.
The C compiler and linker are needed for building the bytecode runtime for the host. However, we also want a target toolchain C compiler, assembler, and linker to be used for generated programs.
Similarly, the machine and system properties are correct for building the bytecode runtime on the host. But we want the target machine and system properties for building the runtime to be used by generated programs.

This suggests a two-phase build process:

Phase 1: run configure as usual to determine the properties of the host system. Post-modify the configuration properties just enough to create a native-code cross compiler for the target. Then build the native-code compiler as usual. This native-code compiler runs on the bytecode interpreter (ocamlrun) of the host, and generates native code for the target.
Phase 2: run configure on the target system to determine the properties of the target system. Then rebuild just the runtime on the host using the target toolchain and these properties of the target system. The resulting runtime works for the compiled programs.

If the target system is insufficiently Unix-like to run the configure script, it will be necessary to determine the configuration parameters by some other method.

This is how both OCamlXARM and OCamlXSim are built. For people really interested in the details, the following sections show the build process for OCamlXSim 3.1.7. You’ll find the code in an OS X shell script named xsim-build.

Phase 1

The configuration step of Phase 1 looks essentially like this:

export&#160;PLT=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform
export SDK=/Developer/SDKs/iPhoneSimulator6.0.sdk

config1 () {
    # Configure for building bytecode interpreter to run on Intel OS X.
    # But specify iOSSim parameters for assembly and partial link.
    ./configure \
            -cc "gcc" \
            -as "$PLT/Developer/usr/bin/gcc -arch i386 -c" \
            -aspp "$PLT/Developer/usr/bin/gcc -arch i386 -c"
    # Post-modify config/Makefile to select i386 back end for ocamlopt
    # (i386 assembly code).
    sed \
        -e 's/^ARCH[    ]*=.*/ARCH=i386/' \
        -e 's/^MODEL[    ]*=.*/MODEL=default/' \
        -e "s#^PARTIALLD[    ]*=.*#PARTIALLD=$PLT/Developer/usr/bin/ld -r#" \
        config/Makefile
    # Post-modify utils/config.ml.
    make utils/config.ml
    sed \
        -e 's#let[      ][      ]*mkexe[        ]*=.*#let mkexe ="'"$PLT/Developer/usr/bin/gcc -arch i386 -Wl,-objc_abi_version,2 -Wl,-no_pie -gdwarf-2 -isysroot $PLT$SDK"'"#' \
        -e 's#let[      ][      ]*bytecomp_c_compiler[  ]*=.*#let bytecomp_c_compiler ="'"$PLT/Developer/usr/bin/gcc -arch i386 -gdwarf-2 -isysroot $PLT$SDK"'"#' \
        -e 's#let[      ][      ]*native_c_compiler[    ]*=.*#let native_c_compiler ="'"$PLT/Developer/usr/bin/gcc -arch i386 -gdwarf-2 -isysroot $PLT$SDK"'"#' \
        utils/config.ml
}

The configure step itself specifies the C compiler of the host (gcc), which is needed to build the bytecode runtime. The assembler, however, isn’t needed in this phase. So the configure step can specify the target tools for the two types of assembly—in both cases, it specifies the gcc of the target toolchain. This means that the generated cross compiler will run the proper tools when it assembles its generated native code.

After generating configuration information for the host, the script then post-modifies it to become a cross compiler. Most importantly, it modifies config/Makefile to set its ARCH variable to the target architecture. As mentioned above, this is the key step that attaches the target code generator to the host compiler. The other changes specify a more particular model of CPU (not really used for OCamlXSim) and the target tool chain command for doing partial linking.

Note that for OCamlXSim, the target architecture is i386. The iOS Simulator is a 32-bit Intel hardware environment with libraries that recreate the software environment of iOS devices. In the build script for OCamlXARM, the target architecture is armv7.

This leaves the question of how the cross compiler should compile any C programs that are given on its command line, and how it should link the results into an OCaml executable. These commands are inserted at an even deeper level, to avoid interfering with the compilation and linking of the cross compiler runtime. The second set of modifications works by generating utils/config.ml and modifying its commands to be those of the target toolchain.

The build step of Phase 1 looks like this:

build1 () {
    # Don't assemble asmrun/i386.S for Phase 1 build.  Modify
    # asmrun/Makefile temporarily to disable.  Be really sure to put
    # back for Phase 2.
    trap 'mv -f asmrun/Makefile.aside asmrun/Makefile' EXIT
    grep -q '^[         ]*ASMOBJS[      ]*=' asmrun/Makefile &amp;&amp; \
        mv -f asmrun/Makefile asmrun/Makefile.aside
    sed -e '/^[        ]*ASMOBJS[      ]*=/s/^/#/' \
        asmrun/Makefile.aside &gt; asmrun/Makefile
    make world &amp;&amp; make opt
    mv -f asmrun/Makefile.aside asmrun/Makefile
    trap - EXIT
    # Save the Phase 1 shared (dynamically loadable) libraries and
    # restore them after Phase 2.  They're required by some OCaml
    # utilities, such as camlp4.
    #
    find . -name '*.so' -exec mv {} {}phase1 \;
}

This step basically just runs make world and make opt as usual. However, it turns out to be necessary to make some tricky changes before and after.

First, the assembled output of asmrun/i386.S won’t be compatible with the rest of the bytecode runtime. So we remove it from the build rule of asmrun/Makefile, and restore it later. This works because this file is needed only for native executables, and we’re producing only bytecode executables at this point.

Second, the dynamically loadable libraries of the bytecode runtime will be overwritten during Phase 2. These libraries are needed by the bytecode executables. So we move them aside temporarily, and restore them at the end of Phase 2.

Phase 2

For Phase 2, we’d like to run configure on our target system. This can be tricky in general, but for OCamlXSim it’s relatively easy. The iOS Simulator actually runs as a separate software environment on OS X, our host system. It’s possible to generate and run code in this environment by specifying the proper command-line options.

If you aren’t so lucky, the requirement is to generate three files: config/s.h, config/m.h, and config/Makefile. A possible plan is to generate these by running configure on a Unix-like system that’s as similar as possible to your target, then make any other modifications by hand.

The configuration step of Phase 2 looks essentially like this:

config2 () {
    # Clean out OS X runtime
    cd asmrun; make clean; cd ..
    cd stdlib; make clean; cd ..
    cd otherlibs/bigarray; make clean; cd ../..
    cd otherlibs/dynlink; make clean; cd ../..
    cd otherlibs/num; make clean; cd ../..
    cd otherlibs/str; make clean; cd ../..
    cd otherlibs/systhreads; make clean; cd ../..
    cd otherlibs/threads; make clean; cd ../..
    cd otherlibs/unix; make clean; cd ../..
    # Reconfigure for iOSSim environment
    ./configure \
            -host i386-apple-darwin10.0.0d3 \
            -cc "$PLT/Developer/usr/bin/gcc -arch i386 -gdwarf-2 -isysroot $PLT$SDK" \
            -as "$PLT/Developer/usr/bin/gcc -arch i386 -c" \
            -aspp "$PLT/Developer/usr/bin/gcc -arch i386 -c"
    # Rebuild ocamlmklib, so libraries work with iOSSim.
    rm myocamlbuild_config.ml
    cd tools
    make ocamlmklib
    cd ..
}

The purpose of Phase 2 is to build a runtime for the target. So we start by clearing out the old runtime for the host. Now that we’ve built the cross compiler, it won’t be needed.

Next, we rerun configure, specifying the C compiler and assembler of the target toolchain (in our case, the iOS Simulator). We also specify a specific -host, so that configure doesn’t attempt to guess the CPU and operating system.

Then we rebuild ocamlmklib so it works with the target toolchain rather than the host toolchain.

The build step of Phase 2 looks like this:

build2 () {
    # Make iOSSim runtime
    cd asmrun; make all; cd ..
    cd stdlib; make all allopt; cd ..
    cd otherlibs/unix; make all allopt; cd ../..
    cd otherlibs/str; make all allopt; cd ../..
    cd otherlibs/num; make all allopt; cd ../..
    cd otherlibs/dynlink; make all allopt; cd ../..
    cd otherlibs/bigarray; make all allopt; cd ../..
    cd otherlibs/systhreads; make all allopt; cd ../..
    cd otherlibs/threads; make all allopt; cd ../..
    # Restore the saved Phase 1 .so files (see above).
    find . -name '*.sophase1' -print | \
        while read f; do \
            fso="$(expr "$f" : '\(.*\)sophase1$')so"; mv -f $f $fso; \
        done
}

These commands rebuild the runtime using the new toolchain, then restore the dynamically loaded libraries of the host runtime that were saved at the end of Phase 1. These libraries are used by some of the compiling tools—notably, the camlp4 family uses the Unix library.

Serendipitously, the resulting executables and objects look just like those of a traditional OCaml release. So they can be installed using the unmodified install rule of the top-level Makefile. It works out this way because there are two distinct parts: the bytecode subsystem (which works on the host), and the native-code subsystem (which works on the target). Things don’t have to be separated this way, but it’s convenient for now.

If you have comments or questions, please leave them below, or email me at jeffsco@psellos.com.

Posted by: Jeffrey

OCamlXARM 3.1 for Mountain Lion

2012-10-18T11:00:00-08:00

October 18, 2012

For those interested in building iOS apps in OCaml 4, I’ve just revamped OCamlXARM 3.1 for the latest OS X release, OS X 10.8 (Mountain Lion). The only difference is in the default iOS SDK, which I changed from iOS 5.1 to iOS 6.0. Otherwise, this was just a recompile.

You can get binary releases of OCamlXARM here:

For information on how to build from sources and how to test an installation, see Compile OCaml for iOS.

My next plan is to make a Mountain Lion release of OCamlXSim, which will build against the iOS 6 Simulator by default.

In the background I’m trying to invent an iPad app that will encourage you to live in the present moment. An old friend suggests that it could be based on managing a complex undertaking on-screen. Say, something like organizing eighty middle school kids as they perform a Motown adaptation of The Tempest. This is an intriguing idea, and the soundtrack would be excellent.

However, I’m thinking that the app should focus more on you (the person running the app). I imagine that the app shows you on the screen, and you can manipulate the image of yourself by touching and dragging your arms and legs, etc. In the app, your iPad is lost somewhere in your house. Your goal is to solve a series of logistical puzzles to find the missing iPad, and then run the same app in the app that you’re running in real life. If you succeed, there’s a time-tunnel-like graphic that transports you through a kaleidoscopic hall of mirrors into the present moment.

The largest living land mammal is the absent mind. —Don Van Vliet (1941–2010)

As I’ve said before, OCaml is such a powerful language it gives me great ideas for apps.

If you have comments or questions, please leave them below, or email me at jeffsco@psellos.com.

Posted by: Jeffrey

Archimedean Solids in OCaml

2012-10-13T11:00:00-08:00

October 13, 2012

One of the many ideas I have on the back burner is to apply “crowdsourcing” to the age-old question of whether the Platonic solids or the Archimedean solids are cooler. One day I’d like to make an OCaml iOS app that shows a pair of the different masters’ polyhedra and lets you vote on which is cooler.

Recently I was delighted to find that there’s a little OCaml library called Polydroml that calculates geometric information for nearly all the uniform polyhedra. It’s based on the Wythoff construction, which unifies all the different polyhedra through the single idea of tiling the surface of the sphere with spherical triangles.

Polydroml is the work of Fabian Pijcke and Pierre Hauweele. The current Polydroml code supports all but four of the Archimedean solids. I’m the kind of guy who likes to collect the whole set, so I spent a couple days adding support for two more polyhedra to the library.

The two I added are the great rhombicuboctahedron (shown in the figure) and the great rhombicosidodecahedron. They’re characterized by the fact that their vertices are located inside the spherical triangles of the Wythoff construction—not on their edges. As a result, they have more faces than the simpler polyhedra and hence are cooler. (But don’t let me influence your vote when the app comes out.)

I fear there aren’t many people working with polyhedra in OCaml, but maybe I’ll be pleasantly surprised. If you’re interested you can get Polydroml itself, my patch to Polydroml, or a version of Polydroml with my patch already applied, at the following links:

(For convenience I’ve repackaged Polydroml as a zipfile—see the library link above for information on the official release. I have no relationship to the authors of Polydroml, other than that I think they must be pretty cool.)

The final two unimplemented Archimedean solids are so-called “snub” forms, which are possibly the coolest of all the convex uniform polyhedra (just my opinion—not an official endorsement). I’m hoping to add support for them pretty soon, after some further study of the Wythoff construction.

I enjoyed learning some spherical geometry while working on this:

A spherical triangle is determined by its three angles (no similar triangles on the sphere).
Spherical lines (great circles) intersect in two points!
Need to do constructions on the surface of the sphere, not in the plane of your triangle!

It gives me newfound respect for Archimedes, who somehow figured it all out while relaxing in the bath.

If you have comments or questions, please leave them below, or email me at jeffsco@psellos.com.

Posted by: Jeffrey

OCaml 4.00.0 for iOS ARMv6

2012-10-03T11:00:00-08:00

October 3, 2012

After testing all the apps I can, I’m ready to release my port of OCaml 4.00.0 for the earliest iOS devices, the iPhones and iPod Touches with ARMv6 processors. Since Apple has dropped support for ARMv6 from the latest Xcode, this port now has mostly nostalgic value I guess.

On the other hand, I have a couple of first-generation iPhones around my house, and they’re still extremely nice little devices. You often hear about people who even today have racks of outdated PowerPC Macs in their basement, running market analysis algorithms and making profitable stock trades. Or maybe I’m the only one who’s ever heard of people like that. At any rate, the point is that there are lots of ways to use outdated equipment creatively.

After this pep talk, perhaps you’d like to try OCamlXARMv6, which is what I’m calling this compiler. You can download a prebuilt binary of OCamlXARMv6. You can also build OCamlXARMv6 from sources—instructions are on the Compile OCaml for Early iOS page.

OCamlXARMv6 runs on OS X and generates apps using the toolchain that comes with Xcode. Since these are now nostalgia devices, you need to use a classic release of Xcode. The Compile OCaml for Early iOS page tells how to get an old Xcode release.

This project was just a small change to OCamlXARM (which compiles OCaml 4.00.0 for current iOS devices):

Once again, the majority of the work had already been done by Benedikt Meurer, who wrote the new ARM code generator for OCaml 4.00.0. His code generator already supports the ARMv6 architecture. I just had to add a new target system/model and set the defaults properly.

However, I did have to add support for the VFPv2 floating point instruction set, as Meurer’s generator supports only VFPv3. This was a small change, but it was fun to get it working. I’ve already written about this change in OCaml 4.00.0 Patches for VFPv2.

I spend a lot of time “monitoring” this website, Psellos.com. Something I’ve always wanted is a little display that lets me see a summary of the status—how many people are reading this blog vs. the Tompa blog, how many new visitors we’ve had today, whether the mailer is being attacked by a Portuguese password guesser, and so on. It strikes me that an old iPhone would be great for this. I can write a quick app in OCaml and just leave it running on the iPhone a lot of the time. Even without a cell contract, it can access the website over WiFi. There are lots of cool things you could do with an old iPhone, it seems to me.

If you have comments or questions, please leave them below, or email me at jeffsco@psellos.com.

Posted by: Jeffrey

OCaml 4.00.0 Patches for VFPv2

2012-09-30T11:00:00-08:00

September 30, 2012

I’ve just gotten OCaml 4.00.0 working on the earliest iOS devices, the ones that have the ARMv6 architecture. It turns out, though, that Apple no longer supports these devices for active development—Xcode 4.5 has dropped support for ARMv6. You can see this in the Xcode 4.5 release notes. Look for “Changes, General: iOS.”

An OCaml 4.00.0 cross compiler for old iOS devices still might be useful to a few people, though, so I’m going to release it today or tomorrow as a stand-alone project. I’ve personally enjoyed building OCaml 4.00.0 apps with Xcode 4.3 and running them on a couple of ancient iOS devices I have around my house.

In the meantime, one of the things I had to do for this port was to add VFPv2 support to OCaml 4.00.0. VFP is the (somewhat poorly named) standard scalar floating point subsystem for ARM. The OCaml 4.00.0 compiler comes with support for two variants of VFPv3, but the earliest iOS devices supported only VFPv2, the previous revision of VFP.

This was a relatively small and straightforward change, but I thought there might be some others out there who could use it for other OCaml ports. So, I back-ported the changes to the 4.00.0 release, and produced a set of diffs:

VFPv2 patches for OCaml 4.00.0

To apply them, download the OCaml 4.00.0 source tarball and untar it. Then:

$ cd ocaml-4.00.0
$ patch -p0 < ocamlvfpv2.diff

Now, build the compiler as usual for your ARM device. To ask the generated compiler to use VFPv2, use the flag -ffpu vfpv2. However, if you’re working on an OCaml port to a new ARM device, you’ll most likely need to modify the handling of the default ABI and other settings in asmcomp/arm/arch.ml (if you haven’t already).

If you have comments or questions, please leave them below, or email me at jeffsco@psellos.com.

Posted by: Jeffrey

OCaml 4.00.0 on iOS Simulator Is Released

2012-09-24T11:00:00-08:00

September 24, 2012

I’ve just released OCamlXSim 3.1.6, a version of OCaml 4.00.0 for building apps to run in the iOS Simulator. Once you build something you like, you can use OCamlXARM to recompile for actual iOS devices and release it in the iTunes App Store.

You can download the compiler as a binary package named ocaml-4.00.0+xsim-3.1.6. You can also build OCamlXSim from sources—instructions are on the Compile OCaml for iOS Simulator page.

OCamlXSim runs on OS X and generates apps for the iOS Simulator using the toolchain that comes with Xcode. The key thing to know about the iOS Simulator is that it’s not the same as OS X. As a result, generating a compiler for the Simulator is very similar to generating one for iOS.

I’d say there were two parts to the project:

It requires some trickery to convince OCaml to be a cross compiler. As with OCamlXARM, what I do is build the compiler 1½ times. The full build creates a cross compiler whose runtime is for OS X. The half build creates an iOS Simulator runtime to be used by the compiled apps.
The i386 code generator of OCaml 4.00.0 works almost without change. I made some very small changes to support 64-bit OS X executables. They’re only about 9% faster, but I found it an interesting challenge to get them working.

OCaml is such a powerful language it gives me ideas for really great apps. Here’s one I just thought of now. You know how there are several popular apps out there that turn your website into articles in a magazine for the iPad?

My idea is that nobody reads magazines any more—what they do is play multiplayer online games. So my app would turn any website into a multiplayer online game. Each page of the website becomes a small town in the game, and each visitor to the website becomes a player in the game. The players travel from town to town battling monsters representing the parts of the website that nobody wants to read (such as sidebars and banner ads). The useful contents of the website would be integrated into the towns (posters on walls, books in the library, menus in the restaurants, movies at the cinema, etc.). Instead of comments on the pages, the players would talk to each other in avatar form.

If you have comments or questions about this idea (or anything else), please leave them below, or email me at jeffsco@psellos.com.

Posted by: Jeffrey

OCaml 4.00.0 on iOS Is Released

2012-09-14T11:00:00-08:00

September 14, 2012

I’ve just released OCamlXARM 3.1.7, a version of OCaml 4.00.0 for building iOS apps. This is the very latest version of OCaml, which gives you powers other programmers can only envy. But please use your powers for good.

You can download the compiler as a binary package named ocaml-4.00.0+xarm-3.1.7. You can also build OCamlXARM from sources—instructions are on the Compile OCaml for iOS page.

I’ve recently decided that most good ideas start as jokes. When I got the idea of running OCaml on iOS, it seemed slightly crazy. But as things have progressed, it seems more and more sane all the time. Why use less powerful, flexible, and rigorous languages when OCaml runs on iOS just fine? Why spend time worrying about memory management when you can have garbage collection?

OK, well, there are good reasons you might want to use other languages or worry about memory. But I’m going to keep suggesting OCaml anyway, it builds real (occasionally even profitable) iOS apps and lets you concentrate on solving your problem rather than building defenses against all the sources of error in the world.

OCamlXARM runs on OS X and generates apps for iOS using the toolchain that comes with Xcode. I’d say there were three parts of the project:

It requires some trickery to convince OCaml to be a cross compiler. In essence, you want to build the compiler 1½ times. The full build creates a cross compiler whose runtime is for OS X. The half build creates an ARM runtime to be used by the compiled apps.

The majority of the technically difficult work for OCaml 4.00.0 on iOS had already been done by Benedikt Meurer, when he wrote the new ARM code generator for OCaml 4.00.0. I just adapted the output for the iOS assembler. This is partly a textual reformatting problem, and partly an exercise in working around limitations of the iOS assembler.

The ARM code generator of OCaml 4.00.0 is targeted at Linux and its ABI. The ABI of iOS differs in a few ways. For example, I had to make some changes to the code emitted for calling external functions.

Along the way we (OCamlXARM testers and I) encountered a couple of bugs in the base OCaml 4.00.0 release, and some bugs in the iOS toolchain. I imported fixes for the OCaml bugs from the INRIA development repository, and I found workarounds for the iOS toolchain bugs.

You can read about these episodes in my earlier progress reports OCaml 4.00.0 Working on iOS and OCaml 4.00.0 on iOS: Progress Report.

I’d like to thank Benedikt Meurer for help, and the INRIA team for fixing the bugs we reported. I’d also like to thank my colleagues at SEAiq for their help in testing. (The SEAiq guys have recently demonstrated that OCaml threading works under iOS. I’ll post more about this soon.)

If you have comments or questions, please leave them below, or email me at jeffsco@psellos.com.

Posted by: Jeffrey

Convert Linux ARM Assembly Code for iOS (Update 3)

2012-08-28T11:00:00-08:00

August 28, 2012

While getting OCaml 4.00.0 working on iOS, I’ve learned quite a bit about the differences between the Linux ARM assembler and the iOS ARM assembler. The two are related: the iOS assembler is like a cousin of the Linux assembler whose ancestors left the home country a few generations back. However, the differences between the two were one of the main problems I had to solve.

This information was hard won: documentation for the iOS assembler seems rare to nonexistent (email me if you know where to find it). So I spent many hours reading the source code of as(1) at Apple’s open source site. To help others avoid duplicating the effort, I’m publishing here the latest version of my Python script arm-as-to-ios that converts ARM assembly code from the Linux format to the required iOS format. This script contains all the wisdom I’ve accumulated so far (including some that’s not required for the OCaml-on-iOS project).

Note: For this third update, I added a transformation to work around a problem with incremental linking of generated object files. You can read the details of the problem and the workaround in my blog post OCaml 4.00.0 on iOS: Progress Report.

I wrote the script specifically to convert the hand-written ARM assembly files of the OCaml runtime to work on iOS. The advantages of using a script are that the conversion is done consistently, and the script might still be useful if the assembly code is rewritten in the future.

Another advantage is that the script might help other people who need to port ARM assembly code from Linux to iOS. Granted, there probably aren’t a lot of people doing this. But if you are, maybe the script will be a useful starting point or at least a careful list of differences between the assemblers.

The output of the script is upward compatible. By this I mean that a converted assembly file works in its originally supported Linux environments as well as in iOS. This means that the converted assembly files can be sent “upstream” to maintainers (if they’re comfortable with supporting iOS and/or the extra complexity of the code).

The current version of arm-as-to-ios is 1.4.0. In its current form, it does the following conversions:

Declare the ARM architecture for iOS with a .machine pseudo-op. The possibilities are armv6 and armv7.
Specify that armv7 code should use the more space-efficient Thumb encoding in iOS.
Generate declarations for functions, similar to the .type pseudo-op for Linux assemblers. It appears that Apple requires .thumb_func declarations only for Thumb functions. Other symbols are apparently assumed to be ARM functions. To make this work upward-compatibly, I define an assembly macro named .funtype that is expanded properly in the different environments.
Make sure that global symbols have the right format. For Linux, they look like “abc”. For iOS, they look like “_abc” (with a leading underscore). To support upward compatibility, this is handled by a cpp macro named Glo() that generates the proper symbol form for each environment.
Make sure that assembler-local symbols have the right format. For Linux assemblers, they look like “.Lxxx”. For the iOS assembler, they look like “Lxxx”. To support upward compatibly, this is handled by a cpp macro named Loc() that generates the proper symbol form for each environment.
Replace uses of =value notation by explicit loads from memory. The Linux ARM assemblers interpret ldr rM, =value to mean that the value should be loaded into register M immediately (using mov) if possible, and loaded from memory (using ldr with PC-relative addressing) otherwise. The Apple assembler seems not to support this, so arm-as-to-ios replaces uses of =value with explicit memory loads, emitting the pool of values into the .text segment at the end of the file.
Convert jump tables (for the tbh instruction) to a form that works with the iOS assembler. The form commonly used in Linux generates a bad jump table under iOS—apparently the iOS assembler interprets the expressions differently.
Convert “dot relative” expressions to a form that the iOS assembler correctly treats as assembly-time constants. This is a workaround for what looks very much like an iOS assembler bug that prevents incremental linking of the generated object files. (Or possibly it’s a bug in the iOS linker.) Details of the problem and the workaround are given in my blog post OCaml 4.00.0 on iOS: Progress Report. You can also see an example of this conversion below.
Remove uses of two pseudo-ops, .type and .size, when assembling for iOS. They aren’t supported by Apple’s assembler. This is done by defining null assembly macros for them.
Define a macro cbz when using ARM encodings for iOS. The cbz instruction is Thumb-only. The definition replaces it with a pair of ARM instructions.

You can download the script here:

arm-as-to-ios—modify ARM assembly code for use on iOS

The full text of the script is also included at the end of this post.

This is the fourth version of arm-as-to-ios, and there may well be a few more changes when I work on the armv6 architecture. As I make changes, I’ll keep the linked script up to date. If there are significant changes I’ll make another post about them.

If you want to try out arm-as-to-ios, copy and paste the lines from the end of this post into a file named arm-as-to-ios, or download it from the above link. Mark it as a script with chmod:

$ chmod +x arm-as-to-ios

To use the script, specify the name of an ARM assembly file. If no files are given, the script processes its standard input.

The following small example demonstrates the translations that arm-as-to-ios performs. Here is a small file of Linux ARM assembly code:

        .syntax unified
        .text
        .align  2
        .globl  example
        .type example, %function
example:
        sub     r10, r10, 8
        cmp     r10, r11
        bcc     1f
        bx      lr
1:
        ldr     r7, =last_return_address
        str     lr, [r7]
        bl      .Lcall_gc
        ldr     lr, [r7]
        b       example

.Lcall_gc:
        ldr     r12, =bottom_of_stack
        str     sp, [r12]
        bl      garbage_collection
        bx      lr

/* Jump table fragment */

.Ljump:
        tbh     [pc, r4, lsl #1]
        .short  (.Ltest1-.)/2+0
        .short  (.Ltest2-.)/2+1
        .short  (.Ltest3-.)/2+2
.Ltest1:
        ldr     r4, [r4]
.Ltest2:
        str     r6, [sp, 8]
.Ltest3:
        str     r8, [r12]

/* Dot relative (frame table fragment) */

        .word   .L200000 - . + 0xfc000000
        .long   0x1c9080
        .thumb_func     example
        .word   example
        .short  8
        .short  0
.L200000:
        .asciz  "example.ml"

If you run arm-as-to-ios on this file, you get the following output that works for both Linux and iOS assemblers:

        .syntax unified

/* Apple compatibility macros */
#if defined(SYS_macosx)
#define Glo(s) _##s
#define Loc(s) L##s
#if defined(MODEL_armv6)
        .machine  armv6
        .macro  .funtype
        .endm
        .macro  cbz
        cmp     $0, #0
        beq     $1
        .endm
#else
        .machine  armv7
        .thumb
        .macro  .funtype
        .thumb_func $0
        .endm
#endif
        .macro  .type
        .endm
        .macro  .size
        .endm
#else
#define Glo(s) s
#define Loc(s) .L##s
        .macro  .funtype symbol
        .type  \symbol, %function
        .endm
#endif
/* End Apple compatibility macros */

        .text
        .align  2
        .globl  Glo(example)
        .funtype  Glo(example)
Glo(example):
        sub     r10, r10, 8
        cmp     r10, r11
        bcc     1f
        bx      lr
1:
        ldr     r7, Loc(Plast_return_address)
        str     lr, [r7]
        bl      Loc(call_gc)
        ldr     lr, [r7]
        b       Glo(example)

Loc(call_gc):
        ldr     r12, Loc(Pbottom_of_stack)
        str     sp, [r12]
        bl      Glo(garbage_collection)
        bx      lr

/* Jump table fragment */

Loc(jump):
        tbh     [pc, r4, lsl #1]
Loc(B27):
        .short  (Loc(test1)-Loc(B27))/2
        .short  (Loc(test2)-Loc(B27))/2
        .short  (Loc(test3)-Loc(B27))/2
Loc(test1):
        ldr     r4, [r4]
Loc(test2):
        str     r6, [sp, 8]
Loc(test3):
        str     r8, [r12]

/* Dot relative (frame table fragment) */

DR40 =   Loc(200000) - . + 0xfc000000
        .word DR40
        .long   0x1c9080
        .thumb_func     Glo(example)
        .word   Glo(example)
        .short  8
        .short  0
Loc(200000):
        .asciz  "example.ml"

/* Pool of addresses loaded into registers */

        .text
        .align 2
Loc(Plast_return_address):
        .long Glo(last_return_address)
Loc(Pbottom_of_stack):
        .long Glo(bottom_of_stack)

The output consists of a fixed prefix followed by the translation of the input file, followed by the pool of values to be loaded into registers.

The following shows a successful assembly for iOS of the arm.S file from OCaml 4.00.0.

$ PLT=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform
$ PLTBIN=$PLT/Developer/usr/bin
$ arm-as-to-ios asmrun/arm.S &gt; armcompat.S
$ $PLTBIN/gcc -c -DSYS_macosx -DMODEL_armv7 -o armcompat.o armcompat.S
$ file armcompat.o
armcompat.o: Mach-O object arm
$ otool -tv armcompat.o | head
armcompat.o:
(__TEXT,__text) section
caml_call_gc:
00000000        f8dfc1e0        ldr.w   ip, [pc, #480]  @ 0x1e4
00000004        f8cce000        str.w   lr, [ip]
00000008        f8dfc1dc        ldr.w   ip, [pc, #476]  @ 0x1e8
0000000c        f8ccd000        str.w   sp, [ip]
00000010        ed2d0b10        vstmdb  sp!, {d0-d7}
00000014        e92d50ff        stmdb   sp!, {r0, r1, r2, r3, r4, r5, r6, r7, ip, lr}
00000018        f8dfc1d0        ldr.w   ip, [pc, #464]  @ 0x1ec

The following shows the compatible file being generated and assembled under Debian ARMEL (ARM-based Linux system). Note that the generated file armcompat.S is identical to the above—the output of arm-as-to-ios is a single file that works in both environments.

$ ./arm-as-to-ios asmrun/arm.S &gt; armcompat.S
$ gcc -c -DSYS_linux_eabihf -o armcompat.o armcompat.S 
$ file armcompat.o
armcompat.o: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped
$ objdump -d armcompat.o | grep -v '^$' | head
armcompat.o:     file format elf32-littlearm
Disassembly of section .text:
00000000 &lt;caml_call_gc&gt;:
   0:   f8df c1e0       ldr.w   ip, [pc, #480]  ; 1e4 &lt;caml_system__code_end&gt;
   4:   f8cc e000       str.w   lr, [ip]
   8:   f8df c1dc       ldr.w   ip, [pc, #476]  ; 1e8 &lt;caml_system__code_end+0x4&gt;
   c:   f8cc d000       str.w   sp, [ip]
  10:   ed2d 0b10       vpush   {d0-d7}
  14:   e92d 50ff       stmdb   sp!, {r0, r1, r2, r3, r4, r5, r6, r7, ip, lr}
  18:   f8df c1d0       ldr.w   ip, [pc, #464]  ; 1ec &lt;caml_system__code_end+0x8&gt;

If you have any corrections, improvements, or other comments, leave them below or email me at jeffsco@psellos.com. I’d be very pleased to hear if the script has been helpful to anyone.

Posted by: Jeffrey

Appendix

#!/usr/bin/env python
#
# arm-as-to-ios     Modify ARM assembly code for the iOS assembler
#
# Copyright (c) 2012 Psellos   http://psellos.com/
# Licensed under the MIT License:
#     http://www.opensource.org/licenses/mit-license.php
#
# Resources for running OCaml on iOS: http://psellos.com/ocaml/
#
import sys
import re

VERSION = '1.4.0'

# Character classes for expression lexing.
#
g_ccid0 = '[$.A-Z_a-z\x80-\xff]'      # Beginning of id
g_ccid =  '[$.0-9A-Z_a-z\x80-\xff]'   # Later in id
def ccc(cc):                          # Complement the class
    if cc[1] == '^':
        return cc[0] + cc[2:]
    return cc[0] + '^' + cc[1:]
def ccce(cc):                         # Complement the class, include EOL
    return '(?:' + ccc(cc) + '|$)'

# Prefixes for pooled symbol labels and jump table base labels.  They're
# in the space of Linux assembler local symbols.  Later rules will
# modify them to the Loc() form.
#
g_poolpfx = '.LP'
g_basepfx = '.LB'


def exists(p, l):
    for l1 in l:
        if p(l1):
            return True
    return False


def forall(p, l):
    for l1 in l:
        if not p(l1):
            return False
    return True


def add_prefix(instrs):
    # Add compatibility macros for all systems, plus hardware
    # definitions and compatibility macros for iOS.
    #
    # All systems:
    #
    # Glo()     cpp macro for making global symbols (xxx vs _xxx)
    # Loc()     cpp macro for making local symbols (.Lxxx vs Lxxx)
    # .funtype  Expands to .thumb_func for iOS armv7 (null for armv6)
    #           Expands to .type %function for others
    #
    # iOS:
    #
    # .machine  armv6/armv7
    # .thumb    (for armv7)
    # cbz       Expands to cmp/beq for armv6 (Thumb-only instr)
    # .type     Not supported by Apple assembler
    # .size     Not supported by Apple assembler
    #
    defre = '#[ \t]*if.*def.*SYS'  # Add new defs near first existing ones
    skipre = '$|\.syntax[ \t]'     # Skip comment lines (and .syntax)

    for i in range(len(instrs)):
        if re.match(defre, instrs[i][1]):
            break
    else:
        i = 0
    for i in range(i, len(instrs)):
        if not re.match(skipre, instrs[i][1]):
            break
    instrs[i:0] = [
        ('', '', '\n'),
        ('/* Apple compatibility macros */', '', '\n'),
        ('', '#if defined(SYS_macosx)', '\n'),
        ('', '#define Glo(s) _##s', '\n'),
        ('', '#define Loc(s) L##s', '\n'),
        ('', '#if defined(MODEL_armv6)', '\n'),
        ('        ', '.machine  armv6', '\n'),
        ('        ', '.macro  .funtype', '\n'),
        ('        ', '.endm', '\n'),
        ('        ', '.macro  cbz', '\n'),
        ('        ', 'cmp     $0, #0', '\n'),
        ('        ', 'beq     $1', '\n'),
        ('        ', '.endm', '\n'),
        ('', '#else', '\n'),
        ('        ', '.machine  armv7', '\n'),
        ('        ', '.thumb', '\n'),
        ('        ', '.macro  .funtype', '\n'),
        ('        ', '.thumb_func $0', '\n'),
        ('        ', '.endm', '\n'),
        ('', '#endif', '\n'),
        ('        ', '.macro  .type', '\n'),
        ('        ', '.endm', '\n'),
        ('        ', '.macro  .size', '\n'),
        ('        ', '.endm', '\n'),
        ('', '#else', '\n'),
        ('', '#define Glo(s) s', '\n'),
        ('', '#define Loc(s) .L##s', '\n'),
        ('        ', '.macro  .funtype symbol', '\n'),
        ('        ', '.type  \\symbol, %function', '\n'),
        ('        ', '.endm', '\n'),
        ('', '#endif', '\n'),
        ('/* End Apple compatibility macros */', '', '\n'),
        ('', '', '\n')
    ]
    return instrs


# Regular expression for modified ldr lines
#
g_ldre = '(ldr[ \t][^,]*,[ \t]*)=(([^ \t\n@,/]|/(?!\*))*)(.*)'


def explicit_address_loads(instrs):
    # Linux assemblers allow the following:
    #
    #     ldr rM, =symbol
    #
    # which loads rM with [mov] (immediately) if possible, or creates an
    # entry in memory for the symbol value and loads it PC-relatively
    # with [ldr].
    #
    # The Apple assembler doesn't seem to support this notation.  If the
    # value is a suitable constant, it emits a valid [mov].  Otherwise
    # it seems to emit an invalid [ldr] that always generates an error.
    # (At least I have not been able to make it work).  So, change uses
    # of =symbol to explicit PC-relative loads.
    #
    # This requires a pool containing the addresses to be loaded.  For
    # now, we just keep track of it ourselves and emit it into the text
    # segment at the end of the file.
    #
    syms = {}
    result = []

    def repl1((syms, result), (a, b, c)):
        global g_poolpfx
        global g_ldre
        (b1, b2, b3) = parse_iparts(b)
        mo = re.match(g_ldre, b3, re.DOTALL)
        if mo:
            if mo.group(2) not in syms:
                syms[mo.group(2)] = len(syms)
            psym = mo.group(2)
            if psym[0:2] == '.L':
                psym = psym[2:]
            newb3 = mo.group(1) + g_poolpfx + psym + mo.group(4)
            result.append((a, b1 + b2 + newb3, c))
        else:
            result.append((a, b, c))
        return (syms, result)

    def pool1(result, s):
        global g_poolpfx
        psym = s
        if psym[0:2] == '.L':
            psym = psym[2:]
        result.append(('', g_poolpfx + psym + ':', '\n'))
        result.append(('        ', '.long ' + s, '\n'))
        return result

    reduce(repl1, instrs, (syms, result))
    if len(syms) &gt; 0:
        result.append(('', '', '\n'))
        result.append(('/* Pool of addresses loaded into registers */',
                        '', '\n'))
        result.append(('', '', '\n'))
        result.append(('        ', '.text', '\n'))
        result.append(('        ', '.align 2', '\n'))
        reduce(pool1, sorted(syms, key=syms.get), result)
    return result


def global_symbols(instrs):
    # The form of a global symbol differs between Linux assemblers and
    # the Apple assember:
    #
    # Linux: xxx
    # Apple: _xxx
    #
    # Change occurrences of global symbols to use the Glo() cpp macro
    # defined in our prefix.
    #
    # We consider a symbol to be global if:
    #
    # a.  It appears in a .globl declaration; or
    # b.  It is referenced, has global form, and is not defined
    #
    glosyms = set()
    refsyms = set()
    defsyms = set()
    result = []

    def findglo1 (glosyms, (a, b, c)):
        if re.match('#', b):
            # Preprocessor line; nothing to do
            return glosyms
        (b1, b2, b3) = parse_iparts(b)
        mo = re.match('(\.globl)' + ccce(g_ccid), b3)
        if mo:
            tokens = parse_expr(b3[len(mo.group(1)):])
            if forall(lambda t: token_type(t) in ['space', 'id', ','], tokens):
                for t in tokens:
                    if token_type(t) == 'id':
                        glosyms.add(t)
        return glosyms

    def findref1 ((refsyms, skipct), (a, b, c)):

        def looksglobal(s):
            if re.match('(r|a|v|p|c|cr|f|s|d|q|mvax|wcgr)[0-9]+$', s, re.I):
                return False # numbered registers
            if re.match('(wr|sb|sl|fp|ip|sp|lr|pc)$', s, re.I):
                return False # named registers
            if re.match('(fpsid|fpscr|fpexc|mvfr1|mvfr0)$', s, re.I):
                return False # more named registers
            if re.match('(mvf|mvd|mvfx|mvdx|dspsc)$', s, re.I):
                return False # even more named registers
            if re.match('(wcid|wcon|wcssf|wcasf|acc)$', s, re.I):
                return False # even more named registers
            if re.match('\.$|\.L|[0-9]|#', s):
                return False # dot, local symbol, or number
            if re.match('(asl|lsl|lsr|asr|ror|rrx)$', s, re.I):
                return False # shift names
            return True

        if re.match('#', b):
            # Preprocessor line; nothing to do
            return (refsyms, skipct)

        # Track nesting of .macro/.endm.  For now, we don't look for
        # global syms in macro defs.  (Avoiding scoping probs etc.)
        #
        if skipct &gt; 0 and re.match('\.(endm|endmacro)' + ccce(g_ccid), b):
            return (refsyms, skipct - 1)
        if re.match('\.macro' + ccce(g_ccid), b):
            return (refsyms, skipct + 1)
        if skipct &gt; 0:
            return (refsyms, skipct)
        if re.match('\.(type|size|syntax|arch|fpu)' + ccce(g_ccid), b):
            return (refsyms, skipct)

        (b1, b2, b3) = parse_iparts(b)
        rtokens = parse_rexpr(b3)
        if len(rtokens) &gt; 1 and rtokens[1] == '.req':
            # .req has atypical syntax; no symbol refs there anyway
            return (refsyms, skipct)
        for t in rtokens[1:]:
            if token_type(t) == 'id' and looksglobal(t):
                refsyms.add(t)
        return (refsyms, skipct)

    def finddef1(defsyms, (a, b, c)):
        if re.match('#', b):
            # Preprocessor line
            return defsyms
        (b1, b2, b3) = parse_iparts(b)
        rtokens = parse_rexpr(b3)
        if b1 != '':
            defsyms.add(b1)
        if len(rtokens) &gt; 1 and rtokens[1] == '.req':
            defsyms.add(rtokens[0])
        return defsyms

    def repl1((glosyms, result), (a, b, c)):
        if re.match('#', b):
            # Preprocessor line
            result.append((a, b, c))
            return (glosyms, result)
        toglo = lambda s: 'Glo(' + s + ')'
        (b1, b2, b3) = parse_iparts(b)
        tokens = parse_expr(b3)

        if b1 in glosyms:
            b1 = toglo(b1)
        for i in range(len(tokens)):
            if token_type(tokens[i]) == 'id' and tokens[i] in glosyms:
                tokens[i] = toglo(tokens[i])
        result.append((a, b1 + b2 + ''.join(tokens), c))
        return (glosyms, result)

    reduce(findglo1, instrs, glosyms)
    reduce(findref1, instrs, (refsyms, 0))
    reduce(finddef1, instrs, defsyms)
    glosyms |= (refsyms - defsyms)
    reduce(repl1, instrs, (glosyms, result))
    return result


def local_symbols(instrs):
    # The form of a local symbol differs between Linux assemblers and
    # the Apple assember:
    #
    # Linux: .Lxxx
    # Apple: Lxxx
    #
    # Change occurrences of local symbols to use the Loc() cpp macro
    # defined in our prefix.
    #
    lsyms = set()
    result = []

    def find1 (lsyms, (a, b, c)):
        mo = re.match('(\.L[^ \t:]*)[ \t]*:', b)
        if mo:
            lsyms.add(mo.group(1))
        return lsyms

    def repl1((lsyms, result), (a, b, c)):
        matches = list(re.finditer('\.L[^ \t@:,+*/\-()]+', b))
        if matches != []:
            matches.reverse()
            newb = b
            for mo in matches:
                if mo.group() in lsyms:
                    newb = newb[0:mo.start()] + \
                            'Loc(' + mo.group()[2:] + ')' + \
                            newb[mo.end():]
            result.append((a, newb, c))
        else:
            result.append((a, b, c))
        return (lsyms, result)

    reduce(find1, instrs, lsyms)
    reduce(repl1, instrs, (lsyms, result))
    return result


def funtypes(instrs):
    # Linux assemblers accept declarations like this:
    #
    #     .type  symbol, %function
    #
    # For Thumb functions, the Apple assembler wants to see:
    #
    #     .thumb_func symbol
    #
    # Handle this by converting declarations to this:
    #
    #     .funtype symbol
    #
    # Our prefix defines an appropriate .funtype macro for each
    # environment.
    #
    result = []

    def repl1(result, (a, b, c)):
        mo = re.match('.type[ \t]+([^ \t,]*),[ \t]*%function', b)
        if mo:
            result.append((a, '.funtype  ' + mo.group(1), c))
        else:
            result.append((a, b, c))
        return result

    reduce(repl1, instrs, result)
    return result


def jump_tables(instrs):
    # Jump tables for Linux assemblers often look like this:
    #
    #     tbh [pc, rM, lsl #1]
    #     .short (.Labc-.)/2+0
    #     .short (.Ldef-.)/2+1
    #     .short (.Lghi-.)/2+2
    #
    # The Apple assembler disagrees about the meaning of this code,
    # producing jump tables that don't work.  Convert to the following:
    #
    #     tbh [pc, rM, lsl #1]
    # .LBxxx:
    #     .short (.Labc-.LBxxx)/2
    #     .short (.Ldef-.LBxxx)/2
    #     .short (.Lghi-.LBxxx)/2
    #
    # In fact we just convert sequences of .short pseudo-ops of the
    # right form.  There's no requirement that they follow a tbh
    # instruction.
    #
    baselabs = []
    result = []

    def short_match(seq, op):
        # Determine whether the op is a .short of the form that needs to
        # be converted: .short (symbol-.)/2+k.  If so, return a pair
        # containing the symbol and the value of k.  If not, return
        # None.  The short can only be converted if there were at least
        # k other .shorts in sequence before the current one.  A summary
        # of the previous .shorts is in seq.
        #
        # (A real parser would do a better job, but this was quick to
        # get working.)
        #
        sp = '([ \t]|/\*.*?\*/)*'              # space
        sp1 = '([ \t]|/\*.*?\*/)+'             # at least 1 space
        spe = '([ \t]|/\*.*?\*/|@[^\n]*)*$'    # end-of-instr space
        expr_re0 = (
            '\.short' + sp + '\(' + sp +       # .short (
            '([^ \t+\-*/@()]+)' + sp +         # symbol
            '-' + sp + '\.' + sp + '\)' + sp + # -.)
            '/' + sp + '2' + spe               # /2 END
        )
        expr_re1 = (
            '\.short' + sp + '\(' + sp +       # .short (
            '([^ \t+\-*/@()]+)' + sp +         # symbol
            '-' + sp + '\.' + sp + '\)' + sp + # -.)
            '/' + sp + '2' + sp +              # /2
            '\+' + sp +                        # +
            '((0[xX])?[0-9]+)' + spe           # k END
        )
        expr_re2 = (
            '\.short' + sp1 +                  # .short
            '((0[xX])?[0-9]+)' + sp +          # k
            '\+' + sp + '\(' + sp +            # +(
            '([^ \t+\-*/@()]+)' + sp +         # symbol
            '-' + sp + '\.' + sp + '\)' + sp + # -.)
            '/' + sp + '2' + spe               # /2 END
        )
        mo = re.match(expr_re0, op)
        if mo:
            return(mo.group(3), 0)
        mo = re.match(expr_re1, op)
        if mo:
            k = int(mo.group(11), 0)
            if k &gt; len(seq):
                return None
            return (mo.group(3), k)
        mo = re.match(expr_re2, op)
        if mo:
            k = int(mo.group(2), 0)
            if k &gt; len(seq):
                return None
            return (mo.group(7), k)
        return None

    def conv1 ((baselabs, shortseq, label, result), (a, b, c)):
        # Convert current instr (a,b,c) if it's a .short of the right
        # form that spans a previous sequence of .shorts.
        #
        (b1, b2, b3) = parse_iparts(b)

        if b3 == '':
            # No operation: just note label if present.
            result.append((a, b, c))
            if re.match('\.L.', b1):
                return (baselabs, shortseq, b1, result)
            return (baselabs, shortseq, label, result)

        if not re.match('.short[ \t]+[^ \t@]', b3):
            # Not a .short: clear shortseq and label
            result.append((a, b, c))
            return (baselabs, [], '', result)

        # We have a .short: figure out the label if any
        if re.match('\.L', b1):
            sl = b1
        else:
            sl = label

        mpair = short_match(shortseq, b3)
        if not mpair:
            # A .short, but not of right form
            shortseq.append((len(result), sl))
            result.append((a, b, c))
            return (baselabs, shortseq, '', result)

        # OK, we have a .short to convert!
        (sym, k) = mpair
        shortseq.append((len(result), sl))

        # Figure out base label (create one if necessary).
        bx = len(shortseq) - 1 - k
        bl = shortseq[bx][1]
        if bl == '':
            bl = g_basepfx + str(shortseq[bx][0])
            shortseq[bx] = (shortseq[bx][0], bl)
            baselabs.append(shortseq[bx])

        op = '.short\t(' + sym + '-' + bl + ')/2'

        result.append ((a, b1 + b2 + op, c))
        return (baselabs, shortseq, '', result)

    # Convert, accumulate result and new labels.
    reduce(conv1, instrs, (baselabs, [], '', result))

    # Add labels created here to the instruction stream.
    baselabs.reverse()
    for (ix, lab) in baselabs:
        result[ix:0] = [('', lab + ':', '\n')]

    # That does it
    return result


def dot_relative(instrs):
    # The Apple assembler (or possibly the linker) has trouble with code
    # that looks like this:
    #
    #     .word   .Label - . + 0x80000000
    #     .word   0x1966
    # .Label:
    #     .word   0x1967
    #
    # One way to describe the problem is that the assembler marks the
    # first .word for relocation when in fact it's an assembly-time
    # constant.  Translate to the following form, which doesn't generate
    # a relocation marking:
    #
    # DR0 =       .Label - . + 0x80000000
    #     .word   DR0
    #     .word   0x1966
    # .Label:
    #     .word   0x1967
    #
    prefix = 'DR'
    pseudos = '(\.byte|\.short|\.word|\.long|\.quad)'
    result = []

    def tok_ok(t):
        return t in ['.', '+', '-', '(', ')'] or \
            token_type(t) in ['space', 'locid', 'number']

    def dotrel_match(expr):
        # Determine whether the expression is one that needs to be
        # translated.
        tokens = parse_expr(expr)
        return forall(tok_ok, tokens) and \
            exists(lambda t: token_type(t) == 'locid', tokens) and \
            exists(lambda t: token_type(t) == 'number', tokens) and \
            exists(lambda t: t == '-', tokens) and \
            exists(lambda t: t == '.', tokens)

    def conv1(result, (a, b, c)):
        if re.match('#', b):
            # Preprocessor line
            result.append((a, b, c))
        else:
            (b1, b2, b3) = parse_iparts(b)
            mo = re.match(pseudos + ccce(g_ccid), b3)
            if mo:
                p = mo.group(1)
                expr = b3[len(p):]
                if dotrel_match(expr):
                    sym = prefix + str(len(result))
                    instr = sym + ' =' + expr
                    result.append(('', instr, '\n'))
                    result.append((a, b1 + b2 + p + ' ' + sym, c))
                else:
                    result.append((a, b, c))
            else:
                result.append((a, b, c))
        return result

    reduce(conv1, instrs, result)
    return result


def read_input():
    # Concatenate all the input files into a string.
    #
    def fnl(s):
        if s == '' or s[-1] == '\n':
            return s
        else:
            return s + '\n'

    if len(sys.argv) &lt; 2:
        return fnl(sys.stdin.read())
    else:
        input = ""
        for f in sys.argv[1:]:
            try:
                fd = open(f)
                input = input + fnl(fd.read())
                fd.close()
            except:
                sys.stderr.write('arm-as-to-ios: cannot open ' + f + '\n')
        return input


def parse_instrs(s):
    # Parse the string into assembly instructions, also noting C
    # preprocessor lines.  Each instruction is represented as a triple:
    # (space/comments, instruction, end).  The end is either ';' or
    # '\n'.
    #
    def goodmo(mo):
        if mo == None:
            # Should never happen
            sys.stderr.write('arm-as-to-ios: internal parsing error\n')
            sys.exit(1)

    cpp_re = '([ \t]*)(#([^\n]*\\\\\n)*[^\n]*[^\\\\\n])\n'
    comment_re = '[ \t]*#[^\n]*'
    instr_re = (
        '(([ \t]|/\*.*?\*/|@[^\n]*)*)'  # Spaces &amp; comments
        '(([ \t]|/\*.*?\*/|[^;\n])*)'   # "Instruction"
        '([;\n])'                       # End
    )
    instrs = []
    while s != '':
        if re.match('[ \t]*#[ \t]*(if|ifdef|elif|else|endif|define)', s):
            mo = re.match(cpp_re, s)
            goodmo(mo)
            instrs.append((mo.group(1), mo.group(2), '\n'))
        elif re.match('[ \t]*#', s):
            mo = re.match(comment_re, s)
            goodmo(mo)
            instrs.append((mo.group(0), '', '\n'))
        else:
            mo = re.match(instr_re, s, re.DOTALL)
            goodmo(mo)
            instrs.append((mo.group(1), mo.group(3), mo.group(5)))
        s = s[len(mo.group(0)):]
    return instrs


def parse_iparts(i):
    # Parse an instruction into smaller parts, returning a triple of
    # strings (label, colon, operation).  The colon part also contains
    # any surrounding spaces and comments (making the label and the
    # operation cleaner to process).
    #
    # (Caller warrants that the given string doesn't start with space or
    # a comment.  This is true for strings returned by the instruction
    # parser.)
    #
    lab_re = (
        '([^ \t:/@]+)'                  # Label
        '(([ \t]|/\*.*?\*/|@[^\n]*)*)'  # Spaces &amp; comments
        ':'                             # Colon
        '(([ \t]|/\*.*?\*/|@[^\n]*)*)'  # Spaces &amp; comments
        '([^\n]*)'                      # Operation
    )

    if len(i) &gt; 0 and i[0] == '#':
        # C preprocessor line; treat as operation.
        return ('', '', i)
    mo = re.match(lab_re, i)
    if mo:
        return (mo.group(1), mo.group(2) + ':' + mo.group(4), mo.group(6))
    # No label, just an operation
    return ('', '', i)


def parse_expr(s):
    # Parse a string into a sequence of tokens.  A segment of white
    # space (including comments) is treated as a token, so that the
    # tokens can be reassembled into the string again.
    #
    result = []
    while s != '':
        mo = re.match('([ \t]|/\*.*?\*/|@.*)+', s)
        if not mo:
            # Glo(...) and Loc(...) are single tokens
            mo = re.match('(Glo|Loc)\([^()]*\)', s)
        if not mo:
            mo = re.match('"([^\\\\"]|\\\\.)*"', s)
        if not mo:
            mo = re.match(g_ccid0 + g_ccid + '*', s)
        if not mo:
            mo = re.match('[0-9]+[bf]', s)
        if not mo:
            mo = re.match('0[Xx][0-9a-fA-F]+|[0-9]+', s)
        if not mo:
            mo = re.match('.', s)
        result.append(mo.group(0))
        s = s[len(mo.group(0)):]
    return result


def parse_rexpr(s):
    # Like parse_expr(), but return only "real" tokens, not the
    # intervening space.
    #
    return filter(lambda t: token_type(t) != 'space', parse_expr(s))


def token_type(t):
    # Determine the type of a token.  Caller warrants that it was
    # returned by parse_expr() or parse_rexpr().
    #
    if re.match('[ \t]|/\*|@', t):
        return 'space'
    if re.match('Glo\(', t):
        return 'gloid'
    if re.match('Loc\(', t):
        return 'locid'
    if re.match('"', t):
        return 'string'
    if re.match(g_ccid0, t):
        return 'id'
    if re.match('[0-9]+[bf]', t):
        return 'label'
    if re.match('[0-9]', t):
        return 'number'
    return t # Sui generis


def debug_parse(a, b, c):
    # Show results of instuction stream parse.
    #
    (b1, b2, b3) = parse_iparts(b)
    newb = '{' + b1 + '}' + '{' + b2 + '}' + '{' + b3 + '}'
    sys.stdout.write('{' + a + '}' + newb + c)


def main():
    instrs = parse_instrs(read_input())
    instrs = explicit_address_loads(instrs)
    instrs = funtypes(instrs)
    instrs = jump_tables(instrs)
    instrs = global_symbols(instrs)
    instrs = local_symbols(instrs)
    instrs = dot_relative(instrs)
    instrs = add_prefix(instrs)
    for (a, b, c) in instrs:
       sys.stdout.write(a + b + c)


main()

OCaml 4.00.0 on iOS: Progress Report

2012-08-25T11:00:00-08:00

August 25, 2012

After finding and resolving some problems, two of which were very interesting, I’m getting close to releasing a version of OCaml 4.00.0 that cross-compiles for iOS devices. I’ve tested it with all the OCaml iOS apps I can, and my colleagues at SEAiq have tested with their iOS apps also.

Update: OCamlXARM 3.1, based on OCaml 4.00.0, has been released! Read my blog post OCaml 4.00.0 on iOS Is Released. The OCaml-on-iOS page Compile OCaml for iOS has been updated for OCamlXARM 3.1.

I call the compiler OCamlXARM because it runs on a Mac, and cross-compiles for ARM-based iOS devices. You can read about the current release of OCamlXARM in Compile OCaml for iOS.

Initially the new version will compile only for armv7/Thumb, which means the generated apps will only run on moderately recent iOS devices (including all iPads). I’ll release an update that compiles for armv6/ARM, which will be able to create apps for all the historical iOS devices.

If you’re interested in trying a prerelease of the OCaml 4.00.0 cross compiler, send me an email. I recommend this for the adventurous only, but it’s extremely useful to me to get feedback on what works and doesn’t. The less adventurous can try the current release, linked above. The current release is based on OCaml 3.10.2 (a pretty old version admittedly), and has been used to create production iOS apps for a few years now.

For those interested in the ups and downs of doing the port, I wrote about earlier development stages in OCaml 4.00.0 Working on iOS. Here are the two interesting problems that came up recently.

While running a test version of our Cassino app I uncovered a code generation bug in the OCaml 4.00.0 compiler. It turned out to be in the scheduling pass, which reorders instructions to make them execute faster. This has been fixed by the experts at OCaml HQ—you can read about it as Mantis issue 5731. The fix will appear in the next bugfix release of OCaml (scheduled to be 4.00.1), but I’ve also merged the fix into OCamlXARM. Many thanks to (the illustrious) Xavier Leroy for looking at and fixing the problem.

I also had the pleasure to discover what I consider a bug in Apple’s iOS assembler (or possibly it’s a problem with the link editor). You can see the problem in this simple example, using the cross-development versions of the assembler and the link editor—as and ld—from the Xcode 4.3.3 iOS toolchain:

$ cat diffplus.s
        .data
        .word Lsym - . + 0x80000000
        .word 0x1966
Lsym:
        .word 0x1967
$ as -arch armv7 -o diffplus.o diffplus.s
$ otool -d diffplus.o
diffplus.o:
(__DATA,__data) section
00000000        80000008 00001966 00001967 
$ otool -rv diffplus.o
diffplus.o:
Relocation information (__DATA,__data) 2 entries
address  pcrel length extern type    scattered symbolnum/value
00000000 False long   n/a    SECTDIFFTrue      0x00000008
         False long   n/a    PAIR    True      0x00000000

What the otool output shows is that the three generated 32-bit values have the proper values. However, the first of the values is marked as a (somewhat strange) relocatable value. This is incorrect—all of the values are assembly-time constants, and no relocation is required. This error seems to prevent some types of linking of the generated object file:

$ ld -r -o ldr1.o diffplus.o
$ ld -r -o ldr2.o ldr1.o
ld: in ldr1.o, in section __DATA,__data reloc 0: sectionForAddress(0x80000000) address not in any section for inferred architecture armv7
$

The purpose of ld -r is to do incremental linking, that is, to combine several object files (.o files) into one. For files like diffplus.o, however, ld generates an invalid object file as output. If you try to process the file with a later run of ld, you get the error shown.

Unfortunately, the OCaml compiler creates output that looks exactly like diffplus.s above. Lines like this are used in the frame tables that describe OCaml function call sites, used by the garbage collector to avoid collecting values that will still be live when the call returns. Furthermore, ld -r is used internally to implement the OCaml compiler’s -output-obj flag.

After some experimentation I found a workaround. The following assembly code avoids the (seeming) bug in as:

$ cat diffplusok.s
        .data
offset001 = Lsym - . + 0x80000000
        .word offset001
        .word 0x1966
Lsym:
        .word 0x1967
$ as -arch armv7 -o diffplusok.o diffplusok.s
$ otool -d diffplusok.o
diffplusok.o:
(__DATA,__data) section
00000000        80000008 00001966 00001967 
$ otool -rv diffplusok.o
diffplusok.o:
$
$ ld -r -o ldrok1.o diffplusok.o
$ ld -r -o ldrok2.o ldrok1.o
$

This transformed version convinces the assembler that the value is constant at assembly time, so there are no relocation markings in the generated file. This doesn’t present any problems for ld, and so incremental linking works OK.

If no other big problems appear, the new release will be available shortly. The new version will be OCamlXARM 3.1. I’m looking forward to trying out some of the more modern OCaml features in my iOS programming, and I’d also like to do some timing tests. I wonder whether armv7/Thumb code is faster than the armv6/ARM code generated by the previous OCamlXARM release. I’ve also started to be curious how much the scheduling pass (where the recent bug was fixed) improves the speed of my code.

If you have comments or questions, please leave them below, or email me at jeffsco@psellos.com.

Posted by: Jeffrey

Run Debian ARMEL Linux on OS X with QEMU

2012-08-15T11:00:00-08:00

August 15, 2012

While getting OCaml 4.00.0 working on iOS I’ve often wanted an ARM-based Linux system for testing out the stock OCaml compiler. Now I have one, running inside QEMU on my Mac!

QEMU is an impressive system that emulates ten or twelve different hardware systems at an amazing level of detail yet with good performance. A couple of the emulated systems are based on ARM and let you boot a Linux system (such as Debian Squeeze, which is what I used). In essence, QEMU does what I thought the iOS Simulator did, before I found out how it really works. I learned about QEMU from Benedikt Meurer on the OCaml mailing list—he suggested it for running the OCaml 4.00.0/ARM compiler.

The only downside is that it’s extremely tricky to get the ARM subsystem of QEMU working under OS X right now. Many things are in flux: new versions of QEMU, OS X, and Xcode have already come out. So things might be working well by the time you read this. Unfortunately, right now (August 15, 2012) recent versions of QEMU, OS X, and Xcode don’t work together. And realistically it could be a while until they do.

After trying many things, I found a page by Jeremy Kahn that explains how to build QEMU for OS X with Homebrew. Homebrew is a package manager for OS X based on Ruby and Git. It seems to be getting a lot of play these days, and I use it myself.

I made a couple of corrections to Jeremy’s steps. For posterity, here are the steps I followed to get Debian Squeeze ARMEL working under QEMU on my Mac. I have Xcode 4.3.3 and OS X 10.7.4 (Lion).

(Edit: Jeremy has updated his page to include my corrections.)

Preliminaries

Install Xcode. You can download it for free from the Mac App Store.
In Xcode -> Preferences go to Downloads -> Components. Install the Command Line Tools.
Install Homebrew, as directed on the Homebrew Home Page. Make sure your Homebrew is up to date:

$ brew update

Install QEMU

Here begins the tricky part. The ARM subpart of latest QEMU built by Homebrew doesn’t work. It hangs indefinitely at startup, as I can attest from experience. You need to trick Homebrew into using version 1.1.0 of QEMU. You don’t want version 1.1.0-1 (the latest version as of this writing). We’re going to check out an old version of the Homebrew recipe and use that to build QEMU:

$ cd /usr/local   # (or wherever you installed Homebrew)
$ git checkout 2b7b4b3027 Library/Formula/qemu.rb

If you look at the replacement recipe you should see that it uses QEMU 1.1.0 exactly.

$ grep url Library/Formula/qemu.rb
  url 'http://wiki.qemu.org/download/qemu-1.1.0.tar.bz2'

Even more trickery is required. The gcc that comes with the latest Xcode can’t be used to build QEMU. Download an older version as follows:

$ brew install https://raw.github.com/Homebrew/homebrew-dupes/master/apple-gcc42.rb

(Warning: this is a long line. If you cut and paste, be sure to get it all.)

After this, you should have gcc 4.2:

$ which gcc-4.2
/usr/local/bin/gcc-4.2

Build and install QEMU using the alternate compiler:

$ brew install qemu --use-gcc

If it works, you should have qemu-system-arm, the QEMU executable for the full-system ARM emulator.

$ which qemu-system-arm
/usr/local/bin/qemu-system-arm

Install Debian Squeeze ARMEL

You can download the necessary disk image and support files for booting Debian on QEMU from Aurélien Jarno’s ARM QEMU Files at Debian HQ. You need a disk image (debian_*.qcow2), an initial ramdisk (initrd.img-*) and a kernel file (vmlinuz-*). Here are the commands to download the ones I used for Debian Squeeze:

$ curl -O http://people.debian.org/~aurel32/qemu/armel/debian_squeeze_armel_standard.qcow2

$ curl -O http://people.debian.org/~aurel32/qemu/armel/initrd.img-2.6.32-5-versatile

$ curl -O http://people.debian.org/~aurel32/qemu/armel/vmlinuz-2.6.32-5-versatile

(You might find it more convenient to download from the website. Otherwise, be careful of these long command lines.)

You can now boot Debian Squeeze inside the QEMU emulation of ARM:

$ qemu-system-arm -nographic -M versatilepb \
-kernel vmlinuz-2.6.32-5-versatile \
-initrd initrd.img-2.6.32-5-versatile \
-hda debian_squeeze_armel_standard.qcow2 \
-append "root=/dev/sda1 console=ttyAMA0"

You should see many lines of boot output, then a login prompt:

debian-armel login:

The root password is root. There is a nonprivileged user account named user, whose password is also user.

To exit the emulator, type “^A x” (Control-a, then x).

The emulator works exceptionally well—well enough that I successfully built the OCaml 4.00.0 compiler from sources and then ran tests with it. There is one smallish problem that the (simulated) SCSI disk seems to encounter hardware errors occasionally. I’ve never heard of hardware errors with a simulated piece of hardware! (I guess you could say this makes the simulation even more accurate.) My web searches suggest that this is a known problem that will be fixed in a future release of QEMU.

I find it strangely thrilling to run a simulated ARM system on my Mac. (Pehaps I’m too easily thrilled.)

If you have any corrections, improvements, or other comments, leave them below or email me at jeffsco@psellos.com.

Posted by: Jeffrey

Convert Linux ARM Assembly Code for iOS (Update 2)

2012-08-04T11:00:00-08:00

August 4, 2012

Note: I wrote a new, improved version of this script, described in Convert Linux ARM Assembly Code for iOS (Update 3).

The output of the script is upward compatible. By this I mean that a converted assembly file is supposed to work in its originally supported Linux environments as well as in iOS. In theory this means that the converted assembly files could be sent “upstream” to maintainers (if they’re comfortable with supporting iOS and/or the extra complexity of the code).

The current version of arm-as-to-ios is 1.3.0. In its current form, it does the following conversions:

Declare the ARM architecture for iOS with a .machine pseudo-op. The possibilities are armv6 and armv7.
Specify that armv7 code should use the more space-efficient Thumb encoding in iOS.
Generate declarations for functions, similar to the .type pseudo-op for Linux assemblers. It appears that Apple requires .thumb_func declarations only for Thumb functions. Other symbols are apparently assumed to be ARM functions. To make this work upward-compatibly, I define an assembly macro named .funtype that is expanded properly in the different environments.
Make sure that global symbols have the right format. For Linux, they look like “abc”. For iOS, they look like “_abc” (with a leading underscore). To support upward compatibility, this is handled by a cpp macro named Glo() that generates the proper symbol form for each environment.
Make sure that assembler-local symbols have the right format. For Linux assemblers, they look like “.Lxxx”. For the iOS assembler, they look like “Lxxx”. To support upward compatibly, this is handled by a cpp macro named Loc() that generates the proper symbol form for each environment.
Replace uses of =value notation by explicit loads from memory. The Linux ARM assemblers interpret ldr rM, =value to mean that the value should be loaded into register M immediately (using mov) if possible, and loaded from memory (using ldr with PC-relative addressing) otherwise. The Apple assembler seems not to support this, so arm-as-to-ios replaces uses of =value with explicit memory loads, emitting the pool of values into the .text segment at the end of the file.
Convert jump tables (for the tbh instruction) to a form that works with the iOS assembler. The form commonly used in Linux generates a bad jump table under iOS—apparently the iOS assembler interprets the expressions differently.
Remove uses of two pseudo-ops, .type and .size, when assembling for iOS. They aren’t supported by Apple’s assembler. This is done by defining null assembly macros for them.
Define a macro cbz when using ARM encodings for iOS. The cbz instruction is Thumb-only. The definition replaces it with a pair of ARM instructions.

You can download the script here:

arm-as-to-ios—modify ARM assembly code for use on iOS

The full text of the script is also included at the end of this post.

This is the third version of arm-as-to-ios, and there may well be a few more changes when I work on the armv6 architecture. As I make changes, I’ll keep the linked script up to date. If there are significant changes I’ll make another post about them.

If you want to try out arm-as-to-ios, copy and paste the lines from the end of this post into a file named arm-as-to-ios, or download it from the above link. Mark it as a script with chmod:

$ chmod +x arm-as-to-ios

To use the script, specify the name of an ARM assembly file. If no files are given, the script processes its standard input.

The following small example demonstrates the translations that arm-as-to-ios performs. Here is a small file of Linux ARM assembly code:

        .syntax unified
        .text
        .align  2
        .globl  example
        .type example, %function
example:
        sub     r10, r10, 8
        cmp     r10, r11
        bcc     1f
        bx      lr
1:
        ldr     r7, =last_return_address
        str     lr, [r7]
        bl      .Lcall_gc
        ldr     lr, [r7]
        b       example

.Lcall_gc:
        ldr     r12, =bottom_of_stack
        str     sp, [r12]
        bl      garbage_collection
        bx      lr

.Ljump:
# A jump table (code fragment).
        tbh     [pc, r4, lsl #1]
        .short  (.Ltest1-.)/2+0
        .short  (.Ltest2-.)/2+1
        .short  (.Ltest3-.)/2+2
.Ltest1:
        ldr     r4, [r4]
.Ltest2:
        str     r6, [sp, 8]
.Ltest3:
        str     r8, [r12]

If you run arm-as-to-ios on this file, you get the following output that works for both Linux and iOS assemblers:

        .syntax unified

/* Apple compatibility macros */
#if defined(SYS_macosx)
#define Glo(s) _##s
#define Loc(s) L##s
#if defined(MODEL_armv6)
        .machine  armv6
        .macro  .funtype
        .endm
        .macro  cbz
        cmp     $0, #0
        beq     $1
        .endm
#else
        .machine  armv7
        .thumb
        .macro  .funtype
        .thumb_func $0
        .endm
#endif
        .macro  .type
        .endm
        .macro  .size
        .endm
#else
#define Glo(s) s
#define Loc(s) .L##s
        .macro  .funtype symbol
        .type  \symbol, %function
        .endm
#endif
/* End Apple compatibility macros */

        .text
        .align  2
        .globl  Glo(example)
        .funtype  Glo(example)
Glo(example):
        sub     r10, r10, 8
        cmp     r10, r11
        bcc     1f
        bx      lr
1:
        ldr     r7, Loc(Plast_return_address)
        str     lr, [r7]
        bl      Loc(call_gc)
        ldr     lr, [r7]
        b       Glo(example)

Loc(call_gc):
        ldr     r12, Loc(Pbottom_of_stack)
        str     sp, [r12]
        bl      Glo(garbage_collection)
        bx      lr

Loc(jump):
# A jump table (code fragment).

        tbh     [pc, r4, lsl #1]
Loc(B27):
        .short  (Loc(test1)-Loc(B27))/2
        .short  (Loc(test2)-Loc(B27))/2
        .short  (Loc(test3)-Loc(B27))/2
Loc(test1):
        ldr     r4, [r4]
Loc(test2):
        str     r6, [sp, 8]
Loc(test3):
        str     r8, [r12]

/* Pool of addresses loaded into registers */

        .text
        .align 2
Loc(Plast_return_address):
        .long Glo(last_return_address)
Loc(Pbottom_of_stack):
        .long Glo(bottom_of_stack)

The output consists of a fixed prefix followed by the translation of the input file, followed by the pool of values to be loaded into registers.

The following shows a successful assembly of the arm.S file from OCaml 4.00.0:

$ PLT=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform
$ PLTBIN=$PLT/Developer/usr/bin
$ arm-as-to-ios asmrun/arm.S &gt; armios.S
$ $PLTBIN/gcc -c -arch armv7 -DSYS_macosx -DMODEL_armv7 -o armios.o armios.S
$ file armios.o
armios.o: Mach-O object arm
$ otool -tv armios.o | head
armios.o:
(__TEXT,__text) section
caml_call_gc:
00000000        f8dfc1e0        ldr.w   ip, [pc, #480]  @ 0x1e4
00000004        f8cce000        str.w   lr, [ip]
00000008        f8dfc1dc        ldr.w   ip, [pc, #476]  @ 0x1e8
0000000c        f8ccd000        str.w   sp, [ip]
00000010        ed2d0b10        vstmdb  sp!, {d0-d7}
00000014        e92d50ff        stmdb   sp!, {r0, r1, r2, r3, r4, r5, r6, r7, ip, lr}
00000018        f8dfc1d0        ldr.w   ip, [pc, #464]  @ 0x1ec

If you have any corrections, improvements, or other comments, leave them below or email me at jeffsco@psellos.com. I’d be very pleased to hear if the script has been helpful to anyone.

Posted by: Jeffrey

Appendix

Here is the current text of the script:

#!/usr/bin/env python
#
# arm-as-to-ios     Modify ARM assembly code for the iOS assembler
#
# Copyright (c) 2012 Psellos   http://psellos.com/
# Licensed under the MIT License:
#     http://www.opensource.org/licenses/mit-license.php
#
# Resources for running OCaml on iOS: http://psellos.com/ocaml/
#
import sys
import re

VERSION = '1.3.0'

# Prefixes for pooled symbol labels and jump table base labels.  They're
# in the space of Linux assembler local symbols.  Later rules will
# modify them to the Loc() form.
#
g_poolpfx = '.LP'
g_basepfx = '.LB'


def add_prefix(instrs):
    # Add compatibility macros for all systems, plus hardware
    # definitions and compatibility macros for iOS.
    #
    # All systems:
    #
    # Glo()     cpp macro for making global symbols (xxx vs _xxx)
    # Loc()     cpp macro for making local symbols (.Lxxx vs Lxxx)
    # .funtype  Expands to .thumb_func for iOS armv7 (null for armv6)
    #           Expands to .type %function for others
    #
    # iOS:
    #
    # .machine  armv6/armv7
    # .thumb    (for armv7)
    # cbz       Expands to cmp/beq for armv6 (Thumb-only instr)
    # .type     Not supported by Apple assembler
    # .size     Not supported by Apple assembler
    #
    defre = '#[ \t]*if.*def.*SYS'  # Add new defs near first existing ones
    skipre = '$|\.syntax[ \t]'     # Skip comment lines (and .syntax)

    for i in range(len(instrs)):
        if re.match(defre, instrs[i][1]):
            break
    else:
        i = 0
    for i in range(i, len(instrs)):
        if not re.match(skipre, instrs[i][1]):
            break
    instrs[i:0] = [
        ('', '', '\n'),
        ('/* Apple compatibility macros */', '', '\n'),
        ('', '#if defined(SYS_macosx)', '\n'),
        ('', '#define Glo(s) _##s', '\n'),
        ('', '#define Loc(s) L##s', '\n'),
        ('', '#if defined(MODEL_armv6)', '\n'),
        ('        ', '.machine  armv6', '\n'),
        ('        ', '.macro  .funtype', '\n'),
        ('        ', '.endm', '\n'),
        ('        ', '.macro  cbz', '\n'),
        ('        ', 'cmp     $0, #0', '\n'),
        ('        ', 'beq     $1', '\n'),
        ('        ', '.endm', '\n'),
        ('', '#else', '\n'),
        ('        ', '.machine  armv7', '\n'),
        ('        ', '.thumb', '\n'),
        ('        ', '.macro  .funtype', '\n'),
        ('        ', '.thumb_func $0', '\n'),
        ('        ', '.endm', '\n'),
        ('', '#endif', '\n'),
        ('        ', '.macro  .type', '\n'),
        ('        ', '.endm', '\n'),
        ('        ', '.macro  .size', '\n'),
        ('        ', '.endm', '\n'),
        ('', '#else', '\n'),
        ('', '#define Glo(s) s', '\n'),
        ('', '#define Loc(s) .L##s', '\n'),
        ('        ', '.macro  .funtype symbol', '\n'),
        ('        ', '.type  \\symbol, %function', '\n'),
        ('        ', '.endm', '\n'),
        ('', '#endif', '\n'),
        ('/* End Apple compatibility macros */', '', '\n'),
        ('', '', '\n')
    ]
    return instrs


# Regular expression for modified ldr lines
#
g_ldre = '(ldr[ \t][^,]*,[ \t]*)=(([^ \t\n@,/]|/(?!\*))*)(.*)'


def explicit_address_loads(instrs):
    # Linux assemblers allow the following:
    #
    #     ldr rM, =symbol
    #
    # which loads rM with [mov] (immediately) if possible, or creates an
    # entry in memory for the symbol value and loads it PC-relatively
    # with [ldr].
    #
    # The Apple assembler doesn't seem to support this notation.  If the
    # value is a suitable constant, it emits a valid [mov].  Otherwise
    # it seems to emit an invalid [ldr] that always generates an error.
    # (At least I have not been able to make it work).  So, change uses
    # of =symbol to explicit PC-relative loads.
    #
    # This requires a pool containing the addresses to be loaded.  For
    # now, we just keep track of it ourselves and emit it into the text
    # segment at the end of the file.
    #
    syms = {}
    result = []

    def repl1((syms, result), (a, b, c)):
        global g_poolpfx
        global g_ldre
        (b1, b2, b3) = parse_iparts(b)
        mo = re.match(g_ldre, b3, re.DOTALL)
        if mo:
            if mo.group(2) not in syms:
                syms[mo.group(2)] = len(syms)
            psym = mo.group(2)
            if psym[0:2] == '.L':
                psym = psym[2:]
            newb3 = mo.group(1) + g_poolpfx + psym + mo.group(4)
            result.append((a, b1 + b2 + newb3, c))
        else:
            result.append((a, b, c))
        return (syms, result)

    def pool1(result, s):
        global g_poolpfx
        psym = s
        if psym[0:2] == '.L':
            psym = psym[2:]
        result.append(('', g_poolpfx + psym + ':', '\n'))
        result.append(('        ', '.long ' + s, '\n'))
        return result

    reduce(repl1, instrs, (syms, result))
    if len(syms) &gt; 0:
        result.append(('', '', '\n'))
        result.append(('/* Pool of addresses loaded into registers */',
                        '', '\n'))
        result.append(('', '', '\n'))
        result.append(('        ', '.text', '\n'))
        result.append(('        ', '.align 2', '\n'))
        reduce(pool1, sorted(syms, key=syms.get), result)
    return result


def global_symbols(instrs):
    # The form of a global symbol differs between Linux assemblers and
    # the Apple assember:
    #
    # Linux: xxx
    # Apple: _xxx
    #
    # Change occurrences of global symbols to use the Glo() cpp macro
    # defined in our prefix.
    #
    # We consider a symbol to be global if:
    #
    # a.  It appears in a .globl declaration; or
    # b.  It appears, doesn't have local form, and is not defined
    #
    endsy = '($|[^a-zA-Z0-9])' # End of a symbol

    allsyms = set()
    defsyms = set()
    glosyms = set()
    result = []

    def findglob1 (glosyms, (a, b, c)):
        mo = re.match('\.globl[ \t]+([^ \t@:,+\-*/()]+)', b)
        if mo:
            glosyms.add(mo.group(1))
        return glosyms

    def findany1 ((allsyms, skipct), (a, b, c)):

        def looksglobal(s):
            if re.match('(r|a|v|p|c|cr|f|s|d|q|mvax|wcgr)[0-9]+$', s, re.I):
                return False # numbered registers
            if re.match('(wr|sb|sl|fp|ip|sp|lr|pc)$', s, re.I):
                return False # named registers
            if re.match('(fpsid|fpscr|fpexc|mvfr1|mvfr0)$', s, re.I):
                return False # more named registers
            if re.match('(mvf|mvd|mvfx|mvdx|dspsc)$', s, re.I):
                return False # even more named registers
            if re.match('(wcid|wcon|wcssf|wcasf|acc)$', s, re.I):
                return False # even more named registers
            if re.match('\.L|[0-9]|#', s):
                return False # local symbol or number
            if re.match('(asl|lsl|lsr|asr|ror|rrx)$', s, re.I):
                return False # shift names
            return True

        if re.match('#', b):
            return (allsyms, skipct)
        # Track nesting of .macro/.endm.  For now, we don't look for
        # global syms in macro defs.  (Avoiding scoping probs etc.)
        #
        if skipct &gt; 0 and re.match('\.(endm|endmacro)' + endsy, b):
            return (allsyms, skipct - 1)
        if re.match('\.macro' + endsy, b):
            return (allsyms, skipct + 1)
        if skipct &gt; 0:
            return (allsyms, skipct)
        if re.match('\.(type|size|syntax|arch|fpu)' + endsy, b):
            return (allsyms, skipct)
        lb = b
        lb = re.sub('@.*', '', lb)
        lb = re.sub('/\*.*?\*/', '', lb)
        mo = re.match('[^:]*:[ \t]*(.*)', lb)
        if mo:
            lb = mo.group(1)
        lb = re.match('[^ \t]*[ \t]*(.*)', lb).group(1)
        if re.match('\.req', lb):
            return (allsyms, skipct)
        for s in re.findall('[^ \t@:,+\-*/[\]{}()]+', lb):
            if looksglobal(s):
                allsyms.add(s)
        return (allsyms, skipct)

    def finddef1(defsyms, (a, b, c)):
        mo = re.match('([^ \t]+)[ \t]+\.req' + endsy, b) \
                or re.match('([^ \t:]+)[ \t]*:', b)
        if mo:
            defsyms.add(mo.group(1))
        return defsyms

    def repl1((glosyms, result), (a, b, c)):
        if re.match('#', b):
            # Preprocessor line
            result.append((a, b, c))
        else:
            matches = list(re.finditer('[^ \t@:,+*/-]+', b))
            if matches != []:
                matches.reverse()
                newb = b
                for mo in matches:
                    if mo.group() in glosyms:
                        newb = newb[0:mo.start()] + \
                                'Glo(' + mo.group() + ')' + \
                                newb[mo.end():]
                result.append((a, newb, c))
            else:
                result.append((a, b, c))
        return (glosyms, result)

    reduce(findglob1, instrs, glosyms)
    reduce(findany1, instrs, (allsyms, 0))
    reduce(finddef1, instrs, defsyms)
    glosyms |= (allsyms - defsyms)
    reduce(repl1, instrs, (glosyms, result))
    return result


def local_symbols(instrs):
    # The form of a local symbol differs between Linux assemblers and
    # the Apple assember:
    #
    # Linux: .Lxxx
    # Apple: Lxxx
    #
    # Change occurrences of local symbols to use the Loc() cpp macro
    # defined in our prefix.
    #
    lsyms = set()
    result = []

    def find1 (lsyms, (a, b, c)):
        mo = re.match('(\.L[^ \t:]*)[ \t]*:', b)
        if mo:
            lsyms.add(mo.group(1))
        return lsyms

    def repl1((lsyms, result), (a, b, c)):
        matches = list(re.finditer('\.L[^ \t@:,+*/\-()]+', b))
        if matches != []:
            matches.reverse()
            newb = b
            for mo in matches:
                if mo.group() in lsyms:
                    newb = newb[0:mo.start()] + \
                            'Loc(' + mo.group()[2:] + ')' + \
                            newb[mo.end():]
            result.append((a, newb, c))
        else:
            result.append((a, b, c))
        return (lsyms, result)

    reduce(find1, instrs, lsyms)
    reduce(repl1, instrs, (lsyms, result))
    return result


def funtypes(instrs):
    # Linux assemblers accept declarations like this:
    #
    #     .type  symbol, %function
    #
    # For Thumb functions, the Apple assembler wants to see:
    #
    #     .thumb_func symbol
    #
    # Handle this by converting declarations to this:
    #
    #     .funtype symbol
    #
    # Our prefix defines an appropriate .funtype macro for each
    # environment.
    #
    result = []

    def repl1(result, (a, b, c)):
        mo = re.match('.type[ \t]+([^ \t,]*),[ \t]*%function', b)
        if mo:
            result.append((a, '.funtype  ' + mo.group(1), c))
        else:
            result.append((a, b, c))
        return result

    reduce(repl1, instrs, result)
    return result


def jump_tables(instrs):
    # Jump tables for Linux assemblers often look like this:
    #
    #     tbh [pc, rM, lsl #1]
    #     .short (.Labc-.)/2+0
    #     .short (.Ldef-.)/2+1
    #     .short (.Lghi-.)/2+2
    #
    # The Apple assembler disagrees about the meaning of this code,
    # producing jump tables that don't work.  Convert to the following:
    #
    #     tbh [pc, rM, lsl #1]
    # .LBxxx:
    #     .short (.Labc-.LBxxx)/2
    #     .short (.Ldef-.LBxxx)/2
    #     .short (.Lghi-.LBxxx)/2
    #
    # In fact we just convert sequences of .short pseudo-ops of the
    # right form.  There's no requirement that they follow a tbh
    # instruction.
    #
    baselabs = []
    result = []

    def short_match(seq, op):
        # Determine whether the op is a .short of the form that needs to
        # be converted: .short (symbol-.)/2+k.  If so, return a pair
        # containing the symbol and the value of k.  If not, return
        # None.  The short can only be converted if there were at least
        # k other .shorts in sequence before the current one.  A summary
        # of the previous .shorts is in seq.
        #
        # (A real scanner and parser would do a better job, but this was
        # quick to get working.)
        #
        sp = '([ \t]|/\*.*?\*/)*'              # space
        sp1 = '([ \t]|/\*.*?\*/)+'             # at least 1 space
        spe = '([ \t]|/\*.*?\*/|@[^\n]*)*$'    # end-of-instr space
        expr_re0 = (
            '\.short' + sp + '\(' + sp +       # .short (
            '([^ \t+\-*/@()]+)' + sp +         # symbol
            '-' + sp + '\.' + sp + '\)' + sp + # -.)
            '/' + sp + '2' + spe               # /2 END
        )
        expr_re1 = (
            '\.short' + sp + '\(' + sp +       # .short (
            '([^ \t+\-*/@()]+)' + sp +         # symbol
            '-' + sp + '\.' + sp + '\)' + sp + # -.)
            '/' + sp + '2' + sp +              # /2
            '\+' + sp +                        # +
            '((0[xX])?[0-9]+)' + spe           # k END
        )
        expr_re2 = (
            '\.short' + sp1 +                  # .short
            '((0[xX])?[0-9]+)' + sp +          # k
            '\+' + sp + '\(' + sp +            # +(
            '([^ \t+\-*/@()]+)' + sp +         # symbol
            '-' + sp + '\.' + sp + '\)' + sp + # -.)
            '/' + sp + '2' + spe               # /2 END
        )
        mo = re.match(expr_re0, op)
        if mo:
            return(mo.group(3), 0)
        mo = re.match(expr_re1, op)
        if mo:
            k = int(mo.group(11), 0)
            if k &gt; len(seq):
                return None
            return (mo.group(3), k)
        mo = re.match(expr_re2, op)
        if mo:
            k = int(mo.group(2), 0)
            if k &gt; len(seq):
                return None
            return (mo.group(7), k)
        return None

    def conv1 ((baselabs, shortseq, label, result), (a, b, c)):
        # Convert current instr (a,b,c) if it's a .short of the right
        # form that spans a previous sequence of .shorts.
        #
        (b1, b2, b3) = parse_iparts(b)

        if b3 == '':
            # No operation: just note label if present.
            result.append((a, b, c))
            if re.match('\.L.', b1):
                return (baselabs, shortseq, b1, result)
            return (baselabs, shortseq, label, result)

        if not re.match('.short[ \t]+[^ \t@]', b3):
            # Not a .short: clear shortseq and label
            result.append((a, b, c))
            return (baselabs, [], '', result)

        # We have a .short: figure out the label if any
        if re.match('\.L', b1):
            sl = b1
        else:
            sl = label

        mpair = short_match(shortseq, b3)
        if not mpair:
            # A .short, but not of right form
            shortseq.append((len(result), sl))
            result.append((a, b, c))
            return (baselabs, shortseq, '', result)

        # OK, we have a .short to convert!
        (sym, k) = mpair
        shortseq.append((len(result), sl))

        # Figure out base label (create one if necessary).
        bx = len(shortseq) - 1 - k
        bl = shortseq[bx][1]
        if bl == '':
            bl = g_basepfx + str(shortseq[bx][0])
            shortseq[bx] = (shortseq[bx][0], bl)
            baselabs.append(shortseq[bx])

        op = '.short\t(' + sym + '-' + bl + ')/2'

        result.append ((a, b1 + b2 + op, c))
        return (baselabs, shortseq, '', result)

    # Convert, accumulate result and new labels.
    reduce(conv1, instrs, (baselabs, [], '', result))

    # Add labels created here to the instruction stream.
    baselabs.reverse()
    for (ix, lab) in baselabs:
        result[ix:0] = [('', lab + ':', '\n')]

    # That does it
    return result


def read_input():
    # Concatenate all the input files into a string.
    #
    def fnl(s):
        if s == '' or s[-1] == '\n':
            return s
        else:
            return s + '\n'

    if len(sys.argv) &lt; 2:
        return fnl(sys.stdin.read())
    else:
        input = ""
        for f in sys.argv[1:]:
            try:
                fd = open(f)
                input = input + fnl(fd.read())
                fd.close()
            except:
                sys.stderr.write('arm-as-to-ios: cannot open ' + f + '\n')
        return input


def parse_instrs(s):
    # Parse the string into assembly instructions, also noting C
    # preprocessor lines.  Each instruction is represented as a triple:
    # (space/comments, instruction, end).  The end is either ';' or
    # '\n'.  Instructions might have embedded comments, but they
    # probably won't get fixed up if they do.  (I've never seen it in
    # real code.)
    #
    def goodmo(mo):
        if mo == None:
            # Should never happen
            sys.stderr.write('arm-as-to-ios: internal parsing error\n')
            sys.exit(1)

    cpp_re = '([ \t]*)(#([^\n]*\\\\\n)*[^\n]*[^\\\\\n])\n'
    comment_re = '[ \t]*#[^\n]*'
    instr_re = (
        '(([ \t]|/\*.*?\*/|@[^\n]*)*)'  # Spaces &amp; comments
        '(([ \t]|/\*.*?\*/|[^;\n])*)'   # "Instruction"
        '([;\n])'                       # End
    )
    instrs = []
    while s != '':
        if re.match('[ \t]*#[ \t]*(if|ifdef|elif|else|endif|define)', s):
            mo = re.match(cpp_re, s)
            goodmo(mo)
            instrs.append((mo.group(1), mo.group(2), '\n'))
        elif re.match('[ \t]*#', s):
            mo = re.match(comment_re, s)
            goodmo(mo)
            instrs.append((mo.group(0), '', '\n'))
        else:
            mo = re.match(instr_re, s, re.DOTALL)
            goodmo(mo)
            instrs.append((mo.group(1), mo.group(3), mo.group(5)))
        s = s[len(mo.group(0)):]
    return instrs


def parse_iparts(i):
    # Parse an instruction into smaller parts, returning a triple of
    # strings (label, colon, operation).  The colon part also contains
    # any surrounding spaces and comments (making the label and the
    # operation cleaner to process).
    #
    # (Caller warrants that the given string doesn't start with space or
    # a comment.  This is true for strings returned by the instruction
    # parser.)
    #
    lab_re = (
        '([^ \t:/@]+)'                  # Label
        '(([ \t]|/\*.*?\*/|@[^\n]*)*)'  # Spaces &amp; comments
        ':'                             # Colon
        '(([ \t]|/\*.*?\*/|@[^\n]*)*)'  # Spaces &amp; comments
        '([^\n]*)'                      # Operation
    )

    if len(i) &gt; 0 and i[0] == '#':
        # C preprocessor line; treat as operation.
        return ('', '', i)
    mo = re.match(lab_re, i)
    if mo:
        return (mo.group(1), mo.group(2) + ':' + mo.group(4), mo.group(6))
    # No label, just an operation
    return ('', '', i)


def debug_parse(a, b, c):
    # Show results of instuction stream parse.
    #
    (b1, b2, b3) = parse_iparts(b)
    newb = '{' + b1 + '}' + '{' + b2 + '}' + '{' + b3 + '}'
    sys.stdout.write('{' + a + '}' + newb + c)


def main():
    instrs = parse_instrs(read_input())
    instrs = explicit_address_loads(instrs)
    instrs = funtypes(instrs)
    instrs = jump_tables(instrs)
    instrs = global_symbols(instrs)
    instrs = local_symbols(instrs)
    instrs = add_prefix(instrs)
    for (a, b, c) in instrs:
       sys.stdout.write(a + b + c)


main()

OCaml 4.00.0 Working on iOS

2012-07-31T11:00:00-08:00

July 31, 2012

I’ve been having a great time modifying OCaml 4.00.0 to work on iOS, and today I was able to build the Portland example app with my modified compiler, and run it on an iPod Touch. It seems to be running normally (knock on wood), so things are looking very good. Before releasing it I want to test some more demanding apps, and also clean up a few loose ends.

I call the compiler OCamlXARM because it runs on a Mac, and cross-compiles for ARM-based iOS devices. It requires Apple’s Xcode, which contains the necessary cross-compilation toolchain and the Cocoa Touch libraries. Right now my test version builds for armv7/Thumb, which means the generated apps only run on moderately recent iOS devices (including all iPads). I don’t foresee any problem creating a version of OCamlXARM for armv6/ARM, which will support all the historical iOS devices. It should also be possible to generate code for armv7/ARM. It should just be a matter of working through the details.

If you’re interested in trying a prerelease, send me an email. I recommend this for the adventurous only. The less adventurous can try version 1.0.15 of OCamlXARM, which is based on OCaml 3.10.2 (admittedly, a rather old OCaml release).

The newly revamped ARM code generation in OCaml 4 is the work of Benedikt Meurer of the University of Siegen. My modifications just add support for iOS, while leaving the existing Linux support in place. For any brothers and sisters working at low levels, here are the changes I’ve made so far.

The runtime assembly language file arm.S needs to be translated into proper form for the Apple assembler. Rather than doing this by hand, I wrote a Python script named arm-as-to-ios that does the translation. In fact, its output works both with Linux and Apple assemblers. For those interested, I’ve written a blog post about arm-as-to-ios.
Make the same modifications to the code emitted by the OCaml compiler itself. The native code OCaml compiler works by emitting assembly code and then passing it to an external assembler.
Revamp code emitted for jump tables. The Apple assembler disagrees about the meaning of the jump table code emitted by the stock compiler, and the resulting code crashes. The new emitted code is intended to work for both Linux and Apple assemblers.
Add support for Apple’s slightly different linkage to C. In essence, floating values are passed and returned in pairs of integer registers rather than in floating registers.

I’ll test more thoroughly, then I’ll release the OCamlXARM patches and binary. The new version will be OCamlXARM 3.1. I’m looking forward to trying out the new OCaml language features, and maybe doing some timing tests to see if armv7/Thumb code is faster than the armv6/ARM code generated by the previous OCamlXARM release.

If you have comments or questions, please leave them below, or email me at jeffsco@psellos.com.

Posted by: Jeffrey

Convert ARM Assembly Code for Apple’s iOS Assembler (Update 1)

2012-07-19T11:00:00-08:00

July 19, 2012

I’m making reasonable progress in getting OCaml 4.00.0 working on iOS. Just now I was able to build the entire system in a hybrid form, where the compiler is built for the host (OS X i386) and the standard library is built for the target (iOS ARM). This is already pretty close to what you want for a cross compiler. I’m hoping to be able to test some generated code on an iOS device soon. At the same time, OCaml 4.00.0 has reached the release candidate stage, so things are really starting to cook.

While building the libraries for ARM, I learned more about the incompatibilities between the GNU ARM assembler (for the supported Linux targets of OCaml) and Apple’s ARM assembler for iOS. This led me to revamp my Python script that converts ARM assembly code from the current GNU format to the required Apple format. I also decided I should make the conversion upward compatible; in other words, the converted assembly file should continue to work in its originally supported Linux environments as well as in iOS.

Note: I wrote a new, improved version of this script, described in Convert Linux ARM Assembly Code for iOS (Update 3).

The advantage of using a script is that it keeps the changes consistent, and it will still be useful if arm.S is rewritten in the future. The script, named arm-as-to-ios, now does the following:

Declare the architecture for iOS. The possibilities are armv6 and armv7. Currently I’m concentrating on getting armv7 to work, but the generated file also assembles successfully for armv6.
Specify that armv7 code should use the more space-efficient Thumb encoding in iOS.
Generate declarations for functions, similar to the .type pseudo-op for the Linux targets. It appears that Apple requires .thumb_func declarations only for Thumb functions. Other symbols are apparently assumed to be ARM functions. To make this work upward-compatibly, I define an assembly macro named .funtype that is expanded properly in the different environments.
Make sure that assembler-local symbols have the right format. For GNU assemblers, they look like “.Lxxx”. For the Apple assembler, they look like “Lxxx”. To support upward compatibly, this is handled by a cpp macro named Loc() that generates the proper symbol form for each environment.
Replace uses of =value notation by explicit loads from memory. The usual ARM assemblers interpret ldr rM, =value to mean that the value should be loaded into register M immediately (using mov) if possible, and loaded from memory (using ldr with PC-relative addressing) otherwise. The Apple assembler seems not to support this. arm-as-to-ios replaces uses of =value with explicit memory loads, emitting the pool of values into the .text segment at the end of the file.
Remove uses of two pseudo-ops, .type and .size, when assembling for iOS. They aren’t supported by Apple’s assembler. This is done by defining null macros for them.
Define a macro cbz when using ARM encodings for iOS. The cbz instruction is Thumb-only. The definition replaces it with a pair of ARM instructions.

Another advantage of using a script is that it might be useful to other people who need to port ARM assembly code to iOS. Granted, there probably aren’t a lot of people doing this. But if you are, maybe the script will provide a useful starting point.

You can download the script here:

arm-as-to-ios—modify ARM assembly code for use on iOS

The full text of the script is also included at the end of this post.

As I expected, I’ve already updated the script based on what I’ve learned while doing the OCaml 4-on-iOS project. As I make changes, I’ll keep the linked script up to date. If there are more large changes I’ll make another post about them.

If you want to try out arm-as-to-ios, copy and paste the lines from the end of this post into a file named arm-as-to-ios, or download it from the above link. Mark it as a script with chmod:

$ chmod +x arm-as-to-ios

To use the script, specify the name of an ARM assembly file. If no files are given, the script processes its standard input.

The following small example demonstrates the translations that arm-as-to-ios performs. Here is a small file of Linux (non-Apple) ARM assembly language:

        .syntax unified
        .text
        .align  2
        .globl  example
        .type example, %function
example:
        sub     r10, r10, 8
        cmp     r10, r11
        bcc     1f
        bx      lr
1:
        ldr     r7, =last_return_address
        str     lr, [r7]
        bl      .Lcall_gc
        ldr     lr, [r7]
        b       example

.Lcall_gc:
        ldr     r12, =bottom_of_stack
        str     sp, [r12]
        bl      garbage_collection
        bx      lr

If you run arm-as-to-ios on this file, you get the following output that works for all assemblers (Linux and Apple):

        .syntax unified

/* Apple compatibility macros */
#if defined(SYS_macosx)
#define Loc(s) L##s
#if defined(MODEL_armv6)
        .machine  armv6
        .macro  .funtype
        .endm
        .macro  cbz
        cmp     $0, #0
        beq     $1
        .endm
#else
        .machine  armv7
        .thumb
        .macro  .funtype
        .thumb_func $0
        .endm
#endif
        .macro  .type
        .endm
        .macro  .size
        .endm
#else
#define Loc(s) .L##s
        .macro  .funtype symbol
        .type  \symbol, %function
        .endm
#endif
        .text
        .align  2
        .globl  example
        .funtype  example
example:
        sub     r10, r10, 8
        cmp     r10, r11
        bcc     1f
        bx      lr
1:
        ldr     r7, Loc(Plast_return_address)
        str     lr, [r7]
        bl      Loc(call_gc)
        ldr     lr, [r7]
        b       example

Loc(call_gc):
        ldr     r12, Loc(Pbottom_of_stack)
        str     sp, [r12]
        bl      garbage_collection
        bx      lr

/* Pool of addresses loaded into registers */

        .text
        .align 2
Loc(Plast_return_address):
        .long last_return_address
Loc(Pbottom_of_stack):
        .long bottom_of_stack

The output consists of a fixed prefix followed by the translation of the input file, followed by the pool of values to be loaded into registers.

The following shows a successful assembly of arm.S from OCaml 4.00.0:

$ PLT=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform
$ PLTBIN=$PLT/Developer/usr/bin
$ arm-as-to-ios asmrun/arm.S &gt; armios.S
$ $PLTBIN/gcc -c -arch armv7 -DSYS_macosx -DMODEL_armv7 -o armios.o armios.S
$ file armios.o
armios.o: Mach-O object arm
$ otool -tv armios.o | head
armios.o:
(__TEXT,__text) section
caml_call_gc:
00000000        f8dfc1e0        ldr.w   ip, [pc, #480]  @ 0x1e4
00000004        f8cce000        str.w   lr, [ip]
00000008        f8dfc1dc        ldr.w   ip, [pc, #476]  @ 0x1e8
0000000c        f8ccd000        str.w   sp, [ip]
00000010        ed2d0b10        vstmdb  sp!, {d0-d7}
00000014        e92d50ff        stmdb   sp!, {r0, r1, r2, r3, r4, r5, r6, r7, ip, lr}
00000018        f8dfc1d0        ldr.w   ip, [pc, #464]  @ 0x1ec

If you have any corrections, improvements, or other comments, leave them below or email me at jeffsco@psellos.com. I’d be very pleased to hear if the script has been helpful to anyone.

Posted by: Jeffrey

Appendix

Here is the current text of the script:

#!/usr/bin/env python
#
# arm-as-to-ios     Modify ARM assembly code for the iOS assembler
#
# Copyright (c) 2012 Psellos   http://psellos.com/
# Licensed under the MIT License:
#     http://www.opensource.org/licenses/mit-license.php
#
# Resources for running OCaml on iOS: http://psellos.com/ocaml/
#
import sys
import re

VERSION = '1.1.0'


def add_prefix(instrs):
    # Add compatibility macros for all systems, plus hardware
    # definitions and compatibility macros for iOS.
    #
    # All systems:
    #
    # Loc()     cpp macro for making local symbols (.Lxxx vs Lxxx)
    # .funtype  Expands to .thumb_func for iOS armv7 (null for armv6)
    #           Expands to .type %function for others
    #
    # iOS:
    #
    # .machine  armv6/armv7
    # .thumb    (for armv7)
    # cbz       Expands to cmp/beq for armv6 (Thumb-only instr)
    # .type     Not supported by Apple assembler
    # .size     Not supported by Apple assembler
    #
    defre = '#[ \t]*if.*def.*SYS'  # Add new defs near first existing ones
    skipre = '$|\.syntax[ \t]'     # Skip comments lines (and .syntax)

    for i in range(len(instrs)):
        if re.match(defre, instrs[i][1]):
            break
    else:
        i = 0
    for i in range(i, len(instrs)):
        if not re.match(skipre, instrs[i][1]):
            break
    instrs[i:0] = [
        ('', '', '\n'),
        ('/* Apple compatibility macros */', '', '\n'),
        ('', '#if defined(SYS_macosx)', '\n'),
        ('', '#define Loc(s) L##s', '\n'),
        ('', '#if defined(MODEL_armv6)', '\n'),
        ('        ', '.machine  armv6', '\n'),
        ('        ', '.macro  .funtype', '\n'),
        ('        ', '.endm', '\n'),
        ('        ', '.macro  cbz', '\n'),
        ('        ', 'cmp     $0, #0', '\n'),
        ('        ', 'beq     $1', '\n'),
        ('        ', '.endm', '\n'),
        ('', '#else', '\n'),
        ('        ', '.machine  armv7', '\n'),
        ('        ', '.thumb', '\n'),
        ('        ', '.macro  .funtype', '\n'),
        ('        ', '.thumb_func $0', '\n'),
        ('        ', '.endm', '\n'),
        ('', '#endif', '\n'),
        ('        ', '.macro  .type', '\n'),
        ('        ', '.endm', '\n'),
        ('        ', '.macro  .size', '\n'),
        ('        ', '.endm', '\n'),
        ('', '#else', '\n'),
        ('', '#define Loc(s) .L##s', '\n'),
        ('        ', '.macro  .funtype symbol', '\n'),
        ('        ', '.type  \\symbol, %function', '\n'),
        ('        ', '.endm', '\n'),
        ('', '#endif', '\n')
    ]
    return instrs


# Prefix for pooled symbols.  It's in the space of local symbols for the
# input file.  Later rules will modify this to the Loc() form.
#
g_prefix = '.LP'

# Regular expression for modified ldr lines
#
g_ldre = '(ldr[ \t][^,]*,[ \t]*)=(([^ \t\n@,/]|/(?!\*))*)(.*)'


def explicit_address_loads(instrs):
    # The Gnu assembler allows the following:
    #
    #     ldr rM, =symbol
    #
    # which loads rM with [mov] (immediately) if possible, or creates an
    # entry in memory for the symbol value and loads it PC-relatively
    # with [ldr].
    #
    # The Apple assembler doesn't seem to support this notation.  If the
    # value is a suitable constant, it emits a valid [mov].  Otherwise
    # it seems to emit an invalid [ldr] that always generates an error.
    # (At least I have not been able to make it work).  So, change uses
    # of =symbol to explicit PC-relative loads.
    #
    # This requires a pool containing the addresses to be loaded.  For
    # now, we just keep track of it ourselves and emit it into the text
    # segment at the end of the file.
    #
    syms = {}
    result = []

    def repl1((syms, result), (a, b, c)):
        global g_prefix
        global g_ldre
        mo = re.match(g_ldre, b, re.DOTALL)
        if mo:
            if mo.group(2) not in syms:
                syms[mo.group(2)] = len(syms)
            psym = mo.group(2)
            if psym[0:2] == '.L':
                psym = psym[2:]
            newb = mo.group(1) + g_prefix + psym + mo.group(4)
            result.append((a, newb, c))
        else:
            result.append((a, b, c))
        return (syms, result)

    def pool1(result, s):
        global g_prefix
        psym = s
        if psym[0:2] == '.L':
            psym = psym[2:]
        result.append(('', g_prefix + psym + ':', '\n'))
        result.append(('        ', '.long ' + s, '\n'))
        return result

    reduce(repl1, instrs, (syms, result))
    if len(syms) &gt; 0:
        result.append(('', '', '\n'))
        result.append(('/* Pool of addresses loaded into registers */',
                        '', '\n'))
        result.append(('', '', '\n'))
        result.append(('        ', '.text', '\n'))
        result.append(('        ', '.align 2', '\n'))
        reduce(pool1, sorted(syms, key=syms.get), result)
    return result


def local_symbols(instrs):
    # The form of a local symbol differs between Gnu assemblers and the
    # Apple assember:
    #
    # Gnu:   .Lxxx
    # Apple: Lxxx
    #
    # Change occurrences of local symbols to use the Loc() cpp macro
    # defined in our prefix.
    #
    lsyms = set()
    result = []

    def find1 (lsyms, (a, b, c)):
        mo = re.match('(\.L[^ \t:]*)[ \t]*:', b)
        if mo:
            lsyms.add(mo.group(1))
        return lsyms

    def repl1((lsyms, result), (a, b, c)):
        matches = list(re.finditer('\.L[^ \t@:,+*/-]+', b))
        if matches != []:
            matches.reverse()
            newb = b
            for mo in matches:
                if mo.group() in lsyms:
                    newb = newb[0:mo.start()] + \
                            'Loc(' + mo.group()[2:] + ')' + \
                            newb[mo.end():]
            result.append((a, newb, c))
        else:
            result.append((a, b, c))
        return (lsyms, result)

    reduce(find1, instrs, lsyms)
    reduce(repl1, instrs, (lsyms, result))
    return result


def funtypes(instrs):
    # Gnu assemblers accept declarations like this:
    #
    #     .type  symbol, %function
    #
    # For Thumb functions, the Apple assembler wants to see:
    #
    #     .thumb_func symbol
    #
    # Handle this by converting declarations to this:
    #
    #     .funtype symbol
    #
    # Our prefix defines an appropriate .funtype macro for each
    # environment.
    #
    result = []

    def repl1(result, (a, b, c)):
        mo = re.match('.type[ \t]+([^ \t,]*),[ \t]*%function', b)
        if mo:
            result.append((a, '.funtype  ' + mo.group(1), c))
        else:
            result.append((a, b, c))
        return result

    reduce(repl1, instrs, result)
    return result


def read_input():
    # Concatenate all the input files into a string.
    #
    def fnl(s):
        if s == '' or s[-1] == '\n':
            return s
        else:
            return s + '\n'

    if len(sys.argv) &lt; 2:
        return fnl(sys.stdin.read())
    else:
        input = ""
        for f in sys.argv[1:]:
            try:
                fd = open(f)
                input = input + fnl(fd.read())
                fd.close()
            except:
                sys.stderr.write('arm-as-to-ios: cannot open ' + f + '\n')
        return input


def parse_instrs(s):
    # Parse the string into assembly instructions, also noting C
    # preprocessor lines.  Each instruction is represented as a triple:
    # (space/comments, instruction, end).  The end is either ';' or
    # '\n'.  Instructions might have embedded comments, but they
    # probably won't get fixed up if they do.  (I've never seen it in
    # real code.)
    #
    def goodmo(mo):
        if mo == None:
            # Should never happen
            sys.stderr.write('arm-as-to-ios: internal parsing error\n')
            sys.exit(1)

    cpp_re = '([ \t]*)(#([^\n]*\\\\\n)*[^\n]*[^\\\\\n])\n'
    comment_re = '[ \t]*#[^\n]*'
    instr_re = (
        '(([ \t]|/\*.*?\*/|@[^\n]*)*)'  # Spaces &amp; comments
        '(([ \t]|/\*.*?\*/|[^;\n])*)'   # "Instruction"
        '([;\n])'                       # End
    )
    instrs = []
    while s != '':
        if re.match('[ \t]*#[ \t]*(if|ifdef|elif|else|endif|define)', s):
            mo = re.match(cpp_re, s)
            goodmo(mo)
            instrs.append((mo.group(1), mo.group(2), '\n'))
        elif re.match('[ \t]*#', s):
            mo = re.match(comment_re, s)
            goodmo(mo)
            instrs.append((mo.group(0), '', '\n'))
        else:
            mo = re.match(instr_re, s, re.DOTALL)
            goodmo(mo)
            instrs.append((mo.group(1), mo.group(3), mo.group(5)))
        s = s[len(mo.group(0)):]
    return instrs


def main():
    instrs = parse_instrs(read_input())
    instrs = explicit_address_loads(instrs)
    instrs = funtypes(instrs)
    instrs = local_symbols(instrs)
    instrs = add_prefix(instrs)
    for (a, b, c) in instrs:
        sys.stdout.write(a + b + c)
#        sys.stdout.write('{' + a + '}' + '{' + b + '}' + c)


main()

Convert ARM Assembly Code for Apple’s iOS Assembler

2012-07-10T11:00:00-08:00

July 10, 2012

Recently I’ve been working on getting OCaml 4.00.0 working on iOS. As I write this, 4.00.0 is the newest version of OCaml, not yet released but available as a beta. I’m treating it as a new project, not trying to re-use any of the patches we’ve been using for OCaml 3.10.2.

The first interesting problem I hit is that Apple’s ARM assembler for iOS (called “as”, the traditional Unix name) is quite different from other ARM assemblers. Although it derives ultimately from the same GNU codebase, it appears the Apple assembler split off many years ago and has followed a separate evolutionary path.

This needs to be solved for an OCaml-on-iOS port, because part of the OCaml runtime is written in assembly code—a file named arm.S. For the work on OCaml 3.10.2, we rewrote arm.S extensively by hand. This time, I decided to write a Python script to convert ARM assembly code from the current GNU format to the format used by Apple’s iOS assembler. This keeps the changes consistent, and it ought to help when arm.S is rewritten in the future.

Note: I wrote a new, improved version of this script, described in Convert Linux ARM Assembly Code for iOS (Update 3).

So now I have a script named arm-as-to-ios that works well enough to convert arm.S to a form that can be assembled for iOS. It’s nothing fancy; currently it just makes the following changes:

Replace uses of =value notation by explicit loads from memory. The usual ARM assemblers interpret ldr rM, =value to mean that the value should be loaded into register M immediately (using mov) if possible, and loaded from memory (using ldr with PC-relative addressing) otherwise. The Apple assembler seems not to support this. arm-as-to-ios replaces uses of =value with explicit memory loads, emitting the pool of values into the .text segment at the end of the file.
Remove uses of two pseudo-ops, .type and .size. They aren’t supported by Apple’s assembler. This is done by defining null macros for them.
Define a macro cbz. The cbz instruction is Thumb-only. This defininition replaces it with a pair of ARM instructions. Note that the macro parameter syntax of Apple’s assembler is different (possibly just more restrictive) than the usual GNU tools.

Another advantage of using a script is that it might be useful to other people who need to port assembly code to iOS. Granted, there probably aren’t a lot of people doing this. But if you are, maybe the script will provide a useful starting point.

You can download the script here:

arm-as-to-ios—modify ARM assembly code for use on iOS

I have no doubt that I’ll need to update the script as the project progresses. I’ll keep the linked script up to date. If there are large changes I’ll make another post about them.

Here, also, is the current text of the script:

#!/usr/bin/env python
#
# arm-as-to-ios     Modify ARM assembly code for the iOS assembler
#
# Copyright (c) 2012 Psellos   http://psellos.com/
# Licensed under the MIT License:
#     http://www.opensource.org/licenses/mit-license.php
#
# Resources for running OCaml on iOS: http://psellos.com/ocaml/
#
import sys
import re

VERSION = '1.0.0'


def add_macro_defs(instrs):
    # Emit compatibility macros.
    #
    # cbz:    Thumb only; replace with cmp/beq for ARM
    # .type:  Not supported by Apple assembler
    # .size:  Not supported by Apple assembler
    #
    skippable = '$|\.syntax[ \t]'
    i = 0
    for i in range(len(instrs)):
        if not re.match(skippable, instrs[i][1]):
            break
    instrs[i:0] = [
        ('', '', '\n'),
        ('/* Apple compatibility macros */', '', '\n'),
        ('        ', '.macro  cbz', '\n'),
        ('        ', 'cmp     $0, #0', '\n'),
        ('        ', 'beq     $1', '\n'),
        ('        ', '.endm', '\n'),
        ('        ', '.macro  .type', '\n'),
        ('        ', '.endm', '\n'),
        ('        ', '.macro  .size', '\n'),
        ('        ', '.endm', '\n'),
        ('', '', '\n')
    ]
    return instrs


# Prefix for derived symbols
#
g_prefix = 'PL'

# Regular expression for modified ldr lines
#
g_ldre = '(ldr[ \t][^,]*,[ \t]*)=(([^ \t\n@,/]|/(?!\*))*)(.*)'


def explicit_address_loads(instrs):
    # The Gnu assembler allows the following:
    #
    #     ldr rM, =symbol
    #
    # which loads rM with [mov] (immediately) if possible, or creates an
    # entry in memory for the symbol value and loads it PC-relatively
    # with [ldr].
    #
    # The Apple assembler doesn't seem to support this notation.  If the
    # value is a suitable constant, it emits a valid [mov].  Otherwise
    # it seems to emit an invalid [ldr] that always generates an error.
    # (At least I have not been able to make it work).  So, change uses
    # of =symbol to explicit PC-relative loads.
    #
    # This requires a pool containing the addresses to be loaded.  For
    # now, we just keep track of it ourselves and emit it into the text
    # segment at the end of the file.
    syms = {}
    result = []

    def change1((syms, result), (a, b, c)):
        global g_prefix
        global g_ldre
        mo = re.match(g_ldre, b, re.DOTALL)
        if mo:
            if mo.group(2) not in syms:
                syms[mo.group(2)] = len(syms)
            newb = (mo.group(1) + g_prefix + mo.group(2) + mo.group(4))
            result.append((a, newb, c))
        else:
            result.append((a, b, c))
        return (syms, result)

    def pool1(result, s):
        global g_prefix
        result.append(('', g_prefix + s + ':', '\n'))
        result.append(('        ', '.long ' + s, '\n'))
        return result

    reduce(change1, instrs, (syms, result))
    if len(syms) &gt; 0:
        result.append(('', '', '\n'))
        result.append(('/* Pool of addresses loaded into registers */',
                        '', '\n'))
        result.append(('', '', '\n'))
        result.append(('        ', '.text', '\n'))
        result.append(('        ', '.align 2', '\n'))
        reduce(pool1, sorted(syms, key=syms.get), result)
    return result


def read_input():
    # Concatenate all the input files into a string.
    #
    def fnl(s):
        if s == '' or s[-1] == '\n':
            return s
        else:
            return s + '\n'

    if len(sys.argv) &lt; 2:
        return fnl(sys.stdin.read())
    else:
        input = ""
        for f in sys.argv[1:]:
            try:
                fd = open(f)
                input = input + fnl(fd.read())
                fd.close()
            except:
                sys.stderr.write('arm-as-to-ios: cannot open ' + f + '\n')
        return input


def parse_instrs(s):
    # Parse the string into assembly instructions while tolerating C
    # preprocessor lines.  Each instruction is represented as a triple:
    # (space/comments, instruction, end).  The end is either ';' or
    # '\n'.  Instructions can have embedded comments, but they won't get
    # fixed up if they do.  (I've never seen it in real code.)
    #
    def goodmo(mo):
        if mo == None:
            # Should never happen
            sys.stderr.write('arm-as-to-ios: internal parsing error\n')
            sys.exit(1)

    cpp_re = '([ \t]*#([^\n]*\\\\\n)*[^\n]*[^\\\\\n])\n'
    instr_re = (
        '(([ \t]|/\*.*?\*/|@[^\n]*)*)'  # Spaces &amp; comments
        '(([ \t]|/\*.*?\*/|[^;\n])*)'   # "Instruction"
        '([;\n])'                       # End
    )
    instrs = []
    while s != '':
        if re.match('[ \t]*#', s):
            mo = re.match(cpp_re, s)
            goodmo(mo)
            instrs.append((mo.group(1), '', '\n'))
        else:
            mo = re.match(instr_re, s, re.DOTALL)
            goodmo(mo)
            instrs.append((mo.group(1), mo.group(3), mo.group(5)))
        s = s[len(mo.group(0)):]
    return instrs


def main():
    instrs = parse_instrs(read_input())
    instrs = add_macro_defs(instrs)
    instrs = explicit_address_loads(instrs)
    for (a, b, c) in instrs:
        sys.stdout.write(a + b + c)


main()

Copy and paste the lines into a file named arm-as-to-ios (or download it from the above link). Mark it as a script with chmod:

$ chmod +x arm-as-to-ios

To use the script, specify the name of an ARM assembly file. If no files are given, the script processes its standard input. The following shows a successful assembly of arm.S:

$ PLT=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform
$ PLTBIN=$PLT/Developer/usr/bin
$ arm-as-to-ios asmrun/arm.S | cpp &gt; armios.S
$ $PLTBIN/as -arch armv6 -o armios.o armios.S
$ file armios.o
armios.o: Mach-O object arm
$ otool -tv armios.o | head
armios.o:
(__TEXT,__text) section
caml_call_gc:
00000000        e59fc2a0        ldr     ip, [pc, #672]  @ 0x2a8
00000004        e58ce000        str     lr, [ip]
.Lcaml_call_gc:
00000008        e59fc29c        ldr     ip, [pc, #668]  @ 0x2ac
0000000c        e58cd000        str     sp, [ip]
00000010        ed2d0b10        vstmdb  sp!, {d0-d7}
00000014        e92d50ff        push    {r0, r1, r2, r3, r4, r5, r6, r7, ip, lr}

If you have any corrections, improvements, or other comments, leave them below or email me at jeffsco@psellos.com. I’d be very pleased to hear if the script has been helpful to anyone.

Posted by: Jeffrey

Install OCaml on Amazon Linux (EC2)

2012-06-19T11:00:00-08:00

June 19, 2012

Edited September 2, 2012

Here is a quick way to get OCaml installed on an Amazon EC2 instance running Amazon Linux. The problem is that you’d like to use yum, the handy package management tool. But none of the stock repositories in Amazon Linux contains an OCaml package.

Since Amazon Linux is compatible with CentOS 6, what I ended up doing was installing the OCaml package from CentOS 6.2. This gives you OCaml 3.11.2, which is perfectly fine for our current purposes. We’ve run a few tests, and it is working for us.

Note: if you’re not committed to using Amazon Linux, another way to get OCaml support is to use the Ubuntu images instead. I’ve run some tests with the 32-bit version of Ubuntu Server 12.04 LTS, and the OCaml support seems excellent. The repository contains OCaml 3.12.1, which is the latest release (currently).

For those who want to use OCaml on Amazon Linux, here are the steps I used to install it. I assume you’ve got an active EC2 instance running Amazon Linux.

First, add the CentOS 6.2 repository to your yum configuration. As root, create a file named /etc/yum.repos.d/centos6.repo with the following contents. The mirrorlist and gpgkey lines here might be wrapped in your browser, but each is one long line (make your browser as wide as possible to see this).

[centos6]
name=Centos 6 Base
mirrorlist=http://mirrorlist.centos.org/?release=6.2&arch=$basearch&repo=os
gpgcheck=1
gpgkey=http://mirror.centos.org/centos-6/6/os/$basearch/RPM-GPG-KEY-CentOS-6
priority=2
enabled=1

(Added note: based on a comment, I changed the gpgkey URL above. The old URL had become inaccessible since I originally wrote this up. To check the validity, you can try visiting the URL to make sure it exists. Replace $basearch with i386 or x86_64 as appropriate.)

To avoid overriding the stock packages you want to set the priority lower than the other repositories (i.e., set it to a bigger integer). All my other repositories are priority 1, so 2 is big enough.

The use of the basearch variable means that things will work for both 32- and 64-bit EC2 instances. The lines below are taken from a 32-bit instance (but I have tested on both).

Yum should now see the CentOS OCaml package:

# yum list ocaml
Loaded plugins: fastestmirror, priorities, security, update-motd
Loading mirror speeds from cached hostfile
* amzn-main: packages.us-west-2.amazonaws.com
* amzn-updates: packages.us-west-2.amazonaws.com
* centos6: mirrors.cat.pdx.edu
2125 packages excluded due to repository priority protections
Available Packages
ocaml.i686                   3.11.2-2.el6                   centos6

You can now install OCaml:

# yum install ocaml
    . . .
# ocaml
        Objective Caml version 3.11.2
 
#

When you’re done, you might want to change enable=1 to enable=0 in your centos6.repo file, to avoid placing unnecessary load on the CentOS mirrors in the future.

Please leave any corrections, questions, or comments below, or send them to me at jeffsco@psellos.com.

Posted by: Jeffrey

IcosaBlue 2.0, Now with Weekend Teapot!

2012-06-11T11:00:00-08:00

June 11, 2012

I’ve rewritten IcosaBlue, an example OCaml app that shows how to use OpenGL ES 1.1 under iOS. It works under OS X 10.7 (Lion) and still displays a rotating blue icosahedron.

However, to keep the excitement at a high level, I added a new feature to IcosaBlue for version 2.0. On weekdays, it still displays the traditional rotating blue icosahedron, but on weekends it displays a rotating blue teapot (shown in screenshot).

I’m now thinking about new features to add in future releases. I’d still be interested in coding up some kind of competition for supremacy among different polyhedra. But the new teapot display suggests that some other household objects might be able to compete as well.

As usual, the old version of IcosaBlue is available in the OCaml Programming Archives.

Please leave any questions or comments below, or send them to me at jeffsco@psellos.com.

Posted by: Jeffrey

LablGLES Released for Lion

2012-06-04T11:00:00-08:00

June 4, 2012

I’ve just updated LablGLES, an OCaml interface for OpenGL ES 1.1. I use it to write iOS apps in OCaml, but it should work in almost any OCaml environment with OpenGL ES. I’ve rewritten the instructions to work with OS X 10.7 (Lion) and the latest Xcode (4.3.2).

I also coded up a simple consistency checker that found quite a few dangling LablGL symbols in LablGLES. These are symbols that are defined in OpenGL but not in OpenGL ES. Eliminating them will allow the OCaml compiler to catch errors in LablGLES code that were previously being caught at runtime.

LablGLES is based on LablGL, by Jacques Garrigue and others. As an interesting sidelight, I just now ran my consistency checker against the base LablGL release and it seems to have found an error! Another small victory for static analysis.

As usual, the old version of LablGLES will remain available in the OCaml Programming Archives.

Please leave any questions or comments below, or send them to me at jeffsco@psellos.com.

Posted by: Jeffrey

OCaml iOS Simulator App “Voronoi” Updated for Lion

2012-05-29T11:00:00-08:00

May 29, 2012

I updated the OCaml iOS Simulator example app, Voronoi, to build and run under Lion with the latest Xcode. It lets you draw fantastic-looking Voronoi diagrams by placing dots on the screen. It also shows how to run OCaml on iOS, with no need for an iOS device. There’s a binary version that you can run in the simulator just by clicking on it. Or you can download sources and build it yourself.

The accompanying Voronoi screenshot shows what it looks like—but imagine that you can move the dots or add new ones while the shapes and colors adjust hypnotically.

Whenever I run this app I get excited by what I can come up with in just a few minutes, and end up making a big gallery of screenshots. There are a few more in the writeup, but I have many more if anybody is interested. Or you could make your own screenshots and send them to me.

The update makes no changes to the OCaml and ObjC code—Voronoi only uses parts of iOS that haven’t changed since iOS 3.1. However, I built a launcher app that lets you run Voronoi in the iOS Simulator with just a few clicks (no command line). I also repackaged the sources so you can build and run in the simulator under Xcode with just a few clicks.

An advantage of using Xcode is that it’s the supported way of running apps in the simulator. For those who actually like to work from the command line (as I often do) the instructions also show how to build and run the app that way.

As always, the previous version of Voronoi is still available in the OCaml Programming Archives.

Posted by: Jeffrey

OCaml iOS App “Slide24” Updated for Lion

2012-05-26T11:00:00-08:00

May 26, 2012

I updated the OCaml iOS example app, Slide24, to build under Lion with the latest Xcode. It lets you solve the well known 5 × 5 sliding tile puzzle. It will also solve it for you if you like, using a tiny bit of AI. If you’re interested in running OCaml on iOS, this app shows how to interface with GUI elements of Cocoa Touch. You can download the sources and build it to run on your own iOS device.

There are no changes to the OCaml and ObjC code—all the updates are in the instructions and in the project metadata used by Xcode. The generated app runs on iOS 3.1 and later.

There seems to be a fairly steady stream of interest in this app, maybe because it’s a classic problem for testing heuristic searches. In fact an expert in the field offered to help me make my heuristic work better. (I think he could tell I don’t know anything about heuristic searching, beyond what I read in Wikipedia while coding up the app.) I’d be really happy to improve the heuristic someday, and I’ll also happily accept patches from anybody who has already done so.

As always, the previous version of Slide24 is still available in the OCaml Programming Archives.

Posted by: Jeffrey

Wrap an iOS Simulator App as a Mac App

2012-05-25T11:00:00-08:00

May 25, 2012

This note shows how to whip up a full-fledged Mac app that just launches an app in the iOS Simulator under Lion. It’s based on Platypus, a free program that wraps up any script as a Mac app. The wrapped script is essentially runsim, which runs an iOS Simulator app. See Run iOS Simulator from the Command Line (Improved) for the full description of runsim.

Until Apple releases the iOS Simulator as a standard part of OS X (which would open up all kinds of interesting possibilities for cross-device apps), the target audience for the generated apps is fairly small. Only an iOS developer is going to have the iOS Simulator readily available on their system. But, in fact, I often release iOS demo apps for other developers to look at, and anyway I think it’s pretty cool how easy it is to do this with Platypus.

One problem with running iOS Simulator apps automatically is that the location of the simulator isn’t the same on every system. The simulator is part of Xcode, which (under Lion) is an ordinary application that can be located anywhere you like.

To handle this, I use drag-and-drop: if you drop your Xcode.app onto the launcher app, it remembers the location for later. When you open the launcher app (double-click on it in the Finder), it uses the remembered location of Xcode to find the simulator. (The iOS Simulator app is literally located inside the Xcode app.)

So, the script to be wrapped by Platypus looks like this:

case $# in
0)
    ./runsim Psi ;;
*)
    case "$(basename "$1" | tr '[:upper:]' '[:lower:]')" in
    xcode.app) echo "$1" &gt; runsim.xcloc ;;
    esac
    ;;
esac

When the wrapped script runs, it can tell whether it was a drag-and-drop target or not by the number of arguments. If there is no argument, nothing was dropped. The script just uses runsim to launch the desired simulator app. (In this example, it launches Psi, a tiny example iOS app.) If there is an argument, something was dropped. If it’s named Xcode.app, the script remembers its location for later.

I call this script clicksim. As given here, it needs to change a little bit depending on the iOS Simulator app you want to wrap up: you need to specify the name of your app after runsim.

That’s really all there is to it. Platypus handles the details of wrapping clicksim, runsim, the app executable, and any other associated files into a Mac app.

The figure above shows how to configure Platypus to wrap clicksim and runsim. The bundled files are as follows:

Psi—the app executable
Icon.png—icon for the app in the simulator
runsim—the runsim script
runsim.uuid—UUID for the app
runsim.xcloc—location of Xcode

You can generate a UUID using the uuidgen utility. A good initial value for the location of Xcode is /Applications/Xcode.app. The runsim.xcloc file should be writable so that the script can change its contents if necessary.

To make the drag-and-drop facility work more nicely, you can specify the files that will be accepted by the app. Click the Settings button, and you’ll see a new dialog like this:

In this example, we want to accept only files ending with .app (applications), and only folders (packages).

If you want to try this example yourself, I created an archive with all the parts you need. First, download Platypus from its home page, and install it. Then download the archive:

Archive for wrapping Psi as Mac app with Platypus

To try out the example from Finder:

Double click the zipfile, then open the generated folder.
Double click on FillProfile.app. This initializes paths in psilauncher.platypus for your site.
Double click on psilauncher.platypus. This brings up the Platypus main window, as shown above.
Click Create to create the app. Choose a convenient location for the generated app.
Double-click on the PsiLauncher.app generated in step 4. This will start Psi in the iOS Simulator. It will be on the second page of apps—swipe to the left to see it.
If Psi doesn’t show up, you may need to set the simulated iOS version. runsim puts apps into the iOS 5.1 simulator. Set the version number to 5.1 with the Hardware -> Version menu.

To try out the example from the command line:

$ unzip psi-platy-1.0.1.zip
$ cd psi-platy-1.0.1
$ fillprofile
$ platypus -P psilauncher.platypus PsiLauncher.app

To run PsiLauncher.app, you can double-click on it, or you can run it from the command line:

$ open PsiLauncher.app

As above, you may need to set the simulated iOS version to 5.1 for Psi to show up.

If you have any comments, corrections, or suggestions, leave them below or email me at jeffsco@psellos.com.

Posted by: Jeffrey

Tiny iOS App in One Source File

2012-05-22T11:00:00-08:00

May 22, 2012

Psi is a tiny, but complete, iOS test app in one source file, around 40 lines of Objective C. It’s nothing fancy, it just draws a Greek psi character on the screen. But I thought it might be useful to other folks. Sometimes it’s just nice to have a little example.

Psi can be very simple because it’s targeted at iOS 5, when Apple generalized the startup process to add storyboard support. A side effect is that it’s now possible to have no startup file (nib or storyboard file) at all. Psi shows how this can work. You can find a more detailed description of the iOS app launch sequence in a blog post by Ole Begemann, which is where I got the idea.

You can download the binary of Psi and run it directly in the iOS Simulator:

Psi Tiny iOS App Binary for iOS Simulator

To try out this version, unzip and double click on the launcher app PsiLauncher.app. You need to have Xcode and the iOS 5.0 Simulator installed for this to work. Psi appears on the second screen of apps—swipe to the left to see it. If it’s not there, you might need to change the version number to 5.1 in the Hardware -> Version menu.

Psi is so exceptionally simple that it’s really not very interesting to run—the figure above shows everything there is to see. However, it might be interesting to see how I packaged up an OS X app to run Psi in the simulator.

You can also download the sources and an Xcode project for building and running in the iOS Simulator or on an iOS device:

Psi Tiny iOS App Sources and Xcode project

To try out this version, unzip and double click on the Xcode project, Psi.xcodeproj.

You can also build and run from the command line using the runsim script if you are so inclined. After unzipping the sources, here’s what you need to do:

$ cd psi-1.0.0
$ make -f Makefile.iossim Psi
$ runsim Psi

If Psi doesn’t show up, set the simulated iOS version number of the iOS Simulator to 5.1 with the Hardware -> Version menu. runsim places apps into the iOS 5.1 simulator.

For more about the runsim script, see Run iOS Simulator from the Command Line (Improved).

Finally, here is the full source of Psi.

/* psi.m     Tiny iOS App in one file
 *
 * (It just draws a Greek letter Psi.)
 *
 * Copyright (c) 2012 Psellos   http://psellos.com/
 * Licensed under the MIT License:
 *     http://www.opensource.org/licenses/mit-license.php
 */
#import &lt;UIKit/UIKit.h&gt;

@interface AppDelegate : NSObject &lt;UIApplicationDelegate&gt; {
}
@end

@implementation AppDelegate : NSObject
- (BOOL) application: (UIApplication *) anAppl
                didFinishLaunchingWithOptions: (NSDictionary *) opts
{
    UIViewController *vc = [[UIViewController alloc] init];
    UIWindow *w =
        [[UIWindow alloc] initWithFrame: [[UIScreen mainScreen] bounds]];
    UILabel *l = [[UILabel alloc] initWithFrame: [w bounds]];
    l.font = [UIFont fontWithName: @"MarkerFelt-Thin" size: 300.0];
    l.text = [NSString stringWithUTF8String: "\xce\xa8"];
    l.textColor =
        [UIColor colorWithRed: 0.141 green: 0.251 blue: 0.439 alpha: 1.0];
    l.textAlignment = UITextAlignmentCenter;
    l.backgroundColor =
        [UIColor colorWithRed: 0.800 green: 0.333 blue: 0.000 alpha: 1.0];
    vc.view = l;
    w.rootViewController = vc;
    [w makeKeyAndVisible];
    return YES;
}
@end

int main(int argc, char *argv[])
{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    int retVal = UIApplicationMain(argc, argv, nil, @"AppDelegate");
    [pool release];
    return retVal;
}

If you have any comments, corrections, or suggestions, leave them below or email me at jeffsco@psellos.com.

Posted by: Jeffrey

Run iOS Simulator from the Command Line (Improved)

2012-05-19T11:00:00-08:00

May 19, 2012

I like to run apps in the iOS Simulator from outside Xcode—it’s simpler and faster a lot of the time. So, I wrote a shell script named runsim that installs an app in the simulator’s file system and then asks the simulator to start up. In version 1.0 of runsim, you had to start the app yourself by clicking on its icon.

I’ve just finished work on version 2.0 of runsim. I added the ability to start apps in the simulator automatically from the command line. I also separated out the different functions, so you can install, uninstall, list, and run apps as separate operations.

I use runsim to demonstrate OCaml iOS Simulator apps built with OCamlXSim, but it should be useful to anybody who occasionally enjoys a disintegrated development environment like I do.

You can read the full details on Run iOS Simulator from the Command Line.

You can also download runsim from the following link:

runsim — run app in iOS Simulator from command line

Before using it, however, I suggest you read the full description linked above. There are some complexities in using the automatic start-up facility that you want to understand beforehand.

If you have any comments, corrections, or suggestions, leave them below or email me at jeffsco@psellos.com.

Posted by: Jeffrey

OCaml iOS Simulator App “Gamut” Updated for Lion

2012-05-14T11:00:00-08:00

May 14, 2012

I updated the basic OCaml iOS Simulator example app, Gamut, to build under Lion with the latest Xcode. If you’re interested in running OCaml on iOS, building this app and running it in the iOS Simulator is an easy way to get started. There’s also a binary version that you can run in the simulator just by clicking on it.

Gamut is a simple app that shows an animation with colors that change as you touch the screen. The accompanying screenshot shows what it looks like—but imagine that the colors are changing hypnotically.

The update makes no changes to the OCaml and ObjC code—Gamut only uses parts of iOS that haven’t changed since iOS 3.1. However, I spent some time making it easier to try out the app. I built a launcher app that lets you run Gamut in the iOS Simulator with just a few clicks (no command line). I also repackaged the sources so you can build and run in the simulator under Xcode with just a few clicks.

Internally, the launcher app uses the runsim script that I described in a recent blog post Run iOS Simulator from the Command Line. I used Platypus (a really nice free Mac app) to transform runsim into a Mac app. In a day or two I’ll write up a small description of how to do this.

As always, the previous version of Gamut is still available in the OCaml Programming Archives.

Posted by: Jeffrey

OCaml iOS App “Portland” Updated for Lion

2012-05-09T11:00:00-08:00

May 9, 2012

I updated the basic OCaml iOS example app, Portland, to build under Lion with the latest Xcode. It’s a very simple app that just tells you which way you’re holding the phone, as in the accompanying screenshot. If you want to try running OCaml on iOS, building this app and running it on your phone might be a good way to get started.

There are no changes to the OCaml and ObjC code—all the updates are in the instructions and in the project metadata used by Xcode. The generated app runs on iOS 3.1 and later. It would be an interesting exercise to rewrite the app to target a more recent iOS version. I tried a few variations myself, but in the end I decided to target as many devices as possible.

As always, the previous version of Portland is still available in the OCaml Programming Archives.

Posted by: Jeffrey

Psellos Blog

When iOS Simulator Apps Go AWOL

OCamlXSim 3.1 for Mountain Lion

OCaml Cross Compilation Build Howto

Compiler Source Changes

Ordinary OCaml Build

Cross Compiling Requirements

Phase 1

Phase 2

OCamlXARM 3.1 for Mountain Lion

Archimedean Solids in OCaml

OCaml 4.00.0 for iOS ARMv6

OCaml 4.00.0 Patches for VFPv2

OCaml 4.00.0 on iOS Simulator Is Released

OCaml 4.00.0 on iOS Is Released

Convert Linux ARM Assembly Code for iOS (Update 3)

Appendix

OCaml 4.00.0 on iOS: Progress Report

Run Debian ARMEL Linux on OS X with QEMU

Preliminaries

Install QEMU

Install Debian Squeeze ARMEL

Convert Linux ARM Assembly Code for iOS (Update 2)

Appendix

OCaml 4.00.0 Working on iOS

Convert ARM Assembly Code for Apple&#8217;s iOS Assembler (Update 1)

Appendix

Convert ARM Assembly Code for Apple&#8217;s iOS Assembler

Install OCaml on Amazon Linux (EC2)

IcosaBlue 2.0, Now with Weekend Teapot!

LablGLES Released for Lion

OCaml iOS Simulator App &#8220;Voronoi&#8221; Updated for Lion

OCaml iOS App &#8220;Slide24&#8221; Updated for Lion

Wrap an iOS Simulator App as a Mac App

Tiny iOS App in One Source File

Run iOS Simulator from the Command Line (Improved)

OCaml iOS Simulator App &#8220;Gamut&#8221; Updated for Lion

OCaml iOS App &#8220;Portland&#8221; Updated for Lion

Convert ARM Assembly Code for Apple’s iOS Assembler (Update 1)

Convert ARM Assembly Code for Apple’s iOS Assembler

OCaml iOS Simulator App “Voronoi” Updated for Lion

OCaml iOS App “Slide24” Updated for Lion

OCaml iOS Simulator App “Gamut” Updated for Lion

OCaml iOS App “Portland” Updated for Lion