[fpc-pascal] FormatSettings not updated in Linux
Contrary to what written in docs, DefaultFormatSettings aren't adjusted to the current locale in Linux at the startup of an application both on fpc 2.6.4 and on fpc 2.7.1. One is forced to explicitly add "clocale" in the uses section of the application, in order to get the proper locale settings. Did someone forget to add cloclale to the uses section of /rtl/unix/sysutils.pp or there's another reason for this? Giuliano -- Giuliano Colla Project planning question: when it's 90% done, are we halfway or not yet? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FormatSettings not updated in Linux
On 02/01/15 13:35, Giuliano Colla wrote: > Contrary to what written in docs, DefaultFormatSettings aren't adjusted > to the current locale in Linux at the startup of an application both on > fpc 2.6.4 and on fpc 2.7.1. Where is this written? At least http://www.freepascal.org/docs-html/rtl/sysutils/defaultformatsettings.html doesn't say anything like that. > One is forced to explicitly add "clocale" in the uses section of the > application, in order to get the proper locale settings. > Did someone forget to add cloclale to the uses section of > /rtl/unix/sysutils.pp or there's another reason for this? The reason is that by design, FPC-compiled programs for Linux do not depend on libc and clocale introduces a dependency on libc. It's the same reason why you have to use the cthreads unit to get a functional thread manager under Linux. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FormatSettings not updated in Linux
On 1/2/15, Jonas Maebe wrote: > The reason is that by design, FPC-compiled programs for Linux do not > depend on libc and clocale introduces a dependency on libc. It's the > same reason why you have to use the cthreads unit to get a functional > thread manager under Linux. We need fplocale unit maybe? I tried long time ago, but failed miserably. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FormatSettings not updated in Linux
On 02/01/15 14:55, Bart wrote: > On 1/2/15, Jonas Maebe wrote: > >> > The reason is that by design, FPC-compiled programs for Linux do not >> > depend on libc and clocale introduces a dependency on libc. It's the >> > same reason why you have to use the cthreads unit to get a functional >> > thread manager under Linux. > We need fplocale unit maybe? > I tried long time ago, but failed miserably. It would probably also significantly increase the size of the binary. We now have an fpwidestring unit, but if you want to have the same functionality as with cwstring (including support for Japanese and Chinese character sets), it increases the size of your binary by several megabytes (or you have to supply several megabytes of code page conversion tables). As a result, I doubt it will be very popular. After just having spent 2 days debugging an issue in fcl-res that could have been avoided by just using the assembler instead of by reimplementing object writers from scratch, I'm even more strengthened in my conviction that it is a mistake trying to implement and reimplement everything just to make cross-compiling somewhat easier, or to avoid libc version compatibility problems on Linux that were common 15 years ago. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Error while linking
Hi, One of my project just started fail on compilation. Other projects compile fine. In lazarus message window I get only "Error: Error while linking". Normally in that case, more details were printed like "missing -lib" etc but here I get only "error while linking". Tried cleanup output dir but not helped. How to investigate this? Project dir has permissions to write. Lazarus 1.2.6 FPC 2.6.4 Kubuntu 14.04 64 bit Regards ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error while linking
On 02/01/15 15:31, Krzysztof wrote: > One of my project just started fail on compilation. Other projects > compile fine. In lazarus message window I get only "Error: Error while > linking". Normally in that case, more details were printed like "missing > -lib" etc but here I get only "error while linking". Tried cleanup > output dir but not helped. How to investigate this? Project dir has > permissions to write. Compile with -Cn, and then to manually run ppas.sh (Linux/Unix) or ppas.bat (other platforms) from the command line. Sometimes the linker messages get swallowed by the compiler (or Lazarus?) for some reason. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error while linking
On Fri, 02 Jan 2015 15:39:39 +0100 Jonas Maebe wrote: > On 02/01/15 15:31, Krzysztof wrote: > > One of my project just started fail on compilation. Other projects > > compile fine. In lazarus message window I get only "Error: Error while > > linking". Normally in that case, more details were printed like "missing > > -lib" etc but here I get only "error while linking". Tried cleanup > > output dir but not helped. How to investigate this? Project dir has > > permissions to write. > > Compile with -Cn, and then to manually run ppas.sh (Linux/Unix) or > ppas.bat (other platforms) from the command line. Sometimes the linker > messages get swallowed by the compiler (or Lazarus?) for some reason. To see all messages in Lazarus use the popup menu of the Messages window (right click). Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FormatSettings not updated in Linux
Den 02-01-2015 kl. 15:07 skrev Jonas Maebe: On 02/01/15 14:55, Bart wrote: On 1/2/15, Jonas Maebe wrote: The reason is that by design, FPC-compiled programs for Linux do not depend on libc and clocale introduces a dependency on libc. It's the same reason why you have to use the cthreads unit to get a functional thread manager under Linux. We need fplocale unit maybe? I tried long time ago, but failed miserably. It would probably also significantly increase the size of the binary. We now have an fpwidestring unit, but if you want to have the same functionality as with cwstring (including support for Japanese and Chinese character sets), it increases the size of your binary by several megabytes (or you have to supply several megabytes of code page conversion tables). As a result, I doubt it will be very popular. After just having spent 2 days debugging an issue in fcl-res that could have been avoided by just using the assembler instead of by reimplementing object writers from scratch, I'm even more strengthened in my conviction that it is a mistake trying to implement and reimplement everything just to make cross-compiling somewhat easier, or to avoid libc version compatibility problems on Linux that were common 15 years ago. Jonas I pretty much disagree on all points. Maybe it's nice if you sit on some popular flavour Linux, but relying on GNU tools and libraries is a pain point on Windows and for crosscompiling in general. For library components such as cthreads, cwstring, clocale, etc. it's nice to have a choice whether you want libc provided units. We have those already, and they mostly seem to work(?). But I think it would be nice to have both, so you could at least have a choice whether you would want to skip right over building a bunch of C. For object writers and assemblers, sure. There are probably lots of problems, but I haven't had any big issues on Windows with FPC for soon a decade. I hope that can become the case for ARM/Linux/Embedded too soon :) It just need some testing on a wider scale for all the bumps to be ironed out. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error while linking
2015-01-02 15:51 GMT+01:00 Mattias Gaertner : > > To see all messages in Lazarus use the popup menu of the > Messages window (right click). > Thank you Mattias! lgmime-2.6 was hidden in lazarus message window. Problem solved ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FormatSettings not updated in Linux
On 02/01/15 15:59, Jeppe Græsdal Johansen wrote: > Den 02-01-2015 kl. 15:07 skrev Jonas Maebe: >> After just having spent 2 days debugging an issue in fcl-res that could >> have been avoided by just using the assembler instead of by >> reimplementing object writers from scratch, I'm even more strengthened >> in my conviction that it is a mistake trying to implement and >> reimplement everything just to make cross-compiling somewhat easier, or >> to avoid libc version compatibility problems on Linux that were common >> 15 years ago. >> > I pretty much disagree on all points. Maybe it's nice if you sit on some > popular flavour Linux, Our basic "manager" units are independent of Linux flavours and should not introduce any dependencies on a particular flavour or version of Linux. > but relying on GNU tools and libraries is a pain > point on Windows and for crosscompiling in general. We have never relied on GNU libraries on Windows, and I didn't mean to imply that we should. On Windows, we do however rely on standard OS library functionality for threading, localisation etc rather than implementing it ourselves. That's what I'm in favour of. As to assemblers/linkers: in the compiler, the internal assemblers and linkers are optional, so there it doesn't really bother me. > For library components such as cthreads, cwstring, clocale, etc. it's > nice to have a choice whether you want libc provided units. We have > those already, and they mostly seem to work(?). But I think it would be > nice to have both, so you could at least have a choice whether you would > want to skip right over building a bunch of C. You don't have to build a bunch of C. You copy over the libraries from the Unix system you want to deploy on. If you don't have access to such a system, then you can't test your program either and you have bigger problems than a lack of libraries. > For object writers and assemblers, sure. There are probably lots of > problems, but I haven't had any big issues on Windows with FPC for soon > a decade. I hope that can become the case for ARM/Linux/Embedded too > soon :) I've had major problems with the integrated object writer of fcl-res both with the AIX port in the past and now with the Darwin/AArch64 port. It's not because its architecture is bad (it's not), but because it's a lot of fiddling with low level stuff for which barely any debugging tools exist, and for some details also documentation. It's just completely wasted time and effort on my part that I could have spent on doing useful things. And to top it off, you'll still need the libraries and cross-binutils (to the extent that they exist) for both targets, because neither Apple nor IBM supports syscall compatibility across OS versions (libc is their "system call interface"), and maintaining a binary writer and linker for Apple's ever changing stuff would be more or less a full time job by itself (maybe for AIX it would be more doable). > It just need some testing on a wider scale for all the bumps to be > ironed out. If you never add new targets and your existing targets stay completely static, maybe. Otherwise you keep encountering new bumps because things change slightly, or you have to implement support for new targets, which in turn also adds new bumps. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error while linking
On Fri, 2 Jan 2015 16:13:26 +0100 Krzysztof wrote: > 2015-01-02 15:51 GMT+01:00 Mattias Gaertner : > > > > > To see all messages in Lazarus use the popup menu of the > > Messages window (right click). > > > > Thank you Mattias! lgmime-2.6 was hidden in lazarus message window. Problem > solved That message should be visible in Lazarus 1.3. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FormatSettings not updated in Linux
Il 02/01/2015 13:47, Jonas Maebe ha scritto: On 02/01/15 13:35, Giuliano Colla wrote: Contrary to what written in docs, DefaultFormatSettings aren't adjusted to the current locale in Linux at the startup of an application both on fpc 2.6.4 and on fpc 2.7.1. Where is this written? At least http://www.freepascal.org/docs-html/rtl/sysutils/defaultformatsettings.html doesn't say anything like that. See here: http://www.freepascal.org/docs-html/rtl/sysutils/shortdaynames.html Giuliano -- Giuliano Colla Project planning question: when it's 90% done, are we halfway or not yet? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FormatSettings not updated in Linux
Am 02.01.2015 um 16:43 schrieb Jonas Maebe: > On 02/01/15 15:59, Jeppe Græsdal Johansen wrote: >> Den 02-01-2015 kl. 15:07 skrev Jonas Maebe: >>> After just having spent 2 days debugging an issue in fcl-res that could >>> have been avoided by just using the assembler instead of by >>> reimplementing object writers from scratch, I'm even more strengthened >>> in my conviction that it is a mistake trying to implement and >>> reimplement everything just to make cross-compiling somewhat easier, or >>> to avoid libc version compatibility problems on Linux that were common >>> 15 years ago. >>> >> I pretty much disagree on all points. Maybe it's nice if you sit on some >> popular flavour Linux, > > Our basic "manager" units are independent of Linux flavours and should > not introduce any dependencies on a particular flavour or version of Linux. I still doubt that it is possible to build a glibc-linked linux binary like the compiler which runs on all linux flavours still being in support. Just look at the pain with the IDE on linux. Bottom line in the bug tracker and on the mailing lists: if the provided IDE binary does not work for you, just do not use it, we cannot help you (I know, in this case we could switch to an external gdb and get rid of glibc but this proves only the point). > >> but relying on GNU tools and libraries is a pain >> point on Windows and for crosscompiling in general. > > We have never relied on GNU libraries on Windows, and I didn't mean to > imply that we should. On Windows, we do however rely on standard OS > library functionality for threading, localisation etc rather than > implementing it ourselves. That's what I'm in favour of. Yes, because Windows offers an reasonable OS interface for this functionality. > >> For library components such as cthreads, cwstring, clocale, etc. it's >> nice to have a choice whether you want libc provided units. We have >> those already, and they mostly seem to work(?). But I think it would be >> nice to have both, so you could at least have a choice whether you would >> want to skip right over building a bunch of C. > > You don't have to build a bunch of C. You copy over the libraries from > the Unix system you want to deploy on. If you don't have access to such > a system, then you can't test your program either and you have bigger > problems than a lack of libraries. It sounds simple like this, yes, but as far as I remember I never succeeded to build any fpc program depending on glibc for arm linux by cross compiling from windows. I guess scamp and masta can tell stories about this. > I've had major problems with the integrated object writer of fcl-res > both with the AIX port in the past and now with the Darwin/AArch64 port. > It's not because its architecture is bad (it's not), but because it's a > lot of fiddling with low level stuff for which barely any debugging > tools exist, and for some details also documentation. It's just > completely wasted time and effort on my part that I could have spent on > doing useful things. At least on Windows the internal assembler/linker are still time safers. > > And to top it off, you'll still need the libraries and cross-binutils > (to the extent that they exist) for both targets, because neither Apple > nor IBM supports syscall compatibility across OS versions (libc is their > "system call interface"), and maintaining a binary writer and linker for > Apple's ever changing stuff would be more or less a full time job by > itself (maybe for AIX it would be more doable). Actually having a Apple binary writer would FPC enable finally to cross-compile to Mac OS X ;) > >> It just need some testing on a wider scale for all the bumps to be >> ironed out. > > If you never add new targets and your existing targets stay completely > static, maybe. Otherwise you keep encountering new bumps because things > change slightly, or you have to implement support for new targets, which > in turn also adds new bumps. > For me, I do not want to miss the assembler/linker for i386/x86-64 for windows, especially because I can fix bugs easily in them which is not the case for binutils. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FormatSettings not updated in Linux
On Fri, 2 Jan 2015, Jonas Maebe wrote: On 02/01/15 14:55, Bart wrote: On 1/2/15, Jonas Maebe wrote: The reason is that by design, FPC-compiled programs for Linux do not depend on libc and clocale introduces a dependency on libc. It's the same reason why you have to use the cthreads unit to get a functional thread manager under Linux. We need fplocale unit maybe? I tried long time ago, but failed miserably. It would probably also significantly increase the size of the binary. We now have an fpwidestring unit, but if you want to have the same functionality as with cwstring (including support for Japanese and Chinese character sets), it increases the size of your binary by several megabytes (or you have to supply several megabytes of code page conversion tables). As a result, I doubt it will be very popular. After just having spent 2 days debugging an issue in fcl-res that could have been avoided by just using the assembler instead of by reimplementing object writers from scratch, I'm even more strengthened in my conviction that it is a mistake trying to implement and reimplement everything just to make cross-compiling somewhat easier, or to avoid libc version compatibility problems on Linux that were common 15 years ago. I will not argue about the linker and assembler, but I am not sure your libc argument is quite correct. It is about binary compatibility. If gnu C lib devs change the alignment of some struct, they just do it. All C programs can be recompiled, relinked, and that is it. Some client libs make this problem even bigger (apache, mysql, probably others). Pascal programmers are in a bigger predicament. A Free Pascal programmer would need to wait till we update our import headers of libc, make a new release and so on. It creates a bigger maintenance problem and ties us to the libc release cycle. By contrast, like Microsoft with the Windows API, the Linux kernel people maintain a much stricter backward compatibility for userland tools. So, from my point of view, not relying on Libc and using direct kernel access on Linux is the best option. That you miss out on some userland functionality of Libc such as localization, and for this need to rely on glue code units, is something that I take into the bargain. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Binary code generated for Integer and PtrInt
Does it make sense to use PtrInt instead of Integer for optimization or code size reasons? In other words, does the compiler generate faster or smaller code in 64-bit CPUs for the native integer size? Does it depend on architecture? Regards, Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FormatSettings not updated in Linux
In our previous episode, Jonas Maebe said: > After just having spent 2 days debugging an issue in fcl-res that could > have been avoided by just using the assembler instead of by > reimplementing object writers from scratch, I do like the object writers mostly from a support viewpoint. The FPC as-a-system is a lot more equal and deterministic across installations, and one or several dimensions from versioning matrix disappear. Moreover there is hope to avoid having long time unfixable issues like: http://www.freepascal.org/faq.var#unix-ld219 > I'm even more strengthened in my conviction that it is a mistake trying to > implement and reimplement everything just to make cross-compiling somewhat > easier, > or to avoid libc version compatibility problems on Linux that were > common 15 years ago. The libc discussion is IMHO different. Last week, the FPC_USE_LIBC became 11 years old. There are hardly user experiences on Linux. (admitted, usually some bugs have accumulated causing a first movers disadvantage). Frankly, I guess nobody is really that interested, and the current solution works fine enough. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Binary code generated for Integer and PtrInt
Am 02.01.2015 um 19:31 schrieb Juha Manninen: > Does it make sense to use PtrInt instead of Integer for optimization or code > size reasons? Hard to say, but I wouldn't expect a benefit because bigger data types means also more cache pollution. > In other words, does the compiler generate faster or smaller code in 64-bit > CPUs for the native > integer size? Normally the code is a little bit smaller (less sign extensions), but the data footprint is bigger. > Does it depend on architecture? The comments above are probably valid for all 64 bit CPUs except alpha which is not supported by fpc. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Binary code generated for Integer and PtrInt
On 02/01/15 21:16, Florian Klämpfl wrote: > Am 02.01.2015 um 19:31 schrieb Juha Manninen: >> Does it make sense to use PtrInt instead of Integer for optimization or code >> size reasons? > > Hard to say, but I wouldn't expect a benefit because bigger data types means > also more cache pollution. > >> In other words, does the compiler generate faster or smaller code in 64-bit >> CPUs for the native >> integer size? > > Normally the code is a little bit smaller (less sign extensions), but the > data footprint is bigger. > >> Does it depend on architecture? > > The comments above are probably valid for all 64 bit CPUs except alpha which > is not supported by fpc. And except for AArch64, where 32 bit will, in principle, also be more efficient than 64 bit in all cases. It can even use the lower 8/16/32 bit of a register as index in a memory references and sign/zero-extend + optionally multiply it with the access size. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Binary code generated for Integer and PtrInt
Am 02.01.2015 um 21:34 schrieb Jonas Maebe: > On 02/01/15 21:16, Florian Klämpfl wrote: >> Am 02.01.2015 um 19:31 schrieb Juha Manninen: >>> Does it make sense to use PtrInt instead of Integer for optimization or >>> code size reasons? >> >> Hard to say, but I wouldn't expect a benefit because bigger data types means >> also more cache pollution. >> >>> In other words, does the compiler generate faster or smaller code in 64-bit >>> CPUs for the native >>> integer size? >> >> Normally the code is a little bit smaller (less sign extensions), but the >> data footprint is bigger. >> >>> Does it depend on architecture? >> >> The comments above are probably valid for all 64 bit CPUs except alpha which >> is not supported by fpc. > > And except for AArch64, where 32 bit will, in principle, also be more > efficient than 64 bit in all cases. It can even use the lower 8/16/32 > bit of a register as index in a memory references and sign/zero-extend + > optionally multiply it with the access size. But integer operations are done always on 64 bit in FPC? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Binary code generated for Integer and PtrInt
On 02/01/15 22:12, Florian Klämpfl wrote: > Am 02.01.2015 um 21:34 schrieb Jonas Maebe: >> > And except for AArch64, where 32 bit will, in principle, also be more >> > efficient than 64 bit in all cases. It can even use the lower 8/16/32 >> > bit of a register as index in a memory references and sign/zero-extend + >> > optionally multiply it with the access size. > But integer operations are done always on 64 bit in FPC? If you have var l: longint; a: array of word; begin a[l]:= ... end then the index will still be a longint. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FormatSettings not updated in Linux
Florian Klämpfl wrote: Am 02.01.2015 um 16:43 schrieb Jonas Maebe: On 02/01/15 15:59, Jeppe Græsdal Johansen wrote: Den 02-01-2015 kl. 15:07 skrev Jonas Maebe: After just having spent 2 days debugging an issue in fcl-res that could have been avoided by just using the assembler instead of by reimplementing object writers from scratch, I'm even more strengthened in my conviction that it is a mistake trying to implement and reimplement everything just to make cross-compiling somewhat easier, or to avoid libc version compatibility problems on Linux that were common 15 years ago. I pretty much disagree on all points. Maybe it's nice if you sit on some popular flavour Linux, Our basic "manager" units are independent of Linux flavours and should not introduce any dependencies on a particular flavour or version of Linux. I still doubt that it is possible to build a glibc-linked linux binary like the compiler which runs on all linux flavours still being in support. Just look at the pain with the IDE on linux. Bottom line in the bug tracker and on the mailing lists: if the provided IDE binary does not work for you, just do not use it, we cannot help you (I know, in this case we could switch to an external gdb and get rid of glibc but this proves only the point). Noting that I asked about something related to this in fpc-devel the other day, I assure you that I feel your pain. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FormatSettings not updated in Linux
Michael Van Canneyt wrote: On Fri, 2 Jan 2015, Jonas Maebe wrote: in my conviction that it is a mistake trying to implement and reimplement everything just to make cross-compiling somewhat easier, or to avoid libc version compatibility problems on Linux that were common 15 years ago. I will not argue about the linker and assembler, but I am not sure your libc argument is quite correct. It is about binary compatibility. If gnu C lib devs change the alignment of some struct, they just do it. All C programs can be recompiled, relinked, and that is it. It's not just that. Some of the GNU/C crowd make the confident assertion that a bug-free compiler /cannot/ generate code that breaks alignment, despite the fact that the majority whine if they can't pack their data structures exactly how they want. I'm trying to wean my colleagues off SPARC, I'm no longer convinced that the pain is worth it. Does anybody have any Debian/multiarch issues that they want to air? I seem to have caught the attention of one of the admins. -8<- > > Multiarch obviously introduces its own problems. Could you provide some examples? Multiarch seems unrelated to the portability of Debian. In fact I think it has a more positive impact on portability, since for less portable software you can workaround that by installing binaries from another architecture and running them directly where possible or use qemu-user to emulate them where not possible. ->8- -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Binary code generated for Integer and PtrInt
Am 02.01.2015 um 23:02 schrieb Jonas Maebe: > On 02/01/15 22:12, Florian Klämpfl wrote: >> Am 02.01.2015 um 21:34 schrieb Jonas Maebe: And except for AArch64, where 32 bit will, in principle, also be more efficient than 64 bit in all cases. It can even use the lower 8/16/32 bit of a register as index in a memory references and sign/zero-extend + optionally multiply it with the access size. >> But integer operations are done always on 64 bit in FPC? > > If you have > > var > l: longint; > a: array of word; > begin > a[l]:= ... > end > > then the index will still be a longint. > True, so even less reasons to use PtrInt. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
