Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2004-06

1st post

4 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Marcel Martin

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 Delphi, i.e., should a routine always restore DF=0?

2) " end [ {$IFNDEF REGCALL} 'eax','ecx', {$ENDIF} 'edi']; " Is the previous line meaningful? (See the routine below)

3) When P is a PUI32 (PUI32 = ^Longword), I use Inc(P,Count) to increment P by Count (Count > 1). It compiles fine but there is the message "Conversion between ordinals and pointers are not not portable". What does it mean? Portable towards what? (I am compiling with {$MODE OBJFPC})

4) "Internal error 200310221". Let's say I have one program (set as primary file) and one unit. The only way to compile (and to build) both of them is to activate the unit window and to "build" from there. In all other cases, "compile" and "build" stop with this internal error. I suppose I didn't correctly configure something (?) (Windows 98, AMD 2600+)

Thanks in advance for your time.

mm http://www.ellipsa.net/ type TUI32 = Longword; PUI32 = ^TUI32; //============================================================================== // Fill P^ with Count 32-bit words equal to Value // Require: Count >= 0 //============================================================================== {$IFDEF NX_NOASMCODE} procedure nx_fill(P: PUI32; Count: Longint; Value: TUI32); var i : Longint; begin Assert(Count >= 0); for i := 1 to Count do begin P^ := Value; Inc(P); end; end; {$ELSE} // NX_NOASMCODE {$IFDEF NX_DEBUG} procedure nx_fill_debug(P: PUI32; Count: Longint; Value: TUI32); {$ELSE} procedure nx_fill(P: PUI32; Count: Longint; Value: TUI32); {$ENDIF} assembler; asm {$IFNDEF REGCALL} mov edi, P mov eax, Value mov ecx, Count {$ELSE} // re-ordering the procedure parameters could avoid 2 "mov" but // f(Value,P,Count) is less 'coherent' than f(P,Count,Value) mov edi, eax mov eax, ecx mov ecx, edx {$ENDIF} rep stosd end [ {$IFNDEF REGCALL} 'eax','ecx', {$ENDIF} 'edi']; {$IFDEF NX_DEBUG} procedure nx_fill(P: PUI32; Count: Longint; Value: TUI32); begin Assert(Count >= 0); nx_fill_debug(P,Count,Value); end; {$ENDIF} {$ENDIF} // NX_NOASMCODE

Reply by email

Peter Vreman
to Marcel Martin
Show quoted text 10 lines
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 Delphi, i.e., should a routine always restore DF=0?

Yes. That is part of the calling convention

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 not used for assembler procedures. But for assembler blocks within a procedure the information is used.

Show quoted text 5 lines
3) When P is a PUI32 (PUI32 = ^Longword), I use Inc(P,Count) to increment P by Count (Count > 1). It compiles fine but there is the message "Conversion between ordinals and pointers are not not portable". What does it mean? Portable towards what? (I am compiling with {$MODE OBJFPC})

That is a bug, please submit it to the bug repository. The message means that you are loading a pointer to an ordinal (=integer). This can lead to problems when compiling for 64bit platforms like x86-64 (that is already working and going to be supported in 1.9.6).

Show quoted text 6 lines
4) "Internal error 200310221". Let's say I have one program (set as primary file) and one unit. The only way to compile (and to build) both of them is to activate the unit window and to "build" from there. In all other cases, "compile" and "build" stop with this internal error. I suppose I didn't correctly configure something (?) (Windows 98, AMD 2600+)

That is a bug. Without sources we are not able to analyse and fix the problem. Try to minize the problem (guess that will be hard) and send me the sources so i can reproduce it.

Reply by email

Marcel Martin
to Peter Vreman

Hello,

Thanks for the quick answers.

Peter Vreman wrote 6 lines
> 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 not used for assembler procedures. But for assembler blocks within a procedure the information is used.

With "standard calling conventions", do you mean I have to write code like with Delphi (push/pop ebx,edi,esi)? Yesterday, I spent all day long to remove all these push/pop :-)
Should I also write push/pop for eax,ecx,edx when REGCALL is not defined?

Show quoted text 10 lines
> 3) When P is a PUI32 (PUI32 = ^Longword), I use Inc(P,Count) to > increment P by Count (Count > 1). It compiles fine but there is the > message "Conversion between ordinals and pointers are not not > portable". What does it mean? Portable towards what? (I am compiling > with {$MODE OBJFPC}) That is a bug, please submit it to the bug repository. The message means that you are loading a pointer to an ordinal (=integer). This can lead to problems when compiling for 64bit platforms like x86-64 (that is already working and going to be supported in 1.9.6).

I will do that.

Show quoted text 10 lines
> 4) "Internal error 200310221". Let's say I have one program (set as > primary file) and one unit. The only way to compile (and to build) > both of them is to activate the unit window and to "build" from > there. In all other cases, "compile" and "build" stop with this > internal error. I suppose I didn't correctly configure something (?) > (Windows 98, AMD 2600+) That is a bug. Without sources we are not able to analyse and fix the problem. Try to minize the problem (guess that will be hard) and send me the sources so i can reproduce it.

Unfortunately, I am not able to reproduce it myself! Now that I use a lot of units, it almost no more occurs. In fact, today it occurred only once not when using the mouse but when hitting Ctrl-F9.

Reply by email

Peter Vreman
to Marcel Martin
Show quoted text 17 lines
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 not used for assembler procedures. But > for > assembler blocks within a procedure the information is used. With "standard calling conventions", do you mean I have to write code like with Delphi (push/pop ebx,edi,esi)? Yesterday, I spent all day long to remove all these push/pop :-)

FPC is delphi compatible with it's calling conventions on i386.

Should I also write push/pop for eax,ecx,edx when REGCALL is not defined?

See remark above. There is no difference with delphi anymore. Also note that the REGCALL define is unsupported. It is only a temporary define used internally for bootstrapping a 1.9.x compiler. It'll be removed without notice in the development series after 2.0.

Reply by email