R. Clayton (rclayton@monmouth.edu)
(no date)
Where does user primary store? Is it inside some object? Or Is it on some
disk?
It doesn't matter where the primary store resides or what it is; it only
matters that you access it via the fetch() and store() member functions defined
in memory.h (or the associated mem_store() and mem_fetch() macros defined in
mass.h, which you are not obligated to use).
This, by the way, is proper object-oriented programming: you don't care what or
where something is, you only care about the interface.
Or Should I just read from the disk and allocate 1024 x 32 bytes using
malloc() (x 32 because its an int) and treat that as a primary store?
You don't have to create primary store; it's part of the simulator.
The "word * primary_store" in memory.h, is it any related to the above? Then
this primary store is what is discussed in system.h
It is, but also note it's in the private part of the memory class, and so it's
none of your business. (This, by the way, is why c++ is not a proper
object-oriented language. All the private declarations should be hidden away
from the user of the interface as defined by the public declarations.)
The above declarations about sys_base, usr_base, dev_base must be on
memory,.h rather than system.h
I'm not sure why you say that; sys_, usr_, and dev_base are just constants, and
can be defined anywhere.
If the system.h spaces are related to primary_store in memory.h, then this is
the one my scheduler or process manager must load onto?
Sorry, I'm not sure what "this" refers to.
If it does not violate assignment standards, Can I see the .C files that
correspond to memory.C (header: memory.h)? Also mass.C, system.C and utils.C
For my own understanding of the project.
It doesn't violate the standards, but I don't think it's a good idea. Seeing
the simulator source will tell you nothing more about doing the assignments
that the code you already have.
My interpretation of your questions leads me to believe you're paying too much
attention to parts of the code you should be ingoring, and the way to solve
that problem is not to give you more code you should also be ignoring.
This archive was generated by hypermail 2.0b3 on Fri Dec 03 2004 - 12:00:06 EST