Re: [fpc-devel] FPC and Windows Phone 8

2014-03-25 Thread Yury Sidorov

On 24.03.2014 21:36, Vsevolod Alekseyev wrote:

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

...
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


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,
j...@cp-lab.com
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-24 Thread Vsevolod Alekseyev

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'

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-24 Thread Florian Klämpfl
Am 24.03.2014 16:30, schrieb Vsevolod Alekseyev:
 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.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-24 Thread Vsevolod Alekseyev

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.


On 3/24/2014 3:21 PM, Florian Klämpfl wrote:

Am 24.03.2014 16:30, schrieb Vsevolod Alek
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.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-24 Thread Florian Klämpfl
Am 24.03.2014 20:36, schrieb Vsevolod Alekseyev:
 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.

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.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-24 Thread Vsevolod Alekseyev

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


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.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-24 Thread Florian Klämpfl
Am 24.03.2014 21:05, schrieb Vsevolod Alekseyev:
 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?

 
 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.

 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

 
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
 

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-24 Thread Vsevolod Alekseyev
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.



On 3/24/2014 4:08 PM, Florian Klämpfl wrote:

Am 24.03.2014 21:05, schrieb Vsevolod Alekseyev:

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?


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-24 Thread Tomas Hajny
On Mon, March 24, 2014 21:19, Vsevolod Alekseyev wrote:
 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


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-24 Thread Vsevolod Alekseyev
Won't that ruin the cross-RTL building process? The files still need to 
be assembled.


On 3/24/2014 4:35 PM, Tomas Hajny wrote:

On Mon, March 24, 2014 21:19, Vsevolod Alekseyev wrote:

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


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-24 Thread Tomas Hajny
On Mon, March 24, 2014 21:42, 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




 On 3/24/2014 4:35 PM, Tomas Hajny wrote:
 On Mon, March 24, 2014 21:19, Vsevolod Alekseyev wrote:
 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?


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-21 Thread Florian Klämpfl
Am 19.03.2014 18:07, schrieb Vsevolod Alekseyev:
 *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.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-21 Thread Vsevolod Alekseyev

Explain please?

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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-21 Thread Florian Klämpfl
Am 21.03.2014 17:34, schrieb Vsevolod Alekseyev:
 Explain please?

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

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

 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

 
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
 

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-21 Thread Vsevolod Alekseyev
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?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-21 Thread Florian Klämpfl
Am 21.03.2014 17:43, schrieb Vsevolod Alekseyev:
 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 ;)?

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-21 Thread Vsevolod Alekseyev
Point taken :) How old is this option, anyway? -h, unfortunately, 
doesn't have a What's new section.




ppcarm -h ;)?


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-21 Thread Florian Klämpfl
Am 21.03.2014 17:50, schrieb Vsevolod Alekseyev:
 Point taken :) How old is this option, anyway? 

Aug. 2013, r25370

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-19 Thread Florian Klaempfl
Just a note: trunk supports now to generate hardfloat arithmetics with 
thumb enabled.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-19 Thread Vsevolod Alekseyev

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

On 3/19/2014 9:42 AM, Florian Klaempfl wrote:
Just a note: trunk supports now to generate hardfloat arithmetics with 
thumb enabled.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-19 Thread Florian Klaempfl

Am 19.03.2014 15:10, schrieb Vsevolod Alekseyev:

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


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



On 3/19/2014 9:42 AM, Florian Klaempfl wrote:

Just a note: trunk supports now to generate hardfloat arithmetics with
thumb enabled.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-19 Thread Vsevolod Alekseyev
*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.



On 3/19/2014 12:59 PM, 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).




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-19 Thread Jeppe Græsdal Johansen

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).


Den 19-03-2014 15:10, Vsevolod Alekseyev skrev:

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

On 3/19/2014 9:42 AM, Florian Klaempfl wrote:
Just a note: trunk supports now to generate hardfloat arithmetics 
with thumb enabled.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-13 Thread Vsevolod Alekseyev
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.




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-13 Thread Michael Schnell

On 03/13/2014 03:24 PM, 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-12 Thread Michael Schnell

On 03/11/2014 01:08 PM, 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-12 Thread Michael Schnell

On 03/11/2014 03:12 PM, 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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-12 Thread Michael Schnell

On 03/11/2014 02:02 PM, 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-12 Thread Sven Barth
Am 12.03.2014 10:31 schrieb Michael Schnell mschn...@lumino.de:

 On 03/11/2014 02:02 PM, 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 :-) ).

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

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-12 Thread Michael Schnell

On 03/12/2014 12:17 PM, Sven Barth wrote:


 (in fact not for 68K :-) ).

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

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


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-12 Thread Vsevolod Alekseyev
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.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-12 Thread Michael Schnell

On 03/12/2014 02:17 PM, Vsevolod Alekseyev wrote:

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.

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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Florian Klämpfl


On 11. März 2014 03:13:18 MEZ, Vsevolod Alekseyev se...@sprynet.com wrote:
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.

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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Sven Barth

On 11.03.2014 03:10, Vsevolod Alekseyev wrote:

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


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



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.


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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Florian Klämpfl


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

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. 

This sounds pretty simple to me :-)?

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Sven Barth

Am 11.03.2014 07:50, schrieb Florian Klämpfl:


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

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.

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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Sven Barth

Am 11.03.2014 07:48, schrieb Florian Klämpfl:


On 11. März 2014 03:13:18 MEZ, Vsevolod Alekseyev se...@sprynet.com wrote:

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.

Normally,  the ABI is defined by the OS vendor and not the tool chain?
That Windows isn't normal here should have been shown by the MinGW ABI 
problem already :P


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Michael Schnell

On 03/11/2014 03:10 AM, 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Michael Schnell

On 03/11/2014 03:13 AM, 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Michael Schnell

On 03/11/2014 08:53 AM, 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Mark Morgan Lloyd

Michael Schnell wrote:

On 03/11/2014 03:10 AM, 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.


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.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Vsevolod Alekseyev
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.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Vsevolod Alekseyev
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? 

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Vsevolod Alekseyev
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 :)
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Vsevolod Alekseyev
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


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Sven Barth

Am 11.03.2014 15:12, schrieb Vsevolod Alekseyev:

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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-11 Thread Vsevolod Alekseyev
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...


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-10 Thread Sven Barth

On 10.03.2014 00:20, 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-10 Thread Michael Schnell

On 03/10/2014 12:20 AM, 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-10 Thread Vsevolod Alekseyev
 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



-Original Message-
From: fpc-devel-boun...@lists.freepascal.org
[mailto:fpc-devel-boun...@lists.freepascal.org] On Behalf Of Sven Barth
Sent: Monday, March 10, 2014 2:50 AM
To: fpc-devel@lists.freepascal.org
Subject: Re: [fpc-devel] FPC and Windows Phone 8

On 10.03.2014 00:20, 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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-10 Thread Sven Barth

Am 10.03.2014 13:52, schrieb Vsevolod Alekseyev:

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.

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...

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
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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-10 Thread Nikolay Nikolov

On 03/10/2014 03:03 PM, Sven Barth wrote:

Am 10.03.2014 13:52, schrieb Vsevolod Alekseyev:


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

The first three might be bugs in the assembler writer...
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
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-10 Thread 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/

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] FPC and Windows Phone 8

2014-03-10 Thread Vsevolod Alekseyev
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).

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


[fpc-devel] FPC and Windows Phone 8

2014-03-09 Thread Vsevolod Alekseyev
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.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel