Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi,
16.12.2018 2:13, I wrote:

Is there any easy way to see how exactly ppcrossarm.exe invokes
assembler (command-line arguments passed) during a cross-compiler build
and also to inspect intermediate .s files?


Got it, somewhat:
-mfpu=softvfp is passed to arm-linux-as while compiling intermediate .s 
files (when using -Cfsoft), not sure if it is correct and intentional,
and no special flags passed to arm-linux-as while compiling assembler 
sources.

Hence the difference reported by objdump.

Now apparently, current binutils' ld wants that somehow fpu type is also 
specified for linking output if it was specified when assembling input 
and they probably need to match each other. I could not find such 
option, but e.g. gcc apparently has some way to automagically do it.



Thank you!

Regards,
Nikolai


Thing is, object files compiled from pascal (like system.o) still get
this suspicious VFP flag even after I started using CROSSOPT="-CpARMV6
-Cfsoft". However, object files compiled from assembler sources (like
prt0.o) does not. I'm trying to find where it comes from.

arm-linux-objdump.exe -p prt0.o
prt0.o: file format elf32-littlearm
private flags = 0: [APCS-32] [FPA float format]

arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

As a side note, I suddenly realised that I don't need any specially
crafted version of binutils as long as I target linux and build binutils
from source. Standard binutils source tar compiles with almost zero
effort on modern mingw, at least for linux target.


Thank you!

Regards,
Nikolai


15.12.2018 23:23, I wrote:

Still can not understand this ".o uses VFP instructions, whereas .\pp
does not", but because I build binutils myself I've found and disabled
the ld error exit on (in_flags & EF_ARM_VFP_FLOAT) != (out_flags &
EF_ARM_VFP_FLOAT), and then with such "fixed" binutils crossfpc build
completed somehow. I can now produce arm-linux executables, but probably
something is wrong anyway because this "VFP float format" is present in
.o files but not in final elf executables:

arm-linux-objdump.exe -p t.o
t.o: file format elf32-littlearm
private flags = 400: [APCS-32] [VFP float format]

arm-linux-objdump.exe -p t
t: file format elf32-littlearm
Program Header:
..
private flags = 0: [APCS-32] [FPA float format]

(t.pas is a helloworld one-liner.)

Besides, I get tons of warning from ld like this:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
C:\FPC\3.0.4\units\arm-linux\rtl\system.o: Warning: Arm BLX instruction
targets Arm function 'SYSTEM_$$_SYSINITSTDIO'.

It looks like literally every function in every unit produce such a "Arm
BLX instruction" warning. Seems suspicious.

And finally, on the target board, the executable totally fails with:

"Illegal instruction"

Any hints?


Thank you!

Regards,
Nikolai


It successfully produced object files, but ld refsuses to link them.
Again, the message is:
pp.o uses VFP instructions, whereas .\pp does not
(lots of these repeated)

I'm guessing is that either some option is missing for ld to actually
accept that VFP is present, or rather I need to rebuild my binutils for
a different (hard fp) target?

(The exact call that fails now is arm-linux-ld.exe -s -L. -o .\pp
.\link.res)


Thank you!

Regards,
Nikolai





___
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




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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Sven Barth via fpc-devel]

Am Sa., 15. Dez. 2018, 23:55 hat Nikolai Zhubr 
geschrieben:

> Hi,
>
> Is there any easy way to see how exactly ppcrossarm.exe invokes
> assembler (command-line arguments passed) during a cross-compiler build
> and also to inspect intermediate .s files?
>

You can try -sh which should generate a bat file inside the output
directory that you can look at.

Regards,
Sven

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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi,

Is there any easy way to see how exactly ppcrossarm.exe invokes 
assembler (command-line arguments passed) during a cross-compiler build 
and also to inspect intermediate .s files?


Thing is, object files compiled from pascal (like system.o) still get 
this suspicious VFP flag even after I started using CROSSOPT="-CpARMV6 
-Cfsoft". However, object files compiled from assembler sources (like 
prt0.o) does not. I'm trying to find where it comes from.


arm-linux-objdump.exe -p prt0.o
prt0.o: file format elf32-littlearm
private flags = 0: [APCS-32] [FPA float format]

arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

As a side note, I suddenly realised that I don't need any specially 
crafted version of binutils as long as I target linux and build binutils 
from source. Standard binutils source tar compiles with almost zero 
effort on modern mingw, at least for linux target.



Thank you!

Regards,
Nikolai


15.12.2018 23:23, I wrote:

Still can not understand this ".o uses VFP instructions, whereas .\pp
does not", but because I build binutils myself I've found and disabled
the ld error exit on (in_flags & EF_ARM_VFP_FLOAT) != (out_flags &
EF_ARM_VFP_FLOAT), and then with such "fixed" binutils crossfpc build
completed somehow. I can now produce arm-linux executables, but probably
something is wrong anyway because this "VFP float format" is present in
.o files but not in final elf executables:

arm-linux-objdump.exe -p t.o
t.o: file format elf32-littlearm
private flags = 400: [APCS-32] [VFP float format]

arm-linux-objdump.exe -p t
t: file format elf32-littlearm
Program Header:
..
private flags = 0: [APCS-32] [FPA float format]

(t.pas is a helloworld one-liner.)

Besides, I get tons of warning from ld like this:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
C:\FPC\3.0.4\units\arm-linux\rtl\system.o: Warning: Arm BLX instruction
targets Arm function 'SYSTEM_$$_SYSINITSTDIO'.

It looks like literally every function in every unit produce such a "Arm
BLX instruction" warning. Seems suspicious.

And finally, on the target board, the executable totally fails with:

"Illegal instruction"

Any hints?


Thank you!

Regards,
Nikolai


It successfully produced object files, but ld refsuses to link them.
Again, the message is:
pp.o uses VFP instructions, whereas .\pp does not
(lots of these repeated)

I'm guessing is that either some option is missing for ld to actually
accept that VFP is present, or rather I need to rebuild my binutils for
a different (hard fp) target?

(The exact call that fails now is arm-linux-ld.exe -s -L. -o .\pp
.\link.res)


Thank you!

Regards,
Nikolai





___
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


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[wkitty42]

On 12/15/18 11:57 AM, Nikolai Zhubr wrote:

15.12.2018 19:09, wkitt...@windstream.net:

On 12/15/18 10:36 AM, Nikolai Zhubr wrote:

So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?



is this a typo? should it be -CfVPF4_S16 with F and V swapped?


No. From ppcrossarm.exe -i:

Supported FPU instruction sets:
   SOFT,LIBGCC,FPA,FPA10,FPA11,VFPV2,VFPV3,VFPV3_D16,FPV4_S16



ok, it just jumped out at me because you had been talking about VFP but this was 
FPV... and apparently i goofed my above, too... i don't even know which one 
would be proper... it is just crazy that there are so many but that would be a 
standard, wouldn't it? :lol:



(And yes, such kind of abbrevations is always a bit frustrating to type and 
check, although it is obviously not fpc's fault)



i'm guessing that VFP is Virtual Floating Point which i would understand as 
being emulated kinda like we used to do when a machine didn't have a math 
co-processor in it...



--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] x86_64 Optimizer Overhaul

[Jonas Maebe]

On 15/12/18 21:04, Ben Grasset wrote:
On Sat, Dec 15, 2018 at 2:43 PM Jonas Maebe > wrote:


That is incorrect.

I didn't mean that it doesn't *care* about being fast, but more that it 
will not necessarily use more memory in all cases that it might result 
in a speed gain, and generally is more concerned with a "balanced" 
approach, which is what I've always heard to be the case. Is that really 
not true at all?


It makes use of thread-local heaps and pooling for small allocation 
sizes, both of which are aimed at increasing speed. For blocks that are 
too large for the pools, there are no particular trade-offs afaik (it's 
just a linked list of free blocks per thread that can be reused). It's 
probably true that it will have a smaller memory footprint than 
something like jemalloc, at least as long as memory fragmentation (which 
jemalloc is very good at avoiding) doesn't take the upper hand.



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

Re: [fpc-devel] x86_64 Optimizer Overhaul

[J. Gareth Moreton]

 Apologies for my webmail client problems.  There's little I can do about
that.
 This was the object pooling that I did -
https://bugs.freepascal.org/view.php?id=34679 - though there's some cycle
counting involved (e.g. in OptPass1MOV, only the integer registers are
updated instead of all 8 types), this little bit of refactoring also fixed
a couple of memory leaks as a side-effect, since two of the peephole
optimisation routines created an array of TUsedRegs objects, but failed to
free them afterwards.  There are also quite a few locations where
ReleaseUsedRegs is called multiple times in the same routine, mostly in an
attempt to avoid using a "try...finally" block.  Such configurations are
just asking for a bug to be introduced where it's forgotten in one of the
branches.

 Gareth aka. Kit

 On Sat 15/12/18 19:37 , Martok list...@martoks-place.de sent:
 Sorry for hijacking the thread. Your mail client issue makes the
conversation 
 really hard to follow, so I have literally no idea what the current
subtopic of 
 a reply chain is, and there's little point in properly detaching a thread.


 Am 15.12.2018 um 18:13 schrieb J. Gareth Moreton: 
 > I dare ask, does that mean we should avoid workarounds in the compiler
(and 
 > our own programs) that aim to avoid constant construction and
destruction of 
 > objects, and instead try to improve the memory manager? 

 I was thinking more along the lines of avoiding cycle-counting special
paths at 
 the cost of reliability, when there are much larger issues that would
benefit 
 every program. 

 I would not be surprised if some of the large difference Simon listed when

 calling out the bounty come from this side, instead of raw instruction
throughput. 

 > Thus, I would imagine that Delphi's *default* internal memory management

 > system is more along the lines of what is done in FPC's cmem unit, which
is 
 > well known to be objectively faster than FPC's default memory manager 
 I'm fairly certain the runtime is written in Pascal, except for parts of
the 
 startup code. The memory manager at some point (I think D2006?) adopted
FastMM: 
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 

 

Links:
--
[1]
http://docwiki.embarcadero.com/RADStudio/2010/en/Configuring_the_Memory_Manager%26gt
[2] mailto:fpc-devel@lists.freepascal.org
[3] 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] Case block optimisation

[J. Gareth Moreton]

 I'll see what I can do!

 The one thing about my case optimisations here is that they're done at the
node level.  Some parts are platform-independent, but unfortunately,
things like jump table generation have to be implemented for each platform.

 The aint shuffling is a little difficult to test for sure, but what's
worse is the use of TConstExprInt, and not just because of the overhead
involved with reading and writing to them.  I used logic in some places
though, like when I do a sort of for-loop between max_ and hv, I subtracted
1 from each variable (sometimes implicitly) to account for a potential
overflow situation.  It's impossible for it to trigger an underflow
because max_ is greater than min_, and they wouldn't be equal otherwise a
jump table won't even be generated.

 Either way, I'm just enjoying myself with this!

 Gareth aka. Kit

 On Sat 15/12/18 19:55 , Martok list...@martoks-place.de sent:
 Am 15.12.2018 um 18:08 schrieb J. Gareth Moreton: 
 > So here's something else I've been playing with in the interim... I've
been 
 > working on improving the algorithms used when compiling case blocks. 
It was 
 > driven partly by my binary search idea for certain kinds of case block,
which I 
 > wrote up over here:
http://wiki.freepascal.org/Case_Compiler_Optimization
[1]">http://wiki.freepascal.org/Case_Compiler_Optimization 

 Feel free to include '0033093_Casenode_order.patch' from 
  [2]; 
 It's actually already a bit simpler in your version ;-) 

 The one thing that still bugs me (but I know it's not really seen as a
problem 
 in FPC) is that every platform cg theoretically has to implement all of
that, 
 causing a lot of duplication. 

 I like the use of more expressive intermediate names. But there was a lot
of 
 overflowed-aint-shuffling, are you sure that still works everywhere? 

 Bug 0032115 provides a "nice" test case for things that can go wrong with 
 different word sizes, and is also a good test for the true label count. 

 -- 
 Regards, 
 Martok 

 ___ 
 fpc-devel maillist - fpc-devel@lists.freepascal.org [3] 
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[4]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 

 

Links:
--
[1] http://wiki.freepascal.org/Case_Compiler_Optimization
[2] https://bugs.freepascal.org/view.php?id=33093
[3] mailto:fpc-devel@lists.freepascal.org
[4] 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] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi again,

15.12.2018 19:52, Nikolai Zhubr:

15.12.2018 18:24, Florian Klämpfl:

Now, I'm targeting an A20-olinuxino-micro board, which is afaik
armv7a with VPFv4. The board is running either openwrt
or opensuse. (And actually, the binaries produced by the pre-built
native compiler have been tested in both environments
already)

So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?


... and -dFPC_ARMHF. It is more important than the others.


So, apparently most close to success for now was:
CROSSOPT="-CpARMV7A -CfvFPV2 -dFPC_ARMHF"


I've got more results.

First, for completeness, here is my actual /proc/cpuinfo:
Processor   : ARMv7 Processor rev 4 (v7l)
processor   : 0
BogoMIPS: 1434.46
processor   : 1
BogoMIPS: 1439.63
Features: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 
idiva idivt


Currently, I'm trying with CROSSOPT="-CpARMV7A -CfvFPV3 -dFPC_ARMHF"
(FPV4_S16 failed with some assembler complaints, posted earlier, so I 
then tried vFPV3 and it compiled, so I just stayed with it for now)


Still can not understand this ".o uses VFP instructions, whereas .\pp 
does not", but because I build binutils myself I've found and disabled 
the ld error exit on (in_flags & EF_ARM_VFP_FLOAT) != (out_flags & 
EF_ARM_VFP_FLOAT), and then with such "fixed" binutils crossfpc build 
completed somehow. I can now produce arm-linux executables, but probably 
something is wrong anyway because this "VFP float format" is present in 
.o files but not in final elf executables:


arm-linux-objdump.exe -p t.o
t.o: file format elf32-littlearm
private flags = 400: [APCS-32] [VFP float format]

arm-linux-objdump.exe -p t
t: file format elf32-littlearm
Program Header:
..
private flags = 0: [APCS-32] [FPA float format]

(t.pas is a helloworld one-liner.)

Besides, I get tons of warning from ld like this:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: 
C:\FPC\3.0.4\units\arm-linux\rtl\system.o: Warning: Arm BLX instruction 
targets Arm function 'SYSTEM_$$_SYSINITSTDIO'.


It looks like literally every function in every unit produce such a "Arm 
BLX instruction" warning. Seems suspicious.


And finally, on the target board, the executable totally fails with:

"Illegal instruction"

Any hints?


Thank you!

Regards,
Nikolai


It successfully produced object files, but ld refsuses to link them.
Again, the message is:
pp.o uses VFP instructions, whereas .\pp does not
(lots of these repeated)

I'm guessing is that either some option is missing for ld to actually
accept that VFP is present, or rather I need to rebuild my binutils for
a different (hard fp) target?

(The exact call that fails now is arm-linux-ld.exe -s -L. -o .\pp
.\link.res)


Thank you!

Regards,
Nikolai





___
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] x86_64 Optimizer Overhaul

[Ben Grasset]

On Sat, Dec 15, 2018 at 2:37 PM Martok  wrote:

> In any case, FPC's cmem on Win32 calls into mscvrt, and that is so slow
> that I
> killed the test code after a couple of minutes, where even FPC-builtin was
> done
> after 10 seconds.
>

Interesting. On Win64 I've found it to be consistently faster. Also, the
cmem unit changed to call into a copy of Jemalloc.dll (i.e. je_malloc
instead of malloc and such), something I've experimented with, is WAY
faster.

On Sat, Dec 15, 2018 at 2:43 PM Jonas Maebe  wrote:

> That is incorrect.


I didn't mean that it doesn't *care* about being fast, but more that it
will not necessarily use more memory in all cases that it might result in a
speed gain, and generally is more concerned with a "balanced" approach,
which is what I've always heard to be the case. Is that really not true at
all?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Case block optimisation

[Martok]

Am 15.12.2018 um 18:08 schrieb J. Gareth Moreton:
> So here's something else I've been playing with in the interim... I've been
> working on improving the algorithms used when compiling case blocks.  It was
> driven partly by my binary search idea for certain kinds of case block, which 
> I
> wrote up over here: http://wiki.freepascal.org/Case_Compiler_Optimization

Feel free to include '0033093_Casenode_order.patch' from

It's actually already a bit simpler in your version ;-)

The one thing that still bugs me (but I know it's not really seen as a problem
in FPC) is that every platform cg theoretically has to implement all of that,
causing a lot of duplication.

I like the use of more expressive intermediate names. But there was a lot of
overflowed-aint-shuffling, are you sure that still works everywhere?

Bug 0032115 provides a "nice" test case for things that can go wrong with
different word sizes, and is also a good test for the true label count.


-- 
Regards,
Martok

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

Re: [fpc-devel] x86_64 Optimizer Overhaul

[Jonas Maebe]

On 15/12/18 19:37, Ben Grasset wrote:
Should this really be surprising at all though? To me it seems obvious 
why that would be the case. Delphi the compiler (not the IDE) is not 
written in Pascal. It's written in a combination of C and C++. Thus, I 
would imagine that Delphi's *default* internal memory management system 
is more along the lines of what is done in FPC's cmem unit, which is 
well known to be objectively faster than FPC's default memory manager


As Martok wrote, Delphi's memory manager is FastMM. That one is written 
in assembler, afaik. Additionally, cmem is mainly faster (on Unix 
platforms) if you reallocate many (large) memory blocks, which is 
related to what Florian talked about earlier.


as 
FPC's default memory manager simply does not aim to be fast but rather 
to use the smallest amount of memory possible.


That is incorrect.


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

Re: [fpc-devel] x86_64 Optimizer Overhaul

[Martok]

Sorry for hijacking the thread. Your mail client issue makes the conversation
really hard to follow, so I have literally no idea what the current subtopic of
a reply chain is, and there's little point in properly detaching a thread.


Am 15.12.2018 um 18:13 schrieb J. Gareth Moreton:
> I dare ask, does that mean we should avoid workarounds in the compiler (and
> our own programs) that aim to avoid constant construction and destruction of 
> objects, and instead try to improve the memory manager?

I was thinking more along the lines of avoiding cycle-counting special paths at
the cost of reliability, when there are much larger issues that would benefit
every program.

I would not be surprised if some of the large difference Simon listed when
calling out the bounty come from this side, instead of raw instruction 
throughput.


> Thus, I would imagine that Delphi's *default* internal memory management
> system is more along the lines of what is done in FPC's cmem unit, which is
> well known to be objectively faster than FPC's default memory manager
I'm fairly certain the runtime is written in Pascal, except for parts of the
startup code. The memory manager at some point (I think D2006?) adopted FastMM:

In any case, FPC's cmem on Win32 calls into mscvrt, and that is so slow that I
killed the test code after a couple of minutes, where even FPC-builtin was done
after 10 seconds.



-- 
Regards,
Martok


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

Re: [fpc-devel] x86_64 Optimizer Overhaul

[J. Gareth Moreton]

 Well, Florian did say he was concerned about the increased maintenance
costs, given how complex the compiler is already.  Granted, it's one of
the few surefire ways that I've sped up the compiler quite significantly. 
Other speed-ups like other case block algorithms may also help.

 Though the modifications as they stand are perfectly adequate, some "inc"
instructions get changed to "mov, add, mov" that, while not particularly
bad, are a little unexpected, since one of my criteria was that optimised
code is either identical or better to what it was before, not worse.  I
can always introduce a fix for that later though.

 If I know the changes will be approved or rejected, I can work on
additional peephole optimisations that depend somewhat on the overhaul.

  Gareth aka. Kit

 On Sat 15/12/18 19:05 , "Ben Grasset" operato...@gmail.com sent:
 On Sat, Dec 15, 2018 at 1:14 PM J. Gareth Moreton  wrote:P.S. This thread
is supposed to be for the x86_64 optimizer overhaul that I presented!
 Despite the other reply I just sent about the memory management stuff I
also agree here! Your changes look very beneficial and it would be nice to
see them get formally addressed ASAP.   ___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] x86_64 Optimizer Overhaul

[Ben Grasset]

On Sat, Dec 15, 2018 at 1:14 PM J. Gareth Moreton 
wrote:

> P.S. This thread is supposed to be for the x86_64 optimizer overhaul that
> I presented!
>

Despite the other reply I just sent about the memory management stuff I
also agree here! Your changes look very beneficial and it would be nice to
see them get formally addressed ASAP.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] x86_64 Optimizer Overhaul

[Ben Grasset]

On Sat, Dec 15, 2018 at 1:01 PM Martok  wrote:

> I just tested something, and I'm a surprised by how big the difference is.
>

Should this really be surprising at all though? To me it seems obvious why
that would be the case. Delphi the compiler (not the IDE) is not written in
Pascal. It's written in a combination of C and C++. Thus, I would imagine
that Delphi's *default* internal memory management system is more along the
lines of what is done in FPC's cmem unit, which is well known to be
objectively faster than FPC's default memory manager as FPC's default
memory manager simply does not aim to be fast but rather to use the
smallest amount of memory possible.

It seems to me like a clear cut issue of just deciding what the biggest
priority is. If anything, it might make sense to implement a
secondary-default memory manager for FPC that does not necessarily call C
functions like malloc but *does* aim specifically for speed, and that could
perhaps be made available either via a command-line flag or perhaps just by
using a unit the same way cmem is.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] x86_64 Optimizer Overhaul

[J. Gareth Moreton]

 I dare ask, does that mean we should avoid workarounds in the compiler
(and our own programs) that aim to avoid constant construction and
destruction of objects, and instead try to improve the memory manager?
 So many discoveries!
 Gareth aka. Kit
 P.S. This thread is supposed to be for the x86_64 optimizer overhaul that
I presented!

 On Sat 15/12/18 18:01 , Martok list...@martoks-place.de sent:
 Am 15.12.2018 um 17:12 schrieb Florian Klämpfl: 
 > The memory manager itself pools already, so no need for the compiler. If
somebody wants to improve the heap manager: 
 > implement OS supported re-allocations (OS can move memory by just
shuffling pages). 

 Very much agree, it's not a user program's job to work around the standard

 memory manager in daily use. Doing that is a C++-ism that shouldn't exist
in a 
 sane environment ;-) 

 I just tested something, and I'm a surprised by how big the difference is.
This 
 simple test is 1.5 times slower in FPC/trunk/win32 than Delphi 2007 and
2.8 
 times slower for instances of TComponent. Medium-size GetMemory (I tested
123 
 bytes) is 22 times slower in FPC. 
 Looks like there is quite some potential there. 

 const COUNT=1; 
 var 
 t1, t2: dword; 
 objs: array[0..1] of TObject; 
 i, j: integer; 
 begin 
 t1:= Gettickcount; 
 for i := 0 to COUNT - 1 do begin 
 for j := 0 to high(objs) do 
 objs[j]:= TObject.Create; 
 for j := 0 to high(objs) do 
 objs[j].Free; 
 end; 
 t2:= Gettickcount; 

 writeln((t2-t1)/COUNT:10:3, 'ms'); 
 Readln; 
 end. 

 -- 
 Regards, 
 Martok 

 ___ 
 fpc-devel maillist - fpc-devel@lists.freepascal.org [1] 
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 

 

Links:
--
[1] mailto:fpc-devel@lists.freepascal.org
[2] 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] Case block optimisation

[J. Gareth Moreton]

 Hi everyone,

 So here's something else I've been playing with in the interim... I've
been working on improving the algorithms used when compiling case blocks. 
It was driven partly by my binary search idea for certain kinds of case
block, which I wrote up over here:
http://wiki.freepascal.org/Case_Compiler_Optimization [1]

 So far, the binary search is a bit inconclusive on timing improvements, so
I need to work on it a bit more and also write some tests to show correct
operation and timings.

 Nevertheless, find attached a preliminary patch that improves other
aspects of code generation:

 - If a case block only contains one branch (not including the else block),
the initial range check is removed, since this becomes wasted effort.- If
the else block is empty, the else label is set to the end label - though
this doesn't increase the code size, it takes a bit of strain off the
peephole optimizer.
 - On -O2 and above, some node analysis is now done on the branch labels. 
Most of the time this just redirects it to the end label for empty blocks,
but if the block contains a goto statement, it will redirect it to its
destination instead, thus increasing performance by not having multiple
jumps (this won't get picked up by the peephole optimiser if the label
addresses are in a jump table).
 - Some checks now use what I call the 'true count' rather than the 'label
count'.  The true count includes each individual value in a range - for
example, 0..2 counts as 3.
 - For jump tables, if the case block almost covers the entire range (32
entries or fewer from full coverage), the initial range check is removed
and the gaps included in the jump table.

 To give an example as to where these improvements take effect, the
"taicpu.calcsize" method in "/x86/aasmcpu.pas" has a large case block that
analyses the encoding of assembler commands - before, this only became a
linear list because while there are loads of entries, the "labelcnt" value
is still under 64 because a number of values are combined into a range. 
This is now changed to an efficient jump table, and furthermore, it is
almost exhaustive because the input type is a Char, and only a handful of
values redirect to the else block, which raises an internal error.  As a
result, the jump table is changed to contain all 256 possible values (1KB
in size), with addresses to the else block where appropriate.

 The patch doesn't contain the binary search yet, but this algorithm covers
situations that are unsuitable for a jump table, namely the domain is large
but the number of valid blocks is very sparse (for example, if the input
type is a Word, a number of small values are checked, and then it checks
the value 10,000 as well, which sits well beyond any other values).  The
jump tree is still used for excessively-large case blocks.

 I won't consider it ready for patching just yet because I want to create
some more tests first.  Still, what do you think?

 Gareth aka. Kit
 (P.S. I hope the patch isn't too large that it gets flagged for
moderation)
  

Links:
--
[1] http://wiki.freepascal.org/Case_Compiler_Optimization


case-improvement.patch
Description: Binary data
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] x86_64 Optimizer Overhaul

[Martok]

Am 15.12.2018 um 17:12 schrieb Florian Klämpfl:
> The memory manager itself pools already, so no need for the compiler. If 
> somebody wants to improve the heap manager:
> implement OS supported re-allocations (OS can move memory by just shuffling 
> pages).

Very much agree, it's not a user program's job to work around the standard
memory manager in daily use. Doing that is a C++-ism that shouldn't exist in a
sane environment ;-)

I just tested something, and I'm a surprised by how big the difference is. This
simple test is 1.5 times slower in FPC/trunk/win32 than Delphi 2007 and 2.8
times slower for instances of TComponent. Medium-size GetMemory (I tested 123
bytes) is 22 times slower in FPC.
Looks like there is quite some potential there.


const COUNT=1;
var
  t1, t2: dword;
  objs: array[0..1] of TObject;
  i, j: integer;
begin
  t1:= Gettickcount;
  for i := 0 to COUNT - 1 do begin
for j := 0 to high(objs) do
  objs[j]:= TObject.Create;
for j := 0 to high(objs) do
  objs[j].Free;
  end;
  t2:= Gettickcount;

  writeln((t2-t1)/COUNT:10:3, 'ms');
  Readln;
end.

-- 
Regards,
Martok


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

15.12.2018 19:09, wkitt...@windstream.net:

On 12/15/18 10:36 AM, Nikolai Zhubr wrote:

So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?



is this a typo? should it be -CfVPF4_S16 with F and V swapped?


No. From ppcrossarm.exe -i:

Supported FPU instruction sets:
  SOFT,LIBGCC,FPA,FPA10,FPA11,VFPV2,VFPV3,VFPV3_D16,FPV4_S16

(And yes, such kind of abbrevations is always a bit frustrating to type 
and check, although it is obviously not fpc's fault)



Thank you!

Regards,
Nikolai


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

15.12.2018 18:24, Florian Klämpfl:

Now, I'm targeting an A20-olinuxino-micro board, which is afaik armv7a with 
VPFv4. The board is running either openwrt
or opensuse. (And actually, the binaries produced by the pre-built native 
compiler have been tested in both environments
already)

So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?


... and -dFPC_ARMHF. It is more important than the others.


So, apparently most close to success for now was:
CROSSOPT="-CpARMV7A -CfvFPV2 -dFPC_ARMHF"

It successfully produced object files, but ld refsuses to link them. 
Again, the message is:

pp.o uses VFP instructions, whereas .\pp does not
(lots of these repeated)

I'm guessing is that either some option is missing for ld to actually 
accept that VFP is present, or rather I need to rebuild my binutils for 
a different (hard fp) target?


(The exact call that fails now is arm-linux-ld.exe -s -L. -o .\pp 
.\link.res)



Thank you!

Regards,
Nikolai





___
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] x86_64 Optimizer Overhaul

[J. Gareth Moreton]

 Ah right, so things like "TmpUsedRegs" (an array of TUsedRegs) constantly
being created and destroyed in the peephole optimizer is actually not that
much of a penalty hit, and creating a pooled object for continuous use
doesn't give that much of a performance gain?

 Gareth

 On Sat 15/12/18 16:12 , Florian Klämpfl flor...@freepascal.org sent:
 Am 12.12.2018 um 13:49 schrieb Ryan Joseph: 
 > 
 > 
 >> On Dec 12, 2018, at 7:20 PM, Martok  wrote: 
 >> 
 >> Checking out the memory manager(s) could be useful as well - there are
a lot of 
 >> small allocations, that generally tends to put much stress on it. 
 >> And any improvement there would also directly benefit user
applications. 
 > 
 > I was going to say the same thing myself and even planned to do a test.
My profiles show the top hits being getmem/freemem which really don’t
need to be there. 
 > 
 > There’s no reason to be allocating and freeing nodes (for example)
over and over again when we could just allocate a large pool at startup and
return to the pool instead of freeing. It would make the compiler utilize
more memory but that’s a good trade off for me personally. This is
especially a good idea because the compiler is a one pass program so leaks
over the long term aren’t a problem. 

 The memory manager itself pools already, so no need for the compiler. If
somebody wants to improve the heap manager: 
 implement OS supported re-allocations (OS can move memory by just
shuffling pages). 
 ___ 
 fpc-devel maillist - fpc-devel@lists.freepascal.org [2] 
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[3]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 

 

Links:
--
[1] mailto:list...@martoks-place.de
[2] mailto:fpc-devel@lists.freepascal.org
[3] 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] x86_64 Optimizer Overhaul

[Florian Klämpfl]

Am 12.12.2018 um 13:49 schrieb Ryan Joseph:
> 
> 
>> On Dec 12, 2018, at 7:20 PM, Martok  wrote:
>>
>> Checking out the memory manager(s) could be useful as well - there are a lot 
>> of
>> small allocations, that generally tends to put much stress on it.
>> And any improvement there would also directly benefit user applications.
> 
> I was going to say the same thing myself and even planned to do a test. My 
> profiles show the top hits being getmem/freemem which really don’t need to be 
> there.
> 
> There’s no reason to be allocating and freeing nodes (for example) over and 
> over again when we could just allocate a large pool at startup and return to 
> the pool instead of freeing. It would make the compiler utilize more memory 
> but that’s a good trade off for me personally. This is especially a good idea 
> because the compiler is a one pass program so leaks over the long term aren’t 
> a problem.

The memory manager itself pools already, so no need for the compiler. If 
somebody wants to improve the heap manager:
implement OS supported re-allocations (OS can move memory by just shuffling 
pages).
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[wkitty42]

On 12/15/18 10:36 AM, Nikolai Zhubr wrote:

So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?



is this a typo? should it be -CfVPF4_S16 with F and V swapped?


--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Florian Klämpfl]

Am 15.12.2018 um 16:36 schrieb Nikolai Zhubr:
>> There is no single ARM/Linux platform, but many different incompatible
>> ones (which is one of the reasons there are no provided FPC
>> cross-compilers for this "platform".
> 
> Right, this is what I overlooked indeed (Well, because a pre-built native 
> compiler for ARM did work successfully out of
> the box, producing perfectly usable arm binaries for me)
> 
> Now, I'm targeting an A20-olinuxino-micro board, which is afaik armv7a with 
> VPFv4. The board is running either openwrt
> or opensuse. (And actually, the binaries produced by the pre-built native 
> compiler have been tested in both environments
> already)
> 
> So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?

... and -dFPC_ARMHF. It is more important than the others.



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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

15.12.2018 17:38, Jonas Maebe:

T:\...3.0.4\fpcsrc\rtl\units\arm-linux>arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

I suspect this is an inintended flag set by my arm-linux-as.exe for
some reason... Probably have to get rid of it somehow...


It would be useful to know on which ARM/Linux platform you want to run
your code (board/processor, and if it's an ancient board and/or kernel,
whether it's ARMEL/EABI or not), and which command line options you are
using to build FPC.

There is no single ARM/Linux platform, but many different incompatible
ones (which is one of the reasons there are no provided FPC
cross-compilers for this "platform".


Right, this is what I overlooked indeed (Well, because a pre-built 
native compiler for ARM did work successfully out of the box, producing 
perfectly usable arm binaries for me)


Now, I'm targeting an A20-olinuxino-micro board, which is afaik armv7a 
with VPFv4. The board is running either openwrt or opensuse. (And 
actually, the binaries produced by the pre-built native compiler have 
been tested in both environments already)


So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?
If I use it, I get the following errors:

T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s: Assembler 
messages:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:12587: Error: 
selected processor does not support `rfs r0' in ARM mode
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:12590: Error: 
selected processor does not support `wfs r0' in ARM mode
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:19745: Error: 
selected processor does not support `fcpyd d0,d1' in ARM mode
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:19746: Error: 
selected processor does not support `fcpyd d1,d0' in ARM mode

system.pp(379) Error: Error while assembling exitcode 1


Thank you!

Regards,
Nikolai




Jonas
___
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] Building cross-compiler for arm-linux on win32

[wkitty42]

On 12/15/18 9:29 AM, Nikolai Zhubr wrote:
I suspect this is an inintended flag set by my arm-linux-as.exe for some 
reason... Probably have to get rid of it somehow...



so the real questions are:

  1. is this flag being set erroneously?
  2. are the .o files being built properly?
  3. should ./pp (and others?) be rebuilt so that it does
 use/allow VFP instructions to be used?



--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Jonas Maebe]

On 15/12/18 15:29, Nikolai Zhubr wrote:

15.12.2018 16:58, I wrote:

C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o uses VFP
instructions, whereas .\pp does not
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: failed to merge target
specific data of file


Hm, indeed, objdump confirms this VFP thing:

T:\...3.0.4\fpcsrc\rtl\units\arm-linux>arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

I suspect this is an inintended flag set by my arm-linux-as.exe for some 
reason... Probably have to get rid of it somehow...


It would be useful to know on which ARM/Linux platform you want to run 
your code (board/processor, and if it's an ancient board and/or kernel, 
whether it's ARMEL/EABI or not), and which command line options you are 
using to build FPC.


There is no single ARM/Linux platform, but many different incompatible 
ones (which is one of the reasons there are no provided FPC 
cross-compilers for this "platform".



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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

15.12.2018 16:58, I wrote:

C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o uses VFP
instructions, whereas .\pp does not
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: failed to merge target
specific data of file


Hm, indeed, objdump confirms this VFP thing:

T:\...3.0.4\fpcsrc\rtl\units\arm-linux>arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

I suspect this is an inintended flag set by my arm-linux-as.exe for some 
reason... Probably have to get rid of it somehow...



Thank you!

Regards,
Nikolai



T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\objpas.o uses VFP
instructions, whereas .\pp does not
. [lots of similar lines follow]

Any ideas?

Thank you!

Regards,
Nikolai


15.12.2018 3:24, I wrote:

Hi all,

I'm trying to build a cross-compiler for arm-linux target on a win32
host. It fails at assembling system.s (produced from system.pp) with the
following output:

T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s: Assembler
messages:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11309: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11334: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11360: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11387: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:13271: Error:
garbage following instruction -- `ldrd r0,r1,[r0]'
make.EXE[6]: *** [system.ppu] Error 1

I'm using arm-linux-as.exe from the recommended
binutils-2.15.94-win32-arm-linux.zip package downloaded from fpc
download area:

arm-linux-as --version
GNU assembler 2.15.94 20050202
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of the GNU General Public License. This program has absolutely no
warranty.
This assembler was configured for a target of `arm-linux-elf'.

What could be the reason for these errors?


Thank you!

Regards,
Nikolai
___
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] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi all,

Ok, apparently the binutils-2.15.94-win32-arm-linux.zip (provided on the 
fpc website) is somewhat outdated to be really usable for arm target.
Retrying with (self-built) binutils-2.28 apparently solves the previous 
problem but now I have another: ld yells something about VFP instructions:


T:/_tmp/fpcbuild-3.0.4/fpcsrc/compiler/ppcrossarm.exe -Tlinux -Parm 
-XParm-linux- -Xr -Ur -Xs -O2 -n -Fuarm -Fusystems 
-FuT:/_tmp/fpcbuild-3.0.4/fpcsrc/rtl/units/arm-linux -Fiarm -FE. 
-FUarm/units/arm-linux -dRELEASE -darm -dGDB -dBROWSERLOG -Sew-darm 
-dGDB -dBROWSERLOG  -Sew pp.pas
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: warning: .\link.res 
contains output sections; did you forget -T?
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error: 
arm\units\arm-linux\pp.o uses VFP instructions, whereas .\pp does not
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: failed to merge target 
specific data of file arm\units\arm-linux\pp.o
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error: 
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o uses VFP 
instructions, whereas .\pp does not
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: failed to merge target 
specific data of file 
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error: 
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\objpas.o uses VFP 
instructions, whereas .\pp does not

. [lots of similar lines follow]

Any ideas?

Thank you!

Regards,
Nikolai


15.12.2018 3:24, I wrote:

Hi all,

I'm trying to build a cross-compiler for arm-linux target on a win32
host. It fails at assembling system.s (produced from system.pp) with the
following output:

T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s: Assembler
messages:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11309: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11334: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11360: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11387: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:13271: Error:
garbage following instruction -- `ldrd r0,r1,[r0]'
make.EXE[6]: *** [system.ppu] Error 1

I'm using arm-linux-as.exe from the recommended
binutils-2.15.94-win32-arm-linux.zip package downloaded from fpc
download area:

arm-linux-as --version
GNU assembler 2.15.94 20050202
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of the GNU General Public License. This program has absolutely no warranty.
This assembler was configured for a target of `arm-linux-elf'.

What could be the reason for these errors?


Thank you!

Regards,
Nikolai
___
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