Are you sure those are the precise steps you took? Because that should
work as you expected it unless you have a broken binutils version. It's
normally very quick to complain about incompatible ARM versions
Try to disassemble the objects in the source directory at
rtl/units/arm-embedded
Den 07-09-2014 18:22, Sven Barth skrev:
On 07.09.2014 17:17, Jeppe Græsdal Johansen wrote:
Den 07-09-2014 17:11, Sven Barth skrev:
On 07.09.2014 16:36, Reinier Olislagers wrote:
Hi,
AFAIU at least x86/x64 Windows and Linux use an internal linker. Any
others? (Related: how can one find out
Den 17-08-2014 20:03, Sergio Flores skrev:
I'm trying to use threads in Android, but it seems they are not
working yet in FPC?
I tried two approachs, using FPC TThread and using pthreads, none
would work.
Using TThread requires including cthreads unit right?
But including this unit makes
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
Den 12-03-2014 16:51, Michael Ring skrev:
As there was no reaction I created a patch, question is if this patch
can be generally applied or if this version of patch should be
specific for arm targets. I guess it should be universal because it
matches the other definitions that also use pChar
Should be fixed in trunk now.
Regards,
Jeppe
Den 03-09-2013 08:44, Michael Ring skrev:
Trunk for armv7m buils just fine with this commandline:
make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
SUBARCH=armv7m CROSSOPT=-O- BINUTILSPREFIX=arm-none-eabi-
doing the same for
Den 17-06-2013 08:20, Sergei Gorelkin skrev:
16.06.2013 23:39, Michael Ring пишет:
I had some time this weekend (while beeing grilled by the sun on my
balcony) to work on another
thing that did not work correct and that I did not understand (Now I
do, I least I hope ;-)
As said before in
Den 02-06-2013 22:41, Michael Ring skrev:
Hi, perhaps I am overseeing a simple solution for my problem:
On the pic32 there are two flash areas, one at 0x9d00 for the main
program and another at 0xbfc0 that is called Boot Flash. On reset
the program starts in the boot flash at the
: operation combines symbols in different segments
the error is from the .size line.
Am 02.06.13 22:51, schrieb Jeppe Græsdal Johansen:
Den 02-06-2013 22:41, Michael Ring skrev:
Hi, perhaps I am overseeing a simple solution for my problem:
On the pic32 there are two flash areas, one at 0x9d00
Den 10-02-2013 21:47, Adriaan van Os skrev:
I maintain a large 600.000 FreePascal project that compiles for Mac OS
X. It mixes MacPascal and Delphi compiler modes. Unfortunately the
compiler is now producing random error messages, that disappear on a
clean rebuild. The error messages are not
Den 23-01-2013 00:54, vrt277 skrev:
Hi FPC team,
There is good proposed extension of for-in loop on fpc wiki: get
enumerator Position if available
http://wiki.freepascal.org/for-in_loop#Proposed_extensions. From my
point of view it's essential part of iterators. Especially for data
Could you write the complete command line you use for compiling?
Den 19-01-2013 22:58, Michael Ring skrev:
Thank you very much Florian, this problem is now indeed fixed. I have
encountered another one:
/Users/ring/devel/fpc/rtl/units/arm-embedded/sysutils.s: Assembler
messages:
The IR changes syntax often, so using that will most likely cause version
problems. The other option is to use C++ classes directly which apparently is
more stable.
I know i386, x86_64 and ARM works pretty good. I don't know about the few
others.
Compiling speed is very, very slow :) (when
Den 24-12-2012 07:53, Martin Schreiber skrev:
On Sunday 23 December 2012 17:44:53 Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Do you know how RTTI will be encoded?
I would guess short/ansistrings, since pascal identifiers must be a
subset of ASCII anyway.
Not
Den 07-11-2012 00:12, Andrew skrev:
On 12-11-06 05:07 PM, Michael Van Canneyt wrote:
Please re-open the issue and I will post an updated program that fails
EVERY TIME.
Or just use the attached Widen.lpr... :-)
Try this
FSize:=int64(1024*1024*1024)*Factor;
1024*1024*1024 is handled as a
Den 02-11-2012 14:32, Sergei Gorelkin skrev:
02.11.2012 17:08, Michael Van Canneyt пишет:
On Fri, 2 Nov 2012, Andrew Brunner wrote:
I think it would be a good solution and even prove faster in
controlled environments. Plus all
data is stored as widestrings in the DOM.
The first
Den 02-11-2012 18:04, Michael Van Canneyt skrev:
On Fri, 2 Nov 2012, Jeppe Græsdal Johansen wrote:
and LF, to appear in data, both in literal and escaped forms.
In other words, XML is wrong technology to work with binary data,
unless it is encoded into textual form (Base64 or alike
Den 02-11-2012 18:19, Sergei Gorelkin skrev:
02.11.2012 21:06, Jeppe Græsdal Johansen пишет:
Den 02-11-2012 18:04, Michael Van Canneyt skrev:
On Fri, 2 Nov 2012, Jeppe Græsdal Johansen wrote:
and LF, to appear in data, both in literal and escaped forms.
In other words, XML is wrong
Den 30-10-2012 21:54, SkyDiablo skrev:
so wow !
my question have a little prehistory, but direct to the problem. i
have compile a crosscompiler;
windows - Linux/MIPS
all works fine with one exception. if i start my helloWorld binary on
my destination target system, i get this message:
Are you using the code from branches/laksen/avr32new or something older?
And have you managed to fixed the non-aligned access bugs, that was
where I got stuck?
Regards,
Jeppe
Den 24-10-2012 20:33, Michel Catudal skrev:
I have started work on the fpc avr32. I used the patches from Laksen
Den 24-10-2012 21:16, Michel Catudal skrev:
Le 24/10/2012 14:50, Jeppe Græsdal Johansen a écrit :
Are you using the code from branches/laksen/avr32new or something older?
And have you managed to fixed the non-aligned access bugs, that was
where I got stuck?
Regards,
Jeppe
I took the code
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.
Also, wouldn't MOVD XMM5, [Bias] imply that you are moving from the
address stored
Den 16-09-2012 18:10, Florian Klaempfl skrev:
Am 16.09.2012 17:53, schrieb Daniël Mantione:
Op Sun, 16 Sep 2012, schreef Luca Olivetti:
but I don't know the outcome. Is it currently possible to develop
software
for that mcu with freepascal?
As far as I know the Cortex M series cannot run
I have made a preliminary backend and RTL stub in branches/laksen/avr32new/
Some of the large problems is that the load instructions allow non-aligned
loads in the ld.w forms. This proves to introduce many strange problems, and I
don't have any debug equipment.
Regards, Jeppe
Den 13-09-2012 21:41, Florian Klämpfl skrev:
Am 13.09.2012 21:38, schrieb Jeppe Græsdal Johansen:
I have made a preliminary backend and RTL stub in
branches/laksen/avr32new/
Some of the large problems is that the load instructions allow
non-aligned loads in the ld.w forms.
This proves
Den 08-07-2012 14:42, Thomas Schatzl skrev:
Actually, I saw that armv5 already supports blx, do not know right
now why
it isn't generated in the first place. Did you ever try compiling the
compiler or your program with -Cparmv5? Maybe it's just that the
compiler
default is armv5?
I never
Den 09-07-2012 11:20, Felipe Monteiro de Carvalho skrev:
makefile:29: *** You need the GNU utils package to use this Makefile. Stop.
Looks like it can't find a proper strip binary. Is your binutils prefix
correct? Maybe you have problems with the backslashes? A silly
suggestion: try changing
Den 25-05-2012 13:54, Jonas Maebe skrev:
Fuxin Zhang wrote on Fri, 25 May 2012:
And my progress and problems:
I've got the source from subversion and tried to build it in ubuntu
11.10 x86-64 machine. With the following patch and commands, I can get a
partly working ppcrossmipsel(it can at
Den 05-01-2012 03:35, David Welch skrev:
With the cortex-m0 parts now hitting the market I think it is time to
bring up the topic of thumb support again, not arm not thumb2 but
thumb (the only common instruction set across almost the entire arm
family (the exception being the pre-armv4t)).
Den 20-12-2011 21:51, Geoffrey Barton skrev:
I have been trying to cross-compile arm embedded for a cortexm3 using 2.6.0rc1.
I had this working previously with 2.4.0 and stellaris controllers.
Following the instructions on the wiki page 'TARGET_Embedded' and adding
suitable devices into
Den 05-11-2011 18:01, Mattias Gaertner skrev:
This sounds as if a Net and a Host uses different ordered bytes, which
makes the whole point of an and mask pointless.
Network order is always big endian. Host endian is just the endian of
your host computer. So in most cases they are indeed
Den 19-10-2011 04:10, David Welch skrev:
And from that point to the present (19505 or so) using instructions
from the target embedded wiki page:
make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded
CPU_TARGET=arm SUBARCH=armv4
the build fails with a lot of heap.inc errors.
Is
Sash0k wrote:
Hi, fpc community!
I try to compile fpc on my Toshiba AC100 smartbook (tegra 2 - ARM Cortex-A9
CPU), with Ubuntu 11.04 Natty, but have a problem:
First, I have download precompiled fpc from
ftp://ftp.freepascal.org/pub/fpc/dist/2.4.4/arm-linux/
It installs good and makes Hello
Den 13-09-2011 10:15, Michael Schnell skrev:
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU provides support for this. (I
Den 13-09-2011 16:52, Hans-Peter Diettrich skrev:
Michael Schnell schrieb:
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU
Den 30-08-2011 11:49, Martin skrev:
The following line to install fpc used to work:
make.exe install INSTALL_PREFIX=c:\FPC\trunk\ COPYTREE=echo
UPXPROG=echo
But now leads to:
.\fpmake.exe install --localunitdir=../.. --globalunitdir=..
--os=win32 --cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o
Is it really that big a deal?
I think the negatives outweigh the positives in the changes implied
here. Say what you want about the priciples about the instruction
sets(ARM and Thumb2), but they still share 95% of the backend code.
When you're dealing with lowlevel targets like embedded arm
Den 21-08-2011 00:00, David Welch skrev:
A! that makes sense. I assume that is either leftover from a
prior build? And how do I get a new/fresh build to look in the right
place?
It's installed in /fpcarm. This directory should contain a bin and units
directory. You simply need to change
Den 21-08-2011 17:06, Geoffrey Barton skrev:
On 21 Aug 2011, at 15:33, John Clymer wrote:
As part of my table-ization of cpuinfo.pas, I am including a generic
part for each (no code published for this yet.) The caveat to this
is that FLASH size and SRAM sizes are just set to extremely large
Den 21-08-2011 17:43, John Clymer skrev:
I found FPC_HAS_SYSTEMS_INTERRUPT_TABL, enabled it - but it was still
broken for Thumb2 (stellaris, stm32).
For Thumb2, it was broken in the following ways:
1) Stack_top should be placed at vector 0.
I disagree, but I guess that's a question of
Den 20-08-2011 16:46, David Welch skrev:
I was hoping for thumb support but I now see that the choices are
limited to arm and thumb+thumb2 (without any separation between thumb
and thumb2). Actually thumb2 wasnt working for me, I got an
arm+thumb2 mix, so I will ride this along for a while
:23 AM, Jeppe Græsdal Johansen wrote:
Den 20-08-2011 16:46, David Welch skrev:
I was hoping for thumb support but I now see that the choices are
limited to arm and thumb+thumb2 (without any separation between thumb
and thumb2). Actually thumb2 wasnt working for me, I got an arm+thumb2
mix, so I
On 11-08-2011 13:56, Sven Barth wrote:
Am 09.08.2011 11:54, schrieb Michael Schnell:
On 08/08/2011 10:00 PM, Sven Barth wrote:
It will be interesting to see whether they want to license Cooper,
RemObject's upcoming Pascal compiler for Java, as well; their plans to
support Android as well in
On 09-08-2011 15:53, Geoffrey Barton wrote:
On 9 Aug 2011, at 14:14, John Clymer wrote:
I was thinking more of a generic controller class, including a
memory.def (or whatever one wants to name it) file. That would be
easiest as it would only effect the t_embed.pas file (and cpuinfo.pas
On 07-08-2011 20:42, Graeme Geldenhuys wrote:
own compiler later on. As long as they don't start blatantly copying code from
FPC
into their own compiler
The problem is, how would we know? Nobody can see their compiler code.
Good news is that any modifications or bug fixes they make, they
45 matches
Mail list logo
