XML CO527 Anonymous Questions and Answers

This page lists the various questions and answers. To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.

We have taken the liberty of making some minor typographical corrections to some of the questions as originally put. Although most of the questions here will have been submitted anonymously, this page also serves to answer some questions of general interest to those on the course.

Question 61:

Submission reference: IN3753

When you say a 32-bit OS can support 4GB of virtual memory in a virtual machine, why can you not just bypass this by sticking two registers together like we do with the AVR's real memory (allowing a 16-bit address space made up of 2 8-bit parts)?

Answer 61:

Mainly because it's not necessary — a 32-bit OS must be running on a 32-bit machine [1], so registers would be 32-bits wide too (i.e. enough to hold a full 32-bit address). You could in theory build a 32-bit address out of two 16-bit registers, but I'm not aware of any hardware that has this (16-bit registers and a 32-bit address space). The closest I've probably seen is a 16-bit machine that can address 24-bits of memory (16 MiB) by combining registers contents. The original IBM PC (16-bit PC-AT era) had sort of this, combining two 16-bit registers to produce a 20-bit address (in base + offset style).

[1] There have been efforts at running a 32-bit OS on a lesser machine, but at that point it basically becomes emulation of the 32-bit machine. It works, but the performance hit is significant (at least an order of magnitude usually) and since you're running on a slow 8/16-bit machine, the resulting speed of the 32-bit system (emulated) makes it near unusable! Try running qemu and an OS inside itself a few times; what's at the bottom won't be quick..!

Referrers: Question 65 (2014)

Question 62:

Submission reference: IN3754

So, can I just check I'm understanding this right, in "brne 0b", the "0b" part of this means branch to "L0:" backwards? If it were "0f" it would try to branch forwards? And if it were "2b" it would try to branch to "L2:" backwards?

Answer 62:

Yes. Though I wouldn't expect you to remember details like that for exam purposes (if that was pertinent to an exam question, it'd be said in comments or text).

Keywords: assembly

Question 63:

Submission reference: IN3755

I'm a little confused on the difference between R and V bits in pages. V is set if the page is currently in a page frame, and R is set if the page is referenced. Surely if a page is currently in a page frame it is referenced, and if not it is not? It seems to me these bits both perform the same function.

Answer 63:

Not entirely. One (V) means the page is valid (resident in a page frame). The other (R) means the page has been referenced by the virtual machine. It is perfectly sensible for a page to be resident but non-referenced (see stuff on pre-paging or clustering on page-in) and in some instances necessary (the NUR replacement mechanisms periodically clear the R bits). It might even make sense to have the reverse: a page marked as referenced, but which is non-resident (the OS might just like to leave the 'R' bit there to mean "it was referenced", before it got paged out).

Keywords: memory-management

Question 64:

Submission reference: IN3756

When it comes to the exam, will we be expected to remember specifics about the AVR itself? For example, that the FLASH is 32k or that the pins are PD0 or PB5?

Answer 64:

Not that sort of detail, but I would expect you to know, for instance, what FLASH is (non-volatile memory), what it's used for (program storage) and what its characteristics are (slow write, fast read). For the I/O pins, just being aware that there are architectural things (PORTA, etc.) that can be connected to physical I/O pins is enough — that's descending into electronics a bit, and that's not something this module assesses (even though I did give a handful of lectures on basic electronic stuff, more for completeness of knowledge and understanding than anything else).

Question 65:

Submission reference: IN3757

Regarding Question 61 (2014), what I meant was: Why can't we put two 32-bit registers together to support more than 4GB of memory? Thank you for the insight given in your answer though, very interesting!

Answer 65:

I guess you can, in some sense. Although I don't think we've talked about it much (for good reason) the Intel/PC architecture has segment registers as well as 32-bit general-purpose/index registers. These are partly historical baggage, but potentially do allow more than 4GB of virtual memory to be addressed (not that the OS would support it, so you'd probably need to write your own from bare-metal/OSKit/etc.). Intel 32-bit instructions typically look something like (for a store word to memory) "mov %eax, (%edi)" but you can augment with a segment selector, e.g. "mov %eax, ES:(%edi)", and depending on how the segment/page-tables are setup (and/or LDT/GDT on Intel) this might allow you to address more than 4 GB memory. The down-side (apart from having to hack around with the OS) is that you'd also need to write a C compiler to support it, or write everything in assembler..! Luckily, all this mess has gone away with 64-bit mode :-).

Question 66:

Submission reference: IN3758

If being able to write to other programs' virtual memory is a bad thing (I assume this is the whole reason behind the protection in the first place) why is it so simple to just change the protection?

void write(DWORD wAddress, int *val, int dataLen) 
{
    unsigned long oldProt;
    VirtualProtect((LPVOID) wAddress, dataLen, PAGE_EXECUTE_READWRITE,
&oldProt);
    memcpy((LPVOID)wAddress, val, dataLen);
    VirtualProtect((LPVOID) wAddress, dataLen, oldProt);
}

or sometimes even simply:

void write(HANDLE hProc, DWORD wAddress, int val)
{
    WriteProcessMemory(hProc, (LPVOID) wAddress, Uvalue, sizeof(value),
NULL); 
}

What's the point of protection if you can just turn it off like this? Is it more of protection against accidental writing to memory?

Answer 66:

In the first code snippet, the process is only writing to its own virtual memory. I.e. the "wAddress" is in the process's own virtual memory. This is simply just changing the permissions of an existing page to read-write, copying some data (from elsewhere in the virtual memory at "val") then putting the protection back again. There might be good reasons why an application would want to do this, but it's not common. On the other hand, if a process wants to trash its own virtual machine, then let it wreck havoc!

The second example is something different, and that will potentially write stuff into a process's virtual-memory. Of course, the calling process must have sufficient permission to do that (without digging through API doc grot, one of your processes at a minimum, appropriate permission on the target page and probably some other restrictions). The docs suggest this is mainly used by debuggers, which would make sense (changing a variable's value in some process being debugged).

These are not common things to be doing in either case, however, and the fact you have to go to some lengths to do it would discourage programmers in the first place. There's no good reason why a program would want to make its entire virtual-memory space writable, for instance, unless it was trying to be malicious, or insanely badly programmed. Protection is not just against accidental code-errors (e.g. writing to an undefined pointer that happens to be in the code segment) but also against what people might try and do to a program (e.g. buffer-overflow exploiting it).

Keywords: virtual-memory

Question 67:

Submission reference: IN3759

Any chance of getting A5 - Systems programming marks back ? Or is it because of the fact the exams have been cramped together so closely even you guys don't have enough time to get back our coursework marks before we do our exam ?

Answer 67:

I'm trying to get these processed as soon as possible, but I prioritised getting A4 moderated. If you're losing sleep over not having a mark, try emailing me and I may be able to give you a provisional mark (depending on whether it went through the tests successfully or not). But the fundamental reason it's late is just pure overload, and I'm mostly babysitting this weekend :-) rather than marking :-(.

Question 68:

Submission reference: IN3760

When you say, for an application, it has some virtual memory in the real memory, some virtual memory in the swap-space, and the rest is invalid, is the invalid stuff just memory the application will never use?

So, as a really simplified example: If an application had 4GB of available virtual memory and only actually needed 1GB, this used 1GB will be split up between real memory and the swap-space, and the remaining 3GB is invalid?

Answer 68:

That's not the entire set. There may be pages that are marked as "new page", i.e. it's not allocated in RAM or swap, but the resulting page fault when an application tries to access it will cause it to be allocated (in RAM). In the example, only as much virtual memory as needed is typically allocated, and only as needed (on demand). Over simplified, you could imagine that a virtual machine starts life as a whole pile (4 GiB's worth) of "new page"s. In practice this won't happen, as the page table(s) for that would be huge. However, starting with a handful of "new page"s would be sensible. These will be allocated as needed as the virtual-memory is populated with program code, constants, libraries and whatnot. When a page-fault happens in the "invalid" region beyond the page-table, the page-table (and virtual-memory used) are simply extended/grown.

If you look at the slides on the "application environment" you can see some examples of what happens in reality. It's not trivial. For many applications, not much actual RAM (real memory) may be required anew: the pages of the VM that are things like application code can be shared between any other instances of the same program (modulo position independent code or partial relocation), and such pages are mapped on top of files in the file-system (memory mapping, or mapped file-system).

Keywords: virtual-memory