[fpc-devel] Re: Purpose of uses ... in?
Date: Tue, 13 Jul 2010 11:48:27 +0200 (CEST) From: mar...@stack.nl (Marco van de Voort) Subject: Re: [fpc-devel] Re: Purpose of uses ... in? To: FPC developers' list fpc-devel@lists.freepascal.org Message-ID: 20100713094827.af1ac17...@turtle.stack.nl Content-Type: text/plain; charset=US-ASCII In our previous episode, Schindler Karl-Michael said: thread saying that they use this functionality (both in FPC and in Delphi). Therefore I don't think it is a good idea to remove or change it. If different functionality is desired, I think it's better to add a different construct rather than using the same construct but with a different meaning. When checking, I found that it is used for all files in UltraStar Deluxe. With or without paths? IOW does it only change casing? Then it might not be that bad. (though it doesn't deserve a beauty price either). Probably that is because of Kylix, that doesn't have FPC's in case of doubt, just lowercase all filenames escape, resulting in the need to micromanage it manually using IN. I have no solid idea about why it is used in the first place. Fortunately, only relative paths are given. I have to check, whether it changes casing. If so, it should be easy to fix, in particular since Delphi is used for Windows only, whereas Linux and Mac OS X are fpc. I'll investigate, whether we can actually get rid of it. Thanks for pointing out the issue. MiSchi___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
In our previous episode, Hans-Peter Diettrich said: One must keep in mind though that he probably measures on a *nix, and there is a reason why on Windows the make cycle takes twice the time on Windows. One of these issues are memory mapped files, that can speed up file access a lot (I've been told), perhaps because it maps directly to the system file cache? As said, I always had the feeling that it was binary startup time, and directory I/O rather than basic blockwrite/read speed. Most files are tens of kbs max, and will probably be read entirely anyway by the system. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
Hans-Peter Diettrich wrote:
Jeppe Johansen schrieb:
I think that'll only complicate things. I think the compiler should be
able to do anything, down to lowest level. Just like you have CLI,
HLT, FXSTOR, WRMSR, etc instruction support in x86
Then many users will wonder why their application with included ASM from
somewhere else (DOS time...) will compile fine, but fails to run :-(
Users, who do embedded stuff (without OS) NEED FULL control over the
controller. I agree with Jeppe, that the compiler should not restrict
something. Otherwise, you would need eventually ugly workarounds like
the following (on ARM7 with an old fpc 2.3.1), which could easily be
done in gcc btw.
procedure Disable;
{
mrs r0, cpsr
orr r0, r0, #0x80
msr cpsr, r0
}
begin
asm
.long 0xE10F
.long 0xE3800080
.long 0xE129F000
end;
end;
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On 07/13/2010 06:27 PM, Jonas Maebe wrote: b) indeed also because of the searching for filenames with different cases. It might sometimes indeed make sens to not be forced to use the same name for the unit and the file containing it's source code. So using in with just a file name, without the obviously non-portable directory notation, and thus (hopefully) having the compiler search in the normal unit search path does make sense. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
On 07/13/2010 11:18 PM, Hans-Peter Diettrich wrote: When we rely on an OS file chache, we can read all files entirely into memory, instead of using buffered I/O. Loading the complete file instead of parts of it would do unnecessary memory copies. In fact I suppose using file mapping instead of read (and maybe write) should improve speed in many cases. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
On 07/13/2010 05:19 PM, Hans-Peter Diettrich wrote: It may be a good idea to implement different models, that either read entire files... read - map -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
On 07/14/2010 12:00 AM, Hans-Peter Diettrich wrote: One of these issues are memory mapped files, that can speed up file access a lot (I've been told), perhaps because it maps directly to the system file cache? AFAIK File Mapping is used a lot and very successfully with Linux, but it _is_ available with NTFS. No idea if, here, the implementation is done in a way this it's really fast. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
On 07/13/2010 05:38 PM, Hans-Peter Diettrich wrote: I don't know details about this CPU, but possibly priviledged operations (and registers) are not part of the CPU definition, because these cannot be used in ordinary applications. It may be a good idea to create multiple code generators, for machines that can be used either for non-priviledged (application) or privileged (system, driver...) coding. At least a priviledge level should be passed to the compiler and assembler, so that it can flag the need for privileged instructions in the given source code. If necessary, you can always code the very unusual instructions manually to hex code and provide them as DC in the ASM code. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
On 07/14/2010 11:02 AM, Bernd Mueller wrote: ... which could easily be done in gcc btw. ... I'm quite sure that FPC's ASM can compile hex constants (using DC ???) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
Michael Schnell wrote: On 07/14/2010 11:02 AM, Bernd Mueller wrote: ... which could easily be done in gcc btw. ... I'm quite sure that FPC's ASM can compile hex constants (using DC ???) that is not the point. You don't wont to bother with (error prone) hex constants, but want to use the regular assembler mnemonics. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
In our previous episode, Michael Schnell said: On 07/14/2010 12:00 AM, Hans-Peter Diettrich wrote: One of these issues are memory mapped files, that can speed up file access a lot (I've been told), perhaps because it maps directly to the system file cache? AFAIK File Mapping is used a lot and very successfully with Linux, but it _is_ available with NTFS. No idea if, here, the implementation is done in a way this it's really fast. I've tried it long ago in win2000, and maybe even XP. If you linearly access the files with a large enough blocksize (8 or 16kb), it was hardly measurable. (+/- 300MB files). Probably if you go linearly, the readahead is already near efficient. But FPC might not adhere to this scheme, I don't know if FPC currently loads the whole file or leaves the file open while it processes e.g. a .inc. If it doesn't load the whole file, opening others triggers head movement (if not in cache) that could be avoided. Mapping does not change that picture (the head still has to move if you access a previously unread block). Mapping mainly is more about - zero-copy access to file content - and uses the VM system to cache _already accessed_ blocks. The compiler does not do enough I/O to make the first worthwhile, the second is irrelevant to the compiler;s access pattern. The only way it could matter if the memory mapped file reads more sectors speculatively after a page access, but I don't know if that is the case, it might be as well be less. (since normal File I/O is more likely to be linear) So in summary, I think _maybe_ reading the whole file always might win a bit in filereading performance. I don't expect memory mapping to do so. The whole file hypothesis could be easily testable (if applies at all) by increasing the buffersize. But if I understand finput.pas properly, FPC already uses a 64k buffersize (which is larger than most sourcefiles), so I don't expect much gain here. And, worse, I think that even if that results in a gain is dwarfed by directory operations (searching files, creating new files) and binary startup time. (of compiler but also other tools). (*) empirical time for a core2 to move a large block. (source+dest cache) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
On 14 Jul 2010, at 10:49, Bernd Mueller wrote: Michael Schnell wrote: On 07/14/2010 11:02 AM, Bernd Mueller wrote: ... which could easily be done in gcc btw. ... I'm quite sure that FPC's ASM can compile hex constants (using DC ???) that is not the point. You don't wont to bother with (error prone) hex constants, but want to use the regular assembler mnemonics. quite right! especially with a processor like the ARM, where it keeps, er.., improving its instruction set between each generation of hardware! rgds, Geoffrey Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
Well, this is off topic, but ARM is quite a bit backwards compatible. All ARM versions are backwards compatible(if we ignore thumb, which fpc doesn't support anyway) :) Geoffrey Barton skrev: On 14 Jul 2010, at 10:49, Bernd Mueller wrote: Michael Schnell wrote: On 07/14/2010 11:02 AM, Bernd Mueller wrote: ... which could easily be done in gcc btw. ... I'm quite sure that FPC's ASM can compile hex constants (using DC ???) that is not the point. You don't wont to bother with (error prone) hex constants, but want to use the regular assembler mnemonics. quite right! especially with a processor like the ARM, where it keeps, er.., improving its instruction set between each generation of hardware! rgds, Geoffrey Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bottlenecks]
Hans-Peter Diettrich wrote: Memory management can not normally be parallelized. What's this then: http://topsoftwaresite.nl/ You are talking cows dung. It is actually in production at one of the largest stockbrokers in Europe. You should have written : It is hard to do parallization The link is for a very good scaling memorymanager over multi processor systems provided the software is also well written. Ivo's memorymanager is even lock free, if you use it properly. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
Michael Schnell wrote: On 07/13/2010 06:27 PM, Jonas Maebe wrote: b) indeed also because of the searching for filenames with different cases. It might sometimes indeed make sens to not be forced to use the same name for the unit and the file containing it's source code. So using in with just a file name, without the obviously non-portable directory notation, and thus (hopefully) having the compiler search in the normal unit search path does make sense. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.830 / Virus Database: 271.1.1/3003 - Release Date: 07/13/10 20:36:00 Yes, but that defeats unit aliasing by renaming: like uses foo in bar.pas instead of uses foo (implies in foo.pas). Did somebody mention this in the discussion? Programmers are not very imaginative in naming. It is plainly helpfull to be able to rename a file if another file with a different content. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
In our previous episode, Thaddy said: Yes, but that defeats unit aliasing by renaming: like uses foo in bar.pas instead of uses foo (implies in foo.pas). Did somebody mention this in the discussion? Programmers are not very imaginative in naming. It is plainly helpfull to be able to rename a file if another file with a different content. I really wonder what the point is of such hack. You still have to walk all references to add ( in ' '), so you might as well do a proper rename. In the past it was sometimes used to have long unit names refer to 8.3 filenames, but I haven't really cared about 8.3 for almost a decade now. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
Hi May I ask why do we need a CONFIG_OABI_COMPAT=y in the kernel to for fpc to work on arm-linux? regards Nataraj On Wed, Jul 14, 2010 at 3:42 PM, Jeppe Johansen jepj...@kom.aau.dk wrote: Well, this is off topic, but ARM is quite a bit backwards compatible. All ARM versions are backwards compatible(if we ignore thumb, which fpc doesn't support anyway) :) Geoffrey Barton skrev: On 14 Jul 2010, at 10:49, Bernd Mueller wrote: Michael Schnell wrote: On 07/14/2010 11:02 AM, Bernd Mueller wrote: ... which could easily be done in gcc btw. ... I'm quite sure that FPC's ASM can compile hex constants (using DC ???) that is not the point. You don't wont to bother with (error prone) hex constants, but want to use the regular assembler mnemonics. quite right! especially with a processor like the ARM, where it keeps, er.., improving its instruction set between each generation of hardware! rgds, Geoffrey Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
Nataraj S Narayan wrote: Hi May I ask why do we need a CONFIG_OABI_COMPAT=y in the kernel to for fpc to work on arm-linux? The fpc target for eabi is called 'armel', the 'arm' target compiles for oabi. Regards, Micha On Wed, Jul 14, 2010 at 3:42 PM, Jeppe Johansen jepj...@kom.aau.dk mailto:jepj...@kom.aau.dk wrote: Well, this is off topic, but ARM is quite a bit backwards compatible. All ARM versions are backwards compatible(if we ignore thumb, which fpc doesn't support anyway) :) Geoffrey Barton skrev: On 14 Jul 2010, at 10:49, Bernd Mueller wrote: Michael Schnell wrote: On 07/14/2010 11:02 AM, Bernd Mueller wrote: ... which could easily be done in gcc btw. ... I'm quite sure that FPC's ASM can compile hex constants (using DC ???) that is not the point. You don't wont to bother with (error prone) hex constants, but want to use the regular assembler mnemonics. quite right! especially with a processor like the ARM, where it keeps, er.., improving its instruction set between each generation of hardware! rgds, Geoffrey Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org mailto:fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org mailto:fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org mailto:fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
Marco van de Voort wrote: In our previous episode, Thaddy said: Ok, you write always cheerful, I was merely pointing out it is not clean, but useful :)) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On Wed, Jul 14, 2010 at 7:49 AM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Thaddy said: Yes, but that defeats unit aliasing by renaming: like uses foo in bar.pas instead of uses foo (implies in foo.pas). Did somebody mention this in the discussion? Programmers are not very imaginative in naming. It is plainly helpfull to be able to rename a file if another file with a different content. I really wonder what the point is of such hack. You still have to walk all references to add ( in ' '), so you might as well do a proper rename. In the past it was sometimes used to have long unit names refer to 8.3 filenames, but I haven't really cared about 8.3 for almost a decade now. I prefer to use search path instead of in, but I think it's a good idea to use aliases for units. As Thaddy said Programmers are not very imaginative in naming. I agree. I always nominate my units with prefix to haven't name conflicts with other units. MD. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [off list] Re: [fpc-devel] Compiler bottlenecks]
A fact has nothing to do with emotions. Check that code. Then write a review. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
On 14/07/10 11:54, Nataraj S Narayan wrote: Hi May I ask why do we need a CONFIG_OABI_COMPAT=y in the kernel to for fpc to work on arm-linux? Do you still need this with the latest fpc compiled for eabi? Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
Bernd Mueller schrieb: Users, who do embedded stuff (without OS) NEED FULL control over the controller. I agree with Jeppe, that the compiler should not restrict something. In this case I don't understand how FPC is useful at all. I cannot create executable files for such a device... Otherwise, you would need eventually ugly workarounds like the following (on ARM7 with an old fpc 2.3.1), which could easily be done in gcc btw. C has some language constructs for OS or driver implementation, e.g. interrupt. Should we add these to the OPL, to make FPC/OPL compete with gcc/C? It would be nice, though, to have an Pascal DDK for Windows ;-) Abstract: Even if it's easy to add privileged instructions to every machine, the ordinary user IMO should be protected from using them. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
Michael Schnell schrieb: One of these issues are memory mapped files, that can speed up file access a lot (I've been told), perhaps because it maps directly to the system file cache? AFAIK File Mapping is used a lot and very successfully with Linux, but it _is_ available with NTFS. I've heard it the opposite way, that it has become available for *certain* Linux distros as well ;-) And Delphi (Windows!) users reported noticeable performance boosts (factor 3+), even if nobody ever came up with non-trivial example code, including fallbacks for restricted (32 bit) address space. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
Marco van de Voort schrieb: In our previous episode, Michael Schnell said: On 07/14/2010 12:00 AM, Hans-Peter Diettrich wrote: One of these issues are memory mapped files, that can speed up file access a lot (I've been told), perhaps because it maps directly to the system file cache? AFAIK File Mapping is used a lot and very successfully with Linux, but it _is_ available with NTFS. No idea if, here, the implementation is done in a way this it's really fast. I've tried it long ago in win2000, and maybe even XP. If you linearly access the files with a large enough blocksize (8 or 16kb), it was hardly measurable. (+/- 300MB files). Probably if you go linearly, the readahead is already near efficient. Windows offers certain file attributes for that purpose, that notify the OS of intended (strictly) sequential file reads - what would allow to read-ahead more file content into the system cache. Mapping does not change that picture (the head still has to move if you access a previously unread block). Mapping mainly is more about - zero-copy access to file content - and uses the VM system to cache _already accessed_ blocks. - and backs up RAM pages by the original file, they never will end up in the swap file. The whole file hypothesis could be easily testable (if applies at all) by increasing the buffersize. But if I understand finput.pas properly, FPC already uses a 64k buffersize (which is larger than most sourcefiles), so I don't expect much gain here. I see the biggest benefit in many possible optimization in the scanner and parser, which can be implemented *only if* an entire file resides in memory. When memory management and (string) copies really are as expensive as some people say, then these *additional* optimizations should give the really achievable speed gain. IMO we should give these additional optimziations an try, independent from the use of MMF. When an entire source file is loaded into memory, we can measure the time between reading the first token and hitting EOF in the parser, eliminating all uncertain MMF/file cache timing. It's only a matter of the acceptance of such a refactored model, since it's a waste of time when it never will become part of the trunk, for already known reasons. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
Thaddy schrieb: Programmers are not very imaginative in naming. It is plainly helpfull to be able to rename a file if another file with a different content. Just in the FPC compiler case many unit names are hard coded, while the files to use reside e.g. in a specific machine directory, selected in the search path. When it becomes desireable to replace only one of these files, as happened to me, then a solution could be to name that replacement file differently from its contained unit name. Then it would be helpful to allow for exchangable file names, at least at project/program level. Only then one can be sure that a specific file is used across the entire project, regardless of all other files in the search path. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
Michael Schnell schrieb: On 07/13/2010 11:18 PM, Hans-Peter Diettrich wrote: When we rely on an OS file chache, we can read all files entirely into memory, instead of using buffered I/O. Loading the complete file instead of parts of it would do unnecessary memory copies. How that? Of course the entire file uses more address space than a smaller buffer, but when the file is parsed, the same number of bytes must be copied to local memory in either case. And when the entire file sits in memory, the scanner and parser operations can be optimized for much higher speed, by e.g. removing unnecessary address calculations, bounds checks and string copies. In fact I suppose using file mapping instead of read (and maybe write) should improve speed in many cases. Therefore my question about a platform independent solution for MMF. At least we could implement a MMF (source) file class, that emulates this feature on platforms without MMF support. Support also could be restricted to map only entire files, for the compiler - otherwise the management of mapping windows would degrade the achievable performance. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bottlenecks]
Thaddy schrieb: Hans-Peter Diettrich wrote: Memory management can not normally be parallelized. What's this then: http://topsoftwaresite.nl/ You are talking cows dung. It is actually in production at one of the largest stockbrokers in Europe. You should have written : It is hard to do parallization My point is: when multiple threads try to acquire an new memory block at the same time, and they happen to find the same gap, then only one of these can win. The other threads must continue or - in the worst case - restart their search for the next matching gap. So IMO only a low *chance* for such concurrent tries can result in *typically* better performance of such a memory management model. With increasing memory fragmentation the collision chance increases as well. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
Hans-Peter Diettrich schrieb: Bernd Mueller schrieb: Users, who do embedded stuff (without OS) NEED FULL control over the controller. I agree with Jeppe, that the compiler should not restrict something. In this case I don't understand how FPC is useful at all. I cannot create executable files for such a device... LD for such targets can create .hex files, those can be loaded into such devices. I used FPC already for a control application with an LPC2124 without any OS. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On Wed, Jul 14, 2010 at 10:03 AM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Thaddy schrieb: Programmers are not very imaginative in naming. It is plainly helpfull to be able to rename a file if another file with a different content. Just in the FPC compiler case many unit names are hard coded, while the files to use reside e.g. in a specific machine directory, selected in the search path. When it becomes desireable to replace only one of these files, as happened to me, then a solution could be to name that replacement file differently from its contained unit name. Then it would be helpful to allow for exchangable file names, at least at project/program level. Only then one can be sure that a specific file is used across the entire project, regardless of all other files in the search path. I am surprised as there is no conflict of names of units in the FPC / Lazarus. There are names very short, which could be used as variable names... MD. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bottlenecks]
Hans-Peter Diettrich schrieb: Thaddy schrieb: Hans-Peter Diettrich wrote: Memory management can not normally be parallelized. What's this then: http://topsoftwaresite.nl/ You are talking cows dung. It is actually in production at one of the largest stockbrokers in Europe. You should have written : It is hard to do parallization My point is: when multiple threads try to acquire an new memory block at the same time, and they happen to find the same gap, then only one of these can win. The other threads must continue or - in the worst case - restart their search for the next matching gap. So IMO only a low *chance* for such concurrent tries can result in *typically* better performance of such a memory management model. With increasing memory fragmentation the collision chance increases as well. Just look at the FPC memory manager: to avoid this some structures like the freelist are thread specific. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On 2010-07-14 16:26, Marcos Douglas wrote: I am surprised as there is no conflict of names of units in the FPC / Lazarus. There are names very short, which could be used as variable names... Is there, still, a platform (where FPC can be used) that restricts filenames to being so short? Cheers, Adem ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
Hans-Peter Diettrich wrote: Bernd Mueller schrieb: Users, who do embedded stuff (without OS) NEED FULL control over the controller. I agree with Jeppe, that the compiler should not restrict something. In this case I don't understand how FPC is useful at all. I cannot create executable files for such a device... sure, fpc can. I have a custom designed board running with an ARM9 (on Linux) and an ARM7 (no OS) which were both programmed in fpc. I only had to use gcc for the kernel modules. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
In our previous episode, Hans-Peter Diettrich said: Probably if you go linearly, the readahead is already near efficient. Windows offers certain file attributes for that purpose, that notify the OS of intended (strictly) sequential file reads - what would allow to read-ahead more file content into the system cache. I can vaguely remember something like that too. It is a matter of hacking that into the RTL, and then measure make cycle (requires a few reboots to preclude caching) Mapping does not change that picture (the head still has to move if you access a previously unread block). Mapping mainly is more about - zero-copy access to file content - and uses the VM system to cache _already accessed_ blocks. - and backs up RAM pages by the original file, they never will end up in the swap file. If swapping enters the picture, then all these savings are peanuts, so we assume that is absent. The whole file hypothesis could be easily testable (if applies at all) by increasing the buffersize. But if I understand finput.pas properly, FPC already uses a 64k buffersize (which is larger than most sourcefiles), so I don't expect much gain here. I see the biggest benefit in many possible optimization in the scanner and parser, which can be implemented *only if* an entire file resides in memory. When memory management and (string) copies really are as expensive as some people say, then these *additional* optimizations should give the really achievable speed gain. That's easily said, but often when you enter the details, you have to often make compromises. And sacrifice speed. IMO we should give these additional optimziations an try, independent from the use of MMF. When an entire source file is loaded into memory, we can measure the time between reading the first token and hitting EOF in the parser, eliminating all uncertain MMF/file cache timing. It's only a matter of the acceptance of such a refactored model, since it's a waste of time when it never will become part of the trunk, for already known reasons. I don't think we ever going to give an up front carte blanche for a massive rewrite to go into trunk. That is simply not sane. A subsmission will always be judged on performance and maintainability before being admitted. If this bothers you, try to find smart ways to phase the changes, and limit yourself to a few things at a time, and don't try to speedoptimize I/O, change parser, allow multiple frontends etc, all at the same time. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bottlenecks]
On 2010-07-14 13:29, Thaddy wrote: The link is for a very good scaling memorymanager over multi processor systems provided the software is also well written. Ivo's memorymanager is even lock free, if you use it properly. I hadn't heard about TopMemory till now. I read the PDF that comes in the download and it seems to be making quite a lot of the right noises. The one thing that caught my eye that might or might not be reason to worry is this: Memory Usage Part of the speedup that TopMemory achieves comes from allocating more memory then necessary and grouping allocations that are in the same sizerange. Therefore your application will use more memory when it runs. If you care more about low memory usage then TopMemory is not for you. It is optimized for performance at the cost of memory. Which is not usually a problem with the amounts of memory even regular PC’s have these days. There were a couple of charts showing how enredibly useful TopMemory could be when speed is the overriding factor, but no indication about how hungry it is for memory. Any comments on that? Cheers, Adem ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
In our previous episode, Hans-Peter Diettrich said: And Delphi (Windows!) users reported noticeable performance boosts (factor 3+), even if nobody ever came up with non-trivial example code, including fallbacks for restricted (32 bit) address space. Yeah, and no wonder, most probably benchmarked against plain textfile I/O with its default 128 byte buffer. One can actually spice FPC/Delphi text I/O up quite nicely with settextbuf to 8k (the last time I tested, in P4 3 GHz times, higher values didn't really matter anymore) The compiler however already has its own 64k buffering system. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Messages overhead
IMO compiler messages slow down compilation a lot. When messages are not really output (prevented by message level...), then a lot of procedure calls and string operations can be avoided, when the message preparation is bypassed at all. verbose.Message1 ff. could check the level (and exit accordingly) prior to any further work. MayBeLoadMessageFile could be moved into Msg2Comment in most cases, and again a quick check (or inline) can prevent calling this subroutine at all. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Messages overhead
Op Wed, 14 Jul 2010, schreef Hans-Peter Diettrich: IMO compiler messages slow down compilation a lot. How do you know this, did you benchmark or is it just your opinion? When messages are not really output (prevented by message level...), then a lot of procedure calls and string operations can be avoided, when the message preparation is bypassed at all. verbose.Message1 ff. could check the level (and exit accordingly) prior to any further work. MayBeLoadMessageFile could be moved into Msg2Comment in most cases, and again a quick check (or inline) can prevent calling this subroutine at all. Sounds reasonable to me, but wether it will speed up compilation is another question. Anyway, simply write a patch, could be a nice excercise to get started with compiler development. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Compiler bottlenecks
Hans-Peter Diettrich wrote on Wed, 14 Jul 2010: Marco van de Voort schrieb: Mapping does not change that picture (the head still has to move if you access a previously unread block). Mapping mainly is more about - zero-copy access to file content - and uses the VM system to cache _already accessed_ blocks. - and backs up RAM pages by the original file, they never will end up in the swap file. Apart from specific scenarios, memory mapping can easily be slower than direct reads. The main reason is that you get round trips to the OS via hardware interrupts whenever you trigger a page fault, instead of doing one or more (relatively cheap compared to interrupts) system calls. The potential savings of a few memory copies, especially for files in the range of 2-500kb, is very unlikely to compensate for this. I see the biggest benefit in many possible optimization in the scanner and parser, which can be implemented *only if* an entire file resides in memory. Then just read it into a buffer in one shot. When memory management and (string) copies really are as expensive as some people say, then these *additional* optimizations should give the really achievable speed gain. a) the memory management overhead primarily comes from allocating and freeing machine instruction (and to a lesser extent node tree) instances b) the string copy cost I mentioned primarily comes from getting symbol names for the purpose of generating rtti and assembler symbol names Jonas PS: please update the subject when changing the topic This message was sent using IMP, the Internet Messaging Program. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On Wed, 14 Jul 2010 12:23:00 -0300 Marcos Douglas m...@delfire.net wrote: On Wed, Jul 14, 2010 at 11:45 AM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Wed, 14 Jul 2010 10:26:11 -0300 Marcos Douglas m...@delfire.net wrote: [...] I am surprised as there is no conflict of names of units in the FPC / Lazarus. Of course there are. For example unit dialogs. This is solved by the search path. And if do you have your own unit Dialogs too, what you do? Me? I would rename my unit. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On Wed, Jul 14, 2010 at 12:32 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Wed, 14 Jul 2010 12:23:00 -0300 Marcos Douglas m...@delfire.net wrote: On Wed, Jul 14, 2010 at 11:45 AM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Wed, 14 Jul 2010 10:26:11 -0300 Marcos Douglas m...@delfire.net wrote: [...] I am surprised as there is no conflict of names of units in the FPC / Lazarus. Of course there are. For example unit dialogs. This is solved by the search path. And if do you have your own unit Dialogs too, what you do? Me? I would rename my unit. Hum... Okay, but if this unit (Dialogs, in your example) is part of another framework, not yours? MD. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On Wed, 14 Jul 2010 12:51:29 -0300 Marcos Douglas m...@delfire.net wrote: On Wed, Jul 14, 2010 at 12:32 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Wed, 14 Jul 2010 12:23:00 -0300 Marcos Douglas m...@delfire.net wrote: On Wed, Jul 14, 2010 at 11:45 AM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Wed, 14 Jul 2010 10:26:11 -0300 Marcos Douglas m...@delfire.net wrote: [...] I am surprised as there is no conflict of names of units in the FPC / Lazarus. Of course there are. For example unit dialogs. This is solved by the search path. And if do you have your own unit Dialogs too, what you do? Me? I would rename my unit. Hum... Okay, but if this unit (Dialogs, in your example) is part of another framework, not yours? I would tell the devels of the framework. And if they want to keep it, then I can not use both Dialogs units. I had not yet the case where I needed both and can not rename both. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
Marco van de Voort schrieb: I don't think we ever going to give an up front carte blanche for a massive rewrite to go into trunk. That is simply not sane. ACK. I'm more concerned about work that is blacklisted for some reason. A subsmission will always be judged on performance and maintainability before being admitted. If this bothers you, try to find smart ways to phase the changes, and limit yourself to a few things at a time, and don't try to speedoptimize I/O, change parser, allow multiple frontends etc, all at the same time. Just this is hard to obey, when I see so many details that could be improved. Will it do harm when I create more than one branch, e.g. one for general optimizations? Can other people contribute to such an branch as well? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bottlenecks]
Jonas Maebe schrieb: This technique is well known and implemented by virtually all memory managers these days (it's called pooling, or freelists). FPC's default memory manager also does that (up to a certain allocation size). Unless you create huge pools, it does not affect total memory much. Even large pools are preferrable over chains of blocks, because following a chain can cause many page faults, at least it trashes the caches. This is a known problem with garbage collectors (Java...), which can cause huge amounts of data being loaded into RAM, even if the current process actually doesn't use them. This is really bad for an garbage collector, which has been activated due to a shortage on memory - and it might be one reason for the use of compacting GC in .NET. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Compiler bottlenecks
On 2010-07-14 18:21, Jonas Maebe wrote: Apart from specific scenarios, memory mapping can easily be slower than direct reads. The main reason is that you get round trips to the OS via hardware interrupts whenever you trigger a page fault, instead of doing one or more (relatively cheap compared to interrupts) system calls. The potential savings of a few memory copies, especially for files in the range of 2-500kb, is very unlikely to compensate for this. Now that SSDs (which are near enough to random access memory) are getting to be cheap enough to be affordable for mainstream use (plus the much higher bandwidths of SATA3, USB3) is it feasible to further optimize IO speeds for the compiler at this stage? Cheers, Adem ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] arm embedded cortexm3 procedure address
disassembling from an elf file produce by FPC cross-assembling for arm embedded, an empty procedure:- procedure UART0int:nostackframe; begin end; looks like this:- 01a4 P$UARTTEST_UART0INT: 1a4: 46f7mov pc, lr 1a6: 46c0nop (mov r8, r8) if I grab the address of this procedure as a constant in assembler (or assign it to a pointer using @; same result):- asm .long UART0int end; the resulting constant disassembles as:- 1bc:01a5.word 0x01a5 which seems to be one greater than the address of the procedure. Is this right? If so, why? also, why does the compiler sometimes add a 'nop' to the end of a procedure (as above)? Geoffrey ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexm3 procedure address
Geoffrey Barton wrote on Wed, 14 Jul 2010: the resulting constant disassembles as:- 1bc:01a5.word 0x01a5 which seems to be one greater than the address of the procedure. Is this right? Yes. If so, why? To identify the code as Thumb code. also, why does the compiler sometimes add a 'nop' to the end of a procedure (as above)? The default alignment of routines is 4 bytes. And it's most likely the assembler or linker that adds the nop, rather than the compiler. Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
14.07.2010 15:44, Hans-Peter Diettrich: [...] Abstract: Even if it's easy to add privileged instructions to every machine, the ordinary user IMO should be protected from using them. Oh come on, the user who insert asm instuctions manually doesn't need such a naive 'protection'. I'm pretty sure no-one would like such 'care'. Its almost like saying: the ordinary user might try to do i := 1; j := 0; k := i div j; and therefore generally most of integer arithmetic should also be restricted etc etc. Nikolai DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
Nikolai Zhubr wrote on Wed, 14 Jul 2010: 14.07.2010 15:44, Hans-Peter Diettrich: [...] Abstract: Even if it's easy to add privileged instructions to every machine, the ordinary user IMO should be protected from using them. Oh come on, the user who insert asm instuctions manually doesn't need such a naive 'protection'. If a patch is submitted to add these opcodes, it will be applied. Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On Wed, Jul 14, 2010 at 12:59 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Wed, 14 Jul 2010 12:51:29 -0300 Marcos Douglas m...@delfire.net wrote: On Wed, Jul 14, 2010 at 12:32 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Wed, 14 Jul 2010 12:23:00 -0300 Marcos Douglas m...@delfire.net wrote: On Wed, Jul 14, 2010 at 11:45 AM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Wed, 14 Jul 2010 10:26:11 -0300 Marcos Douglas m...@delfire.net wrote: [...] I am surprised as there is no conflict of names of units in the FPC / Lazarus. Of course there are. For example unit dialogs. This is solved by the search path. And if do you have your own unit Dialogs too, what you do? Me? I would rename my unit. Hum... Okay, but if this unit (Dialogs, in your example) is part of another framework, not yours? I would tell the devels of the framework. And if they want to keep it, then I can not use both Dialogs units. I had not yet the case where I needed both and can not rename both. Then, another example: You want to work with ZIP and RAR format files. So, imagine you found, on the net, 2 libs, one for each type format. The problem is each lib uses the same name to main unit e.g. zip.pas. Both libs are very used by million of people on the world and they, the developers do not want to change the name of yours unit. And now, you understood the little problem? MD. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On Wed, 14 Jul 2010 13:54:10 -0300 Marcos Douglas m...@delfire.net wrote: [...] I would tell the devels of the framework. And if they want to keep it, then I can not use both Dialogs units. I had not yet the case where I needed both and can not rename both. Then, another example: You want to work with ZIP and RAR format files. So, imagine you found, on the net, 2 libs, one for each type format. The problem is each lib uses the same name to main unit e.g. zip.pas. Both libs are very used by million of people on the world and they, the developers do not want to change the name of yours unit. Do you have the links to the two projects? And now, you understood the little problem? Of course I understand the problem, but I have not yet encountered it in a real project. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On Wed, Jul 14, 2010 at 2:05 PM, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Wed, 14 Jul 2010 13:54:10 -0300 Marcos Douglas m...@delfire.net wrote: [...] I would tell the devels of the framework. And if they want to keep it, then I can not use both Dialogs units. I had not yet the case where I needed both and can not rename both. Then, another example: You want to work with ZIP and RAR format files. So, imagine you found, on the net, 2 libs, one for each type format. The problem is each lib uses the same name to main unit e.g. zip.pas. Both libs are very used by million of people on the world and they, the developers do not want to change the name of yours unit. Do you have the links to the two projects? No, that was an example... And now, you understood the little problem? Of course I understand the problem, but I have not yet encountered it in a real project. So, if we can to put an alias to unit names, there are no more problem. I had this problem in real projects. Always happen with the units that have very short names or names that are very generic. Therefore, most of the frameworks put a prefix in the units. BTW, I use my prefix for units of project (e.g. myparser, mytextutils, mydb, etc). If I create a lib, I choose other prefix. MD. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Blackfin support
In our previous episode, Hans-Peter Diettrich said: I don't think we ever going to give an up front carte blanche for a massive rewrite to go into trunk. That is simply not sane. ACK. I'm more concerned about work that is blacklisted for some reason. One reason the more to phase and modularize your efforts. It is less all or nothing. As far as the blacklisting goes. There is only one way to counter skepticism. Show the goods, and it better be good. Core is not unreasonable (*), but it will take more than simply pointing at some totally out of sync, totally overhauled branch, and saying done. Free Pascal is not a one way show, and that means cooperation and communication. People's opionions differ. A subsmission will always be judged on performance and maintainability before being admitted. If this bothers you, try to find smart ways to phase the changes, and limit yourself to a few things at a time, and don't try to speedoptimize I/O, change parser, allow multiple frontends etc, all at the same time. Just this is hard to obey, when I see so many details that could be improved. Will it do harm when I create more than one branch, e.g. one for general optimizations? Can other people contribute to such an branch as well? Keep in mind that running many branches long term will only increase the amount of management to keep them in sync, makes it more difficult to merge the finished results back etc. Focus your efforts, on as small phases as possible. And don't ever consider other people helping you in your planning, since it will nearly always be less than expected. (*) well except me obviously, but I won't be reviewing compiler submissions, so it is easier for me to say this all. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
In our previous episode, Marcos Douglas said: And if they want to keep it, then I can not use both Dialogs units. I had not yet the case where I needed both and can not rename both. Then, another example: You want to work with ZIP and RAR format files. So, imagine you found, on the net, 2 libs, one for each type format. The problem is each lib uses the same name to main unit e.g. zip.pas. Both libs are very used by million of people on the world and they, the developers do not want to change the name of yours unit. I would say thats is a pretty strange situation, since those million people will all have the same problem, and won't like adding xxx in 'yyy' to all uses, and edit one of those packages to fix that everytime a new release comes out. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
In our previous episode, Marcos Douglas said: And now, you understood the little problem? Of course I understand the problem, but I have not yet encountered it in a real project. So, if we can to put an alias to unit names, there are no more problem. I had this problem in real projects. Always happen with the units that have very short names or names that are very generic. Therefore, most of the frameworks put a prefix in the units. Note that the in syntax is not a cure all similar to prefixing and making sure that that all filenames are unique. This because there are still two units with the same name in the searchpath, and one mistake in fixing the uses clauses will cause problems. Moreover, I agree mostly with Mattias in that dealing quickly with rare cases is a lot less work then heavy handed approaches to 'fix' the problem. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On Wed, Jul 14, 2010 at 2:21 PM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Marcos Douglas said: And if they want to keep it, then I can not use both Dialogs units. I had not yet the case where I needed both and can not rename both. Then, another example: You want to work with ZIP and RAR format files. So, imagine you found, on the net, 2 libs, one for each type format. The problem is each lib uses the same name to main unit e.g. zip.pas. Both libs are very used by million of people on the world and they, the developers do not want to change the name of yours unit. I would say thats is a pretty strange situation, since those million people will all have the same problem... Remember, this is an example... ... and won't like adding xxx in 'yyy' to all uses, and edit one of those packages to fix that everytime a new release comes out. Exactly! On Wed, Jul 14, 2010 at 2:27 PM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Marcos Douglas said: And now, you understood the little problem? Of course I understand the problem, but I have not yet encountered it in a real project. So, if we can to put an alias to unit names, there are no more problem. I had this problem in real projects. Always happen with the units that have very short names or names that are very generic. Therefore, most of the frameworks put a prefix in the units. Note that the in syntax is not a cure all similar to prefixing and making sure that that all filenames are unique. This because there are still two units with the same name in the searchpath, and one mistake in fixing the uses clauses will cause problems. You're right :( And if we can do that: uses zip IN '/units/my/zip.pas' AS myzip; zip IN '/units/lib/zip/zip.pas' AS ziplib; Now, I can point the real path and I can use 'n' units with the same name. What do you think about it? Moreover, I agree mostly with Mattias in that dealing quickly with rare cases is a lot less work then heavy handed approaches to 'fix' the problem. Yes, I agree with you. MD. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
On 14.07.2010 18:54, Marcos Douglas wrote:
On Wed, Jul 14, 2010 at 12:59 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Wed, 14 Jul 2010 12:51:29 -0300
Marcos Douglas m...@delfire.net wrote:
On Wed, Jul 14, 2010 at 12:32 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Wed, 14 Jul 2010 12:23:00 -0300
Marcos Douglas m...@delfire.net wrote:
On Wed, Jul 14, 2010 at 11:45 AM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Wed, 14 Jul 2010 10:26:11 -0300
Marcos Douglas m...@delfire.net wrote:
[...]
I am surprised as there is no conflict of names of units in the FPC /
Lazarus.
Of course there are. For example unit dialogs. This is solved by the
search path.
And if do you have your own unit Dialogs too, what you do?
Me? I would rename my unit.
Hum... Okay, but if this unit (Dialogs, in your example) is part of
another framework, not yours?
I would tell the devels of the framework.
And if they want to keep it, then I can not use both Dialogs units. I
had not yet the case where I needed both and can not rename both.
Then, another example:
You want to work with ZIP and RAR format files. So, imagine you found,
on the net, 2 libs, one for each type format. The problem is each lib
uses the same name to main unit e.g. zip.pas.
Both libs are very used by million of people on the world and they,
the developers do not want to change the name of yours unit.
create a rar.pas containing only the line:
{$include rar/zip.pas}
compile with:
fpc -Un rar.pas
-UnDo not check where the unit name matches the file name
regards
Stefan
And now, you understood the little problem?
MD.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
signature.asc
Description: OpenPGP digital signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
Marcos Douglas schrieb:
On Wed, Jul 14, 2010 at 2:55 PM, Stefan Kisdaroczi ki...@hispeed.ch wrote:
create a rar.pas containing only the line:
{$include rar/zip.pas}
compile with:
fpc -Un rar.pas
-UnDo not check where the unit name matches the file name
Interesting...
Anyone ever used this?
I'm still using it. Or make a symlink:
ln -s rar/zip.pas rar.pas
In combination with {$L xzy.o} and 'external name ...' you can do
wonderful things. Don't do this at home! (maybe at work :-)
Stefan
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] Purpose of uses ... in?
Hello Mattias, Wednesday, July 14, 2010, 7:05:01 PM, you wrote: And now, you understood the little problem? MG Of course I understand the problem, but I have not yet encountered MG it in a real project. I can vaguely remember a case like this in Delphi several years ago, but I think the problem was a precompiled .dcu which I can not rename. Is this possible ? -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Messages overhead
Daniël Mantione schrieb: IMO compiler messages slow down compilation a lot. How do you know this, did you benchmark or is it just your opinion? Common knowledge, proved by experience. [...] Sounds reasonable to me, but wether it will speed up compilation is another question. Anyway, simply write a patch, It's not a matter of an simple patch :-( The message ID has to be re-encoded in a way, that allows to determine e.g. the message level immediately. All this currently is done only after text substitution, by inspection of the returned string. could be a nice excercise to get started with compiler development. How is message encoding and composition related to compiler development? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Compiler bottlenecks
Jonas Maebe schrieb: Apart from specific scenarios, memory mapping can easily be slower than direct reads. The main reason is that you get round trips to the OS via hardware interrupts whenever you trigger a page fault, instead of doing one or more (relatively cheap compared to interrupts) system calls. The potential savings of a few memory copies, especially for files in the range of 2-500kb, is very unlikely to compensate for this. When the file resides in the OS file cache, no page faults will occur unless the file was removed from the cache. If not, every access request has to do disk I/O, resulting in process switching etc., so that the page faults are neglectable. I see the biggest benefit in many possible optimization in the scanner and parser, which can be implemented *only if* an entire file resides in memory. Then just read it into a buffer in one shot. That's just what I suggested, for a first test :-) When memory management and (string) copies really are as expensive as some people say, then these *additional* optimizations should give the really achievable speed gain. a) the memory management overhead primarily comes from allocating and freeing machine instruction (and to a lesser extent node tree) instances b) the string copy cost I mentioned primarily comes from getting symbol names for the purpose of generating rtti and assembler symbol names May be, we'll see... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Parser rewrite
Marco van de Voort schrieb: Will it do harm when I create more than one branch, e.g. one for general optimizations? Can other people contribute to such an branch as well? Keep in mind that running many branches long term will only increase the amount of management to keep them in sync, makes it more difficult to merge the finished results back etc. These branches could be trashed again, when they proved useless or after merge into trunk. I could create separate projects in another repository as well, but these could not be merged back so easily. Focus your efforts, on as small phases as possible. ACK. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Messages overhead
Hans-Peter Diettrich wrote: Daniël Mantione schrieb: IMO compiler messages slow down compilation a lot. How do you know this, did you benchmark or is it just your opinion? Common knowledge, proved by experience. I had benchmarked that, and submitted some patching some (already long) time ago. Those patches inserted calls to CheckVerbosity before blocks of messages of rarely used verbosity, like V_Tried. This way it was possible to get rid of majority of rarely seen messages, while struggling with more common verbosities seems impractical (those are few anyway). Message processing indeed includes some overhead, but this is not #1 bottleneck to worry about. Maybe #10 or so. Most processing is done in shortstrings, which is fast. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
