Re: [Pgubook-readers] memory and addressing

[Bryn Reeves]

On Thu, 2005-01-13 at 13:27, Peter Parkes wrote:
> Just to start things off, Great book.Congratulations. I'll show it to my 
> teachers at school this year.
> But getting on to other things, I wanted to ask a couple of questions, both 
> related to the "maximum" program in chapter three.
> The first part relates to a question which Tim Hilton asked on this forum 
> almost a year ago. After data_items:, Tim uses the label data_end: to mark 
> the end of the list. I gather that this is simply calling the assembler to 
> allocate the next piece of memory to this label. If this is the case, it 
> would suggest that memory is used sequentially ...which has to eventually 
> come to an end, no matter how much memory you have. I assume this problem is 
> fixed by re-using memory after it has been freed up, but this must mean that 
> it is fragmented and so cannot be guaranteed to be sequential in the sense 
> that, if you use one chunk of memory, the next piece you ask for may not be 
> the following address. So, how can it be assumed that data_end will be 
> anywhere near data_items? Or am I completely off the track here?
> 

Hi Peter,
Not far off. What you say is true for dynamic (heap) allocations, i.e.
using malloc()/free(). However, the data in this case is statically
allocated when the program is compiled and is placed in the initialised
data section (.data) of the resulting binary. This memory is NEVER freed
during the process lifetime. The relevant line is:

.section .data

For this reason, you can be confident the data_end symbol will reliably
mark the end address of data_items. 

iirc, there is some discussion of this in PGU, around the chapter which
deals with the uninitialised data section (.bss) - I don't have my copy
with me so I can't get a page reference atm.

> Next, my other question relates to how I approached this problem. 
> I guess I'm just not sure about what I've done and would like your
> opinion. I feel that it's a bit of a cop-out to tell the program 
> how many data items there are but I couldn't see another simple 
> way. It seems to work but I wonder if it's not for the wrong 
> reason.

Telling the program how much data it has is a perfectly legitimate way
to solve the problem. The C language's 'for' loops are often used this
way if the limit is known. Often in practise, the value is derived
rather than being hard-coded but it's still a correct solution.

Other approaches include having a marker value to indicate end-of-list
(e.g. keep processing till you hit a -1 or a 0 or some other 'special'
value in the list - think C strings and NULL) and the symbol marker
method used above (the linux kernel uses this, for e.g. to mark
beginning/end of the system call table). 

Cheers,

Bryn.