Operating Systems 2014F: Assignment 4 - Revision history

Soma: /* Solutions */

2014-10-17T00:07:53Z

Solutions

← Older revision		Revision as of 00:07, 17 October 2014
Line 20:		Line 20:
	## The caller invokes the function (using <tt>call</tt>)		## The caller invokes the function (using <tt>call</tt>)
	## The callee saves the base pointer %ebp and copies the stack pointer %esp to %ebp (using <tt>push</tt> and <tt>mov</tt>). Note %ebp is used to access local variables and arguments.		## The callee saves the base pointer %ebp and copies the stack pointer %esp to %ebp (using <tt>push</tt> and <tt>mov</tt>). Note %ebp is used to access local variables and arguments.
	## ~~Space is allocated~~ on the stack for local variables.		## The callee allocates spaces on the stack for local variables using <tt>sub %esp</tt>.
	## When the callee finishes, it puts the return value in %eax, removes local variables from the stack then executes <tt>ret</tt>.		## When the callee finishes, it puts the return value in %eax, removes local variables from the stack then executes <tt>ret</tt>.
	## The caller removes the arguments from the stack, restores its registers (using <tt>pop</tt>) as necessary, and uses the return value in %eax as necessary to continue the computation.		## The caller removes the arguments from the stack, restores its registers (using <tt>pop</tt>) as necessary, and uses the return value in %eax as necessary to continue the computation.

Soma at 00:06, 17 October 2014

2014-10-17T00:06:13Z

← Older revision		Revision as of 00:06, 17 October 2014
Line 15:		Line 15:
	==Solutions==		==Solutions==
	# Library calls (as reported by ltrace) are function calls that are made to dynamically-linked libraries. Functions whose addresses have been resolved at compile time (statically linked) are not reported by ltrace.		# Library calls (as reported by ltrace) are function calls that are made to dynamically-linked libraries. Functions whose addresses have been resolved at compile time (statically linked) are not reported by ltrace.
	# Note that the following assumes that the no optimization has been done. With optimization, fewer instructions are made to invoke functions, up to and including inlining functions so that the code for the function is effectively "inserted" into the caller. Optimization may also change the opcodes that are used and may pass and return values in registers.		# Note that the following assumes that the no optimization has been done. With optimization, fewer instructions are made to invoke functions, up to and including inlining functions so that the code for the function is effectively "inserted" into the caller. Optimization may also change the opcodes that are used and may pass and return values in registers. For more information, see [http://www.cs.dartmouth.edu/~sergey/cs108/tiny-guide-to-x86-assembly.pdf The Tiny Guide to x86 Assembly].
	## The caller pushes the function arguments onto the stack		## The caller saves any "caller save" registers it wishes to using <tt>push</tt>
	## The caller invokes the function (using call)		## The caller pushes the function arguments onto the stack (right to left order normally) using <tt>push</tt> or other instructions along with space for the return value, if necessary.
	## The callee		## The caller invokes the function (using <tt>call</tt>)
			## The callee saves the base pointer %ebp and copies the stack pointer %esp to %ebp (using <tt>push</tt> and <tt>mov</tt>). Note %ebp is used to access local variables and arguments.
			## Space is allocated on the stack for local variables.
			## When the callee finishes, it puts the return value in %eax, removes local variables from the stack then executes <tt>ret</tt>.
			## The caller removes the arguments from the stack, restores its registers (using <tt>pop</tt>) as necessary, and uses the return value in %eax as necessary to continue the computation.
	# See syscall-hello-pid.c below.		# See syscall-hello-pid.c below.
	# See syscall-hello-pid.s below.		# See syscall-hello-pid.s below.

Soma: /* Solutions */

2014-10-16T23:51:50Z

Solutions

← Older revision		Revision as of 23:51, 16 October 2014
Line 15:		Line 15:
	==Solutions==		==Solutions==
	# Library calls (as reported by ltrace) are function calls that are made to dynamically-linked libraries. Functions whose addresses have been resolved at compile time (statically linked) are not reported by ltrace.		# Library calls (as reported by ltrace) are function calls that are made to dynamically-linked libraries. Functions whose addresses have been resolved at compile time (statically linked) are not reported by ltrace.
	# Note that the following assumes that the no optimization has been done. With optimization, fewer instructions are made to invoke functions, up to and including inlining functions so that the code for the function is effectively "inserted" into the caller.		# Note that the following assumes that the no optimization has been done. With optimization, fewer instructions are made to invoke functions, up to and including inlining functions so that the code for the function is effectively "inserted" into the caller. Optimization may also change the opcodes that are used and may pass and return values in registers.
	~~: This is~~		## The caller pushes the function arguments onto the stack
			## The caller invokes the function (using call)
			## The callee
	# See syscall-hello-pid.c below.		# See syscall-hello-pid.c below.
	# See syscall-hello-pid.s below.		# See syscall-hello-pid.s below.

Soma at 23:41, 16 October 2014

2014-10-16T23:41:05Z

← Older revision		Revision as of 23:41, 16 October 2014
Line 15:		Line 15:
	==Solutions==		==Solutions==
	# Library calls (as reported by ltrace) are function calls that are made to dynamically-linked libraries. Functions whose addresses have been resolved at compile time (statically linked) are not reported by ltrace.		# Library calls (as reported by ltrace) are function calls that are made to dynamically-linked libraries. Functions whose addresses have been resolved at compile time (statically linked) are not reported by ltrace.
	#		# Note that the following assumes that the no optimization has been done. With optimization, fewer instructions are made to invoke functions, up to and including inlining functions so that the code for the function is effectively "inserted" into the caller.
			: This is
	# See syscall-hello-pid.c below.		# See syscall-hello-pid.c below.
	# See syscall-hello-pid.s below.		# See syscall-hello-pid.s below.

Soma: /* syscall-hello-pid.c */

2014-10-09T03:16:43Z

syscall-hello-pid.c

@@ Line 21: / Line 21: @@
 ===syscall-hello-pid.c===
 <source lang="c">
 </source>

Soma at 18:56, 8 October 2014

2014-10-08T18:56:20Z

← Older revision		Revision as of 18:56, 8 October 2014
Line 12:		Line 12:
	# [3] Write a program "syscall-hello-pid.c" that is based on syscall-hello.c but outputs "Hello, I am process 417!" (assuming the PID of the process running it is 417). Note that you will have to get the current process ID, convert it to a string, and combine it with the "Hello" string. USE NO LIBRARY FUNCTIONS except syscall().		# [3] Write a program "syscall-hello-pid.c" that is based on syscall-hello.c but outputs "Hello, I am process 417!" (assuming the PID of the process running it is 417). Note that you will have to get the current process ID, convert it to a string, and combine it with the "Hello" string. USE NO LIBRARY FUNCTIONS except syscall().
	# [4] Add a comment to every line of the assembly code version of your syscall-hello-pid.c code, as produced by <tt>gcc -s</tt>, explaining the purpose of each line. Explain with reference to the C code, not the assembly code. For example, a change in the stack pointer should be notated as "allocate space for local variables x and pid" not "changed the stack pointer". You may want to add in flags such as "-O2" and "-g" to get easier to interpret assembly code. '''You may ignore/delete all lines that start with a period,''' as those do not generate code directly. If you had trouble with the previous question, you may instead comment the assembly from syscall-hello.c, but at the loss of one point (out of 10).		# [4] Add a comment to every line of the assembly code version of your syscall-hello-pid.c code, as produced by <tt>gcc -s</tt>, explaining the purpose of each line. Explain with reference to the C code, not the assembly code. For example, a change in the stack pointer should be notated as "allocate space for local variables x and pid" not "changed the stack pointer". You may want to add in flags such as "-O2" and "-g" to get easier to interpret assembly code. '''You may ignore/delete all lines that start with a period,''' as those do not generate code directly. If you had trouble with the previous question, you may instead comment the assembly from syscall-hello.c, but at the loss of one point (out of 10).

			==Solutions==
			# Library calls (as reported by ltrace) are function calls that are made to dynamically-linked libraries. Functions whose addresses have been resolved at compile time (statically linked) are not reported by ltrace.
			#
			# See syscall-hello-pid.c below.
			# See syscall-hello-pid.s below.

			===syscall-hello-pid.c===
			<source lang="c">

			</source>

			===syscall-hello-pid.s===
			<source lang="asm">

			</source>

Soma at 14:16, 1 October 2014

2014-10-01T14:16:30Z

← Older revision		Revision as of 14:16, 1 October 2014
Line 1:		Line 1:
	Please submit the answers to the following questions via CULearn by midnight on Saturday, October 4, 2014 (extended from October 1st). There 10 points in 4 questions.		Please submit the answers to the following questions via CULearn by midnight on '''Saturday, October 4, 2014''' (extended from October 1st). There 10 points in 4 questions.

	Submit your answers as a single text file named "<username>-comp3000-assign4.txt" (where username is your MyCarletonOne username). The first four lines of this file should be "COMP 3000 Assignment 4", your name, student number, and the date of submission. You may wish to format your answers in [http://en.wikipedia.org/wiki/Markdown Markdown] to improve their appearance.		Submit your answers as a single text file named "<username>-comp3000-assign4.txt" (where username is your MyCarletonOne username). The first four lines of this file should be "COMP 3000 Assignment 4", your name, student number, and the date of submission. You may wish to format your answers in [http://en.wikipedia.org/wiki/Markdown Markdown] to improve their appearance.

Soma at 14:16, 1 October 2014

2014-10-01T14:16:19Z

← Older revision		Revision as of 14:16, 1 October 2014
Line 1:		Line 1:
	Please submit the answers to the following questions via CULearn by midnight on ~~Wednesday~~, October 1, 2014. There 10 points in 4 questions.		Please submit the answers to the following questions via CULearn by midnight on Saturday, October 4, 2014 (extended from October 1st). There 10 points in 4 questions.

	Submit your answers as a single text file named "<username>-comp3000-assign4.txt" (where username is your MyCarletonOne username). The first four lines of this file should be "COMP 3000 Assignment 4", your name, student number, and the date of submission. You may wish to format your answers in [http://en.wikipedia.org/wiki/Markdown Markdown] to improve their appearance.		Submit your answers as a single text file named "<username>-comp3000-assign4.txt" (where username is your MyCarletonOne username). The first four lines of this file should be "COMP 3000 Assignment 4", your name, student number, and the date of submission. You may wish to format your answers in [http://en.wikipedia.org/wiki/Markdown Markdown] to improve their appearance.

Soma at 18:47, 26 September 2014

2014-09-26T18:47:35Z

← Older revision		Revision as of 18:47, 26 September 2014
Line 1:		Line 1:
	~~'''This assignment is not yet finalized (REALLY)'''~~

	Please submit the answers to the following questions via CULearn by midnight on Wednesday, October 1, 2014. There 10 points in 4 questions.		Please submit the answers to the following questions via CULearn by midnight on Wednesday, October 1, 2014. There 10 points in 4 questions.

Soma: /* Questions */

2014-09-26T17:55:15Z

Questions

← Older revision		Revision as of 17:55, 26 September 2014
Line 10:		Line 10:

	==Questions==		==Questions==
	# [1] What is the difference between function calls and library calls?		# [1] What is the difference between function calls and library calls (as reported by ltrace)?
	# [2] In assembly, how does a program make a function call (using C semantics)? Describe the process and state the specific instructions used in x86 assembly code.		# [2] In assembly, how does a program make a function call (using C semantics)? Describe the process and state the specific instructions used in x86 assembly code.
	# [3] Write a program "syscall-hello-pid.c" that is based on syscall-hello.c but outputs "Hello, I am process 417!" (assuming the PID of the process running it is 417). Note that you will have to get the current process ID, convert it to a string, and combine it with the "Hello" string. USE NO LIBRARY FUNCTIONS except syscall().		# [3] Write a program "syscall-hello-pid.c" that is based on syscall-hello.c but outputs "Hello, I am process 417!" (assuming the PID of the process running it is 417). Note that you will have to get the current process ID, convert it to a string, and combine it with the "Hello" string. USE NO LIBRARY FUNCTIONS except syscall().
	# [4] Add a comment to every line of the assembly code version of your syscall-hello-pid.c code, as produced by <tt>gcc -s</tt>, explaining the purpose of each line. Explain with reference to the C code, not the assembly code. For example, a change in the stack pointer should be notated as "allocate space for local variables x and pid" not "changed the stack pointer". You may want to add in flags such as "-O2" and "-g" to get easier to interpret assembly code. '''You may ignore/delete all lines that start with a period,''' as those do not generate code directly. If you had trouble with the previous question, you may instead comment the assembly from syscall-hello.c, but at the loss of one point (out of 10).		# [4] Add a comment to every line of the assembly code version of your syscall-hello-pid.c code, as produced by <tt>gcc -s</tt>, explaining the purpose of each line. Explain with reference to the C code, not the assembly code. For example, a change in the stack pointer should be notated as "allocate space for local variables x and pid" not "changed the stack pointer". You may want to add in flags such as "-O2" and "-g" to get easier to interpret assembly code. '''You may ignore/delete all lines that start with a period,''' as those do not generate code directly. If you had trouble with the previous question, you may instead comment the assembly from syscall-hello.c, but at the loss of one point (out of 10).