Jonas Maebe wrote:
On 13 Oct 2010, at 09:58, Sven Barth wrote:
Am 05.10.2010 10:13, schrieb Jonas Maebe:
A couple of days ago I fixed an error in svn trunk for ARMEL that caused
the stack to become temporarily unbalanced after performing syscalls
with 5 or more parameters (the bug is still t
Henry Vermaak wrote:
On 20/01/11 08:20, Michael Schnell wrote:
On 01/19/2011 05:13 PM, Henry Vermaak wrote:
it's really expensive to trap the illegal instructions and emulate them.
AFAIK, the trapping is done by the ARM CPU, anyway, providing the
emulation functions just costs some memory, bu
Hello,
I am running the test suite with remote execution (from a Windows host)
on an ARM-Linux target. Some test programs fail at runtime, because they
depend on libraries, which were not automatically copied to the target.
For example:
Failed to run test/tlib1b.pp 2011/01/21 18:06:08 (16
Jonas Maebe wrote:
On 23 May 2011, at 11:49, Bernd Mueller wrote:
I am running the test suite with remote execution (from a Windows
host) on an ARM-Linux target. Some test programs fail at runtime,
because they depend on libraries, which were not automatically copied
to the target. For
Jonas Maebe wrote:
On 27 May 2011, at 14:56, Bernd Mueller wrote:
If you think, this patch could be the right way to copy the libraries,
I would submit a second patch which expands all required %needlibrary
directives.
Isn't it easier to simply copy all compiled libraries to the t
Jonas Maebe wrote:
Isn't it easier to simply copy all compiled libraries to the target when
they are compiled (just like compiled test programs are copied)?
this second approach (which works well for me) copies the libraries when
the are compiled. No need to expand the %needlibrary directive
Jonas Maebe wrote:
On 30 May 2011, at 11:04, Bernd Mueller wrote:
Jonas Maebe wrote:
Isn't it easier to simply copy all compiled libraries to the target
when they are compiled (just like compiled test programs are copied)?
this second approach (which works well for me) copie
Jonas Maebe wrote:
On 30 May 2011, at 11:19, Bernd Mueller wrote:
Jonas Maebe wrote:
Why do you limit it to Linux targets?
I am not sure about the other targets.
LibraryFileName:= 'lib' +
ForceExtension(SplitFileName(PPFile[current]), 'so');
The above code builds
Pierre Free Pascal wrote:
Just add a LibExt constant to dotest.pp source
with the same conditionals as for ExeExt, this should be enough.
const
ObjExt='o';
PPUExt='ppu';
{$ifdef UNIX}
ExeExt='';
LibExt='so';
{$else UNIX}
{$ifdef MACOS}
ExeExt='';
LibExt='so';
{$else MACOS}
Ex
Jonas Maebe wrote:
Maybe better would be to hardcode .so for Linux and FreeBSD, and use
dynlibs.SharedSuffix for all other targets.
maybe I am missing something, but wouldn't dynlibs.SharedSuffix retrieve
the library suffix for the host? So, when I am crosscompiling from
Windows, I would ge
Jonas Maebe wrote:
...So it's just a stopgap solution for them until they have time to build their
own ARM compiler...
wow! The former state of the art compiler vendor
(Borland/Inprise/Borland/Codegear/Emb...) is not able to produce a
compiler of its own ;-)
Regards, Bernd.
__
Graeme Geldenhuys wrote:
On 7 August 2011 17:29, Jonas Maebe wrote:
Going from a completely i386-specific code generator to an ARM
code generator is a lot of work, especially if you at the same time
also have to create a 64 bit code generator.
Maybe they should just call it quits on there comp
Hello,
can someone please provide an example, how interrupt handling for
STM32F1x is done with fpc? I would like to see how an I/O signal may
trigger an (interrupt) procedure. Thanks.
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.freepa
Thomas Schatzl wrote:
http://packages.debian.org/squeeze/armel/fp-compiler/download ->
http://ftp.de.debian.org/debian/pool/main/f/fpc/fp-compiler_2.4.0-2_armel.deb
so I supposed it would contain the necessary stuff for all supported
flavors. But maybe I did not look hard enough.
Armel mea
Paul Ishenin wrote:
I remember author of Total Commander who had failed to port his project
to FPC + Laz because of many incompatilities in both projects.
IMHO, you are not right. the 64-bit version seems to be written in
FPC/Lazarus:
The string "FPC 2.5.1 [2011/12/03] for x86_64 - Win64"
Michael Ring wrote:
Could it be acceptable to change behaviour of the Code-Generator when
compiling for arm-embedded? (or by implementing {$bitaccesssize 4},
which looks like a nice syntax for this to me)?
What I have in Mind is that arm seems to support unaligned access, so it
might for a
On 05/01/2017 11:36 AM, Michael Van Canneyt wrote:
Only 3.0.2 linux for i386 CPU has the problem. 64-bit is OK.
hmm, I don't get the lineinfo on x86-64 (Ubuntu 16.04/Mate, 64-Bit).
armel and armhf are affected too.
Regards, Bernd.
___
fpc-devel m
On 05/01/2017 02:34 PM, Marco van de Voort wrote:
In our previous episode, Bernd Mueller said:
Only 3.0.2 linux for i386 CPU has the problem. 64-bit is OK.
hmm, I don't get the lineinfo on x86-64 (Ubuntu 16.04/Mate, 64-Bit).
armel and armhf are affected too.
Please test with the
Felipe Monteiro de Carvalho wrote:
Acording to the nokia wiki using thumb would be produce smaller and
faster code on the majority of mobiles, so it may be useful to see of
just for more information:
"The Thumb code requires 70 % of space of the ARM code.
The Thumb code uses 40 % more instru
Vincent Snijders wrote:
Instead of testing for arm cpu, you could use
FPC_REQUIRES_PROPER_ALIGNMENT too. So it is fixed for sparc as well.
yes, the changed patch is attached.
Regards, Bernd.
Index: packages/graph/src/inc/gtext.inc
Hello,
the attached patch avoids misaligned data access (bus errors), during
font rendering (with the graph unit) on Arm-Linux devices.
Regards, Bernd.
Index: packages/graph/src/inc/gtext.inc
===
--- packages/graph/src/inc/gtext.i
Daniël Mantione wrote:
Op Tue, 26 Feb 2008, schreef Florian Klaempfl:
Daniël Mantione schrieb:
Op Tue, 26 Feb 2008, schreef Vincent Snijders:
Bernd Mueller schreef:
Hello,
the attached patch avoids misaligned data access (bus errors), during
font rendering (with the graph unit) on Arm
Daniël Mantione wrote:
Op Tue, 26 Feb 2008, schreef Bernd Mueller:
Daniël Mantione wrote:
Op Tue, 26 Feb 2008, schreef Florian Klaempfl:
Daniël Mantione schrieb:
Op Tue, 26 Feb 2008, schreef Vincent Snijders:
Bernd Mueller schreef:
Hello,
the attached patch avoids misaligned data
Bernd Mueller wrote:
(very unexpected) result of this benchmark is, that a version with
leaving the TStroke-Record packed, is about 13 % faster than the
original patch. I am going to send a new patch soon.
unfortunately this one is about 10 % slower on X86. So, I am going to
leave this to
Hello,
the ARMv5 runtime detection in rtl/arm/arm.inc fails, because the used
pld instruction does not raise SIGILL on ARM architectures ARMv4 and
below. If you would use an instruction which raises a SIGILL, it would
still fail, because SignalToRunerror in rtl/linux/arm/sighnd.inc does
not r
Florian Klaempfl wrote:
Bernd Mueller schrieb:
Hello,
the ARMv5 runtime detection in rtl/arm/arm.inc fails, because the used
pld instruction does not raise SIGILL on ARM architectures ARMv4 and
below. If you would use an instruction which raises a SIGILL, it would
still fail, because
Florian Klaempfl wrote:
CPUs supporting CLZ might not support PLD. Can you test if using ldrd works?
yes, ldrd works.
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Florian Klaempfl wrote:
Bernd Mueller schrieb:
Florian Klaempfl wrote:
CPUs supporting CLZ might not support PLD. Can you test if using ldrd
works?
yes, ldrd works.
Ok, my question was not very good ;) I meant, can we use ldrd, i.e. does
ldrd cause a sigill exception on ARMv4?
:-)
I
Florian Klaempfl wrote:
I commited a fix in 10458. I tried to fix SignalToRunerror without
assembler, maybe it works.
yes it works, thanks.
You chose ldrd r0, [sp] to force the SIGILL on ARMv4. According to the
docs the load address has to be double word (8 byte) aligned, otherwise
a Bus Er
Dave Parsons wrote:
Has anyone seen this before?
may be it is related to
http://bugs.freepascal.org/view.php?id=10873
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Hello,
the attached patch improves the performance of the rtl Move_blended
procedure by about 16 % on ARMv4, when both destination and source
addresses are aligned. I rearranged the code and could remove one
instruction of the inner loop 'Ldwordloop'. I think the patch should
work for the Mov
Bernd Mueller wrote:
You chose ldrd r0, [sp] to force the SIGILL on ARMv4. According to the
docs the load address has to be double word (8 byte) aligned, otherwise
a Bus Error/Misaligned data access Error on ARMv5 would occur. Is it
save to use sp in your way?
ok, it does not work. This is
Micha Nelissen wrote:
Bernd Mueller wrote:
ok, it does not work. This is what I guessed. But I am in doubt about
your current fix:
asm
bic r0,sp,#7
ldrd r0,[r0]
end;
r0 is double word (8 byte) aligned now, but does it always point to a
valid memory location? IMHO something like
Florian Klaempfl wrote:
Does the ARM ABI require that the stack is aligned to 8 byte boundaries?
Sorry, I don't know.
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Hello,
The ARMv5 runtime detection is fixed in fpc 2.3.1. Could you please
apply this fix to fpc 2.2.1 too? The procedure fpc_cpucodeinit in
rtl/arm/arm.inc is affected.
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http:
Yury Sidorov wrote:
From: "Bernd Mueller" <[EMAIL PROTECTED]>
Hello,
The ARMv5 runtime detection is fixed in fpc 2.3.1. Could you please
apply this fix to fpc 2.2.1 too? The procedure fpc_cpucodeinit in
rtl/arm/arm.inc is affected.
I merged it to 2.2.1
thank you.
Hello,
The compiler message "PPU Invalid Version n" should be made a fatal
error. This would help Lazarus to display the real problem (wrong ppu
version), instead of displaying the error Massage "Fatal: Can't find
unit x", which is misleading in this case.
Regards, Bernd.
Index: compiler/ms
Florian Klaempfl wrote:
Bernd Mueller schrieb:
Hello,
The compiler message "PPU Invalid Version n" should be made a fatal
error. This would help Lazarus to display the real problem (wrong ppu
version), instead of displaying the error Massage "Fatal: Can't find
unit x&q
Bernd Mueller wrote:
Florian Klaempfl wrote:
Bernd Mueller schrieb:
Hello,
The compiler message "PPU Invalid Version n" should be made a fatal
error. This would help Lazarus to display the real problem (wrong ppu
version), instead of displaying the error Massage "Fatal: Can
Florian Klaempfl wrote:
Bernd Mueller schrieb:
Hello,
I am trying hard to avoid C on an ARM7TDMI/ARMv4T Controller
(AT91SAM7Sx) ;-)
What about simply supporting the interrupt keyword on arm? Point me to
some description and I'll implement it.
That would be great. I have got the inform
Florian Klaempfl wrote:
Bernd Mueller schrieb:
Hello,
I am trying hard to avoid C on an ARM7TDMI/ARMv4T Controller
(AT91SAM7Sx) ;-)
What about simply supporting the interrupt keyword on arm? Point me to
some description and I'll implement it.
I searched the web for some details:
Michael Schnell wrote:
This is why I decided to handle this kind of complexity with an FPGA
with embedded (Linux-) Processor.
which system/vendor did you choose?
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://list
Marco van de Voort wrote:
In our previous episode, Bernd Mueller said:
Marco van de Voort wrote:
So the main reason for using HW as much as possible is to keep the actual uc
free as much as possible for other tasks.
yes, this is why I consider to use an ARM7 controller "in front of"
Michael Schnell wrote:
How much do you need on a PIC ?
I did not have many hope for really using Pascal on the PIC, but I am
just thinking about a project with a PIC24 (which is a quite normal 16
bit processor core with 64K linear addressable memory (completely
integrated in the chip), ot
Marco van de Voort wrote:
So the main reason for using HW as much as possible is to keep the actual uc
free as much as possible for other tasks.
yes, this is why I consider to use an ARM7 controller "in front of" an
ARM9 (Linux) controller, although the ARM9 should have the power to
handle
Unicode support in FPC?
Sorry for jumping in. I am not so much interested in Unicode because I
mostly use shortstrings and ansistrings for performance reasons. But may
be it is worth to look how the gcc people have solved these issues.
Regards, Bernd.
_
Felipe Monteiro de Carvalho wrote:
I would like to hear of others actually have a better proposal for Lazarus.
sorry, I have no idea since I am doing primarily embedded stuff. Speed
and backward compatibility are the most important factors to me.
But it seems, that not everybody is happy wi
Hello,
I am just curious how fpc 2.2.4 could be build by fpc 2.2.2? fpc 2.2.4
depends on Sysutils/ExeSearch which seems to be introduced with 2.2.4.
Easy to fix, but I am wondering how this could happen.
Regards, Bernd.
___
fpc-devel maillist - f
Mattias Gaertner wrote:
Has someone tested threads under windows 64bit W7_64bit ?
See this bug report:
http://bugs.freepascal.org/view.php?id=14389
I guess the problem is not special to W7_64-bit. Windows 98 as well as
Windows 2000 are running the threads sequential on my single cpu
machine.
oc...@pocketmt.com wrote:
Just a question Florian,
C offers the "volatile" attribute to mention that a variable can change
value without source code intervention (for example a variable that maps
to a port register).
I had all sort of troubles with gcc aggressive optimizations. Two years
ago,
Florian Klaempfl wrote:
Just wanted to ask another question:
is there any support for interrupt procedures?
It is implemented for DOS/go32v2.
how to declare a proc as an
interrupt and associate it to its vector?
Not yet, but my processor specific units declare callbacks/hooks.
is that i
Florian Klaempfl wrote:
Bernd Mueller schrieb:
Florian Klaempfl wrote:
Just wanted to ask another question:
is there any support for interrupt procedures?
It is implemented for DOS/go32v2.
how to declare a proc as an
interrupt and associate it to its vector?
Not yet, but my processor
Carsten Bager wrote:
I have a problem with the new 240 compiler.
I get errors when calling functions in the sysutils unit.
I have tested the 251 compiler, and it was exactly the same.
I am normally using the 224 compiler, and it works fine.
[...]
program hw1;
uses
sysutils;
Type
Datetime_
Bernd Mueller wrote:
I can confirm, that the program crashes on ARM-Linux/OABI/FPA/uClibc
compiled with fpc 2.4.0. I think the problem is related to floating
point, since an ordinary "writeln(1 / 3);" crashes the machine too.
my next guess is, that the 2.4.0 compiler ha
Jonas Maebe wrote:
On 22 Feb 2010, at 18:02, Bernd Mueller wrote:
The program runs fine, if the optimization is disabled.
The problem is that none of the compiler developers has a system to practically
test FPA support, so it does not get tested at all...
Would armel/EABI be the better
Jonas Maebe wrote:
On 23 Feb 2010, at 11:31, Bernd Mueller wrote:
Would it help, to upload the fpc test suite results?
Definitely! Especially if you could do that daily, so that it is clear
when things get broken.
I compiled the fpc 2.4.0 RTL with -O0 and run the test suite with -00
Hello,
I get a bus error in fpc_PopAddrStack (on ARM-Linux) in a multithreaded
application. Maybe, that the local Pointer hp in fpc_PopAddrStack is
loaded with an unaligned memory address.
The role of fpc_PopAddrStack is not clear to me. Does it mean, that an
exception occurred somewhere and
Jonas Maebe wrote:
On 13 May 2010, at 17:55, Bernd Mueller wrote:
I get a bus error in fpc_PopAddrStack (on ARM-Linux) in a multithreaded
application. Maybe, that the local Pointer hp in fpc_PopAddrStack is loaded
with an unaligned memory address.
The most likely reason is that you are at
Michael Schnell wrote:
On 06/23/2010 04:49 PM, Henry Vermaak wrote:
No, SWP is atomic, so the implementation looks good (at a glance).
Seemingly not on all ARM sub-archs:
>From some ARM manual:
The ARM7500FE does not use the lock feature available in the ARM701
macrocell
You must
Michael Schnell wrote:
- the code for the old sub-arch is not very good (and it can't be good,
as here Kernel-help is necessary):
[...]
- it might fail as it's not granted that all ARMv5 chips have a
correct implementation of the atomicness of the swap instruction
which affected chips
Hans-Peter Diettrich wrote:
Jeppe Johansen schrieb:
I think that'll only complicate things. I think the compiler should be
able to do anything, down to lowest level. Just like you have CLI,
HLT, FXSTOR, WRMSR, etc instruction support in x86
Then many users will wonder why their application wi
Michael Schnell wrote:
On 07/14/2010 11:02 AM, Bernd Mueller wrote:
... which could easily be done in gcc btw. ...
I'm quite sure that FPC's ASM can compile hex constants (using "DC" ???)
that is not the point. You don't wont to bother with (error prone) hex
const
Hans-Peter Diettrich wrote:
Bernd Mueller schrieb:
Users, who do embedded stuff (without OS) NEED FULL control over the
controller. I agree with Jeppe, that the compiler should not restrict
something.
In this case I don't understand how FPC is useful at all. I cannot
create execu
Joost van der Sluis wrote:
Helping us to test version 2.1.4 now, can avoid problems when you
finally update your fpc-version to 2.2.0.
there seems to be a problem, when the archive bit of a unit source file
is reset. I am running on Windows 98 SE and I am testing the ARM-Linux
compiler. Other
Bernd Mueller wrote:
there seems to be a problem, when the archive bit of a unit source file
is reset. I am running on Windows 98 SE and I am testing the ARM-Linux
compiler. Other platforms should be affected too.
The compiler does not find the unit, if the archive bit is reset:
"
Bernd Mueller wrote:
there seems to be a problem, when the archive bit of a unit source file
is reset. I am running on Windows 98 SE and I am testing the ARM-Linux
compiler. Other platforms should be affected too.
The compiler does not find the unit, if the archive bit is reset:
"Fatal:
Andrew Haines wrote:
Please let me know if this file works for you.
works on Windows 98 SE.
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Felipe Monteiro de Carvalho wrote:
On 7/4/07, Martin Schreiber <[EMAIL PROTECTED]> wrote:
Compile time FPC: 17.9s Delphi: 1.28s
Exe size FPC: 2.27MB Delphi: 1.87MB
Contrary to most others, my analysis is the following:
It's really great that fpc now generates binaries of competitive size
with
Hello,
can anyone please tell me, how to compile the RTL for ARM-Linux since
revision 8006?
I tried to verify the bug fix 8967 (thank you Yury Sidorov) on my
system, but I am not able to compile the RTL anymore.
Adding the -Sg switch seems to be required to compile softfpu, but I get
now:
Yury Sidorov wrote:
From: "Bernd Mueller" <[EMAIL PROTECTED]>
Hello,
can anyone please tell me, how to compile the RTL for ARM-Linux since
revision 8006?
I tried to verify the bug fix 8967 (thank you Yury Sidorov) on my
system, but I am not able to compile the RTL anymore
Marco van de Voort wrote:
So far, I used following make call:
make CPU_TAGET=arm OS_TARGET=linux PP=ppcrossarm OPT="-Tlinux -CX -Sg"
Try to force hardware FPU mode by using -CfFPA switch.
no, it does not help. I get exactly the same error. Perhaps something
changed in the build process for the
this compiles without errors. But I would like to get a hardfloat
enabled RTL again.
What host OS do you use?
I am using Windows 98SE for cross compiling.
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepa
Yury Sidorov wrote:
From: "Bernd Mueller" <[EMAIL PROTECTED]>
this compiles without errors. But I would like to get a hardfloat
enabled RTL again.
What host OS do you use?
I am using Windows 98SE for cross compiling.
Where arm-linux cross binutils for win32 can be downlo
Yury Sidorov wrote:
I compiled binutils myself and yes, the problem is present.
It does not happen when doing make cycle on real arm-linux box.
I will fix this issue.
thank you very much.
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.fr
74 matches
Mail list logo
