(Mar 19, 10:00 AM)Question: One of the FAQ answers says we need to support thousands of threads, but the assignment says that each program must be able to have its own private segment(s), and we're not required to support more than a few hundred segments. What am I missing?

Answer: You're missing the distinction between "program" and "thread". An instance of a program (e.g. emacs) might involve a few private segments and a potentially large number of threads. The threads in any given program instance should all enjoy the same set of segment access modes. You're not required to enforce isolation between threads within the same program instance (though you should be able to enforce isolation between different instances of the same program). If you have a compelling reason to support some other relative quantities of threads, programs, and segments, that's also OK.

(Mar 18, 11:30 PM)Question: I'm still confused about how much detail I need to give about the O/S kernel algorithms.

Answer: Your primary job is to design the MMU and its data structures. For each of the requirements in the assignment that deals with the O/S, you just need to give enough detail to show that it should be possible for the O/S to implement the required feature using your MMU.

(Mar 18, 11:30 PM)Question: Do I have to adhere to the design details given in the Getting Started section of the assignment. For example, am I required to use 8-bit segment numbers?

Answer: You are not required to adhere to any of the details in the Getting Started section. For example, if you decide you need 9-bit segment numbers and 25-bit segment offsets (for 34 bits total), that's fine. Your changes should make sense, and you should justify them.

(Mar 18, 11:30 PM)Question: The MMU sometimes has to translate more than one address per executed instruction -- for example, for an LD it has to translate the LD's instruction address as well as the address of the data to be loaded. I'm worried this will take more than one cycle. Does my MMU have to support multiple simultaneous translations?

Answer: No. Assume the Beta just uses the MMU twice, in sequence, for each of the two addresses.

(Mar 18, 11:30 PM)Question: My MMU loads multiple table entries from memory in order to translate each address. I'm worried this will be slow -- is that a problem?

Answer: It's fine if your MMU has to load a few table entries from physical memory in order to translate an address. It would not be so good if your MMU had to make 100s of memory references to translate a single address.

(Mar 18, 11:30 PM)Question: The assignment says we have to explain how system calls work. I'm not sure what that means.

Answer: You should discuss this in a way similar to that of the description on page 2-27 of the course notes.

(Mar 17, 8:00 PM)Question: Is it OK if we place a limit on the total number of threads that are possible?

Answer: It's pretty common to have computers with hundreds of programs running, and you'd like each program to be able to contain dozens of threads. Thus, while it's OK to impose a limit on the number of threads, that limit should be in the thousands. But you can probably come up with a design that avoids requiring the MMU to know about every thread. You might provide a basic set of facilities in the MMU hardware, and let the O/S implement an open-ended number of threads on top of that.

(Mar 17, 8:00 PM)Question: The assignment says "A program should be able to indicate whether other programs are allowed to read, write, or execute its segments." Does this mean that a program should be able to specify a different permissible access mode for each other program? Or is it OK if a program just chooses one access mode applicable to all other programs?

Answer: It would be better to allow precise control over sharing. For example, suppose thread X is using a particular shared segment just to send data to thread Y, perhaps in a style similar to a UNIX pipe. It would be nice to prevent bugs in unrelated thread Z from overwriting that shared segment.

(Mar 17, 8:00 PM)Question: The assignment does not actually mention that different segments should be able to have different sizes (though the example SegmentDescriptor does have a length field). Do we need to support this?

Answer: Yes.

(Mar 17, 8:00 PM)Question: The assignment mentions a "single address space" shared by all programs. Does this mean, for example, that when emacs refers to segment number 87, it is referring to the same segment that xterm sees when xterm refers to segment 87?

Answer: Yes.

(Mar 13, 11:00 PM)Question: What is the "O/S" mentioned at the end of Section III?

Answer: O/S is a conventional shorthand for "Operating System". For some reason lost in antiquity, it is usually written with a slash in the middle.

(Mar 13, 11:00 PM)Question: Who/what creates segment table entries?

Answer: The model is that the O/S kernel will modify the MMU's tables or registers when the O/S wants to create a segment, delete a segment, or modify the access permissions of a segment. Programs will use system calls to ask the O/S to do this on their behalf. You are responsible for creating an MMU design that allows the O/S full control over segments what are accessible. For example, the O/S might decide that thread X is allowed to read and write segment 107, but that thread Y is only allowed to read segment 107. When the O/S performs a context switch from X to Y, the O/S should be able to arrange that 107 not be writeable.

(Mar 13, 11:00 PM)Question: The assignment mentions that two instances of the same program should be able to share the same executable code segment. When the shell starts (for example) /usr/bin/emacs, how does it decide whether it needs to create a new segment for emacs's executable code, as opposed to re-using a code segment from an emacs that's already running?

Answer: The O/S is responsible for keeping track of this. The O/S could provide a map(file, access-mode) system call. This call would ask the O/S to return a segment number that refers to a segment containing the contents of the file, and to allow the current program to access the segment in the specified mode. The idea is that if that file (e.g. /usr/bin/emacs) is already in a segment, the O/S will return the existing segment number; otherwise the O/S will allocate a new segment number and physical memory, and copy the file from the disk into the new segment. The O/S might deny the request if, for example, the UNIX file system permission bits prohibit the program from accessing the file in the specified mode.

(Mar 13, 11:00 PM)Question: The assignment mentions that a thread must be able to have its own private segments. How is it supposed to allocate them?

Answer: The O/S will provide a system call that allocates a new private segment. For example, the call might look like allocate(size, access-mode, shared-flag). This system call would allocate a new segment number, allocate size bytes of physical memory, and arrange with the MMU to allow the calling program to access the segment; then it would return the new segment number to the calling program. The shared-flag argument would control whether other threads were allowed to access the segment.

(Mar 13, 11:00 PM)Question: How much of the design should focus on how the kernel works? How much on how the MMU works? Answer: Your design should focus mainly on how the MMU works. You need to outline how the kernel uses your MMU facilities to implement the features required by the assignment. You don't have to describe any other aspects of the kernel.

(Mar 13, 12:00 noon) Question: In the design project 1 description it says that we won't be able to use the supervisor bit. Does this mean that we cannot have a notion of code running in "kernel mode" vs. code running in "user mode"?

Answer: You are allowed to modify the Beta in whatever ways you feel are best suited to the requirements stated in the assignment. For example, if you decide that you need a notion of code running in kernel vs user mode, you're allowed to put that in your design. Of course, you should specify how the CPU and/or MMU decide what mode to operate in. The original Beta decided this by looking at the supervisor bit, which was defined as the high-order bit of the program counter; you can adopt that idea if you can make it work, but it's likely there are more elegant solutions.