Following requests, let me tell how I made a chunk of Pascal code compile and work on Windows Phone 8, with help from FPC.

Here's my story. I have an algorithm library written in Delphi. No input/output, just operations in memory; all calls for I/O are factored away into a dedicated unit that I'm free to replace. I've already succeeded in running this code in iOS and Android using Free Pascal's built-in means. Interaction with the main body of my code, which is in C++, is accomplished via a bunch of "cdecl" functions on the Pascal side, and an object with cdecl callback function pointers, populated on the C++ side. Pascal code is compiled into a static library for iOS, dynamic library on Android. It all works.

Enter Windows Phone 8. In order to have a good debugging experience, you need to build the code both for Intel x86 (for the emulator), and for ARM (for devices). The flavor of ARM that WP8 uses is strictly Thumb-2, with hard floating point and hard-float calling convention (i. e. parameters in floating point registers). Also, on Intel, even the integer calling convention doesn't match between C and Pascal. Here's what I do.

I compile my FPC sources to assembly for Win32/Intel (with -a option). I'm applying some search-replace fixes so that the generated assembly works with MASM. Then I copy the assembly into the WP8 project, where it's assembled and put into a static library.

Free Pascal code relies on its RTL. Even if you don't call library functions much (my library doesn't), there's string stuff, set stuff, some floating point routines like rounding. I've put together a replacement implementation in C for a limited subset of the FPC RTL. String/set functions are implemented faithfully, the rest just pass it along to the relevant C RTL functions. I've also built an assembly file for Intel that translates the calling conventions. For some FPC routines, it contains stubs - a trivial implementation that consists of a single RET statement.

As the starting point for the ARM build, I compile my Pascal for ARM/Android while specifying -CpARMV7A -CfVFPV3_D16; that approximates WP8's dialect of ARM the closest. Naturally, for this to work, I need a copy of the FPC cross-RTL built for the same configuration. I didn't know about the ARMHF target when I was first designing all this; I could've approximated the WP8 dialect even better with ARMHF. Windows Phone 8 uses hard-FP ABI. Maybe later.

Anyway, on the ARM side, things are more involved. For one thing, the generated assembly assumes the ARM mode while WP8 only takes Thumb. So I've put together a translation script in JavaScript that takes ARM assembly with GAS-style directives and makes it work as Thumb-2 with MASM-style directives. For most commands, there's no change; but sometimes, ARM and Thumb has different limits for immediate operands and such; in those cases, my translation script replaces a single command with a small sequence (instead of ldr rd,[rm,offset] with an overlarge offset - add/ldr combo, etc). Also, Microsoft ARMASM assumes the UAL syntax, while FPC generates pre-UAL mnemonics. Replacing those is a part of the translation. Finally, I had work around a bug in ARMASM.

There's also a separate RTL glue assembly file for ARM. It's not as big as the Intel one, since the integer calling conventions match. Among other things, it translates calling conventions for FP functions.

As you see, I've never meant to implement a whole application, or even a whole native layer in Pascal. It's just an algorithm library. Also, I'm heavily relying on the fact that RTL use is limited in the library. Reimplementing a large body of FPC RTL from scratch would be unimaginably hard.

Vsevolod Alekseyev wrote

Enter Windows Phone 8. In order to have a good debugging experience, you need to build the code both for Intel x86 (for the emulator), and for ARM (for devices). The flavor of ARM that WP8 uses is strictly Thumb-2, with hard floating point and hard-float calling convention (i. e. parameters in floating point registers). Also, on Intel, even the integer calling convention doesn't match between C and Pascal. Here's what I do.

Please elaborate in how far the calling convention does not match. This might be a bug in FPC then.

I compile my FPC sources to assembly for Win32/Intel (with -a option). I'm applying some search-replace fixes so that the generated assembly works with MASM. Then I copy the assembly into the WP8 project, where it's assembled and put into a static library.

i386 FPC has support for MASM. Use -Amasm for that.

As you see, I've never meant to implement a whole application, or even a whole native layer in Pascal. It's just an algorithm library. Also, I'm heavily relying on the fact that RTL use is limited in the library. Reimplementing a large body of FPC RTL from scratch would be unimaginably hard.

winrt (i386-winrt, x86_64-winrt and arm-winrt) should become a full target of FPC in the future. It "just" needs to be done.

Regards,
Sven

Vsevolod Alekseyev wrote

WP8 uses is strictly Thumb-2, with hard floating point and hard-float calling convention (i. e. parameters in floating point registers).

Why/how does the OS dictate how in a user program the functions are called ? (In fact in an ASM program you can use whatever calling convention you like).

OK, you can't use registers the OS does not save in interrupts etc, also there are restrictions regarding threadvars, but this does not seem to be the problem, you describe.

-Michael

Please elaborate in how far the calling convention does not match. This

might be a bug in FPC then

I'm talking about my replacement for the subset of the Pascal RTL. The calling code assumes the Pascal convention, the implementation is in C. They don't match on Intel.

i386 FPC has support for MASM. Use -Amasm for that.

I do already. I don't now remember the exact history behind each replacement, but here they are.

- DGROUP is a problem; I comment it out
- So is ASSUME
- The syntax of SEGMENT is different
- Instead of .386p I want .686p
- Instead of _CODE I want _TEXT

Ah ok, that wasn't clear from your mail. :)

> i386 FPC has support for MASM. Use -Amasm for that. I do already.

That wasn't clear either from your mail...

The first three might be bugs in the assembler writer... could you maybe elaborate what the exact problems are?
Also it would be possible to couple the generation of .386p/.686p to the selected target processor. Is there a list of valid options somewhere? What's the difference between _CODE and _TEXT in MASM?

Regards,
Sven

These sound more like a DOS thing. DGROUP is usually used in DOS programs to specify which object file segments have to be merged in a single physical segment (pointed by DS). See:

http://www.nasm.us/doc/nasmdoc7.html#section-7.4.2

(I know this is NASM's and not MASM's documentation, but it explains what DGROUP is)

Also it would be possible to couple the generation of .386p/.686p to the selected target processor. Is there a list of valid options somewhere?

I did this for NASM for the i8086 target, see compiler/x86/agx86nsm.pas, lines 1187..1199. Pretty sure it's just as easy to do for the MASM writer.

What's the difference between _CODE and _TEXT in MASM?

I don't know much about MASM (both the old DOS versions and the new ones), because I used TASM back in the old days and then later switched to NASM, but maybe it's another DOS thing?

Nikolay

Let me reintroduce back each of the problematic lines and see what happens.

Uncommenting DGROUP causes the following error message: error A2214: GROUP directive not allowed with /coff option I don't know what does DGROUP do, but Nikolay knows :) It's a DOS remnant, and makes no sense in Win32.

Uncommenting ASSUME causes the following:
error A2074: cannot access label through segment registers And it makes sense, too; who cares for segment registers on a flat model platform.

.i386 works on VS2012, but on VS2005 (where I debugged initially) it'd give me the following error on every ALIGN 16 line:
error A2189: invalid combination with segment alignment : 16

Other issues, I recall, were about alignment, too. I think specifying .i686 shorted them all out, since it forces an even coarser alignment requirement. So in conjunction with .i686, the replacements for _CODE and for SEGMENT might not be necessary anymore . But they don't hurt, either.

Anyways, as far as I can see, the biggest hurdle to implementing a Windows Phone target in FPC would be the ARM dialect. It's strictly Thumb-2 with hardware floating point and hard-float ABI. Some time ago, I've tried for a short while to make classic, 32-bit ARM code work on a device, and I couldn't. I've tried several assembly sequences that would branch and switch mode; they all would cause an exception. I'm not sure if non-support for ARM code is a feature in newer ARM cores; I'll ask around. FPC, as of now doesn't support Thumb-2 with hard FP.

For the record, the native subsystem of Windows RT (AKA Windows 8 for ARM) and that of Windows Phone 8 are not identical - there's no binary compatibility. Microsoft has plans to merge them (away from phone, towards Windows RT), but that won't be the case for the near future. According to rumors, in the next major WP8 update, the Silverlight front-end will still be supported, but the direction would be towards WinRT all the way through. Source:
http://arstechnica.com/information-technology/2014/02/windows-phone-8-1-will -be-big-big-enough-to-be-windows-phone-9/

It's not all assembly. The fake FPC RTL was written in C because I wanted it to be portable (Intel/ARM/Thumb at the very least, at some point MIPS too). The calling convention of C code *is* largely driven by the platform's toolchain.

Why/how does the OS dictate how in a user program the functions are called

? (In fact in an ASM program you can use whatever calling convention you like).

Normally, the ABI is defined by the OS vendor and not the tool chain?

You could report these as bugs. I bet the MASM writer didn't get that much love in the past. ;)

I don't have a Windows Phone 8 device, so I can't test. But as FPC is in theory capable of generating Thumb code it should be "just" a matter of wiring the correct settings together inside the compiler for a winrt target.

For the record, the native subsystem of Windows RT (AKA Windows 8 for ARM) and that of Windows Phone 8 are not identical - there's no binary compatibility.

They are API compatible (though WP8 is a subset of WRT). In how far they could really be treated as one target needs to be seen. At first I would nevertheless implement i386/x86_64-winrt, because that will lay the API ground work which all winrt/wp8 platforms will share and is far easier to debug than WP8.

Regards,
Sven

On 11. März 2014 03:10:08 MEZ, Vsevolod Alekseyev .

This sounds pretty simple to me :-)?

If one adjusts the compiler, yes. If on the other hand one uses the non-Thumb code generated by the compiler and converts it to Thumb: no. :P

Regards,
Sven

That Windows isn't normal here should have been shown by the MinGW ABI problem already :P

Regards,
Sven

Vsevolod Alekseyev wrote

I've tried several assembly sequences that would branch and switch mode; they all would cause an exception.

Supposedly the interrupt code of the OS does not save and restore the "running in Thumb mode" flag. So you are out of luck with non-Thumb code.

This is obviously a shortcoming due to the arrogance of the creator of the OS, thoughtlessly castrating the high-performance feature of the processor.

This strictly recommends not to use this OS.

-Michael

Vsevolod Alekseyev wrote

The calling convention of C code *is* largely driven by the platform's toolchain.

So you mean "the meaning of 'STDCALL' needs to adhere to the toolchain used"

This of course is true (but not that closely depending on the OS itself)

OTOH the other message in this thread resulted in the knowledge that the preservation of the "thumb" flag (that of course under the hood also is pert of the ABI) does depend on the usability of the OS.

-Michael

Sven Barth wrote

That Windows isn't normal here should have been shown by the MinGW ABI problem already :P

In Windows the correct ABI is not even published.

E.g. we all do know that (with normal X86 32 bit windows) The Microsoft C compilers rely on the area to be be used for Threadvars is pointed to by a Selector register, while the docs say that this pointer needs to be fetched by a complex call.

That is why on that behalf fpc programs are slower than visual C programs.

- Micheal

I don't know whether this is news to anybody: if not my apologies for adding noise to the thread.

Elsewhere, I see a number of experienced (ex-)Delphi programmers complaining that

!! It seems Microsoft has changed the functionality of GetVersionEx !! with Windows 8.1 to no longer return the accurate operating system ! ...and instead shows the version of the operating system that it ! thinks your program wants to hear, rather like a child answering a ! tricky question ('Have you tidied your room?). Fabulous.

There's more in that vein, including some tentative workarounds, but this appears to be a potential portability pitfall.

How interesting. Where's you hear this?

Supposedly the interrupt code of the OS does not save and restore the

"running in Thumb mode" flag. So you are out of luck with non-Thumb code.

Not on Windows. The calling convention of DLL functions (including API) and callbacks is mandated by the platform indeed, but within your app it's a free-for-all. Just ask Delphi with their funky register-based convention :)

Normally, the ABI is defined by the OS vendor and not the tool chain?

For the record, all modern mobile SDKs that I know of use Thumb as the default instruction set for native code compilation. And with Thumb-2 on ARMv7 cores, the performance is on par between ARM and Thumb. The original Thumb, years ago, was compiled to ARM, but not any longer.

Thumb may even beat ARM occasionally, because more code fits into a cache line. And I won't be surprised if newer cores start optimizing for Thumb at the expense of ARM.

Windows CE is not modern :)

From where I sit, it beats patching a huge codebase that I know next to nothing about. Besides, my job is made easier by avoiding the gnarliest parts of the FPC RTL. No objects, no dynarrays, no RTTI, no exceptions, no Unicode. That's how easy (read: old-fashioned, almost Turbo Pascal-style) *my* codebase is. What's there not to love? :)

If one adjusts the compiler, yes. If on the other hand one uses the

non-Thumb code generated by the compiler and converts it to Thumb: no. :P

Vsevolod Alekseyev wrote

Windows CE is not modern :)

Windows Phone 8 is not based on Windows CE, but on Windows NT. Also Windows CE never had problems with non-Thumb code...

Regards,
Sven

I know. As a counterpoint to my initial statement, Windows CE defaults to building into ARM. That's why I hedged. :)

My point is, while only Windows Phone 8 *enforces* Thumb, others, specifically iOS, Android, bada, all *default* to Thumb. Won't be long until CPU builders wake up to that and start optimizing accordingly.

Windows Phone 8 is not based on Windows CE, but on Windows NT. Also

Windows CE never had problems with non-Thumb code...

Vsevolod Alekseyev wrote

How interesting. Where's you hear this?

It's an obvious conclusion from your statement that any non-Thumb code crashes.

-Michael

Vsevolod Alekseyev wrote

For the record, all modern mobile SDKs that I know of use Thumb as the default instruction set for native code compilation. And with Thumb-2 on ARMv7 cores, the performance is on par between ARM and Thumb. The original Thumb, years ago, was compiled to ARM, but not any longer....

I did not do any research on Thumb myself, but I did some regarding MIPS (running on PIC32) that also can run in modes with 32 Bit and 16 Bit instructions words.

It's obvious that it depends on the hardware environment such as the size and relative speed (regarding the CPU) of the 1st level cache if code runs faster with 32 Bit instruction words.

Small code snippets with many iterations with limited data memory usage (such as calculation of PI) tend to run faster with 32 instruction words.

With MIPS you can call 32 or 16 bit functions without any Mode-Switch overhead, so "Math" libraries should be done in 32 Bit, While a database supposedly is better compiled to 16 Bit.

-Michael

Vsevolod Alekseyev wrote

Just ask Delphi with their funky register-based convention :)

I did a research on many different CPUs for a future project and found that - like with Delphi - with many modern GNU C compilers registers are used for the first few function arguments (in fact not for 68K :-) ).

-Michael

that - like with Delphi - with many modern GNU C compilers registers are used for the first few function arguments (in fact not for 68K :-) ).

Which is a pity as it has a nice amount of registers to spare :P

Regards,
Sven

I suppose nobody wanted to stand up and change the old fashioned "STDCALL" default ABI for sake of speed.

-Michael

It's one possible implementation, but hardly the only one. In fact, this kind of implementation would have testable consequences - specifically, a *short* amount of ARM would be able to run unmolested in a debuggerless environment - i. e. if no interrupts come while in ARM mode. I'll try it when I get a chance.

It's an obvious conclusion from your statement that any non-Thumb code

crashes.

You can't prevent interrupts when in Usermode. So even a short function will crash sometimes.

When you do a non-Thumb function that does not call any other function same only can be influenced by an interrupt. So if it crashes at all, you know that the interrupt logic of the OS is buggy.

-Michael

I've tried; the results are consistent with the interrupt thing. The following snippet:

ASMTest
mov r12, lr
blx a
mov lr, r12
bx lr

ALIGN 4
ARM
a
bx lr

Consistently crashes when executed under a debugger, but ran as expected 10 times in a row when standalone.

Naturally, this means that any kind of *sensible* ARM code would pointless. Oh well. At least there are no CPU-level miracles :)

You can't prevent interrupts when in Usermode. So even a short

function will crash sometimes.

When you do a non-Thumb function that does not call any other

function same only can be influenced by an interrupt. So if it crashes at all, you know that the interrupt logic of the OS is buggy.

Vsevolod Alekseyev wrote

Consistently crashes when executed under a debugger, but ran as expected 10 times in a row when standalone.

Under debugger you will constantly have interrupts. So this is as expected.

-Michael

Just a note: trunk supports now to generate hardfloat arithmetics with thumb enabled.

With -CpARMv7M, I presume? Thanks, I'll try.

Vsevolod Alekseyev wrote

With -CpARMv7M, I presume? Thanks, I'll try.

Yes. What kind of thumb is generated depends on the -Cp switch.

Just a reminder:
ARMv7-M code will not work on a ARMv7-A. They are have different instruction set capabilities(mostly related to division though).

*checks Wikipedia* Indeed so. 7M always has division, 7A might not. If there's no way to generate Thumb-2 code for 7A, then it's no use, I'm afraid.

Jeppe Græsdal Johansen wrote

Just a reminder: ARMv7-M code will not work on a ARMv7-A. They are have different instruction set capabilities(mostly related to division though).

Vsevolod Alekseyev wrote

*checks Wikipedia* Indeed so. 7M always has division, 7A might not. If there's no way to generate Thumb-2 code for 7A, then it's no use, I'm afraid.

Who said that this is not possible? Just create thumb and select 7a as cpu.

Explain please?

Vsevolod Alekseyev wrote

Explain please?

In which regard?
Does
-CIthumb -Cparmv7a
not work?

This is the first time I hear about -CI. It's not documented, and ppcrossarm -i doesn't mention it (in a month-old trunk build).

Is there another source of information I should watch?

In which regard? Does -CIthumb -Cparmv7a not work?

Vsevolod Alekseyev wrote

This is the first time I hear about -CI. It's not documented, and ppcrossarm -i doesn't mention it (in a month-old trunk build). Is there another source of information I should watch?

ppcarm -h ;)?

Point taken :) How old is this option, anyway? -h, unfortunately, doesn't have a "What's new" section.

ppcarm -h ;)?

Vsevolod Alekseyev wrote

Point taken :) How old is this option, anyway?

Aug. 2013, r25370

Not quite there yet.

Got trunk:27263, issued the following:

make clean crossall crossinstall OS_TARGET=android CROSSOPT="-CpARMv7A -CfVFPV3_D16 -CIthumb" CPU_TARGET=arm INSTALL_PREFIX=C:\FPC\2.7.1

Got error:

unix.s:1262: Error: r13 not allowed here
-- `adds r1,r13'

Compilation errors encountered with
make clean all OS_TARGET=linux CROSSOPT="-CpARMv7A -CfVFPV3_D16 -CIthumb -al" CPU_TARGET=arm
are fixed now. However I cannot test the resulting code, as I have no suitable armv7a device.

Thanks. But the Android build is acting funny now, and I'm not sure why.

make clean all OS_TARGET=android CROSSOPT="-CpARMv7A -CfVFPV3_D16 -CIthumb" CPU_TARGET=arm INSTALL_PREFIX=C:\FPC\2.7.1

...

C:/FPC/2.7.1/src/compiler/ppcrossarm.exe -Tandroid -Parm -XParm-linux-androideabi- -Xr -Ur -Xs -O2 -n -Fuarm -Fusystems -FuC:/FPC/2.7.1/src/rtl/units/arm-android -Fiarm -FE. -FUarm/units/arm-android -dRELEASE -CpARMv7A -CfVFPV3_D16 -CIthumb -darm -dGDB -dBROWSERLOG -Sew -CpARMv7A -CfVFPV3_D16 -CIthumb -darm -dGDB -dBROWSERLOG -Sew pp.pas
D:\android-ndk-r9d\toolchains\arm-linux-androideabi-4.8\prebuilt\windows-x86_64\ bin\arm-linux-androideabi-ld.bfd.exe: cannot find crtbegin_dynamic.o D:\android-ndk-r9d\toolchains\arm-linux-androideabi-4.8\prebuilt\windows-x86_64\ bin\arm-linux-androideabi-ld.bfd.exe: cannot find -lc pp.pas(238,36) Error: Error while linking
pp.pas(238,36) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted

That used to work; the Android cross-toolchain would build without me having to provide the path to libc. Why would FPC want to *link* anything for Android over the course of cross-toolchain building? I thought it would first build a cross-compiler (a Windows executable), then compile but not link a bunch of units; no Android-targering linker necessary. Now it looks like FPC is trying to build the Android-hosted compiler, too.

Removing -CIthumb doesn't help.

This is normal that fpc builds a compiler for native usage when cross compiling because it is a test if the cross setup works fine and it makes also bootstrapping easier. Since I'am not interested in android development, I've no clue however, how to fix it.

Makes sense. But it's a new behavior, isn't it?

Vsevolod Alekseyev wrote

Makes sense. But it's a new behavior, isn't it?

No. Only some platforms are excluded (like embedded or msdos) because a native compiler for them makes no sense/will not work due to limited resources.

Did this work for you before?

Worked for a while. And I would recompile the cross-toolchain from trunk fairly often. Maybe some recent developments brought a unit into FPC that's dependent on libc? Anyway, specifically for Android it's not a big deal, because the necessary libc comes with the Android NDK. Adding "-Fl%NDKROOT%\platforms\android-9\arch-arm\usr\lib" to CROSSOPT helps. But for other cross-building scenarios, where the target platform's C RTL might not be readily available, this could pose a problem.

Wouldn't adding '-s' (or '-st') to CROSSOPT help?

Tomas

Won't that ruin the cross-RTL building process? The files still need to be assembled.

Vsevolod Alekseyev wrote

Won't that ruin the cross-RTL building process? The files still need to be assembled.

True, my fault. Nevertheless, you might be still able to build the RTL afterwards by running the make command in the RTL directory (and in packages).

Alternatively, you could probably supply a dummy cross-linker binary.

Tomas

Use "make clean crossall ..."

In such case the native fpc binaries will not be built. Only cross compiler and cross units will be built.
See: http://wiki.freepascal.org/Android

Yury Sidorov,