[fpc-devel] co-processor offset out of range issue in Debian armhf.

2017-01-26 Thread peter green

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

2015-06-17 Thread peter green

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

2014-12-24 Thread peter green

Sergio Flores wrote:


Eg: Calling lnxp1(x) with x1 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


Re: [fpc-devel] Building 2.7.1 on current Raspbian fails

2014-10-23 Thread peter green

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

2014-10-22 Thread peter green

 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

2014-10-22 Thread peter green

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

2014-10-21 Thread peter green

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

2014-10-21 Thread peter green

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

2014-10-21 Thread peter green

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

2014-10-20 Thread peter green

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

2014-10-18 Thread peter green

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?

2014-03-09 Thread peter green

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?

2014-03-08 Thread peter green

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

2014-03-07 Thread peter green

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?

2014-03-06 Thread peter green

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?

2014-03-03 Thread peter green

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 on odroid (ARM hardfloat)

2013-08-10 Thread peter green

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)

2013-05-30 Thread peter green

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)

2013-05-29 Thread peter green
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/multiarch triplet


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/multiarch 
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

2013-05-08 Thread peter green

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

2013-04-08 Thread peter green

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

2012-10-04 Thread peter green

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.

2012-08-12 Thread peter green
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

2012-08-01 Thread peter green

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] vfp exception issues with freepascal

2012-07-28 Thread peter green
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 stdio.h

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] Re: vfp exception issues with freepascal

2012-07-28 Thread peter green

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] Re: vfp exception issues with freepascal

2012-07-28 Thread peter green

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] Inline assembler.

2012-07-19 Thread peter green
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

2012-03-26 Thread peter green

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

2012-03-24 Thread peter green


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] Patch: Add support for armhf

2012-03-21 Thread peter green

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


Re: [fpc-devel] passing options for the build process.

2012-03-21 Thread peter green

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/multiarch triplet* (or lib/multiarch triplet). 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] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)

2012-03-20 Thread peter green

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] update on freepascal armhf porting, doubles are working now for singles.

2012-03-20 Thread peter green



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 paramcount  0 then 

[fpc-devel] passing options for the build process.

2012-03-20 Thread peter green
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] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)

2012-03-19 Thread peter green




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)

2012-03-18 Thread peter green

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 ireg23,.Lj38
   

Re: [fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)

2012-03-18 Thread peter green




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


[fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)

2012-03-17 Thread peter green


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]
# Register s0 released
   

[fpc-devel] update on freepascal armhf porting, doubles are working now for singles.

2012-03-16 Thread peter green
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.

2012-03-15 Thread peter green

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


[fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.

2012-03-11 Thread peter green
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)
@@ 

Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.

2012-03-11 Thread peter green

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


Re: [fpc-devel] More on freepascal armhf porting attempt, some progress made but now stuck.

2012-03-11 Thread peter green




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.

2012-03-11 Thread peter green


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.

2012-03-11 Thread peter green




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.

2012-03-11 Thread peter green



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.

2012-03-11 Thread peter green



NR_S0NR_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] freepascal on armhf again

2012-03-04 Thread peter green




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' 21 | tee ../buildlog
cp compiler/ppcarm /
make compiler_cycle PP=/ppcarm 'OPT=-dFPC_ARMEL -CfVFPV3_D16 -CpARMV7' 
21 | 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
-{$if 

[fpc-devel] freepascal on armhf again

2012-03-03 Thread peter green
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

2012-01-09 Thread peter green
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

2011-09-05 Thread peter green
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

2011-08-19 Thread peter green

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

2011-08-18 Thread peter green

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

2011-08-12 Thread peter green

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


[fpc-devel] fpc build problems on some debian armel buildds

2011-06-30 Thread peter green
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] Re: fpc build problems on some debian armel buildds

2011-06-30 Thread peter green

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


Re: [fpc-devel] Re: fpc build problems on some debian armel buildds

2011-06-30 Thread peter green

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

2011-06-30 Thread peter green

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] Damaged .ppu problem

2010-01-14 Thread peter green



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

2009-10-30 Thread peter green
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

2008-12-13 Thread peter green




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

2008-11-28 Thread peter green

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... ;-)

2008-11-20 Thread peter green



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] Unicodestring branch, please test and help fixing

2008-09-09 Thread peter green



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] Unicodestring branch, please test and help fixing

2008-09-09 Thread peter green



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] Unicode resourcestrings

2008-02-29 Thread peter green




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

2008-02-01 Thread peter green



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

2007-11-27 Thread peter green

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

2007-11-24 Thread peter green



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

2007-11-13 Thread peter green



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] what fpc is good for?

2007-05-12 Thread peter green

 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

2007-04-27 Thread peter green
 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] Freepascal 2.0.4 made it to Ubuntu Feisty

2007-02-15 Thread peter green

 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] procedure ... message

2007-02-12 Thread peter green

 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

2007-02-04 Thread peter green
 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


[fpc-devel] strings: a proposeal

2007-02-03 Thread peter green
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] strings: a proposeal

2007-02-03 Thread peter green


 -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


RE: [fpc-devel] Incompatibilities between win32 windows unit andwince windows unit

2007-01-07 Thread peter green


 -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] Incompatibilities between win32 windows unitandwince windows unit

2007-01-07 Thread peter green

 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] LGPL vs MPL

2006-12-26 Thread peter green

 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

2006-12-18 Thread peter green

 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?

2006-12-16 Thread peter green


 -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

2006-12-15 Thread peter green


 -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

2006-12-14 Thread peter green

 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

2006-12-11 Thread peter green
  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

2006-11-30 Thread peter green

 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

2006-11-14 Thread peter green

 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

2006-10-22 Thread peter green
 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

2006-10-20 Thread peter green

 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

2006-10-18 Thread peter green
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


RE: [fpc-devel] type question

2006-10-14 Thread peter green
one trick if you wan't to keep a type but redefine the operators on it is to
wrap it in a single element record.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Marc
 Weustink
 Sent: 14 October 2006 16:42
 To: FPC developers' list
 Subject: Re: [fpc-devel] type question


 Peter Vreman wrote:
  On Saturday 14 October 2006 15:55, Marc Weustink wrote:
  Hi,
 
  if I define 2 types like:
 
  type
MyA = type string;
MyB = type string;
 
  are MyA and MyB considered as the same type ?
  No, you are explicitly marking them as a new type. This is a very cool
  feature
  of Pascal you wont find in many other languages.
 
  (For instance, you could use it to create a new integer-type
 for little-
  and
  big-endian numbers, ensuring that you _never_ directly assign a
  little-endian
  number to a big-endian one, or vice versa)
 
  For the compiler the types are not equal anymore, but they are still
  compatible for implicit type conversion. This has mainly impact on
  overload choosing and parameter passing. Normal assignments
 using ':=' are
  not affected because of the still available implicit type conversion.

 I came to this when I wanted to do operator overloading on them. The
 compiler complained that you cannot overload for equal types.

 So I wanted first to know if it are equal types or not.

 Next question: Should operator overloading be possible on such types ?

 Marc

 ___
 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] type question

2006-10-14 Thread peter green

 In the case of wrapper integers in records, are 4-byte records handled as
 efficiently by the compiler as 4-byte integers? I suspect it's
 some radically
 different code that handles it.
test it?


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


RE: [fpc-devel] Default strings encoding

2006-10-10 Thread peter green
  I'm not sure what
  WideString holds. Maybe UTF-16? Or a limited UTF-16 with only 2 bytes
  characters.

 UCS-2. Basically this is UTF-16 with only 2-byte characters, allthough
 there are small differences in the high regions; UCS-2 is code
 points $0..$, while UTF-16 has facilities to allow for multiword
 characters.
there is nothing intrinsic about how widestring is implemented that stops it
holding UTF-16 multiword characters, its just a matter of whether the
routines its passed to do (on windows i belive surrogate support depends on
a registry setting and is disabled by default on western editions).


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


RE: [fpc-devel] Language extension: absolute for classes

2006-10-01 Thread peter green

 Changing type to something which is not a descendant (and thus
 incompatible) seems useless and always dangerous to me, so should be
 forbidden if possible.
useless yes, dangerous if not carefull yes but its the number one way for
bypassing protected ;)

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


RE: [fpc-devel] Language extension: absolute for classes

2006-10-01 Thread peter green


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Micha
 Nelissen
 Sent: 01 October 2006 21:41
 To: FPC developers' list
 Subject: Re: [fpc-devel] Language extension: absolute for classes


 peter green wrote:
  Changing type to something which is not a descendant (and thus
  incompatible) seems useless and always dangerous to me, so should be
  forbidden if possible.
  useless yes, dangerous if not carefull yes but its the number
 one way for
  bypassing protected ;)

 protected as in language (type) protection ?
protected as in the protected modifier for stuff in a class which is hugely
overused in the vcl.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


RE: [fpc-devel] Linking problem

2006-09-23 Thread peter green
i'm guessing (i could be wrong) that you need to link in libstdc++

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Ivo
 Steinmann
 Sent: 23 September 2006 19:48
 To: FPC developers' list
 Subject: [fpc-devel] Linking problem
 
 
 Hello all
 
 I tried to link libmodplug.so but get this error:
 
 /usr/lib/libmodplug.so: undefined reference to `operator new[](unsigned 
 int)'
 /usr/lib/libmodplug.so: undefined reference to `operator delete(void*)'
 /usr/lib/libmodplug.so: undefined reference to `operator delete[](void*)'
 /usr/lib/libmodplug.so: undefined reference to `operator 
 new(unsigned int)'
 
 do I have to link another library also (something like libstd) or is 
 there a way that I can define those function in my application? Im a 
 littlebit confused about operator
 
 greets
 Ivo
 ___
 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] Propose: change TComponent.Tag from longint to PtrInt

2006-09-04 Thread peter green

 ...which makes it impossible to use streams for anything derived from
 Tcomponent, which is really a lot. I don't think we should break this
 feature to allow broken code to work.
BTW even borland themselves seemed to promote its use for storing pointers

from delphi 3 help:
Tag has no predefined meaning to Delphi. The Tag property is provided for
the convenience of storing additional integer value or pointer information
for special needs in an application. For example, use the Tag property when
implementing case statements with a component.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


RE: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt

2006-09-03 Thread peter green

 I'd like to propose change TComponent.Tag type from longint to PtrInt.
 I know it's not a good programing practice, but sometimes this property
 can be used to hold pointers.
 In 32bit there's not many problems since pointer and longint have the
 same size,  but the thing changes in 64 bit.
 The choice of PtrInt has the benefit of not modifying nothing in 32bit,
 while in 64bit you getting a integer of the same size of pointers.

 What do you think?
do it, this was a very common use of tag in lots of delphi code and i can't
see any problems with having it as a 64 bit type.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


RE: [fpc-devel] FPC 2.0.4 is out!

2006-08-29 Thread peter green

 I would love to be a maintainer and build .deb files, however I do not
 own a 64 bit CPU and can't afford one at the moment because it would
 also mean a new motherboard and RAM too, so that crosses me out pretty
 much. In fact, I really would love to see Free Pascal packages in the
 Ubuntu universe repositories in the future.
the source package is already there. The problem is that the autobuilders can't 
build it (because of the recursive build dep issue) and there seem to be very 
few people who have permission to upload manually built packages in ubuntu.

IMO it would be a good idea to restructure the debian packaging of fpc to 
include starting compilers as part of the source. What do others think?

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


  1   2   >