Re: [fpc-devel] PR advancement
Ales Katona wrote: 5. Isn't Free Software equal to crappy software? You're right. About Proprietary Software, there is no need to ask the question, the answer is obvious. mm ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics; Vote
[EMAIL PROTECTED] wrote: Delphi.Net2.0 is using Chrome is using C# is using C/C++ is using Why should FPC use generics ??? Why should FPC be Pascal-ish? Is that your question? :-) mm ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
Hans-Peter Diettrich a écrit :
Marcel Martin wrote:
Unexpected overflows? The overflows occur or not according to
simple rules, perfectly defined, which ones depend on the types
of the operands.
Unexpected as depending on the values, not on the types. When the ranges
of the possible operands are known, it's also known whether an overflow
can occur in computations with these operands.
But overflows cannot be unexpected. If x is a Longword and
if x 0, Inc(x,-1) will raise an overflow. And this is not
unexpected.
It is unexpected, for multiple reasons:
1) From online help in D4:
Inc(X) corresponds to the statement X := X + 1, and Inc(X, N)
corresponds to the statement X := X + N.
I cannot see any correspondence, when one form produces overflows,
whereas the other form doesn't.
It shouldn't. Under the same circumstances, both have to
raise overflows. Here, it's not the overflow rules that are
inconsistent but the way they are implemented by such or
such compiler.
2) The overflow only occurs for special, machine specific conditions.
The writer of high level language code IMO can expect that no machine
specific details will influence the behaviour of his code, else the
compiler at least must issue appropriate warnings.
I agree. But what is the link with the fact that in no case
the compiler should code a Inc(x,-1) as a Dec(x,1)?
Since I don't have the current FPC compiler, I refer to D4 in this
(hopefully) last example:
This list is named fpc-devel ;-)
type
TCard = 0..1000; //or 0..$ or 0..$8000
var
x: TCard;
const
c = -1;
begin
x := 5;
x := x + c;
Inc(x, c);
end;
Here no overflow occurs, at least not in D4.
No more with FPC. But with {$R+}, FPC will raise a range
check error if the resulting x is not in 0..1000. (For Delphi,
I don't know, it's too boring to get the generated assembler
code.)
An overflow occurs only in
the special case where the upper bound of the type is $, in
general when the highest bit in the highest byte of the memory
representation is part of the type. Would you call this an expected
behaviour?
Yes. Because I know that overflows only occur with 'native'
types :-)
IMO the inconsistent behaviour of the above code is a bug. I can accept
such behaviour only with respect to *full* Delphi compatibility,
This is the last reason for which I would accept. FPC has not to
follow Delphi and still less to be compatible with Delphi bugs.
(The future of Pascal is not Delphi, this is FPC ;-)
where
every bug must be reproduced also by the FPC compiler. Otherwise I
expect a consistent and machine independent compilation and execution of
all high level language code.
From that point of view, FPC is incomparably better than Delphi.
Now, yes, maybe FPC developpers could add some code to check
overflows even for 'exotic' types. If you really need it, ask
them.
We have a big, BIG, communication problem...
I realized already that we are talking about different things :-(
I'm talking about computation in general, you're talking about machine
specific number representations and calculations.
We are talking about Should the compiler replace Inc(x,-1)
by Dec(x,1)? The answer is no. And that's not because perfectly
defined overflow rules are not correctly implemented in Delphi
that this answer should change.
Please check your arguments with regards to unsigned types in general,
i.e. any zero-based integer type.
With your example? If the same rules would apply for both user
defined types and native types, in x := x + c, the compiler
should regard c = -1 as c = 1000 (since the range 0..1000 is
the one of the residues modulo 1001). So x := x + c should be
coded as x := x + 1000 (or an error should be raised because -1
is not in 0..1000) and if x 0, with {$Q+}, the operation
should raise an overflow. The same for Inc(x,c). (Notice that
with Dec(x,1), an overflow should occur only if x = 0 whereas
with Inc(x,-1) it should occur only if x 0. These two
instructions yield the same result but they don't get it the
same way and, thus, are not equivalent.)
mm
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
Marcel Martin a écrit :
Hans-Peter Diettrich a écrit :
As outlined before, the above assignment of x:=-x should
raise an range check error. A comparison of x=-x will return False, in
the Int64 range.
Not with FPC. (Moreover, I didn't make comparisons, I only
used := and -.)
But, if X is a Longint equal to -2^31, with {$Q+}, the
instruction x := -x; should raise an overflow and it
would seem it doesn't (I just checked it with FPC v2.0).
This, this is a bug.
mm
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
Hans-Peter Diettrich a écrit :
Peter Vreman wrote:
IMO the compiler can convert between Inc and Dec, for negative
constants, so that the value always is positive, compatible with
signed and unsigned data types.
That means different behaviour between the use of a variable or constant.
That is something you never want.
Why not? I expect that the compiler evaluates constant expressions, and
creates the best code for the resulting values.
The best code is, before all, the correct code.
So, if x is a Longword and if SomeConstant equals
-1, either it adds $ (and there will be an overflow
if x 0) or it stops at compile time saying that -1 is not
a Longword.
In the case of Inc(x, SomeConstant) the value of the named constant can
be changed, with arbitrary positive or negative values. Would you then
want to find all uses of someconst in your code, to find out where
your code deserves a modification?
If I declare a constant as an unsigned integer, if I wrote my
code assuming it is an unsigned integer and if, suddenly,
I decide to change that, of course, I may expect some problems.
Note: I have the feeling that you are confusing signed/unsigned
and negative/positive. When I talk of unsigned integers, I am not
talking about signed ones that may be positive. No, I am talking
about integers that can never be negative.
IMO every calculation, that can result in illegal results in *normal*
operation, has to be handled appropriately in the code. If no problems
are predicted, expected, and handled, in explicit code, the compiler
only has to care about coding errors, that result in *unexpected*
overflows. I don't think that a calculation should produce or not
produce an overflow, depending only on the sign of the given value.
Unexpected overflows? The overflows occur or not according to
simple rules, perfectly defined, which ones depend on the types
of the operands.
If A is a Longword (this is an unsigned type, no instance can be
negative). So if A = 2^32-1 and if I compute A + 1, there is an
overflow because the resulting value should be 2^32 and this value
doesn't exist for the Longword type.
From
the mathematical viewpoint +(+1) and -(-1) is perfectly equivalent, as
is +(-1) and -(+1).
Computationally, this is not equivalent.
+(-1) - add eax, $
-(+1) - sub eax, $0001
And at this point, even if we know the content of eax before the
operation, we cannot know if there is or not an overflow without
knowing the type of the integer contained in eax.
Moreover, when programming, mathematical considerations have to
be handled with care. Mathematically, (x = -x) - (x = 0).
Computationally, this is wrong (because the computer doesn't work
over the ring Z but over a ring Z/2^kZ). If x is a Longint and
if x = -x, either x = 0 or x = -2^31.
Try this
x : Longint;
...
x := Longint($8000); // x := -2^31
WriteLn(IntToStr(x));
x := -x;
WriteLn(IntToStr(x));
(And this is not a bug. This is a consequence of the 2-complement
representation of signed integers.)
When there exist reasons why such expressions should
be handled differently, the user is responsible for indicating such an
exceptional situation.
If the situation is such that I want no overflows, I always can
tell the compiler: {$Q-}.
mm
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
Vinzent Hoefler a écrit :
On Thursday 07 July 2005 05:39, Peter Vreman wrote:
shouldn't it implement inv(v,-1) in exactly the same way it
implements v:=v-1?
The problem is what type do you give to -1. In the old situation the
-1 was converted to the same type as v - longword.
Which should trigger a range check already, because -1 can't be
represented as valid longword.
Personal note: Maybe there was a reason why Borland Pascal didn't do
range checks on Inc/Dec.
Yes, there is always a good reason for a bug :-)
To the FPC team.
If ever you changed that, i.e., if you suppressed the overflows
with Inc and Dec, thanks to let us know explicitely (here, for
instance). Personally, I would have to rewrite a few lines of
code, like, for instance, in
procedure XDiv2(X: PBigFloat);
begin
with X^ do if not IEqu0(Mantissa) then {$Q+} Dec(Exponent); {$Q-}
end;
The only time I ever used it was a checksum
calculation which was modulo anyway. Any other time I use the usual
operators. So especially with the added overflow check I think, Inc
and Dec are pretty useless functions, because the don't do anything you
can't accomplish by using + or - unless you have
very_long_and_complex_variable_names and want to save some typing work.
That's a matter of habit. Not sure but I believe that with TP3,
the compiled code was better with Inc than with +.
mm
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
peter green a écrit : shouldn't it implement inv(v,-1) in exactly the same way it implements v:=v-1? Well, I am far to be an expert in compilers but I think no, it shouldn't. v := v + Longword(-1) is different from v := v - Longword(1). The resulting value v is the same but not the way to get it. If, as a programmer, I write 'Inc', the compiler should code an addition and not a subtraction. mm ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Not really a bug...
Peter Vreman a écrit : Hello, I am using FPC 2.0.0, Win32. When subtracting a longword from a longword, FPC codes the operation as if it were a 64-bit operation. This is not really a bug since the code is correct but this uselessly increases the running times and the sizes of the executables. (I found no bug report about that) There were a couple of bug reports about this issue. It is already fixed in current svn. I am using FPC 2.0.0 with some files overwritten by the ones downloaded from ftp://ftp.freepascal.org/pub/fpc/snapshot/v21/i386-win32/ (file base.i386-win32.zip) and the problem is still there. base.i386-win32.zip doesn't contain updated files? mm ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Not really a bug...
Hello, I am using FPC 2.0.0, Win32. When subtracting a longword from a longword, FPC codes the operation as if it were a 64-bit operation. This is not really a bug since the code is correct but this uselessly increases the running times and the sizes of the executables. (I found no bug report about that) For instance, with u, v and w Longwords, the following subtraction u := v - w; is coded as movl U_P$TEST2_V,%eax movl $0,%ebx movl U_P$TEST2_W,%ecx movl $0,%edx subl %ecx,%eax sbbl %edx,%ebx movl %eax,U_P$TEST2_U Here, not only 2 movl's and 1 sbbl are useless but FPC also wastes time to save/use/restore extra register(s). At the moment, the only work around I found to make a subtraction with Longwords is to write the operation this way: u := Longword(Longint(v) - Longint(w)); coded as movl U_P$TEST2_V,%eax subl U_P$TEST2_W,%eax movl %eax,U_P$TEST2_U notice that u := v; Dec(u,w); movl U_P$TEST2_V,%eax movl %eax,U_P$TEST2_U movl U_P$TEST2_W,%eax subl %eax,U_P$TEST2_U shows there is no problem with Dec (the same with Pred(), if u is a Longword, writing u-1 is not ok but writing Pred(u) is ok). mm ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Function variables and overload
Hello, Let's say there is a function function ICmp(A,B: PBigInt): SInt32; and a TBigIntList class having the following method that can sort the list according to Cmp procedure TBigIntList.Sort(Cmp: TBigIntCompareFunc); with, of course, type TBigIntCompareFunc = function(A,B: PBigInt): SInt32; Now, if ICmp is not overloaded, there is no problem, the call L.Sort(@ICmp); works. But, of course, it doesn't work if ICmp is overloaded. In fact, we cannot have both overloaded functions _and_ the the possibility to use them as variables. Yes, there are ways to fix the problem (no overload or embedding the overloaded functions in local functions) but none is really satisfying. Would it be possible to get something like L.Sort(@ICmp(PBigInt,PBigInt)); in case ICmp is overloaded? If we could add the parameter types, there would be no more ambiguity, the compiler would exactly know which overloaded function it has to use. When I ask 'would it be possible', I mean 'would it be possible without having to rewite all the compiler' ;-) mm ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Function variables and overload
Peter Vreman a écrit : Hello, Let's say there is a function function ICmp(A,B: PBigInt): SInt32; and a TBigIntList class having the following method that can sort the list according to Cmp procedure TBigIntList.Sort(Cmp: TBigIntCompareFunc); with, of course, type TBigIntCompareFunc = function(A,B: PBigInt): SInt32; Now, if ICmp is not overloaded, there is no problem, the call L.Sort(@ICmp); works. But, of course, it doesn't work if ICmp is overloaded. In fact, we cannot have both overloaded functions _and_ the the possibility to use them as variables. Yes, there are ways to fix the problem (no overload or embedding the overloaded functions in local functions) but none is really satisfying. Would it be possible to get something like L.Sort(@ICmp(PBigInt,PBigInt)); in case ICmp is overloaded? If we could add the parameter types, there would be no more ambiguity, the compiler would There is ambiguity with a normal call to the function. The compiler sees the ( and thinks it is parsing a call to Icmp(). Yes. I already encountered this problem when using a function variable. Ok. And this way L.Sort(@ICmp:PBigInt:PBigInt); and if ever ICmp was overloaded but had no parameter L.Sort(@ICmp); Well, of course, I don't know the compiler enough to propose something clean and not ambiguous but the problem is not to find a way to tell the compiler Use this routine and not an other one, I am sure it is not too much difficult. No, the problem is Is it easy to modify the parser in order to implement it?. It would really be nice to be able to use overloaded routines as non overloaded ones. At the moment, in order not to lose the possibility to transmit routines to lists, like procedure TBigIntList.ForEach(Proc: TBigIntBinaryOperator; A: PBigInt; Test: TBigIntTestFunc=nil); // add A to all even integers of the list L.ForEach(@IAdd,A,@IIsEven); which is much faster than for i := 0 to L.Count-1 do if IIsEven(L[i]) then IAdd(L[i],A); I suppressed most overloaded routines by adding suffixes: IAddUI32, IAddSI32, IAddUI64, etc. It works but that's rather ugly :-) To conclude, if you cannot add such a feature to FPC, you cannot. Don't worry, FPC is already very good as it is. mm ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
