Re: [fpc-pascal] Is RV32I instruction set for RISC-V (embedded) supported?
On 3/5/21 6:22 PM, Florian Klämpfl via fpc-pascal wrote: It is not expected that it works as RiscV support is still work in progress, but it should work ;) I'll look into it. Thank you. For me, the compiler for RV32I/RV32IMAC works already pretty well. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is RV32I instruction set for RISC-V (embedded) supported?
I saw your changes in revision 48881, downloaded latest trunk, compiled with make crosszipinstall CPU_TARGET=riscv32 OS_TARGET=embedded SUBARCH=rv32i but the problem remains: make[4]: Entering directory '/home/bernd/fpc/fpc331/48882/src/rtl/embedded' /bin/mkdir -p /home/bernd/fpc/fpc331/48882/src/rtl/units/riscv32-embedded /home/bernd/fpc/fpc331/48882/src/compiler/ppcrossrv32 -Ur -Cprv32i -Tembedded -Priscv32 -XPriscv32-embedded- -Ur -Xs -O2 -n -Fi../inc -Fi../riscv32 -FE. -FU/home/bernd/fpc/fpc331/48882/src/rtl/units/riscv32-embedded -Fl/home/bernd/riscv/riscv_2008/lib/gcc/riscv64-unknown-elf/10.1.0/rv64imafdc/lp64d -driscv32 -dRELEASE -al -Us -Sg system.pp @system.cfg /home/bernd/fpc/fpc331/48882/src/rtl/units/riscv32-embedded/system.s: Assembler messages: /home/bernd/fpc/fpc331/48882/src/rtl/units/riscv32-embedded/system.s:39578: Error: unrecognized opcode `mul x11,x11,x10' ... system.pp(311) Error: Error while assembling exitcode 1 system.pp(311) Fatal: There were 2 errors compiling module, stopping The compiler still seems to produce mul opcodes. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Is RV32I instruction set for RISC-V (embedded) supported?
Hello, I would like to use fpc to program a FPGA softcore RISC-V cpu. The softcore has the RV32I instruction set implemented. I modified the Makefile in rtl/embedded, so that the known SUBARCH rv32imac replaces the option -Cprv32imac with now -Cprv32i. But this leads to the following error message, when I try to compile the crosscompiler/rtl: /home/bernd/fpc/fpc331/48875/src/compiler/ppcrossrv32 -Ur -Cprv32i -Tembedded -Priscv32 -XPriscv32-embedded- -Ur -Xs -O2 -n -Fi../inc -Fi../riscv32 -FE. -FU/home/bernd/fpc/fpc331/48875/src/rtl/units/riscv32-embedded -Fl/home/bernd/riscv/riscv_2008/lib/gcc/riscv64-unknown-elf/10.1.0/rv64imafdc/lp64d -driscv32 -dRELEASE -al -Us -Sg system.pp @system.cfg /home/bernd/fpc/fpc331/48875/src/rtl/units/riscv32-embedded/system.s: Assembler messages: /home/bernd/fpc/fpc331/48875/src/rtl/units/riscv32-embedded/system.s:39578: Error: unrecognized opcode `mul x11,x11,x10' Is this expected, since RV32I is not supported, or should this work? Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point exception not always caught on Linux i386.
On 10/11/19 10:51 AM, Bart wrote: See https://www.freepascal.org/docs-html/current/prog/progsu69.html#x76-750001.2.69 sorry, I forgot to mention, that I checked with {$SAFEFPUEXCEPTIONS ON}, but it did not change the behavior. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Floating point exception not always caught on Linux i386.
Hello, FPC 3.0.4, Linux i386 the following program should catch the floating point exception (always), but crashes on the fourth call to the procedure Run: program test; {$mode objfpc}{$H+} procedure Run; var r: Real; i: Integer; begin i:= 1; try r:= i / 0.0; except r:= 0; // Crash here on fourth call. end; Writeln('ok'); end; begin Run; Run; Run; Run; end. The output: ok ok ok Runtime error 207 at $080480F9 $080480F9 $0804815C $0806644D The program was compiled with no additional compiler parameters. I could not reproduce this problem with the trunk version of the compiler, but all versions down to 2.2.2 show the described behavior. FPC 2.2.0 is working correct. The 64-bit version of FPC 3.0.4 works correct too. Is this something for the bug tracker? Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Coroutines and VirtualAlloc
On 04/20/2017 09:40 AM, Mark Morgan Lloyd wrote: Turning it around a little: are there still FPC targets that don't have threads? Having coroutines would allow a native thread mechanism to be implemented, without relying on the underlying OS. it would be really nice to have coroutines for the embedded targets like AVR and ARM. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ARM CMSIS support
Marc Santhoff wrote: Did you use the stmf103fw.pas translation from Jeppe or make you own unit for supporting the 429? I needed only a few peripherals (GPIO, USART, RCC and embedded FLASH). I wrote this stuff by myself. My target would be f407, although the project in mind has to be done using an Atmel SAM7 now, programmed in C... :| I used the AT91SAM7S256 controller 5 years ago (with fpc 2.3.1 btw). If I had to use ATMEL, I would look at the SAM3S or SAM4S family. They should replace the SAM7 which is now over 10 years old. But since ATMEL has been bought by Microchip, I would avoid them. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ARM CMSIS support
Michael Ring wrote: (Glad to hear that basic functionality works...) I finished my first (small) project with the STM32F429ZI controller and everything went smooth :-) Even with optimization level -O2. Thanks everyone, who is involved in the ARM compiler/rtl development. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ARM CMSIS support
Michael Ring wrote: By the way, with fpc trunc compiler you can target your board directly: ppcrossarm -WpDISCOVERYF407VG (see ppcrossarm -i for other Discovery boards) You should also refrain from using optimizations > -O1 as there are some issues with the compiler that make your compiled binary unusable. I have built the crosscompiler and the rtl for the STM32F429xx controller. Basic functions seem to work. By default, the rtl is compiled with optimization -O2. Should the rtl be better compiled with optimization -O1 too, if there are issues with the compiler? Or is the rtl not affected? What is recommended by the developers? Where bug reports accepted, if I use optimization -O2? Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Which compiler for ARM embedded project?
Hello, five years ago, I realized an embedded project with fpc 2.3.1. I used an AT91SAM7S256 Controller (ARMv4T). I am considering to use a more recent fpc compiler for a new project with the same controller. So my question: Which fpc compiler is recommended nowadays? Upcoming 3.0.0 or trunk? Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Text IDE, the displayed cursor position
Graeme Geldenhuys wrote: On 2013-03-01 14:03, Ebeling wrote: When I start a new program by clicking the button "new", the cursor stands in the upper left corner, but its position is displayed as "1:976". Just to confirm, I see the exact same thing under 64-bit FreeBSD using FPC 2.6.0 no problem with FPC 2.6.2 under (32-bit) Windows 98 ;-) Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Endian issues when porting FPC programs from x86 to other platforms
Jonas Maebe wrote: On 02 Nov 2010, at 21:39, Felipe Monteiro de Carvalho wrote: On Tue, Nov 2, 2010 at 7:04 PM, Bo Berglund wrote: Thanks, that helps a lot! Are there also overloaded BEtoN functions for floating point values? I think that single and double have always the same binary layout. That's incorrect, their endianess changes in the same way as that of integer data (except on ARM when using the FPA floating point unit, which uses its own special byte ordering). on ARM/OABI with double precision Netwinder FPE it is little endian with low and high dwords swapped. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Strange WinCE Bug
Felipe Monteiro de Carvalho wrote: What do you recommend? Simply creating a report? http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?os=17&cpu=6&version=0&date= it looks, as if 2.4.x was not so well tested on Wince. Perhaps you could run the test suite and see if it is a compiler problem. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Holger Bruns wrote: Holger Bruns schrieb: I try to implement a direct port access. If this also leads to access errors, I should give it up. Embarassing. Accessing ports is limited to ports < 03ffh, more ports cannot be released with fpioperm. This means to me, successful serial port access on higher addresses cannot yet be implemented with fpc. If this policy can be ruled out, let me know. so you must use a very special serial hardware which is located on io address higher than $3ff. Seems unlikely to me. In your former post, you tried to access io address 1000 (decimal) this is $3e8 (hexadecimal) and should be an ordinary COM3. May be you are mixing up decimal vs. hexadecimal notation. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] test suite, TEST_REMOTEOPT
Hello, I could not pass the test suite option TEST_REMOTEOPT to the makefile. I tried TEST_REMOTEOPT=xxx and "TEST_REMOTEOPT=xxx" both did not work on Win32. I changed the makefile a bit and it works now for me. Don't know, if this is a proper patch: Index: tests/Makefile === --- tests/Makefile (Revision 12568) +++ tests/Makefile (Arbeitskopie) @@ -1528,7 +1528,7 @@ qec...@echo $(1) endif ifdef TEST_REMOTEOPT -override DOTESTOPT+="-U$(TEST_REMOTEOPT)" +override DOTESTOPT+=-U$(TEST_REMOTEOPT) endif ifdef TEST_PUTTY override DOTESTOPT+=-R$(TEST_PUTTY) -W Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
Marc Santhoff wrote: Am Dienstag, den 09.12.2008, 09:53 +0100 schrieb Marco van de Voort: In our previous episode, Marc Santhoff said: some small THUMB things, but FPC doesn't generate THUMB code). One possible difference coming to my mind (although only a speed issue, not influencing nonetheless working code): There are some ARM7 (and maybe ARM9, not sure) core variants having no hardware multiplication unit. IIRC the M in TDMI stands for "hardware multiplier unit". Experiences with gcc showed me that the 32x32=64 mult commands are not used in that case. Wikipedia also calls ARM7 ARMV3 arch, and only ARM7TDMI ARMV4. This could be the reason why. (and maybe the D and the I) It would be nice to have the chance of setting some extra command line arguments to the call to the assembler - I think that is what Riley is is asking for. The trick is that if you give FPC that info, it can check both code generated and the assembler reader, and do the same AND provide a valid source line. IOW, I don't see a good reason to do this in the backend assembler, if it can be better done in the frontend. Since I've been enlighted that I'm mistakenly ignored the fact that fpc does the code generation and since ARM v4 is only mentioned on ARMs web site as an ancient architecture mostly faded away I'm strongly with you: http://www.arm.com/products/CPUs/architecture.html Citation: "ARMv4 The oldest version of the processor architecture supported today. All previous versions are now obsolete. Implementations include some members of the ARM7™ processor family and Intel StrongARM® processors. ARMv4 can be considered a 32-bit ISA operating in a 32-bit address space." Maybe, the fancy pictures on the ARM website concerning the ARM architectures could lead to the assumption, that ARMv4 is mostly faded away ;-) But this is not correct. A lot of ARM7 embedded controllers are ARMv4 devices, including ATMEL AT91SAM7x, NXP LPC2x and STM STR7x. FPC targets them perfectly. BTW the Openmoko Neo 1973 and Neo FreeRunner use a Samsung S3C2442 (ARM9) which is ARMv4 too. The compiler(s code generator) should take care of target cpu variants and architectures. I think, this would be a lot of work. Which architecture should be implemented first? ARMv5 or better the latest ARMv7 (CORTEX) variants. But what about the Thumb/Thumb-2 instruction set? Also very interesting. From my point of view the current situation with FPC/ARM is pretty good. And if someone really needs architecture specific implementations, he could try to add these features to the compiler. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
Bernd Mueller wrote: Aleksa Todorovic wrote: So, the situation is like this: 1) Target ARM architecture needs to be "told" to FPC since FPC needs this information to do correct code generation. At least up to fpc 2.2.2, the compiler does not use any information about the ARM architecture. There is one runtime check in the RTL which tries to detect if the architecture is newer than ARMv4. If this is the case, the RTL uses an optimized move function. the RTL for ARM-Linux, I forgot to mention. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
Aleksa Todorovic wrote: So, the situation is like this: 1) Target ARM architecture needs to be "told" to FPC since FPC needs this information to do correct code generation. At least up to fpc 2.2.2, the compiler does not use any information about the ARM architecture. There is one runtime check in the RTL which tries to detect if the architecture is newer than ARMv4. If this is the case, the RTL uses an optimized move function. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bus error in ARM architecture
Florian Klaempfl wrote: They also asked me to send them some code which illustrates the problem, which they claim should not exist because the compiler should make sure everything is aligned. FPC does too as long as you don't force the compiler to use a certain memory layout like using the packed keyword or casting unaligned pointers like plongint(13)^:=1234; what do you think about http://bugs.freepascal.org/view.php?id=12137 ? IMO the unaligned directive should not be required in this case to "fix" the bug. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] arm-linux, no bus error on misaligned data access
Daniël Mantione wrote: echo 4 > /proc/cpu/alignment ... and your program should abort at any unaligned access. Daniël, thank you very much. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] arm-linux, no bus error on misaligned data access
Hello, my ARM-Linux board seems to be resistant against bus errors/misaligned data access or the compiler does some magic to prevent these ;-) It would help me, to debug a program, when my board would abort with an error message, so that I can isolate the bug. Does someone know, if there exists something like a Linux option do disable/enable data aborts? Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] arm-linux, using unit cthreads fails
Hello, the following program is throwing an Access Violation on my system (ARM920T, uClibc): program project1; {$mode objfpc}{$H+} uses cthreads, SysUtils; function TheThread(pAnyArgument: Pointer): Longint; begin repeat Sleep(1000); until FALSE; end; begin Writeln('Running...'); BeginThread(@TheThread, NIL); repeat until FALSE; end. This is the error output: # ./project1 Running... An unhandled exception occurred at $40082E50 : EAccessViolation : Access violation $40082E50 of ../objpas/sysconst.pp $0001CA04 BEGINTHREAD, line 104 of D:/fpc231/9749/src/rtl/inc/thread.inc $0001C988 BEGINTHREAD, line 81 of D:/fpc231/9749/src/rtl/inc/thread.inc $00010434 main, line 21 of project1.pas $4005D6B4 of ../objpas/sysconst.pp I crosscompiled the program with fpc 2.3.1 and following parameters: ppcrossarm.exe -S2cgi -TLinux -Parm -gl -vewnhi -l -Fu. -oproject1 -XRpathtodynlinker\gcc-4.1.2-uclibc I tried to debug this and am stuck now in cthreads.pp. line 289: if pthread_create(ppthread_t(@threadid), @thread_attr, @ThreadMain,ti) <> 0 then The program is crashing within the execution of pthread_create Using pthreads alone is working fine BTW. I can live with pthreads, but I would like to know, what is going wrong. Thanks for any hints and pointers. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] arm-linux, program does not start when using unit pthreads
Koenraad Lelong wrote: Bernd Mueller schreef: Koenraad Lelong wrote: I tried on my arm-linux board, AFAIK NOT uClibc. It works fine. Thanks. Are you crosscompiling? Do you use static or dynamic linking? Regards, Bernd. When I read you reply about linking I realised I didn't think about the fact that the linker would remove unused units (does it, without adding smartlining ?). Sorry about this. I crosscompiled the program with dynamic linking, at least I didn't add a switch for static linking. Maybe you can send me you command-line. Dynamic linking seems to work for me now too. It was mainly a linker issue. Thanks. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] arm-linux, program does not start when using unit pthreads
Koenraad Lelong wrote: I tried on my arm-linux board, AFAIK NOT uClibc. It works fine. Thanks. Are you crosscompiling? Do you use static or dynamic linking? Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] arm-linux, program does not start when using unit pthreads
Bernd Mueller wrote: when I try to start a simple "Hello"-Program, which uses the unit pthreads, on an arm-linux target (uClibc), I get the message "not found". The program is crosscompiled from win32, using the fpc 2.2.0 compiler: program project1; {$mode objfpc}{$H+} uses pthreads; begin Writeln('Hello'); end. There seems to be a problem with the shared libraries. I checked the directory /lib for the libraries and symlinks, but the required libraries seem to be present. the reason for the "not found" message was, that the dynamic linker on my target was not found. I fixed that, but I get now an Segmentation fault :-( I fear this one will be hard to find. Thanks. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] arm-linux, program does not start when using unit pthreads
Hello, when I try to start a simple "Hello"-Program, which uses the unit pthreads, on an arm-linux target (uClibc), I get the message "not found". The program is crosscompiled from win32, using the fpc 2.2.0 compiler: program project1; {$mode objfpc}{$H+} uses pthreads; begin Writeln('Hello'); end. There seems to be a problem with the shared libraries. I checked the directory /lib for the libraries and symlinks, but the required libraries seem to be present. ldd project1 checking sub-depends for '/lib/libpthread.so.0' checking sub-depends for '/lib/libc.so.0' libpthread.so.0 => /lib/libpthread.so.0 (0x) libc.so.0 => /lib/libc.so.0 (0x) /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x) Then I compiled a gcc "Hello"-program with the library pthread linked in. This program runs fine. This is the ldd output: ldd p libpthread.so.0 => /lib/libpthread.so.0 (0x4000e000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40028000) libc.so.0 => /lib/libc.so.0 (0x40038000) ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x4000) I am also wondering about the differences in the address fields of the ldd ouput. All fpc address fields are set to 0x, while the gcc address fields have different values. Thank you for any hints and pointers. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] serial.pp - I can't talk to modem
Graeme Geldenhuys wrote: Uh, it works!!! Thanks a million Bernd. If you ever come to South Africa, look me up, I owe you a beer. :) thanks four your invitation, unfortunately I am not living around the corner (Germany). So don't expect me in the next couple of days ;-)) Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] serial.pp - I can't talk to modem
Graeme Geldenhuys wrote: SerWrite(serialhandle, s, Length(s)); SerWrite(serialhandle, s[1], Length(s)); Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpc 2.2.0, trying to install as none root on Linux
Hello, I have downloaded fpc-2.2.0.i386-linux.tar, decompressed the archive and run the install script ./install.sh as none root. The script prompts the following message: "Install prefix (/usr or /usr/local) [/home/bernd/fpc-2.2.0]:" I read the manual and expected to answer some simple questions. I think, it is my lack of Linux experience, but is not clear to me, what I should enter now. I would like to install the compiler/rtl/docs into /home/bernd/fpc220 and leave the rest of the system completely untouched. Is this possible? If yes, what do I have to enter? Thanks. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 0.9.24 released
Mattias Gaertner wrote: The Lazarus team is glad to announce the 0.9.24 release. This release is based on fpc 2.2.0. Thank you. I used the 0.9.20 since November 2006. The progress you did with the 0.9.24 is huge. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freepascal 2.2.0 released
Joost van der Sluis wrote: The Free Pascal Compiler team is pleased to announce the release of FPC 2.2.0! Congratulations and thank you very much. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Arm EABI vs OABI [was:DateToStr in arm does not work!]
Luca Olivetti wrote: En/na Henry Vermaak ha escrit: i urge you to read this: http://wiki.debian.org/ArmEabiPort http://www.codesourcery.com/gnu_toolchains/arm/faq.html i haven't completely read it (hence i can't answer your questions that well, sorry). I'm wondering if my strange problems are due to a badly built compiler and/or rtl. you did not mention a third possibility: the compiler itself has some serious issues. See the various bug reports in the mantis bug tracker. I know for sure that my kernel (that I cannot upgrade at the moment) supports OABI and has EABI badly patched in (i.e, it doesn't work 100%), everything else should be OABI (debian arm, not armel). To build 2.1.4 I used a binary snapshot of 2.1.3 (ftp://ftp.freepascal.org/pub/fpc/beta/2.1.2/arm-linux/) and did not specify any special option while building, so, what convention is my compiler/rtl using? Is it possible that it's generating EABI and hitting sometimes the special cases that don't work in my kernel? In that case, how should I rebuild it in order to generate OABI code? I guess that fpc does not care about OABI/EABI. The compiler ether generates fpu opcodes or not (when floating point is used). This depends on the -CfSOFT option while building the compiler/rtl. Perhaps one of the developer can confirm or deny this. Thanks. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateToStr in arm does not work!
Luca Olivetti wrote: En/na [EMAIL PROTECTED] ha escrit: Luca, > could you check bug 9191? > > http://www.freepascal.org/mantis/view.php?id=9191 if I try to compile, the linker complaints about not finding the object dl, though dl.o and dl.ppu are present in the rtl/units/arm-linux directory. D:\FPC214\B1\BINUTI~3\arm-linux-ld.exe: cannot find -ldl pippo.pas(47,6) Error: Error while linking pippo.pas(47,6) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted How do you call the compiler? And please show me your fpc.cfg file. I do simply an "fpc pippo.pas" (or "fpc pippo2.pas"), I'm running it directly on the arm, I'm not cross-compiling (that's why I asked you, I wanted to see if cross-compiling makes a difference). My fpc.cfg is what the installer for 2.1.3 generated, manually amended for 2.1.4 (consider that fpc is installed under /home/luca/fpc-2.1.4). It's attached. I finally got your program crosscompiled on my windows machine. But if I start it on the linux target, I get the output "not found". I think, I made something wrong, when I tried to resolve the library .so symlinks. Another problem was, that my ARM Linux uses uClibc and not libc, so the linker complaint about some missing references in cprt0. I made changes in cprt0.as and recompiled the rtl. I need more time (and experience) to track this problem down. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateToStr in arm does not work!
Jonas Maebe wrote: The -ldl refers to libdl.so, not to dl.o. You have to copy it from your ARM system to your Windows machine, and add the directory with all your ARM libraries to the linker's search path, like Luca did: -Fl/usr/lib/gcc/arm-linux-gnu/4.1.2 thank you Jonas, that was helpful. I finally was able to compile the file, but I think there is still a problem with the libraries. The program does not run as expected. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateToStr in arm does not work!
josepascual wrote: Hi Everyone; Please, can someone test this program and write to the list if it works in arm-linux. program datetostr_test; uses sysutils; begin writeln(datetostr(now)); end. I always receive An unhandled exception occurred at $BEED89C8 : EAccessViolation : Access violation $BEED89C8 if for someone this program work, please write me with your Fpc for arm version. the program works for me. FPC 2.1.4 compiler built without softfloat option, running on an (little endian) ARM processor without fpu on Linux, kernel version 2.6.21.1 (OABI). ppcrossarm -gl datetostr_test.pas Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateToStr in arm does not work!
Henry Vermaak wrote: On 03/07/07, josepascual <[EMAIL PROTECTED]> wrote: Thank you henry, I have downloaded svn version 7943 how can I donwload svn 7929? How are you build fpc for arm? make clean crossall CPU_TARGET=arm OS_TARGET=linux ? Which version of binutils do you have? (eabi?) Is SOFTFLOAT in freepascal the equivalent to EABI in c? soft float just means that the compiler needs to emulate the floating point unit if it doesn't exist in your hardware (like some arm processors). if you have an fpu, then you don't have to worry about soft float. Are you sure? If I remember right, using softfloat in conjunction with fpc means, that the compiler never emits floating point operations. All the floating point is going through the softfpu unit. This means, *if* you have a fpu, you waste speed. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ARM-Linux, building RTL fails
Hello again, with latest Trunk, Rev. 7387, building of the ARM-Linux RTL fails: ppcrossarm.exe -Tlinux -Parm -XParm-linux- -Xc -Xr -Fi../inc -Fi../arm -Fi../unix -Fiarm -FE. -FU../../rtl/units/arm-linux -Tlinux -CX -darm -Us -Sg system.pp softfpu.pp(122,12) Error: Duplicate identifier "UInt64" system.pp(52,34) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Removing UInt64 in softfpu.pp or in systemh.inc seems to solve the problem. seems to be related to bug entry 8860 (fpc complains:UInt64 not found). Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] ARM-Linux, building RTL fails
Hello, with latest Trunk, Rev. 7387, building of the ARM-Linux RTL fails: ppcrossarm.exe -Tlinux -Parm -XParm-linux- -Xc -Xr -Fi../inc -Fi../arm -Fi../unix -Fiarm -FE. -FU../../rtl/units/arm-linux -Tlinux -CX -darm -Us -Sg system.pp softfpu.pp(122,12) Error: Duplicate identifier "UInt64" system.pp(52,34) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Removing UInt64 in softfpu.pp or in systemh.inc seems to solve the problem. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] LongWord
Jonas, On 7 mei 2007, at 14:15, Carsten Bager wrote: I have written a small demo program that gives a runetime error when it runs. Is it the compiler or is it me? See http://www.freepascal.org/mantis/view.php?id=8321 for a long discussion on this topic. I think I have hit a similar case with the following code: {$mode objfpc}{$H+} program test; { FPC 2.0.4} var w: Word; begin w:= ; if lo(w) <> lo(w + (5 - 5)) then writeln('This is a little bit unexpected'); end. What would you suggest as a "workaround"? Using the mod operator? Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Flushing serial inqueue on Linux
I can read incoming characters, so the connection is ok and lHandle is valid. I tried TCIOFLUSH as another QueSelector and tried also ioctl instead of Fpioctl. termio.tcflush but that does fpioctl(fd,TCIOflush,pointer(qsel)); TCFlush is working now. Thank you. my problem with fpioctl was the third parameter qsel. In my first attempts I tried something like fpioctl(fd,TCIOflush,@qsel); which does compile with no warning but does not work. the pointer type cast is the correct way: fpioctl(fd,TCIOflush,pointer(qsel)); Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Flushing serial inqueue on Linux
I can read incoming characters, so the connection is ok and lHandle is valid. I tried TCIOFLUSH as another QueSelector and tried also ioctl instead of Fpioctl. termio.tcflush but that does fpioctl(fd,TCIOflush,pointer(qsel)); TCFlush is working now. Thank you. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Flushing serial inque on Linux
Hello, I am trying to flush the serial inque on Linux with no success. So far I have: procedure FlushInQue(lHandle: Longint); var QueSelector: Longint; begin QueSelector:= TCIFLUSH; Fpioctl(lHandle, TCFLSH, @QueSelector); end; I can read incoming characters, so the connection is ok and lHandle is valid. I tried TCIOFLUSH as another QueSelector and tried also ioctl instead of Fpioctl. BTW, I am new to Linux (Ubuntu 6.06) and not really sure, which units I have to include: baseunix, oldlinux unix. I tried several combinations. Thanks, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Short introduction
Hello, my name is Bernd Mueller. My favourite programming languages are Pascal (since Turbo Pascal 3), x86-Assembler and C. I design and program Embedded Systems (mostly x86, M16C, x51, AVR and now ARM9/ARM7). I am using FreePascal since about one year and I am impressed by the quality of the compiler. Thank you. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal