[ProgClub list] Memory management in C

Asher Glynn asher.glynn at gmail.com
Sun Oct 2 05:09:07 AEDT 2011

> I quite like Pascal
> Ah yes, but you're from a much older version of the matrix. :)

And I'm a little OCD about some things - OCD and Pascal like each other.

>  By convention. When I convert to machine code, after the branch I know
>> that
>> param1 is in register 1, param2 is in register2 etc. Depending on how many
>> registers I've got (lots on a RISC machine) I might not need to do
>> anything
>> else. On the stack I'm passing by convention anyway, I know that param1 is
>> at offset X and param 2 is at offset Y...
> 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.

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

>  By default you statically link which involves copying most libraries into
>> the eventual binary. Not desirable nowadays, so if you were writing an OS
>> you'd choose to late link at load time, possibly even later than that.
>> You'd
>> possibly also (nowadays) think about extra things to help you debugging
>> even
>> if you didn't have the source or a debug copy of the binary.
> Cool.
> 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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.progclub.org/pipermail/list/attachments/20111001/e5a84e27/attachment.html>

More information about the list mailing list