2012/10/2 Jeppe Græsdal Johansen jjoha...@student.aau.dk
Integer is not a specifically sized type. It might differ based on what
platform you are on. For example, it's 16bit on i386-linux when compiled
with mode fpc. With mode objfpc on the same platform it's 32bit.
The code is compiled
Hi,
03.10.2012 5:29, luiz americo pereira camara:
[...]
The complete procedure:
{$ASMMODE INTEL}
procedure AlphaBlendLineConstant(Source, Destination: Pointer; Count:
Integer; ConstantAlpha, Bias: Integer);
asm
{$ifdef CPU64}
// RCX contains Source
// RDX contains Destination
// R8D contains
It depends on the compiler mode, not the platform - at least according
to the docs in http://www.freepascal.org/docs-html/ref/refsu5.html:
---
The integer type maps to the smallint type in the default Free Pascal
mode. It maps to either a longint in either Delphi or ObjFPC mode. The
cardinal type
Hello, FPC developers' list.
What should MemSize function do? Should it return the same info for
statically allocated memory?
I don't see any documentation on MemSize function here:
http://freepascal.org/docs-html/rtl/system/memoryfunctions.html
So I decided to test it since we rely on it
On 03 Oct 2012, at 03:29, luiz americo pereira camara wrote:
I'm porting some Delphi assembly code.
It worked fine with fpc 2.6.0 i386-64bit windows compiler
When i tried the same code with fpc 2.6.0 i386-64bit for linux it
failed to
compile with the following error:
Error: Asm: 16 or 32
Hello,
I am trying to compile for hardfloat.
When passing floats as parameters to a C-library function call,
I get incorrect values inside the library.
Both for singles as doubles.
If I write the same call to the c-library in c,
I get assembler like
call function test_param (int, single,
2012/10/3 Jonas Maebe jonas.ma...@elis.ugent.be
On 03 Oct 2012, at 03:29, luiz americo pereira camara wrote:
at the line
// Load XMM5 with the bias value.
MOVDXMM5, [Bias] //Bias = Integer
Is it a know issue or a limitation of linux version?
Win64 uses a
2012/10/4 luiz americo pereira camara luiz...@oi.com.br
2012/10/3 Jonas Maebe jonas.ma...@elis.ugent.be
On 03 Oct 2012, at 03:29, luiz americo pereira camara wrote:
at the line
// Load XMM5 with the bias value.
MOVDXMM5, [Bias] //Bias = Integer
Is it a know
On 03 Oct 2012, at 10:15, Paul Ishenin wrote:
What should MemSize function do? Should it return the same info for
statically allocated memory?
For statically allocated memory it will work just as badly as freemem
and reallocmem.
Jonas___
On 03 Oct 2012, at 23:39, Den Jean wrote:
I am trying to compile for hardfloat.
The problem is that you are not compiling for hardfloat.
Pascal compiler options like
fpc -Aas -O- -CfVFPv3 -Cparmv7 -CaEABI pmain.pp
or
fpc -Aas -dFPC_ARMEL -O- -dFPC_ABI_EABI -CfVFPv3 -Cparmv7 -CaEABI
Hello,
The hard float abi is not supported in fixes_2_6, and probably never
will be. Additionally, you cannot compile programs for the hard
float abi using a regular eabi compiler. You have to compile the ARM
compiler with -dFPC_ARMHF.
I tried fixes_2_6 first as the idea was to use lazarus Qt
On 04 Oct 2012, at 15:31, den.j...@telenet.be wrote:
But when I do
make crosszipinstall it gives me a cross ppcrossarm (i386 executable)
and arm rtl/packages.
How can I generate a corresponding (to arm rtl/packages) ppcarm (arm
executable)
from i386 so that i can copy over a full fpc
Hi,
After the crosszipinstall, compiler/ppcarm (not installed, but in the
source directory) is the native ARM compiler.
I looked there with `file pp* `
How could I have missed that ?
Thanks for the quick responses.
Kind regards,
Den Jean
___
On Thursday 04 October 2012 16:23:34 den.j...@telenet.be wrote:
After the crosszipinstall, compiler/ppcarm (not installed, but in the
source directory) is the native ARM compiler.
I looked there with `file pp* `
How could I have missed that ?
Well I could check now and it is not there
Am 04.10.2012 19:42, schrieb Den Jean:
On Thursday 04 October 2012 16:23:34 den.j...@telenet.be wrote:
After the crosszipinstall, compiler/ppcarm (not installed, but in the
source directory) is the native ARM compiler.
I looked there with `file pp* `
How could I have missed that ?
Well I
On Thursday 04 October 2012 20:40:23 Florian Klämpfl wrote:
At least -dFPC_ARMHF shouldn't be a cross opt.
Thx for the info
extracts Makefile.fpc:
snip
#
# Cycle targets
snip
# 3. Source CPU Target CPU
#First source native
Hi,
On Thu, 2012-10-04 at 19:42 +0200, Den Jean wrote:
On Thursday 04 October 2012 16:23:34 den.j...@telenet.be wrote:
After the crosszipinstall, compiler/ppcarm (not installed, but in the
source directory) is the native ARM compiler.
I looked there with `file pp* `
How could I have
On Thursday 04 October 2012 21:09:55 Thomas Schatzl wrote:
I put an armhf snapshot from today at
http://members.yline.com/~tom_at_work/fpc-2.7.1.arm-linux.tar.gz . I
I was going to do the same thing :-)
Do you have more experiemce with fpc and armhf, any problems
you are aware of?
will see if
Hi,
On Thu, 2012-10-04 at 21:30 +0200, Den Jean wrote:
On Thursday 04 October 2012 21:09:55 Thomas Schatzl wrote:
I put an armhf snapshot from today at
http://members.yline.com/~tom_at_work/fpc-2.7.1.arm-linux.tar.gz .
I was going to do the same thing :-)
Do you have more experiemce with
On 04.10.2012 21:04, Den Jean wrote:
On Thursday 04 October 2012 20:40:23 Florian Klämpfl wrote:
At least -dFPC_ARMHF shouldn't be a cross opt.
Thx for the info
extracts Makefile.fpc:
snip
#
# Cycle targets
snip
# 3. Source
On Thursday 04 October 2012 21:54:19 Thomas Schatzl wrote:
Basically the difference between armel and armhf are
- fpc cannot create valid armhf shared libraries
Other problems common to both (just from interpreting the testsuite
results, filtering known failing tests):
- there are
Den Jean wrote:
On Thursday 04 October 2012 21:54:19 Thomas Schatzl wrote:
Basically the difference between armel and armhf are
- fpc cannot create valid armhf shared libraries
Other problems common to both (just from interpreting the testsuite
results, filtering known failing tests):
-
On Thursday 04 October 2012 21:54:19 Thomas Schatzl wrote:
Yes. Probably one of the first milestones for a new arch is self-hosting
(if possible at all).
Ahum it always fails over here
time make OPT='-dFPC_ARMHF -Aas -O- -CaEABIHF -CfVFPV3_D16 -Cparmv7a' clean
all
Hi,
On Thu, 2012-10-04 at 22:51 +0200, Den Jean wrote:
On Thursday 04 October 2012 21:54:19 Thomas Schatzl wrote:
Yes. Probably one of the first milestones for a new arch is self-hosting
(if possible at all).
Ahum it always fails over here
time make OPT='-dFPC_ARMHF -Aas -O- -CaEABIHF
Hi,
On Thu, 2012-10-04 at 23:18 +0200, Thomas Schatzl wrote:
Hi,
On Thu, 2012-10-04 at 22:51 +0200, Den Jean wrote:
Ahum it always fails over here
time make OPT='-dFPC_ARMHF -Aas -O- -CaEABIHF -CfVFPV3_D16 -Cparmv7a' clean
all
units_bs/arm-linux/fpmkunit.s:28079: Rd and Rm
On Thursday 04 October 2012 23:18:43 Thomas Schatzl wrote:
Just checked, processor info (-Cparmv7a) is not passed to the assembler.
Try -Cparmv7 - only then --march=armv7-a is passed correctly
yep.
but make still fails
/home/jan/svn/fpc/compiler/ppcarm src/fpmkunit.pp -n
Hi,
On Thu, 2012-10-04 at 23:55 +0200, Den Jean wrote:
On Thursday 04 October 2012 23:18:43 Thomas Schatzl wrote:
Just checked, processor info (-Cparmv7a) is not passed to the assembler.
Try -Cparmv7 - only then --march=armv7-a is passed correctly
yep.
but make still fails
Tried again,
On Friday 05 October 2012 00:12:46 Thomas Schatzl wrote:
Let's start from the beginning. What's your starting compiler? 2.7.0 I
guess? (which is the only option anyway for hardfloat).
on i386 i used cross binutils from fedora packages
cross-binutils-common.noarch 2.22.52.0.3-1.fc17
On Friday 05 October 2012 00:12:46 Thomas Schatzl wrote:
(note the additional -s param) and paste the resulting ppas.bat after
it fails here? The line that invokes gas should use the correct gas. And
it should have a correct --march=armv7-a parameter.
$ cat ppas.sh
#!/bin/sh
DoExitAsm ()
{
29 matches
Mail list logo
