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
...
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'
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
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
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
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
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
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
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
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
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).
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.
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
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 -
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
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 ;)?
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
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
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
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
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.
*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
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
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.
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
___
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
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
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
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
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
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
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
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
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 :)
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 :-)?
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.
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
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
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
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
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
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
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
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
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)
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 -
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
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
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
-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
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.
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
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.
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
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
55 matches
Mail list logo
