Re: [fpc-pascal]Behavior of system.New procedure
You are not to presume anything. Perhaps it will be random, perhaps it will be zero filled - depends on the compiler amongst other things. You must do as if it contains the most unexpected data, and therefore initialise the fields *yourself*, and the safer is to do it the quicker. Regards. En réponse à Luiz Américo <[EMAIL PROTECTED]>: > If someone can help me with this... > Take the following example: > > type > TRec = record >Apointer:Pointer; >AInt:Integer; > end; > PRec = ^TRec; > > var >Arec:PRec; >Return:Boolean; > > begin >New(ARec); >Return:=ARec^.APointer = nil; (Always True ?) >Return:=ARec^.Aint = 0; (Always True ?) > end. > > > My question is: > after allocating a new instance for Arec with New proc, the record > fields (APointer and Aint) will be always zero filled or will receive > random values? > > Thanks in advance > > Luiz __ Jérémie Lefrançois 06 73 27 35 97 Consultant Altran Technologies ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Default calling convention
> 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,C: Longint);", if "proc" is not embedded then >> > eax = A, edx = B and ecx = C but if "proc" is embedded then edx = A, >> > ecx = B and C is on the stack. >> > >> > Is this convention definitive or temporary? I am not sure it is >> > definitive since it makes the code of assembler routines dependent >> > on their status: embedded or not. > >> In general it is not wise anyway to let the assembler become to >> dependant >> on calling convention. > >> Keep on using > >> mov eax,param1 >> mov ecx,param2 > >> etc. Clearer, and doesn't have the problem between >> procedure/methods/nested >> procedures. > > I agree with you but it doesn't work. For instance, take this > procedure > > procedure nx_fill(P: PLongword; Count: Longint; Value: Longword); > assembler; > asm > pushl %edi > movl Value,%eax > movl Count,%ecx > movl P,%edi > rep > stosl > popl %edi > end; > > in the .s file, FPC 1.9.4 produces this: > > .globl NXKERNEL_NX_FILL$PLONGWORD$LONGINT$LONGWORD > pushl %ebp > movl %esp,%ebp > pushl %edi > movl %ecx,%eax // eax is modified > movl %edx,%ecx > movl %eax,%edi // eax is more equal to P, access violation > rep > stosl > popl %edi > ret > > With this one > > procedure nx_fill(P: PLongword; Count: Longint; Value: Longword); > assembler; > asm > pushl %edi > movl%eax,%edi // edi <- P > movl%ecx,%eax // eax <- Value > movl%edx,%ecx // ecx <- Count > rep > stosl > popl%edi > end; > > the produced code is correct but now this proc can no more be used as a > nested proc. Check what Delphi does for nested procedures. If it is different from FPC then FPC will be adapted. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Default calling convention
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 = B and C is on the stack. Is this convention definitive or temporary? I am not sure it is definitive since it makes the code of assembler routines dependent on their status: embedded or not. This is exactly the same as Delphi (7) behaves. procedure nx_fill(P: PLongword; Count: Longint; Value: Longword); assembler; asm pushl %edi movl%eax,%edi // edi <- P movl%ecx,%eax // eax <- Value movl%edx,%ecx // ecx <- Count rep stosl popl%edi end; In this case procedure nx_fill(P: PLongword; Count: Longint; Value: Longword); assembler; asm pushl %edi movlP,%edi // edi <- P movlValue,%eax // eax <- Value movlCount,%ecx // ecx <- Count rep stosl popl%edi end; works both as embedded and non-embedded assembler procedure because the order of assignments is ok in both cases. Btw, there's already a method in the system unit which does the same thing as your routine: filldword()... Regards, Thomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Default calling convention
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): Longword; register; var y : Longword; asm mov y, 1 add eax, x add eax, y end; begin x := 7; Result := DoAdd(1); end; The result should be 9 (1+7+1) but for Delphi it is only 3. "DoAdd" is coded this way mov [ebp-$04], $0001 // mov y, 1 add eax, [ebp-$4] // add eax, x add eax, [ebp-$4] // add eax, y i.e., for Delphi 5.01, x and y are the same thing! I think the best thing that could be done would be to manage so that FPC always makes use of [ebp-something] to access a parameter when the programmer makes use of the parameter name, i,e., with any calling convention the instruction "mov eax,param" should never be coded as "mov eax,reg" but always as "mov eax,[ebp-something]". -- mm http://www.ellipsa.net/ ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Default calling convention
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, edx = B and ecx = C but if "proc" is embedded then edx = A, > ecx = B and C is on the stack. > > Is this convention definitive or temporary? I am not sure it is > definitive since it makes the code of assembler routines dependent > on their status: embedded or not. > > This is exactly the same as Delphi (7) behaves. I don't know, I have Delphi 5.01. > >> procedure nx_fill(P: PLongword; Count: Longint; Value: Longword); > >> assembler; > >> asm > >> pushl %edi > >> movl%eax,%edi // edi <- P > >> movl%ecx,%eax // eax <- Value > >> movl%edx,%ecx // ecx <- Count > >> rep > >> stosl > >> popl%edi > >> end; > > In this case > >procedure nx_fill(P: PLongword; Count: Longint; Value: Longword); >assembler; >asm >pushl %edi >movlP,%edi // edi <- P >movlValue,%eax // eax <- Value >movlCount,%ecx // ecx <- Count >rep >stosl >popl%edi >end; > > works both as embedded and non-embedded assembler procedure because the > order of assignments is ok in both cases. Yes, but this way a program becomes a mineland. You write this, a few weeks later, for some reason, you change the line order, and you waste time to find why, suddenly, your program crashes (and yet, assuming you immediately activate the bug). -- mm http://www.ellipsa.net/ ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Default calling convention
Marcel Martin schrieb: 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. > > [example code snipped] Interestingly, D7 has the same bug. I think the best thing that could be done would be to manage so that FPC always makes use of [ebp-something] to access a parameter when the programmer makes use of the parameter name, i,e., with any calling convention the instruction "mov eax,param" should never be coded as "mov eax,reg" but always as "mov eax,[ebp-something]". See the other answer about the 'pascal' modifier. Regards, Thomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Default calling convention
Hello, In this case procedure nx_fill(P: PLongword; Count: Longint; Value: Longword); assembler; asm pushl %edi movlP,%edi // edi <- P movlValue,%eax // eax <- Value movlCount,%ecx // ecx <- Count rep stosl popl%edi end; works both as embedded and non-embedded assembler procedure because the order of assignments is ok in both cases. Yes, but this way a program becomes a mineland. You write this, a few weeks later, for some reason, you change the line order, and you waste time to find why, suddenly, your program crashes (and yet, assuming you immediately activate the bug). :( That's true. I usually add a 'pascal' procedure modifier to most (if not all) assembler routines exactly because of that. This forces parameter passing on the stack. This is a little slower, but if your hand-coded assembler proc is only faster if the parameters are passed through registers, it might be a good idea to use Pascal right away... Regards, Thomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Default calling convention
> 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): Longword; register; > var y : Longword; > asm > mov y, 1 > add eax, x > add eax, y This is unsupported, Accessing variables not in the current stackframe need additional assembler instructions. That is the reason why FPC gives an error for this: p.pp(7,17) Error: You can not reach X from that code Don't forget that you should be familair with the code generated by the compiler when programming assembler functions. If you don't know, then keep away from programming assembler. > end; > begin > x := 7; > Result := DoAdd(1); > end; > > The result should be 9 (1+7+1) but for Delphi it is only 3. > "DoAdd" is coded this way > > mov [ebp-$04], $0001 // mov y, 1 > add eax, [ebp-$4] // add eax, x > add eax, [ebp-$4] // add eax, y > > i.e., for Delphi 5.01, x and y are the same thing! > > I think the best thing that could be done would be to manage so that > FPC always makes use of [ebp-something] to access a parameter when This is your opinion for 'best', other ppl like the register calling more. > the programmer makes use of the parameter name, i,e., with any calling > convention the instruction "mov eax,param" should never be coded as > "mov eax,reg" but always as "mov eax,[ebp-something]". That is already supported: Solution 1: add a begin...end around the assembler block. The parameters will then first be loaded to the local stackframe and the assembler uses [ebp-xx]. IIRC delphi works the same. Solution 2: Changing the calling convention from register to stdcall. ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
