haas/fall2026/comporg/projects/dap0.md
... ...
@@ -0,0 +1,100 @@
1
+# CSCS2650 Computer Organization
2
+
3
+# PROJECT: DEBUG A PROGRAM (dap0)
4
+
5
+## OBJECTIVE
6
+
7
+Create a simple debugging output routine to help investigate issues in
8
+program logic.
9
+
10
+## TASK
11
+
12
+Implement a Vircon32 assembly subroutines that displays the 32-bit
13
+hexadecimal value of an indicated item to the display at a provided set
14
+of coordinates (supplied via the stack).
15
+
16
+Specifically, you want to call the subroutine **`_debug`**, and place it
17
+in a file called **`debug.s`** so that you can **`%include`** it as
18
+needed in your debugging efforts.
19
+
20
+It is written entirely in Vircon32 assembly language, using no
21
+compiler-generated routines from the Vircon32 API (no **print**, no
22
+**itoa**)- you want to create whatever supporting routines are needed.
23
+
24
+Pass 3 parameters via the stack:
25
+
26
+ * value to display (first added)
27
+ * X coordinate (second added)
28
+ * Y coordinate (third added)
29
+
30
+Be sure to preserve all register and important system states (ie whatever
31
+was going on before the call to debug must be preserved: save and
32
+restore)
33
+
34
+Make use of the stack instructions **PUSH** and **POP**, although all
35
+stack access does not have to exclusively be via **PUSH** and **POP**.
36
+
37
+Utilize bitwise logic in the process to convert each nibble of data into
38
+the value/region you will display
39
+
40
+Try it out on some existing code, posting a screenshot (with context) to
41
+the class discord.
42
+
43
+Provide usage instructions (what needs to be added to existing code to
44
+use your debug subroutine)
45
+
46
+## SUBMISSION
47
+
48
+To be successful in this project, the following criteria (or their
49
+equivalent) must be met:
50
+
51
+ * Project must be submit on time, by the deadline.
52
+ * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
53
+ * Processing must be correct based on input given and output requested
54
+ * Output, if applicable, must be correct based on values input
55
+ * Code must be nicely and consistently indented and aligned
56
+ * Code must be consistently written, to strive for readability from having a consistent style throughout
57
+ * Code must be commented
58
+ * Sufficient comments explaining the point of provided logic **MUST** be present
59
+ * Track/version the source code in your private semester repository
60
+ * Submit a copy of your source code to me using the **submit** tool by the deadline.
61
+
62
+## SUBMIT TOOL USAGE
63
+
64
+Let's say you have completed work on the project, and are ready to
65
+submit, you would do the following (once on LAB46, with all your data
66
+present):
67
+
68
+```
69
+lab46:~/src/SEMESTER/comporg/dap0$ make submit
70
+```
71
+
72
+You should get some sort of confirmation indicating successful submission
73
+if all went according to plan. If not, check for typos and or locational
74
+mismatches.
75
+
76
+### RUBRIC
77
+
78
+I'll be evaluating the project based on the following criteria:
79
+
80
+```
81
+182:dap0:final tally of results (182/182)
82
+*:dap0:submitted file called debug.s or debug.asm [13/13]
83
+*:dap0:subroutine is called _debug or __debug [13/13]
84
+*:dap0:code assembles with no warnings or errors [13/13]
85
+*:dap0:parameters obtained via the stack [26/26]
86
+*:dap0:register states preserved across call [13/13]
87
+*:dap0:debug subroutine uses the stack [26/26]
88
+*:dap0:process utilizes bitwise logic [26/26]
89
+*:dap0:screenshot of subroutine in action to discord [13/13]
90
+*:dap0:code contains usage instructions in comments [13/13]
91
+*:dap0:output contains display of contents at coordinates [13/13]
92
+*:dap0:functionality is correct and to specifications [13/13]
93
+```
94
+
95
+### ADDITIONALLY
96
+
97
+ * Solutions not abiding by spirit of project will be subject to a 50% overall deduction
98
+ * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
99
+ * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
100
+ * Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction
haas/fall2026/comporg/projects/dap1.md
... ...
@@ -0,0 +1,106 @@
1
+# CSCS2650 Computer Organization
2
+
3
+# PROJECT: DEBUG A PROGRAM (dap1)
4
+
5
+## OBJECTIVE
6
+
7
+Extend our debugging infrastructure with the creation of a
8
+**`_debugmemory`** subroutine.
9
+
10
+## TASK
11
+
12
+Implement a Vircon32 assembly subroutine that uses your dap0 **`_debug`**
13
+subroutine. Your task is to display a range of memory addresses, along
14
+with their hexadecimal contents.
15
+
16
+The starting and ending memory addresses are given as parameters via the
17
+stack.
18
+
19
+Specifically, you want to call the subroutine **`_debugmemory`**, and
20
+place it in your existing **debug.s** file so that both can be
21
+**%include**'ed as needed in debugging efforts.
22
+
23
+It will call **`_debug`** in the process of operation (let **`_debug`**
24
+handle the display of information)
25
+
26
+Of course: written entirely in Vircon32 assembly language, using no
27
+compiler-generated routines from the Vircon32 API (no **print**, no
28
+**itoa**, only the routines YOU write)
29
+
30
+You will pass 2 parameters via the stack:
31
+
32
+ * starting address (first pushed)
33
+ * ending address (second pushed)
34
+
35
+You want to make sure all register states preserved (ie whatever was
36
+going on before the call to debug must be preserved: save and restore)
37
+
38
+Make use of the stack instructions **PUSH** and **POP**, although all
39
+stack access does not have to exclusively be via **PUSH** and **POP**
40
+
41
+Try it out on some existing code, posting a screenshot (with context) to
42
+the class discord
43
+
44
+In your code (via comments), provide usage instructions (what needs to be
45
+added to existing code to use your debug subroutine)
46
+
47
+Modify **`_debug`** to "return" an updated X and Y coordinate (by
48
+updating the value stored in the stack), so that **_debugmemory** can
49
+**POP** and use it in its own processes.
50
+
51
+Make sure to display any leading zeros in your output.
52
+
53
+## SUBMISSION
54
+
55
+To be successful in this project, the following criteria (or their
56
+equivalent) must be met:
57
+
58
+ * Project must be submit on time, by the deadline.
59
+ * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
60
+ * Processing must be correct based on input given and output requested
61
+ * Output, if applicable, must be correct based on values input
62
+ * Code must be nicely and consistently indented and aligned
63
+ * Code must be consistently written, to strive for readability from having a consistent style throughout
64
+ * Code must be commented
65
+ * Sufficient comments explaining the point of provided logic **MUST** be present
66
+ * Track/version the source code in your private semester repository
67
+ * Submit a copy of your source code to me using the **submit** tool by the deadline.
68
+
69
+## SUBMIT TOOL USAGE
70
+
71
+Let's say you have completed work on the project, and are ready to
72
+submit, you would do the following (once on LAB46, with all your data
73
+present):
74
+
75
+```
76
+lab46:~/src/SEMESTER/comporg/dap1$ make submit
77
+```
78
+
79
+You should get some sort of confirmation indicating successful submission
80
+if all went according to plan. If not, check for typos and or locational
81
+mismatches.
82
+
83
+### RUBRIC
84
+
85
+I'll be evaluating the project based on the following criteria:
86
+
87
+```
88
+234:dap1:final tally of results (234/234)
89
+*:dap1:submitted file called debug.s or debug.asm [13/13]
90
+*:dap1:subroutine is called _debugmemory or __debugmemory [13/13]
91
+*:dap1:code assembles with no warnings or errors [26/26]
92
+*:dap1:parameters obtained, modified in the stack [26/26]
93
+*:dap1:register states preserved across call [26/26]
94
+*:dap1:debugging subroutines use stack instructions [26/26]
95
+*:dap1:screenshot of subroutine in action to DISCORD [26/26]
96
+*:dap1:code contains usage instructions in comments [26/26]
97
+*:dap1:output contains display of addresses, contents [26/26]
98
+*:dap1:functionality is correct and to specifications [26/26]
99
+```
100
+
101
+### ADDITIONALLY
102
+
103
+ * Solutions not abiding by spirit of project will be subject to a 50% overall deduction
104
+ * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
105
+ * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
106
+ * Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction
haas/fall2026/comporg/projects/dap2.md
... ...
@@ -0,0 +1,97 @@
1
+# CSCS2650 Computer Organization
2
+
3
+# PROJECT: DEBUG A PROGRAM (dap2)
4
+
5
+## OBJECTIVE
6
+
7
+Extend our debugging infrastructure with the creation of a
8
+**`debugregs`** subroutine.
9
+
10
+## TASK
11
+
12
+Implement a Vircon32 assembly subroutine that uses your dap0 routine.
13
+subroutine. Your task is to display the set of CPU registers (R0-R13),
14
+along with their hexadecimal contents.
15
+
16
+No parameters need to be given to this debugging subroutine, since it
17
+will always be displaying this same range of registers.
18
+
19
+Specifically, be sure to:
20
+
21
+... call the subroutine **`debugregs`** or **`_debugregisters`**, and
22
+place it in your existing **debug.s** file so that both (and also
23
+**_debugmemory** from dap1) can be **%include**'ed as needed in debugging
24
+efforts.
25
+
26
+Make sure it that it calls and makes use of your original **_debug**
27
+in the process of operation (let **_debug** handle the display of
28
+information).
29
+
30
+That it is written entirely in Vircon32 assembly language, using no
31
+compiler-generated routines from the Vircon32 API (no **print**, no
32
+**itoa**)
33
+
34
+As stated above: no parameters need to be passed in to use this routine.
35
+
36
+Pertaining to the registers, make sure your routine preserves existing
37
+register states, so that whatever was going on before the call to debug
38
+is saved, so you can restore it upon completion).
39
+
40
+Display registers R0-R7 in the left column, starting at or near the top
41
+left of the screen, with R8-R13 in the right column, separated by an
42
+appropriate distance.
43
+
44
+## SUBMISSION
45
+
46
+To be successful in this project, the following criteria (or their
47
+equivalent) must be met:
48
+
49
+ * Project must be submit on time, by the deadline.
50
+ * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
51
+ * Processing must be correct based on input given and output requested
52
+ * Output, if applicable, must be correct based on values input
53
+ * Code must be nicely and consistently indented and aligned
54
+ * Code must be consistently written, to strive for readability from having a consistent style throughout
55
+ * Code must be commented
56
+ * Sufficient comments explaining the point of provided logic **MUST** be present
57
+ * Track/version the source code in your private semester repository
58
+ * Submit a copy of your source code to me using the **submit** tool by the deadline.
59
+
60
+## SUBMIT TOOL USAGE
61
+
62
+Let's say you have completed work on the project, and are ready to
63
+submit, you would do the following (once on LAB46, with all your data
64
+present):
65
+
66
+```
67
+lab46:~/src/SEMESTER/comporg/dap1$ make submit
68
+```
69
+
70
+You should get some sort of confirmation indicating successful submission
71
+if all went according to plan. If not, check for typos and or locational
72
+mismatches.
73
+
74
+### RUBRIC
75
+
76
+I'll be evaluating the project based on the following criteria:
77
+
78
+```
79
+286:dap2:final tally of results (286/286)
80
+*:dap2:submitted file called debug.s or debug.asm [26/26]
81
+*:dap2:subroutine is called _debugregs or __debugregisters [26/26]
82
+*:dap2:code assembles with no warnings or errors [26/26]
83
+*:dap2:register states preserved across call [26/26]
84
+*:dap2:calls upon original _debug to do data output [26/26]
85
+*:dap2:output contains display of registers, contents [52/52]
86
+*:dap2:screenshot of subroutine in action to DISCORD [26/26]
87
+*:dap2:code contains usage instructions in comments [26/26]
88
+*:dap2:output contains display of addresses, contents [26/26]
89
+*:dap2:functionality is correct and to specifications [26/26]
90
+```
91
+
92
+### ADDITIONALLY
93
+
94
+ * Solutions not abiding by spirit of project will be subject to a 50% overall deduction
95
+ * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
96
+ * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
97
+ * Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction
haas/fall2026/comporg/projects/pnc0.md
... ...
@@ -0,0 +1,95 @@
1
+# CSCS2650 Computer Organization
2
+
3
+# PROJECT: PRIME NUMBER COMPUTATIONS (pnc0)
4
+
5
+## OBJECTIVE
6
+
7
+Start exploring algorithm/implementation comparison and optimization with
8
+respect to various approaches of computing prime numbers.
9
+
10
+## GRABIT
11
+
12
+There is a GRABIT available, containing some skeleton code, an XML file,
13
+and a Makefile, that will facilitate building the cartridge.
14
+
15
+## TASK
16
+
17
+Implement two separate, independent programs, one in Vircon32 C, and
18
+other in Vircon32 assembly, that:
19
+
20
+ * performs a brute force/"trial-by-division" process on a range of values, 2-N
21
+ * the values for N are some sufficient quantity still small enough to fit within an integer
22
+ * the values for N will have some relationship (powers of 2, powers of 10/magnitudes) that ideally can be computed via some loop/equation (ie 1024, 2048, 4098, 8192, 16384, etc.)
23
+ * the values for N have some sufficient quantity large enough where its upper set values will take some amount of time to compute (fast enough to have some relatable value, not to exceed 16 seconds)
24
+ * for each value of N:
25
+ * display that N/upper bound
26
+ * tally: display the number of primes identified (2-N)
27
+ * display the amount of time taken to do the total computation for that value of N, out to 3 decimal places
28
+ * display each N value and result in an arrangement on the screen that can be clearly identified and read by the viewer
29
+ * timing should go out, as reasonable, to a few decimal places, and should be consistent across all attempts.
30
+ * timing is on the computational process only, not the display of results.
31
+ * create a graph (using some external tool) that plots the performance of the C and assembly implementations working on identical workloads of this brute force algorithm according to the various N's and the time it took. Share your graph of your results on the class discord and on the project documentation page.
32
+ * a line graph is the suggested best candidate
33
+ * the assembly version is to be done entirely by hand, and make zero use of C API functions. Just the usual in/out stuff we've been doing.
34
+ * this will not be an interactive program: it starts up, does its thing, outputs it results, then halts.
35
+ * this brute force implementation is meant as our baseline. As such, it should not contain any optimizations or attempted improvements. As we progress through `pnc1` and `pnc2`, this base implementation should be the least efficient. This is important, to allow us to realize the impact of various improvements we will be making in those upcoming projects.
36
+
37
+## REFERENCE
38
+
39
+The following are reference screenshots of what your implementations
40
+should approximate:
41
+
42
+### PNC0 C IMPLEMENTATION
43
+
44
+![PNC0/C runtime](images/pnc0runtime.png)
45
+
46
+## SUBMISSION
47
+
48
+To be successful in this project, the following criteria (or their
49
+equivalent) must be met:
50
+
51
+ * Project must be submit on time, by the deadline.
52
+ * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
53
+ * Processing must be correct based on input given and output requested
54
+ * Output, if applicable, must be correct based on values input
55
+ * Code must be nicely and consistently indented and aligned
56
+ * Code must be consistently written, to strive for readability from having a consistent style throughout
57
+ * Code must be commented
58
+ * Sufficient comments explaining the point of provided logic **MUST** be present
59
+ * Track/version the source code in your private semester repository
60
+ * Submit a copy of your source code to me using the **submit** tool by the deadline.
61
+
62
+## SUBMIT TOOL USAGE
63
+
64
+Let's say you have completed work on the project, and are ready to
65
+submit, you would do the following (once on LAB46, with all your data
66
+present):
67
+
68
+```
69
+lab46:~/src/SEMESTER/DESIG/pnc0$ make submit
70
+```
71
+
72
+You should get some sort of confirmation indicating successful submission
73
+if all went according to plan. If not, check for typos and or locational
74
+mismatches.
75
+
76
+### RUBRIC
77
+
78
+I'll be evaluating the project based on the following criteria:
79
+
80
+```
81
+156:pnc0:final tally of results (156/156)
82
+*:pnc0:submitted working C and assembly implementations [26/26]
83
+*:pnc0:post screenshots to class DISCORD channel [26/26]
84
+*:pnc0:processing is correct, and to specifications [26/26]
85
+*:pnc0:no optimizations or improvements on the process [26/26]
86
+*:pnc0:graph produced from timing data produced [26/26]
87
+*:pnc0:timing data is taken out to at least 3 decimal places [26/26]
88
+```
89
+
90
+### ADDITIONALLY
91
+
92
+ * Solutions not abiding by spirit of project will be subject to a 50% overall deduction
93
+ * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
94
+ * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
95
+ * Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction
haas/fall2026/comporg/projects/pnc1.md
... ...
@@ -0,0 +1,97 @@
1
+# CSCS2650 Computer Organization
2
+
3
+# PROJECT: PRIME NUMBER COMPUTATIONS (pnc1)
4
+
5
+## OBJECTIVE
6
+
7
+Continue exploring algorithm/implementation comparison and optimization
8
+with respect to various approaches of computing prime numbers.
9
+
10
+## GRABIT
11
+
12
+There is a GRABIT available, containing some skeleton code, an XML file,
13
+and a Makefile, that will facilitate building the cartridge.
14
+
15
+## TASK
16
+
17
+Add to your two separate, independent programs, one in Vircon32 C, and
18
+other in Vircon32 assembly, functionality that:
19
+
20
+ * implements functionality for the following optimizations (both in C and assembly):
21
+ * break: breaks from trial division/brute force when a viable factor is found (break on composite)
22
+ * odds: assuming 2 is prime, does odds-only processing (both number and factor check)
23
+ * sqrt: only processes up through the square root point of the number being evaluated
24
+ * implementation here include the following:
25
+ * break
26
+ * odds
27
+ * sqrt
28
+ * break+odds
29
+ * odds+sqrt
30
+ * break+sqrt
31
+ * break+odds+sqrt
32
+ * collects the same timing data with common workloads to the brute force/naive variants from pnc0
33
+ * new variants added to the runtime graph you made in pnc0, adjusting and re-running pnc0 variants to allow for a consistent presentation of information
34
+ * be sure to use distinctive colors/patterns to distinguish items on the graph (again, line graph is a recommended choice)
35
+
36
+## REFERENCE
37
+
38
+The following are reference screenshots of what your implementations
39
+should approximate:
40
+
41
+### PNC1 C IMPLEMENTATION
42
+
43
+![PNC1/C runtime](images/pnc1runtime.png)
44
+
45
+## SUBMISSION
46
+
47
+To be successful in this project, the following criteria (or their
48
+equivalent) must be met:
49
+
50
+ * Project must be submit on time, by the deadline.
51
+ * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
52
+ * Processing must be correct based on input given and output requested
53
+ * Output, if applicable, must be correct based on values input
54
+ * Code must be nicely and consistently indented and aligned
55
+ * Code must be consistently written, to strive for readability from having a consistent style throughout
56
+ * Code must be commented
57
+ * Sufficient comments explaining the point of provided logic **MUST** be present
58
+ * Track/version the source code in your private semester repository
59
+ * Submit a copy of your source code to me using the **submit** tool by the deadline.
60
+
61
+## SUBMIT TOOL USAGE
62
+
63
+Let's say you have completed work on the project, and are ready to
64
+submit, you would do the following (once on LAB46, with all your data
65
+present):
66
+
67
+```
68
+lab46:~/src/SEMESTER/DESIG/pnc1$ make submit
69
+```
70
+
71
+You should get some sort of confirmation indicating successful submission
72
+if all went according to plan. If not, check for typos and or locational
73
+mismatches.
74
+
75
+### RUBRIC
76
+
77
+I'll be evaluating the project based on the following criteria:
78
+
79
+```
80
+208:pnc1:final tally of results (208/208)
81
+*:pnc1:submitted working C and assembly implementations [13/13]
82
+*:pnc1:graph produced from timing data produced [26/26]
83
+*:pnc1:post screenshots to class DISCORD channel [26/26]
84
+*:pnc1:processing is correct, and to specifications [26/26]
85
+*:pnc1:working break on composite optimization [26/26]
86
+*:pnc1:working odds only processing optimization [26/26]
87
+*:pnc1:working sqrt factor cap optimization [26/26]
88
+*:pnc1:all variants and combinations thereof operational [26/26]
89
+*:pnc1:timing data is taken out to at least 4 decimal places [13/13]
90
+```
91
+
92
+### ADDITIONALLY
93
+
94
+ * Solutions not abiding by spirit of project will be subject to a 50% overall deduction
95
+ * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
96
+ * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
97
+ * Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction
haas/fall2026/comporg/projects/pnc2.md
... ...
@@ -0,0 +1,113 @@
1
+# CSCS2650 Computer Organization
2
+
3
+# PROJECT: PRIME NUMBER COMPUTATIONS (pnc2)
4
+
5
+## OBJECTIVE
6
+
7
+Continue exploring algorithm/implementation, this time exploring a new
8
+algorithm: the sieve of eratosthenes and selected optimization.
9
+
10
+## GRABIT
11
+
12
+There is a GRABIT available, containing some skeleton code, an XML file,
13
+and a Makefile, that will facilitate building the cartridge.
14
+
15
+## TASK
16
+
17
+Add to your two separate, independent programs, one in Vircon32 C, and
18
+other in Vircon32 assembly, functionality that implements the following:
19
+
20
+ * sieve of eratosthenes (soe)
21
+ * sieve of eratosthenes with sqrt optimization (soe +s)
22
+
23
+Collect the timing data and add them onto your graphs. NOTE that you may
24
+have to adjust your bounds, and if needed, drop the naive brute
25
+implementation from consideration due to the extreme gap in performance.
26
+
27
+## PROGRAM
28
+
29
+Your next program, and first sieve, will be the Sieve of Eratosthenes.
30
+Perhaps among the best and likely longest-known sieves, its origins date
31
+from antiquity.
32
+
33
+This sieve, instead of calculating to determine the eligibility of a
34
+prime, works in a manner of marking off patterns of values that cannot be
35
+prime (so, it is composite-focused in approach vs. prime-focused).
36
+
37
+In order for it to work, we must store all the values we're processing so
38
+we can obtain what is left when done– what remains are the prime
39
+values.
40
+
41
+Some refined considerations:
42
+
43
+ * include memory management related to the sieve in your timing
44
+ * take measurements out to FIVE (5) decimal places
45
+ * consider doing a bar graph instead of line graph
46
+
47
+Please check out the [wikipedia page for the Sieve of Eratosthenes](https://en.wikipedia.org/wiki/Sieve_of_Eratosthenes)
48
+
49
+Here is an animated image of this sieve in action (from wikipedia):
50
+
51
+![sieve animation](images/sieveanimation.gif)
52
+
53
+## REFERENCE
54
+
55
+The following are reference screenshots of what your implementations
56
+should approximate:
57
+
58
+### PNC2 C IMPLEMENTATION
59
+
60
+![PNC2/C runtime](images/pnc2runtime.png)
61
+
62
+## SUBMISSION
63
+
64
+To be successful in this project, the following criteria (or their
65
+equivalent) must be met:
66
+
67
+ * Project must be submit on time, by the deadline.
68
+ * Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
69
+ * Processing must be correct based on input given and output requested
70
+ * Output, if applicable, must be correct based on values input
71
+ * Code must be nicely and consistently indented and aligned
72
+ * Code must be consistently written, to strive for readability from having a consistent style throughout
73
+ * Code must be commented
74
+ * Sufficient comments explaining the point of provided logic **MUST** be present
75
+ * Track/version the source code in your private semester repository
76
+ * Submit a copy of your source code to me using the **submit** tool by the deadline.
77
+
78
+## SUBMIT TOOL USAGE
79
+
80
+Let's say you have completed work on the project, and are ready to
81
+submit, you would do the following (once on LAB46, with all your data
82
+present):
83
+
84
+```
85
+lab46:~/src/SEMESTER/DESIG/pnc2$ make submit
86
+```
87
+
88
+You should get some sort of confirmation indicating successful submission
89
+if all went according to plan. If not, check for typos and or locational
90
+mismatches.
91
+
92
+### RUBRIC
93
+
94
+I'll be evaluating the project based on the following criteria:
95
+
96
+```
97
+260:pnc2:final tally of results (260/260)
98
+*:pnc2:submitted working C and assembly implementations [26/26]
99
+*:pnc2:graph produced from timing data produced [26/26]
100
+*:pnc2:post screenshots to class DISCORD channel [26/26]
101
+*:pnc2:processing is correct, and to specifications [26/26]
102
+*:pnc2:working sieve of eratosthenes implementation [52/52]
103
+*:pnc2:working soe with sqrt implementation [52/52]
104
+*:pnc2:all variants and combinations thereof operational [26/26]
105
+*:pnc2:timing data is taken out to at least 5 decimal places [26/26]
106
+```
107
+
108
+### ADDITIONALLY
109
+
110
+ * Solutions not abiding by spirit of project will be subject to a 50% overall deduction
111
+ * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
112
+ * Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
113
+ * Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction