Re: [fpc-devel] Graphical RAD IDE in FPC
On 17/09/18 06:30, Alexander via fpc-devel wrote: I obtain lazarus_1_8_4 sources and make it.See about dependent Lazarus: GTK widgets. GTK is C widgets, but not native Pascal widgets. MSE have independent widgets. I want have RAD IDE, not just IDE. This is advantage Pascal over C. GTK is a /library/ written in C. It sits on top of X11, written in C. They sit on top of an operating system, written in C. They all run on a processor written in VHDL or something similar. I'm afraid that it's just something you're going to have to live with, imagining that you can do absolutely everything in a single language is quixotic. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64
On 27/04/18 06:45, Thorsten Engler wrote: But the only responses are by a reporter named Thaddy de Koning,> which are for me totally useless and IMO he did miss the point.It's not the first time the person has been less than helpful... After looking through other issues he has commented on, I don't think he has contributed anything beyond, usually wrong, often aggressive and/or insulting, notes on the tracker. Note that "reporter" means that somebody's not a manager of the bug tracker. The designation covers a lot of people who are regular contributors to- and testers of- the core FPC code, and it's probably unfair for somebody to accuse one of them of trolling without considering that. Having said that, I think that the OP would possibly have made a bit more headway if he'd reported it as a simple regression against the 2016 version of the compiler. I have to say that I don't think Thaddy has exactly helped things by implying that a 64-bit double is converted into an 80-bit extended on an architecture which doesn't support that type. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fix CamelCase in unit and method names
On 22/03/18 15:30, Juha Manninen wrote: On Thu, Mar 22, 2018 at 3:15 PM, Denis Kozlov <dez...@gmail.com> wrote:> Please do... It has caused enough eye (OCD) stress over the years ;) +1Yes, it has bothered also me a lot. I use code completion to get theunit names correctly. Most of them are CamelCase but some arelowercase. The result looks sloppy. Maybe it is OCD, don't know. Itbothers me anyway. Is my understanding correct that there's no compiler warning for this sort of inconsistency? -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MACRO - correct syntax?
On 25/02/18 18:15, Giuliano Colla wrote: Il 25/02/2018 18:34, Florian Klämpfl ha scritto: http://www.gnu-pascal.de/gpc/Preprocessor.html, nobody prevents people to run a preprocessor before> FPC gets the code. That's a constructive suggestion. Easily put in the makefile [DUCKS] :-) -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MACRO - correct syntax?
On 25/02/18 10:30, Florian Klämpfl wrote:
Am 25.02.2018 um 11:12 schrieb Mark Morgan Lloyd:> On 25/02/18 02:15, Ozz Nixon wrote:>> {$MACRO
ON}>> {$DEFINE _CTASSERT(X,Y,Z):=assert(x=y,z);}>> Begin _CTASSERT(1,1,'Constant
failed.');end.> > I don't believe parameters are supported :-(>
Why so sad? They are not supported on purpose :)
Because it messes up what the OP was trying to do, which is not
necessarily something to feel good about.
And as far as "doing it on purpose" is concerned, you might or might not
be acquainted with what happened when the illustrious Brigadier Gerard
tried his hand at cricket...
https://www.arthur-conan-doyle.com/index.php/The_Brigadier_in_England
:-)
--
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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MACRO - correct syntax?
On 25/02/18 02:15, Ozz Nixon wrote:
{$MACRO ON}
{$DEFINE _CTASSERT(X,Y,Z):=assert(x=y,z);}
Begin _CTASSERT(1,1,'Constant failed.');end.
I don't believe parameters are supported :-(
--
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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An extension of fpc language: the BASED construct
On 26/12/17 23:15, Giuliano Colla wrote: Il 26/12/2017 14:27, Mark Morgan Lloyd ha scritto:> What does gdb (and possibly other debuggers) make of this? What currently gdb tells (and any other debugger would tell) is : No symbol "Item" in current context. Once the appropriate entries are implemented in the debugger symbol table, it will behave like it does in similar conditions, i.e. displaying a value referenced by a pointer. I didn't mention in my ToDo list because I'm a bit lazy, but this too has to be done. I'm getting uncomfortable with the amount of "magic" required here. Is it really appropriate to declare Item as a variable, when it's > really more akin to a macro? It's not different from the declarations: myString: string;myObject: TObject; where your declaration only reserves a pointer, while the actual string or object will be instantiated only at run time. Item is a variable, whose location isn't known at compile time, but will be known only at run time. Except that you've already said above that "Item" doesn't actually exist, while "myString" does even if the compiler etc. knows that it's to be implicitly dereferenced. I'd suggest that this would be better approached either as a generalisation of managed types- strings and the rest, or as a final resolution of the "with" controversy including full consideration of the scope issues. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An extension of fpc language: the BASED construct
On 26/12/17 12:45, Giuliano Colla wrote: /In short the BASED construct makes the C-style dereferencing operator unnecessary, by moving dereferencing from code to declaration. In fpc this translates into code looking like this, in this trivial example: var I: BYTE; I1: INTEGER; ItemPtr: Pointer; Item: BYTE BASED ItemPtr; IntegerItem: INTEGER BASED ItemPtr; ItemPtr := @I; Item := $41; ItemPtr := @I1; IntegerItem := -32767; This code will load the BYTE value $41 into the variable I, and the INTEGER value -32767 into the variable I1. What does gdb (and possibly other debuggers) make of this? Is it really appropriate to declare Item as a variable, when it's really more akin to a macro? -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] How does one request new features?
On 05/12/17 22:15, Tomas Hajny wrote: On Tue, December 5, 2017 21:50, J. Gareth Moreton wrote:> Should I still open a bug/feature request though? When it comes to> high-performance applications such as> games and scientific/mathematical programs, I feel this is quite> important. I believe that the feature request entry in Mantis (referring the createdWiki page) would be indeed useful. Agreed, but I think https://sourceforge.net/projects/vectorpascalcom/ is also noteworthy. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] How does one request new features?
On 04/12/17 21:15, Michael Van Canneyt wrote: On Mon, 4 Dec 2017, J. Gareth Moreton wrote: Hi everyone,>> I have a little question to ask. If one wishes to request new features for a future version of Free Pascal, > how does one go about it and what is the process of determining if it is a good idea or should be dropped, as > well as any cross-platform and language nuances that need sorting out? Put it in the bugtracker. If it needs a long explanation/manyconsiderations: make a WIKI page first and refer to it in the bugtracker. But please make sure that any wiki page is marked as being for the discussion of a suggestion, and that it's deleted if not adopted. The wiki's already got a maintenance problem with outmoded examples 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dangerous optimization in CASE..OF
On 04/10/17 08:15, Martok wrote: Hi all, another few months, and something funny happened this morning: a tweet shows upin my timeline which links to this article on efficient codegen for dispatchwith switch statements:<http://www.cipht.net/2017/10/03/are-jump-tables-always-fastest.html>Very interesting! Why I'm resurrecting this thread is the reference to Arthur Sale's 1981 paper"The Implementation of Case Statements in Pascal". He compares linear lists,jumptables, binary search and masksearch (on B6700 machines). The bit onjumptables (journal-page 933) contains this part:"""The jump-table itself consists of half-word (3 bytes) unconditional branches,and must be half-word synchronized. The range-check and indexed branch add up to23 bytes of instructions on the assumption that the range limit values arefitted into 8-bit literals, and there is a 0-2 byte padding required to achievejump-table synchronization. *The range check is never omitted as theconsequences of a wild branch which lands outside the jump-table are potentiallydisastrous.* If the range is r, the space requirements are therefore [...]""" "potentially disastrous" probably didn't mean security as much as "my room-sizedmainframe crashes", but the point stands... I've eyeballed that but don't have time to give it the attention it deserves. I'd remind you that some of the Pascal implementations for the Burroughs systems relied on using the tagged architecture in non-standards ways which might have needed the compiler to be "blessed" to a privileged state. In general the B6700 etc. was more resilient than the earlier B5500, which had the serious flaw that it had "character mode" operations which worked on absolute addresses and completely bypassed the descriptor-based protection mechanism. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dangerous optimization in CASE..OF
On 01/07/17 22:45, Martok wrote: This is fine if (and only if) we can be absolutely sure that theEXPRESSIONRESULT always is between [low(ENUM)..high(ENUM)] - otherwise %eax inthe example above may be anywhere up to high(basetype)'th element of thejumptable, loading an address from anything that happens to be located after ourjumptable and jumping there. This is, I cannot stress this enough, extremelydangerous! I expect not everyone follows recent security research topics, sojust believe me when I say that: if there is any way at all to jump "anywhere",a competent attacker will find a way to make that "anywhere" be malicious code. Is this made safe by always having an else/otherwise? If so, could the compiler at least raise a warning if an enumeration was sparse but there was no else/otherwise to catch unexpected 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Porting fpc to linux-sparc64
On 29/05/17 15:15, Karoly Balogh (Charlie/SGR) wrote: Hi, On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote: Plus you need to fix the Makefile.fpc in rtl/linux to include -32 for> SPARC, and regenerate it using fpcmake -Tall. Then everything works. Maybe> it's also possible to just add ASTARGET=-32 into the make command line,> without patching the Makefile. But I did not try this.>> Can you try if you can reproduce this? Err, sorry, there's a typo in the previous line I've sent. here's thecorrect one. Also, ASTARGET= override seems to work, so you don't need topatch the sources, you can fix it during build with options. Like this: make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32" This builds current 3.1.1 SVN with the preinstalled 3.0.2 package on theDebian SPARC64 box without patching anything. Now, if you want to patchthe compiler for this, or simply wire additional options to the packagesupplied fpc.cfg with the right paths and options, that decision is notmine to make. I'm not the Linux maintainer, and even less of a SPARCmaintainer. :) I'm happy enough to test on the OSes etc. that I've got set up here. Is it /just/ that command line? Is this going via Mantis? Whatever, good work everybody. It's a public holiday in the UK- it is in Berlin as well or is the flurry of work just a coincidence? -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Porting fpc to linux-sparc64
On 29/05/17 11:12, Karoly Balogh (Charlie/SGR) wrote: Hi, On Mon, 29 May 2017, Mark Morgan Lloyd wrote: My recollection is that the SPARC64 code generator is immature,> hopefully Jonas will comment on that. Not sure what "immature" means, granted, I don't know anything aboutSPARC, but from what I see, FPC definitely handles SPARC as a 32bit onlyarchitecture now. All the definitions in fpcdefs.inc hardwires CPUsettings as 32bit, it doesn't seem to know about a 64bit ALU,sparc/cpubase has only sizes defined as 32bit, etc. And I can't see a separate SVN branch for 64bit either. So I'd say it'ssimply "not there"? I /thought/ that there used to be something, and that I'd discussed it briefly some while ago with Jonas. After all, we're probably the last people to still have a (small) number of desktop systems, and it seems to be me who's caused most of the hassle about the architecture over the years :-) I notice that Jonas commented recently https://forum.lazarus.freepascal.org/index.php?topic=36272.0 -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Porting fpc to linux-sparc64
On 29/05/17 08:15, Karoly Balogh (Charlie/SGR) wrote: Hi, On Sun, 28 May 2017, John Paul Adrian Glaubitz wrote: When trying to cross-build fpc for sparc64, I ran into linker issues. I was> able to resolve these when changing the ELF format from 32 to 64 bits in> compiler/system/t_linux.pas and changing the dynamic loader path from> /lib/ld-linux.so.2 to /lib64/ld-linux.so.2. However, trying to run these> binaries on an actual sparc64 box running Debian unstable results in bus errors. Hmm, we had the last testsuite run for SPARC Linux back in 2013. I wasunder the impression it's still being tested... The Solaris version's lasttestresult is from 2012... https://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=1=150744https://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=1=120817 Which might suggest that the trunk could be broken at this point. :(And/or completely unprepared for 64bit in any way. Although we still seemto have a stable 3.0.2 release. Can you try if the stable release built byus works on your system? Any binary from this. ftp://ftp.freepascal.org/pub/fpc/dist/3.0.2/sparc-linux/ The important thing to know about the linker on 32-bit Solaris is the -Xn option to force the native one to be used. Apart from that more info is needed before anybody here can comment. Thus, I was wondering whether there are still people around who care for the> SPARC port of fpc and who could help me. We have very fast sparc64 porterboxes> available running Debian unstable and I'd be happy to create accounts on these> machines for anyone who wants to help. I don't know anything about SPARC, but if no one else volunteers, I cantake a look. In fact, maybe even a full 64bit SPARC port shouldn't be thathard (famous last words...), but at least a few weeks of work for sure forsomeone who knows the compiler internals. 32-bit 3.0.2 builds without problems for both Linux and Solaris, and by and large works including the Lazarus IDE. My recollection is that the SPARC64 code generator is immature, hopefully Jonas will comment on that. Adrian, I've put very little time into the SPARC 64-bit Debian port, and despite tracking the mailing list I'm a little unclear how complete it is and- in particular- how easily it installs. Does it support multiarch to allow 32-bit binaries to run seamlessly? -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Different results of random(int32) and random(int64) for negative limit value
On 20/05/17 13:00, Martin Schreiber wrote:
Hi,
FPC fixes_3_0, Linux X86:"var i1: int32;begin for i1:= 0 to 5 do begin
writeln(random(int32(-16))); end; writeln('*'); for i1:= 0 to 5 do begin
writeln(random(int64(-16))); end;end;"
produces"-9-9-11-13-10-13*395468"Is this intended? If not, which one is
correct?https://www.freepascal.org/docs-html/current/rtl/system/random.htmlstates for 32 and 64
bit"Random returns a random number larger or equal to 0 and strictly less than L."which raises the
question, what means "less"?
What does it do if the parameter is +ve? Note
https://mantis.freepascal.org/view.php?id=31693
--
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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.0.2 for SPARC
On 06/05/17 06:30, Ozz Nixon wrote: (Personally): AWESOME! :-) The compiler etc. should be OK, the thing to really watch out for- particularly on Solaris- is which variant of binutils is being used (ditto for tar etc., particularly during installation). There's a Solaris page on the Wiki which is probably still relevant: http://wiki.lazarus.freepascal.org/Lazarus_on_Solaris As Pierre had to remind me, the -Xn issue is still 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.0.2 for SPARC
On 08/05/17 14:00, Pierre Muller wrote: Le 05/05/2017 à 13:00, Mark Morgan Lloyd a écrit :> This is something that was discussed on the FPC-Pascal ML but it died.> > I am able to build installation bundles for SPARC running Linux (Debian) > and Solaris (OpenSXCE). The fp IDE works but doesn't have libgdb > support, and I've got limited time to struggle up the learning curve. > Would these be of use for the downloads area, which at present only has > 2.6.2 and 2.4.2 respectively?> I have uploaded the files that Mark sent to meto both main ftp server and SourceForge,and adapted html pages. You should now be able to download 3.0.2 sparc-solaris and sparc-linuxinstallation tar files by following the links starting at: https://www.freepascal.org/download.var If you encounter any problems, to download the files or toinstall the new 3.0.2 sparc compiler, please let us know! Thanks Mark! All credit to the core developers who've generally made this project a success, and my apologies for bothering them over the years with what's admittedly a fairly obscure platform by now. I think it's worth keeping alive if possible though, because its insistence on fairly strict alignment etc. is useful for showing up potential problems. Lazarus should compile on both Linux and Solaris, subject to one known bug when invoking help https://mantis.freepascal.org/view.php?id=22696 -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.0.2 for SPARC
On 05/05/17 16:00, Pierre Muller wrote: You probably need to add the -Xn option into the makepack script! Thanks for the pointer as to where it goes: those last words stopped me spending days looking for the appropriate makefile :-) If I do this it builds successfully: *sunos*) MAKE=gmake EXTRAOPT='-Xn' # Use GNU tar if present if [ "`which gtar`" != "" ]; then TAR=`which gtar` fi ;; Should I raise a bug on Mantis for this? can anybody comment on what impact this would have on the Intel target for Solaris? I'll add a note to the existing stuff on the Wiki. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.0.2 for SPARC
On 05/05/17 12:00, Pierre Muller wrote: Hi Mark, Le 05/05/2017 à 13:00, Mark Morgan Lloyd a écrit :> This is something that was discussed on the FPC-Pascal ML but it died.> > I am able to build installation bundles for SPARC running Linux (Debian) > and Solaris (OpenSXCE). The fp IDE works but doesn't have libgdb > support, and I've got limited time to struggle up the learning curve. > Would these be of use for the downloads area, which at present only has > 2.6.2 and 2.4.2 respectively? Yes it would be very nice,libgdb missing for IDE is really not a big deal... Please let me know how you can send me the files. For reasons I'd prefer not to discuss, I can't easily get access to e.g. Dropbox so am limited to email, FTP, or something similarly "old school". If you want to continue this off-list I suggest using the email address in my sig below, since it's less likely to have messages deleted as spam. On Linux we're talking about something like: 53780480 2017-04-07 09:20 fpc-3.0.2.sparc-linux.tar I need to revisit the Solaris build. Checking, I see that I can make fpcsrc without too much trouble using something like gmake NOGDB=1 OPT='-V3.0.0 -O- -gl -Xn -vt' all but the full build is giving me a linking error. Following Pierre's instructions I'm using CHECKLIBGDB=no install/makepack which is eventually failing with /usr/local/src/fpc/fpcbuild-3.0.2/fpcsrc/compiler$ /usr/local/bin/ppcsparc -Ur -Xs -O2 -n -Fusparc -Fusystems -Fu/usr/local/src/fpc/fpcbuild-3.0.2/fpcsrc/rtl/units/sparc-solaris -Fisparc -FE. -FUsparc/units/sparc-solaris -dRELEASE-dsparc -dGDB -dBROWSERLOG -Sew pp.pas /usr/bin/gld:built in linker script:21: syntax error pp.pas(238,36) Error: Error while linking pp.pas(238,36) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted I'm pretty sure I've come across this one before and that the cause is something like the wrong linker being invoked by the makefile, leave it with me so I can go through my notes. I'll be back ;-) - I don't know what the future of SPARC is going to be like, and whether the attempts that are being made to get 64-bit SPARC Linux working will make it any rosier. -- 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/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] FPC 3.0.2 for SPARC
This is something that was discussed on the FPC-Pascal ML but it died. I am able to build installation bundles for SPARC running Linux (Debian) and Solaris (OpenSXCE). The fp IDE works but doesn't have libgdb support, and I've got limited time to struggle up the learning curve. Would these be of use for the downloads area, which at present only has 2.6.2 and 2.4.2 respectively? -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Can FPC at least give a hint/warning?
On 08/11/16 10:26, Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: The Solaris and C communities appeared to take the line that a correct compiler "could not" generate unaligned accesses, although they held off clarifying whether "could" in that context means "if it does it's an error" or "it must rearrange data to avoid an error". I believe that Solaris and in some cases Linux can handle unaligned accesses in the kernel, although there's obviously a significant performance penalty. I can remember the early powerpc ports where I came into trouble with the NetBSD port because the Linux kernel used emulation to fix unaligned float loads/stores, while NetBSD didn't. I believe the Linux ARM kernel can intercept some alignment traps, the SPARC kernel can do something similar but only for kernel code (I don't know whether that will change with the current push to get Debian onto SPARC-64, it could be an artifact of the kernel being 64-bit but the userspace 32-bit). -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Can FPC at least give a hint/warning?
On 08/11/16 06:30, Dennis wrote: Gennady Agranov wrote: Hi, I have submitted a bug - http://bugs.freepascal.org/view.php?id=30872 (misaligned data exception on ARMv7) And this big was resolved as "won't fix" 1. I understand that one has to work really hard to encounter this bug - and there are easy workarounds, but it there are also different ways to resolve this bug - e.g. just giving a hint would suffice - IMHO a compiler warning or hint would be nice. Alignment was a major issue back when SPARC was still a realistically viable platform. The Solaris and C communities appeared to take the line that a correct compiler "could not" generate unaligned accesses, although they held off clarifying whether "could" in that context means "if it does it's an error" or "it must rearrange data to avoid an error". I believe that Solaris and in some cases Linux can handle unaligned accesses in the kernel, although there's obviously a significant performance penalty. Working on the principle that the FPC community would do well to avoid antagonising people with expectations derived from experience with other compilers and languages, I'd suggest that a warning when potentially-misaligned code is generated is in order. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] A generic function for (multicore) cache flush?
On 31/10/16 18:48, Nikolai Zhubr wrote: Hello all, Is there any good generic (portable) function to ensure memory cache flush for a thread on a multicore system? What I'm trying to do is essentially fetch some debugging counters from multiple threads. They might happen to run on separate cores, thus having something pending in local cache sometimes. Surely that shouldn't happen on a properly-implemented cache-coherent system? -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Using double quotes
Marcos Douglas wrote: On Sat, Feb 27, 2016 at 6:38 AM, Mark Morgan Lloyd <markmll.fpc-de...@telemetry.co.uk> wrote: Marcos Douglas wrote: Is there any chance to implement in the compiler something link this? S := " insert into t ( id, description ) values ( 1, 'foo' ) "; Did you see? No, I don't see. It looks like an ordinary string to me, except that you're allowing it to extend over multiple lines somewhat like a unix here-document. Here are the differences: This: S := " insert into t ( id, description ) values ( 1, 'foo' ) "; instead of this: S := 'insert into t ( ' + ' id, description ' + ') values ( ' + ' 1, ''foo'' ' + ')'; A better solution would be a variant of Format() that could define repeated or indeterminate parameters, and that possibly allowed C-style backslash escapes. In any case, looking at your usage case it's very common to have inline variables, and again they'd be better handled by Format. Expecting somebody to rewrite the parser is probably not realistic, and in any event there's probably better things to do with double-quotes (e.g. modified semantics for Unicode). -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Using double quotes
Marcos Douglas wrote: Is there any chance to implement in the compiler something link this? S := " insert into t ( id, description ) values ( 1, 'foo' ) "; Did you see? No, I don't see. It looks like an ordinary string to me, except that you're allowing it to extend over multiple lines somewhat like a unix here-document. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Random thread-safe
Jonas Maebe wrote: Also: the entire state of the random number generator consists of regular global variables, so it is not safe to use it from multiple threads in parallel. Would it make sense to you to make random thread-safe? E.g. with the use of "threadvar" instead of "var" for the global variables in question? No. The Mersenne twister has a lot of state (about 2KB). Duplicating this for every thread, along with associated slowdown, is not worth it. It's better to use a class that encapsulates the state of a random number generator and then instantiate this class for every thread. Could I ask for clarification of this please. Are you saying that Random() will crash if called simultaneously by multiple threads, or that it will return suboptimal results? If, as an example, I have two threads doing network or comms jobs and I want to introduce jitter in the retries, does that mean that I have to put Random() into a critical section? -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Random thread-safe
Jonas Maebe wrote: Mark Morgan Lloyd wrote: Could I ask for clarification of this please. Are you saying that Random() will crash if called simultaneously by multiple threads, or that it will return suboptimal results? It's undefined. The current implementation won't crash, but the results will indeed be suboptimal. If, as an example, I have two threads doing network or comms jobs and I want to introduce jitter in the retries, does that mean that I have to put Random() into a critical section? Yes. Thanks Jonas, noted. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Program too long ?
Bernd Oppolzer wrote:
Jonas Maebe schrieb:
On 14/01/16 17:45, Mathias wrote:
The code is machine generated.
I wanted to test which compiler is faster, the. Of FPC or C ++
C ++ could compile the code without errors.
Whether or not it can be compiled is unrelated to the language of
course, but to the compiler. We indeed only develop FPC for use with
procedures that don't have an extreme size, because that way the
compiler uses less memory and is faster. Since such massive routines
are often indeed only present in case of machine-generated code, and
since in that case you can usually easily adapt your generation to
split up the code in multiple routines, there's not much incentive to
change this (other than being able to say "yes, we can handle this").
Jonas
Some history:
The original Pascal compiler (Wirth in the 1970s) also had such an error
message
"procedure too long"; this is a well known issue for almost all compiled
languages,
and such limits hit you most of the time much earlier than physical
limits or storage
limits.
I came across some interesting stuff relating to the history of GCC.
Apparently Stallman started off with a Pascal derivative ("Pastel"), but
various things that the compiler did at a syntactic level (if I'm
interpreting it correctly, roughly comparable with generics) meant that
it had to be able to hold the entire parse tree in RAM before generating
code... which exceeded the capabilities of most computers available at
the time. http://www.webcitation.org/6N4WnuuZk
--
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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Program too long ?
wkitt...@windstream.net wrote: OTOH it's very easy to end up with enormous functions- or even an enormous main block- if machine-generating source by e.g. macro expansion. now that you mention it, i do have a machine generated routine in one of my apps... it was much easier to write code to generate all of the individual case statements for the bit checking than to try to manually write all of them and not typo anything... it started as tri-state for 5 sets of vars and was reduced to bi-state for those 5 sets after a huge epiphany... we ended up with 1024 case values to check instead of something over 18000... I did it comparatively recently: machine-translate SNMP MIBs into Pascal. Now in practice individual functions/methods weren't that bad, but they easily could have been and having to break things up to suit an indeterminate limit would have been a right pain. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Program too long ?
wkitt...@windstream.net wrote: On 01/13/2016 05:01 PM, Mathias wrote: I wanted a test following compile 1'000'000x WriteLn. Procedure too complex, it requires too many registers Fatal: Compilation aborted Error: /usr/bin/ppcx64 returned an error exitcode wowowow... is there something wrong/bad with a short routine? OTOH it's very easy to end up with enormous functions- or even an enormous main block- if machine-generating source by e.g. macro expansion. I've come across some text-processing tools which were built like this... typically via antique FORTRAN which lacked functions to get unhappy about :-) -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fcl-net for Solaris etc.
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: Can anybody confirm that the comment reference to netdh.h in fcl-net/src/cnetdb.pp should actually be netdb.h, Yes. At least it was back then. (and according to the Paul Vixie author reference, some time before) because I'm having a lot of difficulty reconciling that with reality. Because? I was having a lot of difficulty reconciling the comment's reference to netdh.h with reality because I can't find that file on any local machines and all the Google refs to it look like typos. In the case of Solaris 11 the structure that needs to be checked appears to be in netdb.h I've just raised 29223 on Mantis with a patch to enable cnetdb for Solaris (tested on SPARC OpenSXCE 2014). I'm afraid that I don't have access to any of the BSDs which similarly lack it (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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Timezones
Zachary Vance wrote: Additionally, POSIX says that if TZ is set but invalid or empty, it should default to UTC, not to localtime. Observing the contents of the TZ variable is of course an option, that should not be a problem. But the default to localtime will most likely not be changed for 2 reasons a) compatibility with Delphi. b) backwards compatibility. FPC does not pretend to be POSIX. I only learnt about the TZ variable investigating this bug and don't know Pascal. That said, this seems to match the page you linked. I'm unclear if the content of literal timezones and timezone files are the same--my local ones on my computer look different, so I'd definitely test to make sure the example strings on the linked page work. If you need someone to test timezone parsing methods because you're not on Linux, try the debian-reproducible IRC. (I'd offer but I don't know fpc at all). You might want to replace '/usr/share/zoneinfo/' by the value of TZDIR if it's defined, for consistency with the rest of fpc? If you want to try our original failing test case, which is from Arch Linux but should run on any Linux system: 1. Delete /etc/timezone 2. Symlink /etc/localtime to your timezone file (not UTC, please) 3. Run TZ='' ppadump ... [If you're not modifying things, I guess it would be TZ='UTC'] Output currently uses the content of /etc/localtime, but should be in UTC. Obeying TZ sounds reasonable to me, subject to considering the Windows situation (some unix-style programs on DOS/Windows honour it). I remember previous debate on getting a guaranteed UTC timestamp, and this might be a useful way forwards provided obviously that the underlying OS plays ball. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.0.0 class property default
Mark Morgan Lloyd wrote: Up to and including 2.6.4, this works: TRoundRobin= CLASS(TObject) . PUBLIC . (*$IFDEF HAS_TRUE YIELD *) PROPERTY HasTrueYield: BOOLEAN DEFAULT TRUE; (*$ELSE *) PROPERTY HasTrueYield: BOOLEAN DEFAULT FALSE; (*$ENDIF*) . END; However using 3.0.0 rc1 I get roundrobin.pas(80,55) Fatal: Syntax error, "READ" expected but "identifier DEFAULT" found It looks as though this was coded for a facility that wasn't actually used, but that the intention was to convert a compile-time conditional into something that could be incorporated into an ordinary boolean expression. What is the correct syntax, and how far back is FPC compatible with it? Anybody got any thoughts on this please? -- 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/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] FPC 3.0.0 class property default
Up to and including 2.6.4, this works: TRoundRobin= CLASS(TObject) .. PUBLIC .. (*$IFDEF HAS_TRUE YIELD *) PROPERTY HasTrueYield: BOOLEAN DEFAULT TRUE; (*$ELSE *) PROPERTY HasTrueYield: BOOLEAN DEFAULT FALSE; (*$ENDIF*) .. END; However using 3.0.0 rc1 I get roundrobin.pas(80,55) Fatal: Syntax error, "READ" expected but "identifier DEFAULT" found It looks as though this was coded for a facility that wasn't actually used, but that the intention was to convert a compile-time conditional into something that could be incorporated into an ordinary boolean expression. What is the correct syntax, and how far back is FPC compatible with 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fwd: While - Otherwise Statement
Michael Van Canneyt wrote: But the existence of such a continue block shows the fundamental issue on which a decision is needed. should (if a volunteer for a patch exists) every little "save one statement in your code helper" be added? Because there are thousands of them, and if you add them all the readability of code will go down, because you need to first learn them all. I think the answer to your question is a clear and loud "NO". The argument that we can refrain from using these new features does not hold, because other people will be using it, and we will have to know all of it to be able to understand their code. None of these features will automagically make Object Pascal a popular language. However, I seem to be one of the very few thinking this given the enthousiasm with which people are discussing this. For what it's worth, I agree with you. It's one thing restoring something like the "inline if" (or a functional equivalent) which was in ALGOL and is regularly used in most current languages, but doing something like adding a completely new flow control construct which has no significant precedent in other languages is much more difficult to defend. Soon I will be forced to emigrate to Javascript country. Despite all its drawbacks, it remains at least a simple language. a dozen keywords and you're done. No wonder Node.js is so popular. Compare that with the jungle we're making of it... :( At the same time, I think it's worth distinguishing three distinct cases that contribute to syntax complexity. The first is the case that you had in early ALGOL implementations, where there was limited support for external libraries and where every detail of control of- for example- file open mode had to be expressed as part of the language syntax. The second is the case where a language has a fairly verbose syntax, but where this is used to define a rich set of general-purpose flow-control and data-definition constructs. This is where Pascal is at. The third case is modern C++, Javascript and so on which grossly overload the limited ASCII character set and where abusing even the lowly parenthesis can have non-obvious effects. Then there's the issues they have with things like "static", and their use of "std::something" as quasi-directives. I'm still struggling with a mainframe emulator, originally written in Javascript, where around half of the complexity was due to the lack of any support for multithreading. I also think that the recent forking of the Scratch graphical language, where a significant proportion of the community has rejected MIT's attempts to reimplement it in Javascript, indicates that there's an increasing awareness that both the language and its typical implementations- i.e. embedded in a browser or as ActionScript in Flash- leave much to be desired. And Node.js is lipstick on a pig. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fwd: While - Otherwise Statement
wkitt...@windstream.net wrote: On 10/13/2015 04:32 AM, Michael Van Canneyt wrote: On Mon, 12 Oct 2015, wkitt...@windstream.net wrote: On 10/12/2015 03:43 PM, Martin Frb wrote: Actually the above does not represent what the actual feature request is about The "else" is to be executed, after the while (even if the while looped ZERO times). But it is to be skipped if the while exited via break (and only then). For that reason "else" or "otherwise" are badly chosen keywords. Because they imply a different function. exactly my and others' points... "and" would be better but then one might just as easily use a goto to jump around that part if break was used to get out of the loop... anyway, it seems that no matter what the discussion, it won't make it into the compiler... that according to another post from a compiler dev ;) Maybe my remark was not clear. I'm not against this *functionality*. I merely pointed out that *the syntax using 'else'* is not going to make it because it breaks backwards compatibility. a... my bad... sorry 'bout that... i've been thinking about this, too... 'else' and 'otherwise' mean the same thing... what they seem to be looking for is 'aswell'... foo := 0; while foo < 100 do begin inc(foo); end; aswell begin dec(foo); end; either 'aswell' or 'aswellas'... while foo is less than 100 increment foo as well as decrement foo when it is no longer less than 100... If somebody really has to do this wouldn't "also" be a better choice to avoid (getting close to overloading "as"? :-/ -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fwd: While - Otherwise Statement
Ralf Quint wrote: On 10/12/2015 10:18 AM, Michael Van Canneyt wrote: That is the meaning of "However, both syntax would cause code incompatibility." and is already in my very first reply to OP. So While... else or While .. Otherwise will never make it in the compiler. Thanks for that. This is s typical example of one of those things that just don't make any sense in the first place. Either the while loop is executed or it isn't, depending in the expression. I don't see an actual use case for any else/otherwise extension to it... The only possible use would be to specify a finalisation statement which was only executed if the while loop cycled at least once, or possibly one which was executed if the loop never cycled. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Teensy (no OS) programmed with Free Pascal Embedded ARM
Paul Breneman wrote: Got a reply with lots of questions: How easy is it to do all the common hardware things from Freepascal? How much low-level setup is required use digital and analog I/O? Can you use the serial ports? Timers? Capacitive touch sensing? Can you even access the registers without porting a massive header file? Is it possible to link with existing C or C++ libraries? Any quick summary anyone would like for me to post as a response? Please write back here if you don't want to register on that forum. My one question would be: how general is this? Specifically, how close is it to being able to program a breadboarded chip as described at http://hackaday.com/2015/10/09/arming-a-breadboard-everyone-should-program-an-arm/ -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] new features and facilities
Michael Van Canneyt wrote: On Fri, 9 Oct 2015, Sven Barth wrote: I'm not sure this kind of semantics is possible with a compiler intrinsic... But if it is: In that case the IfThen or IIF() or somesuch has my absolute top preference, followed by ternary. (and the If .. then expression should be blasted to hell ;) ) Yes a compiler intrinsic could handle that. In the end all three syntaxes are the same code representation anyway: namely an if-node. The IfThen() intrinsic would be fine with me as well. Let's call this our common ground ;) Agreed ! It would be even better if it could be generalised to evaluate and return one of any number of expressions. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] new features and facilities
Michael Van Canneyt wrote: On Sat, 10 Oct 2015, Sven Barth wrote: Am 10.10.2015 10:51 schrieb "Mark Morgan Lloyd" < markmll.fpc-de...@telemetry.co.uk>: Michael Van Canneyt wrote: On Fri, 9 Oct 2015, Sven Barth wrote: I'm not sure this kind of semantics is possible with a compiler intrinsic... But if it is: In that case the IfThen or IIF() or somesuch has my absolute top preference, followed by ternary. (and the If .. then expression should be blasted to hell ;) ) Yes a compiler intrinsic could handle that. In the end all three syntaxes are the same code representation anyway: namely an if-node. The IfThen() intrinsic would be fine with me as well. Let's call this our common ground ;) Agreed ! It would be even better if it could be generalised to evaluate and return one of any number of expressions. How do you think that could look like? IfThen() is the wrong intrinsic for this and for a CaseOf() intrinsic you'd nevertheless need the case labels. And /then/ I agree with Ralf that it isn't understandable... I had the same thought. The only case I see applicable is an ordinal. CaseOf(a, ord(a)=0, ord(a)=1, ord(a)=2...) Still it seems somewhat convoluted. Two possibilities that I can see. The first would be a variable or expression followed by an array of corresponding expressions, implicitly zero-based: left := CaseOf(a, [b, c, d]); The second would be an array of tuples, each a predicate followed by an expression, with the predicates evaluated left-to-right until one is true. In either case there would have to be explicit rules as to what happened if the variable was out of range or no predicate evaluated true: I don't know whether it would be feasible to have a final optional flags element to determine this sort of thing, or if this is moving too far from what could reasonably be called a syntax structure. One thing that bothers me about these approaches is that sooner or later some awkward cuss (such as myself) will start whining about how much better Pascal would be if there were a decent macro preprocessor so that CaseOf() could be specialised into other forms expressing choice :-/ I'd add that historically, extended ALGOLs had if-then-else inline but put anything with more elements (e.g. tables of labels) into the declarations at the start of a block. However my reading of the manuals suggests that they might have been inconsistent about whether the first element was indexed 0 or 1. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] new features and facilities
Michael Van Canneyt wrote: On Fri, 9 Oct 2015, Sven Barth wrote: Am 08.10.2015 23:48 schrieb "Michael Van Canneyt" <mich...@freepascal.org>: Actually, yes I think C's or Javascript's ternary is better suited. Let me explain. If I see If expr1 then expr2 else expr3 it says 'statement' to me. But a ? b : c; Says "expression" to me. So left := a ? b : c; That's probably only because other languages use that as the ternary. No, it is because there are no keywords involved. The keyword "If" starts a statement. It's a simple rule. As I said: by using "if" in an expression, you break the rule and introduce ambiguity. There also another reason why I prefer the variant with the if: ease to implement in the compiler. For the if one merely needs to add a corresponding case in factor() while for the ?: one needs to fiddle with the compiler's operator precedence rules that are applied in sub_expr() which can lead to desaster either during implementation or later on when bugs are discovered... I don't see how the use of "if" differs from "?" in rules of precedence, they are at the exact same level. They're both just tokens to the compiler. At least "?" has the advantage of being new and not yet used, so is unambiguously. Jonas, what's your take on this as an overall language guru? -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] goto illegal in fpc?
Schneider wrote: Folks: https://alum.mit.edu/www/toms/ftp/shell.p Shows up as a bad link here. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] new features and facilities
Ondrej Pokorny wrote: As Michael has said, adding an extra else or for that matter otherwise would be a problem. And what about the inline if? That should be backwards compatible at a first glance. And it would be a fun thing because the Delphi community has asked for it for many years and Embarcadero looks like they won't add it at all :) Inline if is an ALGOL feature, and it's inexplicable why it's never been in Pascal. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] new features and facilities
David W Noon wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 08 Oct 2015 16:12:56 +, Mark Morgan Lloyd (markmll.fpc-de...@telemetry.co.uk) wrote about "Re: [fpc-devel] new features and facilities" (in <mv64m9$95v$1...@pye-srv-01.telemetry.co.uk>): Ondrej Pokorny wrote: As Michael has said, adding an extra else or for that matter otherwise would be a problem. And what about the inline if? That should be backwards compatible at a first glance. And it would be a fun thing because the Delphi community has asked for it for many years and Embarcadero looks like they won't add it at all :) Inline if is an ALGOL feature, and it's inexplicable why it's never been in Pascal. Indeed, it is even more succinct in C/C++: x = ? : ; At which point you'll have various members of the Pascal community decrying it as too C-like. This was taken directly from ALGOL 60 and remains a very elegant feature. However, Jensen & Wirth excluded it from the original Pascal Report. More to the point, I don't believe it was in in Wirth's early Pascal compilers although it was in ALGOL-W. This is actually quite a messy area, since ALGOL 68 changed the syntax to add an explicit FI for compatibility with the statement-level IF THEN ELSE FI. ALGOL also had inline CASE etc., and some implementations (e.g. Burroughs) extended this to accomodate jump tables etc. Curiously, Wirth's Stanford-era compilers use these liberally. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] new features and facilities
Ralf Quint wrote: On 10/8/2015 9:54 AM, Sven Barth wrote: I had the idea to implement inline-if as well. I think the syntax I selected is derived from Oxygene, but it looks very Pascal and shouldn't break anything: left := if expr1 then expr2 else expr3; Thereby expr1 returns Boolean and expr2 determines the type of the whole inline-if, thus expr3 needs to be compatible to expr2. Sorry, but that doesn't "look Pascal" at all, and is anything but easily understandable, specially given the possible complexity of expr[1,2,3]... But at least in this instance there's /always/ an ELSE, so there's no risk of apparent ambiguity due to "dangling else": a closing END or FI isn't needed. It's more difficult to argue for inline CASE, particularly since that one might have optional ELSE or OTHERWISE. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] new features and facilities
Michael Van Canneyt wrote: On Thu, 8 Oct 2015, Sven Barth wrote: Am 08.10.2015 19:10 schrieb "Ralf Quint" <freedos...@gmail.com>: On 10/8/2015 9:54 AM, Sven Barth wrote: I had the idea to implement inline-if as well. I think the syntax I selected is derived from Oxygene, but it looks very Pascal and shouldn't break anything: left := if expr1 then expr2 else expr3; Thereby expr1 returns Boolean and expr2 determines the type of the whole inline-if, thus expr3 needs to be compatible to expr2. Sorry, but that doesn't "look Pascal" at all, and is anything but easily understandable, specially given the possible complexity of expr[1,2,3]... And you think C's ternary would be more Pascal? Also you need /some/ definition of what defines the type no whether what syntax you choose (in addition expr1 is the same as in normal ifs, so it's only the "complexity" of expr2 and expr3). And no, "the left side" is not the Pascal answer either. Actually, yes I think C's or Javascript's ternary is better suited. Let me explain. If I see If expr1 then expr2 else expr3 it says 'statement' to me. But a ? b : c; Says "expression" to me. So left := a ? b : c; OK. So presumably, since false < true, b is executed if a is false and c is executed if it's true? >:-) looks more 'right' than the 'if then else', because the right-hand side is clearly an expression. The "if expr1 then expr2 else expr3" is equally counter-intuitive and confusing as anonymous functions. Keyword "If" starts a statement. If you allow to use it in expressions, its meaning becomes context sensitive. That is a bad thing in my book. So if this thing needs to be implemented, then I'd much prefer it in the ternary form. The way I look at it is that it's restoring a feature that was (possibly accidentally) dropped during the ALGOL -> Pascal transition. As such I don't have any problem with ALGOL-style left := if a then b else c; After all, while concise C-style operators work well in expressions this is not a simple expression where all components are evaluated: it's directly equivalent to the statement-level if potentially including exactly the same short-circuiting rules in the boolean expression (a above). The thing I do have problems with is the difficulty people had explaining nested inline ifs during the 1960s. However I think that was more because they simply hadn't worked out how to write language documentation rather than there being anything inherently tricky about it, and these days there's absolutely no reason why it shouldn't be spaced and indented in a thoroughly Pascal-like fashion :-) -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.0.0-rc1 release
Tomas Hajny wrote: On Thu, August 27, 2015 15:03, Frank Grotelueschen wrote: Please don't stop support for W2K. It was the first 'full useable' Windows based on NT-Kernel and is still used today. I don't think that the Win32 target maintainers would want to break working under W2K on purpose, but it's difficult to guarantee support for such a version if it isn't used and tested by the respective FPC developers regularly. On the other hand, anyone interested in support for such a version may decide to keep testing the trunk version and report any possible issues as soon as they arise, so that possible options for resolution may be discussed. I still have a few NT4 app servers, and a very small number of W2K systems. There are definite issues relating to Unicode support on NT4 which /could/ be fixed, but are probably not worth the effort since the NT4 APIs were basically not fully implemented by Microsoft. The bottom line with both NT4 and W2K is that ancillary software like installation programs are no longer viable. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.0.0-rc1 release
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: I still have a few NT4 app servers, and a very small number of W2K systems. Possession That's not the important question, rather how much new software do you develop for those? I'd not expect to ship anything externally, since we run stuff here as a service to our customers. If I moved an app from Delphi to Lazarus and it didn't run on NT4, it would be unfortunate that I couldn't do a direct comparison but in view of the OS's age hardly surprising. If I couldn't run an app on W2K I'd be slightly less happy, because as I understand it that is the last version of Windows which doesn't need to be registered/unlocked. Our preferred target is unix, but there are some things which the windowing architecture of Windows make easier. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Marco van de Voort wrote: Typing was never the limiting factor in programming, Surely you're joking. Do you really claim that there has ever been any excuse for this sort of terseness, except for minimising keyboard work? A0: R := INSYMBOL; A1: IF F[S[I]] G[R] THEN GO TO A2; IF R = MARK THEN GO TO A9; I := J := I+1; S[I] := R; MOVE(NAME, V[I]); GO TO A0; A2: IF F[S[J-1]] = G[S[J]] THEN BEGIN J := J-1; GO TO A2 END; M := MTB[S[J]]; A3: IF PRTB[M] = 0 THEN BEGIN ERROR(5); GO TO EXIT END; N := J; And that's Wirth's code, by the way. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Jonas Maebe wrote: Den wrote: Just like ECMAScript, C++, PHP, most languages now have a 'standards' document behind it. That's their *roadmap*. Their *leadership*. Design it and the *community* will show *support*. ISO Pascal and ISO Extended Pascal were like that in the early 90s: 1) there was an official ISO standard and standards committee for it 2) there were a number commercial compilers supporting it such as HP Pascal and IBM's compiler for its System/370 3) later on (in 1996) a GCC-based implementation arrived for it (the equivalent of the LLVM of the moment) And still almost no one uses ISO/Extended Pascal anymore. Why? Possibly because the de facto Pascal standards had already become Think Pascal on the Mac and Turbo Pascal on the PC by then, and none of those programmers wanted to rewrite all of their code (although Think Pascal was a bit closer to ISO Pascal). Or maybe because in general, many people just preferred those language dialects for one reason or another. In any case, introducing one new standard to rule them all seldom (if ever) works (and you can bet someone will be unable to resist to add a link to the related xkcd comic). I was selling and supporting development tools in the late 80s. From memory, there was one compiler (in the PC arena) that prided itself on robust ISO Pascal support and expressed little interest in extending towards any of the de-facto standards: nobody bought it. Their Wp page still claims It is the only compiler in existence that fully implements the ISO 10206 standard for Extended Pascal. I still have occasional problems with an old hand on a private conferencing system I use. He worked for Olivetti in the 80s, and found that he and his colleagues were mandated to write an operating system and support software in unextended ISO Pascal. In retrospect, that is universally recognised as being an inappropriate combination, but almost everybody at the time could see it as well... he still misses no opportunity to denigrate pascal as being grossly incomplete for real work. This one? https://xkcd.com/927/ Standards do not magically make a language more popular. They only work if they follow from a desire of an entire community to design one and to adhere to it. Design it and the community will show support is exactly the opposite of what happens in practice. Which in practice means that we'd need to get all of the major post-Borland compilers pulling in the same direction, starting off with Gnu Pascal, and would need to get Embarcadero committing themselves to long-term language stability. Formal standards only work if they have the support of a major standards body from day one. And informal industry standards normally take the form of openly-published documentation, and we've got that in abundance (but if Den wants to help with the indexing, I'm sure we'd all appreciate 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] grab_vcsa permissions when building from source
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: On Linux (other unixes untested), (afaik vcsa is a linux only thing) I can confirm it's not in the build for Solaris. I notice that when installing prebuilt binaries grab_vcsa is setuid root, but when building from source (svn or snapshot) it's only got basic permissions. Is this something that should be done by the installation makefile, and if so does it merit a bug report? I think this belongs to the distribution package level. The binary tgz distribution tries to set things up for systems without package system, therefore it has it. Currently the makefiles don't have a grasp of files with differing sets of permissions. (other than executable or not). Thanks for the clarification :-) -- 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/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] grab_vcsa permissions when building from source
On Linux (other unixes untested), I notice that when installing prebuilt binaries grab_vcsa is setuid root, but when building from source (svn or snapshot) it's only got basic permissions. Is this something that should be done by the installation makefile, and if so does it merit a bug report? -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Internal linker bug?
patspiper wrote:
Hi,
Linking a pascal project (with {$L mylib.obj}) with a specific .obj
(COFF32) file using the internal linker (Windows) yields an executable
that produces an exception when run. On the other hand, the external
linker produces a sane executable.
The executable is supposed to contain calls from a unit to public
functions in the .obj file, but these calls are to incorrect locations
while the surrounding code is correct, hence the exception.
eg:
External linker (correct): call function1
Internal linker (wrong) : call fpc_widestr_to_ansistr+40
A dump of the .obj file shows that all public functions have an offset
(value) in the symbol table, but no relocation entry, whereas
Static/Nonpublic and external symbols have a relocation entry even if
the symbol table entry offset (value) is 0.
Is this a bug in the internal linker especially that the external linker
does exhibit this behaviour?
Note: I am not too involved in .obj formats, so pls bear with me if the
above is inaccurate.
For the benefit of anybody who's not followed the thread, summary at
http://lists.lazarus.freepascal.org/pipermail/lazarus/2015-June/092881.html
including a link to the conversion tool (originally suggested by José
Mejuto).
--
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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] bitwise shift oddity a b
Jonas Maebe wrote: Martin Frb wrote: What is supposed to happen if the 2nd argument is negative? I would propose to document it as undefined behaviour, just like C does (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf , section 4.5.7). The reason is that the behaviour can differ depending on the cpu, so if you want to guarantee consistent behaviour on all platforms, you can no longer just emit a shift left/right instruction and have to add all kinds of checks. Maybe we should support emitting range checks for the right operand though (to give an error if it falls outside the range of shift values whose behaviour is defined). Alternatively, could it be coopted into something useful e.g. a count of the zero bits on the left/right of the operand? -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] New preprocessor directive
Michael Van Canneyt wrote:
Hello,
As you probably know, it is possible to include source filename, line
number, date etc. in your source
with the following directives:
{$I %FILENAME%}
{$I %LINE%}
{$i %DATE%}
At my request, Florian added
{$I %CURRENTROUTINE%}
to the list of possibilities, which means you can do nifty things as:
Entering $main
Entering DoSomething
Doing something in DoSomething at line 44
Entering DoNested
Nested handling in DoNested
Exiting DoNested
Exiting DoSomething
Entering MyMethod
Doing some things in MyMethod at line 61
Entering DoNested
Nested handling in DoNested
Exiting DoNested
Exiting MyMethod
Exiting $main
Useful, thanks.
--
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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC and OpenSXCE/Illumos/Solaris 11
Jonas Maebe wrote: Mark Morgan Lloyd wrote on Wed, 13 May 2015: That particular machine self-destructed, so I don't have an adequate record of what versions of gld/ld were installed. A rebuilt system using the SunFreeware libraries etc. (which are for Solaris 10 rather than 11) appears to be OK, except that SunFreeware binutils installs ld (not gld) in /usr/local/bin which has the result that an older (buggy) version of gld is picked up by FPC before the correct one. Creating symlinks /usr/local/bin/gld etc. appears to fix the problem. You can use the -Xn command line parameter on Solaris to use the native linker instead of the GNU one (FPC 3.x). Thanks, it's one of the things I've already got on my list to check. Somebody added that to the Wiki page, initially as something undocumented. Google suggests that gld 2.19 is known to be broken on Solaris, other versions appear OK; I've modified the script I use for building to log which binary is actually used as announced in -vt output. There's supposed to be a new OpenSXCE build at the end of this month or during June, so I'm holding off any further work until then. There's a whole load of politics/nationalism associated with the project, I'm doing my best to be non-judgemental in the interest of helping to keep the SPARC platform alive. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC and OpenSXCE/Illumos/Solaris 11
Mark Morgan Lloyd wrote: I'm taking a minimal look at OpenSXCE, which is a compilation of Illumos (formerly Open Solaris 11 etc.) for SPARC. I've already got SPARC Solaris 10 running, so am able to see what's different rather than being confused by a completely unfamiliar platform. With a fairly complete installation (i.e. including GNU binutils etc.) and FPC 2.6.4 built on a Solaris 10 system, compiling a trivial program results in /usr/bin/gld:built in linker script:21: syntax error I can see that there's been various discussion of this sort of thing before, with truncated/missing linker scripts being implicated (i.e. it's not really an FPC problem). In this case, it appears that none of the linker script files are being opened, and I find that if I put an explicit -k-T/usr/gnu/sparc-sun-solaris2.11/lib/ldscripts/elf32_sparc.x in /etc/fpc.cfg I can build simple test programs. If anybody understands what's going on, can they confirm that this is an appropriate file to use? Using FPC 2.6.4, if I try building 2.7.1 it runs most of the way through provided that I put the above hack on the command line to accommodate cases where fpc.cfg is not being used. However it eventually fails with /usr/bin/gar: creating libpfpmake.a Linking fpmake /usr/bin/gld: internal error ldlang.c 4884 fpmake.pp(49) Error: Error while linking Can anybody suggest why fpmake is pushing gld into this kind of error, and can it be disabled? (I note that 2.6.4 barfs on fastcgi earlier in the build sequence because the -k-T hasn't been passed through, I presume this has been fixed for 2.7.1.) I was hoping to be able to investigate whether Lazarus would run on this system, since gtk etc. is a much later version than the one with Solaris 10 including more complete Unicode support etc. However in view of the proprietary nature of both Solaris and SPARC I'm not proposing to put much time into it- unless of course the existing problems turn out to be trivial. That particular machine self-destructed, so I don't have an adequate record of what versions of gld/ld were installed. A rebuilt system using the SunFreeware libraries etc. (which are for Solaris 10 rather than 11) appears to be OK, except that SunFreeware binutils installs ld (not gld) in /usr/local/bin which has the result that an older (buggy) version of gld is picked up by FPC before the correct one. Creating symlinks /usr/local/bin/gld etc. appears to fix the problem. I'm currently trying to put some minor updates into http://wiki.lazarus.freepascal.org/Lazarus_on_Solaris in case anybody else is still interested. -- 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/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] FPC and OpenSXCE/Illumos/Solaris 11
I'm taking a minimal look at OpenSXCE, which is a compilation of Illumos (formerly Open Solaris 11 etc.) for SPARC. I've already got SPARC Solaris 10 running, so am able to see what's different rather than being confused by a completely unfamiliar platform. With a fairly complete installation (i.e. including GNU binutils etc.) and FPC 2.6.4 built on a Solaris 10 system, compiling a trivial program results in /usr/bin/gld:built in linker script:21: syntax error I can see that there's been various discussion of this sort of thing before, with truncated/missing linker scripts being implicated (i.e. it's not really an FPC problem). In this case, it appears that none of the linker script files are being opened, and I find that if I put an explicit -k-T/usr/gnu/sparc-sun-solaris2.11/lib/ldscripts/elf32_sparc.x in /etc/fpc.cfg I can build simple test programs. If anybody understands what's going on, can they confirm that this is an appropriate file to use? Using FPC 2.6.4, if I try building 2.7.1 it runs most of the way through provided that I put the above hack on the command line to accommodate cases where fpc.cfg is not being used. However it eventually fails with /usr/bin/gar: creating libpfpmake.a Linking fpmake /usr/bin/gld: internal error ldlang.c 4884 fpmake.pp(49) Error: Error while linking Can anybody suggest why fpmake is pushing gld into this kind of error, and can it be disabled? (I note that 2.6.4 barfs on fastcgi earlier in the build sequence because the -k-T hasn't been passed through, I presume this has been fixed for 2.7.1.) I was hoping to be able to investigate whether Lazarus would run on this system, since gtk etc. is a much later version than the one with Solaris 10 including more complete Unicode support etc. However in view of the proprietary nature of both Solaris and SPARC I'm not proposing to put much time into it- unless of course the existing problems turn out 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC CHM files
Marco van de Voort wrote: Once: - install latex - install tex4ht (nowadays just from package, in the past this was torture) I notice that tex4ht is mandated by various things including OpenWRT, which provides an incentive for mainstream distreaux to get it right. Everytime: - with a full snapshot of FPC available run fpcdocs/fixdocs.sh with the sources of FPC at ../fpc - Switch to lazarus - make sure all xml docs for all units exists. This usually takes most time. - Check location of fpdoc dir in build_lcl_chm.sh it needs to find the generated FPC docs for cross referencing. - run doc/html/build_lcl_chm.sh I wonder if I could ask a related question. A year or so ago I was playing around, trying to see if I could generate a list of which version of FPC gained each function, and trying to generate a permuted index to help answer the how do I FAQs. I ran into various problems which gave me the impression that the raw help file data required the utilities in the matching FPC version: is that reasonable, or should the format from 2.0.0 onwards be absolutely invariant? -- 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/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Testing FPC on PPC Mac
I've got a spare PPC G4 Mac here with OS X 10.4 and possibly 10.5 that for a couple of years has been earmarked for an FPC and possibly Lazarus test system. I believe that I've got Xcode 2.0 on the 10.4 system, if I try running ld gcc or make from a shell I get an appropriate response. I've not fiddled with 10.5 since I believe it's incomplete and there isn't much RAM in the machine. The FPC download from Sourceforge etc. unpacks to include ReadMe.txt, which refers me to http://www.freepascal.org/xcode.html which turns out to be a redirect to http://www.freepascal.org/down/powerpc/macosx.html hence the generic http://sourceforge.net/projects/freepascal/files/ I really don't want to mess this system up since I don't have any OS X experience, don't have installation media, and the chap who gave it me has fled the country (specifically, he was last heard of discovering that his bicycle was incompatible with Brno's tram tracks). Can anybody tell me definitively what else I need, and what I should be doing next? -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Testing FPC on PPC Mac
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: which refers me to http://www.freepascal.org/xcode.html which turns out to be a redirect to http://www.freepascal.org/down/powerpc/macosx.html That's wrong and lands you on an old copy of the site. The central site's pages end on .var (apache translation system) Not /my/ wrong though :-) http://www.freepascal.org/down/powerpc/macosx.var The dutch mirror doesn't run apache and there the html page is still valid and the same as the above .var: http://freepascal.stack.nl/down/powerpc/macosx.html I really don't want to mess this system up since I don't have any OS X experience, don't have installation media, and the chap who gave it me has fled the country (specifically, he was last heard of discovering that his bicycle was incompatible with Brno's tram tracks). Can anybody tell me definitively what else I need, and what I should be doing next? Afaik that's it, binutils+make+gdb from xcode + the installer. Thanks, I'll see where I get to. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Testing FPC on PPC Mac
Mark Morgan Lloyd wrote: Afaik that's it, binutils+make+gdb from xcode + the installer. Thanks, I'll see where I get to. Testing 2.7.1 at revision 29398, compiling with make NOGDB=1 OPT='-V2.6.4 -O- -gl -Xs-' all which has worked for the other architectures I've tried it on, I get /bin/mkdir -p powerpc/units/powerpc-darwin /usr/local/bin/ppcppc -Ur -Xs -O2 -n -Fupowerpc -Fusystems -Fu/usr/local/src/fpc/trunk-2.7.1-29398/rtl/units/powerpc-darwin -Fipowerpc -FE. -FUpowerpc/units/powerpc-darwin -dRELEASE -V2.6.4 -O- -gl -Xs- -dpowerpc -dGDB -dBROWSERLOG -Fuppcgen -Sew pp.pas /usr/bin/ld: unknown flag: -macosx_version_min An error occurred while linking pp.pas(244,13) Error: Error while linking pp.pas(244,13) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted I presume that ld from Xcode 2.0 is slightly too old, and that that flag isn't supported. Is there a way of accommodating this at the command line, or is the only way by finding the flag in the build files and disabling it? [Slightly later] It looks as though it's in the compiler itself, so I'd presumably have to start off with a cross-build or work back to 2.6.0... which is a lot of work for an architecture that I don't really use. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Testing FPC on PPC Mac
Jonas Maebe wrote: On 12 Feb 2015, at 12:17, Mark Morgan Lloyd wrote: I presume that ld from Xcode 2.0 is slightly too old, and that that flag isn't supported. Is there a way of accommodating this at the command line, or is the only way by finding the flag in the build files and disabling it? Install Xcode 2.5, its linker should support that option. For instructions on how to get it: http://stackoverflow.com/questions/1204824/where-can-i-download-xcode-for-mac-os-x-10-4 Thanks for that Jonas, I'll use it as a fallback position but am already making slow progress using -st 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Testing FPC on PPC Mac
Jonas Maebe wrote: On 12 Feb 2015, at 14:13, Mark Morgan Lloyd wrote: Jonas Maebe wrote: On 12 Feb 2015, at 12:17, Mark Morgan Lloyd wrote: I presume that ld from Xcode 2.0 is slightly too old, and that that flag isn't supported. Is there a way of accommodating this at the command line, or is the only way by finding the flag in the build files and disabling it? Install Xcode 2.5, its linker should support that option. For instructions on how to get it: http://stackoverflow.com/questions/1204824/where-can-i-download-xcode-for-mac-os-x-10-4 Thanks for that Jonas, I'll use it as a fallback position but am already making slow progress using -st etc. All FPC Darwin/PPC versions from the past years have only been tested with the Xcode 2.5 tools and hence are also only supported with that version. You may encounter other issues by sticking with an outdated version. No changes will be made to FPC to accomodate for them either, because an upgrade path to a newer version with fixed bugs and required features is readily available (so there is no reason to complicate the compiler to support the older versions as well). Understood, wasn't asking you to. If I can limp along with pre-2.5 on OSX 10.4, I might try putting a newer one on 10.5. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Testing FPC on PPC Mac
Pierre Free Pascal wrote: Hi Mark, you should use -s option for compilation. This will generate a ppas.sh script that contains the call to the linker. Maybe removing this command line option will be enough to fix linking. I hope you will be able to generate a recent Free Pascal Complier on your machine! Already worked some of that out, by reference to the notes I did on building MIPS etc. natively. I've built a fixed 2.6.4 32-bit compiler to make sure that the initial installation is runnable, and a full build of 2.7.1 appears to have got over the initial hump. This is going to take a while since the machine doesn't have much RAM, I want to do as much testing as possible before I open it up in case anything goes wrong. Assuming this works, I hope to try Lazarus. I don't know whether I've got the time to progress to Leopard/10.5 and the 64-bit compiler, but I'd imagine that that's somewhat nearer what other people are testing regularly. Considering other platforms, that leaves 68K on Debian that I was hoping to test but probably won't have time to, and an AMD Athlon which Lazarus doesn't seem to like... again, I assume that somebody's picked any problems up already on such a popular platform. If FPC's -k option can add linker options, wouldn't an option to remove them be useful? I'll probably be back with more problems... -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] SVN checkout errors
Gabor Boros wrote: Hi, When I try to checkout form http://svn.freepascal.org on Windows with TortoiseSVN always got an error at different stage. .. No error with other repositories from other servers. Lazarus CCR, Firebird, etc. I don't know if this is related but I find that the FPC/Lazarus repositories are very sensitive to routing changing in the middle of a checkout. This shows up in particular if working on a system emulated by Qemu etc., making sure that all traffic leaves us over the same line results in a dramatic improvement. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC on SPARC Linux
Mark Morgan Lloyd wrote:
Pierre Free Pascal wrote:
Hi Mark,
did you try to generate the libraries needed to compile FP IDE with
GDB support by
using the script in fpcsrc/packages/gdbint/gen-gdblib-inc.sh ?
If you have a build directory of a certain GDB version (let's say 7.8.1
as an example), simply copy the script over to build-gdb-7.8.1/gdb,
and run
it locally.
This script tries to determine all the libraries needed
and generates a second script called copy-libs.sh
that you should call in turn, with a simple arg, the target directory,
for example, ./copy-libs.sh ~/pas/libgdb-7.8.1
After that,
using make -C ./packages/gdbint GDBLIBDIR=~/pas/libgdb-7.8.1
followed by
make -C ide GDBLIBDIR=~/pas/libgdb-7.8.1
should makes the things much easier.
One caveat is to avoid system installed libraries to be installed
instead of the ones inside this directory.
On systems on which I got this problem, I had to manually
remove all lines {$librarypath XXX}
where XXX resolved to /usr/lib or /lib
I've found where we discussed this before, about August 2013. Part of
the solution at the time was to use -Xd but...
In the hope this will help,
Pierre Muller
Thanks Pierre, I'll investigate. OTOH the existing GDB 6.7.1 libraries
appear sufficient for 2.2.4 through 2.4.4 and for 2.6.4, all on the same
system without any underlying adjustments.
The problem is that there's now a -Xd being put in the internal command
line, without a -Fl for the location of libgcc.a since it's no longer
being picked up from fpc.cfg.
If I add an explicit -Fl/usr/lib/gcc/sparc-linux-gnu/4.4 (or whatever)
to match libgcc.a then fp builds and runs with libgcc, although I've not
tested this aggressively. There was an outdated reference to 4.3.2 in
fpc.cfg which had been moved around between several generations of
machines, this could have affected some earlier builds.
Is there a more appropriate way of doing this than using OPT=-Fl..., and
is having a fixed path for libgcc in fpc.cfg still appropriate?
Noting that the makefile is able to work around the case where it can't
find libgdb, could something similar be done for libgcc? In other words,
a stern warning that something's not right without screwing the entire
build?
I notice that on at least some systems (not limited to SPARC) the libgcc
path in /etc/fpc.cfg is derived from the gcc version info even if this
doesn't match what's on disc, e.g. something like ...linux-gnu/4.3.2
rather than ...linux-gnu/4.3
--
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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC on SPARC Linux
Marco van de Voort wrote: In our previous episode, Joost van der Sluis said: /usr/bin/ld: cannot find -lgcc Install the libc-(devel) package. And your message is not completely clear, does it compile without gdb? (textmode IDE also requires libc via ncurses) It compiles without gdb and appears to run. There are sufficient libraries etc. installed that 2.6.4 compiles and runs, although as I said I've not exercised the debugger. I'd note that 2.7.1 installation still ignores e.g. INSTALL_BINDIR=/usr/local/bin/fpc.d/2.7.1 and insists on clobbering anything in /usr/local/bin, hence the fpc binary from trunk has overwritten the one from 2.6.4 which IMO should not be allowed to happen. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC on SPARC Linux
Joost van der Sluis wrote: On 12/30/2014 07:12 PM, Mark Morgan Lloyd wrote: /usr/bin/ld: cannot find -lgcc Install the libc-(devel) package. And your message is not completely clear, does it compile without gdb? See also the Lazarus-FAQ. Up to date URL please? The version I see is dated 2010 and this is a new problem: 2.6.4 builds and so did 2.7.1 around [checks] 26319 i.e. about a year ago. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC on SPARC Linux
Pierre Free Pascal wrote:
Hi Mark,
did you try to generate the libraries needed
to compile FP IDE with GDB support by
using the script in fpcsrc/packages/gdbint/gen-gdblib-inc.sh ?
If you have a build directory of a certain GDB version (let's say 7.8.1
as an example), simply copy the script over to build-gdb-7.8.1/gdb, and run
it locally.
This script tries to determine all the libraries needed
and generates a second script called copy-libs.sh
that you should call in turn, with a simple arg, the target directory,
for example, ./copy-libs.sh ~/pas/libgdb-7.8.1
After that,
using
make -C ./packages/gdbint GDBLIBDIR=~/pas/libgdb-7.8.1
followed by
make -C ide GDBLIBDIR=~/pas/libgdb-7.8.1
should makes the things much easier.
One caveat is to avoid system installed libraries to
be installed instead of the ones inside this directory.
On systems on which I got this problem, I had to manually
remove all lines {$librarypath XXX}
where XXX resolved to /usr/lib or /lib
In the hope this will help,
Pierre Muller
Thanks Pierre, I'll investigate. OTOH the existing GDB 6.7.1 libraries
appear sufficient for 2.2.4 through 2.4.4 and for 2.6.4, all on the same
system without any underlying adjustments.
--
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/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] FPC on SPARC Linux
whtml.pas whtml.pas(15,2) (2004) Start reading includefile globdir.inc Assembling whtml Compiling wchmhwrap.pas Assembling wchmhwrap Compiling whtmlscn.pas Assembling whtmlscn Assembling whtmlhlp Assembling fpconst Compiling fpusrscr.pas fpusrscr.pas(15,2) (2004) Start reading includefile globdir.inc Assembling fpusrscr Compiling fpswitch.pas Compiling fpvars.pas fpvars.pas(15,2) (2004) Start reading includefile globdir.inc Compiling fpdebug.pas fpdebug.pas(22,2) (2004) Start reading includefile globdir.inc Compiling fpredir.pas Assembling fpredir Compiling fpregs.pas Compiling fpvars.pas fpvars.pas(15,2) (2004) Start reading includefile globdir.inc Compiling fputils.pas Compiling fpvars.pas fpvars.pas(15,2) (2004) Start reading includefile globdir.inc Compiling fpcalc.pas fpcalc.pas(15,2) (2004) Start reading includefile globdir.inc Writing Resource String Table file: fpcalc.rsj Assembling fpcalc Assembling fpvars Assembling fputils Assembling fpregs Compiling fptools.pas fptools.pas(15,2) (2004) Start reading includefile globdir.inc Compiling wini.pas Assembling wini Writing Resource String Table file: fptools.rsj Assembling fptools Compiling fpintf.pas fpintf.pas(15,2) (2004) Start reading includefile globdir.inc Compiling fpcompil.pas fpcompil.pas(15,2) (2004) Start reading includefile globdir.inc Compiling fpsymbol.pas fpsymbol.pas(15,2) (2004) Start reading includefile globdir.inc Compiling fpide.pas fpide.pas(25,2) (2004) Start reading includefile globdir.inc Compiling fpevalw.pas Assembling fpevalw Compiling fpkeys.pas Assembling fpkeys Compiling fpdpansi.pas Assembling fpdpansi Compiling wconsole.pas Assembling wconsole Compiling fpini.pas fpini.pas(18,2) (2004) Start reading includefile globdir.inc Writing Resource String Table file: fpini.rsj Assembling fpini Compiling fpcompil.pas fpcompil.pas(15,2) (2004) Start reading includefile globdir.inc Compiling fpdesk.pas Compiling wresourc.pas Assembling wresourc Compiling fphelp.pas Compiling woahelp.pas Assembling woahelp Compiling wnghelp.pas Assembling wnghelp Compiling wos2help.pas Assembling wos2help Compiling wvphelp.pas Assembling wvphelp Compiling wwinhelp.pas Assembling wwinhelp Assembling fphelp make[2]: *** [all] Error 1 make[1]: *** [ide_all] Error 2 make: *** [build-stamp.sparc-linux] Error 2 Compiling fpcodcmp.pas Assembling fpcodcmp Compiling fpcodtmp.pas Writing Resource String Table file: fpcodtmp.rsj Assembling fpcodtmp Assembling fpdesk Writing Resource String Table file: fpcompil.rsj Assembling fpcompil Compiling fptemplt.pas Assembling fptemplt fpide.pas(1795,2) (2004) Start reading includefile fpmfile.inc fpide.pas(1797,2) (2004) Start reading includefile fpmedit.inc fpide.pas(1799,2) (2004) Start reading includefile fpmsrch.inc fpide.pas(1801,2) (2004) Start reading includefile fpmrun.inc fpide.pas(1803,2) (2004) Start reading includefile fpmcomp.inc fpide.pas(1805,2) (2004) Start reading includefile fpmdebug.inc fpide.pas(1807,2) (2004) Start reading includefile fpmtools.inc fpide.pas(1809,2) (2004) Start reading includefile fpmopts.inc fpide.pas(1811,2) (2004) Start reading includefile fpmwnd.inc fpide.pas(1813,2) (2004) Start reading includefile fpmhelp.inc fpide.pas(1815,2) (2004) Start reading includefile fpmansi.inc Writing Resource String Table file: fpide.rsj Assembling fpide Writing Resource String Table file: fpsymbol.rsj Assembling fpsymbol Assembling fpintf Writing Resource String Table file: fpdebug.rsj Assembling fpdebug Assembling fpswitch Writing Resource String Table file: fpviews.rsj Assembling fpviews Writing Resource String Table file: fpcatch.rsj Assembling fpcatch Writing Resource String Table file: fp.rsj Assembling fp Linking bin/sparc-linux/fp /usr/bin/ld: warning: bin/sparc-linux/link.res contains output sections; did you forget -T? /usr/bin/ld: cannot find -lgcc fp.pas(582) Error: Error while linking fp.pas(582) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[2]: Leaving directory `/usr/local/src/fpc/trunk/ide' make[1]: Leaving directory `/usr/local/src/fpc/trunk' -8- If I build with NOGDB=1 then things are generally OK. 2.6.4 built with libgdb, 2.6.2 and 2.6.0 failed (OK without debugger), older versions generally OK. I'm not at this point able to say which versions I've exercised the debugger with, above is build only. I can live without a debugger, all I'm aiming for at the moment is to have a version of FPC which will work with a fairly recent Lazarus so that I can publish some stuff I've been working on. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] OS/2 and DLLs
Tomas Hajny wrote: On 17 Dec 14, at 15:38, rpzrpz...@gmail.com wrote: Hopefully, FPC core maintainers are not distracted by the legacy support. My philosophy is that supporting multiple platforms- different word sizes, alignment requirements and so on- is a good way to flush out problems. With all the respect to your opinions: If you want to discuss potential reasons for using various operating systems (and/or continuing support of such operating systems in FPC), I suggest that you move that discussion to fpc-other. For now, let's stick to a reminder that the whole FPC is a hobby project. I second that. However I'd add that I do so advisedly: I used OS/2 for quite a few years and I still feel unwell whenever I see it mentioned. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] BOOL
Adriaan van Os wrote: Marco van de Voort wrote: In our previous episode, Adriaan van Os said: reveals 0 for False and -1 for True, where I had expected 0 for False and 1 f according to http://msdn.microsoft.com/en-us/library/eke1xt9y.aspx the same respectively in Visual Studio 2013. There is a C (99?) bool type, and a winapi (and much older) BOOL type. Two different libraries, two different headers, two different cases :-) In old SDKs, BOOL was defined in windef.h, but can't seem to quickly find that in my current 8.1 (that was seriously mangled due to the winrt additions). WIndef.h in the v7.0 WinSDK clearly defines #ifdef TRUE #undef TRUE #endif #define TRUE 1 Afaik BOOL was implemented for winapi benefit, and the boolean* types for pascal booleans (0,1) With a slight health warning in that #undef etc. applies to the C preprocessor which is generally loosely-coupled to the underlying language. There might be cases where this model doesn't apply to Pascal implementations, which typically have integrated handling of compiler directives. I agree that zero and false are generally equivalent, except possibly in the case of unix shell scripts where it gets messy. It's arguably unsafe to ever cast true to a number or enumeration, and possibly the best behaviour would be to ensure that the compiler always handled for b := false to not false do and for b := not false to false do the same. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] BOOL
Mark Morgan Lloyd wrote: I agree that zero and false are generally equivalent, except possibly in the case of unix shell scripts where it gets messy. It's arguably unsafe to ever cast true to a number or enumeration, and possibly the best behaviour would be to ensure that the compiler always handled for b := false to not false do and for b := not false to false do the same. Should obviously have read b := not false to true do Need more caffeine. The salient point is that both give you full coverage of an enumerated type, so it's reasonable to expect every value to be iterated although the order might be undefined. -- 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/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Dynamic codepages etc.
If my understanding is correct, under certain circumstances FPC now considers the dynamic codepage of a string and propagates information across operations. I wonder whether this would be a good time to introduce some form of taint marking, i.e. a flag indicating that a string is of external origin which propagates until a (trusted) function asserts that it's been fully checked? (I've been planning to ask this for a few days, but have just noticed http://hackaday.com/2014/04/04/sql-injection-fools-speed-traps-and-clears-your-record/ which might have been intended as an April Fool joke but still makes a good point.) -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ThousandSeparator
Mattias Gaertner wrote: On Thu, 27 Nov 2014 11:02:06 +0100 Sven Barth pascaldra...@googlemail.com wrote: [...] Yes, there's a message for that and yes on non-Windows OSes this might be problematic... AFAIK on Unix systems you can start each program with a different locale. The system wide locale is just the default on start. Therefore changing the system wide settings should not affect a running application - aka that would be a bug. You can also have completely different desktops etc. (Gnome on one display, KDE on another, a text session on a third), which would be unlikely to use the same notification mechanism. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ThousandSeparator
Sven Barth wrote: On 26.11.2014 16:54, Hans-Peter Diettrich wrote: When the system does not notify all other (running) programs of such an global change, or when some other stupid program doesn't know how to deal with changed settings, the user better shuts down and restarts his system, before and after using that ill behaved program. But exactly *what* should a clever program do, when it receives such a change notification? What should happen with the formatted numbers, shown in the forms of the program? Which code (app/OS?) puts the separators into formatted number strings? At my old company our Delphi application handled runtime changes to these settings rather well. For display the normal XToY (e.g. DateToStr) functions are used which use the DefaultFormatSettings which are updated automatically (the VCL's message loop triggers a repaint when format settings were changed in the system). *This* is how I expect an application to behave (afterall Microsoft's own applications behave this way as well). My recollection is that there's a Windows message that indicates that a control panel applet has changed localisation etc. The lack of anything comparable on other OSes could be a problem, even if user apps and their associated RTLs were happy handling a change. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ThousandSeparator
Marco van de Voort wrote: In our previous episode, Pierre Free Pascal said: I am surprised, for me, as French, I always believed that the French thousand separator is simply a space, what else should it be? A shift space. In utf8 that takes two bytes. How does that look when hand-written on a cheque? -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] CMem allocator memory alignment experiment
Karoly Balogh (Charlie/SGR) wrote: Hi, I think there are several issues with the cmem memory allocator. The main issue that it breaks the underlying malloc() memory alignment, by adding a four/eight byte size value to the start of each block for the sole reason to be able to throw Runtime Error 204 in case someone tries to free a block with the wrong size. At least on Linux, malloc() is documented to align to 64 bit on 32 bit and 128 bit on 64 bit platforms, while this way cmem's GetMem() reduces that to 4 bytes and 8 bytes, respectively. Since cmem is intended for use by FPC, I don't see this as a serious issue unless somebody is exchanging malloc()ed blocks between Pascal and C code. However I'm not saying that it's not worth fixing. This causes multiple performance and other issues, especially on processors which require stricter alignment (most ARM CPUs, but also x86 with SSE, etc). I'm not sure to what extent this remains an issue with current ARM chips. I've got limited ARM hardware, but some tests that I did with somebody else a few months ago didn't show up any issues. It's more of a problem with SPARC particularly on Linux, but that's rapidly going down the tubes as a viable platform- in part because this very issue breaks a lot of stuff and maintainers have neither hardware nor incentive to investigate. Perhaps the most serious scenario is where an architecture or particular implementation requires alignment, but the kernel traps alignment errors and fixes them silently. SPARC Solaris does this and my understanding is that it introduces a very significant performance overhead; ARM Linux may also do it (where demanded by the hardware) but my understanding is that notifications can be enabled. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] CMem allocator memory alignment experiment
Karoly Balogh (Charlie/SGR) wrote: Perhaps the most serious scenario is where an architecture or particular implementation requires alignment, but the kernel traps alignment errors and fixes them silently. SPARC Solaris does this and my understanding is that it introduces a very significant performance overhead; Linux also does this. On some but by no means all platforms. I'm specifically trying to highlight the fact that on SPARC, Solaris can fix alignment issues (at a price) but Linux doesn't try to. I don't know to what extent there are comparable issues on other platforms (in particular x86_64) for which both Solaris and Linux are implemented. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] CMem allocator memory alignment experiment
Marco van de Voort wrote: Since cmem is documented to be used from the main program file (iow the users code), that would nicely put the responsibility there. That might be where it's imported, but it's heavily used by just about everything when non-scalar types are being shared between a dynamically-loaded library (DLL or so) and the main 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] CMem allocator memory alignment experiment
Sergei Gorelkin wrote: 19.11.2014 15:16, Marco van de Voort ?: In our previous episode, Mark Morgan Lloyd said: introduces a very significant performance overhead; Linux also does this. On some but by no means all platforms. I'm specifically trying to highlight the fact that on SPARC, Solaris can fix alignment issues (at a price) but Linux doesn't try to. I don't know to what extent there are comparable issues on other platforms (in particular x86_64) for which both Solaris and Linux are implemented. On PPC (603), Linux did, but netbsd didn't :-) Though that is 1.9.0 times experience and thus slightly dated. On mips-linux, I observe no crashes when doing unaligned access with integer instructions, but it still crashes upon unaligned access using floating-point instructions. Sergei Useful to know. I've never tried this, but presumably the signal can be trapped? -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] PostgreSQL SQLdb transactions
Michael Van Canneyt wrote: On Tue, 4 Nov 2014, Chris Dryburgh wrote: Hi In PostgreSQL it is considered poor practice to have long running idle transactions. https://encrypted.google.com/#q=postgresql+idle+in+transaction This is a known problem, not only for postgres. The problem is the open transaction for an open dataset: committing the transaction (what you would normally do) will close the dataset. The solution for which I have code in place is a flag which tells the transaction that a connected dataset should not be closed when the transaction is committed. The transaction can then be committed or rollbacked as soon as the data is fetched. I have code for this in place that works for all connection types. But it still needs to be checked through the testsuite. Sounds good. The bottom line is that the Delphi model where db controls hold a connection etc. open for an extended period is not a good fit on top of a database server which implements connection pools etc. Another issue is that once a connection has been established to a named server, there's a single point of failure if it tries to reopen it but finds that the nameserver is unavailable. A facility to temporarily cache the IP address, or possibly an application-supplied list of pool names/addresses, would be useful. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] VMS Pascal Compiler mode
Richard Apthorp wrote: Hi Sven, Actually found that HP have a documented list: http://h71000.www7.hp.com/doc/82final/6083/6083pro_032.html#extensions_app I'm not sure I feel qualified to change the compiler but as I work on this porting project I will be creating a list of the main changes which I could then decide if beneficial to create a new compiler mode for (with a lot of help I hope!!!) Thanks again for your advice, Richard. One useful thing might be to create a test case for each extension as you find that FPC (in the default mode ** ) doesn't handle it, and to submit it as a bug for discussion. That would enable all the tentative VMS mode activity to be at least cross-linked. I see from your reference that the compiler extends ANSI/ISO Pascal, but there's no indication of whether, when it was written, it was based on Jensen Wirth or the somewhat later ISO standard. Was it written from scratch, or was it initially based on something like the P6 compiler which I believe was on some DEC systems? ** Anybody: what's the state of the -Miso mode? I don't see it in the -h output. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] VMS Pascal Compiler mode
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: I see from your reference that the compiler extends ANSI/ISO Pascal, but there's no indication of whether, when it was written, it was based on Jensen Wirth or the somewhat later ISO standard. Was it written from scratch, or was it initially based on something like the P6 compiler which I believe was on some DEC systems? The page he referenced lists extensions to both standard and extended pascal. So it seems it is an extended pascal compiler. Yes, but extended from /what/? Not having- as a particular example- P6 documentation, that list could describe something like the extensions that P6 has relative to ISO plus a set of extensions on top of P6. ** Anybody: what's the state of the -Miso mode? I don't see it in the -h output. Getting fairly close for standard pascal, no extended pascal. In that case somebody ought to check that it appears in -h output. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpcmkcfg invocation for two versions (linux)
Marco van de Voort wrote: In our previous episode, Gennadiy Poryev said: I've got two FPC versions installed on my Linux x64 box: 2.6.4 as a bootstrap and 2.7.1 for building Lazarus. Both were installed through 'make zipinstall' from svn and untaring to /usr, hence they reside under /usr/lib64/fpc/2.6.4/ and /usr/lib64/fpc/2.7.1/ accordingly. The switching is done by force-resymlinking /usr/bin/ppcx64 to the correct ppcx64 in their corresponding locations so that /usr/bin/fpc may invoke needed binary. Now Lazarus does not build, complaining about RegisterFCL and I know this is because of missing fpc.cfg. What is the proper way of generating fpc.cfg in such case? I'm particularly concerned about how do define 'basepath'. I did that on Windows easily since bin directory was also located under version directory, which is not the case in Linux. A solution for the ppc* binary is to make a symlink for one of the binaries (typically trunk) to ppx64-2.7.1, and to call fpc with -P2.7.1 This still assumes 2.6.x and 2.7.x can use the same fpc binaries, and is no solution for the rest. I'm not up to date on trunk, but so far using the most-recent fpc seems compatible with all of 2.2.4 through 2.6.x on multiple native platforms. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] creating the embedded port of fpc
Sietse Achterop wrote: On 10/12/2014 10:54 AM, Mark Morgan Lloyd wrote: Sietse Achterop wrote: Dear list, I try to get the embedded port of fpc (for both lcp1728 and stm32f4) to work but fail. I use the info on http://wiki.freepascal.org/TARGET_Embedded but immediate get: make[1]: -iVSPTPSOTO: Command not found . export PP= make clean all Ok, thanks. I now see that you need the hosts fpc to create the embedded version. I assumed only gcc was needed. GCC doesn't enter into the picture at all, the documentation states explicitly that FPC is self-hosted. All you need is the appropriate binutils, which you might end up needing to compile yourself. Way back I put some stuff at http://wiki.lazarus.freepascal.org/Native_MIPS_Systems#Mainline_MIPS_Port which might still be useful. The given make-command only works as root, so i use a INSTALL_PREFIX: make clean buildbase installbase INSTALL_PREFIX=/home/sietse CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv7m This works ok. You should be able to do everything except the final install as a non-privileged user. But the command fpc -Parm -Tembedded -Wplpc1768 -Cparmv7m tled1.pp gives: Error: ppcarm can't be executed, error message: Failed to execute ppcarm, error code: 127 After the make install operation, you might need to set up a symlink for ppcarm. or use PP as before. As before, all subject to comments from anybody who knows what he's doing. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Michael Schnell wrote: IMHO it usually is better to first decide if you want to drink tea or bear before you run to the fridge or to the cupboard. That could be a fatal error, even if permitted by the parser :-) -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Michael Schnell wrote: Something like this to do a matrix multiplication At the moment the only point I am making is this. Assuming a thread pool which can be applied to a parallel activity, it might be desirable to only use that from a single app-level thread. Hence (using your syntax only for consistency): serial for i := 0 to m-1 do begin parallel for j = 0 to n-1 do begin .. end; end; to ensure that the inner loop is parallelised to the greatest possible extent, but that the outer loop is protected from reentry. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Hans-Peter Diettrich wrote: Mark Morgan Lloyd schrieb: Boian Mitov wrote: I think parallel processing belongs in library implementations. I have reservations, based in part on the fact that other language implementations are prepared to assume responsibility for parallelisation, in part on experience with e.g. APL which at the very least specifies that the user should assume that operations are parallelised, and in part on the fact that FPC already vectorises on e.g. SSE2 hardware. What do you (both) mean by parallel processing? I'd suggest that http://wiki.lazarus.freepascal.org/OpenMP_support and related pages is an adequate answer; alternatively see http://www.elementswiki.com/en/Parallel_For_Loops. However the point I'm really trying to make is that IMO before anybody seriously considers adding any form of parallelisation at the language level they should add serialisation (i.e. comparable with a Brinch Hansen monitor etc.). Streaming (SSE...) does *vectoring*, i.e. multiple (floating point) operands of the same *array* are processed in parallel. Such cases can be handled by the compiler, no libraries are involved, no threads, no risk of side-effects. I'm thoroughly aware of the distinction. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Michael Schnell wrote:
On 09/25/2014 07:27 PM, Boian Mitov wrote:
What I am saying is that the parallel loop handles only one specific
case of parallelization, and with limited options.
A library implementation on the other hand offers full flexibility.
Of course I did understand that.
What I was saying that providing a parallel loop syntax candy to make
the library functions more easily usable in standard cases is (nothing
but) an additional benefit, but very helpful for many users..
A parallel loop syntax is very attractive, but the practical difficulty
is that it would probably have to sit on top of threads and getting code
distributed promptly over multiple worker threads, i.e. starting up
within 10s of nSec rather than 10s of mSec, is non-trivial.
I still think that a prerequisite is something that can enforce
sequential operation, so that a paralleled block could not be reentered:
procedure Sub (var x : array of Float); sequential;
procedure ParallelBlock; parallel;
begin
end {ParallelBlock};
begin
ParallelBlock;
end {Sub};
I suppose an interesting challenge, bearing in mind your earlier
question about signals, is whether procedure or block modifiers can be
declared as part of the language but implemented as replaceable runtimes.
--
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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Michael Schnell wrote: On 09/26/2014 05:31 PM, Mark Morgan Lloyd wrote: . A parallel loop syntax is very attractive, but the practical difficulty is that it would probably have to sit on top of threads and getting code distributed promptly over multiple worker threads, i.e. starting up within 10s of nSec rather than 10s of mSec, is non-trivial. Starting a new thread of course is too expensive for something like that. I agree, and I don't think there's a lighter-weight alternative. IMHO, the RTL could be provided with a ThreadPool implementation (I just did such a thingy and it seems to work nicely). Different implementations could potentially use either local threads or OpenMPI. Same could be accessible by the user for more complex stuff and be used as the infrastructure of a parallel loop syntax. Agreed, but a good starting point would be working out how to map a sequential (non-reentrant) block syntax onto e.g. the existing critical section class. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
Boian Mitov wrote: See... this is the point. In order to properly implement parallel loops etc. even in their limited form the compiler needs specific RTL support. So we break one of the basic principles that the compiler is the root, and the RTL is a library compiled in it. Once you start getting the compiler to depend on RTL implementation, you start to get in troubles IMHO. The compiler already depends heavily on the RTL for e.g. string and dynamic array handling. If a string or a dynamic array is already a first-class construct, why shouldn't a foreach be? I think parallel processing belongs in library implementations. I have reservations, based in part on the fact that other language implementations are prepared to assume responsibility for parallelisation, in part on experience with e.g. APL which at the very least specifies that the user should assume that operations are parallelised, and in part on the fact that FPC already vectorises on e.g. SSE2 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS big-endian program starts but does nothing
Sven Barth wrote: On 08.09.2014 22:54, Michael Ring wrote: This smells like a problem I had on pic32. In my case the pic32 chips do not have a floating point unit and the processor creates an illegal instruction (or something similar) exception. I solved this for me by patching out the call to the hardware coprocessor when softfpu is selected. Which should be the correct approach for softfpu anyway. Afterall the premise of softfpu is that there is no hardware FPU to use and thus corresponding CPU instructions are useless (or as it seems in this case lead to nothing). I was wondering whether a completely empty program would be a better test than a Hello, World!. Could a completely empty program be recognised by the compiler etc. as a special case and built with only minimal RTL initialisation, specifically as a test that a program will load and terminate in good order i.e. that FPC and the OS are compatible? Or is there a set of portable options that will already do this, which could be documented prominently? After all, there's been comparable issues on ARM, and there might be more on various platforms in the future. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS big-endian program starts but does nothing
Tomas Hajny wrote: On Tue, September 9, 2014 10:20, Mark Morgan Lloyd wrote: . . I was wondering whether a completely empty program would be a better test than a Hello, World!. Could a completely empty program be recognised by the compiler etc. as a special case and built with only minimal RTL initialisation, specifically as a test that a program will load and terminate in good order i.e. that FPC and the OS are compatible? Or is there a set of portable options that will already do this, which could be documented prominently? After all, there's been comparable issues on ARM, and there might be more on various platforms in the future. Isn't there a risk that behaviour of a program not doing anything might look the same as behaviour of a program failing/crashing before doing what it was asked to do? In addition, what is the supposed difference between an empty program and program built with only minimal RTL initialisation? I don't see why something like this program test; begin end. should use anything other than the absolute minimum that's needed to terminate in good order. At that point gdb (or strace etc.) should be able to confirm that it's terminated rather than crashing, and that would be useful confirmation that as far as the OS and system libraries were concerned the binary format (ELF header etc.) was OK. After all, when this sort of problem has been raised in the past we've usually started off by scratching our heads over whether the user had somehow screwed the file, or had built it with the wrong endianness or for an inappropriate CPU. It would be useful to be able to eliminate some of these possible conditions. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS big-endian program starts but does nothing
Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: In addition, what is the supposed difference between an empty program and program built with only minimal RTL initialisation? I don't see why something like this program test; begin end. should use anything other than the absolute minimum that's needed to terminate in good order. Well, first you must realize that that program is equal to program test; Uses System; begin FPC_INITIALIZEUNITS; // nothing FPC_FINALIZEUNITS; end. The FPC_* routines walk tables and call the all units' initialization and finalization sections. In this case System's. Your observation reduces to letting the compiler figuring out that in the system unit initialization the FPU Initialization can be safely skipped, and that possible state (like the FPU control word) is not important. This is nearly impossible. In fairness, my original question was Could a completely empty program be recognised by the compiler etc. as a special case. So what you're saying- entirely fairly- is that because of the Uses System the problem is probably intractable. But could the Uses system be omitted or replaced by a simpler stub if the program was recognised 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS big-endian program starts but does nothing
Reinier Olislagers wrote: Hi, Periodically I try to cross-compile a simple program [1] for my router with fpc trunk. It starts but does nothing (does not return to command prompt). Noticed an earlier mail from Dennis Poon where he described the same behaviour. I think the previous discussion wound down with the consensus that the distro had custom libraries, possibly derived from ulibc, and that the compiler etc. would have to be specially built for those. I was hoping to set a Qemu-based system to investigate, but didn't get anywhere due to other commitments. -- 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MIPS big-endian program starts but does nothing
Reinier Olislagers wrote: On 06/09/2014 12:20, Mark Morgan Lloyd wrote: I think the previous discussion wound down with the consensus that the distro had custom libraries, possibly derived from ulibc, and that the compiler etc. would have to be specially built for those. I was hoping to set a Qemu-based system to investigate, but didn't get anywhere due to other commitments. Ok. It's running openwrt (also so that may well be the case; however I copied over [1] the libs [2] from the device to my desktop, so that should be a step in the right direction but presumably I need to match the cross binutils [3] ld with the uclibc ld one?!? This might be completely unhelpful, but I'll post it anyway just in case it's perversely relevant. I had FPC running on SPARC under Solaris 10, and investigated getting it running on Solaris 8. The problem turned out to be that a system library (let's say it was libc.so, but I'm working from memory) was symlinked to libc.so.2 on Solaris 10 but libc.so.1 on Solaris 8, and the linking stage was resolving the symlink rather than leaving it until the program was run. In the end I did something like copying libc.so.2 to libc.so.1 and changing libc.so to point to the latter. I built FPC (possibly just ppcsparc) and copied that to the v8 system, then restored the original symlink. At that point FPC ran OK on 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/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Slightly off-topic]Mark Morgan Lloyd: Burroughs emulator
Reinier Olislagers wrote: Hi Mark ( all), Just wanted to know how you're doing with that conversion of the Javascript Burroughs B5500 emulator that you said you were looking at... Wonder if you have interesting stories about performance to tell us ;) Noting obviously that I'm not the prime mover of this, and that I'm mainly transcribing code from Javascript to Pascal to run on unix. As background: the B5x00 was an early-60s design using transistors and diodes rather than valves, assembled as modules and plugged into a wire-wrapped backplane (which, incidentally, is why I was digging for info on the Lawrence Livermore S-1 computer a couple of weeks ago, hence the Stallman comment I posted elsewhere). The B5000 was drum based, the B5500 used discs (/big/ discs), and the B5700 could cluster up to 4x systems around shared disc. Later machines had 2x CPUs, with one mainly handling the operating system and the other devoted to user code. These three machines were not code-compatible with the later B6xxx or B7xxx range, or with the B5900. The operating system was written in an ALGOL derivative, with fairly heavy use of embedded assembler. The frequently-repeated statement that these machines were programmed entirely in ALGOL and that there was no assembler is a simplification. Dijkstra liked them, Knuth and Wirth used them on occasion; Gary Kildall was involved in writing an APL interpreter at IIRC Washington. I'm starting off with a command-line driven variant, i.e. there's no GUI and controls are simulated by typed-in commands using a parser I wrote for something else. I've transcribed the CPU, central control and IOPs, and am currently working on I/O devices starting off with the SPO (Supervisory Printer Output) and card readers/punch. Importantly, as I go I'm adding a fairly extensive set of test/debug commands. I'm hoping to later put together a GUI using Lazarus, and to allow symbolic debugging of the operating system etc. by transferring compiler output listings from the emulated environment to the host. But I'm a long way from that stage. I've got to the point where I can enter a 48-bit I/O descriptor at which point the first free IOP's thread spins once to e.g. read a card into memory. I'm currently tidying up the code but at this time of year I've got a lot of other demands on my time which are causing problems. I'm not sure whether to tackle more I/O devices next (tape or disc), or to start debugging the CPUs mow that I can read a loader deck into memory. I'm hoping to be able eventually to get a cluster running, i.e. 4x twin-CPU systems sharing common disc. Good old mid-60s technology ;-) I'm also hoping to be able to support e.g. non-standard tape formats by loading shared libraries, rather than hardcoding them. There's a number of projects that emulate mainframes from the 7-track tape era, but like the original systems they're very poor at reading each others media. In the longer term, it would be nice to get a Pascal compiler running (there's a listing on Bitsavers). However that would probably need a lot of typing, which takes me back to a large-scale collaborative project that's something else I'm trying to work on. And which is, as they say, yet another story. -- 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/cgi-bin/mailman/listinfo/fpc-devel
