Re: [fpc-devel] 68k question
Hi, On Mon, 21 Dec 2020, J. Gareth Moreton via fpc-devel wrote: > That should be fine - thanks Marcus. I need to reproduce the internal > error that's being reported, and so I can compare the disassembly of > ppcross68k to see where my optimisation is going wrong. To bould any cross compiler, you don't even need the assembler for that particular platform, and you don't need to disassemble, you can just ask the compiler to generate an assembly source for you instead. Here's how I'd build in this case: make crossall CPU_TARGET=m68k OS_TARGET=amiga OPT="-al" CROSSOPT="-al -sh" The OPT="-al" part will make sure that an external assembler is used to generate the crosscompiler assembly sources, and the compiler source lines are intermixed as comments with the generated assembly. Then resulting files will be placed in compiler/m68k/units/*.s The code for the particular IE you're looking for will be in compiler/m68k/units/cgcpu.s, but of course it's possible the wrong code is not there, but somewhere where this function is called from, or in optimize_op_const() which is called right before that IE occurs. You'll probably need Windows binutils to compile the compiler like this, because the use of the internal assembler is omitted. But I find this much more useful than digging into disassemblies... Then CROSSOPT="-al -sh" is for triggering the crosscompiler part, "-al" will make sure again, that assembly sources are generated, and "-sh" will skip the assembling (and potentially linking, but that's not used for this particular build) for the target platform, which means you won't need any external utilities for the target platform. The generated m68k assembly files will be in rtl/units/m68k-amiga, and in the respective packages directories. Cheers, -- Charlie___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Issue with Compiling FPC and MacOS Big Sur
Hi, On Sun, 15 Nov 2020, Jonas Maebe via fpc-devel wrote: > On 15/11/2020 15:19, Karoly Balogh (Charlie/SGR) via fpc-devel wrote: > > > > Yes, I already had to dothis in my build scripts on Mojave. I defined an > > "FIXMOJAVE" environment var, which contains that -XR/Library/... path you > > wrote above, and in all my build scripts I just do: > > > > make OS_TARGET=foo CPU_TARGET=bar OPT="-other -args $FIXMOJAVE" CROSSOPT=... > > I also have macOS 10.14 (Mojave) and I don't need to specify any special > options when building FPC. All libraries and object files are still > available under /usr there, so I have no idea why it would be necessary > in your case. Me neither, but it's been like that ever since I upgrade to Mojave, that these libs and objects are no longer in /usr/lib on my system. I used Sierra on the same machine before, and that worked, then I updated to Mojave and some then-recent XCode/command line utilities in one go (without reinstall), and then the files were gone, I had to add this extra argument to my FPC builds, otherwise things just didn't work. But as I don't really develop native software on my Mac, only use to crosscompile various versions of FPC, I never investigated further, it was goon enough for me. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Issue with Compiling FPC and MacOS Big Sur
Hi, On Sun, 15 Nov 2020, Jonas Maebe via fpc-devel wrote: > > my Macs that the timestamp of that file changed), but this will not help > > for compiling the compiler as the compiler is beeing compiled with the > > flag -n which effectively turns off reading /etc/fpc.cfg. > > Indeed, I glossed over the fact that you were rebuilding FPC. > > > make clean all > > OPT="-Fl/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib > > -Ff/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks" > > You should use the -XR parameter > (-XR/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk) instead of > -Fl/Ff in this situation. Yes, I already had to dothis in my build scripts on Mojave. I defined an "FIXMOJAVE" environment var, which contains that -XR/Library/... path you wrote above, and in all my build scripts I just do: make OS_TARGET=foo CPU_TARGET=bar OPT="-other -args $FIXMOJAVE" CROSSOPT=... It's not the most convenient thing, but it works. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc trunk / parentfp for debugger / missing
Hi, On Sat, 20 Jun 2020, Yuriy Sydorov wrote: > I've added the generic cs_opt_unused_para optimization option. > In future, if needed, more fine-grained related options can be introduced. > > So now the parentfp optimization is enabled for -O2 and higher. Yuriy, your changes seem to have broken ppdump.pp. For all platforms. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC and Z80
Hi, On Mon, 27 Apr 2020, Sven Barth via fpc-devel wrote: >> Well, I'm surprised and impressed you got it to work at all... >> Quite an achievement. > > Considering that we already support AVR as well I was rather confident > here. :D Maybe in the future we can also add GameBoy support which uses > some Z80/8080 hybrid? ^^' I have no idea, but quickly read through some docs, and it seems the GameBoy CPU doesn't have IX/IY registers, which seems to be very useful to implement some of the more complex references handling, according to what Nikolay wrote earlier. Also, it seems to be quite a few stuff missing from it, as well as it has some extras. The question is, how far it diverges from Z80 of course, and how that might violate some basic assumptions the Z80 CG currently does about the ISA. >> I suppose FPC is now probably the compiler working for the biggest >> number of CPUs/OSes - if it wasn't already. (C excepted, probably) > > After GCC I'd assume that, too :) GCC doesn't have most of what it supports mainline, rather in an independenly maintained fork, plus the C library is not included in its tree. So as far as "out of box" solutions go, FPC is quite up there. Charlie___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changes in wiki?
Hi, On Fri, 29 Nov 2019, Werner Pamler wrote: > Who takes care of the wiki software? There is another issue that it is > not possible any more to replace existing uploaded images by new > versions (at least when I tried the last time, some weeks ago). It's me. And I know. I spent today 3 hours again trying to debug it, upgrading/downgrading versions left and right, doing all sorts of DB magic, trying to wave a dead chicken above an upside down pentagramm drawn with black goat blood upon full moon, but to no avail. Because of course a normal Googling doesn't reveal anything, except FPC people asking about this issue on all possible forums. And today I came to the conclusion - again -, that my life is not long enough to debug that pile of PHP garbage, sorry. But as always, ideas and suggestions welcomed. What's for sure, it's not a file/directory simple permission or misconfiguration issue. But probably a genunine bug somewhere. According to some ancient - probably only slightly related - MediaWiki bugtracker entries, it could be in one of the extensions we use. Which are only a handful, actually. No idea. But I failed even enabling some sane debug logging for the Wiki. Like, I follow the manual, expect a debug log to happen, but literally nothing. (Additional funfact: the manual claims some variable to be used for DB debugging, but when I visit that variable's description page, it was removed 5+ versions ago. Yeah.) And without even that, every attempt is just poking into a black hole with a stick. Rant aside, if you ignore that Error message, the "fun" part is, uploading new versions of a file actually seem to work for me. You still get the error, but then when you reload the file, the new content is there. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
Hi, On Sat, 15 Jun 2019, J. Gareth Moreton wrote: > Ryan Joseph requested that I reply to this to show that it's in the > mailing list. Hopefully the technical problems can be resolved! There was an issue affecting GMail users, and GMail's SMTP servers over IPv6. This has been resolved by now. (By disabling IPv6, which is somehow always the easiest solution for IPv6 problems...) Charlie___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Core] Haiku merges: Revision 42117
Hi, On Mon, 27 May 2019, Pierre Muller wrote: > The merge of the two commits generate 3 conflicts, but those are easily > solved. > See attached patch. > > Olivier, did you test the fixes_3_2 branch? > Do you think it is reasonable to enable x86_64-haiku target in that branch? I think if all the changes are merged, it's safe to enable at least, but it needs to be tested of course. I only tested trunk. > charlie, you wrote those patches, thus > it is probably best if you or Olivier decide: > Should I merge them? I think they should be merged, but Olivier is the maintainer. But as the RTL changes are merged already (Marco did it after asking me), I think the associated compiler changes should be merged too. I'm unaware of any Haiku regressions compared to before my changes, OTOH after my changes the entire thing is much cleaner and of course supports x86_64 as well. If anyone is aware of any regression, I'm gladly fixing them ASAP both in trunk and then it can be merged to 3.2 as well. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packed record integers and x86_86
Hi, On Thu, 28 Mar 2019, J. Gareth Moreton wrote: > I think the official unsigned 32-bit integer type in Pascal is > "LongWord". As others have said, be aware that pointers are 64-bit under > x64... that's kind of why it's called x64! If you absolutely must have > a packed record with 32-bit types, I recommend changing Sender and > Target to indices that are added to a base address. > > Similar to what Pierre said, change your Pointer code to something like > this: > > for Indx := 0 to SizeOf(TTCPPackageHeader) - 1 do > Dec(Byte(Pointer(PtrUInt(@x) + Indx)^), ARollCount); How about Dec(PByte(@x)[Indx], ARollCount); instead? That doesn't look like an angry C programmer tried to convert some abomination to Pascal, and works on all pointer sizes. (Unless it also has to compile with say, Delphi.) Charlie___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).
Hi On Fri, 11 Jan 2019, Pierre Muller wrote: > > Make cycle works fine as of current trunk, however "make all" causes a > > KDL, unless you disable fcl-process usage in fpmake. See this patch: > > I already managed to generate a snapshot: > > ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/x86_64-haiku/fpc-3.3.1.x86_64-haiku.tar.gz > > generated yesterday. Oh, nice! Did you also ran into this x86_64 KDL (kernel entering debugger mode) during packages build, or it's a crosscompiled snapshot? If we're about to stuck with a given snapshot for a while, can you re-make the snapshot with today's SVN r40485 or later? That has working stacktraces on signals (i.e. SIGSEGV) and working lineinfo (also for i386 which was also broken before, at least it doesn't work in the 3.0.4 release). Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).
Hi Olivier, On Fri, 11 Jan 2019, Olivier Coursière via fpc-devel wrote: > > It would be nice to also get regular testsuite results for Haiku OS! > I have tested VM automation with vagrant and i should be able to > automate something to launch and upload the result in one click. And > maybe for x86_64 once i have a binary to bootstrap the compiler. I have uploaded a native x86_64 Haiku FPC binary, built from svn r40845: http://charlie.amigaspirit.hu/temp/private/ppcx64-haiku-boot Make cycle works fine as of current trunk, however "make all" causes a KDL, unless you disable fcl-process usage in fpmake. See this patch: http://charlie.amigaspirit.hu/temp/private/haiku_fpmkunit_disable_fcl-process.patch Also see Haiku Trac #14802. Charlie___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Haiku/x86-64 (Was: Proposal to adapt search patch under Haiku using a target specific option (-WH).)
Hi, On Fri, 4 Jan 2019, Olivier Coursière via fpc-devel wrote: > > There seems to be something wrong with the signal setup so strace is > > used to hide a fatal error... Also file handling doesn't really work > > now. But even to get to this level in a few hours was nice. > For signal handling, my bet would be a problem in declarations of types > used in the API. A quick check indicate that i have overlooked some > architecture specific declarations in signal.inc. Some parts should be > in a sighndh.inc in an arch specific directory. It was not a problem > until now ;-) Well, indeed this was the case. packed records are not the way to go when interfacing with C code, to say the least, but there were other minor bits as well. As of r40764, the 64bit compiler works. (Well, it can compile a "hello, world!" to a working executable at least, make cycle I haven't tested yet.) Lets hope I did not break 32bit in the process... :] > Maybe there is a similar problem for file access functions. Yes, the usual problem with BSD/Unix ports, the stat and dirent records were out of alignment for 64bit. Lets hope I managed to fully fix it... I think I'm going to progress towards moving also the 32bit RTL to the Pascal sysinit/startup functions and making sure make cycle works on both versions. Then lets figure out what to do with that GCC 4 path patch, which I also don't really like TBH... But we'll see. After that it's back to you, probably. :) Cheers, -- Charlie___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Haiku/x86-64 (Was: Proposal to adapt search patch under Haiku using a target specific option (-WH).)
Hi, On Wed, 2 Jan 2019, Karoly Balogh (Charlie/SGR) wrote: > > - port/fix to 64bit > > > > With the already proposed changes to simplify the initialization part, > > it is probably "just" a matter of : > > (...) > > Yup, that list sums it up. Also I'm not sure the do_syscall code is still > used in Haiku RTL at this point, but if yes, it needs to be adapted to > 64bit too. (Or remove if not needed.) It turned out, it wasn't needed. So I made a really quick hack this morning, and now FPC builds for and semi-works on Haiku/x86_64... Screenshot: https://twitter.com/chainq/status/1080826380466696192 There seems to be something wrong with the signal setup so strace is used to hide a fatal error... Also file handling doesn't really work now. But even to get to this level in a few hours was nice. The patch is of course still a bit of a mess, especially the RTL part, but I can commit the "trivial" parts of it to SVN, if you have nothing against it? Like adding the target to the compiler at least. (This question is to Olivier primarily, as he's the Haiku maintainer.) Cheers, -- Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).
Hi, On Wed, 2 Jan 2019, Olivier Coursière wrote: >> Should linking without libc (as in, libroot) be supported? > I have only maintained the libc/libroot part since the beginning of > Haiku port ten years ago. Well, we do have other libc-only ports, like the macOS/Darwin version. It's best to remove it then. That code looks really old anyway, and not made with the current compiler in mind when it comes to asm capabilities for example, so if anyone wants it, probably best to re-add from scratch. (Which actually leads us to the question of BeOS port, I'm not sure if there's interest to bring it up to speed again in any way.) >> - see the legacy comments in si_c.pp and si_dllc.pp and figure out what >> to do with those. (Probably only needed to support BeOS, but not >> Haiku?) > > This comment on a Haiku's commit might help you in that area : > https://git.haiku-os.org/haiku/log/?id=22ca923f71dd2d59d7f314d186801acb50524106&showmsg=1&qt=grep&q=23975 > > "BeOS R5's glue code incorrectly calls _thread_do_exit_notification() Yeah, I was already suspecting something like this, after looking into the libc exit code, thanks. The exit notification stuff can be remove then. (Now that it's in Pascal, it's quite easy! :) > - clean up the old linker support > > I don't know what you mean here. fpc currently use Haiku's ld under Haiku. I mean the linker code still aims to support non-libc linking, which is a bit confusing. If no one has worked on it for 10 years and known to be broken, and no benefits to fix it, maybe it's time to remove it. :) > - move to a "buildrtl" system for easier future maintenance > > It is simple enough for me so far at the current rate (a few commits a > year in the Haiku area). But if it could be easier, shared and > consistent with other platforms, + 1 ! Well, it makes the bulk of the RTL a bit easier to rebuild with Lazarus at least, and a tiny bit faster from the command line, because it only makes one compiler invocation from then on for most of the units. But not all platforms use it, so it's up to the platform's maintainer to decide. :) > - port/fix to 64bit > > With the already proposed changes to simplify the initialization part, > it is probably "just" a matter of : > (...) Yup, that list sums it up. Also I'm not sure the do_syscall code is still used in Haiku RTL at this point, but if yes, it needs to be adapted to 64bit too. (Or remove if not needed.) Cheers, -- Charlie___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).
Hi, On Tue, 1 Jan 2019, Karoly Balogh (Charlie/SGR) wrote: > (Not sure if Olivier is on the list, so keep cc:-ing him...) > > So, bottom line, see the following patch: > > http://charlie.amigaspirit.hu/temp/private/haiku_pascal_sysinit.patch I have updated the patch. The exitcode/haltproc handling was incorrect in the previous version. > Completely untested, because see above, but it compiles at least... %) make cycle of current trunk works with it now, at least on a VirtualBox'd Haiku, using the 3.0.4 release as bootstrap. I did not test the library version of the startup though. Do you have a good testcase for that? Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).
Hi, (Not sure if Olivier is on the list, so keep cc:-ing him...) On Mon, 31 Dec 2018, Karoly Balogh (Charlie/SGR) wrote: > > Not really. I have investigated what need to be done for x86-64 port but > > the assembly part (cprt0.as) was enough to dissuade me so far ;-) Other > > CPUs will require a working kernel first ;-) Help is welcome though, on > > both sides... > > At this point it really should be possible to write all/most of the > startup code in Pascal. I looked into it quickly, and it's actually pretty > simple, there doesn't seem to be anything really in the i386 startup code > at least which might be impossible to tackle in a Pascal version. Ok, so looked into the Haiku port a bit. Should linking without libc (as in, libroot) be supported? So far, the RTL seems to depend on linking against libc/libroot, but I'm not sure what was the intention originally, as there seems to be larger bits of unfinished direct syscall code as well. Same applies to the linker logic, it seems to attempt to support linking w/o libc, but looking at the RTL i'm quite sure that never worked. So for now I'm going to assume it's libc only? Also, the inline assembly there (and some Googling) seems to suggest that PIC code is the default on Haiku, while FPC compiled code w/o it (probably for historic reasons) so for now I enabled PIC and PIC via GOT on Haiku. Also, anyone with a working set of cross-as/cross-ld/cross-strip from macOS to Haiku? I tried to build it, and it claimed I need a case sensitive FS, and I was too lazy to create a separate disk image for that for now... :) So, bottom line, see the following patch: http://charlie.amigaspirit.hu/temp/private/haiku_pascal_sysinit.patch Completely untested, because see above, but it compiles at least... %) Also, it needs the Makefile regenerated in rtl/haiku, after the applying the patch. At least the generated code is remarkably similar to the assembler startup code... So i'm sure it would work with some minor fixes (symbol names maybe, linking order, etc), worst case. Some of the possible next steps would be: - test & fix until it works. :) - see the legacy comments in si_c.pp and si_dllc.pp and figure out what to do with those. (Probably only needed to support BeOS, but not Haiku?) - get rid of the unfinished non-libc mess from the Haiku RTL, and when it comes to libc, make it use the generic Un*x stuff where possible. - clean up the old linker support - move to a "buildrtl" system for easier future maintenance - port/fix to 64bit Cheers, -- Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).
Hi, On Mon, 31 Dec 2018, Olivier Coursière via fpc-devel wrote: > > if you want, I can integrate those changes into trunk for you. > Thank you for the offer but i should have some free time in the next two > days. I should already have the change in a 3.0.4 branch. It should be > easy to port to trunk i think. A proper patch would be easier to commit. > > Did you already start working on other CPU support for Haiku? > > Not really. I have investigated what need to be done for x86-64 port but > the assembly part (cprt0.as) was enough to dissuade me so far ;-) Other > CPUs will require a working kernel first ;-) Help is welcome though, on > both sides... At this point it really should be possible to write all/most of the startup code in Pascal. I looked into it quickly, and it's actually pretty simple, there doesn't seem to be anything really in the i386 startup code at least which might be impossible to tackle in a Pascal version. It also seems to contain some syscall wrappers, and they should be perfectly fine in inline assembly as well, and really shouldn't be in the startup code in the first place, IMO. And of course a Pascal startup code would ideally "just work" or with minimal changes on another CPU as well. I have minimal knowledge about BeOS, but I wrote Pascal startup code for some systems (incl. required compiler changes), I might take a look soon, if no one is faster... :) Cheers, -- Charlie___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM
Hi, On Thu, 25 Oct 2018, Florian Klaempfl wrote: > >> That is good news. The contours of a TODO list are becoming visible :) > >> > >> But we may need also need a solution for other platforms, which means the > >> current system should remain in place for those platforms where such a > >> system is not present ? > > > > FPC already has some code to support section threadvars via the GS segment > > on i386 at least, but it doesn't seem to be enabled by default? (Couldn't > > test it, but the tf_section_threadvars target flag, which enable this is > > actually behind a define in i_linux.pas, which I couldn't find enabled > > anywhere?). Also tf_section_threadvars flag has some code to support it > > all over the compiler, including the x86 cg. I have some really vague > > memories I actually enabled it in some experimental local version I had, > > and it worked on first sight at least, but I could be completely off here. > > > > I wonder why it was never enabled by default. > > The %gs based approach works only for object files linked statically to > the executable. In general there are four TLS access models on linux and > at least three of them need to be supported, if one wants to support > dyn. libraries in a usefull manner. Of course, this comes with the > requirement to over means to control the used model. The tls.pdf by U. > Drepper decribes it very well. Ah, right. It's been a while. Ironically, it would have been enough for the actual use case at hand, when I fiddled with it. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM
Hi, On Thu, 25 Oct 2018, Michael Van Canneyt wrote: > >>> - Make Exception handling, TLS etc use the infrastructure that > >>> libpthread is providing > >> > >> TLS is handled already by libpthread. I doubt you will gain much there. > >> > > > > GCC has (depending on the platform) a faster implementation for "__thread" > > variables. E.g. on x86 it uses the GS segment and the data is stored in ELF > > sections. There were experiments in the past to support this in FPC as > > well, so maybe we're on a good way there already. > > That is good news. The contours of a TODO list are becoming visible :) > > But we may need also need a solution for other platforms, which means the > current system should remain in place for those platforms where such a > system is not present ? FPC already has some code to support section threadvars via the GS segment on i386 at least, but it doesn't seem to be enabled by default? (Couldn't test it, but the tf_section_threadvars target flag, which enable this is actually behind a define in i_linux.pas, which I couldn't find enabled anywhere?). Also tf_section_threadvars flag has some code to support it all over the compiler, including the x86 cg. I have some really vague memories I actually enabled it in some experimental local version I had, and it worked on first sight at least, but I could be completely off here. I wonder why it was never enabled by default. Maybe to keep compatibility to some older Linux version, which didn't support this yet? IOW, it might be an one line change. Can I take some of the bounty now? :P Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why/how does the compiler have a non-trivial numberofmemory leaks after over two decades of development?
Hi, On Mon, 30 Jul 2018, J. Gareth Moreton wrote: > I would say that that's a little naïve and dangerous to think like that. > Sure, Windows might have the means to clean up memory after an > application terminates, but not all platforms have such heap > deallocation features (e.g. pure DOS, where certain procedures and > interrupts remain in memory even after the application terminates... > so-called memory-resident programs). While I generally agree, in practice it's usually a non-issue. Pure DOS, as in the 16bit target is not supported to run the compiler, only via GO32V2, and having DPMI TSRs is... well... :) On Amiga and similar systems, AROS, MorphOS for example, which indeed does not free up the memory after a program terminates, I implemented a memory pool in the FPC RTL, so all memory is freed anyway during the program's exit. Any application which wants to go beyond this behavior for whatever of its own reasons is free to use the OS allocation functions directly, or implement its own memory manager. The same with open files on this platform, actually, which wouldn't be closed without the RTL taking care of them. And I also have to manage our own stack, and lets not even mention threading... :) The sideeffect is, that this approach silently "fix" the compiler's own leaks too, so FPC remains useable on these systems. In general it is much safer anyway, because expecting all the broken code out there to get fixed for such systems is sadly just naive. Having this said, anyone who still fixes leaks win the compiler will be my hero! :) Charlie___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] targetandroid
Hi, On Wed, 13 Jun 2018, Adriaan van Os wrote: > >> Yuriy Sydorov wrote: > >>> No special version is needed, use 3.0.4 release sources or trunk > >>> sources. > > I have fpc-3.0.4 installed on OS X 10.6.8. In a separate 3.0.4 sources folder, > I issue > > make clean crossall crossinstall OS-TARGET=android CPU_TARGET=arm > OPT=-Aas-darwin > > and get, after the cleaning stuff, the following error Not all combinations of assemblers and platforms are supported and work. as-darwin is for native OSX and iOS development using clang. For Android (as it's just a special flavor of Linux), you probably have to use the cross GNU binutils supplied with the Android development kit, or some kind of cross-GNU binutils for ARM (supporting EABIv5 maybe?). BTW, it's enough if you have your android cross-tools in the path and specify BINUTILSPREFIX=arm-android- or whatever prefix as/ld/etc has for Android... An additional idea would be to specify the CPU type explicitly as well, because arm has a huge range of CPU subarchitectures which is a constant source of confusion on arm-linux, but I don't think that's the issue here. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Wrong docs: not initialized global variables
Hi,
Just some technical background to this discussion, I don't care who
documented what, I'm just stating how it works. :P
On Thu, 5 Apr 2018, Ondrej Pokorny wrote:
> >>> Now, it is also correct that the compiler developers are aware that
> >>> many people rely on this implementation detail.
> >>
> >> Since when is documented behavior considered as "implementation
> >> detail"? This is not an implementation detail. It is in official
> >> documentation.
> >
> > You and I know very well that this is an implementation detail, needed
> > for internal bookkeeping of the compiler. That the delphi manual states
> > otherwise, I have always considered a grave error on their part:
> > It contradicts one of the core tenets of pascal - see below.
The Delphi manual probably states the de-facto behavior. You cannot not
initialize global variables to zero on most modern Un*ces and Windows,
because the OS will zero out the bss section on executable loading, which
is where most global variables live. (Unless they're in the data section,
in which case they have a specified initial value, but that's more like
typed consts with an initial value in Pascal's context.)
But again, it's zeroed out, not really "initialized". So for example if
you have a type with say, 5..7 value range, it will still contain zero
after start. Hence, uninitialized, therefore the warning is correct. (See
below for examples.)
> Huh, no, I don't know this is an implementation detail. For me the
> initialization rules always were:
>
> 1.) Global variables are initialized. (Why is simple global variables
> initialization needed for internal bookkeeping of the compiler?)
As I wrote above, we cannot not "initialize" (as in: zero out) the global
variables on modern systems, because the compiler doesn't do it, but the
executable loader of the OS. (Well, it's actually a bit more complicated,
if threadvars are involved, but that's platform specific what happens
there, and the end result is the same - global variables are zeroed out.)
> 2.) Class fields are initialized. (Why is simple class fields
> initialization needed for internal bookkeeping of the compiler?)
I think this is something which happens when constructing the class, so
this is runtime behavior, and not compile or exe loading time, and again,
it's just clearing the allocation after GetMem()'ing the heap area for
the class, so you don't get trash in the fields. But they're don't
necessarily initialized to valid values (if zero is not valid).
> 3.) Everything else is not initialized.
> Yes, I have always relied on both 1.+2. For me both points 1.+2. are
> well documented and wanted behavior. Isn't it so?
Do you want initialized, or zeroed out? Zero out will happen,
initialization will not:
Take these two examples:
type
qq = (foo, bar, klepp, mopp, fubb);
q = klepp..fubb;
var
c: q;
begin
writeln(ord(c)); // will write 0;
writeln(c); // will fail with runtime error (out of range)
end.
And:
{$MODE OBJFPC}
type
qq = (foo, bar, klepp, mopp, fubb);
q = klepp..fubb;
type
clfoo = class
c: q;
end;
var
x: clfoo;
begin
x:=clfoo.create;
writeln(ord(x.c)); // write 0;
writeln(x.c); // runtime error (out of range)
end.
Tested with FPC 3.0.4 32bit on macOS.
I'd be interesting to know if Delphi behaved otherwise. But in the above
case the compiler warning about uninitialized variable is completely
valud, even if it's not random but initialized to zero due to OS and RTL
behavior.
Charlie
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPProfiler
Hi, On Mon, 19 Feb 2018, Sven Barth via fpc-devel wrote: > It's not the same scenario as heaptrc is entirely working in the RTL > without any compiler extension (aside from the -gh parameter). Profiling > code however would require extensions to the compiler whereby it would > also need to handle exceptions correctly and such things. Yes, but it's still worth thinking about how to generalize the current GNU Profiler support we have, which is messy at places, and of course entirely depends on GNU Profiler. But it's still mostly about generating a call to _mcount in various ways, taking the stackframe of various platform ABI into account. In theory a call to _mcount could be replaced with a compilerproc, which you could then override in the RTL, allowing a way to add support for various profilers. I'm sure it would allow moving out some of the complexity from the compiler to the RTL, and make things more flexible in the end. (And GNU profiler's _mcount itself also depends on GCC/GLibc implementation details per platform.) Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] *** GMX Spamverdacht *** An extension of fpc language: the BASED construct
HI, On Tue, 26 Dec 2017, Thorsten Engler wrote: > > Item: BYTE BASED ItemPtr; > > Ignoring any other considerations for now, I would have at least used a > logical extension derived from already supported syntax: > > Item: Byte absolute ItemPtr^; As far as I understand (I did not try) this was once supported, but explicitly removed by FPC 2.4.0 from Absolute keyword dereferencing is no longer allowed: http://wiki.freepascal.org/User_Changes_2.4.0#Absolute_variable_declarations As the reasoning there shows, it's a very slippery slope this, which could open a can of worms, so careful people. :) Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.0.4 released!
Hi, On Thu, 30 Nov 2017, Marco van de Voort wrote: > For Downloads, please use the FTP server at > > ftp://freepascal.stack.nl/pub/fpc/dist/3.0.4/ Not sure why Marco decided to redirect everything to the stack.nl mirror as primary source in his announcement, but everything should be on ftpmaster, so: ftp://ftp.freepascal.org/pub/fpc/dist/3.0.4/ Or the right mirror URL for the stack.nl mirror is: ftp://freepascal.stack.nl/pub/mirrors/fpc/dist/3.0.4/ Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Review of AVR patch for bug 31925
Hi, On Wed, 20 Sep 2017, Christo wrote: > I have made an attempt at fixing an AVR related bug. Since this is my > first attempt at messing with the compiler, I would like a review and > critique of my attempt. > (...) > > Can anyone see any problems with this approach, or perhaps suggest a > better approach to fix this bug? I don't know a lot about AVR, and haven't actually tried your patch. But I took a look at it. Few things I see: I wouldn't do IFDEF CPUAVR in inc/generic and inc/compproc. Use maybe IFDEF CPU8 and/or CPU16 instead. This code is indeed generic, and will be useful on other limited CPU archs as well. Or just follow the structure of other MUL helpers, and don't ifdef based on the CPU width at all. The linker will (should) optimize away this code on architectures where it is unnecessary. Also, instead of copypasting the helper function call code, I'd think about generalizing it, and extracting it to a private method of tcgavr, but as I'm not the maintainer of the AVR cg, i'm not sure this is what they would want there. :) But in general I'd say it's the right approach, at least we used this elsewhere too. Charlie___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] trunk broken
Hi, On Sat, 2 Sep 2017, Marco van de Voort wrote: > The expansion of texpropcode in r37108 (Mattias) breaks fppasjs because it > defines an array with texpropcode as range. > > This prohibits building of trunk. Sven fixed it already in r37109. (The quick-response advantage of receiving build notifications from Marcus' Jenkins... ;) Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for FreeBSD/PowerPC
Hi, On Thu, 10 Aug 2017, Marco van de Voort wrote: > > The questions is, can I just go in and upgrade our syscall interface to > > the newer calls (where makes sense), or do we intend to support older > > systems too? > > To my knowledge there is no universal "newer" and "older" BSD syscall > set. Are you talking about something NetBSD specific? So the first thing > would be to qualify that, and/or verify in how much the other BSDs > follow. Well, you can turn off the COMPAT calls in the kernel config. While they're enabled now by default, it certainly looks like something which might go away, or optional. Also while fixing up stuff I ran into the fact that the alignments have changed anyway between aout and ELF it seems, so some of the stuff we have won't work on really old systems anyway, even if you plug in some old binutils for them. But I was mainly referring to stat and fsstat structures and the syscalls which are using them. It's quite an ifdef-mess already, so I was hoping to remove some of that. And there were a few other calls, but I can't remember. I just remember using ktruss, and running into a few compat calls shown. > It might require revalidating all ports, since e.g. structures might change > which in turn might mean validating them on all targets (mostly due to > padding) Yapp, see above. :) I'm pretty certain some if not all of the netbsdppc $ifdef'ing and the related hacks are pretty much unnecessary at this point. But I understand the compiler has advanced a lot since these were added, so I don't mean to point fingers. > I remembered btw that NetBSD did run briefly on PPC though, around FPC > 1.9.2 on a PPC603, Florian helped with the assembler back then. I > remember the main issue was some problem with fpu instructions needing > alignment on 603 but not on 604e. Yes, I ran into the same issue while porting to AmigaOS4 a bit later, and not only 603 but some of the derived cores too, like the 750 etc. It had the same issues. But the compiler has a much better infrastructure to deal with these issues these days. My PowerPC assembly is a bit rusty, but I can still tackle this. ;) Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for FreeBSD/PowerPC
Hi, On Wed, 9 Aug 2017, Curtis Hamilton wrote: > I just formally subscribed to this mailing list. > > I'm interested in fpc on FreeBSD/PowerPC, however, I don't want to > create any additional work nor break something that's not broken. That > being said, I'm willing to work on this alone or with anyone who is also > interested. My personal work target is for PowerPC 64-bit (Power Mac > G5), I do have 32-bit PowerPC (Power Mac G4) hardware available to me. > FreeBSD runs on G4 and G5 Power Macs. > > FYI, I did the work on getting native java (OpenJDK8) support on powerpc64. That sounds cool, welcome on board. The starting point would be this wiki article about how to add a new target to the compiler, which would be necessary for system_powerpc_freebsd and system_powerpc64_freebsd: http://wiki.freepascal.org/Porting_Free_Pascal Which is slightly obsolete, and it doesn't really cover the RTL part, but the main points are still the same to do the first steps. Of course, you have to take care that the compiler and libs sort of already works on FreeBSD, so only implement the CPU specific parts, or include PowerPC/PowerPC64 into the lists where necessary. It's nothing rocket science. If you have specific questions, feel free to ask, also feel free to send patches for review and upstream inclusion. Cheers, -- Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for FreeBSD/PowerPC
Hi Marco, On Tue, 8 Aug 2017, Marco van de Voort wrote: > > FreeBSD for PowerPC never existed in FPC (it's not even in the internal > > platform list, only FreeBSD/i386 and FreeBSD/x86-64). > > I started on it, but stopped due to lack of time. Mind if I fiddle with these things? I don't intend to break anything, and I defnitely seek your input, but I at least intend to care a bit about NetBSD on the CPUs we support and I have access to hardware. Of course you can't avoid other BSDs in the process anyway, so there will be overlaps for sure. > Regularly older calls are replaced by newer calls, but while this is an > organic process, but unfortunately it doesn't happen in all of the BSDs at > the same time or even at all. The questions is, can I just go in and upgrade our syscall interface to the newer calls (where makes sense), or do we intend to support older systems too? I'd say should just upgrade to latest and greatest, especially if a given platform is neglected/was broken or barely maintained otherwise. Any objections? > I don't think there are general rules, best is to discuss it one specific > issue at a time with the relevant maintainers. Well, see my first question above. :) Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for FreeBSD/PowerPC
Hi, On Tue, 8 Aug 2017, Karoly Balogh (Charlie/SGR) wrote: > > I'm interested to know if there has been work on fpc for > > FreeBSD/PowerPC. I'm interested in the status and helping maintain fpc > > for this platform. > > FreeBSD for PowerPC never existed in FPC (it's not even in the internal > platform list, only FreeBSD/i386 and FreeBSD/x86-64). It's certainly > possible to add it though, especially if someone steps up as a regular > maintainer. BTW, while we're at it, does "powerpc" mean powerpc32 or powerpc64 or both in FreeBSD's case? Also, what about the new little endian powerpc64le stuff for the future? Because all of these need a separate ID and platform support in FPC then. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for FreeBSD/PowerPC
Hi, On Mon, 7 Aug 2017, Curtis Hamilton wrote: > I'm interested to know if there has been work on fpc for > FreeBSD/PowerPC. I'm interested in the status and helping maintain fpc > for this platform. FreeBSD for PowerPC never existed in FPC (it's not even in the internal platform list, only FreeBSD/i386 and FreeBSD/x86-64). It's certainly possible to add it though, especially if someone steps up as a regular maintainer. I was recently thinking to revive and bring NetBSD for PowerPC support up to speed, after recently fixing/reviving NetBSD for m68k. But to be honest, even the far more popular x86_64 and i386 versions seem to need some love, and I'd say that probably also goes for FreeBSD (Marco? Any comments?). Maybe these efforts can be combined. I never ran FreeBSD before, I might have the hardware for the PowerPC version tho'. Does it run on one of the following: Mac mini G4, PowerBook G4 (5,6), PowerMac QuickSilver G4, bPlan Pegasos II G4? The main problem that most of the BSD and Unix platforms have a quite entangled backend in the FPC RTL (and even Darwin is considered a BSD in this case), so there's a high risk that one can break something else while fixing a certain platform, and most of it uses a quite old COMPAT syscall interface. So mapping up what's there and how to fix it for the future is the difficulty, while not breaking other Unices and BSDs in the process. :) But otherwise it's definitely doable. Cheers, -- Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Avoid exception if FPHTTPClient cannot connect to server?
Hi, On Mon, 31 Jul 2017, Werner Pamler wrote: > If the URL exists everything is fine (note on Windows, that the OpenSSL > dlls must be copied to the exe directory for the demo to work). If the > URL does not exist, but the server responds, the program returns the > well-known error 404 (if the 404 has been added to the response codes in > HTTPMethod) - also fine. But if a connection to the server cannot be > established -- maybe because the server URL is wrong -- then the program > creates an exception. Synapse, on the other hand, does not crash on this > occasion, it just returns an error 500. This behavior appears to be much > more consistent than fpc's. I disagree. I think generating any HTTP error code locally, which should always come from the server is anything but a good idea. It could mask true server issues from network connectivity issues, which distinction could be still relevant and the client application might want to employ different error mitigation techniques to solve one or the other case. > Is this intentional? Or should I report a bug? The code in FPHTTPClient has an explicit Raise line when the connection is unsuccessful. So I'd say this is not a bug, but by design. Maybe this behavior should be better documented or the Exception itself could be more descriptive tho', but I haven't tried this. (Note that I generally dislike APIs which are designed to throw exceptions, but anyway, in this case it looks like it's by design and it's still better than just generating a random HTTP code locally.) Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Mantis/Bugtracker registrations fixed
Hi, We had numerous reports over the past few weeks, that the FPC/Lazarus Bugtracker registration verification was broken. Thanks to the work of Michael van Canneyt, it should be fixed now. If you had trouble creating a bugtracker account in the last few weeks, please try again now. Charlie ___ 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
Hi, On Tue, 30 May 2017, Marco van de Voort wrote: > In our previous episode, Karoly Balogh (Charlie/SGR) said: > > Err, those are invoked directly from the Makefile, not invoked from inside > > FPC. But you're right, that will be also a problem... Some platforms still > > use asm-written startup stubs in FPC. Not all of them tho'. I think these > > days these startup codes could be written in Pascal anyway, but for Sparc > > they're not. > > (neither are they for *BSD since those use weak symbols) Is it still required? Darwin does all kinds of weak linking too, and it has a Pascal written startup code if I'm correct. Charlie ___ 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
Hi, On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote: > make all ASTARGET=-32 OPT="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32" So Adrian, I've got a question. Looking at fixing this in the right way, the linker search paths at least. What's the right directory to search for libs and objects in a multiarch system? I can add /lib32;/usr/lib32, etc. to the default library search path for FPC, but i find references online that's the "old" way, and the new way should be /usr/lib/, like sparc64-linux-gnu, and sparc-linux-gnu... However, this later is lacking on the buildbox, while there is /lib32... Or are these complementary? The library search paths seems a bit hardwired in t_linux.pas. I can add something like /lib32;/usr/lib32;/usr/X11R6/lib32 for all 32bit platforms, but not sure if that makes sense. I also don't know how "standard" is this among distros. Charlie ___ 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
Hi, On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote: > > However, it should probably not be merged to fixes, because it may be a > > breaking change for older Sparc/Linux versions (see my previous e-mail; > > note that the situation with MIPS was probably different, because the > > support of that CPU is much newer). > > I am pretty sure that the "-32" option hasn't changed for aeons, so > there is nothing to break here. And, as I mentioned before, you are > already passing "-b elf32-sparc -m elf32_sparc" to ld, so adding "-32" > to the assembler would not hurt at all. From what I can see, binutils 2.9.1, released 1/5/1998 (19+ years ago) already has it for SPARC (according to the man page). :) But binutils 2.8.1 from 20 years ago, still didn't. So it was added between those versions. :) I cannot confirm this now, but I'm willing to make a bet that our generated assembly syntax already depends on newer binutils, for things like named sections. Although I'm not sure these are enabled for SPARC in their full glory. Charlie ___ 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
Hi, On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote: > 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 the > Debian SPARC64 box without patching anything. Just for the record, the same command line can be used to build the fixes_3_0 branch without any patching or Makefile-messing as well. I just tried on that box, and it worked. Charlie ___ 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
Hi, On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote: > > Can you try if you can reproduce this? > > Sure. Can you put the cross-compiled ppcsparc somewhere so I can find > and use it? You don't need one. :) See my other mail. Although I did crosscompile a new bootstrap compiler, in the end I did not need it. > > Now, how to package this, or what to commit as fix in trunk/fixes branch, > > is another question. :) > > Well, all the -32 options should definitely go into trunk. Upstream > doesn't support anything but 32 bits for SPARC anyway and after > looking at the rtl/linux/Makefile.fpc, you already do this for mips32. I tend to agree in both. I still want to have the opinion of someone in the FPC team who feels more like a sparc-linux guy than me. (That means if there will be no response in 1-2 days, I will go ahead with the changes in trunk. :P) Charlie ___ 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
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 the correct one. Also, ASTARGET= override seems to work, so you don't need to patch 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 the Debian SPARC64 box without patching anything. Now, if you want to patch the compiler for this, or simply wire additional options to the package supplied fpc.cfg with the right paths and options, that decision is not mine to make. I'm not the Linux maintainer, and even less of a SPARC maintainer. :) Charlie ___ 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
Hi, On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote: > > However, these also seem to be installed in /usr/lib32... So build running > > now, lets see what happens. > > Different error: ... :/ I would gladly keep working on this, but I kinda > ran out of time for now, I can take a deeper look maybe tomorrow, or in > the coming weeks. Sharing this, so meanwhile maybe someone has an idea? > > I'm sure i've seen this error before on other platforms, but I can't > remember the solution. Something with the linker scripts vs. startup > code vs. paths definitely. Did a last attempt, and bingo. :) make all OPTS="-ao-32 -Fo/usr/lib32 -Fl/usr/lib32" Then everything builds, including the FP IDE, and all tools as expected. 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? Now, how to package this, or what to commit as fix in trunk/fixes branch, is another question. :) Charlie ___ 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
Hi, On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote: > However, these also seem to be installed in /usr/lib32... So build running > now, lets see what happens. Different error: ... :/ I would gladly keep working on this, but I kinda ran out of time for now, I can take a deeper look maybe tomorrow, or in the coming weeks. Sharing this, so meanwhile maybe someone has an idea? I'm sure i've seen this error before on other platforms, but I can't remember the solution. Something with the linker scripts vs. startup code vs. paths definitely. Free Pascal Compiler version 3.1.1 [2017/05/29] for sparc Copyright (c) 1993-2017 by Florian Klaempfl and others Target OS: Linux for SPARC Compiling fpmake.pp fpmake.pp(16,3) Note: Local variable "T" is assigned but never used Assembling fpmake Linking fpmake fpmake.pp(49) Warning: "crti.o" not found, this will probably cause a linking failure fpmake.pp(49) Warning: "crtbegin.o" not found, this will probably cause a linking failure fpmake.pp(49) Warning: "crtend.o" not found, this will probably cause a linking failure fpmake.pp(49) Warning: "crtn.o" not found, this will probably cause a linking failure /home/charlie/fpc/trunk/rtl/units/sparc-linux/cprt0.o: In function `_start': (.text+0x58): undefined reference to `_init' /home/charlie/fpc/trunk/rtl/units/sparc-linux/cprt0.o: In function `_start': (.text+0x5c): undefined reference to `_fini' /home/charlie/fpc/trunk/rtl/units/sparc-linux/cprt0.o: In function `_start': (.text+0x64): undefined reference to `_init' /home/charlie/fpc/trunk/rtl/units/sparc-linux/cprt0.o: In function `_start': (.text+0x68): undefined reference to `_fini' fpmake.pp(49) Error: Error while linking fpmake.pp(49) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Charlie ___ 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
Hi, On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote: > Make sure to pass -L/lib32 to the linker because that's where libc6-sparc > gets installed into: > > root@deb4g:~# dpkg -L libc6-sparc |head > /. > /etc > /etc/ld.so.conf.d > /etc/ld.so.conf.d/zz_sparc-biarch-compat.conf > /lib > /lib32 > /lib32/ld-2.24.so > /lib32/libBrokenLocale-2.24.so > /lib32/libSegFault.so > /lib32/libanl-2.24.so > root@deb4g:~# Now, my knowledge on linking-against-libc thiings regarding FPC are a bit rusty, but I'm quite positive we don't need the .so files there at linking stage, but we need the accompanying .a files from the -dev package? However, these also seem to be installed in /usr/lib32... So build running now, lets see what happens. Charlie ___ 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
Hi, On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote: > > Which is because the buildbox doesn't have these 32bit libraries > > installed, so FPC obviously cannot link against them. This is because the > > very limited multiarch you mentioned before I guess. Now, FPC doesn't need > > Libc on linux for its own functionality, but it needs it for FPmake. > > We can easily install a 32-bit C library. It's one of the things that > actually get build, even on 64-bit systems. > > I'll just install that, second. Oh, ok. Nice. :) I'll wait then. Charlie ___ 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
Hi, On Mon, 29 May 2017, Karoly Balogh (Charlie/SGR) wrote: > Which is because the buildbox doesn't have these 32bit libraries > installed, so FPC obviously cannot link against them. This is because the > very limited multiarch you mentioned before I guess. Now, FPC doesn't need > Libc on linux for its own functionality, but it needs it for FPmake. > > Now, FPMake is not to be mixed with FPCMake, the former is a package build > system which is used for the Packages and the IDE. It needs > libc/libpthreads for the parallel builds... (Multithreaded applications > link against libc/libpthreads with FPC under Linux, single threaded > normally do not.) So the bottom line is in clear words: FPC will need at least the fundamental libs (libc, pthreads, libdl) installed on the buildbox in 32bit versions (multiarch), or the rest of the build sinply won't work, and cannot be made to work easily. Charlie ___ 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
Hi, On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote: > In the end, I want to build the Debian package. So, the patches have > to apply against that version. Well. I applied a 1 line patch against rtl/linux/Makefile.fpc, to append -32 when it builds the startup code, regenerated the Makefile using fpcmake -Tall, then started a the build like this in ~/fpc/trunk/: make all OPT="-ao-32" Obviously, the startup compiler doesn't have the -32 fix, so this is why it failed for you, but this option inject this option externally. Then the build initial phase where it rebuilds a new compiler, and starts to use it succeeds. Which is the good news! And then it went through the point where it wants to build fpmake natively with the new compiler. Where it fails with: /home/charlie/fpc/trunk/compiler/ppcsparc fpmake.pp -Fu/home/charlie/fpc/trunk/packages/fpmkunit/units_bs/sparc-linux -Fu/home/charlie/fpc/trunk/rtl/units/sparc-linux -ao-32 Free Pascal Compiler version 3.1.1 [2017/05/29] for sparc Copyright (c) 1993-2017 by Florian Klaempfl and others Target OS: Linux for SPARC Compiling fpmake.pp fpmake.pp(16,3) Note: Local variable "T" is assigned but never used Assembling fpmake Linking fpmake fpmake.pp(49) Warning: "crti.o" not found, this will probably cause a linking failure fpmake.pp(49) Warning: "crtbegin.o" not found, this will probably cause a linking failure fpmake.pp(49) Warning: "crtend.o" not found, this will probably cause a linking failure fpmake.pp(49) Warning: "crtn.o" not found, this will probably cause a linking failure /usr/bin/ld: cannot find -lpthread /usr/bin/ld: cannot find -ldl /usr/bin/ld: cannot find -lc fpmake.pp(49) Error: Error while linking fpmake.pp(49) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Makefile:1712: recipe for target 'fpmake' failed Which is because the buildbox doesn't have these 32bit libraries installed, so FPC obviously cannot link against them. This is because the very limited multiarch you mentioned before I guess. Now, FPC doesn't need Libc on linux for its own functionality, but it needs it for FPmake. Now, FPMake is not to be mixed with FPCMake, the former is a package build system which is used for the Packages and the IDE. It needs libc/libpthreads for the parallel builds... (Multithreaded applications link against libc/libpthreads with FPC under Linux, single threaded normally do not.) Charlie ___ 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
Hi, On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote: > On Mon, May 29, 2017 at 02:57:51PM +0200, Karoly Balogh (Charlie/SGR) wrote: > > Indeed, this worked. Also, not sure what Adrian was doing wrong, but I > > added -32 into sparc/cpugas.pas file as I said, and from then on I started > > getting 32 bit object files, and after fixing the Makefile, I got a 32bit > > FP executable, crosscompiled. Maybe something on the buildbox will reveal, > > why it doesn't work there. > > Nope. Still doesn't work here. Maybe my brain is just messing things > up in today's heat here in Berlin :O. I'm also sitting in Berlin, so we're having different delusions from the heat then... :) BTW, I sent you a pubkey. It's easy to test how the assembler behaves, using those standalone .as files. So "sparc64-linux-gnu-as -Av9 -32 prt0.as -o prt0.o" should result in a 32 bit object. If that doesn't work, nothing will. Charlie ___ 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
Hi, On Mon, 29 May 2017, Tomas Hajny wrote: > > It is, but it's *pregenerated*, and committed to the SVN. The build > > process doesn't generate any Makefiles, actually. (Lets not argue now it > > is a nice practice or not, it is what it is...) To fix this, one has to > > regenerate them. But it's complicated. ;) I'm not sure if you actually has > > to fix inside fpcmake or the submitted Makefile.fpc which fpcmake uses to > > generate the actual Makefile. But by the time I get there I'll figure it > > out. One problem at a time. > > It shouldn't be that difficult in this case - have a look > fpcsrc/rtl/linux/Makefile.fpc. Look at lines 147-153 (mips) and modify > lines 162-166 (sparc) similarly (obviously, not all options used for mips > are relevant for sparc, but the logic should be similar). Once done, call > 'fpcmake -Tall' in that directory. Indeed, this worked. Also, not sure what Adrian was doing wrong, but I added -32 into sparc/cpugas.pas file as I said, and from then on I started getting 32 bit object files, and after fixing the Makefile, I got a 32bit FP executable, crosscompiled. Maybe something on the buildbox will reveal, why it doesn't work there. I'm crosscompiling from Darwin, using binutils 2.27, which I built as sparc64-linux-gnu target. Charlie ___ 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
Hi, On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote: > On Mon, May 29, 2017 at 02:25:34PM +0200, Karoly Balogh (Charlie/SGR) wrote: > > > > Even passing "-Av8plus" does not help. So, the options from > > > > compiler/sparc/cpugas.pas are definitely not passed to the assembler. > > > > I'm looking into it now. Stay tuned. I managed to reproduce your linker > > problem already, at least. :) > > Thanks. But the linker problem is just a result of the assembler not > playing nicely. The linker did nothing wrong ;-). Right, I just meant I'm approaching the actual problem to fix. :) > > > From the build log: > > > > > > as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/prt0.o > > > sparc/prt0.as > > > as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/dllprt0.o > > > sparc/dllprt0.as > > > as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/cprt0.o > > > sparc/cprt0.as > > > as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/gprt0.o > > > sparc/gprt0.as > > > > Err, those are invoked directly from the Makefile, not invoked from inside > > FPC. But you're right, that will be also a problem... Some platforms still > > use asm-written startup stubs in FPC. Not all of them tho'. I think these > > days these startup codes could be written in Pascal anyway, but for Sparc > > they're not. > > But isn't the Makefile generated from fpcmake? :-O It is, but it's *pregenerated*, and committed to the SVN. The build process doesn't generate any Makefiles, actually. (Lets not argue now it is a nice practice or not, it is what it is...) To fix this, one has to regenerate them. But it's complicated. ;) I'm not sure if you actually has to fix inside fpcmake or the submitted Makefile.fpc which fpcmake uses to generate the actual Makefile. But by the time I get there I'll figure it out. One problem at a time. > Let me know if you need access to a porterbox. Probably. If I get to something, I'll drop you a pubkey. Charlie ___ 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
Hi, On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote: > On Mon, May 29, 2017 at 02:14:26PM +0200, John Paul Adrian Glaubitz wrote: > > On Mon, May 29, 2017 at 01:09:05PM +0200, John Paul Adrian Glaubitz wrote: > > > I tried adding "-32" like this: > > > > Even passing "-Av8plus" does not help. So, the options from > > compiler/sparc/cpugas.pas are definitely not passed to the assembler. I'm looking into it now. Stay tuned. I managed to reproduce your linker problem already, at least. :) > From the build log: > > as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/prt0.o > sparc/prt0.as > as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/dllprt0.o > sparc/dllprt0.as > as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/cprt0.o > sparc/cprt0.as > as -o /root/fpc/fpc-3.0.0+dfsg/fpcsrc/rtl/units/sparc-linux/gprt0.o > sparc/gprt0.as Err, those are invoked directly from the Makefile, not invoked from inside FPC. But you're right, that will be also a problem... Some platforms still use asm-written startup stubs in FPC. Not all of them tho'. I think these days these startup codes could be written in Pascal anyway, but for Sparc they're not. Charlie ___ 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
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 about SPARC, but from what I see, FPC definitely handles SPARC as a 32bit only architecture now. All the definitions in fpcdefs.inc hardwires CPU settings 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's simply "not there"? Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] list server outtage
Hi, The list server rebooted this morning. We're investigating with the hosting service why. If you got mails multiple times or your mail got lost, this is why. By now, everything should be back to normal. Sorry about the inconvenience. Charlie ___ 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
Hi, On Mon, 29 May 2017, John Paul Adrian Glaubitz wrote: > Running the file utility on one of the object files shows that the > assembler did not generate 32-bit code. So, at least a hotfix here > would be to pass "-m32" to the assembler. That is easy to add, see in compiler/sparc/cpugas.pas, MakeCmdLine method, which works from the templates at the bottom of the same file. However, this always asks the question, what would happen with other platforms, like does this -m32 change breaks 32bit SPARC and/or some distros/older versions of binutils? Otherwise I can add it permanently, it's no biggie. You can also try to add the OPT="-ao-m32" option to the build to see if that indeed works (or CROSSOPT="-ao-m32" in case of crossbuilds). Charlie ___ 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
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 was under the impression it's still being tested... The Solaris version's last testresult is from 2012... https://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=1&run1id=150744 https://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=1&run1id=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 seem to have a stable 3.0.2 release. Can you try if the stable release built by us works on your system? Any binary from this. ftp://ftp.freepascal.org/pub/fpc/dist/3.0.2/sparc-linux/ > 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 can take a look. In fact, maybe even a full 64bit SPARC port shouldn't be that hard (famous last words...), but at least a few weeks of work for sure for someone who knows the compiler internals. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
Hi, On Thu, 16 Mar 2017, LacaK wrote: > Then I get another error: >test_IPP.lpr(24,1) Error: Illegal COFF Magic while reading > .\Intel_IPP\ippcoremt.lib > > Am I doing something wrong, or there is some kind of incompatibility > between format of supplied libraries and object files supported by FPC ? > (I am on FPC 2.6.4 , is there chance when I will use 3.0.2 that > something changes in this?) Someone wrote already, that the internal linker doesn't support static libraries. You have to use -Xe (GNU LD, as external linker) to have a fighting chance for this to work. It's bundled with FPC. Again, I'm not saying it will work with GNU LD, I'm saying it won't work with the internal linker, and that's true for any FPC version currently. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM
Hi, On Wed, 14 Dec 2016, Michael Schnell wrote: > Of course another (better) option would be a fpc directly creating > WebAssembly, but I understand that this will take a lot of time. There is some interest in a WebAssembly backend, but yes it will take a lot of time. No spoilers for now, and nothing to see, move along. There is also some work underway, to compile Pascal code to JS, but that's a separate project, not implemented as an FPC backend. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Crosscompiling win towards darwin
Hi, On Wed, 23 Nov 2016, Alfred wrote: > > TL;DR: if this patch was accepted into NewPascal w/o comments or concerns, > > then "ouch"... > > Thanks for your advice. > This is exactly why NewPascal is here ! > > Have an idea. Implement. Make public. > perfect:=false; > while (NOT perfect) Use; Get feedback; Correct mistakes; Test; if ok then > perfect:=true; end; Well, we're talking about two different things. In this interpretation, NewPascal serves as some kind of FPC-experimental branch. Which is nice, and nothing to have against it. But still, before merging anything to a master branch, there should be a way to review patches for obvious mistakes, or simply doing things in a wrong way. I see your pull request was accepted without comments in four hours after its submission. Which - given the amount of IFDEFs it contains, still "ouch", IMO. No offense, and nothing personal, just the criticism of the general approach towards code quality in a project with the size of FPC. However, I agree that the FPC team should have a more streamlined way of accepting and reviewing patches, than posting diffs to a bugtracker or a mailing list. The Bazaar went elsewhere over the years, which is always a problem for an opensource project. But the tooling problem is only part of the story. > I will have a look at the patches again. Cool, please keep us posted for updates. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Crosscompiling win towards darwin
Hi, On Wed, 23 Nov 2016, Alfred wrote: > To enable cross from Windows towards Darwin, some changes in FPC were needed. > They have been added into NewPascal, and can be found here: > https://github.com/newpascal/freepascal/commit/a99fe9054957d2c42c780c4d05e59c6fbda31621 > Not meant to be 100% correct, but working. For a starter, if you should do something like: if target_info.system in [system_i386_darwin,...] then... instead of $IFDEF-ing HASUNIX. It's just a random idea, but because of HASUNIX, your patch might have actually broken Win->Linux crosscompiling... Plus Also I haven't actually verified this, but if you actually need to use Unix-style scripting for Win->Darwin crosscompile, you could have just added an exception somehow to use Unix scripts in that case, instead of hacking it into the DOS-format scripts like this, really... TL;DR: if this patch was accepted into NewPascal w/o comments or concerns, then "ouch"... Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is there a way to make Register Allocation inside of Interrupt Service Routines more efficient when using inline-assembler?
Hi, On Sun, 21 Aug 2016, Sergei Gorelkin wrote: > It is actually the opposite way around. > g_save_registers/g_restore_registers methods are only used for first > implemented targets (i386 and maybe m68k). All newer targets are written > without calling them, since they are completely inappropriate to > implement stack frame optimizations or push/pop-alike instructions for > register saving. Well, they still have stubs in the HLCG, which is why I thought it must be newer than just dumping everything in g_proc_entry. Actually, I implemented them quite recently for 68k, and they're still routed in live code in psub.pas. However, since historically I missed the large compiler refactor in the mid-'00s, I believe you. Anyway... > MIPS codegenerator does check which registers are actually used. The > issue is, a procedure with 'interrupt' modifier must not modify any > registers at all because it can be called asynchronously. As soon as an > 'interrupt' procedure calls another (regular) procedure, the callee may > modify any registers from volatile list, and the caller has no way to > know which ones. Therefore, it has no other option than to save/restore > all volatile registers. Well, one possible optimization would be to only save all volatiles if the interrupt routine actually calls another function. Otherwise only save the ones used by the current proc. This would allow some very small and very fast interrupt functions, right? I'm not sure though if there's an easy way to determine if there is a function call inside the function I'm generating code for. Maybe at the point of generating a function call, if the current proc is an interrupt, mark all volatiles as used somehow? Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is there a way to make Register Allocation inside of Interrupt Service Routines more efficient when using inline-assembler?
Hi, On Sun, 21 Aug 2016, Michael Ring wrote: > So unless there is a way to find out which registers get used by a procedure > the only thing I can do to make interrupt routines as lean as possible is to > not use procedures in them if possible. There is a way, of course. Seems like the MIPS CG was never updated to depend on cgobj.g_save_registers/cgobj.g_restore_registers (or implement these on its own), which takes into account which registers were used in the procedure, and only saves those. See g_save/restore_registers implementation in cgobj.pas for an inspiration how it should be done. The m68k CG also reimplements these methods with some CPU-specific extensions. It seems to use the old-style approach of just always saving all volatile registers, and do everything on its own in g_proc_entry/exit which is the old way (and also still used in some other CGs). Not sure why it was never updated tho' for MIPS, I don't know anything about the MIPS CG, and very little about the architecture itself. But it sounds like this definitely the improvement you want. Cheers, -- Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc svn trunk building fails
Hi, On Sun, 5 Jun 2016, Sandro Cumerlato wrote: > fpc svn trunk version 33910 building fails with error: > *..snip..* >Compiling .\fcl-db\src\export\fpxmlxsdexport.pp >Compiling .\fcl-db\src\sqldb\interbase\fbadmin.pp > The installer encountered the following error: > Compilation of "BuildUnit_fcl_db.pp" failed > make[2]: Leaving directory `C:/freepascal/fpc/trunk/packages' > make[1]: Leaving directory `C:/freepascal/fpc/trunk' Actually, another issue is, since when does fpmake hide the compiler output on failures? Because fbadmin.pp is obviously broken, so there should be compiler errors. For a starter, it has the wrong unit name (fbadmin2), but even with that fixed, it doesn't compile. But there isn't a single line of error message in the fpmake output, while there used to be (IIRC)... > Please take a look. Actually, we should have automated builds, so these kind of breakages are noticed, but thanks for the report anyway. :) Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Access violation in fpmake
Hi, On Sun, 15 Nov 2015, Michael Van Canneyt wrote: > Strange, I created a test before committing, and it ran fine. Well. I > reinstated line 1132. But according to logic, that line should not be > necessary. Maybe I am not properly seeing a case where it can go wrong. Wild try/guess just by looking at the code: If FList^[Index].FString is not nil (which is true after the System.Move() there), then at the next line at the assignment, there will be an attempt to reduce the reference count of the string before assigning the new one, and then it's a very likely case that the reference count of it will be zero, so the string is freed. Which means the string at FList^[Index+1] will be invalid, because System.Move() doesn't do anything with the reference counts, so at that point FList^[Index] and FList^[Index+1] are eachothers clones, but the reference count doesn't reflect that. Therefore that nil (and the pointer cast!) is very much required. The pointer cast is needed, so the string will be handled as pointer, and only the value is erased, but the refrence counts are untouched. Someone please fix me if I'm wrong. :) Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FreeSparta project is dead - Generics.Collections is live
Hi, On Tue, 23 Dec 2014, Maciej Izak wrote: > I've Decided to close the "FreeSparta". Thanks you all for your interest. > There are several > reasons. > [...] > When I look for new jobs, it seems that there are no more jobs for > Pascal/Delphi Programmers. Now > in my new job I'm using Java EE and C# most of the time. I can feel your pain. :( I had to spend almost a decade in other languages before I found a Pascal job which suited me. Actually, I visited a few meetings lately, where I talked with representatives of several companies with large existing Pascal code base, and were looking to hire Pascal/Delphi developers, but they were strugling to find good candidates. Or sometimes any at all. Maybe there's supply and maybe there's demand but these - for some reason - cannot meet? How about some FPC/Delphi job forum? Maybe FPC-Devel is not the best place to discuss this, but it's definitely a topic I'd be glad to hear other's opinion on this. Charlie ___ 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
Hi, On Wed, 19 Nov 2014, Marco van de Voort wrote: > > Since the RTL's allocator is documented to align to 16 bytes, it's > > definitely an issue also with Pascal code. We do have code where also > > Pascal side triggers the aligment issue, but indeed, the main issue is > > with linked C libs, depending on pointers from the Pascal side. > > I'm not an alignment expert, but only when loading types that are larger > than the pointer size, since only those are not naturally aligned and so > could cross cacheline bounderies? Yes, but the problem is, you have no idea what the underlying library does, and GCC seems to compile code where it thinks it would be more optimal which expects the malloc()-alike alignment at least. > Anyway, I don't see a problem with having a cmemalign16 (or -32 or whatever) > unit, but I wouldn't blow up allocation unnecessary if there hasn't been a > real problem in most cases. Well, I would still fix the original cmem to not destroy the underlying malloc alignment, but that patch should be much less invasive. Another idea would be to add a simple helper to the RTL, to allocate/free an aligned memory block, something libc already has, IIRC. > Since cmem is documented to be used from the main program file (iow the > users code), that would nicely put the responsibility there. Yes, but this still doesn't answer the question why my cmem16 doesn't work for complex apps, while it seems to pass all simple heap testcases. :) (On a slightly related note, did anyone run current trunk compiler with cmem allocator through valgrind recently? I seem to get quite some "using uninitialized memory" hits.) Charlie ___ 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
Hi, On Wed, 19 Nov 2014, Jonas Maebe wrote: > > Since the RTL's allocator is documented to align to 16 bytes > > Where? Ok, that's actually a very good question. :) I didn't find it anywhere, except some earlier ML/forum posts revealed by Google. However, in practice it still seems to align to 16 bytes, and I asked several people (compiler, RTL, Lazarus developers) during the FPC/Lazraus conference last weekend in the Netherlands and the consensus was, it's known the heap manager aligns to 16 bytes, it's designed to do that, and in general it's a feature, which should be documented if it's not. But yeah, everyone appended "but better ask Jonas". :) CHarlie ___ 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
Hi, On Wed, 19 Nov 2014, Mark Morgan Lloyd wrote: > > 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. Since the RTL's allocator is documented to align to 16 bytes, it's definitely an issue also with Pascal code. We do have code where also Pascal side triggers the aligment issue, but indeed, the main issue is with linked C libs, depending on pointers from the Pascal side. > > 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. We do have limited ARM hardware, based on older ARM cores where this is an issue. We use FPC in production on these chips, so it's an issue for us. And since these cores remain in production for the coming years (not just for us, but in general), the compiler and libs have to deal with it. > 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. Actually there's plenty of hardware, where this is an issue. Almost all "RISC" chips, especially embedded ones do have alignment restrictions to some degree. I know older PPC and recent Power chips having them as well. And even the fastest CPUs have some performance penalty when doing unaligned accessess even if the hardware solves it itself, and it doesn't involve the software side. > ARM Linux may also do it (where demanded by the hardware) but my > understanding is that notifications can be enabled. Yes, we have these notifications enabled, and we're flooded with them, when using the cmem allocator. This is why I started working on this. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] CMem allocator memory alignment experiment
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. This causes multiple performance and other issues, especially on processors which require stricter alignment (most ARM CPUs, but also x86 with SSE, etc). I created a cmem variant, which does 16 byte alignment of the returned memory blocks, just like FPC's own Heap Manager does: https://gist.github.com/chainq/6f69a7821cfa2503962f However, when I build FPC with this cmem16 allocator, the compiler explodes. Also it fails with other larger parts of code, and I'm unsure why, I spent a few days debugging, but I couldn't find the issue. Ideas? I wanted to contribute the code to the FPC SVN (after some cleanup) but because of these issues, I couldn't. Yes, the current alignment code is not the most optimal and wastes some memory, but at least it should work. Must be something trivial. Ideas, opinions, suggestions welcomed. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] RTL: high CPU load in heap manager
Hi, We were profiling our code, and one RTL function regularly popped up in close to the top in the profiling list. It's remove_freed_fixed_chunks(). Can someone explain to me under what condition this code is triggered very often and/or could take long to execute (there's a loop in there)? Maybe we abuse the the heap manager, or there's room for improvement in the RTL, we would like to know. We experienced his on ARM/Linux btw. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] M68k: important milestone reached (again:)
Hi, On Mon, 10 Mar 2014, Sven Barth wrote: > > Well, today on IRC you mentioned Atari too many times for an Amiga guy's > > taste, so I couldn't resist... > > Once is already too many? :P Yes! :) > > http://charlie.amigaspirit.hu/screenshots/uae/UAE-FPC-m68k-2.7.1-FirstEver.png > > > > :) > > Congrats! So the cliffhanger resolved satisfactorly :D Yeah, the cliffhanger was r27066, after that I got an Amiga compiler binary. And then it also needed r27070 before it started to work. (And I have an unfinished quick & dirty RTL patch which I still didn't commit, which is required to build the compiler (an Exec unit), but that's possible to work around if you disable the HASAMIGA parts in assemble.pas.) > > And besides, it was a decade old wish of me to have recent FPC running on > > Amiga again. This also means the CG also somewhat works for a "full" 68k, > > the 68020, not just for ColdFire. Sadly, it's known to be broken for plain > > 68000, so now really back to fixing some CG issues, before adding more > > platform-specific mess... :) > > Yes. Do you think you could somehow crossrun the testsuite on a 68020 or 68000 > system? Well, there's a patched QEMU which - in theory - can run 000 and 020 code. I tried it for some simple 020 bins, and that worked, I'm going to try to run the whole testsuite with it (an also '000). The additional nice thing if it works that it's much easier to get various C libs to test with a full 68k (for example from Debian-m68k) than Coldfire. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] M68k: important milestone reached (again:)
Hi, On Sat, 22 Feb 2014, Sven Barth wrote: > With revision 26849 which I just committed a few minutes ago an imporant > milestone was reached for reviving the M68k port: the cross compiled compiler > is now not only able to compile a program, but this program is also able to > run correctly! > > [...snipp...] > > After that the main work on m68k will switch to optimizations and maybe/likely > revival of other m68k RTLs (Amiga, Atari, Mac OS, NetBSD) :D Of course an > embedded target will be a nice to have as well ;) Well, today on IRC you mentioned Atari too many times for an Amiga guy's taste, so I couldn't resist... http://charlie.amigaspirit.hu/screenshots/uae/UAE-FPC-m68k-2.7.1-FirstEver.png :) And besides, it was a decade old wish of me to have recent FPC running on Amiga again. This also means the CG also somewhat works for a "full" 68k, the 68020, not just for ColdFire. Sadly, it's known to be broken for plain 68000, so now really back to fixing some CG issues, before adding more platform-specific mess... :) Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] M68k: important milestone reached
Hi, On Mon, 24 Feb 2014, Sven Barth wrote: > Am 24.02.2014 17:29, schrieb Michael Schnell: > > On 02/24/2014 03:41 PM, Sven Barth wrote: > > > are normally OS independant as they normally use corresponding CPU > > > instructions. > > Of course for simple stuff like inc/dec I can (better) use atomic 68 K > > instruction :-) . > Of course. But e.g. not every Coldfire architecture supports them. For this > reason I introduced the cpuflags CPUM86K_HAS_TAS and CPUM68K_HAS_CAS which are > set if the test-and-set and the compare-and-swap instructions are available > respectively (68000 only has the TAS, but not the CAS, 68020 and 68040 have > CAS and TAS while Coldfire ISA-A and ISA-A+ have neither and ISA-B and ISA-C > only have TAS). When I find the time I will implement the Interlocked* > functions accordingly :) Keep in mind that at least TAS is (basically) forbidden on Amiga, because it's incompatible with several HW implementations by Commodore and by how DMA accesses are generated by various bus extensions (Zorro II) or custom chips (eg. Agnus) in respect to the CPU and/or CPU expansion cards. The same applies to CAS/CAS2, I guess. Basically anything which tries to do an atomic read-write cycle is not guaranteed to work correctly on Amiga. More info: http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node012B.html http://www.devili.iki.fi/mirrors/haynie/systems/amiga2k/docs/tasa2k.pdf http://eab.abime.net/showthread.php?t=58493 So if you decide to implement anything related to this, better make it OS specific too. :) Thank you. Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 2.6.2 (to build trunk) Fatal: Internal error 20060521
Hi, Yes, it's caused by a recent change I made. I have a half-ready patch, should be fixed over the weekend. However, if you use -O2 only to build the compiler itself instead, it shouldn't appear. Charlie On Sat, 18 Jan 2014, Martin wrote: > Just svn updated (after make clean) trunk to revision: 26506 > > SET FPC=c:\FPC\SVN\ppc386_2_6_2.exe > make.exe all LINKSMART=1 CREATESMART=1 OPTIMIZE=1 OPT="-gl -O3 -Or > -CpPENTIUMM -OpPENTIUMM" > > And I get: > > ... > C:/FPC/SVN/trunc/compiler/ppc1.exe -XX -CX -Ur -Xs -O2 -n -O2 -Fui386 > -Fusystems -FuC:/FPC/SVN/trunc/rtl/units/i386-win32 -Fii386 -FE. > -FUi386/units/i386-win32 > -dRELEASE -gl -O3 -Or -CpPENTIUMM -OpPENTIUMM-di386 -dGDB -dBROWSERLOG > -Fux86 -Sew pp.pas > rgobj.pas(1419,22) Fatal: Internal error 20060521 > Fatal: Compilation aborted > make.exe[5]: *** [ppc386.exe] Error 1 > make.exe[5]: Leaving directory `C:/FPC/SVN/trunc/compiler' > make.exe[4]: *** [next] Error 2 > make.exe[4]: Leaving directory `C:/FPC/SVN/trunc/compiler' > make.exe[3]: *** [ppc2.exe] Error 2 > make.exe[3]: Leaving directory `C:/FPC/SVN/trunc/compiler' > make.exe[2]: *** [cycle] Error 2 > make.exe[2]: Leaving directory `C:/FPC/SVN/trunc/compiler' > make.exe[1]: *** [compiler_cycle] Error 2 > make.exe[1]: Leaving directory `C:/FPC/SVN/trunc' > make.exe: *** [build-stamp.i386-win32] Error 2 > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
