Section notes:

Administrative:
	Clarification of due dates
	Demo times will be stricter now, should be ready to demo independently, demonstrating that the code works completely
	Possible sunday time, but only if you can fully demo it without problems
	Printing out code - Make it pretty, comments aligned, etc. I DO NOT WANT TO HAVE TO PRINT YOUR CODE
	I WILL NEED CODE AT DEMO TIME (I only have 1 day to grade it)
	Please check your email often, and READ my emails (I send out homework clarifications, sometimes right before due dates because that's when the TA's get the info sometimes)
	Do you want outlines returned sooner? Harder for me.

A discussion of pointers:
	There's such a thing as a variable, which contains a value, and then such things as pointers to variables, which are just special variables that contain the ADDRESS of a value (they POINT to a value, rather than HOLDING a value).
	C-syntax:
		int a;  <- a variable that holds the value of an integer
		a = 9;
		int *a; <- a variable that holds the address of an integer (show diagramatically these things in memory)
		*a = 9;
	Asm86-syntax:
		; register variables:
		MOV	SI, 9   <- SI represents an integer variable, so AX contains the value of the variable (9 in this case)
		; memory variables:
		DATA SEGMENT
			IntegerA	DW	?
		DATA ENDS
		CODE SEGMENT
			MOV	IntegerA, 9 ; moves 9 into the memory variable IntegerA
		CODE SEGMENT

		; pointer:
		MOV	[SI], 9 <- SI represents a pointer to an integer, so SI contains the address of an integer in memory

Outline problems:

	What is an outline?
		what should and should not be there
		pseudocode should be high level, describes what you're doing, and algorithms (high-level how)
			should not contain actual assembly implementation (low-level how)
			SHOULD NOT USE REGISTER NAMES (e.g. [DS:SI] = '-' is bad. I have no idea what this is supposed to mean)
	Why should you care?
		You're on pass-fail, but next term, you'll be on grades for 52, and you'll be doing similar things with your code, and Glen will have the same (if not stricter) standards.
	Clarify that there is no one right way to write these programs. I only give the recommended implementation.
	Define the structure! Always do this for shared variables/data structures that will be used in your functions
	Arrays can only be fixed sizes (defined at compile time). We cannot "malloc" for dynamic memory allocation. (on PCs you do this because the OS manages all of memory for you, and you request chunks of it)
		The difference between declaration and instatiation:
			Declaring means you tell the compiler the structure of your STRUC, how IT should allocate memory
			Instantiation means you actually say you want to have a variable of a given type in memory, and then the compiler uses the declaration you gave it earlier to allocate the amount of memory required.

			In this way, you see that you can't allocate variable amounts of memory, since all of this is determined when you compile the program.
			When you run the program, nothing can keep track of variable amounts of memory (since you would need to globally keep track of all dynamic variables, which is what the OS does for you)
	A lot of people should use DO-WHILE loops in EnQ, DeQ when checking for things. Go over this.
	If you know the registers that will get changed and the stack depth, you know you're working at too low a level.

	Go over quick stack example, if one were to implement a stack structure

Code issues:
	File organization - put like functions in one module (file). DO NOT PUT EACH FUNCTION IN SEPARATE FILE/MODULE. This is illogical.
	Better label names
	Emphasize that I will not be able to check all code that gets turned in later on, so if I mark up errors, they should fix them.
	So, yes, you must turn in ALL code that is used for a given homework assignment, so if you reuse the conversion routines in HW6, turn the code in for it again. (Something could have changed in between)

Queue review:
	http://cs.smith.edu/~streinu/Teaching/Courses/112/Applets/Queue/myApplet.html