[ProgClub list] Memory management in C
asher.glynn at gmail.com
Sun Oct 2 04:39:00 AEDT 2011
> ... actually, MS wrote an experimental OS that was completely in .Net
>> by the few people I know who actually saw it, was really, really good. But
>> wouldn't have supported the old Win API so wasn't going anywhere.
> Isn't that a shame?
> I'm surprised Google hasn't released a desktop operating system yet.
> I wonder if they just threw the /unsafe switch and did their own memory
> management. You don't actually need to use the GC in .NET -- did you know?
I believe that it was all "managed"
> IBM writes a lot of their mainframe operating systems in PL/X which is a
>> variant on PL/I. OS/400 I believe has a bit in some OO variant of RPG.
> Are either of those GC'ed?
I'd personally be inclined to have a stab with Oberon (since they've
> developed an OS in it anyway), its Pascal derivative and supports some very
> nice features.
Pascal is such an ugly language, don't you think?
I quite like Pascal
And interestingly you probably wouldn't use many of C's defaults - I think
> its already been commented that its method of passing parameters is
> rather inefficient
What's wrong with how it passes parameters? How could you do better?
> The method of passing parameters is basically to copy their values onto the
> stack, isn't it? (Is this ever averted by leaving them in registers? I
> understand that .NET can pass values in registers, but it probably has
> enough information to be able to do that, I'm not sure how a called function
> would know to check for a parameter in a register if you were calling a
> library function from C..?)
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...
> as is its string representations, and its memory model
>> is quite dangerous.
> I vaguely remember hearing a remark once that having the stack grow down
> and the heap grow up (i.e. each toward the other) has been the source of
> most computer security related issues over the past few decades.
> I'm still not sure how that works when you have multiple stacks. Because
> it's a pretty primitive view of an application to say that it has one stack
> that grows down and one heap that grows up. Often there will be multiple
> stacks, although I'm not sure where they all get located. My understanding
> of memory models is a little trite.
> You wouldn't use its default linking method either. This
>> is kind of true for a lot of OSes that are "written in C" at any rate.
> What's wrong with the linking model? (I don't remember anything about 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the list