<div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I quite like Pascal<br>
</blockquote>
<br>
Ah yes, but you're from a much older version of the matrix. :)</blockquote><div><br>And I'm a little OCD about some things - OCD and Pascal like each other.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
By convention. When I convert to machine code, after the branch I know that<br>
param1 is in register 1, param2 is in register2 etc. Depending on how many<br>
registers I've got (lots on a RISC machine) I might not need to do anything<br>
else. On the stack I'm passing by convention anyway, I know that param1 is<br>
at offset X and param 2 is at offset Y...<br>
</blockquote>
<br></div>
What I don't understand is how the compiler knows which convention to apply. Say for instance that I'm calling a function called 'format' that takes two pointers and returns a pointer (just say). The pointer values could be pushed onto the stack, or they could be passed in registers. The thing is that there will be a binary image of the 'format' function that I'm linking to, and it will be in machine code in some binary somewhere (say a .o file). The machine code of the 'format' function must either be implemented to receive its parameters either via the stack or via registers. But, in implementing the 'format' binary the compiler wouldn't have known anything about the state of the caller, so how could it know which registers, if any, were available for passing the arguments to 'format'? It seems to me like you'd always have to use the stack. I don't understand something, I'm quite sure.</blockquote>
<div><br>It depends on the language - if you have a high level one, forget it, you are doing whatever it says. In C and Pascal you modify it through compiler directives. Say in Windows, every API has a PASCAL macro telling it to pass according to the Pascal calling convention, you include the header file and it tells the compiler what to do. In Pascal I can't remember exactly what it was.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
By default you statically link which involves copying most libraries into<br>
the eventual binary. Not desirable nowadays, so if you were writing an OS<br>
you'd choose to late link at load time, possibly even later than that. You'd<br>
possibly also (nowadays) think about extra things to help you debugging even<br>
if you didn't have the source or a debug copy of the binary.<br>
</blockquote>
<br></div>
Cool.<br>
<br>
I have to say there's something about packaging up your whole app into a single executable that I really like. I.e. statically linking in your library functions. It's nice to have that level of what they call 'xcopy deployment'. As I recall Pascal (and Delphi) worked like that.</blockquote>
<div><br>Yeah, that was a little bit different from the way C links - it ripped the bits out of the unit files it needed and left the rest. It'd certainly resolve a lot of current dependency hell - in Java its a right royal PITA to the extent its almost tempting to write a JAR repackager but its somewhat frowned on.<br>
<br></div></div>