Project 1: Spaces
NC State - Fall ‘25 - CSC 236
Table of Contents
Changelog
Any relevant changes to this page after it’s released will be listed here.
- None so far.
Due date
This project is due on Monday, September 22nd, 2025, 4:30pm ET.
You have a 15-minute buffer for any technical issues, after that you can use your project late days if needed. Please see syllabus for late days policy.
Problem
Overview
You will create a file called spaces.S.
First, your program will read a single byte from STDIN.
This byte (x) will indicate how many bytes the input string is.
The value of x will always be in the range [0, 127].
Then, your program will read an ASCII string of x bytes from STDIN.
It should process this string to combine any repeated spaces.
Note that you should only combine spaces (ASCII value of 32), tabs, new lines, etc., are not spaces and should not be combined.
Next, your program should write the result string (input string with combined spaces, with no extra bytes) to STDOUT.
Finally, your program should exit with a status code of 0.
Examples
- Empty string
- Size Input:
0 - Text Input:
""(empty) - Expected Output:
""(empty)
- Only-spaces string
- Size Input:
4 - Text Input:
" "(4 bytes) - Expected Output:
" "(1 byte)
- String with no spaces
- Size Input:
2 - Text Input:
“hi”(2 bytes) - Expected Output:
“hi”(2 bytes)
- String with single spaces
- Size Input:
5 - Text Input:
“hi hi”(5 bytes) - Expected Output:
“hi hi”(5 bytes)
- String with multiple spaces
- Size Input:
7 - Text Input:
“hi hi”(7 bytes) - Expected Output:
“hi hi”(5 bytes)
- String with leading spaces
- Size Input:
7 - Text Input:
" hi hi"(7 bytes) - Expected Output:
" hi hi"(6 bytes)
- String with trailing spaces
- Size Input:
7 - Text Input:
“hi hi "(7 bytes) - Expected Output:
“hi hi "(6 bytes)
- String with other spacing chars
- Size Input:
5 - Text Input:
" \t \n "(5 bytes) - Expected Output:
" \t \n "(5 bytes)
We have some examples with the complete input string that you can copy-paste to help your development at the end of this page.
Project Grading
Your code will be graded on documentation (20%) and accuracy (80%).
Documentation
The documentation score is calculated based on the ratio of comments and lines of code in your file. It is calculated in two equally-weighted parts:
(1) ratio of comment-only lines to all instruction lines
Say x is the ratio of your comment-only lines to all the instruction lines you have.
The grade for this section follows the table below:
| Cutoff | Score |
|---|---|
| x >= 50% | 100% |
| x >= 45% | 75% |
| x >= 40% | 50% |
| x < 40% | 0% |
(2) ratio of instructions with inline-comments to all instructions
Say y is the ratio of your instruction lines that have inline comments to all the instruction lines you have.
The grade for this section follows the table below:
| Cutoff | Score |
|---|---|
| y >= 80% | 100% |
| y >= 70% | 75% |
| y >= 65% | 50% |
| y < 60% | 0% |
Accuracy
Your code will be tested with multiple test cases. Each test case for this project is worth 1 point each, so they’re all equally weighted. All test cases for this proejct are open, so you should be able to see which ones you passed and which ones you failed when grading your code.
Submission
Grading your code
You will use webassembliss to grade your code:
On the grader page, you will enter your full name and UnityID, and upload your spaces.S solution and the spaces.pb2 project configuration file.
Click here to download the project configuration file.
Important: make sure your file is called spaces.S!
After filling in the page and clicking on submit, the page should take you to the grader results.
It might take a minute or so for your submission to be graded if there’s many people submitting, please do *not* refresh right away. If you get a timeout grading your code on the public instance (web.assembliss.app), try using the NCSU-restricted one as that one allows for a longer wait time for the request.
The grader results page shows you the total score your solution received, and has a button at the top that says Download file for submission.
This button should let you download a file called Spaces_UnityID_results.json.
Here’s an example of the top of the grader results page:
The Spaces_UnityID_results.json file contains your name, ID, source code, all information about the tests you passed, and your overall score.
This is the file you will submit to Moodle.
If you scroll down on the grader results, it will also show you which tests you passed, with diffs for all of them. You can also see the documentation score you received.
You can resubmit your updated code as many times as you wish to the server, so you’re able to fix any bugs you have compared to the expected test cases.
Whenever you’re satisfied with the grade you received, you can submit the appropriate json file to Moodle.
There are no efficienty targets for this project, you’re fine to ignore the Source Efficiency and Execution Efficiency sections of the results.
Submitting to Moodle
You will submit your Spaces_UnityID_results.json to Moodle.
The last json file you upload to Moodle will be the one considered for grading, and the timestamp of the last moodle submission will be considered the time you submitted your code for early/late submission policies.
Only files submitted through Moodle will be graded. The teaching staff will not accept submissions received through other channels (email, EdStem, etc.).
The teaching staff will only grade this project after no more submissions can be made (i.e., after the late submission window is closed).
Getting help
Please use EdStem and office hours! For EdStem, make sure to set your posts to private if you’re sharing code. We also have a planned project workday before this project is due, check the course schedule.
Hints
Creating a buffer
Since the max string size is 127, you can allocate 127 bytes for input with:
buffer: .space 127, 0 // creates 127 bytes with value 0
Reading a single byte
You can use the read syscall (which is #63 in ARM64 - Linux) to read things into your program.
STDIN is 0 for the file descriptor, the buffer should be able to hold at least one byte, and count should be 1 since you only want one byte.
Reading more bytes
Same as the hint above, but your count should be however many bytes you want to read and your buffer should be able to store that.
Writing bytes
You can use the write syscall (which is #64 in ARM64 - Linux) to write things from your program.
STDOUT is 1 for the file descriptor, the buffer should have the values you want to write (does not have to be null-terminated), and count should be the number of bytes you want to write.
Creating result string
A couple of ideas: (i) it might be easier to have more than one buffer instead of doing this in-place; (ii) you can output one byte at a time.
Conditional increment
ARM64 has a conditional increment (cinc) instruction that could be useful.
Compare and branch
ARM64 has check == zero and branch (cbz) and check != 0 and branch (cbnz) instructions that could be helpful.
Sample Input/Output for Debugging
The following examples have different things we check on the test cases. They also all have only printable characters, so you can copy-paste them into the WebAssembliss editor (without the quotes).
They all start with ! (ASCII value of 33), meaning they all have 33 bytes to process after the !.
You can use this same logic to create more sample I/O to debug your code by using any printable character to begin your input.
- No spaces
- Input:
"!ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567” - Output:
“ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567”
- Single Spaces
- Input:
"!AB CD EF GHI JKLMN OPQRS TUV WXYZ” - Output:
“AB CD EF GHI JKLMN OPQRS TUV WXYZ”
- Consecutive Spaces
- Input:
"!AB CD EF GHI JKLMN O" - Output:
“AB CD EF GHI JKLMN O”
- Trailing Spaces
- Input:
"!ABC DEF GHI JKLMN " - Output:
“ABC DEF GHI JKLMN "
- Leading Spaces
- Input:
”! ABC DEF GHI JKLMN" - Output:
" ABC DEF GHI JKLMN"
- Trailing and Leading Spaces
- Input:
"! ABC DEF GHI JKLMN " - Output:
" ABC DEF GHI JKLMN "