Re: [fpc-devel] Code generated for the embedded arm port for lpc1768 (armv7m)
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
Those should largely contain variable length thumb2 code.
Den 23-10-2014 20:15, Sietse Achterop skrev:
Hello,
I am trying to get the embedded version of fpc for arm to work.
Currently i try it for the lpc1768 from NXP using the lpcxpresso board.
The example compiles, but doesn't run on the target...
I created a simple example and it seems that the code it generates is
NOT thumb2 code.
I disassembled the elf-file generated by fpc using
arm-none-eabi-objdump -S
I also disassembled it using the debugger arm-none-eabi-gdb
Here is a fragment of the code from both:
From objdump:
01c4 FPC_INITIALIZEUNITS:
1c4:e92d4070 push{r4, r5, r6, lr}
1c8:ebf5 bl1a4 SYSTEM_$$_FPC_CPUINIT
1cc:e59f006c ldrr0, [pc, #108]; 240
FPC_INITIALIZEUNITS+0x7c
1d0:e5904000 ldrr4, [r0]
1d4:e3a05001 movr5, #1
1d8:e1540005 cmpr4, r5
1dc:ba0f blt220 FPC_INITIALIZEUNITS+0x5c
From gdb
0x01c4 fpc_initializeunits+0:70 40 eors
r0, r6
0x01c6 fpc_initializeunits+2:2d e9 f5 ff
stmdbsp!, {r0, r2, r4, r5, r6, r7, r8, r9, r10, r11, r12, sp, lr, pc}
= 0x01ca fpc_initializeunits+6:ff eb 6c
00 ; UNDEFINED instruction: 0xebff006c
0x01ce fpc_initializeunits+10:9f e5
b.n 0xfd10
0x01d0 fpc_initializeunits+12:00 40
ands r0, r0
0x01d2 fpc_initializeunits+14:90 e5
b.n 0xfcf6
0x01d4 fpc_initializeunits+16:01 50
str r1, [r0, r0]
0x01d6 fpc_initializeunits+18:a0 e3
b.n 0x91a
0x01d8 fpc_initializeunits+20:05 00
movs r5, r0
0x01da fpc_initializeunits+22:54 e1
b.n 0x486
0x01dc fpc_initializeunits+24:0f 00
movs r7, r1
Note how the interpretation of the code is different, as is the length
of most instructions.
It looks to me as if the code in the elf-file are (mostly) 32-bit
values, while the debugger does interpret thee code as thumb2 (i think).
In the Makefile in rtl/embedded I find:
ifeq ($(SUBARCH),armv7m)
CPU_UNITS=lm3fury lm3tempest stm32f10x_ld stm32f10x_md
stm32f10x_hd stm32f10x_xl stm32f10x_conn stm32f10x_cl lpc13xx lpc1768
lm4f120 xmc4500 cortexm3 cortexm4 # thumb2_bare
endif
So that suggest (via the comment) that fpc can do thumb2 code, which
it should for cortexm3.
My PC is debian/jessie/64bit: Free Pascal Compiler version
2.6.4+dfsg-3 [2014/07/12] for x86_64
I got the sourcecode for the port from svn as described on the website.
To create the port I do:
make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded
CPU_TARGET=arm SUBARCH=armv7m BINUTILSPREFIX=arm-none-eabi-
For the binutils I use the (current) stuff for the lpc1768 from NXP:
lpcxpresso_7.4.0_229
To create a program I do:
ppcrossarm -Ch1024 -Cs1024 -Tembedded -Parm -Cparmv7m
-XParm-none-eabi- -Wplpc1768 -vu prog.p
Is there anybody that did get this port to work?
Thanks in advance,
Sietse
___
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] Which platforms have internal linkers
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/is there a list somewhere?) (Helps me update my ego-boosting fpcup cross compiler conversion table :) ) Linux has an internal linker, but it's AFAIK not yet the default one. All the Windows platforms (i386-win32/-wince, x86_64-win64, arm-wince and *-nativent) use the internal linker. Regards, Sven ARM doesn't have an internal writer yet though so you still need an external assembler for wince. The question was about linkers, not assemblers ;) Regards, Sven Correct, but if you have to use gas, you will probably have access to ld too :P ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads in Android
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 the app imediately close at startup, silently, with nothing in the log except a message saying the process died. Not including cthreads makes the app thrown an exception when creating a new thread, as expected. (cannot create semaphore or something like that). I tried to use pthreads directly instead. However allocating any memory inside the new thread crashes the app imediately (The stack shows that the crash was in the cmem unit). I guess some setup code has to called at the thread startup to allow the mem manager to work correctly? That is correct. I'm using FPC 2.6.1 for Android compilation, maybe this was fixed in later versions? I'm not sure but you should probably try a newer version, maybe build from trunk. 2.6.1 is old as far as I remember. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC and Windows Phone 8
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 note: trunk supports now to generate hardfloat arithmetics with thumb enabled. ___ 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] arm-embedded target does not compile in trunk since revision 26964 (Some AVR related changes)
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 in the same file. Hi Michael, Just fixed this a slightly different way. Sorry for the delay. Best Regards, Jeppe ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Current Trunk does not build for target embedded amd ARM-Cortex-M0 (Introduced in Rev 25370)
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 armv6m:
make clean buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm
SUBARCH=armv6m CROSSOPT=-O- BINUTILSPREFIX=arm-none-eabi-
gives the following errormessage:
make -C embedded all
/bin/mkdir -p /Users/ring/devel/fpc-orig/rtl/units/arm-embedded
/Users/ring/devel/fpc-orig/compiler/ppcrossarm -Cparmv6m @rtl.cfg -Ur
-Tembedded -Parm -XParm-none-eabi- -Xr -Ur -Xs -O2 -n -Fi../inc
-Fi../arm -FE. -FU/Users/ring/devel/fpc-orig/rtl/units/arm-embedded
-darm -dRELEASE -O- -Us -Sg system.pp
text.inc(2082,14) Warning: Implicit string type conversion from
AnsiString to UnicodeString
text.inc(2301,53) Warning: Implicit string type conversion with
potential data loss from UnicodeString to AnsiString
/Users/ring/devel/fpc-orig/rtl/units/arm-embedded/system.s: Assembler
messages:
/Users/ring/devel/fpc-orig/rtl/units/arm-embedded/system.s:13: Error:
selected processor does not support Thumb mode `stmfd
r13!,{r11,r12,r14,r15}'
/Users/ring/devel/fpc-orig/rtl/units/arm-embedded/system.s:14: Error:
lo register required -- `sub r11,r12,#4'
/Users/ring/devel/fpc-orig/rtl/units/arm-embedded/system.s:16: Error:
lo register required -- `strb r0,[r11,#-48]'
The problem started with rev 25370, all version before that build fine
on armv6m
Comments for 25370 were:
+ arm: tsettings.instructionset
* the selected instruction set is now independent from the cpu type: e.g.
armv7-a can perfectly execute thumb(2) code
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How can I distribute code in two different memory areas? (.section)
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 this thread, I wanted to distribute Code in two different memory areas because this needs to be done so that pic32 startup code works correctly. But when I linked my binary the elf-file had always a startup address somewhere in the wrong memory area. This is what I tried: procedure reset; assembler; nostackframe; public name'_reset'; asm .section .reset,\ax\,@progbits la $k0, _startup jr $k0 //Jump to startup code nop .text end; In general, the custom section support in compiler needs a lot of improvement... Try the following, maybe it could work: procedure anyname; assembler; nostackframe; asm .section .reset,\ax\,@progbits .globl _reset _reset: // -- correct name here la $k0, _startup jr $k0 nop .text end; Regards, Sergei I agree that it needs some work. Having a way to specify the section with a procedure directive would largely be preferable I think. Such a directive could also be interesting for variables and typed constants Also, I think .section .reset should work just fine in most cases ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How can I distribute code in two different memory areas? (.section)
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 first address.
I have written the startup code for the chips now but I need to
distribute some procedures between the two memory areas, for obvious
reasons I must have some code at address 0xbfc0 or the chip will
not boot correctly ;-).
My thought was now to tweak the linker script in the same way the
original linker scripts of pic32 work:
MEMORY
{
kseg0_program_mem(rx) : ORIGIN = 0x9D00, LENGTH = 0x8
kseg1_boot_mem : ORIGIN = 0xBFC0, LENGTH = 0x490
}
SECTIONS
{
.reset _RESET_ADDR :
{
KEEP(*(.reset))
KEEP(*(.reset.startup))
} kseg1_boot_mem
}
In assembler I can then simply write:
.section .reset,code and
.section .reset.startup,code
and then the code, this will automagically end up in the
kseg1_boot_mem, but this does not work with the inline assembler. Any
ideas on how to do this the correct way? Is there something more
intelligent than to write a plain assembler file?
TnX,
Michael
You should be able to use
.section .reset
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How can I distribute code in two different memory areas? (.section)
Den 02-06-2013 23:15, Michael Ring skrev:
Unfortunately that does not seem to work (or I use it wrong):
This procedure:
procedure _general_exception_handler; assembler; nostackframe; public
name '_GENERAL_EXCEPTION_HANDLER';
asm
.section reset
sdbbp 0;
.Lloopb:
b .Lloopb
end;
translates to:
.section .text.n_pic32mx1xxfxxxc_$$__general_exception_handler
.balign 4
.globl PIC32MX1XXFXXXC_$$__GENERAL_EXCEPTION_HANDLER
.type PIC32MX1XXFXXXC_$$__GENERAL_EXCEPTION_HANDLER,@function
PIC32MX1XXFXXXC_$$__GENERAL_EXCEPTION_HANDLER:
.globl _GENERAL_EXCEPTION_HANDLER
.type _GENERAL_EXCEPTION_HANDLER,@function
_GENERAL_EXCEPTION_HANDLER:
.entPIC32MX1XXFXXXC_$$__GENERAL_EXCEPTION_HANDLER
.section reset
sdbbp 0
.Lj11:
b .Lj11
jr $ra
nop
.setmacro
.setreorder
.endPIC32MX1XXFXXXC_$$__GENERAL_EXCEPTION_HANDLER
.Lt3:
.Le2:
.size PIC32MX1XXFXXXC_$$__GENERAL_EXCEPTION_HANDLER, .Le2 -
PIC32MX1XXFXXXC_$$__GENERAL_EXCEPTION_HANDLER
.Ll8:
which creates an assembler error:
/Users/ring/devel/fpc/rtl/units/mipsel-embedded/pic32mx1xxfxxxc.s:94:
Error: 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 for the
main program and another at 0xbfc0 that is called Boot Flash. On
reset the program starts in the boot flash at the first address.
I have written the startup code for the chips now but I need to
distribute some procedures between the two memory areas, for obvious
reasons I must have some code at address 0xbfc0 or the chip will
not boot correctly ;-).
My thought was now to tweak the linker script in the same way the
original linker scripts of pic32 work:
MEMORY
{
kseg0_program_mem(rx) : ORIGIN = 0x9D00, LENGTH = 0x8
kseg1_boot_mem : ORIGIN = 0xBFC0, LENGTH = 0x490
}
SECTIONS
{
.reset _RESET_ADDR :
{
KEEP(*(.reset))
KEEP(*(.reset.startup))
} kseg1_boot_mem
}
In assembler I can then simply write:
.section .reset,code and
.section .reset.startup,code
and then the code, this will automagically end up in the
kseg1_boot_mem, but this does not work with the inline assembler.
Any ideas on how to do this the correct way? Is there something more
intelligent than to write a plain assembler file?
TnX,
Michael
You should be able to use
.section .reset
Try
procedure _general_exception_handler; assembler; nostackframe; public
name '_GENERAL_EXCEPTION_HANDLER';
asm
.section reset
sdbbp 0;
.Lloopb:
b .Lloopb
.text
end;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Random compiler errors
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 clearly reproduceable. Sometimes, everything is OK, sometimes the incorrect error messages are there. I suspect corrupted .ppu files, I there a way to use a tool (like ppudump) or a specially built compiler to investigate this problem systematically, to get an idea of what is wrong ? I do builds through a Makefile. I could image always adding a ppudump to the builds and then looking at the output when random error messages popup, comparing the output to previous builds. Something like that. An automatic ppu sanity mode inside the compiler would even be better. Regards, Adriaan van Os I have seen this behaviour when files with the same name is visible in more places in the directories visible to the compiler, and one is already built(valid .ppu available) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
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 structures which store pairs of key and value associated with key. I want to implement this extension. Moreover I started implementation to explore fpc internals. Current /(not finished)/ result available on github. https://github.com/vkevroletin/freepascal/tree/key-value-iterator My motivation is simple: I'm a student. My teacher is Alexander S. Klenin who should be well known to fp? developers. And I want to implement some feature of fpc as my graduate work. Through improvement of for-in loop is not enough for good graduate work but it is good initial step towards other big contribution. So is get enumerator Position if available http://wiki.freepascal.org/for-in_loop#Proposed_extensions good idea? Thanks, Vasiliy Kevroletin P.S. links for people who dislike computer mouse: proposed extension - http://wiki.freepascal.org/for-in_loop#Proposed_extensions my branch on github - https://github.com/vkevroletin/freepascal/tree/key-value-iterator I think the idea is good if the feature is implemented as optional. That way: - If the enumerator class implements a CurrentIndex method then the for loop can have an index variable. - If not then the for loop can only behave as current for in loops. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm-embedded buid broken since rev 23325
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: /Users/ring/devel/fpc/rtl/units/arm-embedded/sysutils.s:20800: Error: thumb conditional instruction should be in IT block -- `bxeq r14' /Users/ring/devel/fpc/rtl/units/arm-embedded/sysutils.s:20803: Error: thumb conditional instruction should be in IT block -- `subls r1,r1,#32' /Users/ring/devel/fpc/rtl/units/arm-embedded/sysutils.s:20804: Error: thumb conditional instruction should be in IT block -- `strbls r1,[r12]' /Users/ring/devel/fpc/rtl/units/arm-embedded/sysutils.s:20820: Error: thumb conditional instruction should be in IT block -- `bxeq r14' /Users/ring/devel/fpc/rtl/units/arm-embedded/sysutils.s:20823: Error: thumb conditional instruction should be in IT block -- `addls r1,r1,#32' /Users/ring/devel/fpc/rtl/units/arm-embedded/sysutils.s:20824: Error: thumb conditional instruction should be in IT block -- `strbls r1,[r12]' this one can be solved by adding -mimplicit-it=thumb to the the commandline of arm-embedded-as. I have created a replacement script for arm-embedded-as: #!/bin/sh /usr/local/bin/arm-embedded-as -mimplicit-it=thumb $* with this script I can build latest svn. What I do not understand is that this problem only exists when sysutils gets compiled, the svn code from 2012-01-04 works fine, the code from the next day shows this error, the 'only' change is that sysutils gets included in the build. For now, how can I add -mimplicit-it=thumb to the as commandline without my small hack? can I put this somewhere in fpc.cfg? Michael Am 19.01.13 16:19, schrieb Florian Klämpfl: Am 19.01.2013 12:18, schrieb Michael Ring: Today I found some time to research since when excactly arm-embedded does not compile anymore, I found that since revision 23325 compile does not work anymore, can anybody help, it seems that the problem itself is hidden somewhere else in code... Fixed in r23452. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM
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 using ir input at least) Having worked a bit with llvm I don't like the IDE of completely changing the backend of fpc. Mostly because we are then relying on a bunch of C++ programmers to fix bugs and extend the backend in the future. Regards Jeppe Johansen - Reply message - From: Martin Schreiber mse00...@gmail.com Date: Wed, Dec 26, 2012 06:07 Subject: [fpc-devel] LLVM To: fpc-devel@lists.freepascal.org Hi, Does any body work on a LLVM backend for Free Pascal? Has anybody experience with LLVM? Are there licensing issues? What about the quality of the produced code? What about compiling speed? Thoughts? Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
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 Delphi 2009+ btw, which allow UTF8 identifiers. What will FPC do? Martin Hopefully not a thing :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Memory Streams unable to handle reads past 2GB
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 longint on a 32bit machine. Multiplied by a byte will still give a longint, which will overflow if multiplied by 2. It also generates a hint about that: widen.lpr(44,12) Hint: Converting the operands to Int64 before doing the multiply could prevent overflow errors. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Components
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 question I have is if there was such an option would the patch be accepted. I don't see how you can fix the problem. If the input is UTF8, and the result must be converted to a widestring for the DOM, then a conversion MUST take place, there is no way to avoid it. And a conversion means scanning the input byte for byte. In each case, the input must be scanned byte for byte anyway, to detect all the tags. That's what makes XML slow and unusable for large amount of data. The next question is what is the problem with the uf8 routine that it left the offending byte sequence intact without converting the bytes in my sample data? Without error message, it is impossible to tell. In this case, the issue is not encoding, but literal ESC (#27) code used in data. XML specification does not allow codepoints below 32, except TAB,CR 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). Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel XML 1.1 allows anything down to #1, but the current parser doesn't seem to allow that. I guess that should solve most of the problems here. Specifically, TXMLDecodingSource.SkipUntil doesn't allow #1..#31 if FXML11Rules is true, which I think it should. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Components
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). Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel XML 1.1 allows anything down to #1, but the current parser doesn't seem to allow that. I guess that should solve most of the problems here. Specifically, TXMLDecodingSource.SkipUntil doesn't allow #1..#31 if FXML11Rules is true, which I think it should. But the document prolog specified XML version 1.0, so these characters are not allowed. If of course Andrew creates the XML himself, he can specify 1.1 as the XML version, then that may well be a solution. Yes, but changing the version still generates the same error, even though it shouldn't Note that the specs of 1.1 still say that The characters defined in the following ranges are also discouraged. They are either control characters or permanently undefined Unicode characters: [#x1-#x8], [#xB-#xC], [#xE-#x1F], [#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDDF], [#x1FFFE-#x1], [#x2FFFE-#x2], [#x3FFFE-#x3], [#x4FFFE-#x4], [#x5FFFE-#x5], [#x6FFFE-#x6], [#x7FFFE-#x7], [#x8FFFE-#x8], [#x9FFFE-#x9], [#xAFFFE-#xA], [#xBFFFE-#xB], [#xCFFFE-#xC], [#xDFFFE-#xD], [#xEFFFE-#xE], [#xE-#xF], [#x10FFFE-#x10]. So it would be wise to replace the characters with encoded data. Michael. It's true that it's not a good idea, but it should work at least :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] XML Components
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 technology to work with binary data, unless it is encoded into textual form (Base64 or alike). Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel XML 1.1 allows anything down to #1, but the current parser doesn't seem to allow that. I guess that should solve most of the problems here. Specifically, TXMLDecodingSource.SkipUntil doesn't allow #1..#31 if FXML11Rules is true, which I think it should. But the document prolog specified XML version 1.0, so these characters are not allowed. If of course Andrew creates the XML himself, he can specify 1.1 as the XML version, then that may well be a solution. Yes, but changing the version still generates the same error, even though it shouldn't Note that the specs of 1.1 still say that The characters defined in the following ranges are also discouraged. They are either control characters or permanently undefined Unicode characters: [#x1-#x8], [#xB-#xC], [#xE-#x1F], [#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDDF], [#x1FFFE-#x1], [#x2FFFE-#x2], [#x3FFFE-#x3], [#x4FFFE-#x4], [#x5FFFE-#x5], [#x6FFFE-#x6], [#x7FFFE-#x7], [#x8FFFE-#x8], [#x9FFFE-#x9], [#xAFFFE-#xA], [#xBFFFE-#xB], [#xCFFFE-#xC], [#xDFFFE-#xD], [#xEFFFE-#xE], [#xE-#xF], [#x10FFFE-#x10]. So it would be wise to replace the characters with encoded data. Michael. It's true that it's not a good idea, but it should work at least :) To my knowledge, XML 1.1 supports codes below 32 only in escaped forms. #27; is valid in XML 1.1 but not in XML 1.0. Regards, Sergei According to the spec, cdata should allow them unescaped. [2] Char ::= [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10] [20] CData ::= (Char* - (Char* ']]' Char*)) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CrossCompiling :: Windows - Linux/MIPS
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: FPU emulator disabled, make sure your toolchain was compiled with software floating point support (soft-float) someone can think: oh, the toolchain is wrong, but no, with the same toolchain and with an c++ source, i can create a working binary with this compiler switch: -msoft-float. so, how can i implement this software floating point behavoir in my FPC binary? greez thx, sky... When building the crosscompiler try adding CROSSOPT=-Cfsoft. The same argument(-Cfsoft) should be specified when building a program with the crosscompiler afterwards. -Cf sets the FPU type, which by default is set to mips32. soft sets it to softfpu ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc AVR32
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 to get started but am using the newer released fpc as a code base. So far I have added support for the following processors : at32uc3b0256es at32uc3b0256 at32uc3b1256es at32uc3b1256 at32uc3c0512crevc at32uc3c0512c at32uc3c1512crevc at32uc3c1512c at32uc3l016 at32uc3l032 at32uc3l064 at32uc3l116 at32uc3l132 at32uc3l164 at32uc3l216 at32uc3l232 at32uc3l264 at32uc3l316 at32uc3l332 at32uc3l364 Since Atmel will eventually discontinue the AVR32 that runs Linux, I have no plan to do any work on AVR32 Linux. I still need to write some evaluation code for the LCD, EEPROM, I2C, CAN, LIN, etc. I won't include that into the compiler but as an addon. I am going to use the evaluation board AT32UC3C-EK to test the code for the at32uc3c0512crevc part and the EVK1101 for the at32uc3b0256es. My debugging tool is JTAGICE mkII. If anyone has newer evaluation boards and wish to work on this, you will have to adapt my code for those boards. For the at32uc3c0512c the difference is the ethernet port and the bugs in the watchdog. The most obnoxious watchdog bugs were fixed in the production release. Does anyone know if the ethernet is actually present in the engineering sample despite the specs that tells otherwise? For the uc3b differences are kind of important but for most code they are minuscule. The clock is a bit different. Code can be arranged to used either this processor or a newer one. I don't have any uc3l devices so I won't mess with this for now. I have copied source and binaries on my website. I compiled the code under Scientific Linux 6.2 which is a free version of Linux that uses the source of Redhat Enterprise Linux 6. How do I get an account so I can put my code on a directory on the fpc svn? Michel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc AVR32
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 from that new one. I am just starting. My first task was to port to some devices I have and have a binary to work with. One thing that I found annoying was that the makefiles do not seem to know about the fact that the compiler may be a 64 bit compiler. I have several uc3c0512 and uc3c1512 plus an evaluation board. The evaluation board for the uc3b0256es has very few features, not quite as fancy as the one for the automotive part. I have not looked at the non-aligned access bugs yet but will do in time. First I have to have something that I can debug on one of my evaluation boards. On the subject, the alignment is for word or dword access. You cannot access a word in the middle, you will get a trap interrupt. Byte access shouldn't be an issue. In which case are you having the issue with non alignment? so I will know which function to look at. Michel PC relative word loads aren't aligned automatically, and due to the variable instruction length such an instruction might end up on a halfword boundary. I have no clue how to fix it in a simple way. LDDPC has a very small allowable offset ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Same 64bit assembly code compiles under windows but not in linux (fpc 260)
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 in the Bias variable? That would make a whole lot more
sense as to why it generates this error
Den 03-10-2012 03:29, luiz americo pereira camara skrev:
Hi,
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 Bit references not supported
at the line
// Load XMM5 with the bias value.
MOVDXMM5, [Bias] //Bias = Integer
Is it a know issue or a limitation of linux version?
There's a workaround to this issue?
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 Count
// R9D contains ConstantAlpha
// Bias is on the stack
//.NOFRAME
// Load XMM3 with the constant alpha value (replicate it for
every component).
// Expand it to word size.
MOVDXMM3, R9D // ConstantAlpha
PUNPCKLWD XMM3, XMM3
PUNPCKLDQ XMM3, XMM3
// Load XMM5 with the bias value.
MOVDXMM5, [Bias]
PUNPCKLWD XMM5, XMM5
PUNPCKLDQ XMM5, XMM5
// Load XMM4 with 128 to allow for saturated biasing.
MOV R10D, 128
MOVDXMM4, R10D
PUNPCKLWD XMM4, XMM4
PUNPCKLDQ XMM4, XMM4
@1: // The pixel loop calculates an entire pixel in one run.
// Note: The pixel byte values are expanded into the higher
bytes of a word due
// to the way unpacking works. We compensate for this
with an extra shift.
MOVDXMM1, DWORD PTR [RCX] // data is unaligned
MOVDXMM2, DWORD PTR [RDX] // data is unaligned
PXORXMM0, XMM0// clear source pixel register for
unpacking
PUNPCKLBW XMM0, XMM1{[RCX]}// unpack source pixel byte
values into words
PSRLW XMM0, 8 // move higher bytes to lower bytes
PXORXMM1, XMM1// clear target pixel register for
unpacking
PUNPCKLBW XMM1, XMM2{[RDX]}// unpack target pixel byte
values into words
MOVQXMM2, XMM1// make a copy of the shifted
values, we need them again
PSRLW XMM1, 8 // move higher bytes to lower bytes
// calculation is: target = (alpha * (source - target) + 256 *
target) / 256
PSUBW XMM0, XMM1// source - target
PMULLW XMM0, XMM3// alpha * (source - target)
PADDW XMM0, XMM2// add target (in shifted form)
PSRLW XMM0, 8 // divide by 256
// Bias is accounted for by conversion of range 0..255 to
-128..127,
// doing a saturated add and convert back to 0..255.
PSUBW XMM0, XMM4
PADDSWXMM0, XMM5
PADDW XMM0, XMM4
PACKUSWB XMM0, XMM0 // convert words to bytes with
saturation
MOVD DWORD PTR [RDX], XMM0 // store the result
@3:
ADD RCX, 4
ADD RDX, 4
DEC R8D
JNZ @1
{$endif}
end;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] stellaris launchpad
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 generic ARM code; it only understands the Thumb2 instruction set. FPC supports Thumb-2 code generation and arm-embedded supports also some stellaris types (LM3S* types) so it should be possible with little effort to compile programs with FPC for this device. But maybe Jeppe can say more. I also preordered the board, but as far as I can see it shouldn't be too hard to add. It's a Cortex-M4F which has floating point support(for 32bit single math only). The hardware floating point is the only thing not supported by FPC currently. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
SV: [fpc-devel] fpc on AVR32
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 Fra: fpc-devel-boun...@lists.freepascal.org [fpc-devel-boun...@lists.freepascal.org] p#229; vegne af Florian Klämpfl [flor...@freepascal.org] Sendt: 13. september 2012 19:08 Til: FPC developers' list Emne: Re: [fpc-devel] fpc on AVR32 Am 13.09.2012 02:26, schrieb Michel Catudal: I would like to port fpc to the AVR32 uc3c devices. I need more details on the functions that need to be implemented. Take a look at one of the other architectures like arm, fpc/compiler/arm contains the arm specific compiler files. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc on AVR32
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 to introduce many strange problems, Why is this a problem? Because PC relative loads with the wide format aren't automatically aligned to a 4 byte boundary by the processor, and the instruction set is a variable length 16bit ISA like thumb-2. There were a few other issues that were highly annoying too, but I can't remember what they were. Other than that the ISA was beautifully simple. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error building branch targetandroid
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 really tested -Cparmv5, only -Cparmv6 and with no options (so default value), I just conected the points based on your assertion that default=v5, but indeed maybe it is v4. ... or even to some lower common denominator. Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel You should be using -Cparmv5t if you want armv5 and blx. The t indicates that the device has thumb support, which most have, but armv5 is usually safer, hence it's the default. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error building branch targetandroid
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 them from \ to \\ :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] about freepascal for mips
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 least build a helloworld and
runnable):
patch:
Index: Makefile.fpc
===
--- Makefile.fpc(版本 21354)
+++ Makefile.fpc(工作副本)
[snip]
This is to fix various file not found errors. I am not sure whether
it is
'right' fix.
No, definitely it's definitely not right. It's strange that you need
those changes, since the Linux RTL Makefile is used daily. Did you
need those changes even to compile it for i386?
commands:
cd rtl/linux;
patch Makefile.fpc; fpcmake -Ti386-linux,mipsel-linux
It's better to use -Tall (since there are more Linux targets than just
i386 and mipsel).
/home/foxsen/fpc/rtl/units/mipsel-linux/sysutils.o: In function
`SYSUTILS_$$_finalize':
/home/foxsen/fpc/rtl/unix/sysutils.pp:1414: relocation truncated to fit:
R_MIPS_PC16 against
`SYSTEM$_$TINTERFACEDOBJECT_$__$$_QUERYINTERFACE$TGUID$formal$$LONGINT'
/home/foxsen/fpc/rtl/unix/sysutils.pp:1414: relocation truncated to fit:
R_MIPS_PC16 against `SYSTEM$_$TINTERFACEDOBJECT_$__$$__ADDREF$$LONGINT'
/home/foxsen/fpc/rtl/unix/sysutils.pp:1414: relocation truncated to fit:
R_MIPS_PC16 against `SYSTEM$_$TINTERFACEDOBJECT_$__$$__RELEASE$$LONGINT'
pp.pas(224,36) Error: Error while linking
pp.pas(224,36) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted make[1]: *** [ppcmipsel] 错误 1
make[1]:正在离开目录 `/home/foxsen/fpc/compiler'
make: *** [cycle] 错误 2
I know it is related to mips branch offset overflow.
A similar issue exists on PowerPC: conditional branches are limited to
16 bit offsets, while unconditional branches can reach up to 26 bits
or so. As far as I can see, it's similar on MIPS (the B* opcodes
versus the J opcode). If so, you may be able to create a MIPS version
of the fixup_jmps procedure in compiler/ppcgen/aasmcpu.pas and add it
to compiler/mips/aasmcpu.pas (it's called from psub.pas, you'll have
to modify the ifdef there to also activate it for MIPS and MIPSEL).
The actual errors you get are strange though. We never insert
conditional branches from one routine to another (in the above case:
from SYSUTILS_$$_finalize, or more likely from interface wrappers
following that symbol, to various other routines). Looking at the code
for tcgcpu.g_intf_wrapper in compiler/mips/cgcpu.pas, the code for
interface wrappers uses the B as opposed to the J instruction to
branch to the interface wrappers. Maybe that's a copy/paste error from
another platform. I'm not sure what B means though, I don't see it
listed at http://www.mrc.uidaho.edu/mrc/people/jff/digital/MIPSir.html
Anyway, I guess this patch will solve the above error:
Index: compiler/mips/cgcpu.pas
===
--- compiler/mips/cgcpu.pas(revision 21359)
+++ compiler/mips/cgcpu.pas(working copy)
@@ -1722,7 +1722,7 @@
op_onr24methodaddr;
end
else
-
list.concat(taicpu.op_sym(A_B,current_asmdata.RefAsmSymbol(procdef.mangledname)));
+
list.concat(taicpu.op_sym(A_J,current_asmdata.RefAsmSymbol(procdef.mangledname)));
{ Delay slot }
list.Concat(TAiCpu.Op_none(A_NOP));
After some
research,I've found that ppc code support -fPIC.
PIC normally won't help with branch offset overflows.
But when I try to enable
it,the other issue appears:
Yes, PIC requires cpu-specific support. It shouldn't be necessary to
get an initial port up and running though.
Jonas
I wonder how you people managed to build anything at all.
When I tried to build from SVN trunk there would be an endless steam of
internalerrors related to fpu registers, no matter if compiled with MIPS
FPU or softfloat.
I managed to remove the errors with the following patch, such that
everything compiled, but I haven't been able to test it:
http://j-software.dk/fpc-mipsel.patch
Does anyone know if there's an easy way to set up an emulator for
testing? Been fighting with qemu for the last half hour without results.
Regards,
Jeppe
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] cortex-m0 support
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)). cortex-m0 and -m1 are armv6-m based, the -m3 and -m4 are armv7m based. I count something like 20 armv6m instructions that are not in the all thumb variants category. something like 148 armv7m that are not supported by armv6m nor all thumb variants. Just a rough count. This is why you will see folks saying that the cortex-m0 and -m1 are thumb only not thumb2. The cortex-m0 based mbed's have hit the street btw, available at sparkfun and other places. Note that gcc and llvm fail to build working code for the cortex-m0, when you specify cortex-m0 you get thumb2 code which fails miserably. David Looks like it basically only has some branching instructions that can be 32 bit, and thus use R8-R15. This means it'll be pretty easy to create a cg sharing a heap of code with the thumb2 cg. An interesting idea however, could be to create a real Thumb cg, and let the Thumb2(armv7m) and Armv6m cg extend that. That would give the benefit that fpc could generate Thumb code on older platforms too ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded on 2.6.0rc1
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 cpuinfo etc. where they have been missed out, I can build a test program. However disassembling the resulting elf file shows the sections system_fpc_cpuuint, system_sysinitfpu, fpc_initializeunits, fpc_initializeunitsetc, system_internalexit, fpc_do_exit, system_system_exit and init$_system to be 32 bit arm code not thumb2. The rest of the program, including the stellaris.pp code, are correct thumb2 code. It appears the armv7m subarch is not being acted on when compiling rtl? I got the same result if I substituted cortexm3 for this too. Geoffrey ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Do you have an example of how you can see it is 32 bit arm code and not thumb2? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] StrToHostAddr
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 different I don't know what you mean about and mask ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] target embedded heap.inc
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 the problem the build command line or somewhere else? Not that I can see. I just tried the same and it worked just fine. I'm using 2.7.1 from 2011/10/04 to build it with There was another person having the same problem. I guess you just need a recent version as host to build the embedded target ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM native compilation (Toshiba AC100)
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 world program correctly. Next I try to compile mseide. It does, but mseide crashes on start. Some detailed information about it is here (on Russian): http://freepascal.ru/forum/viewtopic.php?f=1t=7300start=15#p56281 To fix the problem with the linker EABI error, you need to override the call to the assembler from the compiler. You can do this by creating a shell script called as, which calls the real as with the original parameters and an extra parameter, which goes something like -meabi=5 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
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 have no idea which of the CPUs supported by FPC has what kind of hardware data-breakpoint support. I suppose this is a very complex list). -Michael i386, x86_64 and ARM has watchpoint/hardware breakpoint support. It's not really hard on either of them to implement. For i386 and x86_64 you can simply write values into DR0-DR3 with entries and configure them through DR6,7(if the OS supports that, I would guess that Windows does since it exposes them in the CONTEXT type). That limits the number to 4 watchpoints/breakpoints, but since breakpoints can be inserted into the code on this platform the number of breakpoints doesn't have to be limited here. For ARM embedded you usually have to go through a JTAG/SWD library, and communicate with the core debugger. ARM seems to have all types freely documented. I'm working on a JTAG library, and have rudimentary support for Cortex-M3 and soon Cortex-A8. An ARM-Linux platform would need hardware debugger monitor support, which I guess would exist somehow. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
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 provides support for this. It's not the CPU, it's more the MMU which can help in finding changed (global) variables. When the static data segment supports interrupts on write, a debugger only has to check whether the affected address in the watch list. Doing such checks on *every* write to memory (stack!?) requires many more lookups. Hardware support for writes to arbitrary memory addresses is restricted to very few addresses, not really useful. How many times do you think you need more than 1-2 watchpoints? Lots of breakpoints I can understand, but I've never found many uses for watchpoints. That's why Delphi normally checks for changed values only when a breakpoint is hit, not on every instruction. That isn't really much of a watchpoint then, unless you single step. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] another make install issue
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 -FuC:/FPC/SVN/trunc/rtl/units/i386-win32 -o -FuC:/FPC/SVN/trunc/packages/hash/units/i386-win32 -o -FuC:/FPC/SVN/trunc/packages/paszlib/units/i386-win32 -o -FuC:/FPC/SVN/trunc/packages/fcl-process/units/i386-win32 -o -FuC:/FPC/SVN/trunc/packages/fpmkunit/units/i386-win32 -o -FE. -o -FUunits/i386-win32 -o -di386 -o -dRELEASE --compiler=C:/FPC/SVN/trunc/compiler/ppc386.exe --prefix=c:\FPC\trunk\ --unitinstalldir=c:\FPC\trunk\/units/i386-win32/fcl-base -ie The installer encountered the following error: Failed to create directory c:\FPC\trunk \bin\ It appears that 2 issu8es play together. 1) the windows path delim is not translated 2) the \ followed by a space is interpreted as escaped space, and included in the path I will try without the trailing \ But imho that shouldn't fail, it's a perfectly legal path (afaik) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Try make.exe install INSTALL_PREFIX=c:\\FPC\\trunk COPYTREE=echo UPXPROG=echo It's a perfectly legal and valid path, but you've forgotten that make is a tool made mostly by C-programmers ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM vs Thumb2 - can't have both
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 you'll still need to know the RTL code pretty well. The build system isn't really very complex either. I personally see no reason to change the way it is Den 23-08-2011 16:01, John Clymer skrev: Digging some more around it today, came up with the following idea... In the rtl/embedded folder - there is the system file for ARM - it is ALL pascal - and compiles to either of Thumb2 or ARMV4 - but not both. In that folder's Makefile.fpc, the units to be built are listed - the could be switched to listing directories to get built. One folder for ARMV4, one for Thumb2. A system file and rtl.cfg file sits in each folder. The system file just bounces back down and includes the current system files from the rtl/embedded folder, but the library gets built in the core specific folder. That's the easy part, the more difficult part will to be to get the compiler to choose the correct system file. That is, the usual ARM folder where the libraries sit would need to have the same 2 seperate subdirectorie, the compiler would have to choose which one based on the core it's currently compiling for. John *From:* David Welch dwe...@dwelch.com *To:* FPC developers' list fpc-devel@lists.freepascal.org *Sent:* Tue, August 23, 2011 10:39:50 AM *Subject:* Re: [fpc-devel] ARM vs Thumb2 - can't have both Most if not all of my references to thumb meant the original ARMv4T thumb instruction set, definitely not the thumb2 extensions, nor ARMv5 or ARMv6 extensions. If for example you had a thumb backend to fpc, you could easily solve this problem, all of these libraries would run on both platforms, one compiler, one set of libraries, compiled one time. There is no thumb backend at the moment, this is the first problem to that solution. I figure most folks would not want to sink to the lowest common denominator. I would then recommend splitting the arm/arm7/ARMv4 architecture from the cortex-m3/ARMv7m, as implemented now they are two incompatible instruction sets. One instruction set happens to share the name of the company, move beyond that sticking point and create two architectures. The third alternative is do what others do and build two sets of libraries, one for each cpu type if that is the preferred term to distinguish arm and thumb2. Even if they are in the same library file but by name the linker extracts the arm cpu whatsit function from the thumb2 cpu whatsit function it is still two compilations of the whatsit function. You really have to pick one of those solutions, same instruction set or compile the libraries twice either as two arches build one or the other but not both, or two cpus within an arch and both/all cpus for an arch get built when the arch compiler is built. David On 08/22/2011 01:15 AM, John Clymer wrote: Yes, all my references of Thumb meant Thumb2. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org mailto:fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
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 your main fpc.cfg file to match those settings. I don't know precisely how that would be done on a unix system. Maybe it would even install directly to your current install directory, if you just run this? make buildbase OS_TARGET=embedded CPU_TARGET=arm CROSSOPT=-Cpcortexm3 CROSSINSTALL=1 sudo make installbase OS_TARGET=embedded CPU_TARGET=arm CROSSOPT=-Cpcortexm3 CROSSINSTALL=1 On a side note, I find it strange that it even accepts your old leftover files. I thought the linker normally would complain about interwork stuff ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
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 (1
MB each for now). Which means if the code size exceeds the space of
the device - the compiler/linker will not catch the overflow of the
available resource. (Running objsize on the ELF file will display
the sizes - so I just run that after every successful compile.)
As I pointed out, this will always fail because the stacktop is set
beyond the available ram. It will cause an exception I think. How do
you propose to be able to set the actual ram top for the generic part,
or am I missing something?
Also, still testing, but I have the interruptreserved word working
(more or less, more testing needed.) This takes the interrupt
codeword with an integer. The integer is the offset into the vectors
table. If no interrupt is provided for the given address, it
defaults to DefaultHandler in the startup file - which is just a
continual loop - so one can breakpoint on it. (This can be enabled /
disabled via a define in the source.) This is should only be enabled
for the embedded target - but I need to double check to ensure that
is the case.
This is a useful development; ideally the integer would be backed by
an enumeration as it is a big table. One thing which I did find
missing was the interrupt enable and disable assembler codes, so I
patched them with data bytes hidden in functions. The keil C compiler
does not like these if you link to units doing this (throws a
data/code wobbly). See the file attached to bug tracker ID0017365 for
how I hacked interrupts.
The CPS* instruction with the correct operand syntax was added in #18334
SVN trunk already has experimental support for the interrupt keyword.
It's enabled with FPC_HAS_SYSTEMS_INTERRUPT_TABLE in fpcdefs.inc. I
discovered a small bug with the current implementation which is fixed
with the attached patch(which also includes some other stuff... the
bugfix is in ncgutil. It didn't search the program file for interrupt
handlers before)
Index: compiler/fpcdefs.inc
===
--- compiler/fpcdefs.inc(revision 18784)
+++ compiler/fpcdefs.inc(working copy)
@@ -33,7 +33,7 @@
$define FPC_HAS_SYSTEMS_INTERRUPT_TABLE
to fpcdefs.inc to reactivate
the corresponding code }
-{$undef FPC_HAS_SYSTEMS_INTERRUPT_TABLE}
+{$define FPC_HAS_SYSTEMS_INTERRUPT_TABLE}
{ This fake CPU is used to allow incorporation of globtype unit
into utils/ppudump without any CPU specific code PM }
Index: compiler/ncgutil.pas
===
--- compiler/ncgutil.pas(revision 18784)
+++ compiler/ncgutil.pas(working copy)
@@ -3197,7 +3197,30 @@
end;
hp:=tused_unit(hp.next);
end;
+for i := 0 to current_module.symlist.Count-1 do
+ begin
+sym:=tsym(current_module.symlist[i]);
+if not assigned(sym) then
+ continue;
+if sym.typ = procsym then
+ begin
+for i2 := 0 to tprocsym(sym).ProcdefList.Count-1 do
+ begin
+pd:=tprocdef(tprocsym(sym).ProcdefList[i2]);
+if pd.interruptvector = 0 then
+ begin
+if pd.interruptvector high(interruptTable) then
+ Internalerror(2011030602);
+if interruptTable[pd.interruptvector] nil then
+ internalerror(2011030601);
+interruptTable[pd.interruptvector]:=pd;
+break;
+ end;
+ end;
+ end;
+ end;
+
new_section(current_asmdata.asmlists[al_globals],sec_init,'VECTORS',sizeof(pint));
current_asmdata.asmlists[al_globals].concat(Tai_symbol.Createname_global('VECTORS',AT_DATA,0));
{$IFDEF arm}
Index: compiler/pdecsub.pas
===
--- compiler/pdecsub.pas(revision 18784)
+++ compiler/pdecsub.pas(working copy)
@@ -2308,7 +2308,7 @@
idtok:_INTERRUPT;
pd_flags :
[pd_implemen,pd_body,pd_notobject,pd_notobjintf,pd_notrecord,pd_nothelper];
handler : @pd_interrupt;
- pocall : pocall_oldfpccall;
+ pocall : pocall_interrupt;
pooption : [po_interrupt];
mutexclpocall :
[pocall_internproc,pocall_cdecl,pocall_cppdecl,pocall_stdcall,
pocall_pascal,pocall_far16,pocall_oldfpccall];
Index: compiler/systems.pas
===
--- compiler/systems.pas(revision 18784)
+++
Re: [fpc-devel] Arm Thumb2 - Stellaris status
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 interpretation. I don't think it's really a vector. So currently vector 0 is for the reset vector at address 0x8004, and _stack_top is placed in front of the table 2) Each address should have the LSB set - to force Thumb mode when the PC gets loaded with that value. That's the linkers job. And it is handled correctly currently as long as the labels where they are pointing to are marked with the .thumb_func directive(as they are when using -Cpcortexm3) I defined FPC_HAS_SYSTEMS_INTERRUPT_TABLE a little further down - so that was only enabled on ARM and AVR (trying not to break other things...) I also have some added logic in ncgutil - for M3 devices - to place the stack_top into vector 0, then place handlers for vectors 1 to TOP. The WriteVector routine for Thumb also adds an offset of 1 to each vector - so as to force Thumb mode upon load to PC. You shouldn't add anything to get thumb vectors, as I explained further up. John ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
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 and see what comes up, otherwise limit my use to ARM targets, or start working on a thumb backend. Adding backends as well as arm embedded are of interest to me so I may work on a little of both. Why thumb support? The choices are indeed currently only either ARM or Thumb2(which is Thumb+32 bit extensions). Thumb2 is a variable length instruction set that looks like an arm+thumb mix, so I guarantee you that it works :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
instruction, but
doesnt make much sense
This does though, the start code from stm32f103.pp
.globl _start
.text
_start:
// Copy initialized data to ram
ldr r1,.L_etext
ldr r2,.L_data
ldr r3,.L_edata
.Lcopyloop:
cmp r2,r3
ittt ls
ldrls r0,[r1],#4
strls r0,[r2],#4
bls .Lcopyloop
The instructions the assembler was able to encode it did:
8000404:e59f103c ldrr1, [pc, #60]
8000408:e59f203c ldrr2, [pc, #60]
800040c:e59f303c ldrr3, [pc, #60]
8000410:e1520003 cmpr2, r3
8000414:94910004 ldrlsr0, [r1], #4
8000448:08000468 stmdaeqr0, {r3, r5, r6, sl}
800044c:2000 andcsr0, r0, r0
8000450:2048 andcsr0, r0, r8, asr
0x08000468 is the word aligned address for the end of the text segment
and 0x2000 the beginning of text for this example so that is
correct as well.
and interestingly the ittt ls instruction is discarded.
The code from stm32f103.pp
ldr r1,.L_etext
ldr r2,.L_data
ldr r3,.L_edata
.Lcopyloop:
cmp r2,r3
ittt ls
ldrls r0,[r1],#4
strls r0,[r2],#4
bls .Lcopyloop
when assembled should look like this
.text:
0:4904 ldrr1, [pc, #16]; (14 .text+0x14)
2:4a05 ldrr2, [pc, #20]; (18 .text+0x18)
4:4b05 ldrr3, [pc, #20]; (1c .text+0x1c)
6:429a cmpr2, r3
8:bf9e itttls
a:f851 0b04 ldrls.wr0, [r1], #4
e:f842 0b04 strls.wr0, [r2], #4
12:e7f8 bls.n6 .text+0x6
14:0001 andeqr0, r0, r1
18:0002 andeqr0, r0, r2
1c:0003 andeqr0, r0, r3
with different addresses of course...when assembled for thumb.
So it doesnt look like that is happening
Pascal main is definitely thumb+thumb2.
08000194 PASCALMAIN:
8000194:46ec movip, sp
8000196:e92d 4800 stmdbsp!, {fp, lr}
800019a:f1ac 0b04 sub.wfp, ip, #4
800019e:b08a subsp, #40; 0x28
More info about my setup:
svn info
URL: http://svn.freepascal.org/svn/fpc/trunk
Repository Root: http://svn.freepascal.org/svn/fpc
Repository UUID: 3ad0048d-3df7-0310-abae-a5850022a9f2
Revision: 18278
Node Kind: directory
Schedule: normal
Last Changed Author: florian
Last Changed Rev: 18278
Last Changed Date: 2011-08-19 18:06:52 -0400 (Fri, 19 Aug 2011)
Ubuntu 10.4 or something like that 64 bit host.
Linux dwelch-desktop 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29
21:07:13 UTC 2011 x86_64 GNU/Linux
fpc is what you apt-get so probably a little behind but stable in the
eyes of ubuntu or debian.
fpc
Free Pascal Compiler version 2.4.0-2ubuntu1.10.04 [2011/06/17] for x86_64
Copyright (c) 1993-2009 by Florian Klaempfl
/usr/lib/fpc/2.4.0/ppcx64 [options] inputfile [options]
Put + after a boolean switch option to enable it, - to di
GNU assembler (Sourcery G++ Lite 2011.03-42) 2.20.51.20100809
Copyright 2010 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-none-eabi'.
So what did I do wrong? and what is the unsafe thing about?
Thanks,
David
On 08/20/2011 11: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 will ride this along for a while and see what comes up,
otherwise limit my use to ARM targets, or start working on a thumb
backend. Adding backends as well as arm embedded are of interest to me
so I may work on a little of both.
Why thumb support? The choices are indeed currently only either ARM or
Thumb2(which is Thumb+32 bit extensions). Thumb2 is a variable length
instruction set that looks like an arm+thumb mix, so I guarantee you
that it works :)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
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 the future could mean this. Of course Cooper would be a way to support Android for framework based apps. Additionally, KSD (the name of FireMonkey before Embarcadero bought it) supports ARM Linux and it should be possible to make it run as a native application on an ARM based Android (same for x86 based Androids). Even if KSD or now FireMonkey supports ARM Linux this does not mean anything for Android. While Android does support native Linux applications it does not have a X server. Currently the only possibility for this is to run a X server through a VNC viewer and thus you can not reproduce the usual feel of an Android application. For that you'd need to write a Java bridge. Regards, Sven As far as I know VXScene is entirely userdrawn, so a native android application could just use OpenGL to draw the components. Android also has some support for a pixbuf object in native mode, which I guess could be used for the same My guess would be that this is the way QT does it too ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
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
file to add the generic type.)
Haven't looked into possibly a compiler option (and may easily be
more trouble than a command line option):
{$ARM_FLASH_START }
{$ARM_FLASH_LENGTH }
{$ARM_SRAM_START }
{$ARM_SRAM_LENGTH }
But, I still think a static memory definition file would require the
least amount of code changes. And would only effect only the ARM
related files.
The compiler option works well when you have conditional options for
different target builds using ifdefs, which I do I lot. It makes it
very easy to see if it is in the source file as it can be locked to
other options and you only need to select it in one place.
A separate linker file starts to make FPC handle like any other
compiler :( instead of the joy to use it is :)
I agree. Keeping the configurations in code is easier to manage,
compared to the spiderweb of magically named files of other embedded
compilers
I think that maybe creating an abstract class hierachy of chip families,
instead of the current solution of a single large case statement, would
be a better solution in the long run
Geoffrey
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
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 will have to share. But then comes the second question, how do you monitor something like that? If someone gets access to the Embacadero supplied compiler(and some of the professional people probably will), they can run a differential test suite run for ARM and see if they fixed any of the remaining problems :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
