As a Russian, I'm equally surprised. We don't normally separate
thousands at all.
On 11/25/2014 11:21 AM, Pierre Free Pascal wrote:
I am surprised,
for me, as French, I always believed that
the French thousand separator is simply a space,
what else should it be?
Pierre Muller
from Strasbourg,
Hi all,
in the FPC reference at
http://www.freepascal.org/docs-html/ref/refse68.html#x127-13700012.1 ,
the formal grammar spec only goes down as far as factor. Can I please
see the grammar for variable reference? A variable reference can be an
arbitrarily complex thing; for example,
MyStruct
IMHO, just documenting the cross-building process for mobile would already
go a long way. Better yet, shipping prebuilt cross-compiler packs for major
desktop platforms. When I say "mobile", I really mean "Android"; iOS is well
covered as it is (modulo arm64) and Windows CE is on the way out.
What test program, please? Where?
On 10/23/2014 4:12 PM, Michael Van Canneyt wrote:
You had better use the fcl-passrc units. They dump a complete syntax
tree.
It is used to generate (a currently limited version of) javascript,
and used to create documentation.
so it should be usable to gen
I don't see local variable definitions there, either...
On 10/23/2014 12:15 PM, Nikolay Nikolov wrote:
On 23.10.2014 г. 18:59, Vsevolod Alekseyev wrote:
On second look, no, the -vp tree is not sufficient. It doesn't have
datatype definitions, doesn't have interface definitions..
On second look, no, the -vp tree is not sufficient. It doesn't have
datatype definitions, doesn't have interface definitions...
On 10/22/2014 4:44 AM, Nikolay Nikolov wrote:
On 10/22/2014 12:23 AM, Vsevolod Alekseyev wrote:
Hi all,
I wonder where in the FPC compilation flow would
There's no separate makefile for fpcmake alone, is there?
On 10/23/2014 11:12 AM, Jonas Maebe wrote:
On 23/10/14 17:06, Vsevolod Alekseyev wrote:
If you follow the steps in that post, you'll get the following:
makefile:197: *** The Makefile doesn't support target i386-winphones
rebuilding fpcmake itself with the new target in
mind...
On 10/23/2014 10:29 AM, Jonas Maebe wrote:
On 23/10/14 16:21, Vsevolod Alekseyev wrote:
With this in mind, how is one supposed to go about implementing a brand
new target? Should I build a compiler from modified release branch, then
use tha
With this in mind, how is one supposed to go about implementing a brand
new target? Should I build a compiler from modified release branch, then
use that to compile the modified trunk?
On 10/23/2014 5:04 AM, Jonas Maebe wrote:
By never saying that people should build trunk with trunk.
Jonas
Good point, thanks. From a brief look, tree.log retains enough
information to rebuild the source. I'll see if I can work with that...
On 10/22/2014 4:44 AM, Nikolay Nikolov wrote:
The compiler already supports dumping the parse tree when you use the
-vp option. But it's more intended for debugg
Hi all,
I wonder where in the FPC compilation flow would be a good spot to dump
the parsed syntax tree of a source?
Here's why I'm asking. For a while now, I've been struggling to adapt a
bunch of Pascal code to various mobile platforms. It's been painful. The
code itself is pretty conservat
h of the the RTL into 2.7.1,
too. Then trunk\packages and trunk\utils built and installed fine.
On 10/8/2014 12:49 PM, Marco van de Voort wrote:
In our previous episode, Vsevolod Alekseyev said:
Indeed, there's no utils\fpcm\bin. Looks like "make all" doesn't build
f
Hi all,
I'm tryng to build the latest FPC trunk on x86/Win32 (under 64-bit
Windows 8, not that it should matter). I have FPC 2.6.4 as a bootstrap
in c:\FPC\2.6.4. The PATH contains c:\FPC\2.6.4\bin\i386-win32. The
source tree is in c:\FPC\trunk.
Here's what I'm doing:
c:\fpc\trunk> make all
I've got a static FPC library on iOS that works fine. Don't pass strings
back and forth, pass PChar's. Pointer-to-records are OK, too, but I'd
think twice regarding objects.
On 8/26/2014 4:47 PM, Sergio Flores wrote:
Let's start this email by saying that I know perfectly that FPC does
not sup
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 r
ding
"-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, schrie
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 t
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 -
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'
_
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
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
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
*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
instruct
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.fre
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.
Nat
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
Yay! Thank you guys.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 s
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) *m
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 b
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
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://l
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 functio
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.
U
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:2
Well, the iOS support in FPC could use some love, too. Out of three iOS
target architectures that Xcode 5.x supports, FPC only generates code for
one. And the installation process isn't exactly straightforward, either. The
Xcode templates for Pascal aren't even a part of FPC proper.
It looks to me
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
> A properly generated object file encodes the abi so normally the linker
complains when you try to link object files with different abis.
Not if generated from assembly :) Which is exactly how the Pascal code works
in my WinPhone and bada ports. Oh, and when I say "fun challenge" I mean
"dirty un
PM
To: FPC developers' list
Subject: Re: [fpc-devel] ARMHF a separate CPU? Why?
On 09 Mar 2014, at 18:09, Vsevolod Alekseyev wrote:
> I guess Free Pascal doesn't care for the same platforms that I do :)
> And that would be the mobile ones - iOS, Android, Windows Phone, bada.
>
Saturday, March 08, 2014 11:13 PM
To: FPC developers' list
Subject: Re: [fpc-devel] ARMHF a separate CPU? Why?
Vsevolod Alekseyev wrote:
> Does Free Pascal really treat ARMHF as a separate CPU target,
It didn't when I initally implemented it and from a quick look at the code
it doesn
AM
To: FPC developers' list
Subject: Re: [fpc-devel] ARMHF a separate CPU? Why?
Am 08.03.2014 16:40, schrieb Vsevolod Alekseyev:
>
> Was this done so that you can have several instances of ARM RTL side
> by side and switch between them seamlessly?
Debian made armhf a separate archite
Does Free Pascal really treat ARMHF as a separate CPU target, distinct from
regular ARM? May I ask why such design? In the grand symphony of native code
generation, the floating point calling convention sounds, to me, as a much
smaller detail than, for example, ARM vs Thumb or PIC vs. non-PIC or
Please, is there a way to make Free Pascal on ARM use floating point
registers for passing floating point parameter?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Hi Sergio,
I say your message on the Free Pascal mailing list:
http://lists.freepascal.org/lists/fpc-devel/2014-January/033140.html
I have recently succeeeded in porting a rather large algorithm library
written in Delphi to Windows Phone, via Free Pascal. Depending on the
specifics of your p
44 matches
Mail list logo
