Hello,

It seams that building arm4 software isn't supported for Symbian OS. At least for third-party software, and any example build for it crashes on startup. So I was investigating other solutions.

I was reading the nokia wiki:

http://wiki.forum.nokia.com/index.php/ARM4,_ARMI_&_THUMB

http://wiki.forum.nokia.com/index.php/Build_Targets

Quoting:

"ARMI is the 32-bit instruction set with extra logic to allow it to call THUMB code in addition to other 32-bit code. ARMI is known as ARM interchange format."

It seams that ARMI could be a solution. Executables built for ARMI actually work normally, but there seams to be a lack of information of what exactly is ARMI. The descriptions found are not detailed enougth.

My greatest doubt is: Can I just compile normal arm4 object files with fpc and link them together with armi compiled object files to get the final executable?

I have a fealing this could work, even if FPC doesn't do that "extra logic to call THUMB", because we don't call the OS routines directly, but rather thougth a c wrapper.

I will, of course, just test, but it will be a lot of work, and if someone knows in advance this should theoretically work, or shouldn't, that could speed things up =)

thanks,

The build_targets page sounds like ARMI starts up in 32-bit (ARM4) mode, but can using some trick enter THUMB mode.

So it seems you only have to do something special for ARMI (vs ARM4) if you do thumb?

From: "Felipe Monteiro de Carvalho"

The solution is to create wrapper library for OS calls. The library will do arm->thumb interworking. It will switch to thumb mode before OS call and switch back to ARM mode after OS call. Also startup code for FPC program should switch CPU to ARM mode.

Yury.

Marco van de Voort wrote

So it seems you only have to do something special for ARMI (vs ARM4) if you do thumb?

My current theory is that the user library present on my phone is built for thumb. So, when a pure arm4 application tryes to access it, it crashes.

The armi application would succed.

This is, of course, just a wild guess.

[ Charset ISO-8859-1 unsupported, converting... ]

It seems that when you branch, in the instruction you can encode if the instructionset of the target is thumb or not.

From my Arm architecture manual (2nd ed) :

The BX (Branch and Exchange) instruction branches to an address held in a register Rm with an optional switch to thumb execution.

Architecture :v5+ and T versions of v4.

If you want more stuff looked up, yell.

Marco van de Voort wrote

It seems that when you branch, in the instruction you can encode if the instructionset of the target is thumb or not.

So, currently fpc set's all branches to use arm4 mode

And C++ apps compiled could check what the system is using and use a if to either call in arm4 or call in thumb mode. The strange thing is that this is a bit arbitrary. There is nothing special about an OS call, it's just a call like any other. I wonder where does the compiler get the information of if the function is in arm4 or thumb mode.

If you want more stuff looked up, yell.

thanks

I'd guess an attribute somewhere in the header. Either per function, or for the header/lib as a whole.

From: "Felipe Monteiro de Carvalho"

FPC just do calls using BL command. It expects that all procedures are ARM4.
C compilers has option called thumb interworking which wraps each procedure call with code which checks for procedure mode and performs necessary mode swithes. It will slowdown calls.

Also as Marco said interworking code can be added or not depending of object file instruction set.

Yury.

On arm-linux and with gnu binutils, simply assemble everything with -mthumb-interwork and you can mix arm and thumb o-files without worrying about anything.