Hello,
For those who never heard of it, i.e., almost everybody :-) I am
writing a big number library for FPC 2.x called NX. It is a
freeware and its source is available. Currently, NX contains only
big integers and big polynomials over GF(2) but, if all goes well,
the units nxfloats and nxcomplex
Hello,
Maybe this has no importance but some file dates are not correct
on the server :
ftp://ftp.freepascal.org/pub/fpc/snapshot/v20/i386-win32
File: base.i386-win32.zip 8496 KB 31/08/2004 01:28:00
^
ftp://ftp.freepascal.org/pub/fpc/snapshot/v21/
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
speci
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 me
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 corre
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 corre
Let it be. I just saw that, in fact, you told about the
problem in the subject of the post :-)
mm
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Tom Verhoeff a écrit :
begin
VMyClass := TMyClass.Create;
//VMyClass.FP := VMyClass.P; { with this assignment, it works }
VMyClass.FP; { this causes an Access Violation }
Of course, at this point FP = nil since you didn't set it.
mm
___
fpc-
Florian Klaempfl a écrit :
Marcel Martin wrote:
Hello,
I need to know *at compile time* whether the type Real is
Single or Double. Currently, I use this
{$IFDEF FPC_HAS_TYPE_DOUBLE}
...
{$ELSE}
{$IFDEF FPC_HAS_TYPE_SINGLE}
...
{$ELSE}
{$FATAL Type Real should be defined as Single or as
Hello,
I need to know *at compile time* whether the type Real is
Single or Double. Currently, I use this
{$IFDEF FPC_HAS_TYPE_DOUBLE}
...
{$ELSE}
{$IFDEF FPC_HAS_TYPE_SINGLE}
...
{$ELSE}
{$FATAL Type Real should be defined as Single or as Double}
{$ENDIF} // FPC_HAS_TYPE_SINGLE
{$ENDIF} // F
About the bug report #3931
>The following does not compile:
>jmp dword ptr [@@FwdJumpTable+ecx*4] <---
>nop {Align Jump Table}
>@@FwdJumpTable:
[...]
Use "jmp dword ptr @@FwdJumpTable[ecx*4]"
Don't use "nop" to align, use the "align" instruction (Yes, FPC
is better than Delphi :-)
mm
__
Hello,
While writing the "pure Pascal" version of a big integer library
(for FPC 2.0), I notice that the use of a very small assembler
function lowers the average running time of the computations by
about 30-35%. This is far from insignificant.
Currently I use a macro to enable the x86 (32 bits) pr
Michael Van Canneyt wrote:
On Thu, 24 Mar 2005 [EMAIL PROTECTED] wrote:
procedure MyXYZPart.DoReport(aRep: IReportable);
begin
if (aRep <> nil) then begin
if (aRep is ILogged) then
(aRep as ILogged).Log(aRep.Report)
else
aRep.Report
end;
I see what you want, but if you would do
pr
Micha Nelissen wrote:
The problem with your approach is: how do you know whether the
memory was extended, or left alone because there was no memory
available to extend it ? In general, shortage of memory produces
a runtime error, but this is configurable by a global var.
No, that's easy. If
Since tonight, I cannot access the 'last 7 days' bug page.
Here is the error message
Warning: mysql_connect(): User 'FPCUser' has exceeded the
'max_connections' resource (current value: 10) in
/FPC/html/bugs/bugs.php on line 11
mm
___
fpc-pascal mailli
mm wrote:
compute !1, i.e., Factorial 1. Currently, all you have
Of course, I should have written "1!" and not "!1".
mm
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Marcel Martin a écrit :
>
> Hello,
>
> The following function SysReAllocMem comes from the file
> /rtl/inc/heap.inc (FPC 1.9.7 / Win32)
>
> function SysReAllocMem(var p: pointer; size: ptrint):pointer;
> [...]
>{ Resize block }
>if not SysTryRes
Hello,
The following function SysReAllocMem comes from the file
/rtl/inc/heap.inc (FPC 1.9.7 / Win32)
function SysReAllocMem(var p: pointer; size: ptrint):pointer;
[...]
{ Resize block }
if not SysTryResizeMem(p,size) then
begin
minsize := MemoryManager.MemSize(p);
if size < mi
Hello,
Yesterday, I downloaded 1.9.5 (executable for Windows). I wanted
to check whether the bug #3335 (which makes the IDE unusable under
Windows) had been fixed.
1) install.exe doesn't work. A windows is opened but it is
immediately followed by a dialog box notifying that the program
is abou
Alan Mead a écrit :
>
> I don't know if this is really a bug or whether it's known... I have
> this line of code:
>
> while ( (i<=Length(fmt)) and (NOT fmt[i] IN ['0'..'9']) ) do
> inc(i);
>
> It compiles fine but I get a RTE:
>
> An unhandled exception occurred at 0x0807B180 :
> EVariantErro
Alan Mead a écrit :
>
> I don't know if this is really a bug or whether it's known... I have
> this line of code:
>
> while ( (i<=Length(fmt)) and (NOT fmt[i] IN ['0'..'9']) ) do
> inc(i);
>
> It compiles fine but I get a RTE:
>
> An unhandled exception occurred at 0x0807B180 :
> EVariantErro
Stephen Downs a écrit :
>
> I am porting a Mac CodeWarrior project to FreePascal and have hit a
> compile problem with a pointer. In my original code I have a structure
> defined along the lines of
>
> testData = record
>testIndex : array [0..12] of integer;
> end;
>
> testDataPointer = ^te
Vincent Snijders a écrit :
>
> Marcel Martin wrote:
> > Hello,
> >
> > I am using fpc 1.9.5 (2004/09/15).
> >
> > There is a problem with the unit heaptrc and the routine
> > Reallocmem. For instance
> >
> > var p : PLongword;
> >
&g
Hello,
I am using fpc 1.9.5 (2004/09/15).
There is a problem with the unit heaptrc and the routine
Reallocmem. For instance
var p : PLongword;
Reallocmem(p,1000*4);
...
Reallocmem(p,200*4); <- this instruction upset heaptrc
Does the problem come from Reallocmem or from the heaptrc unit
Hello,
I saw in the file fpc/rtl/i386/int64p.inc that the function
fpc_mod_qword was disabled with the comment "This does not work
correctly".
The problem is a bad instruction (presumably a typo):
.Lqwordmodr_big_divisior:
|
|
shrdl %cl,%edx,%eax
shrl %cl,%edx
rorl $1,%ed
Anton Tichawa a écrit :
>
> Hello List!
>
> Compiling the unit
>
> ===
>
> unit test;
>
> interface
>
> procedure test.do_test;
>
> implementation
>
> procedure test.do_test;
> begin
> end;
>
> end.
>
> ===
>
> results in compiler errors:
>
> test.pas(5,15) Error: overloaded identifier
Ron Weidner a écrit :
>
> I thought I was getting closer to understanding
> pointers but it appears that I'm still not getting it.
> I wrote the following code fragment but it doesn't
> compile. the errors I get are...
>
> Widget_container_class.pas(80,27) Error: Illegal
> qualifier
> Widget_co
Florian Klaempfl a écrit :
>
> Marcel Martin wrote:
>
> > Florian Klaempfl a écrit :
> >
> >>Thomas Schatzl wrote:
> >>
> >>>In this case
> >>>
> >>> procedure nx_fill(P: PLongword; Count: Longint; Value: Longword);
&
Florian Klaempfl a écrit :
>
> Thomas Schatzl wrote:
> >
> > In this case
> >
> > procedure nx_fill(P: PLongword; Count: Longint; Value: Longword);
> > assembler;
> > asm
> > pushl %edi
> > movlP,%edi // edi <- P
> > movlValue,%eax // eax <- Value
>
Thomas Schatzl a écrit :
>
> Hello,
>
> I noticed that, with FPC 1.9.4, the (default) calling convention
> "register" depends on the fact that a routine is or is not embedded
> in an other routine.
>
> With "proc(A,B,C: Longint);", if "proc" is not embedded then
> eax = A
Peter Vreman a écrit :
>
> Check what Delphi does for nested procedures. If it is different from FPC
> then FPC will be adapted.
>
Overall, no :-) Delphi (at least the version 5.01) is bugged.
For instance, with
function Add: Longword;
var x : Longword;
function DoAdd(a: Longword): Lo
Marco van de Voort wrote:
> Marcel Martin wrote:
> >
> > I noticed that, with FPC 1.9.4, the (default) calling convention
> > "register" depends on the fact that a routine is or is not embedded
> > in an other routine.
> >
> > With "proc(A,B
Hello,
I noticed that, with FPC 1.9.4, the (default) calling convention
"register" depends on the fact that a routine is or is not embedded
in an other routine.
With "proc(A,B,C: Longint);", if "proc" is not embedded then
eax = A, edx = B and ecx = C but if "proc" is embedded then edx = A,
ecx =
Peter Vreman a écrit :
> Added support for the ALIGN directive also to asmmode intel.
Thanks.
BTW, nobody answered about the problem with "Level 2 Optimizations"
I reported here a few days ago. Is it a bug of the compiler? I ask the
question because at the moment I am sure of nothing (sometimes
Peter Vreman a écrit :
>
> > Hello,
> >
> > With v1.9.4, is there a way to align a label in an assembler
> > procedure?
>
> .align, .balign or .p2align
I forgot to tell "with {$ASMMODE INTEL}". But if I understand you
well, in order to use aligned labels, I have to (re-)write the code
with the
Hello,
With v1.9.4, is there a way to align a label in an assembler
procedure?
Thanks
--
mm
http://www.ellipsa.net/
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Hello,
Here is a bug (?) of the compiler (FP 1.9.4) when setting Level 2
Optimizations. I post it here since I don't believe it is possible
to use the bug report form. (I work with Win98, AMD 2600+)
Types used in the code.
type
TBigInt = record
Digits: PDigits;// pointer to a digit
Hello,
Thanks for the quick answers.
Peter Vreman a écrit :
> > 2) " end [ {$IFNDEF REGCALL} 'eax','ecx', {$ENDIF} 'edi']; "
> > Is the previous line meaningful? (See the routine below)
>
> No, FPC 1.9.x follows standard calling conventions. The changed registers
> are fixed. This information is
Hello,
At first, thanks and congratulations for Free Pascal.
I am trying to convert all my libraries (big integers, big floats,
etc) from Delphi 5 to Free Pascal 1.9.4. As a total newbie with Free
Pascal, I have some questions.
1) In an assembler routine, is the direction flag managed like in
39 matches
Mail list logo
