Re: [fpc-devel] Proposal: Multiple assignments
Sven Barth wrote: Does _any_ language support that paradigm ? Python: [...] Java: Also Perl as (a, b) = (0, 0); I can't remember whether a single value on the RHS is expanded. Although "a=b=c" is more like "assign c to b and assign (the new value of) b to a" (but it might work in C as well that way). Please excuse a comment from a non-developer but I really don't like this form. I've coded a number of parsers for script languages etc. and in general provided that you don't allow multiple assignment you can always work out unambiguously whether you're looking at an assignment or a test for equality, even without mandating distinct tokens. I think that the OP needs to research first whether what he is trying to do could be done by a typed constant assignment, or if there is some way of building on the associated semantics rather than attempting ill-considered mutilation of Pascal's underlying syntax. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Some proposals
_-jan...@web.de wrote: I recently put other proposals on http://wiki.freepascal.org/Talk:Modernised_Pascal. However I am not sure whether this is the right place to put this. The forum appears to be a better place. Anywhere but here I'd suggest. The general FPC mailing list would be better, or somewhere where all dialects of Pascal are discussed. Most people put this sort of thing on their personal web page and wait for the World to beat a path to their door, or in a science fiction forum. Speaking as somebody who's been using FPC increasingly over the last five years or so I normally only post in here when I've got intractable build problems. I'm very grateful for the help I've received and the entire community appreciates that the core developers are readily accessible. Using this mailing list for proposals which haven't been debated in depth elsewhere is going to spoil things for everybody. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Enhanced replacement for assignment operators
Alexander Klenin wrote: inc and dec work fine as far as I know for over a decade. Hm, just re-checked -- no, they do not. OK on scalars I believe but not on object properties. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Multiple assignments
Sven Barth wrote: Well... in C a test for equality is always "==". So, when reading it (and not having read a Pascal code some minutes before :P ) one should recognize without problems whether it's an assignment or a comparison expression (it's another story that many people - including me - don't recognize it that easily ^^) As in the classic patch + if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) + retval = -EINVAL; which somebody tried to slip into the Linux kernel. I think though that you only need distinct tokens (i.e. == vs = in the case of C) if the language includes multiple assignments. Or possibly I should say indeterminate assignments, lest there are cases where being able to discard a function's return value introduces ambiguity. So some variant of OP's suggestion such as (a, b):= 0 does have something going for it, at least when compared with a:= b:= 0. In fact- although I don't know whether this is parseable- (a, b):= X with implicit duplication as compared with (a, b):= (X, Y) where both sides have to match, since this is beginning to look like something that could be parallelised . -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] GPM vs Debian warning messages
Looking at http://www.freepascal.org/probs.var I see that FPC still has bug 0008416 open and marked "not fixable", but that it was fixed from the Debian side in February '08 (their http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412927). Would it be appropriate for somebody to remove the startup warning when FP finds itself running on Debian? From the description the problem will only affect Debian "Sarge" or older, and when I tried a year or so ago it appeared that a current FP will not build for a distro of that age due to other library incompatibilities. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
I've previously had FPC (and Lazarus) running natively on Debian ARM, but I think it was "Etch"- things got a bit cloudy after that. The kernel being shipped with Lenny is 2.6.26-2 and I note CONFIG_AEABI=y CONFIG_OABI_COMPAT=y If I download the binary for 2.2.2 it won't compile a trivial app as it stands, but if I use OPT=-CfSOFT I can rebuild it or build a 2.4.0 that appears to work. Is what I am doing reasonable, or should I- as an example- be using 2.4.0 to rebuild itself with -CaEABI before trying to go any further? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
Jonas Maebe wrote: On 20 Aug 2010, at 17:47, Mark Morgan Lloyd wrote: Is what I am doing reasonable, or should I- as an example- be using 2.4.0 to rebuild itself with -CaEABI before trying to go any further? It's best to compile 2.4.0 with -dFPC_ARMEL (no need to use -CaEABI) and use the resulting compiler. Thanks Jonas. It's worth noting that the hardware is an NLSU2 "Slug", so uname -a reports Linux ... 2.6.26-2-ixp4xx #1 Mon Jun 21 20:07:59 UTC 2010 armv5tel GNU/Linux I've got some meatier development boards but they came with CE and I've not found how to get Linux onto them yet. If I use 2.2.2 to build an initial 2.4.0 like make 'NOGDB=1' 'OPT=-CfSOFT' all make 'OPT=-CfSOFT' install I get something that can compile an app provided that I still give it -Cf. If I then try to use that to recompile itself with make 'NOGDB=1' 'OPT=-dFPC_ARMEL' all I get /usr/local/bin/ppcarm -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../arm -Fi../unix -Fiarm -FE. -FU/usr/local/src/fpc/fpcbuild-2.4.0/fpcsrc/rtl/units/arm-linux -dFPC_ARMEL -darm -dRELEASE -Us -Sg system.pp thread.inc(332,10) Warning: Function result does not seem to be set thread.inc(344,11) Warning: Function result does not seem to be set thread.inc(354,11) Warning: Function result does not seem to be set thread.inc(359,11) Warning: Function result does not seem to be set thread.inc(364,11) Warning: Function result does not seem to be set thread.inc(393,10) Warning: Function result does not seem to be set thread.inc(412,11) Warning: Function result does not seem to be set thread.inc(436,11) Warning: Function result does not seem to be set thread.inc(442,11) Warning: Function result does not seem to be set thread.inc(483,10) Warning: Function result does not seem to be set /usr/local/src/fpc/fpcbuild-2.4.0/fpcsrc/rtl/units/arm-linux/system.s: Assembler messages: /usr/local/src/fpc/fpcbuild-2.4.0/fpcsrc/rtl/units/arm-linux/system.s:14465: Error: selected processor does not support `rfs r0' .. /usr/local/src/fpc/fpcbuild-2.4.0/fpcsrc/rtl/units/arm-linux/system.s:56074: Error: selected processor does not support `stfd f0,[r5]' system.pp(373) Error: Error while assembling exitcode 1 system.pp(373) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted make[7]: *** [system.ppu] Error 1 make[7]: Leaving directory `/usr/local/src/fpc/fpcbuild-2.4.0/fpcsrc/rtl/linux' What should I be doing here- using both -Cf and -d? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
Henry Vermaak wrote: I've managed to get trunk working on my slug (also on debian lenny) quite a while ago, so I hope it's still possible. I was using trunk to build a cross compiler, though. Thanks Henry. I've definitely had both FPC and Lazarus running natively on ARM in the past, but I suspect it was on Etch and that I ground to a halt when Debian started forcing the EABI transition. I do remember that I had a demo program for a Velleman K8055 interface board working on x86, SPARC and ARM... can't remember whether I ever tried it on PPC since I've only got a system fairly recently. Is my recollection correct that somebody's working on the MIPS port? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
Jonas Maebe wrote: On 20 Aug 2010, at 22:38, Mark Morgan Lloyd wrote: What should I be doing here- using both -Cf and -d? Yes, that should solve the problem. For the resulting EABI compiler, -Cfsoft will be the default. Thanks Jonas, work continues and I'll report back. Is there a way of getting FPC to report its build parameters? For example, if I say fpc -i to 2.4.0 I get .. Supported ABI targets: DEFAULT .. but it doesn't actually say what the default is. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
Henry Vermaak wrote: Is my recollection correct that somebody's working on the MIPS port? I'm sure Florian did some work on that. I have no experience with mips, but I saw that there are some Loongson laptops now. Exciting stuff. I see discussion of it in this list last November, and reference to an fpc-mips project on Sourceforge. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
Jonas Maebe wrote: Supported ABI targets: DEFAULT .. but it doesn't actually say what the default is. To check whether or not you have an ARM EABI compiler, compile any file with -vei and verify that the output contains the line: Target OS: Linux for ARMEL (rather than "Linux for ARM") Thanks Jonas, noted. Build still running- significant memory overcommit. I'll report back when done. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
Jonas Maebe wrote:
On 20 Aug 2010, at 22:38, Mark Morgan Lloyd wrote:
What should I be doing here- using both -Cf and -d?
Yes, that should solve the problem. For the resulting EABI compiler, -Cfsoft
will be the default.
I can confirm that I can build FPC 2.4.0 to run under Debian "Lenny" on
an ARM-based system (Cisco/Linksys NSLU2 "Slug") using
make 'NOGDB=1' 'OPT=-dFPC_ARMEL -CfSOFT' all
This appears to be OK to the extent that it can compile Lazarus
0.9.28.3, although my initial attempt ("make all") bombed but for some
reason "make 'OPT=-vt' all" was OK.
If starting with a binary of 2.2.2 it's necessary first to generate
2.4.0 using 'OPT=-CfSOFT'. Obviously the amount of memory limits
compilation and in particular linkage speed. I've not tried later
versions yet.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
Mark Morgan Lloyd wrote:
I can confirm that I can build FPC 2.4.0 to run under Debian "Lenny" on
an ARM-based system (Cisco/Linksys NSLU2 "Slug") using
make 'NOGDB=1' 'OPT=-dFPC_ARMEL -CfSOFT' all
This appears to be OK to the extent that it can compile Lazarus
0.9.28.3, although my initial attempt ("make all") bombed but for some
reason "make 'OPT=-vt' all" was OK.
If starting with a binary of 2.2.2 it's necessary first to generate
2.4.0 using 'OPT=-CfSOFT'. Obviously the amount of memory limits
compilation and in particular linkage speed. I've not tried later
versions yet.
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.
The output typically looks something like this, although I don't think
it always fails at the same point:
$ make all
make -C lcl all
make[1]: Entering directory `/usr/local/share/lazarus-stable/lcl'
/bin/rm -f units/arm-linux/alllclunits.ppu
/bin/mkdir -p units/arm-linux
/usr/local/bin/ppcarm -gl -Fu. -Funonwin32 -Fuforms -Fuwidgetset
-Fu/usr/local/lib/fpc/2.4.0/units/arm-linux/rtl -Fiinclude -FE.
-FUunits/arm-linux -darm alllclunits.pp
Free Pascal Compiler version 2.4.0 [2010/08/21] for arm
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Linux for ARMEL
Compiling alllclunits.pp
Compiling lclversion.pas
Assembling lclversion
..
Assembling postscriptprinter
Compiling postscriptcanvas.pas
Compiling postscriptunicode.pas
Fatal: Compilation aborted
An unhandled exception occurred at $00033B60 :
EInOutError : File not found
$00033B60
$000F6A30
$0011A744
$000FA588
$000F4F20
$00140A14
$0011FF78
$0013648C
$0013FDA0
$00140950
$0011FF78
$0013648C
$0013FDA0
$00140950
$0011FF78
$00024370
$8304
make[1]: *** [alllclunits.ppu] Error 217
make[1]: Leaving directory `/usr/local/share/lazarus-stable/lcl'
make: *** [lcl] Error 2
This is not immediately reproducible, so I can't simply rerun the
compiler using gdb to get a backtrace. Is there an easy way to make
sense of those numbers?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
Jonas Maebe wrote: 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). I don't at the moment have any spare ARM systems that I could set up and expose for testing. I've got some development boards (effectively, ARM-based PCs) but they came with CE and I'm not paying the manufacturer $500 for Linux... 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). That sounds promising and I'll try it in a few days (once I've got the trial Lazarus compilations out of the way). What should I be doing- updating to trunk? The overall exercise is extending the native testing I did of FPC on various platforms to Lazarus. Granted that not many people are likely to want to run it natively on an ARM target but I think it's still worth knowing whether it can be done. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
Jonas Maebe wrote: I've requested an account on the GCC compile farm (http://gcc.gnu.org/wiki/CompileFarm, anyone contributing to any free software project can do so), and I guess that at least one of their ARM machines will also support OABI binaries. If you don't get anywhere I might be able to help, although I'm not going to pretend that it would be convenient since I'd have to re-flash a Slug which would mean that I could no longer use it as an emergency fallback system. Things would be far easier if there were still such things as ARM-based workstations, i.e. booting from an external device (USB or whatever) rather than internal Flash. The boards I've got are made by iEi, but you get either CE or Linux- not both. I'm hoping to be able to hack OpenFirmware onto a CompactFlash card which would give it much the same interface as Suns and PPC-based Macs. Maybe the easiest is to simply download http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/linux/arm/syscall.inc?revision=16073&pathrev=16073 and replace the rtl/linux/arm/syscall.inc file in the 2.4.0 source tree with that file. There are no FPC version-specific changes to that code. Noted, I'll report back presently. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building and running FPC natively on ARM under Debian "Lenny"
Jonas Maebe wrote: 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). That fix has a definite improvement on the reliability of the compiler. Before applying it I found that I couldn't get 2.4.0 to recompile itself, I had to revert to 2.2.2. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 2.4.2 RC1 available
Marco van de Voort wrote: Hello, We have placed the first release-candidate of the Free Pascal Compiler version 2.4.2 on our ftp-servers. You can help improve the upcoming 2.4.2 release by downloading and testing this release. If you want you can report what you have done here: http://wiki.freepascal.org/Testers_2.4.2 I've not had time to do the tests "by the book" but I can report that RC1 builds using 2.4.0 on armel, PPC, SPARC and x86 (all Debian "Lenny"), and then can build itself. It's able to build Lazarus on SPARC, I've not checked the other platforms yet. The only niggle I've got is that when I tried to build using 2.2 it went part way through and then barfed because of an "out" parameter. Could the compiler version be checked right at the start of the build? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 2.4.2 RC1 available
Mark Morgan Lloyd wrote: The only niggle I've got is that when I tried to build using 2.2 it went part way through and then barfed because of an "out" parameter. Could the compiler version be checked right at the start of the build? Also trying to make -j 12 on a 12-CPU system wasn't reliable. I don't understand the build process well enough to know where to start on that one. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 2.4.2 RC1 available
Jonas Maebe wrote: On 22 Oct 2010, at 16:35, Michael Van Canneyt wrote: On Fri, 22 Oct 2010, Jonas Maebe wrote: The dependencies are specified in the Makefiles themselves. But manually, if I'm correct ? Yes. But what happens if 2 units use each other ? The dependencies are specified at the package level, not at the unit level. A package is either compiled completely sequentially, or completely in parallel (if none of the units depend on others, like with univint package). Please note that I'm not complaining, merely reporting what I've seen. I've not checked yet to what extent the build will recover if restarted, I think I remember a Linux kernel build failing in some cases on large systems but sorting itself out if the make command was rerun. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for Linux-ARM
Felipe Monteiro de Carvalho wrote: On Tue, Nov 30, 2010 at 3:09 PM, Florian Klaempfl wrote: There is no release for arm-linux. Maybe I could create one, or maybe even a simple zip file with a snapshot of FPC 2.5.1 for linux-arm [...] Even if only I use it, I think that a Linux-arm pre-compiled cross-compiler + pre-compiled binutils will already save me some time when I need to change my development computer. But if you're considering making it public wouldn't it be better to use the "official" 2.4.2 release, at least until somebody really had to have a recent fix or extension? I had to go briefly onto 2.5.1 for ARM and found that it refused to compile Lazarus- if I recall correctly there was a conditional in the source where anything that wasn't 2.4 was assumed to be 2.2 or older. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Pascal for scientific computation
A few days ago I came across a Pascal implementation called Pascal-XSC, formerly Pascal-SC. This is a portable compiler oriented towards mathematicians originating at Karlsruhe, it is written in and compiles to C and is now GPLed. It appears to work although I've not exercised it thoroughly. Since I've not seen mention of it in this or related mailing lists I think it worth getting "into the record", without making any judgment as to its value. http://www.rz.uni-karlsruhe.de/~iam/html/language/pxsc.html http://www2.math.uni-wuppertal.de/wrswt/literatur/PXSCENGL.pdf http://www.xsc.de/ -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
Thaddy wrote: On 3-12-2010 13:52, Michael Van Canneyt wrote: As said in my other mail: The behaviour of Input, Output, StdErr is not governed by OS rules, but by the pascal standard. Michael. My understanding has always been that the PASCAL syntax allowed for console IO in a way that encapsulates the console IO features that an OS supports. My understanding is that you are wrong. "For those program parameters that are file variables, the binding is implementation defined." [J&W, 3rd edition, p200]. "The effect of applying the predeclared procedure Reset or Rewrite to either Input or Output is implementation-defined." [ibid, p129]. Note further that J&W does not make provision for binding a file variable to a named file or device, or for a non-blocking keyboard read. Every description of "classical" Pascal that I have seen makes it abundantly clear that Wirth considered that the mapping between INPUT/OUTPUT and whatever physical or logical devices were available was outside his remit. I'd particularly point out that J&W entertains the possibility that they could be mapped to tapes, card readers or any of the other weird and wonderful I/O devices available when the language was defined. So, FPC might attempt to encapsulate the file handling capabilities of current OSes, which are very different from what were available when Wirth designed Pascal. However at that point I'd suggest that you listen attentively to what FPC's developers tell you, rather than expecting them to listen attentively to you. Written as an exasperated non-developer, -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for Linux-ARM
Felipe Monteiro de Carvalho wrote: On Wed, Dec 1, 2010 at 3:00 PM, Mark Morgan Lloyd wrote: But if you're considering making it public wouldn't it be better to use the "official" 2.4.2 release, at least until somebody really had to have a recent fix or extension? I think too that it should be made official. It will also be better when people can use 2.4.2 + this particular patch then if people need to test snapshots which change all the time. I had to go briefly onto 2.5.1 for ARM and found that it refused to compile Lazarus- if I recall correctly there was a conditional in the source where anything that wasn't 2.4 was assumed to be 2.2 or older. You should try again, the latest Lazarus source code should compile with fpc 2.5.1 I will, but since I'm running natively on a system with very limited memory running a complete build takes a week. Lazbuild using 2.4.2 on armel generates working programs. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for Linux-ARM
Marco van de Voort wrote: I will, but since I'm running natively on a system with very limited memory running a complete build takes a week. Lazbuild using 2.4.2 on armel generates working programs. Yesterday I've made a crosscompiling 2.5.1 snapshot that is able to crosscompile binaries with shared libs support to Sheeva (eabi=4) from Windows. I suppose it would work with any armel -Cfsoft -Cparmv5 device. I have not enabled thumb, but I seem to have it (see cpuinfo below) Unfortunately, my sheeva doesn't have X (yet); it's root is on flash. I also uploaded armel cross-binutils windows->arm-linux. (see msg yesterday) I saw that but figured that everybody else would be saying "well done" and I didn't need to comment :-) One thing I would say though is that if you do load X onto a tight system use FluxBox rather than Gnome or KDE, and keep screen size (whether via XDMCP or VNC) small. I've got a problem running lazarus (i.e. as distinct from lazbuild) on SPARC and ARM, if I can pin it down I'll raise it elsewhere. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for Linux-ARM
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: I had to go briefly onto 2.5.1 for ARM and found that it refused to compile Lazarus- if I recall correctly there was a conditional in the source where anything that wasn't 2.4 was assumed to be 2.2 or older. You should try again, the latest Lazarus source code should compile with fpc 2.5.1 I will, but since I'm running natively on a system with very limited memory running a complete build takes a week. Lazbuild using 2.4.2 on armel generates working programs. Yesterday I've made a crosscompiling 2.5.1 snapshot that is able to crosscompile binaries with shared libs support to Sheeva (eabi=4) from Windows. I suppose it would work with any armel -Cfsoft -Cparmv5 device. I have not enabled thumb, but I seem to have it (see cpuinfo below) Unfortunately, my sheeva doesn't have X (yet); it's root is on flash. I also uploaded armel cross-binutils windows->arm-linux. (see msg yesterday) I'm currently rereading the Build FAQ- slowly and carefully. Is it still the case that native CE is under-exercised? I've got a board here- basically an ARM-based PC- that I could fire up and use for testing. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for Linux-ARM
Felipe Monteiro de Carvalho wrote: On Mon, Dec 6, 2010 at 10:22 AM, Mark Morgan Lloyd wrote: I'm currently rereading the Build FAQ- slowly and carefully. Is it still the case that native CE is under-exercised? What do you mean by "native CE"? Running the compiler etc. on CE, rather than cross-compiling. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for Linux-ARM
Henry Vermaak wrote: On 06/12/10 09:33, Mark Morgan Lloyd wrote: Felipe Monteiro de Carvalho wrote: On Mon, Dec 6, 2010 at 10:22 AM, Mark Morgan Lloyd wrote: I'm currently rereading the Build FAQ- slowly and carefully. Is it still the case that native CE is under-exercised? What do you mean by "native CE"? Running the compiler etc. on CE, rather than cross-compiling. Just interested, how would you do this? Does win ce have an ssh server? Unless I'm badly missing the point: these boards have full video etc. so can run programs in exactly the way that "real" computers do. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for Linux-ARM
Felipe Monteiro de Carvalho wrote: On Mon, Dec 6, 2010 at 10:22 AM, Mark Morgan Lloyd wrote: I'm currently rereading the Build FAQ- slowly and carefully. Is it still the case that native CE is under-exercised? I've got a board here- basically an ARM-based PC- that I could fire up and use for testing. Any exercising for ARM and Windows CE would be good. Specially if you can run the compiler tests. I'll get onto it, but it will be fairly slow work- I'm interleaving a lot of stuff here. I notice somebody's done a SPARC/Solaris binary, I already want to get Solaris v8 running to evaluate a Sun board that's only supported by that OS, and I might get v10 going as well- I've got hardware. I don't have x64 but I assume that it's already getting quite a lot of attention, and I don't have MIPS. I noticed mention of IBM's zSeries in the wiki so I've fleshed out the ZSeries page with some info I had to hand, I reckon that just leaves Itanic as far as "computers" (i.e. as distinct from embedded targets) go. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for Linux-ARM
Henry Vermaak wrote: On 6 December 2010 10:05, Mark Morgan Lloyd wrote: Henry Vermaak wrote: Just interested, how would you do this? Does win ce have an ssh server? Unless I'm badly missing the point: these boards have full video etc. so can run programs in exactly the way that "real" computers do. Oh, right. The devices I've used in the past had no keyboard and a small screen, so this would've been hard. I've got 4x boards here that are basically ARM-based PCs, even booting from an fdisked CompactFlash. Trouble is that they've only got CE on them, and the manufacturer quoted something outrageous to "upgrade them to Linux firmware"- which in practice I suspect only means replacing the CF. One of my forthcoming activities is to disassemble the CF boot sector and try to boot something like OpenFirmware, i.e. make the board look very much like the Sun and Mac systems I've got. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux Signals
Andrew Brunner wrote: I'm trying to get signals to work with sockets under x64 Ubuntu 10.10 (all updates) I installed two handlers for two events SIGIO, and SIGHUP uising fpsigaction(SIGIO, @saAct, nil) . I was expecting to get a byte by byte signal under telnet to my server instance (110-pop3) on the IO but had only received the signal on CRLF. Firefox on the HTTP has the same problem but I suspect a problem since it is impossible to ever receive a signal for binary protocols having no CRLFs for as kernel triggers to signal applications. Perhaps this particular issue is better directed at Debian? I am neither a kernel hacker nor a network guru, but would a signal be raised when a byte was read or when a TCP packet- possibly comprising aggregated bytes- was transferred? I think you'd be better not using a standard telnet client for this but instead using Netcat (nc) or netpipes (faucet and hose) which will not, certainly by default, be fiddling with line-ends or aggregating bytes for efficiency. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for Linux-ARM
Felipe Monteiro de Carvalho wrote: Compiling javalang.pas Assembling javalang javalang.pas(46) Error: Assembler /home/felipe/Programas/fpctrunk/binutils/as not found, switching to external assembling javalang.pas(46) Fatal: There were 1 errors compiling module, stopping The strange thing is that /home/felipe/Programas/fpctrunk/binutils/as works normally (it is a copy of arm-linux-as), I just checked o.O Have you checked with the -vt option to see what the compiler is trying to load? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for Linux-ARM
Felipe Monteiro de Carvalho wrote: On Tue, Jan 18, 2011 at 12:44 PM, Mark Morgan Lloyd wrote: Have you checked with the -vt option to see what the compiler is trying to load? Thanks, indeed, it seams that something changed in the code to search for the binutils and I had to update my .fpc.cfg, thanks. For what it's worth, I now use -vt as standard and it turned out to be particularly useful last week when I was fiddling with Solaris since in some cases there are /three/ copies of some utilities: Sun, Berkeley and GNU. However I usually filter the output through a Perl script, this discards excessive "noise" and ends up saving the compilation command plus a full cross-reference of what was found where. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Interrupt vector table generation
Jeppe Johansen wrote: As I wrote a while back, I would like to make it easier to handle interrupts when using fpc for embedded work The current solution is to use procedure variables with indirect jumps in inline assembler. While that works okay it takes up a lot of space on devices with lots of interrupts, and introduces unnecessary interrupt latencies An idea would be to use weak linking, and while it's possible in external assembler, a nicer solution would be to handle it in procedure directives. That would mean addition of some functionality that is generally unportable and ambiguous across platforms. So I've moved away from this idea for now A better idea, I think, is to use the old interrupt procedure directive. For some embedded platforms simply allow also specifying a interrupt vector/index after the interrupt keyword. Ex: procedure USARTRxInterrupt; interrupt 10; begin // Handler code end; And from that automatically generate an interrupt vector table in the compiler when compiling a program. Those tables of course look different for each targetted architecture, but usually they are either tables of branch instructions or addresses. For embedded work you'll specify the controllertype anyway, and that way know how large the table is, and what kind of vector to use Further, a future benefit of using the interrupt keyword could be generation of procedure exit code. Some platforms need a special "return from exception/interrupt" instructions at the end of interrupt handlers I'm not sure that this belongs in a core language, because (a) the whole concept of interrupts is non-portable, (b) the precise point at which the vector (or equivalent) is installed is determined by the logic of the program, and (c) it says nothing about disabling interrupts while the vector is updated or what to do with the interrupt controller afterwards. Being able to mark a procedure as preserving all registers is highly useful, and saves a lot of messing with assembler. What I've done in the past (on x86 protected mode) was to build the final binary as an NE-format .exe with entry points exported by name, then use a final builder/binder stage (loosely patterned after Intel's) that set up all vectors etc. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FPC for minimal Win-32
I'm currently looking at the potential of a minimal Win32-compatible OS called Sanos, which supposedly implements a useful subset of the Windows console-mode API. As a starting point, I'm using the standard Windows variant of the FPC compiler, but if I build a minimal program (i.e. program test0; begin end.) the executable requires the oleaut32 DLL which is not implemented. Is there an easy way to break this requirement, or do I need to hack and rebuild FPC? If the latter is feasible, could somebody give me a hint where to start? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for minimal Win-32
Sven Barth wrote: On 24.03.2011 21:38, José Mejuto wrote: Hello FPC, Thursday, March 24, 2011, 9:10:10 PM, you wrote: SB> You don't need to rebuild FPC itself, but you need to modify the RTL. SB> Three functions from oleaut32 are included for Windows compatible SB> widestring management. As FPC has a fallback mechanism you can disable that. Or simply create a dummy "oleaut32.dll" which exports the same functions prototypes without doing nothing (empty functions) and drop that DLL in the same folder as the exe. But then you must not use FPC for that DLL as the oleaut32 functions are used in DLLs as well. Ouch :-) Also if you follow this approach it might be safer to stay far away from any function that takes a WideString (UnicodeString might work though). Also since I'm tinkering with an OS of unknown completeness I think I'd rather steer clear of extra DLLs to start with. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for Sanos (a minimal Win-32)
Pierre Free Pascal wrote: I looked a little on the API declared by Sanos and I think that it would probably be easier to use our Unix targets to get a reasonable support for this OS rather than trying to use the Win32 subset. The C API seems to be far more extended than the small Win32 emulation layer. Otherwise you will really need to strip the RTL down a lot: Do not rely on exported function in DLL's looking into sources, you will discover that lots are only pseudo implementations doing nothing. See for instance SetConsoleCtrlHandler implementation in: http://www.jbox.dk/sanos/source/win32/kernel32/kernel32.c.html SetConsoleCtrlHandler is the central function used inside Windows RTL to support exceptions on that target... Using signals.pp unit might help for this particular problem as thread specific exceptions with thread information block seems to be supported (but I didn't test it). I'm tinkering with it at present. If I can get it to the point where an empty program "runs" then I'll be happy for the moment, if it runs a Hello World which also runs on Windows then I'll consider it time well spent. I don't intend to put much effort into this since I don't know whether Sanos really is useful for anything, but I think it has potential as an upgrade for DOS+Go32. After all, if somebody wants a unix-style OS there's plenty of cut-down Linuxes. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for minimal Win-32
Sven Barth wrote: Am 25.03.2011 13:10, schrieb José Mejuto: Hello FPC, Thursday, March 24, 2011, 10:19:09 PM, you wrote: Or simply create a dummy "oleaut32.dll" which exports the same functions prototypes without doing nothing (empty functions) and drop that DLL in the same folder as the exe. SB> But then you must not use FPC for that DLL as the oleaut32 functions are SB> used in DLLs as well. Instead modify RTL to not import that functions, provide a simple empty stub in a "local" DLL to keep the dll loader happy and disable unicode. Maybe I'm dropping something in the path and this approach is not good. SB> Also if you follow this approach it might be safer to stay far away from SB> any function that takes a WideString (UnicodeString might work though). The worst thing could be a "no answer" function, or implement a very basic non complian unicode operations (I had not checked what oleaut32.dll functions perform). As the RTL can be switched to "don't use those functions", as I've described, the impact should be low. Note: You do that switch in your main program as well as the variable/constant is available in the implementation section of the system unit (maybe you need to enable "writable typed constants"). Then a stub would be sufficient. Your earlier source hack works fine for excluding the oleaut32 stuff, I'd somehow got the idea that was being pulled in by MinGW so hadn't gone looking in system.pp. With the patched runtimes available on a pukka Win-32 system, compilation needs -WR before a program will even start loading on Sanos- this was expected from the documentation. There are a couple of user32 calls (CharLowerBuffW and CharUpperBuffW) which presumably could be replaced in system.pp- they're in the same place as the function which was giving me problems with NT4. More significantly, there are a whole lot of unresolved kernel32 entry points- I can't even get a full list at the moment since I can't login to Sanos's telnetd and there's more than a screenful, but they include things like GetStartupInfoA, LocalAlloc, LocalFree and so on and whilst I've not gone hunting yet I suspect that they're fundamental to the RTL's operation. So I might tinker a bit more, but it's definitely not going to be trivial. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Announcement: Free Pascal Compiler Delphi XE PortProject
Matt Emson wrote: On 11/04/2011 12:49, Felipe Monteiro de Carvalho wrote: On Sun, Apr 10, 2011 at 4:46 PM, Skybuck Flying wrote: This project is about "porting" the Free Pascal Compiler to Delphi XE. I am curious: What is the use for this? This is what Mr Flying does - pops up, attempts to do something without really any good reason. He's not been on an FPC list in a while though. I remember when he was trying to reverse engineer 64bit exe files in.. wow.. 2007? He says a lot, listens a little and generates lots of content with little or no sense. He has been accused of trolling before, but the jury is out on this one... Let's judge him by results. However, I must admit that I'm asking "why" as well: why would one want to recompile a portable free compiler with a non-portable non-free one? Now if he'd instead devised a way of bootstrapping FPC using GCC I think that everybody would be unreservedly enthusiastic. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Announcement: Free Pascal Compiler Delphi XE PortProject
Skybuck Flying wrote: The source code compiles, however little sections of code have been disabled as follows: // *** Skybuck: Fix Needed *** These sections are slight free pascal language incompatibilities with Delphi and need to be fixed... There are about 700 of them. (Many duplicates here and there though). Are you saying that you have identified these and inserted about 700 comments or conditional-compilation directives manually? That's a respectable amount of work... -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Announcement: Free Pascal Compiler Delphi XEPortProject
Hans-Peter Diettrich wrote: Skybuck Flying schrieb: Anyway if somebody could take a look at all of this and make some sense of it that would be great/nice, saves me some time and could clear some confusion (?) ;) Before looking at your code, I'd know the role that your project plays at all. Is it only about making the FPC code compilable by Delphi, as the first stage in the FPC bootstrap? In this case it would be easier to use an older Delphi commandline compiler, from the time before the Ansi-To-Unicode move, or simply an legacy FPC. You also could try to make the FPC sources compile by gcc - but I'd delay any such attempts to the time, when there doesn't exist any immediately applicable compiler any more. I think that's very wise advice. I'd also throw in that there's a few things in the compiler etc. that I'm interested in looking at, but that I'm trying to build up a sound base of experience actually /using/ it first. The community has put up with me for six years or so, I still consider myself an inexperienced beginner, and I'd be very reluctant to make any suggestion that the developers had overlooked something significant. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] __LINE__ and __FILE__ macros
Joerg Schuelke wrote:
Am Thu, 28 Apr 2011 20:09:59 +0200
schrieb Joerg Schuelke :
No further explanation needed. Nested comments do it.
I did not know that {$define mx:= ... (*$%LINE%*)} works.
So that's why (*$define mx:= ... doesn't work :-)
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closing bug reports or not ?
Jonas Maebe wrote: On 09 May 2011, at 09:20, LacaK wrote: Closing bug report is task for reporter of bug or is not (so leave it resolved and bug will close somebody later?) ? It's best if the bug reporter closes it once he's verified that the bug has been fixed. Many people don't do that (maybe we should start asking reporters to do that, like the Lazarus team), so in that case we have to do it. Is there a polite way for a reporter who's submitted a fix to ping management when the bug's not been assigned to anybody? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closing bug reports or not ?
Jonas Maebe wrote: On 09 May 2011, at 12:54, Mark Morgan Lloyd wrote: Is there a polite way for a reporter who's submitted a fix to ping management when the bug's not been assigned to anybody? You can always ask about it here, or add a "ping" comment to the bug (the latter will put it back at the top of the list of unassigned bugs). That was intended as a general question more than anything else, but if somebody could pick up my modified serial.pp at 0018946 it would be appreciated. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] MIPS
Felipe and Michael have pointed out to me that David Zhang's mipsel port has been integrated into trunk. Before I start trying to build it, could anybody comment on how complete an implementation it is? Apart from that I can confirm that David's code on Sourceforge is good enough for trivial programs that run on a recent Linux hosted by Qemu. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Michael Schnell wrote: There even is a Linux for PIC32 http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2519¶m=en546018 No idea if this is really useful ? Although despite my enthusiasm for Linux, for hardware like that I find myself asking /why/. I think there's a fairly clear demarcation between projects/products which really do need a multitasking OS with networking etc., and those that quite simply need to fiddle a few inputs and outputs. The real problem is memory size: I remember a development job a few years ago that was basically well-specified and well-planned, but by the time the multitude of UI screens had been roughed out it was painfully obvious that it wouldn't fit in the targeted board's address space. Then it turned out that the compiler supported paging but that the linker offset the tables by one entry: I managed to fix the binaries but we /still/ ran out of space. That experience is, in part, why these days I am more interested in native than cross compilation. If you can get the basic functionality of a project running on a "real" computer to the point where you can gauge its performance and requirements, you're then in a far stronger position to specify the target hardware. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Mark Morgan Lloyd wrote: Felipe and Michael have pointed out to me that David Zhang's mipsel port has been integrated into trunk. Before I start trying to build it, could anybody comment on how complete an implementation it is? Apart from that I can confirm that David's code on Sourceforge is good enough for trivial programs that run on a recent Linux hosted by Qemu. This is where I think we're at. * The compiler compiles to one that runs on x86 and generates mipsel. * In the rtl, prt0.as assembles after a couple of fixes. * In the rtl, dllprt0.as is missing but I notice that on SPARC and several others it is empty. I've tentatively created an empty file. * In the rtl, cprt0.as is missing and I notice that on other targets it is not empty. Same applies to gprt0.as. Ongoing notes at http://wiki.lazarus.freepascal.org/Native_MIPS_Systems#Mainline_MIPS_Port -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Jonas Maebe wrote: On 31 May 2011, at 11:41, Mark Morgan Lloyd wrote: * In the rtl, dllprt0.as is missing but I notice that on SPARC and several others it is empty. I've tentatively created an empty file. The contents of this file have to be implemented to compile dynamic libraries. * In the rtl, cprt0.as is missing and I notice that on other targets it is not empty. This one is required to compile programs that link to the C library. Same applies to gprt0.as. And this one is required to compile programs with -pg (gprof support) Thanks, so for the moment they can be dummies? I think I could fill them in if necessary by referring to other platforms, but I'd rather get the hang of the calling conventions etc. first. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Central reference for ABI, opcodes etc.
Is there e.g. a page on the wiki with links to relevant ABI documents etc. for supported CPUs? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Mark Morgan Lloyd wrote: Mark Morgan Lloyd wrote: Felipe and Michael have pointed out to me that David Zhang's mipsel port has been integrated into trunk. Before I start trying to build it, could anybody comment on how complete an implementation it is? Apart from that I can confirm that David's code on Sourceforge is good enough for trivial programs that run on a recent Linux hosted by Qemu. Current situation is that after ensuring the existence of dummy files I've stepped back from the RTL code and am looking at a problem that appears to be caused by floating point initialisation in the cross compiler. http://wiki.lazarus.freepascal.org/Native_MIPS_Systems#Stall_point As usual, all hints appreciated :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New language idea: Unified types (assignment size-compatible types).
Paul Dunn wrote: On Sun, Jun 19, 2011 at 1:15 AM, Skybuck Flying wrote: Here is a new language idea which would make Delphi a bit more friendly: Do the Embarcadero developers read this list? First the problem: pointers and longwords are not assignment compatible. This is pretty much bullshit because they are the same size. Unfortunately pointers are not the same size as longwords on some architectures - on x64, they're twice the size. The size is irrelevant. Pointers and numeric types have different sets of applicable operators, in the same way as bitsets and numeric types have different operators. You can add two numbers and get a meaningful result, you can't add two pointers or bitsets. There's a fairly old book on linkers and loaders which uses the analogy that pointers are like vectors and integer types like scalars, and then explores the various combinations of operators etc. Whether it would be desirable to have some construct that allowed assignment without a warning is, of course, a different matter. But at that point, in the general case, one has to consider that different architectures assume different pointer behavior, such as the normalised pointers assumed by Turbo Pascal- with which FPC still has some interest in being compatible. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Mark Morgan Lloyd wrote: Mark Morgan Lloyd wrote: Mark Morgan Lloyd wrote: Felipe and Michael have pointed out to me that David Zhang's mipsel port has been integrated into trunk. Before I start trying to build it, could anybody comment on how complete an implementation it is? Apart from that I can confirm that David's code on Sourceforge is good enough for trivial programs that run on a recent Linux hosted by Qemu. Current situation is that after ensuring the existence of dummy files I've stepped back from the RTL code and am looking at a problem that appears to be caused by floating point initialisation in the cross compiler. A define incorrectly suggested that MIPS was using MM registers. Now back following missing files/symlinks in the RTL. http://wiki.lazarus.freepascal.org/Native_MIPS_Systems#Stall_point I hope to have an SGI machine in a few days, provided that it works (it's been stored in a garage) I might be able to look at mips as well as mipsel. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: Current situation is that after ensuring the existence of dummy files I've stepped back from the RTL code and am looking at a problem that appears to be caused by floating point initialisation in the cross compiler. A define incorrectly suggested that MIPS was using MM registers. Now back following missing files/symlinks in the RTL. http://wiki.lazarus.freepascal.org/Native_MIPS_Systems#Stall_point wrt the missing of STAT.inc, IIRC the stat record definition on linux was found to be slightly architecture dependant (x86 being a bit different due to legacy reasons, of both FPC and Linux). Probably the wisest is to take the PPC one and check it quickly against the header. Thanks, I'm already using ppc for comparison purposes which is why I had a hard time finding the MM issue :-) Question if I may: should I be avoiding symlinks as non-portable? I'm gradually hacking through with a mixture of command-line compilation and using Lazarus to step through. I considered looking at FPP to see if I could log all procedure calls, I thought I was looking for something that hadn't been initialised properly. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Pierre Free Pascal wrote:
I had a MIS related question:
using fullcycle I got a warinng about
defdynlinker not being initialized fro mips in systems/t_linux.pas unit.
Is this a correct fix,
Index: t_linux.pas
===
--- t_linux.pas (révision 17859)
+++ t_linux.pas (copie de travail)
@@ -192,6 +192,9 @@
{$endif FPC_ARMEL}
{$endif arm}
+{$ifdef mips}
+ defdynlinker:='/lib/ld-linux.so';
+{$endif mips}
{
Search order:
glibc 2.1+
or can somoeone tell us what the default linker is for a mips linux
machine?
I can't say at this point. I'm working through step-by-step starting
with a cross compiler, i.e. I'm a long way from having a full build.
/If/ I get to the point of a full build then hopefully somebody will
review my work and consider merging it with trunk. Until then I'm
working with a local copy, but the issues I find are noted on the wiki page.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Marco van de Voort wrote: Question if I may: should I be avoiding symlinks as non-portable? For anything that should go back into SVN: no symlinks (*). (and in general, even without SVN concerns, I don't think heavy symlinking is a good concept in sources. This would cause only problems because sb might modify it for ppc, and not notice mips also linked to the file) (*)http://subversion.apache.org/faq.html#symlinks Thanks, noted. Obviously while I've just got a local copy on my system I can easily locate symlinks, SVN is very much in the future since I've got limited confidence in my work so far. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: fpc build problems on some debian armel buildds
Riku Voipio wrote: 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: -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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Felipe Monteiro de Carvalho wrote:
On Thu, Jun 30, 2011 at 6:01 PM, Mark Morgan Lloyd
wrote:
or can somoeone tell us what the default linker is for a mips linux
machine?
I can't say at this point. I'm working through step-by-step starting with a
cross compiler, i.e. I'm a long way from having a full build.
To answer his question you only need to issue the following command in
your MIPS emulator running Linux:
which ld
This should tell you where the linker is
I think his is a loader issue- the binary needs to know what .so to pull
in that later allows it to work out paths etc.
> +{$ifdef mips}
> + defdynlinker:='/lib/ld-linux.so';
> +{$endif mips}
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Felipe Monteiro de Carvalho wrote:
On Thu, Jun 30, 2011 at 7:05 PM, Mark Morgan Lloyd
wrote:
I think his is a loader issue- the binary needs to know what .so to pull in
that later allows it to work out paths etc.
ops, it seams that you are right =O
I only spotted it when I started wondering whether 'which' was going to
be any use in a cross-development environment such as I think one has to
start with in this case.
I presume the answer to the original question is "use the one on the
system you're working on". In other words, if building a cross compiler
to run on i386 assume /lib/ld-linux.so.2; the {$ifdef mips} will only
come into play when building to run natively.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
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
peter green wrote: 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? Google suggests that it's a known issue [1], and that the degree of warning etc. may be controlled using /proc/cpu/alignment [2] 1] http://qemu-forum.ipi.fi/viewtopic.php?f=20&t=5543 2] http://lecs.cs.ucla.edu/wiki/index.php/XScale_alignment#Have_the_kernel_find_the_problem_for_you -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Pierre Free Pascal wrote:
I had a MIS related question:
using fullcycle I got a warinng about
defdynlinker not being initialized fro mips in systems/t_linux.pas unit.
Is this a correct fix,
Index: t_linux.pas
===
--- t_linux.pas (révision 17859)
+++ t_linux.pas (copie de travail)
@@ -192,6 +192,9 @@
{$endif FPC_ARMEL}
{$endif arm}
+{$ifdef mips}
+ defdynlinker:='/lib/ld-linux.so';
+{$endif mips}
{
Search order:
glibc 2.1+
or can somoeone tell us what the default linker is for a mips linux
machine?
Pierre Muller
On Debian "Squeeze" mipsel (using Marco's suggestion):
$ ldd `which gcc`
libc.so.6 => /lib/libc.so.6 (0x2aab)
/lib/ld.so.1 (0x)
$ ls -l /lib/ld.so.1
lrwxrwxrwx 1 root root 12 May 13 11:32 /lib/ld.so.1 -> ld-2.11.2.so
I don't know whether the symlink is resolved during linkage or at load
time. I've certainly found a case on Solaris where the former applied
for system libraries.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SMP > 2 core Cache issue with Posix threads
Michael Schnell wrote: In another topic (now closed) Andrew described that a code similar to HansPeter's example did run correctly on a dual core machine, but produced errors on a machine with more cores. I've not been reading every message. Definitive URL? OTOH if some synchronization ensures that the appropriate code sequences that sets it has been executed, IMHO, Posix compatibility of the infrastructure (compiler, libraries, OS, Hardware) ensures that another thread in fact gets that correct value of that variable (i.e. SMP Cache synchronization after the synchronization is granted). So the really big question is whether any given computer has a robust SMP implementation, or if in actual fact it's some species of NUMA with unreliable cache coherency. It might also be necessary to distinguish between SMP, multicore and hyperthreading. (It it fails only on Andrew's machine, my suggestion is a hardware problem.) Who has a >2 Core machine to test and debug this ? Biggest x86 system I've got here is a Compaq with 2x Xeons which I think are 2x multicore rather than HT. More interestingly I've got a 12-way SMP Sun, and they've been in this game for a while. Linux-only in both cases. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Marc Weustink wrote: Mark Morgan Lloyd wrote: I hope to have an SGI machine in a few days, provided that it works (it's been stored in a garage) I might be able to look at mips as well as mipsel. If the SGI doesn't work, I;ll try to startup mine and give you remote access to it. (I got it in a runnable state, but never had the time to power it up at my home) :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] SMP > 2 core Cache issue with Posix threads
Vincent Snijders wrote: 2011/7/1 Michael Schnell : On 07/01/2011 02:00 PM, Vincent Snijders wrote: I won't call that a definitive URL, but some vague indication. That is more than 200 mails at least. I'd expected you to give a link to the email in the archives where "Andrew described a code". So, which link to click on http://lists.freepascal.org/lists/fpc-devel/2011-June/subject.html or which link to click on http://lists.lazarus.freepascal.org/pipermail/lazarus/2011-June/subject.html ? I have no idea how to find a certain mail in the backlog. So how you expect us to find the description *you* want us to read in all those mails, if even you cannot find it. But it would not help anyway, as AFAIR, no additional information can be found there. Oh, it was just another piece of useless information... Fair play, he /has/ said he's mailed Andrew looking for source. However under the circumstances we've got to have something definitive to inspect and test- I for one would be very unhappy if I spent my time running up a rarely-used system and updating its compiler, only to be told that I didn't have the right version of the test program. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Missing library
Miklos Cserzo wrote: Hi Folks, fpc 2.4.2 gives the following error on SuSE 11.4. What is the name of the missing package? "fp: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory" Since nobody else has answered: Google suggests that this is part of ncurses, previous discussion has been inconclusive as to whether this is an FPC or a SuSE problem. I've never seen it on Debian or Slackware, which suggests the latter. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Sparc < v9
Ludo Brands wrote: membar and stbar are instructions available as of sparc v9. To get fpc running on a sparc command line option that does the same? I wonder whether this would be worth considering on a per-OS basis? Working from memory, when I last looked I think that Linux initialised the processor to a mode where it didn't reorder memory accesses so (if my recollection of the documentation is correct) didn't require membars, in which case an RTL startup check for an unexpected mode should suffice. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Sparc < v9
Ludo Brands wrote: membar and stbar are instructions available as of sparc v9. To get fpc running on a sparc For completeness and playing Devil's Advocate, I do have to ask whether pre-v9 (i.e. pre-UltraSPARC) systems are relevant any more. I've got one remaining Sun4m system (SPARCstation 20) here which will just about run Linux 2.4, not sure it will handle anything later. I've also got several Sun4d which I've managed to get running SMP 2.4 but not 2.6. Both of those will also run Solaris 8 but I don't think later. I've got a Sun4c (SPARCstation IPC) which I can't get to run a realistic (>=2.4) version of Linux, and won't run later than Solaris 7. I must admit that I'm very attached to the Sun4d, because it performs spectacularly and is a Xerox PARC design. But I'd certainly not expect it to run an off-the-shelf FPC. The remaining question is whether there's any mileage in supporting the Gaisler Research LEON processor, which I believe is a v8. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Sparc < v9
Ludo Brands wrote: For completeness and playing Devil's Advocate, I do have to ask whether pre-v9 (i.e. pre-UltraSPARC) systems are relevant any more. QEMU emulates V8. That's why I had to "downgrade". That seems an entirely adequate reason, since I believe a lot of developers use Qemu. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MySQL 5.1 and Double (trouble)
Andrew Brunner wrote: Can someone check the status of update if the bind parameter for double decimal values? I'm getting unexpected rounding errors after updating - the data in the column looks different than what was specified during the update statement. Value: double; Query.Params.ParamByName(sName).AsFloat:=Value; 1.) Update Value : 40734.825668912039 2.) Actual Value after update : 40734.8256689120 3.) Actual Value on read :40734.825668912003 Does MySQL come with an "official" program that you can use to run queries manually? What happens when you use it to store and retrieve that number? I think that SQL specifies that a double has 53 bits in the mantissa which is a bit better than 15 digits which is about what you're seeing. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Getting fpc to work on Solaris (11)
Joost van der Sluis wrote: Hi all, I'm trying to set-up a VM with Solaris (x86_64). Problem is that fpc refuses to link applications. It complains that there is a syntax error in the build-in linker scripts. How that's possible, I don't know. When I use -T, so that the default linker scripts are not used, linking goes well, but the application terminates immediately: 'Bad entry point'. That's probably because the link.res link-script is missing too much info to be used without the default linker-scripts. Does this ring a bell to anyone? And maybe someone know where I can find the default-linker scripts? Which version of the compiler? I didn't see this on SPARC but I think the first thing I'd check would be which linker (ld) was actually being used- I had to do a lot of tweaking to get paths right. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Getting fpc to work on Solaris (11)
Joost van der Sluis wrote: On Mon, 2011-07-11 at 18:29 +0200, Ludo Brands wrote: If you add --verbose it'll print out the internal ld script. See what line 21 corresponds with. I've attached the internal script for the gnu ld 2.21.1 on Solaris 10. Try /usr/bin/gld -s -L. -o test -T ld_internal_script link.res At first it did not work. I've edited the file, changed the output-format in the script from 'elf32-i386-sol2' to 'elf32-i386' and now it works. I'll use this script for now, thanks for the help. But I still wonder why it doesn't work by default... Can't find any reference to a -sol2 suffix even looking at (SPARC) Solaris 8. For that matter I can't find it in the FPC sources, except very obtusely referring to a version of gcc. Has install put something suspect in fpc.cfg? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : [fpc-devel] Getting fpc to work on Solaris (11)
Ludo Brands wrote:
Can't find any reference to a -sol2 suffix even looking at (SPARC)
Solaris 8. For that matter I can't find it in the FPC sources, except
very obtusely referring to a version of gcc. Has install put
something
suspect in fpc.cfg?
This is pure ld. Nothing to do with fpc. When ld is built for a platform it
contains an internal script with basic build information (type of binary
file to create, etc.) for that particular platform. This way the user can
easily build the same software on different platforms without being bothered
with platform specific settings. For Solaris 11 there seems to be a gnu ld
around with wrong/corrupt internal scripts. The one I sent to Joost was the
output I got on solaris 10 from a ld --verbose. If you try this command on
your sparc machine, you'll probably see a lot of differences because of the
different cpu.
If I understand you correctly, on SPARC Solaris 10 I see
GNU ld version 2.15
Supported emulations:
elf32_sparc
elf64_sparc
using internal linker script:
==
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT("elf32-sparc", "elf32-sparc",
"elf32-sparc")
OUTPUT_ARCH(sparc)
One thing I don't understand is whether there's any scope for the
computer type that's optionally fed to binutils's ./configure to appear
in the final programs (ld for Solaris etc.). I definitely see references
to sol2 as the final part of this parameter in config.sub which I
believe is used to check and parse the type, where it's used to specify
that the OS is -solaris2 rather than -sysv etc.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : RE : [fpc-devel] Getting fpc to work on Solaris (11)
Ludo Brands wrote: One thing I don't understand is whether there's any scope for the computer type that's optionally fed to binutils's ./configure to appear in the final programs (ld for Solaris etc.). I definitely see references to sol2 as the final part of this parameter in config.sub which I believe is used to check and parse the type, where it's used to specify that the OS is -solaris2 rather than -sysv etc. That is how cross binutils are made. On system x you do a configure --prefix=dir-to-put-tools --host=the-host --target=the-target The config.guess script is used by configure when you don't specify a target. More usefull info here: http://wiki.osdev.org/OS_Specific_Toolchain Yes, but you can also do e.g. $ ./configure --prefix=/usr/local/mipsel-linux mipsel-linux-gnu and what I was wondering was whether the final portion of the parameter could, in some cases, "leak" into the binaries e.g. into ld's embedded script, resulting in the sort of problem that Joost reported: >>>>> At first it did not work. I've edited the file, changed the >>>>> output-format in the script from 'elf32-i386-sol2' to 'elf32-i386' >>>>> and now it works. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] Gnu ld on Solaris
Ludo Brands wrote: FPC (in svn trunk) already supports using the native Solaris ld by using the -Xn parameter. It doesn't appear to be documented yet though. 2.4.4 works also with -Xn Thanks for that Ludo, I'm currently trying to get all systems here onto 2.4.4 as the stable version before going any further. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : RE : RE : [fpc-devel] Running programs with output redirection
Ludo Brands wrote:
This is all windows though.
Cross platform solution:
Uses process
...
p:=TProcess.Create(nil);
{$IFDEF WIN32}
p.CommandLine := 'cmd /c diff -r dir1 dir2 > diff.txt';
{$ENDIF}
{$IFDEF LINUX}
p.CommandLine := 'bash -c "diff -r dir1 dir2 > diff.txt"';
{$ENDIF}
p.Execute;
Might be safer to refer to sh rather than bash in this context, since
Debian and Ubuntu are moving from Bash to Dash with sh being an
appropriate symlink.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Marc Weustink wrote: Mark Morgan Lloyd wrote: I hope to have an SGI machine in a few days, provided that it works (it's been stored in a garage) I might be able to look at mips as well as mipsel. If the SGI doesn't work, I;ll try to startup mine and give you remote access to it. (I got it in a runnable state, but never had the time to power it up at my home) It turned out to be a radio ham's garage, rather than the garden variety. FPC for IRIX, anybody? :-) I hope everybody appreciates that that was a poor attempt at a joke. MIPS (or rather, I think, mipsel) seems to be getting a bit of attention due to Tilera's efforts, SGI appears to be involved but I think that they're using the chips as coprocessors rather than reconstituting their classic MIPS-based supercomputers as "systems on a chip". -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Including Sorokin's TRegExpr in FPC
Felipe Monteiro de Carvalho wrote: Hello, I was porting a Delphi project and I needed support for TRegExpr. Well, it seams that FPC doesn't already come with one, but it has a Regexpr unit, but it's docs are not very positive about how complete this library is: http://wiki.lazarus.freepascal.org/Regexpr But I asked Sorokin if he could relicense TRegExpr from RegExpStudio in the same modifyed LGPL as the FPC RTL and FCL and he agreed! So, what do you think about adding this unit to FPC: http://openpokergrid.svn.sourceforge.net/viewvc/openpokergrid/Components/regexpr/RegExpr.pas?revision=202&view=markup The only issue is that it has a name colision with an already existing unit in FPC. Hopefully now people won't say anymore that FPC does not have a good regular expression support =) I tested this unit in Linux and it worked fine for my project. I've been using that in Windows for years and it appears stable, although I've not necessarily been tracking updates. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
Hans-Peter Diettrich wrote: IMO CodeGear stumbled with Delphi.NET over the same stone as with Kylix: the Win32 centric VCL :-( I don't think that the VCL was the issue with Kylix. The issues were (a) uncertainty over the Linux community's acceptance of a non-free development environment and (b) the difficulty of having a binary release which was guaranteed to install on any distro or version. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
Jonas Maebe wrote: On 07 Aug 2011, at 20:53, Jonas Maebe wrote: They only have to share them with their customers who get the binary (and even then only for nominal shipping and handling fees). Of course, those customers are then free to pass them along further, if they want to. And in practice, I can't imagine what advantage Embarcadero would have by not immediately publicly sharing any such changes rather than by going through such hoops. From the horse's mouth: https://forums.embarcadero.com/message.jspa?messageID=379331#379331 "If there are any changes or fixes we would contribute them, happily. I don't believe that we made any but it's our policy to contribute back fixes/changes to any opensource project that we leverage." Which presumably means they're using the standard command-line parameters, so potentially a different PPC could be used to generate code for some other target. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
Armin Diehl wrote:
I need some hint regarding opening a serial (ttyUSB) port using the unit
serial. Minicom works fine under my user id. When i call
SerOpen('/dev/ttyUSB0'), fpopen blocks forever. When i first start
minicom on that port, SerOpen and all other functions of serial.pp works
fine.
ttyUSB0 is:
crw-rw 1 root dialout 188, 0 Aug 18 09:37 /dev/ttyUSB0
changing it to
crw-rw-rw- 1 root dialout 188, 0 Aug 18 09:38 ttyUSB0
makes no difference. (my user id has the supplemental group "dialout"
added) SerOpen will always block if minicom is not started on the same
port, the same applies if i try it wit root.
stty with minicom started:
speed 19200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^A; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1;
time = 5;
-parenb -parodd cs8 hupcl -cstopb cread clocal crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon
ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke
stty without mnicom started:
speed 19200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^A; eol = ;
eol2 = ; swtch = ; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1;
time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
-ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke
diff
time = 0; -clocal -crtscts -ixon -ixof
Fedora 14, 64 Bit
2.6.35.13-92.fc14.x86_64 #1 SMP Sat May 21 17:26:25 UTC 2011 x86_64
x86_64 x86_64 GNU/Linux
Assuming that you mean the standard serial.pp, that's not something I've
seen here /but/ I'm using a 32-bit kernel. I think that the first thing
I'd explore is whether you need the incoming control lines (cts, dsr,
cd) to be asserted before the function completes, but quite frankly if
I'm reading your
> When i first start minicom on that port, SerOpen and all other
> functions of serial.pp works fine.
correctly then it sounds like a kernel or driver issue.
Anybody: I've modified serial.pp to support Win-32 and fix a couple of
issues. Bug http://62.166.198.202/view.php?id=18946
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
Armin Diehl wrote:
yes, that is better
function SerOpen(const DeviceName: String): TSerialHandle;
var
flags : cint;
begin
Result := fpopen(DeviceName, O_RDWR or O_NOCTTY or O_NONBLOCK);
if result > -1 then
begin
flags := fpfcntl(Result,F_GetFl);
fpfcntl(Result,F_SETFL,flags and (not O_NONBLOCK));
end;
end;
results in
open("/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 10
fcntl(10, F_GETFL) = 0x8802 (flags
O_RDWR|O_NONBLOCK|O_LARGEFILE)
fcntl(10, F_SETFL, O_RDWR|O_LARGEFILE) = 0
i think this should be changed in serial.pp
But why have I not seen this problem on Debian despite having used this
unit extensively? And why have I not seen it when testing the modified
unit on Solaris with the SerOpen() function being unchanged?
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] serial under linux, SerOpen blocks
Ludo Brands wrote: Some serial ports seem to have clocal unset, for some reason, which causes it to block on open (waiting for the modem status lines). Like you, I've never seen it with any of my serial ports, either. Might have to do with the defaulting to autobaud of some usbserial chips. ___ Apparently a bug in a recent usb serial kernel module pl2303: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/661321 Well spotted :-) I was going to speculate that it might be something to do with the Prolific driver- I think that the device I use most is FTDI. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Code generation oddity on SPARC Linux
I have a fragment of code that looks like this: VAR z, a, alpha, b, c, d, e: Int64; f: DOUBLE; BEGIN td:= td + 0.5; // astronomical to civil z:= Floor(td); f:= td - z; IF z < 2299161.0 THEN a:= z ELSE BEGIN alpha:= Floor((z - 1867216.25) / 36524.25); a:= z + 1 + alpha - Floor(alpha / 4) END; Using 2.4.4 with -a -al -s this compiles to a .s which looks like this: .Ll34: # [439] IF z < 2299161.0 THEN ld [%i6-32],%o0 ld [%i6-28],%o1 callfpc_int64_to_double nop sethi %hi(_$MOONPHASE$_Ld8),%o0 ld [%lo(_$MOONPHASE$_Ld8)+%o0],%f1 fcmpd %f0,%f1 nop fbl .Lj87 nop ba .Lj88 nop .Lj87: .stabn 68,0,441,.Ll35 - MOONPHASE_JYEAR$DOUBLE$INT64$INT64$DOUBLE .Ll35: # [441] a:= z This appears to be the only place in the program where fcmpd %f0,%f1 is generated, although the same opcode is generated with other registers as opeands. Assembling with as (2.17 or 2.18), I get this error: moonphase.s:629: Error: Illegal operands If I change the code to look like this: f:= td - z; IF z - 2299161.0 < 0 THEN a:= z ELSE BEGIN it generates this: .Ll34: # [440] IF z - 2299161.0 < 0 THEN ld [%i6-32],%o0 ld [%i6-28],%o1 callfpc_int64_to_double nop sethi %hi(_$MOONPHASE$_Ld8),%o0 ld [%lo(_$MOONPHASE$_Ld8)+%o0],%f1 fsubs %f0,%f1,%f0 sethi %hi(_$MOONPHASE$_Ld9),%o0 ld [%lo(_$MOONPHASE$_Ld9)+%o0],%f1 fcmps %f0,%f1 nop fbl .Lj87 Having a workaround makes this not particularly crucial, but I'd welcome any comments. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Code generation oddity on SPARC Linux
Jonas Maebe wrote: The sparc only has single precision floating point registers. Double precision values are stored in two consecutive single precision registers, and hence arguments to double precision opcodes must always be even registers. The above demonstrates a bug in the register allocator. Please file a bug report. Thanks Jonas, will do in the morning. I've worked around it by noticing that I only need integer operations at that point- I'm transcribing Perl (MoonPhase.pm) based on C (moontool.c), and it's not the first instance of bad type handling that I've found. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Code generation oddity on SPARC Linux
Jonas Maebe wrote: On 26 Aug 2011, at 22:42, Mark Morgan Lloyd wrote: Using 2.4.4 with -a -al -s this compiles to a .s which looks like this: .Ll34: # [439] IF z < 2299161.0 THEN ld [%i6-32],%o0 ld [%i6-28],%o1 callfpc_int64_to_double nop sethi %hi(_$MOONPHASE$_Ld8),%o0 ld [%lo(_$MOONPHASE$_Ld8)+%o0],%f1 fcmpd %f0,%f1 nop fbl .Lj87 nop ba .Lj88 nop .Lj87: .stabn 68,0,441,.Ll35 - MOONPHASE_JYEAR$DOUBLE$INT64$INT64$DOUBLE .Ll35: # [441] a:= z This appears to be the only place in the program where fcmpd %f0,%f1 is generated, although the same opcode is generated with other registers as opeands. Assembling with as (2.17 or 2.18), I get this error: moonphase.s:629: Error: Illegal operands The sparc only has single precision floating point registers. Double precision values are stored in two consecutive single precision registers, and hence arguments to double precision opcodes must always be even registers. The above demonstrates a bug in the register allocator. Please file a bug report. Submitted as 20072 -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] -dEXTDEBUG and compilation failures
What is the status of the EXTDEBUG code? I know that I have to define that to be able to use the compiler's -an option, but if enabled 2.4.4 doesn't compile. The fix is fairly trivial but if I notice this should I be bug-reporting it? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Building without the fp IDE
Is there a "correct" way of telling the build process to skip the fp IDE? I'm trying to build trunk for SPARC so I can test the two recent FPC fixes plus another in Lazarus and am getting an error when building fp which I'd rather not stop to look at right now (although I'll try to report it later). For the moment I've commented out the IDE=1 line in Makefile.fpc. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building without the fp IDE
Graeme Geldenhuys wrote: On 09/09/2011 14:34, Mark Morgan Lloyd wrote: Is there a "correct" way of telling the build process to skip the fp IDE? Delete the 'ide' folder? :) But won't the top-level makefile rules object to that? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building without the fp IDE
Vincent Snijders wrote: 2011/9/9 Mark Morgan Lloyd : Graeme Geldenhuys wrote: On 09/09/2011 14:34, Mark Morgan Lloyd wrote: Is there a "correct" way of telling the build process to skip the fp IDE? Delete the 'ide' folder? :) But won't the top-level makefile rules object to that? I would just try it, these lines from Makefile.fpc may support it: # Compile also IDE (check for ide and fv dir) ifneq ($(wildcard ide),) Otherwise, I would try make IDE=0 Thanks Vincent, I'll have a play once I've achieved the primary objective which is to test fixes other people have contributed recently: not to do so promptly would border on the ungrateful :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Project Idea: Mini-FPC
Michael Van Canneyt wrote: On Sat, 10 Sep 2011, Jeff Duntemann wrote: If a "mini-FPC" were to be created to help popularize the Pascal language and get beginners interested and up to speed, it would be more useful to provide a simple IDE than a stripped-down compiler. The console FP IDE has never worked well for me (crashes a lot) and Lazarus is very large and intimidatingly complex. I'd rather see some effort put into an easy-to-install beginner's programming environment than in pulling features out of the compiler. I know this isn't the forum for that discussion, but I did want to make the suggestion. Maybe more effort should be put in the 'education' version of lazarus. Someone already started this. I was hoping to put some time into the IDE, but in practice am using Lazarus now even for console apps. One thing that does occur to me is that the sort of cut-down compiler that the OP has suggested is probably very similar to a minimal compiler+libraries combination that would be a useful timesaver when trying to get a new port or version to the "Hello, World!" stage. Is there a makefile target that will do this? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
Martin wrote: On 12/09/2011 08:47, Torsten Bonde Christiansen wrote: I really miss the easy use of the Delphi debugger from D7. Especially the live inspection of object during single step of the code. In that case you (all involved) better specify the required features. The debugger itself (in my understanding) can either have a library-like interface or command-line driven or both. Allowing that gdb is implemented over a wide variety of CPUs and OSes, I wonder whether it would make more sense to "adopt" libgdb than writing something from scratch? I've managed to compile this and incorporate it into the fp IDE for a number of Linux platforms, with the exception of ARM which was problematic. I can't remember the extent to which I've tried for Windows and Solaris. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM native compilation (Toshiba AC100)
Sven Barth wrote: Am 21.09.2011 22:45, schrieb Henry Vermaak: On 20 September 2011 12:18, Henry Vermaak wrote: On 20 September 2011 11:55, Sash0k wrote: So, what can I do next? My goal is get stable fpc + mseide for Toshiba AC100 device. I've built fpc trunk successfully on my AC100. I will check which revision worked tonight. To get this to work, you'll have to revert to revision 18269, build the compiler, then use that compiler as a starting compiler to build trunk. This worked for me. I don't know how the fpc team deals with this normally. Compiling the trunk compiler is only supported when using the latest release (currently 2.4.4) as a starting compiler. Which, stating the obvious, is difficult when the available binary is stuck at 2.2.2. I got from there to 2.4 via (I think) 2.5 with Jonas's help, and since then have moved it between local machines as a binary. I can confirm that 2.4.4 will build FPC trunk (2.7.1) on ARM, and that that can build Lazarus trunk. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM native compilation (Toshiba AC100)
Henry Vermaak wrote: On 22 September 2011 10:26, Mark Morgan Lloyd wrote: I got from there to 2.4 via (I think) 2.5 with Jonas's help, and since then have moved it between local machines as a binary. I can confirm that 2.4.4 will build FPC trunk (2.7.1) on ARM, and that that can build Lazarus trunk. I got 2.4.4 here: ftp://ftp.freepascal.org/pub/fpc/dist/2.4.4/bootstrap/ Maybe we should upload your 2.4.4 ppcarm if it compiles trunk without problems. Important caveat: it compiles trunk on a Qemu-emulated system as described at http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators However this being the case, such a system should be a good starting point if somebody then needed to progress to e.g. different FP support. I routinely build enough for my own use using the contents of fpcbuild/fpcsrc, would that be adequate (and how do I do the final packaging stage) and whither should I upload it? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM native compilation (Toshiba AC100)
Mark Morgan Lloyd wrote: Henry Vermaak wrote: On 22 September 2011 10:26, Mark Morgan Lloyd wrote: I got from there to 2.4 via (I think) 2.5 with Jonas's help, and since then have moved it between local machines as a binary. I can confirm that 2.4.4 will build FPC trunk (2.7.1) on ARM, and that that can build Lazarus trunk. I got 2.4.4 here: ftp://ftp.freepascal.org/pub/fpc/dist/2.4.4/bootstrap/ Maybe we should upload your 2.4.4 ppcarm if it compiles trunk without problems. Important caveat: it compiles trunk on a Qemu-emulated system as described at http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators However this being the case, such a system should be a good starting point if somebody then needed to progress to e.g. different FP support. I routinely build enough for my own use using the contents of fpcbuild/fpcsrc, would that be adequate (and how do I do the final packaging stage) and whither should I upload it? On the other hand it's worth noting that I too am using -O-, so if there's already a usable binary at the URL above I can't better it. However I'd suggest that somebody update the main website to point to it, even if it has an attached health warning. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM native compilation (Toshiba AC100)
Thomas Schatzl wrote: That is a known issue with 2.4.4 that it does not compile trunk with optimization turned on. There seems to be a bug that has been existing for a long time that has been triggered by code changes in 18230; the ARM compiler is not as well maintained as others. I think 2.4.4 definitely builds when specifying -O- as extra build options though. I am working on it, however I fear that -O- will need to be set for some time. So I wonder what version/revision Delphi uses? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] alignment warnings
Henry Vermaak wrote: On 30/09/11 10:52, Martin wrote: On 30/09/2011 10:44, Henry Vermaak wrote: Hi list Thinking more about the alignment problems on arm and elsewhere, I was wondering how hard it would be to implement something like gcc's -Wcast-align. Here's a description from the man page: Warn whenever a pointer is cast such that the required alignment of the target is increased. For example, warn if a "char *" is cast to an "int *" on machines where integers can only be accessed at two- or four-byte boundaries. Why limit it to "on machines where ... can only be accessed at ... boundaries". If code is written for multiply platforms, then the implementor may be on a machine where the cast is allowed, and needs no warning, but soon as the code is compiled on a different architecture, the warnings come up. It would be good, if one could also enable warnings for code, that may have issues on other platforms Because you may be writing code that's specific to a platform? I guess you can have another option that will warn on all machines. I think we need to take into account the particular case of ARM, where some implementations are stricter than others but there's no indication/test in the ABI or loader. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS
Mark Morgan Lloyd wrote: Marco van de Voort wrote: Question if I may: should I be avoiding symlinks as non-portable? For anything that should go back into SVN: no symlinks (*). (and in general, even without SVN concerns, I don't think heavy symlinking is a good concept in sources. This would cause only problems because sb might modify it for ppc, and not notice mips also linked to the file) (*)http://subversion.apache.org/faq.html#symlinks Thanks, noted. Obviously while I've just got a local copy on my system I can easily locate symlinks, SVN is very much in the future since I've got limited confidence in my work so far. I'm trying to put some more time into this. I've got to the point where building the RTL complains with 'Selected assembler reader not supported' which I suspect is because there isn't an racpugas.pas unit in the compiler. Could somebody please kick me ASAP if this isn't the case. As a general question (or possibly this is a feature request), should fpc -i report the available assembler formats? How about also the svn revision number if available? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem with Now() and time changed by ntpd
Felipe Monteiro de Carvalho wrote: One more idea: Do we already have something like NowUTC ? Just like Now, but in UTC. Maybe that would be something interresting to add. Programs that want to measure time differences could use it instead of hacking Now. NowUTC seams to be much more appropriate for time differences then Now, and it would be extremely fast everywhere. Agreed. Basically, the idea of "time" that underpins timers, which should fire correctly irrespective of any DST transitions. But even in this case, what should happen if the user (or NTP) explicitly changes the system clock? Ultimately, what matters for relative timing is ticks-since-boot. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem with Now() and time changed by ntpd
Felipe Monteiro de Carvalho wrote: On Wed, Nov 2, 2011 at 9:56 AM, Marco van de Voort wrote: Not entirely related to the discussion, but I don't see that at all. There is a reason why libc has monotonous time functions. And I think we should have too: Now() -> Like Michael proposed. Implemented with precision, but with a switch for existing code bases to hack it into being fast. And for new projects 2 new methods: NowUTC() -> Current time in UTC GetMonotonousTimeCount() -> Gives the number of microseconds since an unspecified initial time which is totally fixed. This one people should use for more precision timing. Without meaning to cause offense, I think that should be monotonic (i.e. it is guaranteed to never decrement). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] cannot compile fpc 2.6.0 for mips
Andrew Haines wrote: Hi, I was trying to build a cross complier for mips-linux and met this error: make crossinstall PP=/usr/local/lib/fpc/2.6.0/ppcx64 OS_TARGET=linux CPU_TARGET=mipsel make[4]: Entering directory `/home/andrew/programming/fpc-2.6.0/packages/fcl-web' ./fpmake clean --localunitdir=../.. --globalunitdir=.. --os=linux --cpu=mipsel -o -Pmipsel -o -XPmipsel-linux- -o -Xr -o -Ur -o -Xs -o -O2 -o -n -o -Fu/home/andrew/programming/fpc-2.6.0/rtl -o -Fu/home/andrew/programming/fpc-2.6.0/packages/hash -o -Fu/home/andrew/programming/fpc-2.6.0/packages/paszlib -o -Fu/home/andrew/programming/fpc-2.6.0/packages/fcl-process -o -Fu/home/andrew/programming/fpc-2.6.0/packages/fpmkunit -o -FE. -o -FUunits/mipsel-linux -o -dmipsel -o -dRELEASE --compiler=/home/andrew/programming/fpc-2.6.0/compiler/ppcross An unhandled exception occurred at $00423596 : EInstallerError : Invalid CPU name "mipsel" $00423596 $0042BEC1 $0042B70C $0042E015 $0043BE2B $0043BE67 $00400278 make[4]: *** [clean] Error 217 Anybody know which version of fpc supports mips the best? If you progress beyond my effort described at http://wiki.lazarus.freepascal.org/Native_MIPS_Systems please update the page accordingly. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] cannot compile fpc 2.6.0 for mips
Florian Klämpfl wrote: Anybody know which version of fpc supports mips the best? trunk, however mips was never in a working state in svn. The basic compiler works and some of the RTL compiles, but the tweaks necessary are highly tentative since I don't fully understand e.g. the subtleties of some of the CG defines and are only described at http://wiki.lazarus.freepascal.org/Native_MIPS_Systems since I've not asked anybody to commit the changes. I've worked through some of the stuff but have stalled at the assembler reader, which forced me off onto an exercise of reading up on the MIPS ABI etc. whence I never really returned. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Statistics on compiling the Free Pascal compiler for Win32
Paul Robinson wrote: > I sometimes wonder if programmers at the Rite Aid or Walgreens drug > store chains use CVS. (CVS is a competing drug-store chain in the US > as well as the name of a source-code repository system.) Oh well, it > was a better joke when I thought of it. I'd remind you that several other manufacturers (including Burroughs and ICL) used the IBM 029 card punch, even if they typically put their own logo on it. > On the pages on the Free Pascal Wiki I'm writing on my attempts to > port the Free Pascal Compiler over to the IBM 370 series machine > (known now as zSystem), That seems an eminently good idea, since it's about the only major architecture (with the arguable exception of the Itanic) that FPC doesn't target. > with the initial target being an IBM 370 on OS/VS1, Why not start with Linux? it's a bit more accessible for the rest of us, and you'll be able to refer to existing RTL source. > * It's Big Endian (I believe the PDP-11 minicomputer is also.) As are SPARC and PPC, both of which FPC supports. > * The most you can access at any one point from a register is 4K, > whether that's a branch in code, or a piece of data. [...] Only > tables are available, in-line constants are generally not (this is > not exactly true, but is close) I'd suggest reviewing the "Porting GCC to the IBM S/390 Platform" paper that I've cited on http://wiki.lazarus.freepascal.org/ZSeries, and selecting a base system that does allow inline constants. I think it's pretty unlikely that anything's left in (commercial) operation that's older than this, and the Hercules emulator (see for example http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators#Debian_zSeries_Guest_using_Hercules) obviously supports the newer facilities. > * It's internal character set is EBCDIC, not ASCII. Also, the > character set is not continuous along the alphabet, e.g. doing a test > on ['a'..'z'] or ['A'..'Z'] will fail because it will pick up other > non-alphabetic characters. Again, I'd suggest starting off targeting hardware and OS that's happy with ASCII. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
