I'm happy to announce that a couple of weeks back, I finally got my iPhone developer certificate so I could start testing the port. It turned out that a) the version of Mac OS X on the iPhone really is virtually the same as the desktop version, so I did not have to change any existing RTL code at all (I only had to add support for ARM hardware exceptions -- more on that below) b) the ARM code generator in FPC is quite good, as I did not really have to fix anything there (and Darwin/ARM uses the OABI rather than the EABI, so no problems there either) c) the Darwin/ARM support I added to the compiler earlier on, based on looking at GCC-generated code and the GCC and LLVM code generators, worked fine as well (that was a really unexpected but pleasant surprise -- and no, I didn't secretly test that on a jailbroken iPod or so, I wrote it before I even had my iPod
Today, I've converted FPC's glutdemo to OpenGL ES and successfully integrated that code into the Xcode "OpenGL ES Application" template (so all the setup is don't by Apple's Objective-C code, but the drawing/animation by FPC code). The result is that I now have an application on my iPod that displays a flying/swiveling/spinning FPC logo text built out of cubes (screenshot in attachment). Not particularly useful, but nice nonetheless
I'll now focus on trying to create a distribution which is generally usable, i.o.w., an installer package and one or more Xcode template projects that integrate FPC code (I'm currently doing most things manually, with Xcode doing the code signing, transferring to the iPod and attaching the debugger). Some remaining challenges/issues are: 1) Distribution I cannot distribute the translation of one particular header file from the iPhone SDK that is necessary to compile the FPC run time library (for handling hardware exceptions). It can however be converted automatically from the C header. This means that I either have to figure out at installation time where you installed the iPhone SDK (anyone knows whether/how this is possible based on installation receipts or so?), or ask at installation time where it's installed and communicate this back to a script that then will translate the file and compile everything (again, ideas are welcome for how you can do this using Apple's installer -- you can launch apps pre/post installation, but I'm close to a zero as far as writing GUI apps goes and I have no idea how to safely communicate things back to the installation script). 2) Simulator support While the code for the simulator itself is generic Mac OS X/Intel code, the APIs are sometimes slightly different (e.g., OpenGL ES on the iPhone/iPod vs. OpenGL on the desktop -- and OpenGL ES is not a proper subset of OpenGL). This means it has to become an separate FPC target as well (unless you want to manually avoid using the wrong units), which is annoying. I think I won't spend much if any time on this, certainly not initially. 3) Testing While I did not encounter any code generator or other problems during my getting test programs to run, the ARM code generator is not as well tested as the PowerPC and i386 code generators. The problem is that you cannot login remotely on an iPhone/iPod Touch (unless it's jailbroken, but a) my iPod Touch 2G cannot yet be jailbroken, and b) I can't really afford getting into that since that could jeopardise the entire port), which means that there is no way to efficiently run our regression test suite on them at this time (you can maybe do it manually or scripted via Xcode, if you figure out a way to extract the exit code from the test programs, but even then it would be extremely slow). Please note that creating a generally usable distribution with the appropriate Xcode templates itself is a significant amount of work, and that it may still take a couple of weeks before that gets finished. But apart from that: it works
Jonas
Reply With Quote
Bookmarks