[fpc-devel] FPC and Windows Phone 8

[Vsevolod Alekseyev]

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/