a3e7f70bae757e67e59d6a42126c8effd1b61f0b
haas/spring2026/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/spring2026/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 | + |
|
| 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 |