PROGRAMMING ASSIGNMENT #1

Reading virtual /proc files

CS 480/580 100 points Spring 2017

Due Tue. Feb. 14 at 11:59 PM.

Early/late points and final deadline as in syllabus.

Topics covered:
Virtual /proc files
OS interface: review of parm handling
Compiler interface: review of makefiles and header guards
Review of basic C++ I/O and record endings
Review of basic object and pointer handling
Review of C++ string class and STL vector class

Specifications:
Answer the questions below about the machine you are running on (turing/hopper) by writing a
program that reads the virtual files /proc/cpuinfo and /proc/uptime .
1. Check to see if a parameter has been supplied when your program was called, e.g.:
./hw1.exe myfile.txt
If so, assume it is a filename and use it instead of /proc/cpuinfo . If you cant open the file, for
example because it doesnt exist, print a meaningful error message and quit.
2. Different versions of the operating system may have slightly different versions of the cpuinfo
file. You can assume that the item names will be spelled consistently in different versions of the file
for turing/hopper, so you can use any sample file to obtain the item names. If any of the items you
need is missing, print an appropriate message for that question. Similarly, if any of the items you
need is improperly formatted, e.g., no colon or no numeric value, print an appropriate message for
that question.
You can not assume anything about line formatting except for the order of the elements: item
name, colon, value. For example, you can not assume that there will be exactly one space after a
colon, that there will be no extra spaces at the beginning or end of a line, or that any particular
combination of spaces and tabs will be used. Similarly, you can not assume that the number of
digits in a numeric field will always be the same.
3. Processor numbers need not be contiguous, so you need to count the number of distinct
processors. (The majority of the input fields repeat for each processor.)
To get the number of physical CPUs, you must keep track of the number of distinct physical CPU
ids. If there are no physical CPU ids, then the number is 1. CPU ids are not necessarily sequential.
For each physical CPU, look at the cpu cores field to get the number of cores for that physical
CPU. Again, if that field does not exist, the number is 1, since that is a single-core machine. Add
them up to get the total number of processors. Equivalently, you can count the number of distinct
processors. You should get the same answer either way.
When a physical CPU has more than one core, those cores share the L2 cache.

1
4. For each item in parts A-D, express each output in a numbered complete sentence, e.g.:
B: Questions about the configuration:
1. The machine has __ processors.
2. The machine has __ physical CPUs. ( if there is only one: 1 physical CPU. )
...
5. Here are some rules you need to follow for full credit. There will be a 10 point penalty for each
rule violated.
a) Use the C++ string class to represent strings. Do not use character arrays.
b) Do not use loops or character arrays to process strings for any of the questions below. Use
member functions of the string class. You can use a loop to read the file and to count the
number of processors.
c) You may only read each file once and you do not know which order the keywords will come in,
so you need to read the file, save the fields you need, and then format your output.
d) Define a Processor class and use the data for each processor to build a Processor object. Use a
vector of pointers to keep track of your processors (not an array or vector of objects directly).
e) Store the header and body for each class in separate and appropriately named files, e.g.,
Processor.h and Processor.cpp .
f) Define at least two functions, one to test whether a physical CPU is already in a data structure
and one to determine whether a parameter is included in a longer string, and to return the value if
it is. You are welcome to define further functions or classes.
g) Use header guards.
h) You must follow the style and documentation rules given below.
i) You must follow the submission instructions given below.
j) You may not use other inputs than given in the specifications. For example, your program may
not ask a question that the user has to answer.

A: Questions about the cpuinfo file

1. What is the name of the file you are reading? (It will be /proc/cpuinfo or the file
listed in the parm.)
2. How many records are there in that file?
3. How many characters are in that file?
4. Which system utility or utilities did you use to verify that your answers to questions 2 and 3
are correct?

B: Questions about the configuration

1. How many processors (total cores) does the machine have?
2. How many physical CPUs?
3. What are the physical ids? (List them with spaces or commas between them, or none if
no physical ids are listed.)
4. Are there any processors that share L2 cache?

C. Questions about the first processor in the file

1. What is its physical address size?
2. What is its virtual address size?
3. What is the ratio of virtual address size to physical address size? (You can calculate that as
2
 2^(virtual bits - physical bits.)
4. Does it have a floating point unit?
5. How big is the level 2 cache in KB?
6. How big is the level 2 cache in bytes?

D. Questions about uptime

1. How long has it been up in seconds?
2. Express that time in days, hours, minutes and seconds. Round off to the nearest tenth of a
second (one decimal place, e.g., 7 days, 1 hour, 2 minutes, and 4.3 seconds)

Administration:
Name your main program hw1.cpp . You may use as many auxiliary files for classes and headers
as you like. Provide a makefile (with the name makefile ), that your TA can use to compile,
run and clean up after your program. The makefile should permit the following commands:
make
make clean
Your makefile should produce an executable file named hw1.exe. Note that this is not the
standard naming convention for Linux executables.
Zip up all of your source files (no object files, test files, intermediate subdirectories, or other
files). Name your zip file hw1-xxxx.zip , where xxxx is your 4-letter ID in lower case. Zip is
available on turing/hopper, or you can use one of the many free implementations available.
There will be a penalty for violating these rules, e.g., submitting extra files, adding an extra
level of subdirectory, using a different compression program, or naming your files
differently.
In particular, double-check the following before you submit:
1. You have included a makefile .
2. Your makefile works.
3. Your makefile is named makefile .
4. Your program is named hw1.cpp .
5. Your zip file is named hw1-xxxx.zip as described above.
6. Your zip file does not include any unnecessary files, including test files, object files,
executables, old versions, etc.
7. Your zip file does not include any extra levels of subdirectories.
8. Your zip file is in zip format (not .rar, etc.), regardless of which program you used to create it.
9. You have compiled and tested your program on turing/hopper, regardless of where you
developed it.
Text in the Blackboard comment fields will not be seen by our grading protocol and will be
ignored. Feel free to put comments at the top of your program.
Submit the zipped file on Blackboard. We will compile and run them on turing/hopper. You will
lose points if your program does not compile and run on turing/hopper, whether the error is due
to non-standard code or to not following the submission rules.

3
Coding style:
You must follow the rules for CSCI 480 on the course web page. There is a pointer on
Blackboard, and they are also accessible directly at:
http://www.cs.niu.edu/~freedman/480/480-code01.html .

Testing:
Test your program on turing, on hopper and using a command line parameter. Try each of the
provided test files. (For the sake of simplicity, even when you use a command line parameter, the
answers to part D will come from the live system.)
Before you test, build your program using your makefile in an empty directory.

Grading:
Your program must run on any legal input. Some extra test files have been provided in the course
directory on turing/hopper at
~t90rkf1/d480/dhw1-cpuinfo . Your program must run on all legal cases as specified
above; i.e., we do not guarantee that the provided test files will include every possible error
condition.
For full credit, your program must work correctly and follow the specs and documentation
standards above, including naming conventions and file organization.
Grading rubric:
10 points - proper parm handling
10 points - can open and run every provided test file
80 points - 5 points for answer to each question (there are 16 of them)
In addition, there will be a 10 point penalty for violating any of the rules above (10 points per
rule).
If you realize you have made a mistake, you can resubmit your program once before the deadline.
In that case the submission time will be the later one, and your TA will ignore the earlier
submission.

Programming hints:
Here are some functions that you might find useful:
File class: getline
String class: find, rfind , substr , length , c_str , constant npos
Misc. functions: atoi, atof
(may require the C standard library for C++, i.e., <cstdlib> )
isstringstream
(Both of the above are ways to convert a string to a number.)
You are welcome to use any functions of the string class or other C++ classes that you prefer.
The web page at http://www.cs.niu.edu/~freedman/480 contains some useful reference
materials for C++ classes.
Sample code is available in the course directory on turing/hopper.

4
Software:
There are many sources of information on zip, including the man entry on turing/hopper.
There are also many sources of information about makefiles and make. Several pointers are
available on the course web page. Information about header guards is also available from the
course web page.