Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Op Tue, 5 Mar 2013, schreef Henry Vermaak: Damn. My custom config kernel compiles stable kernels in 3-5 minutes on a quad core Xeon, which isn't bad. Did you build with the standard config? What is the standard config? As the operating system is Scientific Linux 6, I'm using the config for the standard 2.6.32 kernel with as little modifications as possible to use it for 3.3.2. I don't have a 4 core Xeon system, but I tried to simulate it on a dual Xeon 2670 system by only using 4 cores: [root@node037 src]# time numactl --physcpubind=0-3 make -j 4 ... real11m45.748s user38m30.405s sys 4m48.634s Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Op Tue, 5 Mar 2013, schreef Mark Morgan Lloyd: I've not had an opportunity to try this, but my understanding is that on a Sun E10K with something like 256 400MHz processors the Linux kernel built in around 20 seconds. I've had it build in about 3 minutes on a system with 16x 80MHz processors, but that was in the days of kernel 2.2 and there was probably less than half today's number of files involved. Well... I put that into question. I don't have a 256 core system, but I have a quad Opteron 6376 system, 64 cores @ 2.4 GHz is quite a bit of compute power. Compiling kernel 3.3.2: [root@node016 linux-3.3.2]# time make -j 64 ... real1m54.823s user77m14.178s sys 11m32.109s To minutes to build a kernel is still fast though :) Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Sun, 3 Mar 2013, schreef Marcos Douglas: On Sun, Mar 3, 2013 at 5:16 PM, Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: On 2013-03-03 19:47, Florian Klämpfl wrote: First 10 m of a marathon done. Is that 'miles' or 'meters'? ;-) Sad. Instead of fight, why not walking together? IMHO Martin Schreiber is doing a great job using these comparisons and some improvements could be made in FPC... but he is making a mistake in their approach of how to present FPC's defects. Martin: I do not know nothing about compilers, but I know the Florian Klämpfl will do nothing about you're saying because do you do not have proposed improvements! You are only showing the Delphi/Kylix speed is extremely superior (even knowing that Delphi do not is multiplataform and do not have the complexity that FPC has, AFAIK). One more thing: try do not thinking only in MSEgui in your thoughts, in your great ideas. IMHO the MSEgui should be part of FPC, somehow, but... FPC Team: Try to hear Martin otherwise, because he is a great developer with great ideas. That FPC is slower than Delphi is a result of many concious decisions: * FPC has a lot of passes through the node tree - allows more features and transformations * FPC has a more layered code generation (hlcg, cg, cpu specific overrides) - allows manu CPU architectures, JVM and more * FPC has an advanced register allocator. Allows speedy code and many CPU architectures. * FPC has external debug information. Due its nature, this debug info requires processing power. As these are concious decisions, there is no quick fix. This doesn't mean no attention has been made to the compiler speed, many efforts have been put into profiling and optimizing the algorithms. For the rest, one has to accept FPC as it is. If FPC was inferior to Delphi, we would not have had this discussion. Further, global bennchmarks of my million line program takes long to compile are not helpfull at all in diagnosing performance problems. (Or bugs, or other issues). Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef Martin Schreiber: In MSEgui development I am happy if users report what they need in their daily work and what is inconvenient in current MSEgui implementation. I then try to examine the problem, find out how it can be solved and implement an universal solution based on what I learned from the conrete real world example. I do not expect that users provide patches, reproducible testcases are enough. If the users provide patches there is a big risk, that they fix their current problem only instead to find an orthogonal improvement. And the quality of the code maybe is not always the best. ;-) Understood. What if your users submit issues that are fundamental to your UTF16-decision? For example shortstrings would be more compact and faster. I suspect you are not going to change MSEIDE to another approach. It's the same here. Compiler speed is lower than Delphi due to design decisions, that cannot be easily altered. Optimization is always possible, but the low hanging fruit is gone, because as said, extensive time has already been spent into compiler speed. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef Martin Schreiber: On Monday 04 March 2013 12:05:37 Florian Klämpfl wrote: Am 04.03.2013 01:00, schrieb Graeme Geldenhuys: 4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That is just too a huge performance difference to justify. Yes, we all know the argument about more platforms, maintainable code etc, but that couldn't possible be the only reason for such a huge speed difference. Somewhere there is a serious bottleneck(s), or the FPC team simply disregard optimization completely. From why I have heard them say, the latter is more likely [unfortunately]. You completely miss the point. If there are only approx 25 features/properties which make the compiler each 10% slower than in total FPC is 10 (1.1^25=10.9) times slower than before. Is this correct? It implies that every feature/property uses 100% of the total process. And if it is true it is absolutely necessary to stop adding features soon because 1.1^50 = 117.4. ;-) Some features only request procesing power if you use them. However, the features in Florian's list require continuous processing power. Two examples how features can impact overall speed: 1. Operator overloading Operators are some of the most common tokens in source code. Without operator overloading, if you parse an operator, you simply generate a tree node. With operator overloading, for each operator that you parse, you have to traverse all loaded units to check if the operator is overloaded. If there are 50 units loaded, this means 50 symtable lookups, simply because the operator might be overloaded. For each operator overload candidate that is found, the compiler has need to check for many possible type conversions to see if the candidate can actually be used. The situation with Pascal type conversion has grown increasingly complex over the years. For example almost any type can be converted into a variant, and a variant can be converted into almost any type. This requires all kinds of special handling, not only to do the right thing, but also not to do ineffcient type conversions. So even if you don't use operator overloading or variants at all, they do affect the compiler speed. 2. Layered code generation The split of the code generation in a high-level and low-level layer, means that for every node that is processed, first the high-level virtual method is called, which in turn calls the lower level virtual method. Thus you have an addition virtual method call for evey node processed. The low level code generator, which is still mostly CPU independent, again calls virtual methods from the abstract assembler layer to generate the actual opcodes. The abstract assembler in turn, has again to worry about multiple assemblers which can emit the final object file. Now each layer not just has its own code, but also its own type and therefore conversion functions need to be called (for example a def has a size), which is converted into a cgsize and ultimately into an opsize. Obviously, if you just had one layer, and could output instruction directly to the object file, you can save a lot of performance. While you might develop for just one platform, the fact that many of them are supported, costs compiler performance. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef Mattias Gaertner: Is there no cache? Something like: Give me all '+' operator overloads in all used units of interface, implementation. Actually a cache was part of my symtable redesign years ago. It never made it into the compiler. But it was designed with a slightly different idea in mind: If you do a symtable lookup you can have many symtables to process: - With statement - Local variables - Parameters - Object symtables, one per inherited object - Unit symtables, two per loaded unit (interface implementation) The idea was to remove this lineair search through all symtables. The concept never made it in the final compiler. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef Mattias Gaertner: Can this be cached? Maybe the compiler can reuse some results? No. The symtable lookups can be parsed, but the candidate selection, which I believe is actually more compute intensive, is dependend on the actual situation where the operator is called, for example the types of the left and right part, which would not yield very high hit rates. Originally the compiler was doing the candidate selection with a simple loop through the parameters that took the first suitable match. When the type conversion matters became more complex the Unable to determine overloaded procedure error became increasingle annoying. At some point I did redesign it with scoring system: Each candidate that is compatible gets assigned a score how well the overloaded procedure matches the parameters. The best match is selected. At that point, the compiler became highly intelligent in finding the correct overloaded procedure/operator, but the amount of computing power involved with overloading went up: Instead of selecting the first candidate, we need to compute the score for all candidates. This even requires floating point arithmetic. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef Sven Barth: Did you work out the concept somewhere? It quite likely there is some archived copy of it in the old CVS repository, but I am sure it's better to start from scratch. The compiler was still using objects at that time, for example. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef Mattias Gaertner:
On Mon, 4 Mar 2013 14:37:40 +0100 (CET)
Daniël Mantione daniel.manti...@freepascal.org wrote:
Op Mon, 4 Mar 2013, schreef Mattias Gaertner:
Can this be cached?
Maybe the compiler can reuse some results?
No. The symtable lookups can be parsed, but the candidate selection, which
I believe is actually more compute intensive, is dependend on the actual
situation where the operator is called, for example the types of the left
and right part, which would not yield very high hit rates.
Why not?
I guess that a high percentage are only a few type,operator,type
combinations.
interface
function substring(x,y:unicodestring):cardinal;
function substring(x,y:ansistring):cardinal;
function substring(x,y:shortstring):cardinal;
implementation
{...}
var a:unicodestring;
b,c:ansistring;;
begin
a:='banana-split';
b:='banana-split';
c:='banana';
writeln(substring('banana','banana-split'));
writeln(substring(b,a));
writeln(substring(a,a));
end.
... we would have 3 cache lookups, and 3 misses. Then we have end of
scope, the symtablestack changes, and we therefore have to invalidate the
cache. In this example, a cache would therefore slowdown instead of
speed-up.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef Sven Barth: It seems that I only achived around 0.1 to 0.2 seconds when compiling the compiler (manually, with -B). But it's now checking only unit System and unit constexp (part of the compiler) for operator overloads. It's also interesting to see that not every unit triggers a search for operators... So this is +/- 2%? Not bad. This fits perfectly into what Florian did explain: Each of the features adds just a bit of compile time. There is no quick solution to make FPC much faster. But each optimization can help a bit. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Op Mon, 4 Mar 2013, schreef luiz americo pereira camara: Is the bigger code just a side effect of a cross platform RTL or the generated code is really bigger / slower? There are again multiple reasons. One is indeed that the code is multiple-platform and therefore some abstraction exist in the RTL. For example, widestring and threat managers mean more code, but make things more flexible. Further: FPC tries to implement every Delphi feature, but also has unique features. Some of these unique features require runtime overhead and thus cause a bigger RTL. Assembler implementations can reduce the size of the RTL, but FPC tries to focus on portability and has therefore relatively less assembler in the RTL. Code generation quality is another factor. While FPC has in absolute terms more optimization power than Delphi, it misses a few crucial optimizations. For example, we don't have loop induction, which allows Delphi to beat FPC in code that stresses this. Further, especially regarding Lazarus, the design of the LCL simply means that a lot of code is pulled into the executable. The Delphi VCL offers more possibilities for smart linking away unneeded code. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Op Sun, 3 Mar 2013, schreef Martin Schreiber: BTW, a significant percentage of the time is waiting for FPC compiling because FPC normally crashes without -B. I think you should focus your efforts on getting those bugs fixed, such as by submitting bug reports that allow reproduction of the problem with programs as simple as you can get them to show the problem. It is completely unrealistic that FPC will get the same compiler speed as Delphi. FPC will become slower in the future for sure, because the compiler will execute more algorithms to generate better code. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Op Fri, 25 Jan 2013, schreef Michael Schnell: On 01/25/2013 11:12 AM, Michael Van Canneyt wrote: Pchar ? You seem to miss my point: the n'th printable character in an utf-8 coded string (may same be stored as a pchar or a string) starts at the m'th byte (m=n). To find m for a given n you need to scan all bytes m. Thus a loop such as for I = 1 to 10 do begin n = Integer (random(10)); c = myString[n]; end; Is rather fast with ANSI coded Strings. When myString is coded in utf-8, it obviously provides silly code byte instead of printable characters, and replacing the term myString[n] by a straight forward function searching for the n'th printable character will be very slow. Yes, it is a known fact that this is a weakness of UTF-8. Consider transforming the string to UTF-16, UTF-32 or even an internal datastructure before doing the random access. Random access inside UTF-8 is an algorithmic time complexity issue. A language extension can only be a band-aid for that. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Op Sat, 26 Jan 2013, schreef Alexander Klenin: With this in mind, consider a user who wants to iterate over the following array: var a: array [1..5] of Integer = (1, 2, 9, 4, 5); In my proposal, he should write: var v, i: Integer; begin for a in a index i do Writeln(i, ' ', v); end. Well... I fail to see the improvement over old fashioned: for i:=low(a) to high(a) do writeln(i,' ',a[i]); Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Op Sat, 26 Jan 2013, schreef Alexander Klenin: var a: array [1..5] of Integer = (1, 2, 9, 4, 5); In my proposal, he should write: var v, i: Integer; begin for v in a index i do Writeln(i, ' ', v); end. In this case I just write for i:=low(a) to high(a) do writeln(i,' ',a[i]); Consider these arguments: 1) Even for simple arrays, depending on array element type, and optimizer implementation, for-in can be more efficient since it can avoid multiplication for element access. True, but it shouldn't. Loop induction is such a well documented optimization that implementation of that optimization (could be a nice job for a student) is by far preferable over mutilating the language. 2) If a is a function of another complex expression returning an array, then for-in may be much more efficient and compact Again true, but again easy to avoid: temp variable, with statement, common subexpression elimination. Again these are all preferable over mutilating the language. 3) If a is an associative array (so i is a String), then the traditional form of loop is not even possible. Disagree. You need to define a mapping between an ordinal type and the index type. This is always possible (otherwise for-in would be impossible to implement). 4) If there is no uniform method for iterating over containers, then each container will define its own method, with the end result that the language will be *more* complex for the user, who will have to remember all these methods. This I consider a valid argument, and it affects the fundament of what a for loop is. A for loop iterates over the keys only, while the values are retrieved by [] syntax. This is perfectly possible even for non-numeric keys as we have properties that allow you to do a['elephant']. The for-in syntax violates this fundamental property by returning values, which means there is a lack of a key. The fundamentalistic view then says we should not have for-in in Pascal, because it changes the fundamental property of a for-loop. For pragmantic reasons the for-in syntax got supported. However, when using it you discover the lack of keys. So you want to repair something that's already broken by design. The question becomes, which is worse? Further mutilation? Or stick to the basics? Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
Op Sat, 26 Jan 2013, schreef Alexander Klenin:
On Sat, Jan 26, 2013 at 5:12 AM, Daniël Mantione
daniel.manti...@freepascal.org wrote:
Consider these arguments:
1) Even for simple arrays, depending on array element type,
and optimizer implementation, for-in can be more efficient since it
can avoid multiplication for element access.
True, but it shouldn't. Loop induction is such a well documented
optimization that implementation of that optimization (could be a nice job
for a student) is by far preferable over mutilating the language.
I argee. Still, for the general container such an optimization is
hard-to-impossible to implement.
?? For the general container figher['ninja'] would not be implemented by
multiplication.
2) If a is a function of another complex expression returning an
array, then for-in may be much more efficient and compact
Again true, but again easy to avoid: temp variable, with statement, common
subexpression elimination. Again these are all preferable over mutilating
the language.
with statement of of course not help (try it).
If you cannot use with directly, wrap the array inside a record.
CSE might help, but is tricky across function boundaries -- function
must be first proven to be pure,
which is non-trivial in Pascal.
temp variable is, of course, always a solution -- but so is using while loop
or even labels and goto. I am tying to make Pascal higher-level language,
as opposed to, e.g. C, which is determined to stay at low level.
I understand your goal, which is commendable. The challenge is to do it in
a way that doesn't turn Pascal in something it is not.
Please try to define a mapping between String and Integer :)
const integer2fighter:array[0..3] of
string=('knight','ninja','samurai','swordman');
function fighter2integer(const s:string):integer;
begin
{implement binary search}
end;
4) If there is no uniform method for iterating over containers, then
each container will define its own method,
with the end result that the language will be *more* complex for the
user, who will have to remember all these methods.
This I consider a valid argument, and it affects the fundament of what a for
loop is. A for loop iterates over the keys only, while the values are
retrieved by [] syntax. This is perfectly possible even for non-numeric keys
as we have properties that allow you to do a['elephant'].
First, for-in loop is not a for-loop. It is unfortunate that due to the need to
avoid new reserved words, for war chosen instead of more logical
foreach or even for each.
But nevertheless, they should not be confused.
Similarly, I have chosen index instead of more logical key,
which tricked some developers into thinking that I am talking about
indeger indexes only.
Second, accessing the associative array element via key has non-trivial cost,
which is avoided by using foreach-type loops.
The for-in syntax violates this fundamental property by returning values,
which means there is a lack of a key. The fundamentalistic view then says we
should not have for-in in Pascal, because it changes the fundamental
property of a for-loop.
fundamentalistic is a right word here.
Yes... because it's wrong to always stick to principles if practical
problems are to be solved. But it's also wrong to add too much pragmatic
exceptions: With software it becomes hard to maintain, with programmings
languages it becomes unelegant and hard to learn.
Pascal was such a breakthough in the 1970's because of its elegance. That
should always be kept in mind when extending the language. (And has been
forgotten too often unfortunately.)
For pragmantic reasons the for-in syntax got supported. However, when using
it you discover the lack of keys. So you want to repair something that's
already broken by design.
I do not see why it is broken -- only because it is contrary to the
fundamentalist view?
Bottom line: yes. Language design is a lot about esthetics. Having many
syntaxes for things as simple as a for loop is bad tasted. The amount of
syntax is getting out of hand.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
Op Tue, 25 Sep 2012, schreef Cephas Atheos: [My apologies for the previous message attempt - obviously the list server doesn't handle html at all, and I could have checked for that first. Sorry for the block of base64!] G'day everyone, As you may be aware, there are a number of significant problems with the FPC community site. For new users, it's a bit of a minefield, and isn't a really good introduction to the wonderful FPC community. I'd like to offer my support and assistance in cleaning up the pages, fixing links and server errors, and generally helping to bring the site (possibly kicking and screaming! :) up to scratch. Hi! I'm fully aware of limitations, and happy to take take help, but please understand I am skeptical to plans like let's install PhpBB and those are not fundamental plans. The FPC community predates most forums on the internet and if I'm right the first messages date from 1999. It maintains full backward compatibility (even old URL's of the previous generation software) still work, scales well and is resonably hacker proof. So work has to be either on improving the current system, or a proper thought out plan to replace it with another well working system that can last again for well over a decade. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] stellaris launchpad
Op Sun, 16 Sep 2012, schreef Luca Olivetti: but I don't know the outcome. Is it currently possible to develop software for that mcu with freepascal? As far as I know the Cortex M series cannot run generic ARM code; it only understands the Thumb2 instruction set. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] enums and integer auto conversion
Op Tue, 11 Sep 2012, schreef Alexander Klenin: On Tue, Sep 11, 2012 at 8:03 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: If you want to do that, you need to add a layer in between that converts the sets into integer bitmasks in a reliable, portable and future-proof way. How about packed sets? Do they have well-defined memory layout? If not, then maybe they should? Sets, are a bit more complicated: Their binary layout is defined in Borland documentation, but this one of the few issues were FPC didn't follow Borland. FPC has smallsets, up to 32 items and longsets, up to 256 items. This is how it is documented in FPC documentation. Packed is ignored on sets and I don't see a need for a packed set with a different binary representation, but *should* sets every become unreliable in binary representation, I would agree with you that there is a need for a packed set that is reliable. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] enums and integer auto conversion
Op Mon, 10 Sep 2012, schreef Den Jean: On Monday 10 September 2012 20:18:52 Vincent Snijders wrote: If it is the combination of enum, then the type of the parameter is set of enum. Ahum, I am talking about passing combinations of enums values (usually bitmasks, assigned enums, some assigned enums are already combinations of other) to C or C++. Sets are not binary compatible for that. They should be. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] enums and integer auto conversion
Op Mon, 10 Sep 2012, schreef Jonas Maebe: On 10 Sep 2012, at 22:06, Daniël Mantione wrote: On Monday 10 September 2012 20:18:52 Vincent Snijders wrote: If it is the combination of enum, then the type of the parameter is set of enum. Ahum, I am talking about passing combinations of enums values (usually bitmasks, assigned enums, some assigned enums are already combinations of other) to C or C++. Sets are not binary compatible for that. They should be. No, sets are an opaque data type. Their internal format is undefined. I knew you would answer to that :) While, I disagree that a set is opaque, but, we can skip that discussion. What's going on here is that, wether it is a good idea or not, the implementor of the QT interface units is trying to provide Pascal data types to its user. Given the fact you are doing that, a set of enum is IMO as reasonable as other weak type to strong type mappings. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] enums and integer auto conversion
Op Mon, 10 Sep 2012, schreef Jonas Maebe: If you want to do that, you need to add a layer in between that converts the sets into integer bitmasks in a reliable, portable and future-proof way. Yes! Let's also convert integers to enums with a case statement rather than typecast, just in case the compiler may not count enums from zero in the future ;) Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] enums and integer auto conversion
Op Mon, 10 Sep 2012, schreef Jonas Maebe: On 10 Sep 2012, at 23:12, Daniël Mantione wrote: Op Mon, 10 Sep 2012, schreef Jonas Maebe: If you want to do that, you need to add a layer in between that converts the sets into integer bitmasks in a reliable, portable and future-proof way. Yes! Let's also convert integers to enums with a case statement rather than typecast, just in case the compiler may not count enums from zero in the future ;) You can explicitly define the ordinal values of enumerations if you depend on that sort of stuff (which afaik the Qt units in fact do). That's a rewriting of history, as we invented that feature. Obviously people were writing interfaces to external libraries before that. Were those programmers wrong? Not at all, they could succesfully rely on guaranteed binary representations in Borland manuals. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode in the RTL (my ideas)
Op Thu, 23 Aug 2012, schreef Hans-Peter Diettrich: Daniël Mantione schrieb: Op Wed, 22 Aug 2012, schreef Felipe Monteiro de Carvalho: On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber mse00...@gmail.com wrote: I am not talking about Unicode. I am talking about day by day programming of an average programmer where the live is easier with utf-16 than with utf-8. Unicode is not done by using pos() instead of character indexes. I think everybody knows my opinion, I stop now. Please be clear in the terminogy. Don't say live is easier with utf-16 than with utf-8 if you don't mean utf-16 as it is. Just say live is easier with ucs-2 than with utf-8, then everything is clear that you are talking about ucs2 and not true utf-16. That is nonsense. * There are no whitespace characters beyond widechar range. This means you can write a routine to split a string into words without bothing about surrogate pairs and remain fully UTF-16 compliant. How is this different for UTF-8? Your answer exactly demonstrates how UTF-16 can result in better Unicode support: You probably consider the space the only white-space character and would have written code that only handles the space. In Unicode you have the space, the non-breaking space, the half-space and probably a few more that I am missing. * There are no characters with uppper/lowercase beyond widechar range. That means if you write cade that deals with character case you don't need to bother with surrogate pairs and still remain fully UTF-16 complaint. How expensive is a Unicode Upper/LowerCase conversion per se? I'd expect a conversion would be quite a bit faster in UTF-16, as can be a table lookup per character rather than a decode/re-encode per character. But it's not about conversion per se, everyday code deals with character case in a lot more situations. * You can group Korean letters into Korean syllables, again without bothering about surrogate pairs, as Korean is one of the many languages that is entirely in widechar range. The same applies to English and UTF-8 ;-) Selected languages can be handled in special ways, but not all. I'd disagree, because there are quite a few codepoints that can be used for English texts beyond #128, like i.e. currency symbols, or ligatures, but suppose I'd follow your reasoning, the list of languages your Unicode aware software will handle properly is: * English If are interrested in proper multi-lingual support... you won't get very far. In UTF-16 only few of the 6000 languages in the world need codepoints beyond the basic multi-lingual plane. In other words you get very far. You mentioned Korean syllables splitting - is this a task occuring often in Korean programs? Yes, in Korean this is very important, because Korean letters are written in syllables, so it's a very common conversion. There are both Unicode points for letters and for syllables. For example people when people type letters on the keyboard, you receive the letter unicode points. If you send those directly to the screen you see the individual letters; that's not correct Korean writing, you want to convert to syllables and send the Unicode points for syllables to the screen. At the begin of computer-based publishing most German texts were hard to read, due to many wordbreak errors. In western-languages, syllables are only important for word-breaks and our publishing software contains advanced syllable splitting algorithms. You'd better not use that code for Korean texts, because there exists no need to break words in that script. In general... different language, different text processing algorithms... But another point becomes *really* important, when libraries with beforementioned Unicode functions are used: The application and libraries should use the *same* string encoding, to prevent frequent conversions with every function call. This suggests to use the library(=platform) specific string encoding, which can be different on e.g. Windows and Linux. Consequently a cross-platform program should be as insensitive as possible to encodings, and the whole UTF-8/16 discussion turns out to be purely academic. This leads again to an different issue: should we declare an string type dedicated to Unicode text processing, which can vary depending on the platform/library encoding? Then everybody can decide whether to use one string type (RTL/FCL/LCL compatible) for general tasks, and the library compatible type for text processing? No disagreement here, if all your libraries are UTF-8, you don't want to convert everything. So if possible, write code to be as string type agnostic. Sometimes, however, you do need to look inside a string, and it does help to have an easy encoding then. Or should we bite the bullet and support different flavors of the FPC libraries, for best performance on any platform? This would also leave it to the user to select his preferred encoding
Re: [fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)
Op Sun, 18 Mar 2012, schreef peter green: My suspiscion was that the compiler was trying to spill but not actually generating any code to implement the spill. I added a debug writeln to setbitmap and it does seem to be being called with both 50,70 and 70,50. Full output is at http://pastebin.com/3jd8zNkh Okay, it is quite unlikely that the register allocator itself ignores such an interference, so you may be rigth it tries to spill but nothing happens. You can check this by adding a breakpoint in Trgobj.spill_registers and and check the contents of spillednodes, or the value of t in the loop that iterates through it. If the register is being spilled, Trgobj.spill_register will call Trgobj.instr_spill_register to modify an instruction using the register. This procedure will in turn call the CPU specific procedures Trgcpu.do_spill_read and Trgcpu.do_spill_written to modify the code. Do_spill_read and do_spill_written are the routines to check if they contain the right support for mregisters (I don't see any specific code there at the moment). Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)
Op Sat, 17 Mar 2012, schreef peter green: I don't think my previous mail got through but if it does please disregard it, my suspiscions as to the cause of the problem were incorrect. While testing my armhf porting work I came across a case where parameters were passed incorrectly to a function with a large number of parameters (14 single, 1 double). Initially I thought this was because of the compilers lack of knowlage of the conflict between double registers and odd numbered single registers. However looking more closely this appears not to be the case. The full assembler is attached and highlights of it are below. Looking at the code it seems that the compiler is loading the constants into temporary registers and then copying them to the final locations for passing them to the parameters. However for some reason it is using S20 to store two different temporary values at the same time. Any idea what could cause this and how to debug it? S20 is NOT used for passing parameters to funtions. This usually has to do with the code generator generating incorrect allocations. The code genator generates code with an infinite amount of imaginary registers and inserts allocations deallocations. Later the register allocator check which imaginary registers conflict. If they don't conflict it can decide to coalesce them into the same imaginary register to reduce register pressure. Please use the command line option -sr to check the generated code before register allocation. You can likely find the cause in there. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] register allocator seems to be using S20 for two things at the same time (related to armhf porting work)
Op Sun, 18 Mar 2012, schreef peter green: Daniël Mantione wrote: Please use the command line option -sr to check the generated code before register allocation. Done and attatched. You can likely find the cause in there. The code with imaginary registers looks correct to me. It seems to load each parameter into a seperate even numbered imaginary register (using odd numbered imaginary registers as temporaries in the process) allocating them as it goes. Then copies them to the locations needed for the function call deallocating them as it goes. I agree, both imaginary registers are correctly allocated and freed. So it seems to me that the problem is in the translation of the form using imaginary registers to the form using real registers. Can you explain (or point me to documentation on) how this form is translated into a form using real registers. The algorithm used is called iterated register coalescing, an advanced form of graph colouting and was designed by Andrew W. Appel. He describes in detail in his book Modern Compiler Implementation in C. Basically the registers are put into worklists, and then 4 procedures: * simplify - takes registers out of the graph that can safely be coloured * coalesce - tries to coalesce registers together to reduce pressure * freeze - selects registers that have a chance to be coalesced and should therefore not be spilled yet * spill - selects a register that should move to memory. These procedures are called iteratively until the worklists are empty. Then the graph is coloured. In particular what exactly happens when there are not enough real registers free to assign a real register for every imaginary register that is in use at a given time? Then a register is spilled, i.e. replace by a location in memory. This may be possible without new registers: mov ireg30d,ireg29d- mov ireg30d,[ebp-40] ... but in some cases a help register is needed: mov ireg30d,[ebp+20] - mov ireg99d,[ebp+20] mov [ebp-40],ireg99d Should a new register is needed, register allocation is completely restarted with the new code. My current suspiscion is that something is missing regarding handling of running out of VFP registers and it hasn't been noticed before because noone has tried to do what i'm doing (implementing a calling convention using VFP registers and then stress testing it) but i've no idea where to look in the sourcecode to confirm/refute that idea. It doesn't look like spilling happens in your example: I don't see moves from/to the stack frame as temporary location. Perhaps the first thing to check is to add a breakpoint in Tinterferencebitmap.setbitmap. The versions of s20 use superregister 50 and 70, so a setbitmap (50,70) or (70,50) should be called at some point to tell the register allocator both registers are active at the same time and cannot be coalesced. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] EBCDIC (was On a port of Free Pascal to the IBM 370)
Op Mon, 30 Jan 2012, schreef rvmart...@ntlworld.com: michael.vancann...@wisa.be wrote the following on 30/01/12 14:49:53: I think the reason for producing an ASCII version first is very simple: All FPC sources - including the compiler - are in ASCII encoding. I don't understand this statement - ASCII and EBCDIC are just human representations of a computer's internal code. ... which can be ASCII or EBCDIC encoded, right? So if the compiler source files are ASCII encoded... then the compiler has to read ASCII to be able to compile itself. I write my programs in the Latin (or Roman) alphabet and the computer does the rest. So the compiler has to care about ASCII/EBCDIC encoding, right? When I was writing VS/Pascal programs I used the same source code as input to VS/Pascal on the mainframe and to Virtual Pascal on the PC. Unless the FP source code is to be fed into a mainframe compiler like IBM's VS/Pascal or the Stanford compiler then the first step is surely to write a backend for the (eg PC) compiler to produce 370 assembler code. Producing EBCDIC rather than ASCII sounds a trivial part of the task Yes, but that's a difference topic than the source encoding. The compiler doesn't care how the assembler generator communicates with the assembler; it could be in any format, even binary. One just has to implement the assembler generator correctly. The compiler does care that the source it processes is ASCII. If it has to be able to read EBCDIC, some conversion has to happen before the scanner. As such a conversion is not necessary for the compiler to compile itself, it may make sense to postpone writing such a conversion and have the initial port be ASCII only. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: EBCDIC ( was On a port of Free Pascal to the IBM 370)
Op Mon, 30 Jan 2012, schreef steve smithers:
Hans-Peter Diettrich wrote on Mon, 30 Jan 2012 17:40:27 +0100
Existing source code frequently assumes ASCII encoding. The obvious are
upper/lowercase conversions, by and/or or add/sub constant values to the
characters. It will be hell to find and fix all such code in the
compiler and RTL, even if only the constants have to be modified for
EBCDIC. Even code with the assumed order of common characters (' ' '0'
'A' 'a') has to be found and fixed manually - how would you even
*find* code with such implicit assumptions?
It does indeed. I am aware of the problems inherent in this. But the RTL
has to be more or less rewritten anyway to support OS. OS is a very different
animal to Windows or Linux.
If you try to achieve a port by modifying all code that deals with
characters you will fail. The amount of work becomes then far too big for
a single person, and the modifications become too huge and wide-spread
that you will raise objections for merging it with the SVN trunk.
In other words, do yourself a favour and keep ALL processing in ASCII. You
can convert between ASCII EBCDIC on input/output. That way the
modifications in order to support EBCDIC are well concentrated in a single
piece of code, which can be easily merged without risk of destabilizing
the code base.
You can then use your manpower, and you still need *a* *lot* of it, to
write a code generator RTL.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] implementation AVX for Intel/AMD Prozessors
Op Sun, 18 Sep 2011, schreef Torsten: I do not know exactly which functions need to be changed. I'm hoping for tips. You will have to be a bit exploring here; AVX is a major upgrade to the x86 instruction set, and there will likely not be a few routines that need to be changed. First step is to make sure they can be used in assembler routines. The assembler is largely table driven, so it you have added them to the tables, a lot should work already. Nevertheless, I expect that modifications are necessary in the both the assembler generators (ag*.pas) and assembler readers (ra*.pas) due to the additional operand that needs to be written/parsed. Only when the point is reached that the instructions are handled well by the assembler reader/writers you could start by adding code generator support. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] implementation AVX for Intel/AMD Prozessors
Op Sun, 18 Sep 2011, schreef Florian Klämpfl: I'am not sure if the ymm registers should be an own register class. After all, they are a superset of xmm Exactly. Since if xmm0 is allocated, ymm0 is allocated too; the register allocator should treat them as a single register. xmm0 and ymm0 are a subregister of the same superregister. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
Op Thu, 7 Jul 2011, schreef Chad Berchek: The problem comes down to the specs though, or rather the lack thereof. As I have searched the web and read some docs at Embarcadero, things have only become more ambiguous. You are looking in the wrong places. Both Turbo Pascal and Delphi came with a language guide that describe the desired behaviour in deep detail. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Op Sun, 15 May 2011, schreef Joerg Schuelke:
Am Sat, 14 May 2011 20:46:30 +0200 (CEST)
schrieb Daniël Mantione daniel.manti...@freepascal.org:
Inlining is better that doing the same with macro's, so is the use of
str/val better than macro tricks.
Wherever you can!
If I do some low level system work, it is possibly better to do it with
a macro.
If I have a project where rtti is needed anyway, I would be dumb not to
use it instead of a macro, if it fits the needs.
Even if you have a project where RTTI is not needed, you would be thumb
not to use it instead of a macro. Really. There is no drawback.
What is the need of rtti: pointer to base classes do not know
to which possibly derived class they point. Thats why *runtime* type
information.
You are completely mistaken. This is what C++ uses RTTI for. FPC (nor
Delphi) does not use RTTI for this purpose at all! We have the typeof
function for this, which returns a pointer to the VMT. I even have no idea
wether the RTTI can be used for this purpose at all :)
All other things which you use in your program do not need
runtime type information, they always know who they are. If I do not
use objects or classes I have therefor no need for runtime type
information.
You are wrong again. Ansistrings/widestrings/variants and so on make use
of RTTI.
To get the associated name of an enum? Thats compile time information.
Then show a practical example where having it at compile time is a real
benefit. Please understand it clear: We are not against new features, but
there must be a benefit.
If there is a need for this it should be delivered to me by something
like {$I %enumname%enum%}, I think you would not like to have it this
way. But {$I %color%red%} will hopefully give 'red'. While {$I %color%}
maybe gives then 'red,green,blue' :-)
What is the need of a macro processor:To change the handwritten code in
an automated way. Is this a bad idea? Are there no needs for this?
For example to hold to lists with same entries under all circumstances
in sync. A macro does this in the simplest manner.
If you have an need for changing your handwritten code in an automated
way and you do not have macros, what would you use then? LaTeX? an IDE
tool?, m4? or inventing an compiler feature, but then do not call it
rtti, call it a macro. (thats pretty polemic, don´t worry)
Feel free to come up with examples and convince us. They need to be
examples of code that is much more awkward to write without macro's.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Op Sat, 14 May 2011, schreef Joerg Schuelke: 2) This is the solution? Making the compiler to store somewhere a string representation in my object file and then give it back to me if I request it by str(enumerate)??? All types (not just enums) have runtime type information that is stored in the object file. Runtime type information is very powerfull and has many applications, for example memory management for automatic types, or the population of a TForm with data entered in the GUI in Lazarus. Converting an enum to a string is another application of runtime type information. Thats so completely ... overhead, with a cannon to shoot a sparrow. There is no overhead because any unused RTTI is removed when smartlinking. Since when has an enumeration such kind of name, which lives outside compile time? RTTI is quite old already, but the compiler can convert between enums and strings since version 2.3. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Op Sat, 14 May 2011, schreef Marco van de Voort: 2) This is the solution? Making the compiler to store somewhere a string representation in my object file and then give it back to me if I request it by str(enumerate)??? Thats so completely ... overhead, Not really, if the RTTI is too slow for you, simply generate the array once on startup. (disclaimer I actually never have tested RTTI speed) It ain't slow at all. I think it beats many quick and dirty manual conversion solutions in speed and/or memory consumption. Maybe if you use it in an inner loop you may want your own code. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Op Sat, 14 May 2011, schreef Joerg Schuelke: Am Sat, 14 May 2011 12:14:52 +0200 schrieb Florian Klämpfl flor...@freepascal.org: Because a lot of code in the compiler is very old (remember, it was started in 1993 using TP) and writestr for enums is new compare with this time span. Nobody rewrote the code yet. And it should not been rewritten this way, because this would force the use of RTTI information inside the compiler , which is needless. It's not needless, it's usefull :) This code: type colour=(red,green,blue); begin writeln(red); writeln(green); writeln(blue); end; ... will cause 52 bytes of RTTI data to be inserted in your executable. Any do-it-yourself solution will consume more space. Therefore the RTTI not only helps to keep the source code compact and therefore readable, it would also help to keep the compiler exe compact. So use of RTTI information inside the compiler is most welcome :) Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Macro Processing
Op Sat, 14 May 2011, schreef Joerg Schuelke: I think of this a little different. Maybe more from an other perspective. For me RTTI is a level of language extension. Like OOP, or generics, or inheritance. Macros are very low level (if you have them). RTTI *allows* for language extensions, like str/val for enums. RTTI by itself are just data structures describing Pascal types, emitted automatically by the compiler. Language extensions can use those data structures to provide their functionality. It is not that I think that I would use a macro instead under all circumstances. But it should be possible to do it without RTTI which is of higher level in the language. I still don't see why it should be possible to do it without RTTI. But the question is, is the unknown reason that you don't want to use str a justification for adding the can of worms that is called macro's? The principle is do not use it if you do not like it. That should not influence the rest of the language. This way I think that it is not that bad to have a small, but powerful macro expander incorporated. It's not that bad, but it should make something possible. Until now I haven't seen many bright examples of things that cannot be elegantly without macro's. 52 bytes of data. And the RTTI code? Not much. Converting an enum to a string is a single procedure. It's quickly won back if you use the feature a few times. Actually this is a nice story about the hidden costs of language features. The procedure would be extremely simple (lookup a pointer to the string in an array, return the string), but FPC supports non sequential enums: type colour=(red:=1,green:=10,blue:=100); The majority of the code in the procedure that converts an enum to a string deals with handling this special situation (don't worry: normal enums are still a simple lookup). Often when you add features, it has unforseen consequences and it can be a complicated effort to make everything together well enough. This is why you want to be carefull adding new features. What if you do not smartlink? Then you get so much extra code in your exe that the RTTI is still a small and irrelevant portion. Actually in the past you could disable RTTI generation, but it was too sensitive for bugs. Removing unused code data is the task of the linker, we decided to make the linker do what it is designed for. I repeat, I have really nothing against RTTI, but I state that it comes from a high level language extension. Good. By the way this RTTI thing comes from the argument: Do not use a macro, instead do it this way. But this forces me to use RTTI, which is possibly not what I want. H... For the same reasoning you could say inline functions are ugly and you want not to be forced to use inlining. The point is that every time you can avoid a macro you win on code clarity, compiler speed (no time spent on evaluation expansion), debugability, parsability by IDE's, and so on. Inlining is better that doing the same with macro's, so is the use of str/val better than macro tricks. We don't want to force you to use RTTI, but our point is that there is proper solution to achieve the same benefit that the macro approach gives. But this way I can show you even OOP is useless :) what I do not believe. While I do believe in the merit of OOP, there are many dubious OOP features that you can criticize in a valid way, escpially because few of those features open new possibilities. But unfortunately it's a waste of time; we need this for compatibility. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Default IntToStr operator for '+' symbol.
Op Fri, 29 Apr 2011, schreef Skybuck Flying: I just had an idea how to better layout floats and such. The old way of laying them out in writeln can be used which I love and is great: Example: begin s := vSomeFloat:16:16 + ' ' + vSomeFloat:16:16; end; Good, then you really need to look into writestr, as Florian wrote, you will like it: writestr(s,vSomeFloat:16:16,' ',vSomeFloat:16:16); ... works fine. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$I %LINE%} and friends
Op Fri, 29 Apr 2011, schreef michael.vancann...@wisa.be:
I wonder why FPC broke Delphi compatibility by adding {$MODE}, instead of
choosing its own prefix for added compiler directives and macros.
Because it would mean yet another kind of directive, this is confusing.
My take on it is that if Delphi aborts on it, that is a Delphi problem. A
compiler should warn, not abort, at a unknown directive.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extended type
Op Wed, 20 Apr 2011, schreef Hans-Peter Diettrich: Of course there exists no general rule, it depends on the concrete purpose of a calculation, which algorithm, precision and type (BCD, fixed point...) yields the best results. But there also exists no reason why a coder should be prevented from using existing instructions and data types. Well... I actually believe compilers should support extended precision. I frequenly get Fortran programs that I need to benchmark that use the REAL*10 type. Do those programmers have good reasons for using REAL*10? Probably not. They use best precision by default. They code in Fortran because of this kind of support. No, not GNU Fortran, it doesn't support REAL*10, so I need to use the expensive commercial compilers. They don't care, they don't pay for it. Is it slow? Yes. Do they care? Sometimes. But... parallelizing over 256 cores gives more benefit than using fast double precisions. They start asking government subsidies for the next big supercomputer for the sake of promoting science. That's what your tax money goes to. Shake your head... It's stupid, I'm doing that for a few years already. But the solution is not to remove extended support from the compiler. Users will walk away. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extended type
Op Tue, 19 Apr 2011, schreef Nikolai Zhubr: 19.04.2011 14:12, Daniël Mantione: MS does preserve FPU states between processes. You can use the x87 on Windows, nothing prevents you from doing so. Maybe the calling Yes it does for 32-bit processes on win64, guaranteed. But do you have any evidence (tests/documents/links) proving it also does so for 64-bit processes on win64? Not at hand, but don't worry, it does preserve FPU states. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extended type
Op Tue, 19 Apr 2011, schreef Florian Klämpfl: It's just that the documentation tells you not to use the x87. Yes, because it's strange programming model should be really dropped. Agree, but the 80 bit support makes some people want to use it. And that will stay this way until CPU manufacturers invent an alternative. By the way, recent GCC versions calculate the goniometric functions in software using SSE3, and I checked that this is indeed slightly faster than the x87. So we can get rid to the x87 stuff, should we want. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extended type
Op Mon, 18 Apr 2011, schreef Hans-Peter Diettrich: Sven Barth schrieb: On Windows 64-bit you must not use the x87 FPU, because Microsoft wants it so. Can you be a bit more concrete? Originally MS spread info it wouldn't work at all under Windows, but that proved to be false, the FPU works technically. Now MS just states it is unsupported. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extended type
Op Sun, 17 Apr 2011, schreef Sven Barth: On Windows 64-bit you must not use the x87 FPU, because Microsoft wants it so. Thus on Win64 Extended=Double. On other x86_64 based operating systems the state might be different. You can use the x87 on Linux. Don't know for FreeBSD, but I expect yes, since it uses the same calling conventions as Linux and x87 is part of those conventions. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Register allocation question
Op Sat, 9 Apr 2011, schreef Florian Klämpfl: Am 09.04.2011 21:04, schrieb Sergei Gorelkin: 09.04.2011 22:26, Sergei Gorelkin ?: 09.04.2011 22:13, Jonas Maebe ?: Simply changing the register order in the array to trgcpu.create in Tcgx86_64.init_register_allocators should do it. Hmm, that was the first thing I tried, but it doesnt't seem to make any difference :( No, it works, I simply looked at the wrong place. As usual :-/ The right place to look is the function not calling other functions, not just any function simple enough. Attached are assembler listings of system.indexqword() compiled for win64 with -O2, with and without the change. Note the prolog and epilog (almost) gone. This is of course a very quick test, and I'll run the testsuite to check more thoroughly. If no issues pop up, it is ok to commit? Problem is, this might hurt non leaf functions. Maybe the register allocators can be initialized differently for leave and non-leave functions? This is a form of biasing, the register allocator is biased to put certain values in certain registers. It's a very old trick to get better register allocations, and the iterated coalescing we do gets much better results than old biased algorithms. However, I had noted that in many cases the iterated coalescing still leaves a lot of freedom during the actual allocations and adding some biasing at this point may be helpfull. I think the challenge is do design some generic infrastructure to tell the register allocator about biasing it should do, and then to add some heuristics somewhere else (like leaf/non-leaf) to give the register allocator the proper instructions. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
Op Fri, 3 Dec 2010, schreef Thaddy: If you all say no, I will live with it. Could you maybe specify what you want to achieve and in what way FPC requires you to use workaround hacks? Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Console IO revisited
Op Fri, 3 Dec 2010, schreef Thaddy: On 3-12-2010 15:50, Daniël Mantione wrote: Could you maybe specify what you want to achieve and in what way FPC requires you to use workaround hacks? Daniël Yes, In FPC the console IO is *always* redirected, be it through a handle or a named file. I don't understand what you mean here. The named file is expected to be independent of redirection. The handle not. Handle copying or inheritance doesn't matter in this case. The 'CONXXX' should always point to one and the same. Without hacks this is not possible in the current implementation. CONXXX != ( sorry, not) the vars Input, output etc. Okay, so you are saying that an assign(input,'CONXXX') results into dual handles? What is the reason you do not use the standard assign(input,''), to attach to stdio? I.e. is there a good reason why you are using CONXXX? At least in winapi speak. (or similar with Posix). But Posix doesn't have a CONXXX equivalent?! And these refer to OS interfaces, not languages. But as I confess, I might be wrong. Show me. Michael has a point of view from the language perspective, which is historically almost correct. My view is it has been superseded by OS's through history. Oh my, I just promised I consider the prevailing opinion as acceptable ;-) I still would like to know what you are trying to achieve. You got closer, but I still don't get the reason why you want to work with CONXXX Also, you understand that making stdio thread-safe without threadvars is a huge change that requires a lot of time investment? Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Op Thu, 30 Sep 2010, schreef Mattias Gärtner: When it is used for quick syntax check the compiler is invoked several times a minute - several thousand times a day. Is that a problem? Expect a few kilobytes that are left over at maximum, the compiler is been debugged for memory leaks, however, this is very difficult for all possible error conditions. If you find a memory leak that you don't like, report a bug, they can be fixed. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Op Wed, 29 Sep 2010, schreef Hans-Peter Diettrich: A last note on the NoGlobals branch, and parallel processing in the compiler: A few comments: You seem to be reasoning from theory, and mainly OOP theory. In principle this is good, I have been reasoning from theory in the past as well, and this helped restructuring sections of the compiler, which we have done extensively in the past and I have had my share in this. This improved the robustness of the compiler. In essence your project was good. There are a few remarks to be made: * There are more theories (religions?) about how maintainable programs should be made. For example there is a strong group of programmers who strongly believes there should be no exceptions to type checking. You could have started a refactoring eliminating typecasts rather than elimination globals. There is functional programming theory. Each theory has its merits in it own way, but it would be wrong to say that turning everything OOP would solve all problems or removing all typecasts will necessarily make our life easier. * The Pascal language implemented by FPC is a mixed procedural/OOP language. Procedural programming has its strengths and FPC makes use of the potential to mix procedural and OOP. * Global variables cause problems with parallelization, but that does not mean the choice for a global variable is a bad idea. Variables like current_module is used so extensively that they are prime candidates to be global. In my opinion you have been following the OOP bible a bit too strict here. * OOP was your goal. Your goal should have been parallelization, OOP should have been your tool. There are more tools, like threadvars. It has been said meny times in this discussion: In a compiler there are dependencies between a lot of datastrcutures. Handling this effectively is a challenge. FPC's approach in many places is to put abstract interdependent objects in a single unit, so these objects can use each other wherever they want. We then add functionality in other units that derive from the abstract units. Tsym, Tdef, Tsymtable are in a single unit. All kinds of symbols, definitions, and symbtables have their own unit. I consider this design a strong one, the problem of cyclic dependencies in the compiler is well controllable. It helps maintenance: I know many C++ projects where all .cpp files over time started to include all .h files. In FPC, if you notice you can't access current_module from the current unit, you know you are doing something wrong. You seemed to have trouble with this model, rather than embrace it and use it to your advantage, you started to break things apart and change the dependencies. As expected this caused you a dependency nightmare, introducing what you tried to eliminate with the better design: You wanted clear interfaces between certain parts of the compiler, but you did end up breaking interfaces external tools can use, and fixing them became beyond any hope. The globals unit has its role. Many symbols are there for a good reason. There can be good reason for moving symbols out of it, if you do so, first try to understand why that symbol is there, and avoid changes in unit dependencies at all costs. Above all: You can get far with theory. FPC has a practical and pragmatic code base but I dare to say it has a theoretically sound base design. New theory can be a solution for practical problems but implementation of it requires of new practical compromises to be made. For performance, memory use or historic reasons, or maybe even because the theory can't catch 100% of the possible situations (there are even some goto statements in the compiler). Nevertheless, you have gotten a lot of knowledge of the compiler, and this project makes me optimistic you can become a good compiler developer. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison Delphi7/FPC2.4.0 compiled MSEide exe's
Op Mon, 13 Sep 2010, schreef Graeme Geldenhuys: Op 2010-09-13 13:47, Martin Schreiber het geskryf: I can not use resource strings because FPC resource strings are not unicode capable AFAIK. Probably related to your choice of UCS-2 - I don't really know the specific issues you have, so it is hard to tell. I can say that I have been using resource strings (with unicode text) for ages, but fpGUI and my projects use UTF-8 internally, which obviously works around (mostly) the lack of Unicode support in FPC because UTF-8 text can be treated as a byte array. Please don't turn this discussion into a UTF-8 versus UCS-2/UTF-16 debate. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PShortString
Op Fri, 10 Sep 2010, schreef Hans-Peter Diettrich: Sergei Gorelkin schrieb: When dynamic strings are used all around, is the use of pointers to ShortString still recommended? (fmodule contains a lot of them) Whenever you care about performance, you'll quickly realize that dynamic strings are plain inappropriate. The concrete use of PShortString strings is inappropriate in your sense, because it results in allocation, copy and deallocation of temporary strings in the code, in many places. This behaviour gave birth to my question. Ansistrings result allocation copy and deallocation during *processing*. The use of ansistrings would make the compiler at least twice as slow and quadruple its memory consumption. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] regarding RTTI unit mail
Op Sun, 29 Aug 2010, schreef Hans-Peter Diettrich: Copyright is about creative decisions. For example the order in which procedures, variables are declared are creative decisions and thus part of the expression of an interface. If you make the same creative decisions as the original program, you violate copyright. I doubt that. It should be possible to compare interfaces easily, for completeness and version compatibility. In languages like C and C++ you can get hell when you change the order of elements, with interleaved #defines and #ifs (what's possible in Pascal as well). If the order of elements is enforced, it is not a creative decision, thus both programmers can make the same decision without violating each others copyright. An interface is a contract, and as such every translation *must* follow the original closely. Be happy an interface by itself is not copyrightable. If you read about the history about the software directive there was a big fight about this, because some companies like IBM wanted copyright to protect them against clones from the far east, while others actually wanted interoperating competing products. But even though they are not copyrightable, you cannot verbatimly copy interface files. There is copyright on the expression of them. The above formulation is almost a literal translation of the German copyright law (UrhG). The UrhG also allows to observe and even decompile a software, in order to make it interface with some other software (interoperability). The only restriction: the results may not be disclosed. It would be interesting to get the full text of the EU directive, in order to find out more. No surpise here: All copyright laws of member states should be compatible with the directive, though many have skipped the wording about interfaces, but that does not matter a lot. You can the directive here: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31991L0250:EN:HTML Replace the EN in the URL in e.g. DE, NL, ... to read it in another language. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Op Sun, 29 Aug 2010, schreef Paul Ishenin: 29.08.2010 21:39, Dimitri Smits wrote: At the present state of fpc compiler it is technically imposible to port delphi rtti unit. To do this you need first to implement the next compiler features: 1. Extended records (methods, class operators) 2. Generics as in delphi 3. Attributes 4. scopeable RTTI ($RTTI directive) I mean that for implementing RTTI unit compatible by interface with delphi you need that 3 features I wrote about. Or how you will port for example TValue record: You can come a long way by using FPC alternatives: Use objects, and overload the := operator. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] regarding RTTI unit mail
Op Sat, 28 Aug 2010, schreef Dimitri Smits: Hi, (just hate it when you send something after re-reading it a few times, and a minute later you know that there is something important you forgot to ask) Since objectnames and interfaces are cloned from Delphi everywhere in the fpc-rtl, I was wondering if this is legitimate use and not a copyright violation? ie: the interface is the same, the implementation is different (unless trivial). Is this, or is this not an issue? The EU software directive says a few words about this matter: Protection in accordance with this Directive shall apply to the expression in any form of a computer program. Ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright under this Directive. In other words: It is okay to copy the interface, but not its expression. Copyright is about creative decisions. For example the order in which procedures, variables are declared are creative decisions and thus part of the expression of an interface. If you make the same creative decisions as the original program, you violate copyright. Generally safe is the clean room approach: Someone who doesn't know the Delphi source code implements it from documentation. This is internationally considered best practise and can avoid discussions wether it is a violation or not. If you happen to know the Delphi sources, you have to be carefull what you write. The EU software directive allows us to develop FPC in a reasonably safe way, but the borders between independent implementation and copyright violation unfortunately is not black and white. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OO rewrite - technical questions
Op Tue, 10 Aug 2010, schreef Michael Schnell: Finally I think that there is a decent chance to modify the compiler and the RTL in a way that threadvars can be used fast and without needing a libc binding Yes there is. I worked on this a long time ago, but I didn't finish it. The code for that is still in the compiler, work on that can be continued. However, it won't be usefull without libc independend thread mananger. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Syntax problem with function result
Op Wed, 28 Jul 2010, schreef Florian Klaempfl: Am 28.07.2010 15:10, schrieb Hans-Peter Diettrich: Florian Klaempfl schrieb: IMO we should have at least an option, that a function name can *not* be used for the function result any more, for the result we have the Result variable. Then we can safely distinguish between function calls (by function name) and results (by Result). If ever required, local functions still can refer to the result of some enclusing function, by e.g. qualified function_name.Result. I think for this purpose a hint is enough. Can it be implemented ASAP, or is a feature request required? If none of the other developers refuse till tomorrow, I'll apply the patch of Jeppe. Anybody else opinions if a hint would be better than the mode switch? If I understand it well this patch will disable not only the fpc externsion: writeln(name_of_function); ... but also the standard Pascal: name_of_function:=value; Why would we want to disable the standard Pascal solution? Why not disable the Borland result extention? Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Syntax problem with function result
Op Wed, 28 Jul 2010, schreef Hans-Peter Diettrich: Daniël Mantione schrieb: If I understand it well this patch will disable not only the fpc externsion: writeln(name_of_function); ... but also the standard Pascal: name_of_function:=value; Why would we want to disable the standard Pascal solution? Why not disable the Borland result extention? TP mode can be handled differently from the other modes, never affected by this option. But this should be mentioned in the documentation, else some people may wonder why the option doesn't work in their legacy code. I wasn't talking about legacy code. I wasn't talking about TP mode either. I was talking about new code. Why not disable the result extension? Delphi is legacy anyway so there is no need anymore to promote its flaws. To be clear: I am not proposing disabling the result extension. I'm just applying the same reasoning. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OO rewrite - technical questions
Op Mon, 19 Jul 2010, schreef Michael Schnell: On 07/19/2010 03:11 PM, Jonas Maebe wrote: That's correct. FPC has largely platform-independent support for threadvars, which is much more heavy-weight than simply using a segment register (indirect procedure call depending on the thread manager, get thread local storage pointer, index local storage with offset specific to the threadvar). Nonetheless in the end a register is needed to be used that is preloaded with different values for different threads. Otherwise a thread can't know which one it is. Registers is the only per-Thread information that is granted to persist by the OS during preemption. You could also work with the current thread id as a key to a pointer to the threadvars. However, segment registers are indeed the way libpthread resolves the TLS keys. There have been attempts to get the segment register approach to work on Windows, but afaik it always crashed on at least one Windows version. YAK I do know that gcc in Linux on X86 uses a segment register. I don't know how gcc works in Windows, but I suppose even Windows is assumed to restore all register values of a thread after a preemption. Yes, though I am still puzzled how it works on x86_64; it seems regvars there are also accessed using fs, but x86_64 prevents you from writing to segment registers. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OO rewrite - technical questions
Op Mon, 19 Jul 2010, schreef Sven Barth:
Hi!
Yes, though I am still puzzled how it works on x86_64; it seems regvars
there are also accessed using fs, but x86_64 prevents you from writing
to segment registers.
As mentioned here http://en.wikipedia.org/wiki/X86_64#Windows in the 10th
point Windows uses the GS segment register to store pointers to the TEB (see
http://en.wikipedia.org/wiki/Thread_Environment_Block ) of the current
running thread (x86 uses FS). So they should still be writable as the TEB is
written to by the Win32 subsystem (of which a part runs in usermode) as part
of its bookkeeping and maybe also by user applications to implement the 64
bit equivalent of SEH.
Well, the following works on i386 but doesn't on x86_64, even though
modify_ldt succeeds:
program ldt_test;
{$asmmode intel}
uses baseunix,linux;
var p:pointer;
ud:user_desc;
begin
p:=pointer(fpmmap(nil,4096,3,MAP_PRIVATE+MAP_ANONYMOUS,-1,0));
ud.entry_number:=1;
pointer(ud.base_addr):=p;
ud.limit:=4096;
ud.flags:=UD_SEG_32BIT or UD_CONTENTS_DATA or UD_USEABLE;
modify_ldt(1,@ud,sizeof(ud));
asm
mov ax,15
mov fs,ax
mov fs:[0].dword,29
end;
writeln(Pcardinal(p)^);
end.
If you know how to make it work, I keep myself recommended :)
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OO rewrite - technical questions
Op Mon, 19 Jul 2010, schreef Hans-Peter Diettrich: Michael Schnell schrieb: I do know that gcc in Linux on X86 uses a segment register. I don't know how gcc works in Windows, but I suppose even Windows is assumed to restore all register values of a thread after a preemption. Windows uses segment registers in exception handling, i.e. it should be possible. But the segment descriptor/selector must point to the correct thread-memory address in the address space, what can not be achieved in application code. Okay, so the Windows kernel sets up the segment registers then by default, that is interresting to know. But Linux does not, yet libpthread is using the segment registers. What I find curious is that you can call modify_ldt sucessfully to setup a segment, but then you cannot use it. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Messages overhead
Op Fri, 16 Jul 2010, schreef Micha Nelissen: Daniël Mantione wrote: Compiler speed can loose from maintainability, but it can also loose from code quality; the performance of your application is probably also worth a lot to you. Does FPC compile significantly faster when using -O- then? That is irrelevant; for example the register allocator made the compiler slower (initially even 3 times, but we managed to reduce it to a few ten %), but had great effects on code quality. The most expensive optimization you can effect with -O is the assembler optimizer, this is noticable in compilation speed. However, debug info is for example something that affects speed more. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Messages overhead
Op Fri, 16 Jul 2010, schreef Micha Nelissen: Daniël Mantione wrote: Op Fri, 16 Jul 2010, schreef Micha Nelissen: Does FPC compile significantly faster when using -O- then? That is irrelevant; for example the register allocator made the compiler slower (initially even 3 times, but we managed to reduce it to a few ten %), but had great effects on code quality. What do you mean with code quality then? I thought performance of the generated code. Then we are thinking the same :) The register allocator sacrified compiler speed for code quality. 2.0 generates much better code than 1.0. Also there were lots of bugs due to runing out of registers before, the register allocator dealt with that problem once and forever, so you can also say we sacrified compiler speed for compiler reliability. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Messages overhead
Op Thu, 15 Jul 2010, schreef Hans-Peter Diettrich: This is what I'm going to do now. Does there exist some profiling code already, or do I have to reinvent the wheel? No, simply use the -pg compiler option, the use gprof. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Messages overhead
Op Thu, 15 Jul 2010, schreef Graeme Geldenhuys: maintainability is more important to the core team that speed. No. That is doesn't do justice to all the effort that is put into performance optimization. It's not about maintainability being more important. It is about making the right trade-offs between: - Compiler speed - Compiler memory usage - Generated code quality - Compiler portability - And indeed compiler maintainability. Compiler speed can loose from maintainability, but it can also loose from code quality; the performance of your application is probably also worth a lot to you. Nevertheless contest the idea that FPC is a slow compiler, I have put a lot of effort in optimizing compiler speed over the years. I work with many compilers daily, including GCC, Pathscale, Intel, Portland Group. FPC wins from all of these compilers by orders of magnitude. Last week I compiled OpenFOAM, a fluid dynamics software written in C++, with the Intel compiler. It took 9 hours for 110 megabytes of source code. FPC compiles such an amount of code in a few minutes... The fact it can do that can be attributed to the Pascal unit system (compared to include headers), but just as much to the choice of smart algorithms and datastrures and a tons of local code optimizations that were coded over many years. Daniël___ 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
Re: [fpc-devel] Purpose of uses ... in?
Op Mon, 12 Jul 2010, schreef Michael Schnell: On 07/12/2010 08:12 AM, Michael Van Canneyt wrote: So for historical reasons, FPC is stuck with the 'in' clause, when in fact it should not exist in the first place. It could be made useful when You may be able to make it more usefull, but there still is no justification for its existance. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of uses ... in?
Op Sun, 11 Jul 2010, schreef Hans-Peter Diettrich: I know that the in filespec is part of the Delphi syntax, but what is it really good for? In my opinion, it is not usefull. I have never seen a clear description of what the semantics should be, for example what happens if the code being compiled is found in the unit path, or if you point to a different directory than the current (i.e. fpc subdir/unit.pas). If you use it, you often also get into trouble with include files. Another problem is that filename pathnames syntactically depend on the operating system. In my opinion, the unit path (-Fu) is the proper way to instruct the compiler where it should search for your units. uses ... in is a Delphi relic we have inherited. AFAIK it's not allowed to rename units this way, and since (currently) only absolute filenames are implemented, I really wonder why FPC allows to use it everywhere? IMO the filespec should allow for relative pathes, and also the use of FPC macros should be possible (e.g. FPCSourceDir). When there exists interest in such an extended functionality, but nobody has the time to implement it, I'll try to implement it myself. I am skeptical, but if you can make it more usefull... Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threading support and C library under Linux/Unix
Op Thu, 24 Jun 2010, schreef Michael Schnell: On 06/23/2010 05:35 PM, Daniël Mantione wrote: It's a non-issue. If you set a thread realtime you know what you are doing and can take care you give up the CPU when feasible, or you simply don't enter mutuxes shared with non-realtime threads. I don't agree. If the RTL provides a method, it should be working and not unavoidably create a dead lock, even if a thread is set to a realtime priority. Moreover Thread Synchronization using FUTEX (via TCriticalSection) (implementing this directly in the RTL instead of using libc is what is being discussed right now here) is especially useful in a realtime system, as it improves the performance of the threaded application. If you are special things, it is reaosnable to ask special attention by the one who does those things. If there is an easy fix, feel free to propose it. Moreover the current implementation is not optimal at all even in a system with time-slices. If there is no other way with this arch but an active spinning lock, the blocked thread should at least give up it's current time slice before retrying to get the lock, so that the blocking thread can work and release the lock. otherwise (in a single CPU system) the resting part of the time slice is deterministically wasted. Yes, but in a multi-cpu system giving up the timeslice is a very bad idea, because the lock might be released a few clock cycles later by the other cpu; you would waste the rest of time slice while you could be crunching. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threading support and C library under Linux/Unix
Op Wed, 23 Jun 2010, schreef Graeme Geldenhuys: Op 2010-06-22 15:31, Marco van de Voort het geskryf: Same problem. You still have to interface with the kernel, and it would be incompatible with C libraries that use threads. Well, if I don't use C libraries (only Object Pascal code), then it should still be beneficial. I can then write pure Object Pascal code/applications and still have multi-threading support. It's not just about eliminating libc dependencies. I believe it would be beneficial in most cases, even when using C libraries, since the Linux kernels does not expose a Posix threads like API, Posix threads are emulated. The FPC model is again unlike the Posix model, so you have again glue code. Directly calling the kernel would remove this overhead and allow for more efficient threading. The fact that the C libraries you call are written for libpthread does not need to be a problem: - You would not be able to share a variable between Pascal and C and have threads in both worlds wait on each other and two threads may not be able to call C code at the same time, you would need to protect that. - However, C libraries could safely launch pthread based threads without getting in the wheels of Pascal based threads. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threading support and C library under Linux/Unix
Op Wed, 23 Jun 2010, schreef Henry Vermaak: On 23 June 2010 13:58, Michael Schnell mschn...@lumino.de wrote: On 06/23/2010 02:45 PM, Henry Vermaak wrote: I think you'll first have to worry porting fpc to those architectures. Right you are :) But anyway, if not using libc, you need to do the FUTEX user space part in Pascal/Assembler Why would you want to do that? Just use the futex syscall. Because the Futex syscall won't give you threads, it requires userspace assistance. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threading support and C library under Linux/Unix
Op Wed, 23 Jun 2010, schreef Henry Vermaak: A futex syscall doesn't know anything about threads, it's for locking. Perhaps I'm misunderstanding you? I have should have written futex instead of threads. With a Futex, you only call the Futex syscall, if the Futex is locked. You still have to test wether the Futex is locked in userspace, and you that with the interlocked assembler instructions. This assembler implementation must be implemented for each architecture (though abstractions can probably be used, we already have many interlockedx procedures). Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threading support and C library under Linux/Unix
Op Wed, 23 Jun 2010, schreef Michael Schnell: On 06/23/2010 05:18 PM, Mattias Gaertner wrote: What system has such an unfair scheduler? A fair Scheduler only can be fair if time slices are to be managed. If you set a thread to a realtime priority (OK, you need to be root to be allowed to do that :) ) it's priority is above all the normal processes. That is quite normal if you do embedded Linux systems. It's a non-issue. If you set a thread realtime you know what you are doing and can take care you give up the CPU when feasible, or you simply don't enter mutuxes shared with non-realtime threads. Of course if there is a simple fix... Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
Op Mon, 1 Feb 2010, schreef Marco van de Voort: In our previous episode, Michael Schnell said: D2009/d2010 are still windows only. Do you think there is any general problem in using D2009 strings with dynamic encoding with Unix ? On the first view I don't see one. In general I prefer to use each platform using its native encoding. Some commercial unices are also using utf-16 afaik, since they haven't switched their TTY to UTF-8 yet. To be investigated. I lean towards RTLString=utf8string; and RTLString=unicodestring on the respective platforms, and then express the RTL in RTLString. No, RTLString=ansistring on Linux and most Unix platforms. Unix is encoding agnostic so if you want to use the native string type you must simple use old fashioned ansistring. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
Op Mon, 1 Feb 2010, schreef Marco van de Voort: In our previous episode, Dani?l Mantione said: Some commercial unices are also using utf-16 afaik, since they haven't switched their TTY to UTF-8 yet. To be investigated. I lean towards RTLString=utf8string; and RTLString=unicodestring on the respective platforms, and then express the RTL in RTLString. No, RTLString=ansistring on Linux and most Unix platforms. Unix is encoding agnostic so if you want to use the native string type you must simple use old fashioned ansistring. This means crossplatform unicode support goes out of the window. I don't like that. It is a consequence if using the native string type. Otherwiser you can just as well use UTF-16 everywhere. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler bug?
Op Sun, 31 Jan 2010, schreef Paul van Helden: Of course Thanks Cobines! I have never used the function name instead of Result, but of course you can. Using () after a function to me seems so C-like and un-Pascallish but it works. But it is things like this that trip up people coming from Delphi, I guess. Isn't this a potential improvement to the compiler though: scan for overloaded functions before assuming that it is the result value (like Delphi does)? (Or warn about overloaded functions without parameters, similar to mode objfpc disallowing parameter names that are the same as methods?) This behaviour is intentional to allow you to read instead of just write the function result. The incompatibility just affects recursive procedures without parameters, which seldomly occurs, because normally the parameters determine the behaviour of the function, and a recursive function without parameters would prevent you writing a mechanism that makes the recursive function terminate. Only if the behaviour of the recursive function is controller by global variables, then you can actually write a recursive function without parameters. Because this is so seldom, and the desire to read from the function result is extremely common, there is a strong case for this behaviour. Indeed Borland did invent result as a method to read from the function result, so FPC had to support that too. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Semicolon before else
Op Tue, 26 Jan 2010, schreef Graeme Geldenhuys: David W Noon wrote: Syntax and understanding is as clear as rain. Adding extra semi-colon, as you suggested, is not. Indeed, it would be undesired to accept that semicolon. What makes me uncomfortable is that he went to the trouble of modifying the compiler for it. We should encourage that. As for the 'otherwise' syntax. You are correct, I have never heard or seen it before. :-) But it is documented in the FPC Language Reference section 10.2.2. Otherwise is used in some Pascal dialects instead of else. This is where it comes from. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] possible 'dynlibs' unit issue
Op Tue, 19 Jan 2010, schreef Graeme Geldenhuys:
Michael Van Canneyt wrote:
Why should it be better ? It doesn't really matter anyway.
PtrUInt has a larger range than PtrInt (allowing full access to memory
address range). Plus, I don't think pointers can be negative values.
The problem occurs when doing pointer arithmetic ptrint+integer
is a bug, because it will overflow if the original pointer$800 and
the result pointer=$800. It is especially dangerous in loops like:
q:=p+distance;
while pq do
begin
{...}
inc(p);
end;
I don't want to think how many bugs have been coded this way :)
However, when using pointers as handles it is another matter... Handles
are not to be used in any calculation, so they cannot overflow. Who cares
if you get a negative handle?
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] possible 'dynlibs' unit issue
Op Tue, 19 Jan 2010, schreef Dariusz Mazur: Is this possible to forbid this at compile time? An easy solution is to wrap it inside a record. This is good practise as it prevents accidental bugs like accidentally writing parameters in the wrong order when calling a procedure. It's basically the point of type safety. Some languages have opaque types designed for this purpose, the difference being that a record only protects against accidental calculations (you could modify the field in the record), while an actual opaque type could enforce it. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI is always enabled??
Op Thu, 10 Dec 2009, schreef Graeme Geldenhuys:
Paul Ishenin wrote:
This is delphi 2010 compatible behavior. Only info about published
methods is not written for classes with {$M-}.
So what is the correct way of asking if a class as RTTI (published
properties) available? Because currently we have stacks of unit tests that
fail in tiOPF due to this change - give always true when asking if publish
properties (RTTI) is available.
Published properties are far from the only information stored in RTTI, and
therefore not the only reason why RTTI is generated. Automated types like
widestring need for example RTTI to function.
I'd say check if the RTTI contains the data you need.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch to call DoneKeyboard in the exitproc of the drivers unit
Op Sun, 16 Aug 2009, schreef Jonas Maebe: On 16 Aug 2009, at 12:15, Nikolay Nikolov wrote: Does anyone have an idea why the call to DoneKeyboard was previously commented? It leaves the keyboard in a bad state if the IDE crashes. It was changed in revision 3443, whose log message says: r3443 | daniel | 2006-05-07 00:57:20 +0200 (Sun, 07 May 2006) | 3 lines Changed paths: M /trunk/fv/app.pas M /trunk/fv/drivers.pas M /trunk/fv/validate.pas M /trunk/ide/fp.pas M /trunk/ide/fpide.pas * Video and keyboard initialization spaghetti organized and hopefully fixed. - Remove useless function from validate.pas Maybe Daniel knows. In Turbo Vision, it is the task of Tapplication to initialize drivers and the task of Tprogram to detect how it was initialized. This was totally messed up; i.e. Tprogram.initscreen is supposed to detect the current screen, but people had inserted code into it that did change the screen, so they also invented a donescreen. This caused a lot of bugs inside FV applications. With this patch, I brought things back as they should be, all intialization/finalization back to Tapplication and Tprogram just detects how things are initialized. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch to call DoneKeyboard in the exitproc of the drivers unit
Op Sun, 16 Aug 2009, schreef Nikolay Nikolov: On 08/16/2009 03:22 PM, Daniël Mantione wrote: Op Sun, 16 Aug 2009, schreef Jonas Maebe: On 16 Aug 2009, at 12:15, Nikolay Nikolov wrote: Does anyone have an idea why the call to DoneKeyboard was previously commented? It leaves the keyboard in a bad state if the IDE crashes. It was changed in revision 3443, whose log message says: r3443 | daniel | 2006-05-07 00:57:20 +0200 (Sun, 07 May 2006) | 3 lines Changed paths: M /trunk/fv/app.pas M /trunk/fv/drivers.pas M /trunk/fv/validate.pas M /trunk/ide/fp.pas M /trunk/ide/fpide.pas * Video and keyboard initialization spaghetti organized and hopefully fixed. - Remove useless function from validate.pas Maybe Daniel knows. In Turbo Vision, it is the task of Tapplication to initialize drivers and the task of Tprogram to detect how it was initialized. This was totally messed up; i.e. Tprogram.initscreen is supposed to detect the current screen, but people had inserted code into it that did change the screen, so they also invented a donescreen. This caused a lot of bugs inside FV applications. With this patch, I brought things back as they should be, all intialization/finalization back to Tapplication and Tprogram just detects how things are initialized. This is all cool, but IMHO DoneKeyboard should also be called in the ExitProc to clean things up in case a runtime error occurs, since then the TApplication destructor isn't (usually) called. Is there a reason not to do that? Calling DoneKeyboard twice on normal exit should be safe, as it checks a flag and does nothing when you call it the second time. I can see the issue with abnormal program exits, but I disabled it because calling it twice had unintended effects. So we need to verify we don't break anything. Daniël ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC micro controller
Op Wed, 29 Jul 2009, schreef Desmond Coertzen: This is my first question / suggestion: With byte sized variables being the smallest accessible variable in the PC architecture, will we see a language extension to provide bit accessible variables for the micro controllers? Do you mean bitpacking? type nibbles=bitpacked record low_nibble=0..15; high_nibble=0..15; end; Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC micro controller
Op Wed, 29 Jul 2009, schreef Desmond Coertzen: That is fantastic! Is this correct for application? var SomeIOPort: nibbles; begin SomeIOPort.low[7] := 1; end; nibbles is not an array? Anyway, you can created bitpacked arrays, so the idea will work. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Topic for the list - Embedded port for PIC Micros
Op Thu, 23 Jul 2009, schreef Michael Schnell: I'd really appreciate the 32 Bit PIC stuff, as this is MIPS and I might want to do a NIOS port some day and the NIOS ISA is said to be quite similar to MIPS (even the names are only a few bits apart :) ) The main challenge for a MIPS port is the absence of flags, there is a lot of code in the compiler that returns expression results in LOC_FLAGS. Of course it is perfectly possible to change these codes to use LOC_REGISTER, but it is work. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] indexed property with default value for param?
Op Thu, 11 Jun 2009, schreef Michael Van Canneyt:
On Thu, 11 Jun 2009, Jonas Maebe wrote:
I would think it is a natural extension of procedural overloading ?
It's not that simple. Properties can be both hidden variable access as
well as procedure access. Variable overloading is not allowed,
because it causes a lot of issues, i.e.:
var a:word;
a:char;
begin
a:=1;
a:='!';
writeln(a); {what does this mean??}
end;
Property overloading gets you the same issues, i.e. in the example above
you could replace both variables with properties and answer the same
question.
Considering this, I do not think it can considered a logical extension of
procedure overloading.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi smart-linking perspective ( Language change and implementation ... )
Op Fri, 5 Jun 2009, schreef Paul Ishenin: How difficult is to teach compiler to remove them during compilation? I sense a hope that somehow the compiler developments will ultimately be able to turn large Lazarus executables into small ones. It is not realistic. The WPO features Jonas is working on are very promising, and I think he is doing something unique, I know no competing compiler that does it. But The compiler will never be automatically able to remove PNG readers, XML parsers and so on, because the LCL deliberately is designed to make executables handle such data. What is resonable to expect is that due to advances into making the compiler more clever, occasionally small gains will be achieved. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Ref documentation doesn't mention deprecated keyword
Op Mon, 1 Jun 2009, schreef Graeme Geldenhuys: How do you mark a unit as deprecated? In the user.pdf I have seen many references to units being deprecated (eg: graph, oldlinux, etc), but I have only seen that being mentioned in the documentation. There doesn't seem to be any compiler reference or deprecated keyword marking that unit as deprecated. Or I clearly missed something. ;-) There is a distinction between legacy deprecated. I.e. Graph remains a supported unit. It may not be the best idea for new code, but there is no recommendation against using it. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi smart-linking perspective ( Language change and implementation ... )
Op Sun, 31 May 2009, schreef Jonas Maebe: Yes, the but the results are not very impressive. The reason is due to the way the LCL is constructed, almost every declared class can theoretically be instantiated. On the other hand, I read that recently the LCL was restructured a bit to improve the situation, so maybe the results would be better now. Also note that WPO can do little about published methods (since it must assume that these can all be called via RTTI). Also not that many references through initialization are just one part of the equation. Many code is referenced through resource files, i.e. if a class X can appear in a resource file, the code to construct the class must be in the executable, even though class X will not actually be in the resource file. One area that particulary demonstrates this is the Tform, it has a lot of fields that can optionally contain a reference to another class. Even when you set all these fields to nil and never construct such a class, there code will end up in the executable, because the executable will only learn that the field is set to nil when it processes the resource file at runtime. These two aspects (unit initialisation and resource files) make both Delphi and Lazarus executables grow quickly, the LCL more because it has more initialization references than the VCL. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String cases development
Op Tue, 5 May 2009, schreef Michael V. Denisenko: A question appeared when I tried to find a method of generating case-expression just once, not for every comparison. Is it optimal to try to add for every case-structure (and do...while, by the way) a temporary variable where we may hold the value of case-expression? Yes, but it only if the variable part of the case expression is complex, i.e. not a simple loadn or perhaps subscriptn of a simple loadn. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Is it possible to remove dependency on cygwin from freepascal ?
Op Tue, 28 Apr 2009, schreef Vincent Snijders: Tomas Hajny schreef: On Tue, April 28, 2009 12:13, sakesun roykiatisak wrote: Is it possible to remove dependency on cygwin from freepascal ? To make it clear, I actually mean remove dependency on some cygwin utilities Fpc compiler is not based on cygwin, however. Sorry if this could cause some confusion to some new freepascal user. As far as I know, the most prominent place causing cygwin dependency on Win32 is the GDB debugger (and its library form used by FP IDE). The stand-alone debugger gdb distributed with fpc is not cygwin, but mingw32. Did someone ever try to build a libgdb under mingw32? Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc map file
Op Sat, 18 Apr 2009, schreef Paul Ishenin: Hello, FPC developers' list I've found one interesting tool for delphi which I really want to have for lazarus and fpc: http://delphitools.info/samplingprofiler/ To work that tool uses map files which generates delphi. I contacted to author and asked him to add support for fpc. But there is one problem - fpc map files does not contains line info. Here is small discussion with Sampling Profiler author I had: http://delphitools.info/forums/index.php?topic=13.0 Can fpc team extend output made by -Xm with line info? Not if the GNU linker is used, which is the case for the majority of platforms. Check the lineinfo unit, it retrieves line number information from the debug information. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [?? Probable Spam] Re: [fpc-devel] fpc map file
Op Sat, 18 Apr 2009, schreef Bogus?aw Brandys: Daniël Mantione pisze: Op Sat, 18 Apr 2009, schreef Paul Ishenin: Daniël Mantione wrote: Can fpc team extend output made by -Xm with line info? Not if the GNU linker is used, which is the case for the majority of platforms. So -Xm is the same as ld -Map ? I thought -Xm map file is always fpc generated. No, the compiler has no knowledge which symbol is placed in which object location, so it cannot generate a map file by itself (unless the internal linker is used). Daniël Does it mean that at least it could work with internal linker under windows ? Yes, but with a strong accent on could, because the work still would need to be done. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String cases development
Op Sat, 18 Apr 2009, schreef Mike Denisenko: Hello everyone, I'm a student of FESU, Russia. I've started to develop a feature - string cases (Topic: Easiest way to case strings, http://www.lazarus.freepascal.org/pipermail/lazarus/2009-March/023369.html), and now some questions appear: Existing method of parsing and generating assembly code doesn't process any constants but ordinal type, so the class holding case data, TCaseNode, contains labelinfo as object of TCaseLabel record. And TCaseLabel contains two fields: _low and _high representing the low and high bounds of interval signed as case label. These fields are of TConstExprInt type, so if we want to process the string label we get a problem: how it's better to hold its value? Should we simply add two string-type fields to TCaseLabel, or it should be solved by creating a base class with some virtual procedures and refactoring all modules having procedures operating with this type? I am fine converting Tcaselabel into a variant record that takes a Pstring field. A new class is not a good idea, since we already have classes for this purpose: Tnode and descendends, a string constant can be represented by a Tstringconstnode. Tnode should be the most flexible since it allows you to handle all types of contants (and non constants if necessary). Probably the parser already creates a Tnode tree, does constant expression evalutation, and then creates a Tcaselabel with the evaluated constant. I wrote this case-label code about 10 years ago, it has a fundamental flaw: There is a worst case with quadratic time blowup, if you create a specially crafted case statement in the code, you can keep the compiler busy for a very long time. On the other hand, this has never been a problem in the lifetime of the compiler. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc binary for OpenBSD 4.4
Op Fri, 13 Mar 2009, schreef Constantine Cusulos: I would like to compile fpc on my OpenBSD4.4/i386 system. The buildfaq (http://www.stack.nl/~marcov/buildfaq.pdf) requires to have a usable fpc binary in order to compile fpc source. OpenBSD has emulation for binaries from linux and FreeBSD so i got the corresponding binaries from Ubuntu/i386 and FreeBSD/i386. Emulation didn't work. That means that i was not able to use the freepascal compiler on my system with either of those binaries. Is there a way i can compile fpc on OpenBSD4.4/i386? The OpenBSD code in the rtlis unmaintained, perhaps Marco can give an idea about the state of that code. Since many platform specific code is shared with FreeBSD Darwin, it can be brought back to life with relative ease. If a bootstrap compiler is missing it may be possible to compile an OpenBSD execitable on another system. If all else fails, the assembler files can be generated on a Linux system, transfered to OpenBSD and assembled/linked there. But this has almost never been necessary. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Debugger for FPC
Op Thu, 12 Mar 2009, schreef Vincent Snijders: Graeme Geldenhuys schreef: On Wed, Mar 11, 2009 at 6:11 PM, Martin Schreiber fp...@bluewin.ch wrote: Delphi/Kylix probably can't map a variable to the address of another variable, because of that Delphi needs separate implementations of format functions with and without FormatSettings parameter. To be honest that is not my concern... As a developer I simply use ShortDateFormat and that's it. I guess the fpc developers traded debuggability for maintainability, so you could have a better fpc (more features or less bugs). That is what it concerns to you as developer. Maybe you disagree with that trade off. The GDB with all its cryptic stabs is not the most maintainable code of the compiler so it's definately not a maintenance trade-off. In fact, better debugaability would make maintenace of the compiler easier as well; the compiler remains an incredibly complex piece of technology that isn't always trivial to debug. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Variable can not be initialized by named constant
Op Mon, 2 Mar 2009, schreef Alexander Klenin: Since issue http://bugs.freepascal.org/view.php?id=13256 was marked resolved, I think this is quite reasonable to expect this to work. The writeability of constants is IMNSHO just an ugly leftover from Delphi history, and should be disabled in _both_ delphi and objfpc modes: Making typed constants writeable has been a disputed feature of the Borland dialect, I agree with that, but fact of the matter is they are writeable and thus cannot form a constant expression. The fact that there exists a $J directive does not change this. There are some estethic arguments against this: allowing them into initalization results in a break of the separation between declarations and code Pascal has: The declaration suddenly gets an assignment statement built-in. I forsee also practical problems: Procedure initialization code would become much more complex. Rather than storing a fixed value in a variable one would need to take care of dynamic types, like ansistring management. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Variable can not be initialized by named constant
Op Mon, 2 Mar 2009, schreef Alexander Klenin:
On Mon, Mar 2, 2009 at 03:16, Daniël Mantione
daniel.manti...@freepascal.org wrote:
Making typed constants writeable has been a disputed feature of the Borland
dialect, I agree with that, but fact of the matter is they are writeable and
thus cannot form a constant expression. The fact that there exists a $J
directive does not change this.
Well, I'd say a better way that, in Delphi, there exists an unfortunately
designed obscure option to make them writeable.
I think that that option default is even more unfortunate -- Pascal language
was always distinguished for its clarity and clean design,
and 'writeable constants' is neither clear nor clean, IMO.
This is a debate that has been held quite a few times :) If you look at
typed consts from the point of view what a mathematical constant is, yes,
it's completely absurd that you can write to them.
But... you need to look at typed consts what they do, and not how they are
named. If you look at the language feature typed consts from you will see
that they are not mathematical constants that exists only at compile time.
If you want a real constant that just has a type you can do something like
const x=longint(1). In contrast with constants, typed consts describes
actual data that will appear in memory.
The compiler cannot prevent you writing to data in memory, since at
runtime, the coder is the boss. All you need is to cast them into a
pointer. Works flawlessly, regardless of the $J state. From this point of
view of the function typed consts form, allowing writes to them isn't that
illogical.
First, allowing to write to a constant is much more aesthetically
unpleasant to me.
Actually, Free Pascal is the almost the only language I know
(besides assembler and FORTRAN IV) allowing such break-of-contract by default,
without the need of any casts or pointers.
Second, I do NOT suggest to convert declaration into an assignment.
As you correctly noted, it is debatable whether such a feature is good or
bad for the language.
Although I personally think that benefits outweigh the costs, this is
totally separate topic.
What I suggest is to:
1) Disallow changing of constants, making them worth their name
2) Allow using of typed constants at the same places as untyped ones,
including initializer expressions.
This should not affect code generation at all, just parsing an constant folding.
Remember again that:
const x:longint=1;{Defines a location in memory large enough to
hold an integer, which contains value 1.}
y=longint(1); {Defines a compile-time symbol that is equavalent to
writing longint(1) somewhere in the code.}
... do completely different things inside the compiler.
It will affect code generation, since typed consts are stored in memory.
There exists no constant folding for typed consts, because they need to be
layed out in memory exactly as the programmer describes, the compiler
cannot mess with that unlike with real compile-time constants. Basically
code has to be generated that reads the typed consts from their fixed
position in memory and copied into the variable.
Of course disallowing writing to typed consts is problematic because of
people making use of this functionality. After all, typed consts existed
long before initialized variables were invented and I'm sure people are
still using them.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$calling register} compiler-directive at wrong place (bug 12881)
Op Sun, 11 Jan 2009, schreef Joost van der Sluis:
{$calling cdecl}
...
procedure fftw_execute(plan:fftw_plan_single);
external 'fftw3f' name 'fftwf_execute'; // -- register
{$calling register}
How can that happen?
It may have to do something with the proceduren not being processed
immedeatelym, after which the preprocessor may have already set the
calling convention to register. It sounds like a serious bug.
Daniël___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode and UTF8String
Op Tue, 2 Dec 2008, schreef Michael Schnell: Nobody talks in this case about UTF-8. Even *ANSIstrings* in there native meaning can contain multi byte chars, there are *multi byte* ansi char sets. If there is a widely used multi-byte ANSI encoding, why so we need Unicode ? IMHO the introduction of Unicode has been necessary as (like you suggested) multi-byte ANSI encoding was commonly ignored nearly completely and there never has been _compiler_ support for them. What compiler support should be necessary to handle i.e. EUC-JP? You want a variable of type char to contain the JIS-0213 coordinates? Unicode, and in particular UTF-8, has not taken off either because languages got support for it. In fact, the most common language, C, has no string support at all. One reason Unicode has taken off because of document exchange, which in the internet age got very common. Another reason is the growing importance of the Far East, developers want therefore better support for the Far East languages, but note this Unicode motivation exists mainly for Western software developers. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode and UTF8String
Op Tue, 2 Dec 2008, schreef Michael Schnell: Thanks for pointing this out. GB2312 suits them well. Likewise, JIS 0213 suits the Japanese well. Are these called ANSI ? Yes, code page 936 and code page 932 are valid ANSI code pages. These standards by themselves of course not, because they are a Chinese respective Japanese industrial standard. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
