1. Developing iPhone apps
- Posted by Matt007 Mar 06, 2009
- 995 views
I am new to Euphoria and noted, with interest, the ability to convert EU programs to C. Has anyone had any experience in writing an iPhone app in EU and then coverting to C for submission to Apple? As I understand it, iPhone apps are written in Objective C.
2. Re: Developing iPhone apps
- Posted by jeremy (admin) Mar 06, 2009
- 992 views
I am not sure about iPhone apps. Euphoria 4.0 is now ported to OS X. Does that help any with iPhone? What type of processor does the iPhone use? Operating System?
Jeremy
3. Re: Developing iPhone apps
- Posted by Matt007 Mar 06, 2009
- 974 views
The SDK will only run under OS X. I haven't seen any specifics on what is running under the hood of the iPhone.
4. Re: Developing iPhone apps
- Posted by jimcbrown (admin) Mar 06, 2009
- 970 views
The SDK will only run under OS X. I haven't seen any specifics on what is running under the hood of the iPhone.
EU works on OS X now, but still requires an x86 processor.
5. Re: Developing iPhone apps
- Posted by Matt007 Mar 06, 2009
- 967 views
OK, but if the code is created with EU on an X86 and then coverted to C, wouldn't the resulting executible be indepent of processor?
6. Re: Developing iPhone apps
- Posted by mattlewis (admin) Mar 06, 2009
- 999 views
OK, but if the code is created with EU on an X86 and then coverted to C, wouldn't the resulting executible be indepent of processor?
The iPhone runs on an ARM chip. At one point, Mark Brown had an interpreter working for an ARM device, so it's definitely possible to do this. However, first, you'd need to port the euphoria code over to that architecture (plus OS). I've never worked with ARM, so I can't really say what might be required.
Matt
7. Re: Developing iPhone apps
- Posted by jimcbrown (admin) Mar 06, 2009
- 988 views
- Last edited Mar 07, 2009
OK, but if the code is created with EU on an X86 and then coverted to C, wouldn't the resulting executible be indepent of processor?
No. The C code for the eu runtime library violates ANSI C in a manner such that it would only compile on an X86. And you need the runtime library or else the converted C code will not run.
It's possible to fix this by "porting" the runtime library and the translator to a different processor. I'm not sure how hard (or easy) it would be, but if you succeeded in doing this then... the rest should be easy by comparision.
