[fpc-devel] co-processor offset out of range issue in Debian armhf.
mricron is failing to build for Debian armhf, specifically we are getting a bunch of "co-processor offset out of range" errors. (9009) Assembling parconvert parconvert.s: Assembler messages: parconvert.s:3775: Error: co-processor offset out of range parconvert.s:3783: Error: co-processor offset out of range parconvert.s:3880: Error: co-processor offset out of range parconvert.s:3886: Error: co-processor offset out of range parconvert.s:3892: Error: co-processor offset out of range parconvert.s:3895: Error: co-processor offset out of range parconvert.s:3899: Error: co-processor offset out of range parconvert.s:3903: Error: co-processor offset out of range parconvert.s:3918: Error: co-processor offset out of range parconvert.s:3924: Error: co-processor offset out of range parconvert.s:3930: Error: co-processor offset out of range parconvert.s:4813: Error: co-processor offset out of range parconvert.s:4817: Error: co-processor offset out of range parconvert.s:4821: Error: co-processor offset out of range parconvert.s:4825: Error: co-processor offset out of range parconvert.s:4895: Error: co-processor offset out of range parconvert.s:4899: Error: co-processor offset out of range parconvert.pas(1375) Error: (9007) Error while assembling exitcode 1 parconvert.pas(1375) Fatal: (10026) There were 2 errors compiling module, stopping Fatal: (1018) Compilation aborted The first error corresponds to the vstr instruction on line 3775 below: # [593] lScanResX := round(readParFloat); movr0,r11 blxPARCONVERT$_$READ_PAR2NII$crcDDE5A164_$$_READPARFLOAT$$DOUBLE blxfpc_round_real blxfpc_int64_to_double vmov.f64d1,d0 subr0,r11,#143360 vstrd1,[r0, #-2528] Which in turn, corresponds to line 593 of parconvert.pas: if lUpCaseStr = 'SCANRESOLUTION(XY)' then begin lScanResX := round(readParFloat); lScanResY := round(readParFloat); More detail at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851834 Any thoughts on what might cause this or possible fixes? my guess is that the compiler is missing an offset range check for access to local variables. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug#789091: fpc: ncurses/form unit declares internal libform objects
On 17/06/15 19:06, Sven Joachim wrote:
Source: fpc
Version: 2.6.4+dfsg-6
The file fpcsrc/packages/ncurses/src/form.pp declares the objects
_nc_Default_Form and _nc_Default_Field:
,
| (* Default objects *)
| {$ifndef darwin}
| _nc_Default_Form : PFORM;cvar;external;
| _nc_Default_Field : PFIELD;cvar;external;
| {$else darwin}
| _nc_Default_Form : PFORM external libform name '_nc_Default_Form';
| _nc_Default_Field : PFIELD external libform name '_nc_Default_Field';
| {$endif darwin}
`
There does not seem to be a good reason to do so, those symbols are not
part of the ncurses form API and will go away from the shared form
library soon, see #788610.
Apparently those two symbols are still in the libform.a library, so as
long as fpc does not support dynamic linking (#472304) there should not
be a problem,
This statement is incorrect, fpc doesn't dynamically link it's own run
time library but it most certainly can and does dynamically link C
libraries.
but please remove these useless declarations and ask
upstream to do the same.
Freepascal upstream: any comments on this?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Android crashes in Tegra CPUs
Sergio Flores wrote: Eg: Calling lnxp1(x) with x>1 results in a SIGILL crash. . I've got an Android app in Play Store with around 300 thousand downloads, and from what I've gathered, this crash happens in any Tegra based device, and only on those. AIUI many tegra devices don't support neon, I wonder if a neon instruction is being used either because of incorrect compiler settings or because of incorrect inline assembler code. If this was happening on regular linux i'd suggest using gdb to get a backtrace and a dissasembly of the sigill location but i'm not sure how possible that is on andriod or how easy it is to get a suitable tegra device running regular linux to experiment on. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Regionalisation (Was ThousandSeparator)
Hans-Peter Diettrich wrote: 2) Formatted numbers, as enterd by the user (maybe by copy&paste from other applications), can have various encodings. Before a conversion into binary values I'd remove all unexpected characters, except for the last (rightmost) '.' or ',', which then becomes the decimal separator as expected by the decoding function (RTL provided). I don't see any reason why thousand seperators can't/shouldn't be to the right of the decimal seperator, nor any reason why a number with a thousand seperator also has to have a decimal seperator. So your algorithm would produce wrong answers in many cases. Which brings us to the root of the problem, some numbers are simply ambiguous without knowing the conventions used by the people who wrote them. is 1,000 one or one thousand? This isn't a problem limited to programming, when doing electronic design I often find myself dealing with datasheets where the authors have translated the text into english but have not translated the numbers to the english conventions. Ususally a human can make an educated guess based on the expected magnitude of the number but it still throws you at first. 3) For all other (non-GUI) purposes a unique string format is used, according to the conversion functions used by the compiler. This means no thousands separator, and a '.' decimal separator. Which for an existing program means digging through your code to find every single decimal conversion and making the judgement call as to whether it's UI related or storage related and deal with the awkward situation that some scenarios (for example reading data from text files whose format is designed by others or which were written by previous versions of your program before you started taking this seriously) may require special handling or even asking the user which interpretion is correct. I'm not surprised some programmers give up and tell users to set their systems to english mode and follow english conventions. Mainland europeans (which afaict are the main case which causes ambiguity) are a fairly significant market but losing them is probablly not a deal breaker for many developers But back to the original problem: I managed to create another user, whose number format settings match the expections of the Ez-Builder, while using my German keyboard. For Linux users this may sound like an easy job, but adding and configuring users in Win8 turned out as kind of a nightmare :-( Win8 requires an eMail address for every new user, but entering a fake address only allows to create the account, without any chance to log in subsequently. Probably the requested password has to be established by mail, at least I found no way to disable or specify or reset the password for the new account. Fortunately I had retained an Guest account, could log in and adjust the format settings as prescribed, and then could successfully start Ez-Builder. After all I hope that these problems are due to the cheap (Premium?) version of my Win8, that is *intentionally* crippled in several ways. From what i've heard there is a way to create a local only user in win8 but it's fairly hidden. Conclusion: Proper handling of separators in formatted numbers is essential, or else users may run into so big trouble, that they will drop your program as unusable. The problem is proper handling is HARD. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Thaddy de Koning wrote: Not for ARMV6 EABIHF Building for ARMV6+vfpv2 armhf is indeed a bit of a messs. Afaict it's not possible to build a cross compiler that defaults to armv6 ARMHF without modifying the source. With the right flags you should be able to create a cross-compiler that is armhf but defaults to ARMv7 and then with the right flags to that you should be able to build a native armv6 armhf compiler using it but I have never tried this. Since you seem to think we are keeping stuff secret I should say how things were actually bootstrapped for debian/raspbian. The initial armhf port I did (of then-current trunk) was done on an armv7 system. using a debian armel build of 2.6.0 and manually setting -dFPC_ARMHF. This was easier at the time than it is now because iirc debian hadn't yet moved the system libraries to multiarch paths. Once my change was accepted into trunk I then backported the changes to 2.6.0 and packaged them in debian. Later debian armhf packages were simply built using the existing debian packages. I did have to make a small change to get 2.6.2 armhf to build with 2.6.0 armhf. The raspbian packages were based on the debian packages and added a further patch to the source to change the default target to armv6+vfpv2. The intial raspbian packages were built using the debian armhf packages, later raspbian packages were built using previous raspbian packages. Meanwhile over in trunk fpk (iirc) added a patch to make the compiler default to targetting armv6+vfpv2 if the compiler itself was built for armv6. A trunk compiler built to target armhf and running on any other CPU will default to targetting armv7+vfpv3_d16. Someone also added code to make fpc look for libraries in multiarch paths on armel and armhf (despite me having been previously told that we should use fpc.cfg and the fpc maintainers wouldn't do this). You can sometimes get away with using armhf libraries with an armel compiler if you don't care about any C library calls that involve floating point being broken. Certainly enough worked for the threaded tools used in the FPC build process to work. IMO there should be an option to the FPC build to build without linking against C libraries, it's kinda crazy that we have to screw arround with the source to do it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Pierre Free Pascal wrote: https://archive.raspbian.org/raspbian/pool/main/f/fpc/ The 2.6.4 release is able to successfully compile a 2.7.1 trunk compiler. :) Thanks for confirming. Several files are missing in this source release: The source package which is made up of fpc_2.6.4+dfsg-4+rpi1.dsc , fpc_2.6.4+dfsg-4+rpi1.debian.tar.xz and fpc_2.6.4+dfsg.orig.tar.gz does contain the files you mention. To extract it you use dpkg-source -x on the dsc file. This is the source used to build the deb files. The "binary" package fpc-source exists primerally for the benefit of lazarus users, it appears to contain more than is needed for lazarus use but not enough to actually build the compiler which does seem a bit strange. This is not raspbian specific, the packages in debian are the same way. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
>> deb http://plugwash.raspbian.org/wsf wheezy-wsf main Thanks. So what exactly does it do? How does one access? It's an apt repository I just set up for fixes to dependency problems caused by the foundations webkit-related packages (they shipped an updated webkit and a load of related updates including things like gcc and binutils) Just for wheezy or will it work on jessie too? John Jessie already has the fix in question (and a version of binutils that needs the fix) in it's normal repository ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
peter green wrote: So it would seem FPC is currently broken on stable Raspbian which is a pity. It's fine on plain raspbian, unfortunately it seems that the raspberry pi foundation are shipping a newer version of binutils which conflicts with the fpc packaging from wheezy. Since the breakage is not related to plain raspbian I won't be putting a fix for this in the main raspbian repository but I intend to set up a repository for fixes to raspberry pi foundation screwups soon and i'll post a url for that when it's ready. Done deb http://plugwash.raspbian.org/wsf wheezy-wsf main ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Paul Michell wrote: On Tuesday 21 Oct 2014 13:45:25 John Lee wrote: Don't know why you have this problem with wheezy, but can confirm I'm running rpi jessie, and the 'sudo' sequence above works for me ok ie does 70Mbyte download & installs fpc with no errors. Haven't really tested it, but help says it is 2.6.2 -8 rpil+b2 2014/7/21 for arm. john I have just done a dist-upgrade and tried again and as you say, I now have an installed 2.6.2. Raspbian jessie should have 2.6.4 soon (it's already in raspbian jessie-staging..). Raspbian wheezy will be staying with 2.6.0 So it would seem FPC is currently broken on stable Raspbian which is a pity. It's fine on plain raspbian, unfortunately it seems that the raspberry pi foundation are shipping a newer version of binutils which conflicts with the fpc packaging from wheezy. Since the breakage is not related to plain raspbian I won't be putting a fix for this in the main raspbian repository but I intend to set up a repository for fixes to raspberry pi foundation screwups soon and i'll post a url for that when it's ready. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Paul Michell wrote: I should probablly get arround to doing a raspbian version of 2.6.4. Yes please :) Ok, i've just uploaded 2.6.4 https://archive.raspbian.org/raspbian/pool/main/f/fpc/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
John Lee wrote: I'll do same for 2.6.x too. Note that plain 2.6.x doesn't support armhf, in debian/raspbian we have a patch adding support. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Paul Michell wrote: I'm currently trying to build 2.7.1 from SVN on the latest Raspbian (2014-09-09). I've previously built this with either 2.6.0 from the repository, or with Thaddy de Koning's build from March 2014. Currently, neither of these will build 2.7.1 on a Raspberry Pi. So I have also tried with the generic arm-linux release archive (fpc-2.6.4.arm-linux.tar). This installed without error and I can compile projects on the Pi with it. What errors are you getting when you try to build with the fpc from the repository. Have you tried the 2.6.2 version from raspbian jessie? I should probablly get arround to doing a raspbian version of 2.6.4. However, when trying to build 2.7.1 (make all) it creates a compiler binary, but fails whilst compiling fpmake. This looks similar to the bug 0024056 which is flagged as resolved. The solution suggested there is to install build-essential, but this is installed by default on Raspbian, so I think there must be something else wrong? Most likely you are trying to build an armel compiler rather than an armhf one. It may be possible to bootstrap an armhf compiler off an armel one with the right settings but it's something I haven't tried in a while. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
Vsevolod Alekseyev wrote: It's your compiler; take it in any direction you want. I'm just surprised that Peter Green's first thought when I say "ARM" is "Raspberry". When I did the armhf port I was targetting it at arm linux hence I fitted it into the exiting frameworks used for arm linux. I have no idea on the status of other arm ports because they aren't platforms I personally care about. I made my post to correct various misconceptions about the port that were flying arround on the list, for example the fact that some people thought it was a new "CPU target". ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARMHF a separate CPU? Why?
Vsevolod Alekseyev wrote: Does Free Pascal really treat ARMHF as a separate CPU target, It didn't when I initally implemented it and from a quick look at the code it doesn't now. What it does do is a little hacky but it followed the pattern of what was already done and a cleaner soloution would have required more radical changes. distinct from regular ARM? May I ask why such design? In the grand symphony of native code generation, the floating point calling convention sounds, to me, as a much smaller detail than, for example, ARM vs Thumb or PIC vs. non-PIC or floating point mode per se. Indeed from a code generation point of view those are probablly more significant. On the other hand from a compatibility point of view they are far less significant, you can mix code that uses arm with code that uses thumb, you can mix PIC code with non-PIC code and you can mix code that uses the FPU with code that does floating point in software with code that uses the fpu (though IIRC fpc blocks the latter on arm eabi for no good reason). You can't really mix code where the c calling convention is different. You could in principle have a mode where the "cdecl" calling convention used to interact with c libraries put floating point values in integer registers while the calling conventions that are only used within pascal code used floating point registers but I haven't seen anyone propose implementing that. Yet the latter features are mere options within the ARM target. To understand the setup tets start from from a premise, namely that native compilation needs to "just work", if I build or download a native compiler for "platform x" I expect it to produce binaries that will work correctly (though they may not be optimal) on "platform x" without the need to be explicitly told how to do so at runtime. Cross compiling is a different case, those doing crossbuilds generally expect to have to do some manual configuration to get a working environment. A freepascal compiler built for a given OS will target that OS by default and each compiler only targets one CPU family. In most cases this just works, for most CPUs and operating systems that freepascal cared about the combination of OS and CPU locked down the ABI to one choice. Unfortunately arm linux is an exception to this, there have been at least four different ABIs targetted by freepascal for arm linux and all of them have been used on systems that are more than capable of running native compilers. The way this is handled is a bit hacky, each ABI has a #define (FPC_OARM, FPC_ARMEL, FPC_ARMEB and FPC_ARMHF), when building the compiler this #define it will set the default ABI and a few other things (default linker script paths, default fpu). If none of the above defines are defined and a native compiler is being built then the setting will be inherited from the abi the compiler is being built for. If a crosscompiler is being built then the default is FPC_ARMEL. I did not introduce this system, I merely expanded it to add armhf to the supported variants. At least in my original armhf patches you could override all the settings that FPC_ARMHF implied (compared to the default FPC_ARMEL) manually with enough command line flags, I don't know if that is still the case, nor do I know if it is the case for other arm variants. Florian later added code so that a compiler built for armhf and armv6 would default to targetting armv6+vfpv2 rather than armv7-a+vfpv3_d16. This was done so that building and using the compiler on raspbian (and similar raspberry pi targetted distros) would "just work". ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM FP calling convention
Vsevolod Alekseyev wrote: Please, is there a way to make Free Pascal on ARM use floating point registers for passing floating point parameter? Yes, build the compiler with -dFPC_ARMHF This is supported upstream in trunk, if you want to use 2.6.x then you can find the nessacery patches in the debian packages. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Smarter way of generating ARMHF fpc trunk installation?
Thaddy wrote: The latter will accept the proper options, which are minimally: CROSSOPT="-dFPC_ARMHF -CfVFPV2 -CpARMV6 -CaEABIHF" You should not need -CaEABIHF. A compiler build with -dFPC_ARMHF should automatically use the hard float ABI (and a few other related settings). I think all the other options you have specified should be accepted by 2.6.x ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Smarter way of generating ARMHF fpc trunk installation?
Reinier Olislagers wrote: fpcup, an FPC/Lazarus build/installation/update program uses the following steps on ARMHF Linux (e.g. raspbian, odroid): 1. Get FPC stable (2.6.2 currently) ARM bootstrap compiler binary This compiler cannot directly build ARMHF FPC trunk. OOI in what way does it fail? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 2.6.2 gives AV on arm
Joost van der Sluis wrote: On 08/09/2013 07:07 PM, Jonas Maebe wrote: On 09 Aug 2013, at 18:46, Joost van der Sluis wrote: Thing is that I'm trying to get fpc 2.6.2 working on the new arm-target of Fedora (armv7, hardware float, little endian). The EABI with hardfloat is not supported at all in 2.6.2. That's good to know. But in that case it should still work with soft-float, no? Things will break if you try and link with C libraries but building the compiler itself with softfloat options should work. If you want patches for hardfloat with 2.6.2 you can find them at https://code.google.com/p/bollin/source/browse/#svn%2Ffpc%2Ftrunk%2Fdebian%2Fpatches the hardfloat releated patches are armhf.diff armhf-linker-path.diff armhf-build-with-2.6.0.diff (only needed if bootstrapping with 2.6.0) and regenerate_messages.diff Once the patches are applied use -dFPC_ARMHF instead of -dFPC_ARMEL to get a hardlfoat build. What linker are you using? the gnu gold linker is known to break freepascal. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc on odroid (ARM hardfloat)
Michel Catudal wrote: You will find binaries for fpc 2.6.2 with hard float support as well as larazus 1. The code is based on the code from Debian. Out of interest what if anything did you change compared to the package from debian? did you just rebuild it in a different environment? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Accepted fpc 2.6.2-1 (source amd64 all)
Marco van de Voort wrote: After some discussion, something to try: try adding -dNO_THREADING to CROSSOPT (for target) and maybe also to OPT (for host) Unfortunately it seems that at least when building natively (note: debian is and always has been natively built) neither OPT or CROSSOPT is passed to the build of fpmake. I asked about this in the past ( http://bugs.freepascal.org/view.php?id=21547 ) and was told it was by design. It will disable threading inside fpmake by not USESing cthreads, eliminating the need for cross-linking to work at all. Disabling threading is the last resort option but really I just want to pass the path to the compiler, I know where it should be looking. The bug report I mentioned above claims there is a FPMAKEOPT variable but I couldn't find any evidence of it in the 2.6.2 source tree. Maybe it appeared after the 2.6 series was branched (last time I ran into this issue I was dealing with trunk) The good news is I found out I can pass the setting in through the "FPCFPMAKE" variable. fpmake was then built successfully. I then ran into the same link problem building fpdoc. I was able to work arround that one through the "OPT" variable. While i've managed to get the debian 2.6.2 package to build I still feel that the best soloution long term is to add the multiarch library paths to the compiler itself. Debian/ubuntu are two of the biggest linux distros, their use of multiarch paths isn't going to go away and while we distro packagers can work arround the fact that the compiler looks there by default end users who use the upstream release directly are likely to be somewhat phased by it (especially because of the way the compiler fails in a non-obvious way). I got a fairly negative response to that last time I suggested it to you guys (don't remember if it was on irc or the mailing list) but since then I notice someone has gone ahead and added the multiarch paths for armel and armhf to the default search path in trunk. root@debian:/fpc-trunk# grep -r arm-linux-gnu * compiler/systems/t_linux.pas: LibrarySearchPath.AddPath(sysrootpath,'/usr/lib/arm-linux-gnueabihf',true); compiler/systems/t_linux.pas: LibrarySearchPath.AddPath(sysrootpath,'/usr/lib/arm-linux-gnueabi',true); Binary file tests/test/cg/obj/linux/arm-eabi/tcext6.o matches root@debian:/fpc-trunk# If they are going to be added for armel and armhf shouldn't they be added for other ports too? That being said, I don't like FPC simply silently dropping those objectfiles. That should be improved, please file a bug (but I think that is more something long term for trunk, not 2.6.2 http://bugs.freepascal.org/view.php?id=24518 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Accepted fpc 2.6.2-1 (source amd64 all)
For those reading this on fpc-devel the context is that the upload of fpc 2.6.2 to debian failed on most architectures and I would like upstream input on sorting it out. Abou Al Montacir wrote: Many targets are broken: powerpc, sparc, armel, armhf. The error message looks very similar on 3 targets (powerpc, sparc and armel) but not for armhf. I've sorted the armhf specific issue. As expected it just required some tweaking of ifdefs so that the code in question wasn't used when building the rtl with 2.6.0. After sorting that issue it failed with much the same linker problem with fpmake as other architectures. /usr/bin/make -C fastcgi smart make[3]: Entering directory `/«PKGBUILDDIR»/fpcsrc/packages/fastcgi' /«PKGBUILDDIR»/fpcsrc/compiler/ppcppc fpmake.pp -n -Fu/«PKGBUILDDIR»/fpcsrc/rtl/units/powerpc-linux -Fu/«PKGBUILDDIR»/fpcsrc/packages/hash/units/powerpc-linux -Fu/«PKGBUILDDIR»/fpcsrc/packages/paszlib/units/powerpc-linux -Fu/«PKGBUILDDIR»/fpcsrc/packages/fcl-process/units/powerpc-linux -Fu/«PKGBUILDDIR»/fpcsrc/packages/fpmkunit/units/powerpc-linux /usr/bin/ld: warning: link.res contains output sections; did you forget -T? /usr/lib/powerpc-linux-gnu/libc_nonshared.a(elf-init.oS): In function `__libc_csu_init': (.text+0x48): undefined reference to `_init' fpmake.pp(30,38) Error: Error while linking fpmake.pp(30,38) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[3]: *** [fpmake] Error 1 make[3]: Leaving directory `/«PKGBUILDDIR»/fpcsrc/packages/fastcgi' make[2]: *** [fastcgi_smart] Error 2 make[2]: Leaving directory `/«PKGBUILDDIR»/fpcsrc/packages' make[1]: *** [packages_smart] Error 2 make[1]: Leaving directory `/«PKGBUILDDIR»/fpcsrc' make: *** [build-arch-stamp] Error 2 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 At a first look, it seems related to a particular component (fastcgi), but deeper look shows that this is the first package being compiled using fpmake (new FP make like utility). The error itself happens while compiling fpmake at link stage. I figured out the cause of this one. To successfully link against libc on many platforms (but NOT i386 and amd64) fpc needs to find certain libraries (/usr/lib/crt?.o iirc). To make things more confusing if it doesn't find them it silently leaves them out of the linker script and the build fails with missing symbol errors. This was discovered some time ago. On debian versions that support multiarch the libraries in question can be found in /usr/lib/ For programs that users build we got arround this some time ago by adding a line to fpc.cfg but that doesn't work for stuff that is built as part of the build process itself like fpmake because the fpc build process (deliberately) ignores fpc.cfg. So the option to make it look int the right place needs to be passed in explicitly. Unfortunately I haven't managed to make the fpc build process pass that in. I vaugely remember an option called something like FPMAKEOPT but I can't seem to find any evidence of it in the 2.6.2 source tree. Another way of solving the problem would be to add /usr/lib/triplet> to the paths that are baked into the compiler (as is done for gcc in debian). IMO this is the best soloution but last time I mentioned this to upstream they didn't seem to keen on the idea. Yet another option would be to disable threading support in fpmake but i'd rather not go down that road. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM V7 Hard float issue
Johan Kotze wrote: It seems that fpc in fact does not produce ARMHF executables with the parameters that I use. Am I using the wrong parameters or is something broken in the ARMHF support ? IIRC fpc doesn't set elf tags to mark objects as hardfloat, this is something I need to look into (if someone else hasn't already). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus issues on ARM Linux
Michel Catudal wrote: I am also having some issues with Lazarus, I am not sure if it is the right forum to talk about it. I had a previous version working fine on Rasphberry Pi. For some reason I can't get it to work on Mele A2000G. I have compiled it on gentoo on the Mele, using distcc and locally, same results. I didn't get any error during compile so I was expecting it to work. fpc seems to work, I haven't written any code with it yet, I was expecting to use lazarus to do that. My system on Mele A2000G is gentoo with mate desktop. I have everything compiled with hard float as I did on the Raphsberry Pi. Upstream 2.6.x does not support the hard float ABI so unless you have a patched version (such as the one shipped in debian) it won't correctly link against C libraries on a system that uses hard float ABIS. Also even when the hard float ABI support is present in the compiler source code you need to either bootstrap with a starting compiler that uses the hard float ABI or explictly specify -d FPC_ARMHF during the build. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Hardfloat
Den Jean wrote: On Thursday 04 October 2012 21:54:19 Thomas Schatzl wrote: Basically the difference between armel and armhf are - fpc cannot create valid armhf shared libraries Other problems common to both (just from interpreting the testsuite results, filtering known failing tests): - there are issues with threading/synchronization (test machine is a quad-core box, previous test machine was single core where as usual such problems don't show up) - fpu exceptions/setting fpu exception mask seem to not work - some problems with fpc resources Thx for the info In the Qt binding I need to do this SetExceptionMask([exDenormalized,exInvalidOp,exOverflow,exPrecision,exUnderflow,exZeroDivide]); because of Qt C++ not allowing such exceptions is this a problem ? Short answer no. Long answer: the reason those tests are failing is because the processor simply does not support floating point exceptions. So your calls to c++ are fine but your pascal code will need to be modified if it was previously relying on floating point exceptions. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] supported compiler versions for building stable releases.
I have long understood that each stable release of freepascal is made to be compilable with the previous release but at a quick glance at the website I couldn't seem to spot any official statement of this. Is it indeed "supported" to compile a stable release with the previous stable release and if so is there a statement of this anywhere. I ask because i've been helping someone in debian who is trying to convince another compiler (for a totally different language) to adopt a similar policy. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] targetandroid - can't build for armv7, hangs on pooledmm.pp
Thomas Schatzl wrote: Last time I tried compiling with -Cfvfpv2 or 3 the compiler did not cycle, so I could not test further. Has been some time, and this was native compilation. Last I heard cycling goes fine but FPU options don't get passed down to other parts of the build process leading to failures if the selected fpu type does not match the default for the OS and variant in question. I imagine you would have similar problems setting the ABI manually (although I don't know if there is a trap to catch people who do that or if the compiler will carry on blindly doing the wrong thing) I think -mfloat-abi does nothing, but maybe that changed recently - there have been many, many changes to the ARM support recently. Further I am actually surprised that there is hardfp support for fpc. There is hardfloat support in freepascal trunk but unless something has changed recently I doubt a c style -mfloat-abi will activate it. IIRC the fpc option you need for the hardfloat ABI is -CaEABIHF. For linux you can use -dFPC_ARMHF when building the compiler to select the armhf "variant" which defaults to armv7-a, vfpv3_d16 and hard float abi. >If so, it is probably in a somewhat experimental state too. well it works well enough to build the fpc and lazarus debian packages (I backported it to 2.6.0 for debian) and I also ran a fairly thourough test of passing parameters to C code to check they were being passed in the right places. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: vfp exception issues with freepascal
shawn wrote: http://sourceware.org/ml/libc-ports/2012-06/msg00021.html I quote: "ARM VFPv3 and VFPv4 do not support trapping floating-point exceptions; VFPv2, VFPv3U and VFPv4U do. The lack of support causes the glibc math/test-fenv test to fail on VFPv3 and VFPv4 systems Am I correctly intepreting this as "most current armv7 implementations don't support trapping exceptions but some of them do or may do in the future"? If there is then IMO we do need to get the fix for the inverted exception masking in freepascal into wheezy. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: vfp exception issues with freepascal
peter green wrote: an IMX53 quickstart board running That should have said running 3.2.0-2-mx5 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] vfp exception issues with freepascal
I am involved in a project called raspbian to produce a hard-float
derivative of debian for the raspberry pi. Within this port we had
problems with floating point exceptions while running the compiler.
These problems were tracked down by masta (a freepascal upstream
developer) to reversed logic in a routine for controlling floating point
exception settings (attempting to disable an exception enabled it and
vice-versa)
Howevr this then left the question of "why didn't I see this problem
when preparing the freepascal packages for debian armhf?". The
conclusion i've come to is that on the armv7 systems i've tested (a
beagleboard XM running 2.6.39.2-x2 and an IMX53 quickstart board running
) the method freepascal uses for enabling vfp exceptions simply doesn't
work.
I've written a small test program in C and inline assembler to
demonstrate this. It tries to enable a number of floating point
exceptions using a price of inline assembly I copied from the freepascal
run time library and then does a division of the command line arguments.
When I test this on a Pi running raspbian I get a floating point
exception as expected.
root@raspbian:~# ./a.out 1 0
Floating point exception
root@raspbian:~#
but when I try it on my beagleboard XM or IMX53 board I don't get any
exception.
root@plugwash:/home/plugwash# ./a.out 1 0
inf
root@plugwash:/home/plugwash#
Any vfp experts able to help get to the bottom of what is going on here?
#include
int main(int argc, char *argv[]) {
__asm__(
"fmrx r0,fpscr\n\t"
// set "round to nearest" mode
"and r0,r0,#0xff3f\n\t"
// mask "exception happened" and overflow flags
"and r0,r0,#0xff20\n\t"
// mask exception flags
"and r0,r0,#0x40ff\n\t"
// disable flush-to-zero mode (IEEE math compliant)
"and r0,r0,#0xfeff\n\t"
// enable invalid operation, div-by-zero and overflow exceptions
"orr r0,r0,#0x0700\n\t"
"fmxr fpscr,r0"
: //no output registers
: //no input registers
: "r0"
);
double a = atoi(argv[1]);
double b = atoi(argv[2]);
double c = a / b;
printf("%f\n",c);
}___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Inline assembler.
Is it possible to tell the inline assembler to output something to the resulting assembler file even though it doesn't recognise the opcode? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch: Add support for armhf
Jonas Maebe wrote:
On 20 Mar 2012, at 23:43, peter green wrote:
I attatch a patch which adds support for armhf to freepascal.
Thanks!
Armhf reffers to arm with the VFP hardfloat variant of EABI. The
defaults are setup to
be suitable for debian armhf (armv7 vfpv3_d16).
Are they Debian-specific? Adding distribution-specific settings to the
compiler is something that should be very much avoided.
One has to chose some set of defaults, the ones i've picked match what
debian/ubuntu are doing. If you want to reduce them to armv6 and vfpv2
that's fine by me too. I don't think any lower is sane (the lowst VFP
variant that freepascal supports is VFPV2 and afaict VFPV2 came in with
armv6).
Some other remarks:
* please split unrelated parts into separate patches (such as making
the internalerror in ninl.pas unique)
I split out the internal error change, most if not all of the other
stuff in the patch is at least somewhat related to each other.
If you want me to split out other stuff please tell me where you would
like the lines drawing (for example if you want the VFPV3_D16 in a
seperate patch please tell me, it may be a bit of a pain to split it
though as in at least one place it is in the same chunk as another armhf
related change)
* please create bug reports for those individual patches and attach
them there, it makes them easier to track than on a mailing list
I've filed bug reports for the main patch and the internalerror patch.
If you want things splitting further please tell me and i'll do so and
file more bugreports.
http://bugs.freepascal.org/view.php?id=21545
http://bugs.freepascal.org/view.php?id=21554
* some stylistic remarks (there may be more, I just quickly glanced
over the patch):
+ if ((target_info.abi=abi_eabi) or (target_info.abi=abi_eabihf)) and
-> change into an in-statement (and as mentioned before, please do not
put multiple if-conditions on the same line except if they are really
short like two boolean variables)
Done
+ if target_info.abi = abi_eabihf then def_system_macro('FPC_ABI_EABI');
-> Put the then-part on a separate line
Done
+end else begin
-> this should be
end
else
begin
Done
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch: Add support for armhf
Unfortunately just after I sent the mail what I thought was a minor problem in the build system turned out to be more serious than I thought, namely cthreads is crashing at initalisation time. I really need to figure out why before merging this patch is considered. Ok solved that issue, it seems if the compiler can find crti.o but not crtn.o it links cthreads using apps successfully but they crash on startup :(, if it can find both crti.o and crtn.o cthreads works ok :). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] passing options for the build process.
Jonas Maebe wrote: The compiler should find the crt*.o files on its own, especially if you create a special compiler binary for the hard float ABI (there is no point in creating a special binary if you still need to separately specify a bunch of additional options to get the correct behaviour). Or are they in distribution-specific directories for the hard float ABI? debian/ubuntu are introducing (ubuntu have had support for a while, debian have been a bit slower on the uptake) something called multiarch. The idea of multiarch is that one system will be able to have packages from a mix* of architectures installed at the same time. This is not something specific to armhf (though armhf does of course have a multiarch triplet). As a result of this many libraries (including crt*.o) are now located in /usr/lib/ (or lib/). See debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636802 for previous discussion of this. Debian currently handles this through an entry in the default config file (though the entry they are using right now is likelt to be problematic on a multiarch system with both armel and armhf since it will match the lib directories for both). A key thing about the way multiarch works is that libraries that are packaged to support multiarch will be located in multiarch directories even if the system they are installed on only has packages from one architecture installed. Multiarch is a debian/ubuntu creation. I believe someone is attempting to push support to upstream gcc. I'm not aware of any distros outside the debian family that are currently using it, I am quite happy to prepare a patch that adds the multiarch locations for each architecture to the hardcoded default search paths if you believe that is an appropriate thing to do. * A multiarch triplet represents an ABI. They are based on GNU triplets but not nessacerally identical to them because sometimes one GNU triplet can convert multiple ABIs and sometimes there can be more than one GNU triplet in use for the same ABI. http://wiki.debian.org/Multiarch/Tuples ** in practice most multiatch systems will probally be combinations like i386/amd64 or ppc/ppc64 or maybe armel/armhf but in principle any combination is possible as long as you can find a way (e.g. binfmt-misc with qemu) to make the biniaries run ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch: Add support for armhf
Jonas Maebe wrote: On 20 Mar 2012, at 23:43, peter green wrote: I attatch a patch which adds support for armhf to freepascal. Thanks! Unfortunately just after I sent the mail what I thought was a minor problem in the build system turned out to be more serious than I thought, namely cthreads is crashing at initalisation time. I really need to figure out why before merging this patch is considered. I'll keep you posted on my progress and i'll try and split things up and file bug reports soon. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] passing options for the build process.
The buildfaq claims that OPT= will add parameters to every compiler commandline. Unfortunately it doesn't seem to actually do that. The options are added when building the compiler and RTL but it seems they aren't added when building fpmake. This is a problem for me as to successfully build fpmake on a multiarch arm system I need to tell it where to find crti.o (it seems freepascal can successfully build stuff linked against c libraries without finding crti.o on some architectures but not others). For now i've created a symlink at /usr/lib/crti.o to /usr/lib/arm-linux-gnueabihf/crti.o to make things work but i'd rather not have to mess with my system in that way. Is there some way of specifying options so that they actually get passed to ALL compiler invocations in the build process? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] update on freepascal armhf porting, doubles are working now for singles.
I can now successfully pass doubles to/from C functions on armhf. I've
written a test program that passes lots of different combinations of
single/double/longint/int64 to C code and all combinations that do not
involve singles are working.
It would also be helpful to add this test to the testsuite
we do have some tests in test/cg
but it wouldn't hurt to add more of that type!
I've attatched the program that generates the test program, if you need
it under a
specific license just ask.
Currently it is set up to test all combinations of up to four parameters
and a more
limited set of combinations up to 17 parameters but these are both
easilly adjusted
to suit.
The generator has two modes, if the letter c is passed as the first
command line
parameter it operates in "pascal calling c" mode. Otherwise it operates in
"pascal calling pascal mode".
In "pascal calling c" mode two files are generated. testfp.dpr and
testfpfunctions.c
in "pascal calling pascal" mode only one file is generated.
Note that "pascal calling c" mode makes some assumptions about the
equivilence
of pascal and c basic types. These assumptions should hold on most platforms
but there may be some where they do not.
program gentestfp;
uses
sysutils,classes;
type
ttype = (sin,dou,int,i64);
const
typenames: array[ttype] of string = ('single','double','longint','int64');
ctypenames: array[ttype] of string = ('float','double','int','long long');
printfspecifiers: array[ttype] of string = ('%f','%f','%ld','%lld');
var
paramcount : longint;
param: longint;
paramcombination: longint;
paramcombinationinner: longint;
returntype : ttype;
paramtype : ttype;
t: text;
c: text;
paramtypes : array[1..17] of ttype;
mainparamtype, lastparamtype : ttype;
calls: tstringlist;
callsofcalls : tstringlist;
cmode : boolean;
procedure genfunction;
var
definitionstring : string;
callstring: string;
cstring: string;
functionname : string;
begin
//generate function name
functionname := 'z';
for param := 1 to paramcount do begin
functionname := functionname + typenames[paramtypes[param]][1];
end;
functionname := functionname + typenames[returntype][1];
definitionstring := 'function ' + functionname;
if paramcount > 0 then begin
definitionstring := definitionstring + '(';
for param := 1 to paramcount do begin
definitionstring := definitionstring +char(param-1+byte('a')) + ':' +
typenames[paramtypes[param]];
definitionstring := definitionstring + ';';
end;
definitionstring[length(definitionstring)] := ')';
end;
definitionstring := definitionstring + ':'+typenames[returntype]+';';
if cmode then begin
definitionstring := definitionstring+'cdecl;external;';
cstring := ctypenames[returntype] + ' ' + functionname;
if paramcount > 0 then begin
cstring := cstring + '(';
for param := 1 to paramcount do begin
cstring := cstring + ctypenames[paramtypes[param]] +' '
+char(param-1+byte('a'));
cstring := cstring + ',';
end;
cstring[length(cstring)] := ')';
end else begin
cstring := cstring + '(void)';
end;
cstring := cstring +'{ ';
if paramcount = 0 then begin
cstring := cstring + 'return 0x12beef;';
end else begin
cstring := cstring +'printf("';
for param := 1 to paramcount do begin
cstring := cstring + printfspecifiers[paramtypes[param]] + ' ';
end;
cstring[length(cstring)] := '\';
cstring := cstring + 'n"';
for param := 1 to paramcount do begin
cstring := cstring + ',' + char(param-1+byte('a'));
end;
cstring := cstring + ');';
cstring := cstring + 'fflush(stdout);';
cstring := cstring + 'return ';
for param := 1 to paramcount do begin
cstring := cstring + char(param-1+byte('a')) + '+';
end;
cstring[length(cstring)] := ';';
end;
cstring := cstring + '}';
writeln(c,cstring);
end else begin
definitionstring := definitionstring +'begin ';
if paramcount = 0 then begin
definitionstring := definitionstring + 'result := $12beef;';
end else begin
definitionstring := definitionstring +'writeln(';
for param := 1 to paramcount do begin
definitionstring := definitionstring + char(param-1+byte('a')) + ',''
'',';
end;
setlength(definitionstring,length(definitionstring)-5);
definitionstring := definitionstring + ');';
definitionstring := definitionstring + 'result := trunc(';
for param := 1 to paramcount do begin
definitionstring := definitionstring + char(param-1+byte('a')) + '+';
end;
definitionstring[length(definitionstring)] := ')';
definitionstring := definitionstring + ';';
end;
definitionstring := definitionstring + ' end;';
end;
writeln(t,definitionstring);
callstring := 'if '+functionname;
callstring := 'd := '+functionname;
if paramcou
Re: [fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)
peter green wrote: The bad news is that a number of testcases are still failing. Next on my list is 16 singles. Ok that was easy, a small logic flaw in my code was preventing a parameter being correctly assigned to the last available single precision register when it should have been. And with that fixed all the parameter combinations I try seem to work. Now I just have to clean up my patch and submit it :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)
S30,$04,$06,$0F,s20,0,0 Should be S30,$04,$06,$0F,s20,0,0 Doh seems I pasted the wrong line twice, it really should be S30,$04,$06,$0F,s30,0,0 Please don't change it in trunk at the moment through because my armhf porting work makes a lot of other changes to armreg.dat and I doubt this bug is hitting anyone else at the moment. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)
Okay, it is quite unlikely that the register allocator itself ignores such an interference, so you may be rigth it tries to spill but nothing happens. Ok that wasn't the issue but you were right about not being the register allocator. Turns out the actual cause was a one character typo in armreg.dat (no I didn't introduce it). S30,$04,$06,$0F,s20,0,0 Should be S30,$04,$06,$0F,s20,0,0 So it was assigning two different registers as it should but when it came to actually write out the assembler file it wrote out s20 for both of them. The good news is that all test cases involving up to 15 parameters (including the "14 singles one double" case I was discussing) are now fixed :) The bad news is that a number of testcases are still failing. Next on my list is 16 singles. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)
The algorithm used is called "iterated register coalescing", an advanced form of graph colouting and was designed by Andrew W. Appel. He describes in detail in his book "Modern Compiler Implementation in C". Thanks, I think i'll grab a copy from the uni library tomorrow. Basically the registers are put into "worklists" How does it decice which worklist to put a register in? do registers move between the worklists? , and then 4 procedures: * simplify -> takes registers out of the graph that can safely be coloured * coalesce -> tries to coalesce registers together to reduce pressure * freeze -> selects registers that have a chance to be coalesced and should therefore not be spilled yet * spill -> selects a register that should move to memory. These procedures are called iteratively until the worklists are empty. Then the graph is coloured. Is this process run seperately for each type of register (int/float/mm)? P.S. I tried putting debug writelns in the code that generates spills and it doesn't seem to be being called for my current testcase :/ (this wasn't the only testcase that failed but I feel it's best to approach them one at a time). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)
Then a register is spilled, i.e. replace by a location in memory. This may be possible without new registers: mov ireg30d,ireg29d-> mov ireg30d,[ebp-40] ... but in some cases a help register is needed: mov ireg30d,[ebp+20] -> mov ireg99d,[ebp+20] mov [ebp-40],ireg99d Should a new register is needed, register allocation is completely restarted with the new code. Thanks for the info. My current suspiscion is that something is missing regarding handling of running out of VFP registers and it hasn't been noticed before because noone has tried to do what i'm doing (implementing a calling convention using VFP registers and then stress testing it) but i've no idea where to look in the sourcecode to confirm/refute that idea. It doesn't look like spilling happens in your example: I don't see moves from/to the stack frame as temporary location. My suspiscion was that the compiler was trying to spill but not actually generating any code to implement the spill. Perhaps the first thing to check is to add a breakpoint in Tinterferencebitmap.setbitmap. The "versions" of s20 use superregister 50 and 70, so a setbitmap (50,70) or (70,50) should be called at some point to tell the register allocator both registers are active at the same time and cannot be coalesced. I added a debug writeln to setbitmap and it does seem to be being called with both 50,70 and 70,50. Full output is at http://pastebin.com/3jd8zNkh ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)
Daniël Mantione wrote:
Please use the command line option -sr to check the generated code
before register allocation.
Done and attatched.
You can likely find the cause in there.
The code with imaginary registers looks correct to me. It seems to load
each parameter into a seperate even numbered imaginary register (using
odd numbered imaginary registers as temporaries in the process)
allocating them as it goes. Then copies them to the locations needed for
the function call deallocating them as it goes.
So it seems to me that the problem is in the translation of the form
using imaginary registers to the form using real registers. Can you
explain (or point me to documentation on) how this form is translated
into a form using real registers. In particular what exactly happens
when there are not enough real registers free to assign a real register
for every imaginary register that is in use at a given time?
My current suspiscion is that something is missing regarding handling of
running out of VFP registers and it hasn't been noticed before because
noone has tried to do what i'm doing (implementing a calling convention
using VFP registers and then stress testing it) but i've no idea where
to look in the sourcecode to confirm/refute that idea.
.file "testfp.dpr"
# Begin asmlist al_begin
.section .text.b_DEBUGSTART_$P$TESTFP
.globl DEBUGSTART_$P$TESTFP
.type DEBUGSTART_$P$TESTFP,#object
DEBUGSTART_$P$TESTFP:
.stabs "/testfp/",100,0,0,.Lf3
.stabs "testfp.dpr",100,0,0,.Lf3
.Lf3:
# End asmlist al_begin
# Begin asmlist al_stabs
.section .data.n_TESTFP
.globl DEBUGINFO_$P$TESTFP
.type DEBUGINFO_$P$TESTFP,#object
DEBUGINFO_$P$TESTFP:
# Defs - Begin unit SYSTEM has index 1
.stabs "void:t2=2",128,0,0,0
.stabs "LONGINT:t3=r3;-2147483648;2147483647;",128,0,0,0
.stabs "DOUBLE:t1=r3;8;0;",128,0,0,0
# Defs - End unit SYSTEM has index 1
# Defs - Begin unit FPINTRES has index 2
# Defs - End unit FPINTRES has index 2
# Defs - Begin unit OBJPAS has index 3
# Defs - End unit OBJPAS has index 3
# Defs - Begin Staticsymtable
# Defs - End Staticsymtable
# Syms - Begin Staticsymtable
.stabs "D:S1",40,0,6,U_$P$TESTFP_$$_D
# Syms - End Staticsymtable
# End asmlist al_stabs
# Begin asmlist al_procedures
.section .text.n_p$testfp_$$_g0
.balign 4
.globl P$TESTFP_$$_G0
.type P$TESTFP_$$_G0,#function
P$TESTFP_$$_G0:
.stabs "G0:F2",36,0,7,P$TESTFP_$$_G0
# Temps allocated between r11-40 and r11-40
# Register r13,r11,r12 allocated
.stabs "testfp.dpr",132,0,0,.Lf1
.Lf1:
.stabn 68,0,7,.Ll1 - P$TESTFP_$$_G0
.Ll1:
# [testfp.dpr]
# [7] procedure g0; begin
mov r12,r13
stmfd r13!,{r11,r12,r14,r15}
sub r11,r12,#4
# Register r12,r12 released
sub r13,r13,#40
# Register ireg16 allocated
.stabn 68,0,8,.Ll2 - P$TESTFP_$$_G0
.Ll2:
# [8] d := zssdd(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15);
ldr ireg16,.Lj10
# Register ireg16 released
# Register mreg49fd allocated
flddmreg49fd,[ireg16]
# Register mreg49fd released
# Register mreg48fd allocated
fcpyd mreg48fd,mreg49fd
# Register ireg17 allocated
ldr ireg17,.Lj14
# Register ireg17 released
# Register mreg51fs allocated
fldsmreg51fs,[ireg17]
# Register mreg51fs released
# Register mreg50fs allocated
fcpys mreg50fs,mreg51fs
# Register ireg18 allocated
ldr ireg18,.Lj18
# Register ireg18 released
# Register mreg53fs allocated
fldsmreg53fs,[ireg18]
# Register mreg53fs released
# Register mreg52fs allocated
fcpys mreg52fs,mreg53fs
# Register ireg19 allocated
ldr ireg19,.Lj22
# Register ireg19 released
# Register mreg55fs allocated
fldsmreg55fs,[ireg19]
# Register mreg55fs released
# Register mreg54fs allocated
fcpys mreg54fs,mreg55fs
# Register ireg20 allocated
ldr ireg20,.Lj26
# Register ireg20 released
# Register mreg57fs allocated
fldsmreg57fs,[ireg20]
# Register mreg57fs released
# Register mreg56fs allocated
fcpys mreg56fs,mreg57fs
# Register ireg21 allocated
ldr ireg21,.Lj30
# Register ireg21 released
# Register mreg59fs allocated
fldsmreg59fs,[ireg21]
# Register mreg59fs released
# Register mreg58fs allocated
fcpys mreg58fs,mreg59fs
# Register ireg22 allocated
ldr ireg22,.Lj34
# Register ireg22 released
# Register mreg61fs allocated
fldsmreg61fs,[ireg22]
# Register mreg61fs released
# Register mreg60fs allocated
fcpys mreg60fs,mreg61fs
# Register ireg23 allocated
ldr
[fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)
While testing my armhf porting work (which I will send on request, including it
in this mail seems to make it too big for the list to accept) I came across a
case
where parameters were passed incorrectly to a function with a large number of
parameters (14 single, 1 double). Initially I thought this was because
of the compilers lack of knowlage of the conflict between double
registers and odd numbered single registers. However looking more
closely this appears not to be the case. The full assembler is attached
and highlights of it are below.
# Register r0 allocated
Looking at the code it seems that the compiler is loading the constants
ldrr0,.Lj14
# Register r0 released
# Register s0 allocated
fldss0,[r0]
# Register s0 released
# Register s20 allocated
fcpys s20,s0
<--snip a load of stuff not involving s20-->
# Register r0 allocated
ldr r0,.Lj54
# Register r0 released
# Register s0 allocated
fldss0,[r0]
# Register s0 released
# Register s20 allocated
fcpys s20,s0
<--snip a load of stuff not involving s20-->
# Register s20 released
# Register s13 allocated
fcpys s13,s20
<--snip a load of stuff not involving s20-->
# Register s20 released
# Register s3 allocated
fcpys s3,s20
Looking at the code it seems that the compiler is loading the constants
into temporary registers and then copying them to the final locations
for passing them to the parameters. However for some reason it is using
S20 to store two different temporary values at the same time. Any idea
what could cause this and how to debug it? S20 is NOT used for passing
parameters to funtions.
I have a hunch it may be a spilling related issue but i've no idea
where to look to confirm/refute that theory.
.file "testfp.dpr"
# Begin asmlist al_begin
.section .text.b_DEBUGSTART_$P$TESTFP
.globl DEBUGSTART_$P$TESTFP
.type DEBUGSTART_$P$TESTFP,#object
DEBUGSTART_$P$TESTFP:
.stabs "/testfp/",100,0,0,.Lf3
.stabs "testfp.dpr",100,0,0,.Lf3
.Lf3:
# End asmlist al_begin
# Begin asmlist al_stabs
.section .data.n_TESTFP
.globl DEBUGINFO_$P$TESTFP
.type DEBUGINFO_$P$TESTFP,#object
DEBUGINFO_$P$TESTFP:
# Defs - Begin unit SYSTEM has index 1
.stabs "void:t2=2",128,0,0,0
.stabs "LONGINT:t3=r3;-2147483648;2147483647;",128,0,0,0
.stabs "DOUBLE:t1=r3;8;0;",128,0,0,0
# Defs - End unit SYSTEM has index 1
# Defs - Begin unit FPINTRES has index 2
# Defs - End unit FPINTRES has index 2
# Defs - Begin unit OBJPAS has index 3
# Defs - End unit OBJPAS has index 3
# Defs - Begin Staticsymtable
# Defs - End Staticsymtable
# Syms - Begin Staticsymtable
.stabs "D:S1",40,0,6,U_$P$TESTFP_$$_D
# Syms - End Staticsymtable
# End asmlist al_stabs
# Begin asmlist al_procedures
.section .text.n_p$testfp_$$_g0
.balign 4
.globl P$TESTFP_$$_G0
.type P$TESTFP_$$_G0,#function
P$TESTFP_$$_G0:
.stabs "G0:F2",36,0,7,P$TESTFP_$$_G0
# Temps allocated between r11-40 and r11-40
# Register r13,r11,r12 allocated
.stabs "testfp.dpr",132,0,0,.Lf1
.Lf1:
.stabn 68,0,7,.Ll1 - P$TESTFP_$$_G0
.Ll1:
# [testfp.dpr]
# [7] procedure g0; begin
mov r12,r13
stmfd r13!,{r4,r11,r12,r14,r15}
sub r11,r12,#4
# Register r12,r12 released
sub r13,r13,#108
# Register r12 allocated
mov r12,#104
sub r12,r11,r12
# Register r12 released
fstmiad r12,{d8,d9,d10,d11,d12,d13,d14,d15}
# Register r0 allocated
.stabn 68,0,8,.Ll2 - P$TESTFP_$$_G0
.Ll2:
# [8] d := zssdd(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15);
ldr r0,.Lj10
# Register r0 released
# Register d0 allocated
flddd0,[r0]
# Register d0 released
# Register d2 allocated
fcpyd d2,d0
# Register r0 allocated
ldr r0,.Lj14
# Register r0 released
# Register s0 allocated
fldss0,[r0]
# Register s0 released
# Register s20 allocated
fcpys s20,s0
# Register r0 allocated
ldr r0,.Lj18
# Register r0 released
# Register s0 allocated
fldss0,[r0]
# Register s0 released
# Register s12 allocated
fcpys s12,s0
# Register r0 allocated
ldr r0,.Lj22
# Register r0 released
# Register s0 allocated
fldss0,[r0]
# Register s0 released
# Register s28 allocated
fcpys s28,s0
# Register r0 allocated
ldr r0,.Lj26
# Register r0 released
# Register s0 allocated
fldss0,[r0]
# Register s0 released
# Register s10 allocated
fcpys s10,s0
# Register r0 allocated
ldr r0,.Lj30
# Register r0 released
# Register s0 allocated
fldss0,[r0]
#
[fpc-devel] update on freepascal armhf porting, doubles are working now for singles.
I can now successfully pass doubles to/from C functions on armhf. I've
written a test program that passes lots of different combinations of
single/double/longint/int64 to C code and all combinations that do not
involve singles are working.
A patch with the current state of the work is attatched.
Index: rtl/arm/setjump.inc
===
--- rtl/arm/setjump.inc (revision 20511)
+++ rtl/arm/setjump.inc (working copy)
@@ -16,7 +16,7 @@
function fpc_setjmp(var S : jmp_buf) : longint;assembler;[Public, alias : 'FPC_SETJMP'];nostackframe; compilerproc;
asm
-{$if defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)}
{$if defined(CPUARMV3) or defined(CPUARMV4) or defined(CPUARMV5)}
fstmiax r0!, {d8-d15}
{$else}
@@ -46,7 +46,7 @@
movsr0, r1
it eq
moveq r0, #1
-{$if defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)}
fldmiad ip!, {d8-d15}
{$endif}
ldmia ip,{v1-v6, sl, fp}
@@ -57,7 +57,7 @@
mov ip, r0
movsr0, r1
moveq r0, #1
-{$if defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)}
{$if defined(CPUARMV3) or defined(CPUARMV4) or defined(CPUARMV5)}
fldmiax ip!, {d8-d15}
{$else}
Index: rtl/arm/math.inc
===
--- rtl/arm/math.inc (revision 20511)
+++ rtl/arm/math.inc (working copy)
@@ -14,7 +14,7 @@
**}
-{$if defined(FPUFPA) or defined(FPUFPA10) or defined(FPUFPA11) or defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$if defined(FPUFPA) or defined(FPUFPA10) or defined(FPUFPA11) or defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)}
{$define FPC_SYSTEM_HAS_ABS}
function fpc_abs_real(d : ValReal) : ValReal;compilerproc;
begin
Index: rtl/arm/mathu.inc
===
--- rtl/arm/mathu.inc (revision 20511)
+++ rtl/arm/mathu.inc (working copy)
@@ -177,7 +177,7 @@
begin
end;
-{$elseif defined(darwin) or defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$elseif defined(darwin) or defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_d16)}
const
_VFP_ENABLE_IM = 1 shl 8; { invalid operation }
Index: rtl/arm/arm.inc
===
--- rtl/arm/arm.inc (revision 20511)
+++ rtl/arm/arm.inc (working copy)
@@ -30,7 +30,7 @@
{$if not(defined(wince)) and not(defined(gba)) and not(defined(nds)) and not(defined(FPUSOFT)) and not(defined(FPULIBGCC))}
{$define FPC_SYSTEM_HAS_SYSINITFPU}
-{$if not defined(darwin) and not defined(FPUVFPV2) and not defined(FPUVFPV3)}
+{$if not defined(darwin) and not defined(FPUVFPV2) and not defined(FPUVFPV3) and not defined(FPUVFPV3_D16)}
Procedure SysInitFPU;{$ifdef SYSTEMINLINE}inline;{$endif}
begin
{ Enable FPU exceptions, but disable INEXACT, UNDERFLOW, DENORMAL }
Index: rtl/arm/setjumph.inc
===
--- rtl/arm/setjumph.inc (revision 20511)
+++ rtl/arm/setjumph.inc (working copy)
@@ -16,7 +16,7 @@
type
jmp_buf = packed record
-{$if defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)}
d8,d9,d10,d11,d12,d13,d14,d15: double;
{$endif}
v1,v2,v3,v4,v5,v6,sl,fp,sp,pc : dword;
Index: compiler/ninl.pas
===
--- compiler/ninl.pas (revision 20511)
+++ compiler/ninl.pas (working copy)
@@ -3094,7 +3094,7 @@
internalerror(200104047);
in_slice_x:
-internalerror(2005101501);
+internalerror(2005101502);
in_ord_x,
in_chr_byte:
Index: compiler/verbose.pas
===
--- compiler/verbose.pas (revision 20511)
+++ compiler/verbose.pas (working copy)
@@ -533,6 +533,8 @@
UpdateStatus;
do_internalerror(i);
inc(status.errorcount);
+//deliberately segfault for easier debugging
+pchar(0)^ := 'A';
raise ECompilerAbort.Create;
end;
Index: compiler/cgobj.pas
===
--- compiler/cgobj.pas (revision 20511)
+++ compiler/cgobj.pas (working copy)
@@ -740,7 +740,10 @@
procedure tcg.ungetcpuregister(list:TAsmList;r:Tregister);
begin
if not assigned(rg[getregtype(r)]) then
- internalerror(200312126);
+ begin
+writeln(ord(getregtype(r)));
+internalerror(200312126);
+ end;
rg[getregtype(r)].ungetcpuregister(list,r);
end;
Index: compiler/systems.inc
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Jonas Maebe wrote: You can give S1, S3, S5 etc different super register numbers (> $1F, so they don't conflict with the super register numbers for D0..D31). As long as you don't change the code in tarmcgarm/Tthumb2cgarm.init_register_allocators() to explicitly tell the register allocator that it can use these "extra" registers, it will won't try to allocate them. So I change "S1,$04,$06,$00,s1,0,0" to "S1,$04,$06,$20,s1,0,0" and so-on in compiler/arm/armreg.dat right? After doing that do I need to do anything to update the generated files or will they be updated automatically? Make sure to adjust first_mm_imreg in arm/cpubase.pas afterwards (add $10 to it, since the numbers $20..$3F will now be used by S1, S3 etc). Ok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
NR_S0<>NR_D0: they can be identified by the sub type. Further, one can perfectly assign NR_S1 to any location explicitly. Umm, my copy of narmcon.pas contains the following. NR_S0 = tregister($0406); NR_S1 = tregister($0406); NR_D0 = tregister($0407); I can see how the compiler can tell whether i'm assigning S0 or D0 but I don't see how it can tell whether I am assigning S0 or S1 when the constants I would use to make the assignment are defined to have the exact same value. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Are you saying that VFP registers are treated as multimedia registers and not as FPU registers? If so presumablly that mean I should be using LOC_MMREG and not LOC_FPUREG as the location for parameters and return values? Yes. Thank you for your help so-far, i'm gradually making progress though there is still some way to go. While i'm currently working on doubles (since double is the dominant floating point type in my experiance and is also easier) at some point I will need to support singles correctly as well and I just ran into an issue that could pose a problem for making singles work correctly. It seems freepascal identifies registers using a series of constants defined in rarmcon.inc which is generated from armreg.dat however to workarround a deficiency in the register allocator the same "register number" was allocated to both of the single precision registers that overlap with any given double precision register. So it seems there is no way to identify the two seperately within the compiler. This is a problem because to correctly implement the EABI VFP calling convention I need to use those registers. Any thoughts on how to get arround this? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Just set a breakpoint in the place where one of the offending instructions is generated, found via grep. E.g., the only place where an LDF is generated is in arm/cgcpu.pas (in a_loadfpu_ref_reg). Hmm, when I grepped for the first and most prolific problem instruction (mvfd) I didn't find anything useful. Maybe I should have tried some of the other problem intstructions. Once you figure out from where that routine gets called, then you do need some compiler knowledge: on ARM, the a_*fpu* routines are (should be) only be used in case of FPA. In case of VFP, the a_*mm* routines must be used instead. So there's probably a missing check for the new VFP FPU type you added (which you can easily figure out via a backtrace once the breakpoint is hit). Hmm, I think you may have identified my problem. Are you saying that VFP registers are treated as multimedia registers and not as FPU registers? If so presumablly that mean I should be using LOC_MMREG and not LOC_FPUREG as the location for parameters and return values? I suspect the next thing I actually need to do is come up with a reduced testcase. The assembler output of system.pp is MASSIVE. Unless you want to step through the entire compiler or code generator until you find where it goes wrong, that shouldn't matter. Ok It's neat until something goes wrong and you have to start figuring out how they compiled the compiler, or the person they downloaded it from. Experience tells us that if the compiler binaries have the same name, they should have the same behaviour. Otherwise support becomes hell (and it becomes equally difficult for users to know what to expect). Well the arm variants (arm, armeb, armel and my new armhf) DO announce themselves in the "target OS" line in the output so there is a fairly easy way to tell them apart. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Then I suggest you simply debug it like any other code: first set a breakpoint in options.pas where the fpu type should be set, and verify that it is in fact set. I'm pretty sure it is getting set because I use it in generating the assembler command line and i'm using an assembler wrapper that tells me what the assembler command line is. Then get the addresses of init_settings.fputype and current_settings.fputype, and set watchpoints on those to see whether they are still changed somewhere else. Also set a breakpoint in the code generator somewhere where it should decide whether to use AFP or VFP instructions, I'll try but I'm having great trouble understanding how the code generator works. I suspect the next thing I actually need to do is come up with a reduced testcase. The assembler output of system.pp is MASSIVE. continue and see what goes wrong. Some other comments about your patch: * please do not write code like this: if (target_info.abi <> abi_eabivfp) AND((p.proccalloption in [pocall_softfloat]) or (cs_fp_emulation in current_settings.moduleswitches) or (current_settings.fputype in [fpu_vfpv2,fpu_vfpv3,fpu_vfpv3_d16])) then Use this instead: if (target_info.abi <> abi_eabivfp) and ((p.proccalloption in [pocall_softfloat]) or (cs_fp_emulation in current_settings.moduleswitches) or (current_settings.fputype in [fpu_vfpv2,fpu_vfpv3,fpu_vfpv3_d16])) then Ok i'll try and remember that. * is hard float really only supported on ARMv7-A? There are several ARMv6 platforms that also support VFP. I belive it is in principle possible to use the hard float ABI with ARMv6. Not sure if any distro is doing so though. If there are it may make sense to make ARMv6 the default for an armhf compiler. * I'm don't think that requiring yet another different ARM compiler binary for this is the proper way. There's already enough confusion as it is with ppcarm variants. I think that there should be no problem to support both vfp-softfloat and vfp-hardfloat using the same binary, which should get rid of all the FPC_ARMHF defines. Currently the only FPC_ARMHF defines are selecting different defaults. You should still be able to select either ABI manually with either compiler binary if you wish. You can always select the appropriate default ABI via the global configuration file. You can but IMO it's neater to have a compiler built to use appropriate defaults for the system it's running on than to mess with generating and updating architecture specific configuration files. * "eabivfp" as a name for the ABI is confusing. The existing VFP support also uses the eabi. But it doesn't use the vfp variant of eabi. Something like eabihardfp would be better. mmm, I mused a bit over that name. It is at least in principle possible to have EABI variants for FPUs other than vfp. I don't think any currently exist though and if they do I guess one could always select on the FPU type. So maybe eabihf or eabihardfloat is indeed a better choice. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Where is the FPU set to a VFP type? I set it in code. Defining FPC_ARMHF selects a new version of "system_arm_linux_info" which sets the ABI to abi_eabivfp. That in turn triggers a block of code that I added to options.pas which sets the default fpu to "fpu_vfpv3_d16" and errors out if the user manually specifies a FPU that is not a VFP variant. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
Florian Klaempfl wrote:
Am 11.03.2012 12:01, schrieb peter green:
It appears to me (i'm not an expert on arm assembler and I can't seem
to find any documentation on FPA) that FPC is generating FPA
instructions even though the FPU is set to a VFP type. What i'm really
struggling to work out is why the heck that is happening. From telling
freepascal to include source lines as comments in the assembler it
doesn't look like inline assembler is responsible.
Can you please post the full assembler listing of a procedure containing
such code?
.section .text.n_system_$$_assign$real48$$double
.balign 4
.globlSYSTEM_$$_assign$REAL48$$DOUBLE
.typeSYSTEM_$$_assign$REAL48$$DOUBLE,#function
SYSTEM_$$_assign$REAL48$$DOUBLE:
# Temps allocated between r13+4 and r13+12
# [346] begin
stmfdr13!,{r14}
subr13,r13,#12
# Var $result located in register d0
# Var b located at r13+0
strr0,[r13]
addr2,r13,#4
movr1,#6
.Lj10088:
ldrbr3,[r0], #1
subsr1,r1,#1
strbr3,[r2], #1
bne.Lj10088
# [347] D:=real2double(b);
addr0,r13,#4
blxSYSTEM_$$_REAL2DOUBLE$REAL48$$DOUBLE
mvfdd0,f0
# Var $result located in register d0
# [348] end;
fstdd0,[r13]
ldfdf0,[r13]
addr13,r13,#12
ldmfdr13!,{r15}
.Le332:
.sizeSYSTEM_$$_assign$REAL48$$DOUBLE, .Le332 -
SYSTEM_$$_assign$REAL48$$DOUBLE
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.
I've made some progress on armhf porting, i've added the nessacery
frameworks (vfpv3_d16 FPU target, EABIVFP ABI target, FPC_ARMHF define)
and made a start on actually implementing the new ABI. I decided to
start with function results.
However i've now reached a problem which has me stumped.
When I try to build my patched compiler (using make compiler_cycle
'OPT=-dFPC_ARMHF' ) the starting compiler builds the RTL and compiler
successfully (as would be expected) but when ppc1 tries to build the RTL
things fail with assembler errors. The errors below are a sample of the
types of error seen (there are a HUGE number of each)
/fpc/rtl/units/arm-linux/system.s:19075: Error: selected processor does
not support ARM mode `mvfd d0,f0'
/fpc/rtl/units/arm-linux/system.s:19077: Error: selected processor does
not support ARM mode `ldfd f0,[r13]'
/fpc/rtl/units/arm-linux/system.s:41169: Error: selected processor does
not support ARM mode `ldfs f0,[r13]'
It appears to me (i'm not an expert on arm assembler and I can't seem
to find any documentation on FPA) that FPC is generating FPA
instructions even though the FPU is set to a VFP type. What i'm really
struggling to work out is why the heck that is happening. From telling
freepascal to include source lines as comments in the assembler it
doesn't look like inline assembler is responsible.
Anyone have any suggestions on where things might be going wrong and how
to debug this?
I've attatched a patch containing my efforts so far.
Index: rtl/arm/setjump.inc
===
--- rtl/arm/setjump.inc (revision 20511)
+++ rtl/arm/setjump.inc (working copy)
@@ -16,7 +16,7 @@
function fpc_setjmp(var S : jmp_buf) : longint;assembler;[Public, alias : 'FPC_SETJMP'];nostackframe; compilerproc;
asm
-{$if defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)}
{$if defined(CPUARMV3) or defined(CPUARMV4) or defined(CPUARMV5)}
fstmiax r0!, {d8-d15}
{$else}
@@ -46,7 +46,7 @@
movsr0, r1
it eq
moveq r0, #1
-{$if defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)}
fldmiad ip!, {d8-d15}
{$endif}
ldmia ip,{v1-v6, sl, fp}
@@ -57,7 +57,7 @@
mov ip, r0
movsr0, r1
moveq r0, #1
-{$if defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)}
{$if defined(CPUARMV3) or defined(CPUARMV4) or defined(CPUARMV5)}
fldmiax ip!, {d8-d15}
{$else}
Index: rtl/arm/math.inc
===
--- rtl/arm/math.inc (revision 20511)
+++ rtl/arm/math.inc (working copy)
@@ -14,7 +14,7 @@
**}
-{$if defined(FPUFPA) or defined(FPUFPA10) or defined(FPUFPA11) or defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$if defined(FPUFPA) or defined(FPUFPA10) or defined(FPUFPA11) or defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)}
{$define FPC_SYSTEM_HAS_ABS}
function fpc_abs_real(d : ValReal) : ValReal;compilerproc;
begin
Index: rtl/arm/mathu.inc
===
--- rtl/arm/mathu.inc (revision 20511)
+++ rtl/arm/mathu.inc (working copy)
@@ -177,7 +177,7 @@
begin
end;
-{$elseif defined(darwin) or defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$elseif defined(darwin) or defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_d16)}
const
_VFP_ENABLE_IM = 1 shl 8; { invalid operation }
Index: rtl/arm/arm.inc
===
--- rtl/arm/arm.inc (revision 20511)
+++ rtl/arm/arm.inc (working copy)
@@ -30,7 +30,7 @@
{$if not(defined(wince)) and not(defined(gba)) and not(defined(nds)) and not(defined(FPUSOFT)) and not(defined(FPULIBGCC))}
{$define FPC_SYSTEM_HAS_SYSINITFPU}
-{$if not defined(darwin) and not defined(FPUVFPV2) and not defined(FPUVFPV3)}
+{$if not defined(darwin) and not defined(FPUVFPV2) and not defined(FPUVFPV3) and not defined(FPUVFPV3_D16)}
Procedure SysInitFPU;{$ifdef SYSTEMINLINE}inline;{$endif}
begin
{ Enable FPU exceptions, but disable INEXACT, UNDERFLOW, DENORMAL }
Index: rtl/arm/setjumph.inc
===
--- rtl/arm/setjumph.inc (revision 20511)
+++ rtl/arm/setjumph.inc (working copy)
@@ -16,7 +16,7 @@
type
jmp_buf = packed record
-{$if defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)}
d8,d9,d10,d11,d12,d13,d14,d15: double;
{$endif}
v1,v2,v3,v4,v5,v6,sl,fp,sp,pc : dword;
Index: compiler/ninl.pas
===
--- compiler/ninl.pas (revision 20511)
+++ compiler/ninl.pas (working copy)
@@ -3094
Re: [fpc-devel] freepascal on armhf again
Maybe this will help you:
http://wiki.freepascal.org/FPC_New_Features_2.6.0#Support_for_VFPv2_and_VFPv3
Thus additionially defining -Cparmv6 might allow the build to be
completed.
It didn't.
I did find the issue though, it seems freepascal wasn't passing a fpu
type parameter to the assembler for any case except softfloat.
I fixed that but in the process discovered that freepascals vfpv3
support is the "d32" version of vfpv3 (yes arm floating point is a mess)
so I decided to try and add a vfpv3_d16 "fpu type". However when I did
so the compiler started outputting a rfs and wfs instruction when
compling the system unit which the assembler didn't like. I eventually
tracked that down to inline assembler in the RTL. Maybe we should add a
FPU_VFP define that is defined for all VFP variants so we don't have to
mess with the ifdefs in the RTL every time we want to add a variant of
VFP (afaict there are a lot of VFP variants).
In the process of working on that I discovered another problem,
according to a comment in the source freepascal's register allocation
does not currently understand the concept of two single precision
registers that overlap with one double precision register, this will
make correctly implementing the "eabi vfp hardfloat" calling convention
difficult but i'm going to get passing doubles working before I worry
about the complications involved in passing singles (and even worse
passing a mixture of singles and doubles).
I've attatched the diff of what i've done so far.
P.S. (mostly as a note to self) i'm currently using the following
commands to build
make compiler_cycle 'OPT=-dFPC_ARMEL' 2>&1 | tee ../buildlog
cp compiler/ppcarm /
make compiler_cycle PP=/ppcarm 'OPT=-dFPC_ARMEL -CfVFPV3_D16 -CpARMV7'
2>&1 | tee ../buildlog
Next step will be to modify the code in cpupara.pas to actually start
passing values in vfp registers.
Index: rtl/arm/setjump.inc
===
--- rtl/arm/setjump.inc (revision 20467)
+++ rtl/arm/setjump.inc (working copy)
@@ -16,7 +16,7 @@
function fpc_setjmp(var S : jmp_buf) : longint;assembler;[Public, alias : 'FPC_SETJMP'];nostackframe; compilerproc;
asm
-{$if defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)}
{$if defined(CPUARMV3) or defined(CPUARMV4) or defined(CPUARMV5)}
fstmiax r0!, {d8-d15}
{$else}
@@ -46,7 +46,7 @@
movsr0, r1
it eq
moveq r0, #1
-{$if defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)}
fldmiad ip!, {d8-d15}
{$endif}
ldmia ip,{v1-v6, sl, fp}
@@ -57,7 +57,7 @@
mov ip, r0
movsr0, r1
moveq r0, #1
-{$if defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$if defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)}
{$if defined(CPUARMV3) or defined(CPUARMV4) or defined(CPUARMV5)}
fldmiax ip!, {d8-d15}
{$else}
Index: rtl/arm/math.inc
===
--- rtl/arm/math.inc (revision 20467)
+++ rtl/arm/math.inc (working copy)
@@ -14,7 +14,7 @@
**}
-{$if defined(FPUFPA) or defined(FPUFPA10) or defined(FPUFPA11) or defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$if defined(FPUFPA) or defined(FPUFPA10) or defined(FPUFPA11) or defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_D16)}
{$define FPC_SYSTEM_HAS_ABS}
function fpc_abs_real(d : ValReal) : ValReal;compilerproc;
begin
Index: rtl/arm/mathu.inc
===
--- rtl/arm/mathu.inc (revision 20467)
+++ rtl/arm/mathu.inc (working copy)
@@ -177,7 +177,7 @@
begin
end;
-{$elseif defined(darwin) or defined(FPUVFPV2) or defined(FPUVFPV3)}
+{$elseif defined(darwin) or defined(FPUVFPV2) or defined(FPUVFPV3) or defined(FPUVFPV3_d16)}
const
_VFP_ENABLE_IM = 1 shl 8; { invalid operation }
Index: rtl/arm/arm.inc
===
--- rtl/arm/arm.inc (revision 20467)
+++ rtl/arm/arm.inc (working copy)
@@ -30,7 +30,7 @@
{$if not(defined(wince)) and not(defined(gba)) and not(defined(nds)) and not(defined(FPUSOFT)) and not(defined(FPULIBGCC))}
{$define FPC_SYSTEM_HAS_SYSINITFPU}
-{$if not defined(darwin) and not defined(FPUVFPV2) and not defined(FPUVFPV3)}
+{$if not defined(darwin) and not defined(FPUVFPV2) and not defined(FPUVFPV3) and not defined(FPUVFPV3_D16)}
Procedure SysInitFPU;{$ifdef SYSTEMINLINE}inline;{$endif}
begin
{ Enable FPU exceptions, but disable INEXACT, UNDERFLOW, DENORMAL }
Index: rtl/arm/setjumph.inc
===
--- rtl/arm/setjumph.inc (revision 20467)
+++ rtl/arm/setjumph.inc (working copy)
@@ -16,7 +16,7 @@
type
jmp_buf = packed record
[fpc-devel] freepascal on armhf again
I decided to take another look at the freepascal armhf issue and decided
that the first step would be to build freepascal with vfp enabled but
still the softfloat ABI then once that was working.
(note: i'm currently working on upstream fpc svn, if/when I get things
working reasonablly on armhf I will look into backporting to the version
in debian)
Unfortunately when I try to build freepascal with vfp enabled
make all 'OPT=-dFPC_ARMEL -CfVFPV3'
I get assembler errors.
/fpc/rtl/units/arm-linux/system.s:43697: Error: selected processor does
not support ARM mode `fmdrr d0,r2,r3'
/fpc/rtl/units/arm-linux/system.s:43698: Error: selected processor does
not support ARM mode `fmrrd r2,r3,d0'
/fpc/rtl/units/arm-linux/system.s:45460: Error: selected processor does
not support ARM mode `fmsr s0,r0'
/fpc/rtl/units/arm-linux/system.s:45461: Error: selected processor does
not support ARM mode `fuitod d0,s0'
/fpc/rtl/units/arm-linux/system.s:45463: Error: selected processor does
not support ARM mode `fldd d1,[r0]'
/fpc/rtl/units/arm-linux/system.s:45464: Error: selected processor does
not support ARM mode `fmuld d0,d0,d1'
/fpc/rtl/units/arm-linux/system.s:45465: Error: selected processor does
not support ARM mode `fmrrd r0,r1,d0'
/fpc/rtl/units/arm-linux/system.s:47271: Error: selected processor does
not support ARM mode `fstmiax r0!,{d8,d9,d10,d11,d12,d13,d14,d15}'
/fpc/rtl/units/arm-linux/system.s:47294: Error: selected processor does
not support ARM mode `fldmiax r12!,{d8,d9,d10,d11,d12,d13,d14,d15}'
/fpc/rtl/units/arm-linux/system.s:55773: Error: selected processor does
not support ARM mode `fldd d0,[r11,#4]'
/fpc/rtl/units/arm-linux/system.s:55795: Error: selected processor does
not support ARM mode `fmrrd r2,r3,d0'
/fpc/rtl/units/arm-linux/system.s:55827: Error: selected processor does
not support ARM mode `fldd d0,[r11,#4]'
/fpc/rtl/units/arm-linux/system.s:55849: Error: selected processor does
not support ARM mode `fmrrd r2,r3,d0'
Any idea what exactly these errors mean (e.g. do any processors support
these instructions and if so which ones), what is causing this (e.g. why
is freepascal generating these instructions) and what if anything I can
do about it?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] simple UTF tests
>But this seems to be be a propriety Microsoft definition while AFAIK, "ANSI" denotes "American National Standards Institute". While ANSI does denote american national standards institute in general it doesn't really mean that in this context. A windows machine has two main code pages in use (both language dependent and for some languages they may be the same code page). The "OEM" code page and the "ANSI" code page. The "OEM" code page is one of the original PC code pages and afaict is mostly used for the console. The "ANSI" code page is used for the non-unicode versions of stuff in windows itself. The term "ANSI" comes from the fact that the initial "ANSI" code page (1252) was based on an ANSI draft of what became ISO-8859-1. 1252 is fairly close to ISO-8859-1 (it just replaces rarely used control characters with more printable characters) but most of the other "ANSI code pages" bear little to no relationship to any ANSI or ISO standard encoding. Afaict in europe, america and australasia both the "ANSI" and "OEM" code pages are simple encodings with one byte per user-visiable character and all characters drawn left to right. Once you move to asia and africa though that no longer holds with CJK languages being represented by multibyte encodings, vietnamese being represented using combining characters and middle eastern languages bringing the complications of bidirectional text. MS encourages programmers to use unicode nowasays and afiact languages added more recently to windows (like the indic languages) don't have any non-unicode support at all. Windows also defines other code page numbers that are used as neither ANSI or OEM code pages. UTF-8 falls into this category. Delphi is a windows program (yeah there was an abortive linux port but that came much later and didn't stick arround for long) so it inherits windows terminology. FPC/lazarus is essentially a delphi clone but is cross platform so it's put in the position of trying to interpret and stretch windows grounded ideas to fit a cross-platform context. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] freepascal support for debian armhf
First a bit of background, on arm ebi gcc has three options for "-mfloat-abi" soft: do all floating point in software, ignore the fpu type selection softfp: use the selected fpu type but use the same calling conventions as "soft" (that is parameters are passed using integer registers). This gives binary compatibility with soft float code but in the case of vfp it comes at a substantial performance cost as all parameters must be moved between fpu and integer registers which causes pipeline stalls hard: use the selected fpu type and use fpu type specific calling conventions. Debian is in the process of introducing a new port called "armhf" which uses -mfloat-abi=hard with VFP (which seems to be become the dominant FPU now). Afaict from quick tests freepascal does support vfp but based on my tests always uses the "soft" calling convention. So it won't link correctly with C code that uses floating point parameters on debian armhf. 1: can someone who knows the fpc arm code confirm the above statement? 2: does anyone have any idea what it would take to add support for the eabi vfp calling convention and for building fpc binaries that use it by default (just as armel FPC binaries use eabi by default) 3: does anyone have any plans to actually do so (I might attempt it but i'm not a compiler developer nor am I an arm assembly programmer, just someone who uses both freepascal and debian on an arm system that could benefit from armhf) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc fails to link against libc on some architectures due to multiarch
tags 636802 +patch
thanks
Note: jonas's reply was only posted to fpc-devel, not to the debian bug
report , a copy can be found at
http://lists.freepascal.org/lists/fpc-devel/2011-August/025444.html
Jonas Maebe wrote:
Is there a standard for multiarch library path locations and names?
Multiarch seems to be a debian/ubuntu creation. Debian and ubuntu seem
to be consistent at least on i386 and amd64. I'm not sure what the
situation is with arm ports of ubuntu (note that multiarch triplets are
supposed to represent an ABI so two arm ports with incompatible ABIs are
supposed to have different multiarch triplets).
If not, that sounds like configuration option that should be added by distribution-specific patches.
I've attatched a patch to debian/rules to add the multiarch path to the
configuration installed by the debian package.
--- fpc-2.4.4/debian/rules 2011-07-04 22:41:08.0 +0100
+++ fpc-2.4.4.new/debian/rules 2011-08-18 08:35:48.0 +0100
@@ -62,6 +62,7 @@
DEB_UPSTREAM_VERSION:=$(shell echo $(DEB_VERSION) | cut -f 1 -d -)
DEB_UPSTREAM_MAIN_VERSION:=$(shell echo ${DEB_UPSTREAM_VERSION} | sed -e 's/^\([0-9\.]*\).*/\1/')
DEB_BUILD=$(lastword $(subst -, ,${DEB_VERSION}))
+DEB_BUILD_MULTIARCH:=$(shell dpkg-architecture -qDEB_BUILD_MULTIARCH)
ifndef PACKAGESUFFIX
export PACKAGESUFFIX=-${DEB_UPSTREAM_MAIN_VERSION}
endif
@@ -205,6 +206,9 @@
# Install configuration files
/bin/bash fpcsrc/compiler/utils/samplecfg \
/usr/lib/fpc/${DEB_UPSTREAM_VERSION} ${INSTALL_DIR}/etc
+ # Add multiarch path to /etc/fpc.cfg so executables linked against libc can be corectly linked
+ echo # multiarch library search path >> ${INSTALL_DIR}/etc/fpc.cfg
+ echo -Fl/usr/lib/$(DEB_BUILD_MULTIARCH) >> ${INSTALL_DIR}/etc/fpc.cfg
${MV} ${INSTALL_DIR}/etc/fpc.cfg ${INSTALL_DIR}/etc/fpc-${DEB_UPSTREAM_MAIN_VERSION}.cfg
# Install RTL demos
$(MAKE) -C demo sourceinstall $(INSTALLOPTS) INSTALL_SOURCEDIR=$(DOC_DIR)/fp-compiler/${DEB_UPSTREAM_MAIN_VERSION}
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
Armin Diehl wrote:
I need some hint regarding opening a serial (ttyUSB) port using the
unit serial. Minicom works fine under my user id. When i call
SerOpen('/dev/ttyUSB0'), fpopen blocks forever. When i first start
minicom on that port, SerOpen and all other functions of serial.pp
works fine.
I don't use serial.pp but here is how I open a serial port for basic
communication (no flow control, modem control or stuff like that) under
linux. I remember this taking some experimentation to get right.
procedure tlserial.open;
var
fd : longint;
config : termios;
baudrateos : longint;
begin
fd := fpopen(device,O_RDWR or O_NOCTTY);
if isatty(fd)=0 then begin
writeln('not a tty');
halt(1);
end;
fillchar(config,sizeof(config),#0);
config.c_cflag := CLOCAL or CREAD;
cfmakeraw(config);
case baudrate of
50: baudrateos := B50;
75: baudrateos := B75;
110:baudrateos := B110;
134:baudrateos := B134;
150:baudrateos := B150;
200:baudrateos := B200;
300:baudrateos := B300;
600:baudrateos := B600;
1200: baudrateos := B1200;
1800: baudrateos := B1800;
2400: baudrateos := B2400;
4800: baudrateos := B4800;
9600: baudrateos := B9600;
19200: baudrateos := B19200;
38400: baudrateos := B38400;
57600: baudrateos := B57600;
115200: baudrateos := B115200;
230400: baudrateos := B230400;
else raise exception.create('unrecognised baudrate');
end;
cfsetispeed(config,baudrateos);
cfsetospeed(config,baudrateos);
config.c_cc[VMIN] := 1;
config.c_cc[VTIME] := 0;
if tcsetattr(fd,TCSAFLUSH,config) <0 then begin
writeln('could not set termios attributes');
halt(3);
end;
dup(fd);
closehandles := true;
end;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpc fails to link against libc on some architectures due to multiarch
reassign 636802 fpc thanks From my testing on armel I now belive that the issue causing the lazarus build failures is a problem with freepascal and multiarch. I haven't tried to troubleshoot the issue on powerpc or sparc as I don't have access to them but I presume it is the same issue. On armel the problem seems to be that freepascal can't find crti.o in the new multiarch path. Confusingly if freepascal can't find crti.o then rather than throwing an error it simply omits it from link.res. Manually pointing freepascal at the multiarch path by using -Fl/usr/lib/arm-linux-gnueabi (for armel) allows the test program to be built successfully. I presume the problem is the same on powerpc and sparc but I have no way of testing those. So it would seem that the multiarch library path for the relavent architecture needs to be added to the default freepascal search path either through adding it to the default configuration file or adding it to the hardcoded list in fpcsrc/compiler/systems/t_linux.pas . ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: fpc build problems on some debian armel buildds
Jonas Maebe wrote: On 30 Jun 2011, at 19:04, peter green wrote: Mark Morgan Lloyd wrote: Riku Voipio wrote: On Thu, Jun 30, 2011 at 03:33:36PM +0100, peter green wrote: The current FPC package builds fine in qemu for me. I will attempt to try on some real hardware too when I get a chance. Qemu allows unaligned memory accesses, which do not always work on real hardware, especially on armv5 and other older arms. Is there a list anywhere of what hardware the buildds run on and/or any other interesting information about their setups so I can try to figure out what if anything the failing buildds have in common. Has anything changed in ancina's configuration recently? All currently running armel buildd's are identical marvell mv78x00 boards. Updates on ancina are the regular "apt-get upgrades" to get latest toolchain etc in sid. There were issues with some versions of FPC, related to more than a certain number of parameters (four?) being passed. Jonas wrote the following on the 5th October last year: Do you know if that fix has made it into any stable releases and if so which ones? It hasn't. It's only available in svn trunk (r16073) Is it reasonablly backportable? Are there any plans for a new stable release any time soon either based on the current stable release branch or freshly branched from trunk? Jonas___ 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] Re: fpc build problems on some debian armel buildds
Mark Morgan Lloyd wrote: Riku Voipio wrote: On Thu, Jun 30, 2011 at 03:33:36PM +0100, peter green wrote: The current FPC package builds fine in qemu for me. I will attempt to try on some real hardware too when I get a chance. Qemu allows unaligned memory accesses, which do not always work on real hardware, especially on armv5 and other older arms. Is there a list anywhere of what hardware the buildds run on and/or any other interesting information about their setups so I can try to figure out what if anything the failing buildds have in common. Has anything changed in ancina's configuration recently? All currently running armel buildd's are identical marvell mv78x00 boards. Updates on ancina are the regular "apt-get upgrades" to get latest toolchain etc in sid. There were issues with some versions of FPC, related to more than a certain number of parameters (four?) being passed. Jonas wrote the following on the 5th October last year: Do you know if that fix has made it into any stable releases and if so which ones? -8<- On 05 Oct 2010, at 10:05, Mark Morgan Lloyd wrote: > When running 2.4.0 on an ARM system (Debian v5 "Lenny", armel) with > limited memory (32Mb RAM + 768Mb swap) and using it to compile a large > project (Lazarus 0.9.28.2) I'm seeing intermittent failures which go > away if the make is restarted. I've not seen this running on other > platforms, and I don't believe it is a problem in the Lazarus sources > since the build will eventually complete giving me runnable code. A couple of days ago I fixed an error in svn trunk for ARMEL that caused the stack to become temporarily unbalanced after performing syscalls with 5 or more parameters (the bug is still there for OABI, but I can't fix that because I don't have access to an OABI machine). A side-effect of that bug was that if the caller passed the address of its own result as one of the parameters to the system call, it would afterwards return a random value as its result and checks for error results caused random failures like the one you posted (the reproducible case that allowed me to fix it was a similar error). Jonas ->8- There might be alignment issues on ARM and SPARC but I've only seen those with Lazarus, not with FPC itself. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: fpc build problems on some debian armel buildds
Riku Voipio wrote: Qemu allows unaligned memory accesses, which do not always work on real hardware, especially on armv5 and other older arms. Do you know specifically how the debian buildds handle unaligned accesses? do they fix them up? do they generate a bus error? do they let them go silently wrong? Regardless though I don't think that is the issue here as I've finally seen the einouterror in qemu after trying building in the precise path the buildd used (and I managed to reproduce it twice in a row under those circumstances). Unfortunately re-running the failing command manually succeeds so it seems like the long path alone is insufficiant to trigger the bug and there must be something in the environment the build system provides as well. I tried shoving a strace in there but that also seemed to stop it failing so i've no idea how I can track this down further. Another complication is that this is happening as the first new compiler is being built using the compiler installed on the build system, in other words even if the issue is tracked down and fixed a new manual upload is likely to be needed to fix it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpc build problems on some debian armel buildds
Freepascal has been failing sometimes with "einouterror file not found" on armel buildds but i'm not really seeing any pattern to the failures either in terms of upstream versions or in terms of buildds 2.4.0-2 was successfully built on muscat 2.4.0-3 failed on arnold 2.4.0-4 failed on arnold and ancina (the latter being a retry at my request) 2.4.2-1 was sucessfully built on alwyn 2.4.2-2 and 2.4.2-2 were successfully build on ancina 2.4.4-1 failed on antheil The current FPC package builds fine in qemu for me. I will attempt to try on some real hardware too when I get a chance. This is worrying for me because I use freepascal on armel and yet it's pretty hard to find a fix for a bug without a meaningful error message and which I cannot reproduce. Is there a list anywhere of what hardware the buildds run on and/or any other interesting information about their setups so I can try to figure out what if anything the failing buildds have in common. Has anything changed in ancina's configuration recently? Could some arm users try building fpc and reporting back if they can reproduce the error and if so on what hardware? (note: you must build with -B or you will run into an unrelated failure). If it fails for you can you try running the failing command under strace to try and determine what the file was? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Damaged .ppu problem
I don't think that people will be happy if the compiler just deletes their ppus if it can't read it for any reason. The compiler cannot know if it can recreate the ppu when it deletes it. Can't it just be made to treat a damaged/unreadable ppu in the same way as an outdated or incompatible (afaict fpc already has ways to deal with ppus that are from the wrong compiler version or built with the wrong version of a unit they depend on) ppu? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] size of extended
in the freepascal "programmers guide" it says "For all other processors which support floating point operations, the extended type is a nickname for the type which supports the most precision". A few points about this 1: is there a table anywhere of the size of extended on different platforms? if so should it be included in or at least referenced form the programmers guide? 2: the mentions of m68k (which was dropped a while back afaict) and very little else in the manual makes me suspect the manual in general may be rather outdated. 3: afaict x64 appears to have true extended yet the text strongly implies that x86 is the only architecture that does. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC on ARM, Debian "Lenny"
Debian "Lenny" has switched to armel rather than arm. Lenny is availible for both arm and armel. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal to Java compiler
Well, I think that the compiler could be shared between a native code and bytecode machine. I think the frontend (parsing the language into a tree structure) can certainly be shared, i'm not sure about the further back stages. Bytecode environments are certainly very different from native code in the sense that you can't just treat variables as variable sized lumps of bytes. - One should not attempt to implement Java or C# language constructs in Pascal. I think to produce a viable compiler you have to. Bytecode environments don't let you access memory directly so you don't have much choice but to use the class/interface structure provided by the bytecode environment. Furthermore all the standard libraries for the language rely on them as an interface so not being interoperable with them would be a huge pain. Lukilly other than the garbage collection issue delphi style object pascal and java/.net actually have pretty similar object models so it shouldn't be too hard to map them. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode support - for the 20th time... ;-)
For best backward compatibility, I would say Copy, Length, Pos etc should work by "character based" by default. The thing is we can't reasonablly provide functions based on what a user would see as a character because doing so would require huge lookup tables (one user visible character != one code point) so the best we can do is code point based which isn't really much better for most tasks than code unit based and would make certain operations MUCH slower. In other words it would be a major speed penalty for a minor gain. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode support (again)
Michael Schnell wrote: It will at best be "friendly old school behaviour which works most of the time, but which fails as soon as the strings are not completely normalised because then you can have decomposed characters and whatnot" (which in turn easily leads to security holes due to incomplete checks, hard to reproduce bugs and "write once, debug everywhere"-style behaviour). Sorry, I don't understand. What not normalized behavior needs to be taken into account ? Remember that an individual code point does not nessacerally represent what a user would consider a character. Indeed one character may be representable in more than one way (either as a precomposed character or a sequence of base character and combining diacritic). And even if we ignore combining diacritics the number of console positions a string takes is not nessacerally equal to the code point either since many CJK characters take two console positions. Given theese facts code point counts and indexes are not much more usefull than code unit indexes and counts. And if you need something better than either code point count or code unit count then you have little choice but to pull in an external library. Pulling in an external library with a relatively unstable interface is not something the compiler or RTL should be doing IMO. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] circular uses clauses
Because a Pascal compiler parses the interface section of an unit only once, ... IMO what would fix a lot of the problem would be a "cross unit forward declaration", that is a way to tell a compiler "this type is a class type declared in unit x that is all you need to know for now" (afaict that is all the compiler needs to know to compile a function prototype or similar) The current situation means that a set of interrelated classes often must either all be put in the same unit or do a lot of typecasting. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Check again... I have just checked the manual and I don't see anything I can use to make sure my custom type starts at a predictable state initially (nessacery so they assignment operator can safely clean up before making the assignment). Nor do I see anything to do automatic clean up when the variable goes out of scope. But it is still a bad idea (like c++) How does one recognize a deep vs shallow string copy f.e. You don't have to! With the java system the string type is immutable anyway so there is no point in doing a deep copy. With the delphi/fpc system the string type automatically makes a shallow copy initially and then copies the actual data if and when it becomes nessacery to do so. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
I fully agree with you. I would like the object oriented way of strings also - but I stopped asking for that ;) There are a lot of advantages over the small amount of disadvantages. Which object orientated way of doing strings? As I see it there are three main ways of doing variable length strings. 1: Let the programmer manage the memory lifetime (the C way), this is tedious, error prone and generally results in lots of unnessacery copying of strings since it is easier for the programmer to have seperate copies owned by different objects than to manage shared strings. 2: Use immutable objects and let the garbage collector clean them up (the java way), this works but since the strings are immutable they must be copied to make any modification. It also relies on a garbage collector will all it's associated problems. 3: Use an automatic reference counting system either implemented in the compiler (the delphi/fpc way) or implemented using a very powerfull operator overloading system (the C++ way, last I checked freepascal did not have sufficiant operator overloading capabilities to implement this) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resourcestrings
This has been discussed before. Automatic conversion to/from ansistrings will always be to/from system encoding. If you want another encoding than the system encoding you will have to do a manual conversion. Actually you as the application developer can control how conversions between ansistrings and widestrings are handled by using getwidestringmanager/setwidestringmanager . So for example you could use a byte value of $7F at the beggining of an ansistring as a marker that the string was in UTF-8 and implement a Ansi2WideMoveProc that checked for it and either interpreted it as UTF-8 if it saw the marker and passed it off to the old Ansi2WideMoveProc if not. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] the libc unit on 64-bit systems
All I really use 'libc' for is to retrieve the user name and group name from the user and group id's of files. As I said, it's not critical, I can always display the id's only. Or maybe parse the /etc/groups and /etc/passwd files to get the names, but I heard that's not very accurate for some reason. Really the only reliable way to get that information is to link with libc. Reading the files in /etc will work on a basic system but will fail if an alternate authentication system is in use. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Controlling the output of the widestring manager
Felipe Monteiro de Carvalho wrote: Hello, Today I took a look at what would be necessary to implement controlling the output of the widestring manager, and implementing this looks rather trivial. The only thing we need is a switch, to control if widestrings should be converted to the current locale or to utf-8. In the case of current locale one can use the current widestring function Wide2AnsiMoveProc . In case of utf-8 we can use the cross-platform UnicodeToUTF8 function. I would start by adding a new field to TWideStringManager: OutputUTF8ToStrings: Boolean; Then when converting a widestring to a short string one should check which procedure to call. I could check all places that call Wide2AnsiMoveProc and instead do: if OutputUTF8ToStrings then UnicodeToUTF8() else Wide2AnsiMoveProc () Or we could add a procedure which does this automatically. Or maybe something else. So, which would be the prefered way? thanks, The whole point of the widestring manager system that it allows you to replace the default conversion routines with whatever conversion you wish. If you want UTF-8 then just write a set of widestring manager routines that do UTF-8. If you want ones that use the windows conversion APIs (which let you convert to any code page that is installed in the system by specifying it's codepage number) write ones that use the windows coversion APIs. If you want ones that use ICU write ones that use ICU and so on. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Widestring and reference counting
Using the following example program and compiling with 'fpc -al wstest.pas' under Linux to see the assembler file (not that I can remember anything of how assembler works). Looking at the asm code I see a call to FPC_WIDESTR_INCR_REF which I assume confirms that WideStrings under Linux using FPC is also reference counted. Is the same true under Windows? Does that mean FPC doesn't have the WideString issues Delphi has? Widestrings under windows are not reference counted for OLE compatibility, on all other platforms they are reference counted. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] copyright infringement in FPC code
And a single code comparison can be seen here... FPC code is on the right. http://www.stevetrefethen.com/files/ppcomp.htm Reading the description carefully it seems like he has modified the delphi code to look more like the FPC code. In many cases two people trying to implement the same relatively simple behaviour will end up with code that differs in little more than variable names and spacing without needing to copy. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Having an always utf-8 string
Felipe Monteiro de Carvalho wrote: Hi, I would like which would be the theoritical way that Free Pascal could support an always utf-8 encoded string (if it will be supported). With that I mean a string which when set by code is converted from widestring to utf-8 in despite of any environmental conditions, or operating system conditions. So I can open a feature request for it. You can do this yourself, just create a record containing an ansistring and then use operator overloading to control how it behaves in assignments to other types. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] what fpc is good for?
> Non trivial Delphi GUI apps also quickly rise to 1.5MB lazarus may produce apps that are size comparable with those from the recent versions of delphi but those are also megabloat compared to those produced by the older versions of delphi. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] C++ Linking technology
> They don't have to: the compilers/interpreters for these languages are > written in C. All they need to do in the worst case is compile a small > stub. For Pascal, the situation is not so simple, as there is no > connection > with C whatsoever. well there is nothing to stop you writing stubs in C/C++ to use with your pascal application, i don't see how thats any harder than writing a C++ stub to call from a plain C interpreter. C++ on linux is a bit of a nightmare though with libstdc++ changing ABI all the time and apps linked against multiple versions of libstdc++ tending to crash so C++ code in your app may be something you want to avoid. you could possiblly ship the c++ as source and the pascal as .o files avoiding the need for fpc on the users machine while avoiding the libstdc++ versioning issues. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] graph module
> > The graph unit is pretty generic in this respect. You indeed only need > > to implement putpixel, getpixel, graphics mode detection, setting a > > graphic mode, setting and getting colour palette entries for indexed > > modes, and closing down the graphic system again. But it's perfectly > > possible to also intercept line, elipse, rectangle etc and to > implement > > them directly in the "driver". > > So, I may implement only putpixel and etc, but then if I wish I may > implement line and othe stuff inside my part of code (or somewhere)? while you can implement just putpixel and such doing so is a surefire way to get terrible performance. to keep overhead down the conversion of shapes into pixels should be pushed as close to the framebuffer as possible, preferablly into the graphics card. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Freepascal 2.0.4 made it to Ubuntu Feisty
> PPC is getting dropped in Fiesty, they will no longer officialy support > PPC. well they are making it no longer an official architecture but they aren't dropping it completely so pressure still needs to be kept up for them to build it on powerpc ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Freepascal 2.0.4 made it to Ubuntu Feisty
> Just like to say, that I noticed the other day that Freepascal 2.0.4 has > made it to the Ubuntu Feisty Universe repositories. Ubuntu Feisty is > expected to be out in April, but has never had Freepascal in it's > repositories before. > > I think this is great news for Freepascal... FINALLY looks like they've built and uploaded the fpc source that was sitting in edgy too only i386 and amd64 though by the looks of things not powerpc i wonder what they will do about updating it though, getting a non-autobuilt binary uploaded on ubuntu is like getting blood out of a stone so there will be problems if they miss a release of freepascal. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] procedure ... message
> What does the compiler do when translating "procedure ... message" ? > > I need to know this as I want to create a non-GUI workalike of the > TApplication class that can do things like "TTimer" > "TThread.Synchronize", Message events, etc, using Windows messages in > Windows (for testing purpose) and system V message queues in Linux. afaict it does the same as delphi does, puts them in some form of table which is used by the dispatch method in tobject (which on delphi at least is called from wndproc which is called from mainwindowproc which is registered as the window procedure for the window and hence called by windows when the mainloop calls the windows api function dispatchmessage). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] strings: a proposeal
> What's wrong with > > type >tmywidestring = type array of widechar; a number of things 1: afaict it lacks the automatic refcounting/copy on write semantics of strings 2: it doesn't allow specification of the allocators/deallocators which causes problems for its safe passing to dlls etc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] strings: a proposeal
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Daniël > Mantione > Sent: 04 February 2007 00:09 > To: FPC developers' list > Subject: Re: [fpc-devel] strings: a proposeal > > > > > Op Sun, 4 Feb 2007, schreef peter green: > > > my proposal is a statement like > > > > type > > tmystring=string(elementtype,allocator,deallocator,copier,uniquer); > > And how should you generate debug information for such a user defined > string? if we require user defined string types to keep the conventions that the underlying pointer points to the first character (with metadata at negative offsets) and that there is a null after the last character in memory then at least for simple element types debugging tools should be able to handle them in the same way they currently do (by treating them as C strings). from a low level perspective such a string is just a pointer to an array plus some compiler magic just like current ansistrings, debugging tools shouldn't need to be aware of the magic any more than they need to be aware of it for current ansistrings. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] strings: a proposeal
currently there is some demand for a fast widestring type on windows and i suspect there will be requirements for more string types in the future. So i make a proposal for a new syntax that will allow string types to be created easilly in libraries or user code. my proposal is a statement like type tmystring=string(elementtype,allocator,deallocator,copier,uniquer); the allocator,deallocator,copier and uniquer would generally be inline functions the elementtype may be any type that doesn't use any compiler magic the allocator allocates a new string of a given number of elements and returns a pointer to the first element, length refcount the allocator and deallocators jobs are obvious to create new strings and reduce the reference count of/dispose of old ones. the copiers job is to increase the reference count if the string is reference counted or copy the string if not the uniquers job is to copy the contents of the string if it is refcounted and its reference count is greater than 1. indexing of the string would be handled in the same way as current strings, that is normally direct access but call the uniquer automatically before starting writes if my understanding is correct this should allow all the widestrings stuff to be moved to the library and people to implement thier own string types as required (for example maybe a widestring counterpart for some system that is similar to com) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Incompatibilities between win32 windows unitandwince windows unit
> I'm not particularly happy with "pascalization" of direct interfaces > myself. me neither, my understanding of this problem is that borland pascalised the windows unit in delphi and freepascal followed suite for win32. but for whatever reason the same was not done for wince. since wince support is so new i'd normally say just change wince to match win32 but that will break a lot of wince using code in strange ways (as you will effectively be passing windows a pointer to a pointer when the windows api expects a pointer to data). maybe the answer is to build two windows units, one called windows and only availible on win32 which will be effectively a delphi compatibility unit and marked as such in the docs and one called say winapi that will be a direct translation without any of this pascalisation. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Incompatibilities between win32 windows unit andwince windows unit
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Aleš Katona > Sent: 07 January 2007 09:55 > To: FPC developers' list > Subject: Re: [fpc-devel] Incompatibilities between win32 windows unit > andwince windows unit > > > On Ne, 2007-01-07 at 00:23 -0200, Felipe Monteiro de Carvalho wrote: > > Hello, > > > > I am porting fpgfx to Windows CE. During this work I noticed a lot of > > incompatibilities between win32 windows unit and wince windows unit. > > Trivial stuff, like a parameter is var on win32, but is a pointer on > > wince. > > > > Is there any special reason why it´s like that? Should we try to get > > both units as compatible as possible? Can I send a patch for that? > > > > thanks, > > I'm not an expert on the windows unit but I encountered similar problems > among platforms and I think we should defenetly go for compat. The best > thing you can do (so nobody can say anything) is "complement" both ends. > So eg: > > you got this in 2 windows unit: > > W1. function A(const data): Pointer; > > W2. function A(data: Pointer): Pointer; one big problem with this sort of thing is that you can pass anything to an untyped const parameter *INCLUDING* a pointer, so if you change something from taking an untyped pointer to taking an untyped const parameter you are going to cause strange bugs for users. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] LGPL vs MPL
> Btw, see > http://www.sun.com/software/opensource/java/faq.jsp#g4 > some discussion on why one would choose for example GPL + Classpath > exception (an amendment text from the Classpath project) vs LGPL. > These two > seem equivalent, but the 1st means that one can include in some Linux > distros that require GPL which distros would those be? given that glibc is lgpl i can't imagine that resistance to it is exactly common in the distro environment ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] help with softfloat for arm big endian crosscompiler
> On the long run I am interested in making (embedded) FPC programs run on > (our own) ARM-hardware. > I only found notice about FPC programs for PDAs. Am I right assuming > that there is no special problem using a displayless ARM9 device (like a > slug) for FPC programs ? afaict the slug is quite high end as embedded stuff goes and should be able to handle the full rtl with no problems. just a matter of sorting out the softfloat issues and if you decide to run in big endian mode changing the endian setting and fixing anything that change breaks. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] fdRead?
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Marco van de > Voort > Sent: 16 December 2006 11:17 > To: FPC developers' list > Subject: Re: [fpc-devel] fdRead? > > > > Hi. Can someone please tell me what the idea behind "fdRead" was? > > Roughly 1.0.x equivalent of fpread. However WinSock packages it as part of > the socket. personlly i'd say nuke it, portable sockets code should really be using recv instead (though winsock differs from unix sufficiantly that most serious apps will wan't to seperate the code anyway) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] help with softfloat for arm big endian crosscompiler
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Michael > Schnell > Sent: 15 December 2006 11:59 > To: FPC developers' list > Subject: Re: [fpc-devel] help with softfloat for arm big endian > crosscompiler > > > > however some hardware is wired up for big endian (the linksys > NSLU2 springs to mind) and hence is a pain to get little endian > linux running on (i belive the network now works in little endian > mode but the front panel lights are still broken) > > > AFAIK, the SLUG Linux is running since a log time Indeed >(I don't know with > what shortcomings, but the Network works, The slug as shipped by linksys runs armeb linux and most of the earlier unofficial attempts were also armeb based. Later they got little endian arm linux to work on the thing but for a long time the built in network adaptor didn't work with little endian linux (thats now fixed i belive) and last i checked front panel lights still weren't working in little endian linux. For TCP/IP hardware big endian just plain makes sense as network byte order is big endian. I dunno how much difference this and the byteswapping drivers make to practical performance though. finally some of us would quite like to have a big endian system arround for testing on and as big endian systems go the slug is cheap! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] help with softfloat for arm big endian crosscompiler
> Hola, most modern ARM cpu's support big endian, that is not the point. > Question is how many an big endian platforms exists, and this is not so > popular, because even if you switch the cpu to big endian, the underlying > hardware remains little endian (with the cpu doing the conversion). This > means that driver code etc. suddenly needs to care about endian > conversions. however some hardware is wired up for big endian (the linksys NSLU2 springs to mind) and hence is a pain to get little endian linux running on (i belive the network now works in little endian mode but the front panel lights are still broken) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Growing a memory stream
> > Well, the linked list would be freed (or the first item of it enlarged > > to the total size, depending on implementation details). > > Still, the peak memory use will twice the size, won't it? sure but unless you are very lucky a call to reallocmem also means alocate-copy-deallocate. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] syncobjs unit
> The thing is full of this. Problem is, each OS and platform has slightly > different arguments and return types AND we need to be flexible enough > to support more than one threading implementation on same platform too > (so no godamn ifdefs). use INT64 everywhere? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] rev. 5356
> 5356 - does not compile under win32 (ppc1 does not stop compiling > pp.pas [neither fails, nor succeeds]) > (memory usage in process list freezes at 31444 Kb) what starting compiler are you using? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] FPC 2.0.4
> Currently we have been developing on FPC for both Windows and Linux and we >have noticed that socket communications are not working correctly under Linux environments. please define what you mean by not working correctly, preferally with a test app > I have also been advised that the netdb has issues on 2.0.4? is this correct? dunno i gave up on using netdb when a friend added IPV6 to the sockets wrapper i use and needed workable IPV6 dns code. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] CmdLine
> CmdLine as property will be great, but I found that property > getter/setter need to be declared before property declaration in the > interface part. This will garbage a global namespace with private > getters/setters. > > Is it possible to make compiler to accept getters/setters not > declared in the interface part, but implemented in the implementation? another way to solve this would be to allow use of public and private outside classes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] request for new compiler option
i'd like a way to tell the compiler not to allow implicit conversions between certain types (e.g. ansi/shortstrings and widestrings) this would make it much easier to clean up existing code that carelessly converts between two sort of but not very compatible types. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
