Re: [fpc-pascal] fast integer multiplication

2005-07-29 Thread Florian Klaempfl
Peter Vreman wrote:

>>Florian Klaempfl a écrit :
>>
>>>Vincent Snijders wrote:
>>>
>>>
>>>
Hi,

Suppose I have the following code:

var
 a,b: dword;
 c: qword;

begin
 a := 1000;
 b := 2000;
 c := a * b;
 writeln(c);
end.

Now, although c is large enough to contain the result only the lower
dword is filled. I can force correct results by using c := qword(a) * b,
but the slow fpc_mul_qword is used.

The code generated for the above sample is:
# [16] c:=a*b;
   movlU_P$PROJECT1_A,%edx
   movlU_P$PROJECT1_B,%eax
   mull%edx
   movl$0,%edx
   movl%eax,U_P$PROJECT1_C
   movl%edx,U_P$PROJECT1_C+4

What I want is the above code, but without the "movl $0,%edx"
instruction. Is there a way to do this (wihtout using fpc_mul_qword).
> 
> 
> No. At the time a*b is calculated there is nothing known about the size of
> the result.

a*b knows that it should do a qword multiplication and it can check if both
operands are dword. It could remove the type casts then and do a mulll.

> 
> 
> 
>>>Only assembler for now. Any suggestions how the compiler could be told
>>>to generate such code?
>>
>>Since you ask the question, I suppose you cannot simply
>>suppress the "movl $0,%edx" line generation [*]. What about
>>using a compiler directive, something like {$EXTENDEDMUL ON/OFF}
>>for instance?
> 
> 
> I don't like this. This means we have to add directives for all kind of
> special cpu features to improve some special corner cases.

Me neither.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fast integer multiplication

2005-07-29 Thread Marcel Martin

Peter Vreman a écrit :
>Marcel Martin wrote :

Since you ask the question, I suppose you cannot simply
suppress the "movl $0,%edx" line generation [*]. What about
using a compiler directive, something like {$EXTENDEDMUL ON/OFF}
for instance?



I don't like this. This means we have to add directives for all kind of
special cpu features to improve some special corner cases.


But it is a special case because FPC makes it special. As I wrote
yesterday, when you write Word := Byte * Byte, what you get is
the exact result (not the result mod 2^8), when you write
Longword := Word * Word, what you get is the exact result (not the
Result mod 2^16), but when you write QWord := Longword * Longword,
there, what you get is not (always) the exact result but the result
mod 2^32. This is FPC which makes special this case by setting the
product high part to 0 (what it doesn't do with other cases).

Being said that, I agree with you that adding compiler directives
is not a good thing [*]. Here, it would be sufficient to suppress
the generation of the line "movl $0,%edx". Since you do not do so,
I suppose there would be some side effects I don't see at the
moment, but it would be the simplest solution.

[*] If QWord := Longword * Longword gave the exact result, it would
allow me to suppress a lot of compiler directives :-)

MM

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fast integer multiplication

2005-07-29 Thread Jonas Maebe


On 29 Jul 2005, at 11:36, Marcel Martin wrote:


But it is a special case because FPC makes it special.


No, it's simply a consequence of the fact that Pascal performs all  
calculations using the native integer type by default.



Jonas

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fast integer multiplication

2005-07-29 Thread Peter Vreman
>>>Since you ask the question, I suppose you cannot simply
>>>suppress the "movl $0,%edx" line generation [*]. What about
>>>using a compiler directive, something like {$EXTENDEDMUL ON/OFF}
>>>for instance?
>>
>> I don't like this. This means we have to add directives for all kind of
>> special cpu features to improve some special corner cases.
>
> But it is a special case because FPC makes it special. As I wrote
> yesterday, when you write Word := Byte * Byte, what you get is
> the exact result (not the result mod 2^8), when you write
> Longword := Word * Word, what you get is the exact result (not the
> Result mod 2^16), but when you write QWord := Longword * Longword,
> there, what you get is not (always) the exact result but the result
> mod 2^32. This is FPC which makes special this case by setting the
> product high part to 0 (what it doesn't do with other cases).
>
> Being said that, I agree with you that adding compiler directives
> is not a good thing [*]. Here, it would be sufficient to suppress
> the generation of the line "movl $0,%edx". Since you do not do so,
> I suppose there would be some side effects I don't see at the
> moment, but it would be the simplest solution.
>
> [*] If QWord := Longword * Longword gave the exact result, it would
> allow me to suppress a lot of compiler directives :-)

The rules are the same as with int64:=longint*longint. Below is a test.
The result is -2 on both fpc and delphi.

var
  e : int64;
  i,j : longint;

begin
  i:=$7fff;
  j:=2;
  e:=i*j;
  writeln(e);
end.




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fast integer multiplication

2005-07-29 Thread Marcel Martin

Peter Vreman a écrit :

Since you ask the question, I suppose you cannot simply
suppress the "movl $0,%edx" line generation [*]. What about
using a compiler directive, something like {$EXTENDEDMUL ON/OFF}
for instance?


I don't like this. This means we have to add directives for all kind of
special cpu features to improve some special corner cases.


But it is a special case because FPC makes it special. As I wrote
yesterday, when you write Word := Byte * Byte, what you get is
the exact result (not the result mod 2^8), when you write
Longword := Word * Word, what you get is the exact result (not the
Result mod 2^16), but when you write QWord := Longword * Longword,
there, what you get is not (always) the exact result but the result
mod 2^32. This is FPC which makes special this case by setting the
product high part to 0 (what it doesn't do with other cases).

Being said that, I agree with you that adding compiler directives
is not a good thing [*]. Here, it would be sufficient to suppress
the generation of the line "movl $0,%edx". Since you do not do so,
I suppose there would be some side effects I don't see at the
moment, but it would be the simplest solution.

[*] If QWord := Longword * Longword gave the exact result, it would
allow me to suppress a lot of compiler directives :-)



The rules are the same as with int64:=longint*longint. Below is a test.
The result is -2 on both fpc and delphi.

var
  e : int64;
  i,j : longint;

begin
  i:=$7fff;
  j:=2;
  e:=i*j;
  writeln(e);
end.


I was talking about the unsigned cases (but, yes, this is the
same with signed ones).

Now, concerning "both fpc and delphi". That Delphi code can be
compiled with FPC is rather good thing but FPC has not to follow
Delphi. The future of Pascal is not Delphi, it is FreePascal. And,
no, for once, I am not joking. :-)

I recently downloaded Lazarus. I wanted to see whether it could
be possible to adapt one of my softwares ("Primo", see at
http://www.ellipsa.net, written with Delphi 5). After having played
a few hours with Lazarus, I estimated that it was feasible and that
it could take me two weeks to do it. I was wrong. It took me less
than three days! Yes, in less than three days, a version of Primo
entirely written with FreePascal and Lazarus was working. Well,
there still are many "cosmetic" problems but it works.
I think that, in at most one year, it will be possible to write
very good programs with FreePascal and Lazarus (I am talking of
programs having clean GUI's).

MM

BTW, since a few days, I have big problems with this list. Most of
my posts come back with messages like:

  Diagnostic-Code: X-Postfix; host lists.freepascal.org[130.161.36.93]
  said: 550-32 x Worm.Lovgate.Z. Last seen 2005-07-29 11:01:07.905214
  (CET) 550 mail from 213.228.0.176 rejected: administrative
  prohibition (host is blacklisted) (in reply to RCPT TO command)

No, there is no worm on my PC ;-)

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] ExecuteProcess

2005-07-29 Thread Michael Van Canneyt


On Thu, 28 Jul 2005, L505 wrote:

> | I will check it, although I "prefer" a platform independent aproach.
>  
> 
> Same .. if anyone knows of other ways to pipe, let us know.

Use TProcess. Works currently on windows and unixes.
See the Lazarus IDE sources for ways how to use it.

Michael.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] fast integer multiplication

2005-07-29 Thread Peter Vreman
> Now, concerning "both fpc and delphi". That Delphi code can be
> compiled with FPC is rather good thing but FPC has not to follow
> Delphi. The future of Pascal is not Delphi, it is FreePascal. And,
> no, for once, I am not joking. :-)

Most users expect the same behaviour in delphi and fpc. We get a lot of
bug reports if we make something incompatible. Even if we document things
properly  the users will start complaining. And projects like CrossFPC are
requesting even more compatibility with Kylix/Delphi.




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal