0
$\begingroup$

I'm in an OS class now. I've been wrestling this problem for a while and can't convince myself of a solution. My professor is very busy and hasn't made time to help. Also, this question is from an example exam, not something I would be graded on.

In this question, we're given a virtual address to translate: 0xFEC. We're also told to use segmentation in accordance with the table and a 14-bit address. Looking at our address in binary, we have 0000 1111 1110 1100. We'll disregard the two most significant bits, as instructed giving 00 1111 1110 1100.

Taking the two leading bits as our segment tells us to use the base for the Code section, which is given to be 12. Then, we go to decimal and add.

dec(00 1111 1110 1100) + dec(12K) = ...

7018 + 12,288 = 19306

The thing that tells me this is incorrect, is that the number 7018 which is approximately 7K is much greater than 3.6K (the given size of the code section). :/

I'm really lost here, and I haven't found any examples of people moving addresses with segmentation or with decimal end numbers.

I think I'm wrong when interpreting the addition, but I'm not sure how.

enter image description here

$\endgroup$
  • $\begingroup$ You may want to recheck your book on hexadecimal. 0xFEC clearly fits in 12 bits (since each hex digit is 4 bits) so it cannot be more than 4095. $\endgroup$ – MSalters Mar 18 at 10:36
  • $\begingroup$ @MSalters I'm confused then. I understand the 0xFEC contains 12 bits, but as these addresses are segmented with two bits indicating the segment, shouldn't we be looking for two leading bits? The question states addresses are 14 bit. $\endgroup$ – big-zero Mar 18 at 10:39
  • $\begingroup$ I'm trying to show why your dec(00 1111 1110 1100)=7018 is obviously wrong. $\endgroup$ – MSalters Mar 18 at 10:48
  • $\begingroup$ Oh! You're correct, but if I convert correctly, I get 4076. This is still higher than the supposed size of the Code section. :/ I appreciate you pointing that out, though! $\endgroup$ – big-zero Mar 18 at 11:02
1
$\begingroup$

I suspect that the problem may lie in your title.

There's a whole lot of real-world variety imaginable in memory architectures, and your book will describe them in the abstract. Importantly, in the real world the particular combination of segmentation and virtual addresses is not used. Intel's x86 architecture supports it, but most Operating Systems don't bother and just set all segments to be identical.

This question therefore does assume something non-standard, which means there needs to be some specification of how the hypothetical mechanism works. Importantly, does segmentation happen before or after virtual address translation?

In the model where segmentation checks happen first, 0x0FEC is not in the code segment. The top bits suggest it is, but the code segment is only 3686 bytes, not 4077 bytes.

Since the virtual address does not lie in any segment, using it would fail even before a virtual-to-physical translation happens.

Now in the model where segment bounds are checked later, you'd first create a physical address, which would use the 12K base address and the 4076 offset. This produces an physical address of almost 16K, past the 15.6K end of the code segment.

$\endgroup$
  • $\begingroup$ Thank you so much. So we're saying that either possibility leads to an address which is NOT in bounds? $\endgroup$ – big-zero Mar 18 at 11:33
  • $\begingroup$ @big-zero: Conceptually, yes, but in hardware implementations the first case will not even generate a physical address. These details may appear trivial, but the recent Spectre flaw in Intel CPU's show that such details matter. Intel CPU's incorrectly do virtual-to-physical translations that are visible in the CPU cache, which affects timing. $\endgroup$ – MSalters Mar 18 at 11:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.