forked from uva-cs/pdr
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
208 lines (208 loc) · 29.7 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="generator" content="pandoc">
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
<title>PDR: Laboratory 8: x86 Assembly Language, part 1 (64 bit)</title>
<style type="text/css">code{white-space: pre;}</style>
<link rel="stylesheet" href="../../markdown.css">
<!--[if lt IE 9]>
<script src="//cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv-printshiv.min.js"></script>
<![endif]-->
</head>
<body>
<h1 id="pdr-laboratory-8-x86-assembly-language-part-1-64-bit">PDR: Laboratory 8: x86 Assembly Language, part 1 (64 bit)</h1>
<p><a href="../index.html">Go up to the Labs table of contents page</a></p>
<h3 id="objective">Objective</h3>
<p>This lab is one of two labs meant to familiarize you with the process of writing, assembling, and linking assembly language code. The purposes of the in-lab and post-lab activities are to investigate how various C++ language features are implemented at the assembly level.</p>
<p>There are both <a href="../lab08-32bit/index.html">32 bit</a> (<a href="../lab08-32bit/index.md">md</a>) and <a href="../lab08-64bit/index.html">64 bit</a> (<a href="../lab08-64bit/index.md">md</a>) versions of this lab. This is the <strong><em>64 bit version</em></strong>.</p>
<h3 id="background">Background</h3>
<p>The Intel x86 assembly language is currently one of the most popular assembly languages and runs on many architectures from the x86 line through the Pentium 4. It is a <a href="http://en.wikipedia.org/wiki/Complex_instruction_set_computing">CISC</a> instruction set that has been extended multiple times (e.g. <a href="http://en.wikipedia.org/wiki/MMX_%28instruction_set%29">MMX</a>) into a larger instruction set. In 2004 it was extended to allow for a 64 bit memory space.</p>
<h3 id="readings">Reading(s)</h3>
<ol type="1">
<li>Read the <a href="../../slides/08-assembly-64bit.html">slides on 64 bit x86</a></li>
<li>The x86 book chapters on <a href="../../book/x86-64bit-asm-chapter.pdf">x86</a> and the <a href="../../book/x86-64bit-ccc-chapter.pdf">C calling convention</a></li>
<li>An optional online reading is <a href="https://www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf">x86-64 Machine-Level Programming</a> from CMU, although they use the other assembly language format</li>
</ol>
<h2 id="procedure">Procedure</h2>
<h3 id="pre-lab">Pre-lab</h3>
<ol type="1">
<li>You should be familiar with the readings described above. They detail the x86 material that this lab requires.</li>
<li>Complete the tutorial, which consists of reading the x86 book chapters on <a href="../../book/x86-64bit-asm-chapter.pdf">x86</a> and the <a href="../../book/x86-64bit-ccc-chapter.pdf">C calling convention</a>.</li>
<li>Read through the section, below, on compiling C++ with assembly on different architectures, as well as the vecsum program.</li>
<li>There are different program formats for different architectures, and this pre-lab <strong>must</strong> be submitted in the submission format for this lab (see the next section, below). If you do not submit it in the required format (64-bit Linux), you will not receive credit for the lab, as it will not compile.</li>
<li>Follow the pre-lab instructions in this document. They require you to write a program in x86 assembly called mathlib.s. To see other examples of nasm code, you should look at the vecsum.s program, as well as the code in the nasm tutorial.</li>
<li>Make sure your mathfun.cpp takes in only the input described in the pre-lab section! Input is to be provided via standard input (i.e., <code>cin</code>), not through command-line parameters.</li>
<li>Your code must compile with <code>make</code>!
<ul>
<li>And does your code work on a 64-bit Linux machine? It will need to in order to receive credit.</li>
<li>You may need to SSH into a lab machine to run your code. To do so, follow the instructions in the SSH/SCP tutorial.</li>
</ul></li>
<li>Files to download <a href="vecsum.s.html">vecsum.s</a> (<a href="vecsum.s">src</a>), <a href="main.cpp.html">main.cpp</a> (<a href="main.cpp">src</a>), <a href="Makefile.html">Makefile</a> (<a href="Makefile">src</a>)</li>
<li>Files to submit mathlib.s, mathfun.cpp, Makefile</li>
</ol>
<h3 id="in-lab">In-lab</h3>
<ol type="1">
<li>Make sure you have completed the reading on the C calling convention.</li>
<li>Follow the in-lab instructions in this document. Your assignment is to write a function in x86 assembly called mergeSort. The merge function is provided in mergeSort.s.</li>
<li>Your code must compile with <code>make</code>. It must work on a 64-bit Linux machine.</li>
<li>When finished with the in-lab, begin working on the post-lab report.</li>
<li>Files to download: <a href="mergeSort.s.html">mergeSort.s</a> (<a href="mergeSort.s">src</a>), <a href="testMergeSort.cpp.html">testMergeSort.cpp</a> (<a href="testMergeSort.cpp">src</a>)</li>
<li>Files to submit: mergeSort.s, testMergeSort.cpp, Makefile</li>
</ol>
<h3 id="post-lab">Post-lab</h3>
<ol type="1">
<li>Write a report that explains the topics listed in the post-lab section below. Be sure to address all the issues in each topic!</li>
<li>Files to download: none (other than the results of your pre-lab and in-lab)</li>
<li>Files to submit: postlab8.pdf</li>
</ol>
<hr />
<h2 id="platform-architectures">Platform Architectures</h2>
<h3 id="different-architectures">Different Architectures</h3>
<p>There are two different platforms that students are potentially developing their code on:</p>
<ol type="1">
<li>64-bit Linux (what is on the VirtualBox image and what the submission server is running, as well as what is installed on the computers in Rice 340 and Olsson 001)</li>
<li>64-bit Mac OS X</li>
</ol>
<p><strong>Your code must compile and run on the submission server, which is a 64-bit Linux machine!</strong></p>
<p>There are three changes that will have to be made to compile your program (and thus to the Makefile) depending on your own development platform:</p>
<ul>
<li>You will have to determine whether to name your function <code>vecsum</code> instead of <code>_vecsum</code> (note the lack of underscore in the former) in vecsum.s (this file is described more below). In the final linking step, if you get a message such as, <code>main.cpp:(.text+0x12): undefined reference to 'vecsum'</code>, then you should change the name of the function.</li>
<li>Some systems will have to supply a command-line parameter to clang++; this can be put on the <code>CXX</code> or <code>CXXFLAGS</code> macro(s) line in your Makefile</li>
<li>All systems will have a specific nasm file format option (via <code>-f</code>) that will need to be specified.</li>
</ul>
<p>The first bullet point highlights a compatibility problem between Linux and Mac OS X. When calling a subroutine, which in C++ would be called <code>foo()</code>, there are two standards as to how to name the assembly routine: you can name it either <code>_foo</code> (adding an underscore is added before the name), or name it just <code>foo</code> (with no underscore). Unfortunately, Linux uses a different standard than Mac OS X, so we have to make (minor) code modifications in order to compile the code on the other system: in Mac OS X, the vecsum.s file should have the subroutine be called <code>_vecsum</code>, and under Linux, it should be called <code>vecsum</code> (this is twice, on lines 11 and 15).</p>
<p>In an effort to make sure all the files submitted conform to one standard or the other, <strong>all assembly and C/C++ code must be submitted in Linux form</strong> (i.e. will be called <code>foo</code> and not <code>_foo</code>). Note that in many programs, such as the vecsum.s that we provided you, you have to change the name in TWO places: on the <code>global</code> line (line 11 of vecsum.s) and on the label line (line 15 of vecsum.s). <strong>If your code does not compile on the submission system, you will receive zero credit!</strong></p>
<p>Also note that your code must compile with <code>make</code>. We provide a sample Makefile that will compile vecsum, so you can just modify this Makefile to compile your pre-lab program. <strong>Please note that you should NOT specify a <code>-o</code> flag to clang++ (not even <code>-o a</code>)</strong>, as we want it to be named the default (a.out). This allows easy porting between the two operating systems.</p>
<p>If you plan to develop this lab in Mac OS X, we suggest that you develop it normally (putting in the <code>_</code> before the subroutine name). Then, once you have verified everything works, remove the underscores from <strong>all</strong> the relevant lines, and test it out on a 64-bit Linux machine, such as the VirtualBox image, before submitting it.</p>
<h3 id="platform-specifics">Platform Specifics</h3>
<p>Each of these different platforms has different compilation lines to allow it to compile. Some of them require changing the assembly files as well. You only need to read the line(s) pertaining to the platform(s) you are developing on.</p>
<p><strong>64-bit Linux:</strong> You have to explicitly tell clang++ to compile in 64-bit mode by passing in the <code>-m64</code> parameter. All assembly subroutine names must <strong>NOT</strong> have a leading underscore (i.e. they should be <code>vecsum</code> and not <code>_vecsum</code>). nasm is invoked with the <code>-f elf64</code> option. If you are using your own Linux installation (not the course VirtualBox image), and you run into compilation issues, try installing the g++-multilib package - we realize that we are not using the g++ compiler, but this installs the correct library in the correct place (if this differs with your version of Linux, then please let us know!).</p>
<p><strong>64-bit Mac OS X:</strong> To run the code, will need to rename all the assembly function names with a leading underscore (i.e. <code>_vecsum</code> not <code>vecsum</code>). You will also have to use the <code>-f macho64</code> format for nasm, and tell clang++ to generate the correct architecture code. In the provided Makefile, change the <code>ASFLAGS</code> macro line to <code>-f macho64</code> (instead of the default <code>-f elf64</code>). You will probably want to remove the <code>-m64</code> flag on the <code>CXX</code> macro line, but be sure to put that back in before you resubmit. Note that you <strong>MUST</strong> change all of this back in order for it to compile via the submission system! Also note that some versions of Mac OS X do not support the format of assembly that we use in this course, which means that you will be stuck reading the assembly in the other format we discussed in class.</p>
<p><strong><em>WARNING FOR MAC OS X:</em></strong> As mentioned in the class introduction (specifically, <a href="../../uva/course-introduction.html#/unixinfo">here</a>), some parts of this lab may <strong>NOT</strong> be compatible with Mac OS X. So if things are not working, or the directions above are running into issues, consider reverting to the VirtualBox image.</p>
<p>Below is a table summarizing the changes</p>
<table style="width:97%;">
<colgroup>
<col style="width: 13%" />
<col style="width: 8%" />
<col style="width: 8%" />
<col style="width: 8%" />
<col style="width: 58%" />
</colgroup>
<thead>
<tr class="header">
<th>Platform</th>
<th>nasm flag</th>
<th>x86 subroutine name</th>
<th>clang++ flags</th>
<th>Notes</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td>64-bit Linux</td>
<td>-f elf64</td>
<td>vecsum</td>
<td>-m64</td>
<td>This is what our submission server is running, <strong>and what your code must work on.</strong> If you have it on your computer, you must install a few packages as well - see above</td>
</tr>
<tr class="even">
<td>64 bit Mac OS X</td>
<td>-f macho64</td>
<td>_vecsum</td>
<td>???</td>
<td>We are unsure about the clang++ flags necessary. May not be able to print the assembly in the format discussed in class.</td>
</tr>
</tbody>
</table>
<p><strong>IMPORANT:</strong> Just to repeat, when you submit your code, it <strong>MUST</strong> be in 64-bit Linux format.</p>
<hr />
<h2 id="pre-lab-1">Pre-lab</h2>
<h3 id="compiling-assembly-with-c">Compiling Assembly With C++</h3>
<p>For this part, you will need to download three files: <a href="vecsum.s.html">vecsum.s</a> (<a href="vecsum.s">src</a>), <a href="main.cpp.html">main.cpp</a> (<a href="main.cpp">src</a>), and <a href="Makefile.html">Makefile</a> (<a href="Makefile">src</a>).</p>
<p>To compile a program written partly in x86 assembly and partly in C++, we have to build the program in parts. We build the C++ file as we have in the past:</p>
<pre><code>clang++ -m64 -Wall -g -c -o main.o main.cpp
</code></pre>
<p>Note that we used the -c flag, which tells the compiler to compile but not link the program. Linking it will create the final executable -- but as there is not a <code>vecsum()</code> function defined (yet), the compiler will report an error stating that it does not know what the vecsum() function is. The <code>-o main.o</code> part tells clang++ to put the compilation output into the file named main.o. Note that the <code>-o</code> flag wasn't really necessary here (as clang++ will use main.o by default when compiling main.cpp), but we wanted to include it, as we are going to use it below. We include the <code>-m64</code> flag to force it to be a 64-bit file. We also added a few more flags (<code>-Wall -g</code>) to print all warnings and compile debugging symbols into the program.</p>
<p>Next, we need to compile the assembly file. To do this, we enter the following:</p>
<pre><code>nasm -f elf64 -g -o vecsum.o vecsum.s</code></pre>
<p>This invokes nasm, which is the assembler that we are using for this course. We'll get to the <code>-f elf64</code> part in a moment. The <code>-o vecsum.o</code> option is the same as with clang++ -- it is telling the assembler to put the output into a file named vecsum.o. If you do not specify a filename with the <code>-o</code> flag, it will default to vecsum.obj, NOT vecsum.o -- this is why we are using the <code>-o</code> flag. We also tell it to include debugging symbols via <code>-g</code>. The assembly file name is specified by the <code>vecsum.s</code> at the end of the command line.</p>
<p>The new flag here is the <code>-f elf64</code>. This tells the assembler the output format for the final executable. Operating systems can typically execute a number of different formats. As we are running under 64 bit Linux, we specify the elf64 format. Mac OS X uses <code>-f macho64</code> -- see the above section for more details.</p>
<p>Finally, we have to link the two files into the final executable. We do this as before:</p>
<pre><code>clang++ -m64 -Wall -g vecsum.o main.o</code></pre>
<p>This tells clang++ to link both of the .o files created above into an executable, which it called <code>a.out</code>. Note that there isn't any compiling done at this stage (the compilation was done before) -- this just links the two object files into the final executable. Also note that for our submitted Makefiles, we will NOT have the <code>-o</code> flag present.</p>
<h3 id="tutorial">Tutorial</h3>
<p>Complete the C++/assembly tutorial, which consists of reading the book chapters on <a href="../../book/x86-64bit-asm-chapter.pdf">x86-64</a> and the <a href="../../book/x86-64bit-ccc-chapter.pdf">calling convention</a>. Another good reading is <a href="https://www.cs.cmu.edu/~fp/courses/15213-s07/misc/asm64-handout.pdf">x86-64 Machine-Level Programming</a> from CMU. (The CMU reading uses the other assembly language format.)</p>
<h3 id="vecsum">Vecsum</h3>
<p>Examine the vecsum subroutine in <a href="vecsum.s.html">vecsum.s</a> (<a href="vecsum.s">src</a>). Use the slides and readings to help understand what is happening in vecsum.s. Make sure you understand the prologue and epilogue implementation, as well as the instructions used in the subroutine.</p>
<p>Compile and run the vecsum program:</p>
<ul>
<li>Use the tutorial as a guide, but see the instructions above.</li>
<li>If you forget the lldb commands described below, see the <a href="../../docs/lldb_summary.html">LLDB command summary</a>, which has a summary of all of these commands.</li>
<li>You can find the assembly and C++ source code in the repository (<a href="vecsum.s.html">vecsum.s</a> (<a href="vecsum.s">src</a>), <a href="main.cpp.html">main.cpp</a> (<a href="main.cpp">src</a>), <a href="Makefile.html">Makefile</a> (<a href="Makefile">src</a>)). For the C++ code compilation (i.e. main.cpp) and the final link, use the <code>-g</code> flag, which allows the program to work well with the lldb debugger.</li>
<li>Use the debugger to step through the assembly code, view the register contents, and view the computer's memory.</li>
<li>Set a breakpoint at the line in the main.cpp where the vecsum() function is called (probably line 38).</li>
<li>Normally, you would use the <code>step</code> function to step into the next instruction. However, since no debugging information was included with the assembler (a shortcoming of nasm), we can't use <code>step</code> -- it will just move to the next C++ instruction (the <code>cout</code>). Instead, we will use <code>stepi</code>, which will step exactly one <em>assembly instruction</em>, which is what we want.</li>
<li>To display the assembly code that is currently being executed, enter <code>disassemble</code>. This is just like <code>list</code>, but it displays the assembly code instead of the C++ code.</li>
<li>Note that this prints things in a different assembly format. To set the format to the style we are used to (and the style we are programming in with nasm), enter <code>settings set target.x86-disassembly-flavor intel</code>. Now enter <code>disassemble</code> again -- the format should look more familiar. You only have to enter that set command once (unless you exit and re-enter lldb).</li>
<li>To see the vecsum function, enter <code>disassemble --name vecsum</code>. Note that this only lists the first third (or so) of the routine -- up until the <code>start</code> label. To see the rest of the code, enter <code>disassemble --name start</code>, <code>disassemble --name done</code>, etc.</li>
<li>To show the contents of the registers, use the <code>info registers</code> command.</li>
</ul>
<h3 id="pre-lab-program-mathlib.s">Pre-lab program: mathlib.s</h3>
<p>You will need to write two routines in assembly, one that computes the product of two numbers, and one that computes the power of two numbers.</p>
<p>The first subroutine will compute the product of the two integer parameters passed in. The restrictions are that it <strong>can only use addition</strong>, and thus cannot use a multiplication operation. We will assume that both of the parameters are positive integers. It must compute this <strong>iteratively</strong>, not recursively. The resulting product is then returned to the calling routine. This subroutine should be called <code>product</code>. We will assume that values will not be provided to the subroutine that will cause an overflow, nor will negative (or zero) parameters be passed in.</p>
<p>The second subroutine will compute the power of the two integer parameters passed in. We will assume that the first parameter is the base, and the second parameter is the exponent. Again, both are integers. The restrictions on this routine are that it <strong>can only use the multiplication</strong> routine described above -- it cannot use <code>imul</code> or call any exponentiation routine. Furthermore, it must be defined <strong>recursively</strong>, not iteratively. This routine should be called <code>power</code>.</p>
<p>You can assume that the numbers passed into both routines will both be positive, so you need not consider negative numbers or zero. Furthermore, as described above, no values will be used on your program that could cause an integer overflow.</p>
<p>Both of these routines should be in a file called mathlib.s, and must use the proper C-style calling convention. You must also provide a mathfun.cpp file, which calls both of your subroutines -- see the main.cpp file provided as a template. The program should take in ONLY two integers (we'll call them <em>x</em> and <em>y</em>). It should then print out the output of calling <code>product(x,y)</code> and <code>power(x,y)</code>. Thus, if the input is 3 and 4, it would print out 12 and 81.</p>
<p>Input is to be read via standard input (i.e., <code>cin</code>), not through command-line parameters.</p>
<p>In order for routines in an assembly file to be callable from C/C++, you need to declare them with <code>global</code>, like is done in <code>vecsum.s</code>. To have multiple routines in a single assembly file (as is needed for mathlib.s), you should have multiple <code>global</code> lines, one for each subroutine that you plan on calling from your C/C++ code.</p>
<hr />
<h2 id="in-lab-1">In-lab</h2>
<p>Come to lab with a functioning version of the pre-lab, and be prepared to demonstrate that you understand how to build and run the pre-lab programs. If you are unsure about any part of the pre-lab, talk to a TA. You should be able to explain and write recursive functions in assembly for the exams in this course, so make sure that you understand how to implement the pre-lab program.</p>
<p>Before starting the in-lab, make sure you read and understand the book chapters on the C calling convention. For the in-lab, you will be implementing merge sort in x86 assembly. We have provided the helper function <code>merge</code> in mergeSort.s. Note: <code>merge</code> makes use of two caller-saved registers, r10 and r11. <strong>Remember to save and restore these registers</strong> before and after calling <code>merge</code>.</p>
<p>Download <a href="mergeSort.s.html">mergeSort.s</a> (<a href="mergeSort.s">src</a>), as well as <a href="testMergeSort.cpp.html">testMergeSort.cpp</a> (<a href="testMergeSort.cpp">src</a>), which you will use to test your code. Make sure you do not alter testMergeSort.cpp, as you must include the original file in your submission. You will need to create a Makefile for the in-lab. To do so, you can copy the pre-lab Makefile and set <code>OFILES=mergeSort.o testMergeSort.o</code>.</p>
<p>Your task for the in-lab is to implement the <code>mergeSort</code> function in mergeSort.s. This function takes in three parameters. The first parameter is a pointer to an int array. The second parameter is an integer corresponding to the left index in the array. The third parameter is an integer corresponding to the right index in the array. The return type of this function is void, and it modifies the original array. You may assume the size of the array is nonzero. When testing your function using testMergeSort.cpp, input will be read via standard input, not through command-line parameters. After entering the array size, you will be prompted to enter each element one by one. This test file will call your <code>mergeSort</code> function on the array, and print the result. Make sure you test your function on arrays of various sizes.</p>
<h3 id="sample-execution-run">Sample Execution Run</h3>
<p>Below is a sample execution run to show you the input and output format we are looking for.</p>
<pre><code>Enter the array size: 5
Enter value 0: -7
Enter value 1: 2
Enter value 2: -39
Enter value 3: 12
Enter value 4: 8
Unsorted array: -7 2 -39 12 8
Sorted array: -39 -7 2 8 12</code></pre>
<p>The following resource explains the merge sort algorithm. This is what you need to implement in x86 assembly: <a href="https://www.hackerearth.com/practice/algorithms/sorting/merge-sort/tutorial/">www.hackerearth.com/practice/algorithms/sorting/merge-sort/tutorial/</a></p>
<p>Once you have completed the in-lab, submit mergeSort.s, testMergeSort.cpp, and your Makefile. <strong>If you finish the in-lab early, you should begin working on the post-lab report.</strong></p>
<hr />
<h2 id="post-lab-1">Post-lab</h2>
<p>For the post-lab, you should investigate and understand the topics below, and prepare a report that explains your findings. Follow the guidelines in the Post-lab Report Guideline section. You must show evidence of your conclusions in the form of assembly code, C++, screenshots, memory dumps, manual quotations, output, etc. Use test cases and the debugger as resources. Additionally, use resources other than yourself (e.g. books, reputable websites) and external to the course (i.e. "the TAs" or "lecture" don't count). <strong><em>You must use (and cite!) at least TWO additional resources for this post-lab!</em></strong></p>
<h3 id="post-lab-8-topics">Post-lab 8 topics</h3>
<p>The questions below are what you must address in your post-lab report. Make sure you answer each part and include sufficient evidence. You should create a simple class to help you answer the following questions. In your class, be sure to include several methods and at least 5 data members of different types and access levels (public and private).</p>
<h3 id="parameter-passing">Parameter passing</h3>
<p>Show and explain assembly code generated by the compiler for a simple function and function call that passes parameters by a variety of means. Show what is happening both in the caller and in the callee. You do not need to describe parts of the C calling convention we described in class (e.g. saving registers, saving the base pointer, how the call instruction works). The focus here is on examining in detail what happens when parameters are passed.</p>
<ol type="1">
<li>How are variables (ints, chars, pointers, floats, etc.) passed by value? How are they passed by reference? Create several functions and examine the parameter registers to help you answer this question.</li>
<li>Create a simple function that takes in an object. How are objects passed by value? How are they passed by reference? Specifically, what is contained in the parameter registers in each case?</li>
<li>Create an array in your main method, and write a function that takes it in as a parameter. How are arrays passed into functions? How does the callee access the parameters? Where are the data values placed? Hint: you will need to determine at least a register-relative address.</li>
<li>Is passing values by reference different than passing by pointer? If they are the same, what exactly is passed in the parameter register? If they are different, how so?</li>
</ol>
<h3 id="objects">Objects</h3>
<ol type="1">
<li>How is object data laid out in memory? Create an object in your main method, and view where each data member is located in memory. How does C++ keep different fields of an object "together"?</li>
<li>Explain how data member access works for objects. How does the assembly know which data member to access? We know how local variables and parameters are accessed (offsets from the base pointer) -- describe how this is done for data fields.</li>
<li>How does method invocation work for objects? Specifically, how does the assembly know which object it is being called out of? Remember that assembly is not object oriented.</li>
<li>How are data members accessed both from inside a member function and from outside? In other words, describe what the assembly code does to access data members in both of these situations.</li>
<li>How are public member functions accessed for your class? Call some of the public member functions for your class and examine the parameters. How is the "this" pointer implemented? Where is it stored? When is it accessed? How is it passed to member functions?</li>
</ol>
<p><strong>Your grade will be based on whether you sufficiently answered and provided evidence for the above questions.</strong></p>
<h3 id="tips-for-getting-started-on-the-post-lab">Tips for Getting Started on the Post-lab</h3>
<p>Think about how best to investigate the issues you choose. A good starting point is to write a small C++ program that illustrates one of the issues. This program should be as simple as possible.</p>
<p>Look at the assembly code associated with your C++ code. To examine the disassembled code you have three options. First, you can step through the code in the debugger using the disassembly view. You can also have the C++ code output to an assembly file using <code>clang++ -S -mllvm --x86-asm-syntax=intel -fomit-frame-pointer fileName.cpp</code>, which can be viewed in emacs. Lastly, you may use the site <a href="https://www.godbolt.org">www.godbolt.org</a> to view the assembly code. You can paste your C++ code directly into the editor, or upload a file. Choose either clang or gcc as your compiler.</p>
<p>Focus on devising experiments that will help you learn more about the particular issues. By tracing though some parts of the code, modifying your C++ code, and comparing the generated assembly for the two different versions, you should be able to come up with some reasonably good hypotheses about what is happening. Seek out resources that explain the issue. Keep in mind that you are required to list your sources in your post-lab report.</p>
<h3 id="post-lab-report-guidelines">Post-lab Report Guidelines</h3>
<p>The report should be a PDF file called postlab8.pdf. See the <a href="../../docs/convert_to_pdf.html">How to convert a file to PDF</a> page for details about creating a PDF file. Your report should be single spaced. In your report, label the items according to which list item they came from (parameter passing or objects), and their item number within that list. Your evidence should be embedded into the document. Highlighting portions of code or drawing arrows between things may help make your explanations clearer. For each item, you should include a short explanation (1-2 paragraphs maximum) and at least one piece of evidence. Don't forget to include at least two external resources. Other than your own experiments, feel free to use online x86 assembly references, C++ books, and resources you may find on the Internet or elsewhere. <strong>Discussing these issues is allowed, however, remember that your code and final report must be your own work and that you must credit ANY resources used.</strong></p>
<p>We want you to investigate the particular topic area from the given list, write code to discover the answers, and learn about this topic on your own.</p>
</body>
</html>