an easy one

So tell me mike on what page of your new book on programming delphi will that appear?

Rob;-)

Hey Rob, long time no speak from you. I hope you are doing well!

Well, my preferences lie not in writing books or articles (I just canceled to write an OpenGL article for the german computer magazin c't) but to put my knowledge into superb software (and if possible, free software) :-)

Ciao, Mike

Yes, I was just kidding about the book, jsut my way of saying that was a superbly well put comment.
Happy to be back, (not with a vengance though) just browsing about these days.

C ya

Rob;-)

wow,
looks good, mike
(also learned something,
didn't know the exact registers)

well, i will left this q one day to hear other explaination from other experts.

to the other experts,
be free, to comment the explaination in your words. if there are more than one good explaination (as now the one) i will offer seperate q(s) for this expert(s).

meikl

Hmmm... I thought using "const" would mean the same as "var", except that the Delphi compiler doesn't accept assignments/changes of this parameter?

What about this code (didn't test it):

type TBuffer = array [0..9999] of integer;

procedure HackBuffer(const buf: TBuffer);
begin
  buf[0] := 0;  // doesn't work
  PInt(@buf)^ := 0;  // works, is this change lost on exit? I'm not sure...
end;

This one should be added:

procedure P(out X : ATyp);

Which is the same as "var", but Delphi can give out more warnings, like "X may not be defined", if X is not set in P.

Even more interesting are parameters like these, I think:

procedure P(X: array of integer);
procedure P(var X: array of integer);
procedure P(const X: array of integer);

Regards, Madshi.

Hallo Madshi, ich hab' schon auf dich gewartet :-)

Well, you are right, you can actually modify the buffer this way and the value is really stored in the buffer. But this doesn't conflict with my description. It is passed as reference and the compiler prevents you to change it directly.

The "out" parameter is a good point as it is useful specifically for interfaces where the parameter itself does not pass in a value but only pass out (and any valid interface passed into an out parameter is referenced down).

To your last parameters. Look at this code straight out of my Geometry unit:

function MakeAffineVector(V: array of Single): TAffineVector; assembler;

// creates a vector from given values
// EAX contains address of V
// ECX contains address to result vector
// EDX contains highest index of V

asm
              PUSH EDI
              PUSH ESI
              MOV EDI, ECX
              MOV ESI, EAX
              MOV ECX, EDX
              INC ECX
              CMP ECX, 3
              JB  @@1
              MOV ECX, 3
@@1:          REP MOVSD                     // copy given values
              MOV ECX, 2
              SUB ECX, EDX                   // determine missing entries
              JS  @@Finish
              XOR EAX, EAX
              REP STOSD                     // set remaining fields to 0
@@Finish:     POP ESI
              POP EDI
end;


You can see here that I have not mentioned all possible kind of parameters. Here the "single" values are passed just like any ordinary array (which could well be dynamically created on the stack by the compiler).

Ciao, Mike

Hi Mike!

>> Well, you are right, you can actually modify the buffer this way and the value is really stored in the buffer. But this doesn't conflict with my description.

Oh yes, you're right of course...   :-)   I read your comment again and now it strikes my eyes...

And thank you for your array parameter description, will be useful someday...   (-:   I didn't know that before.

Regards, Madshi.

The most interesting thing for me was the fact that the result vector is also passed via a register (in the function MakeAffineVector). But this depends on the number and kind of parameters. Open arrays always need a hidden parameter telling the upper bound of the array and if the function is part of a class then the so often mentioned implicit "self" parameter also influences the parameter location. In this case all parameters slide "down" one register. Self is passed in EAX, the next parameters in EDX and ECX. All other registers should always be considered as being unitialized and reserved (on exit the same values must be there as were on enter, the direction flag is btw. cleared on enter and must be cleared on exit, otherwise the application comes in serious trouble because the compiler expects it so!). Btw: Usually Delphi holds the reference of a class usually in EDI or ESI and loads it into EAX when calling a method (but this is not guaranteed, of course) but it describes why an application often so badly crashes when registers used in a method aren't restored properly.

Ciao, Mike

well, closing the thread now.

thanks for the comments

madshi i post a separate q for you