CITS2002 Systems Programming  
 

Unit home

Project 1

help2002

Lecture & Workshop
recordings on LMS

Schedule

FAQ

Unit outline

C textbooks

OS textbooks

Information resources


Extra reading

Past projects

Recent feedback


Working effectively

Look after yourself!

CITS2002 Systems Programming - Project 1 Feedback (2021)

Q11: Any comments or suggestions about the nature of the project?

  • cool project. great to see systems content in the project instead of it being a basic c programming project, really helped me understand why stacks are used and how buffer overflow attacks work
    Thanks; since 2018 we've increased the systems' content of the 1st project as we've increasingly encouraged more programming as Advisable Prior Study (from 2022, there'll be prerequisites). See the list of past projects.
  • This project was very enjoyable, and helped solidify the systems programming concepts.
  • The project outline could have been explained better. The outline had a round about way of explaining 'what to do'. It was difficult to interpret what exactly to do after reading the outline. The project was a great way for students to understand more about the computers. It was challenging which helped the students learn better.
    Yes, things can always be explained better, but different students will always have different levels of comprehension - that's why we have a Clarifications page and a help forum, as it'll never be perfect for all.
  • The project was fairly interesting but I didn't exactly see the relevance to the actual course outside of the fact that we were simulating computer hardware (which is obviously part of a computer system). I personally would've expected something more to do with system calls and operating systems.

    I personally thought the project wasn't particularly difficult or ambitious, though I had experience programming C++ before and so I didn't find programming in C particularly difficult. I can imagine that some other people did, though - to split the instructions into their own functions, I had to use pointers to pass the stack pointer, etc. by reference, and pointers weren't introduced at that point in the unit.

    In my opinion, the most difficult aspects of the project were attempting to reverse-engineer or understand some of the more poorly-specified aspects of the specification. More complex operations like call and return weren't defined completely clearly, which required some testing on my part. prints was probably the most difficult instruction to implement, given that we had to reverse-engineer the representation of the string - two 8-bit characters merged into a 16-bit "word" - and extract the characters from this. Producing the same cache performance was also somewhat difficult and required lots of trial and error.

    Most of the reverse-engineering ended up not being required, as someone asked the same question on help2002 and Chris mostly clarified it.

    Otherwise, my only other comment on the project is that it felt very "unsafe" to write it. Instead of using best practices like typedefs to define the "word" types, macros were used. We were also expected to convert between technically non-equivalent types like int16_t and uint16_t without casting, as well as mixing them indiscriminately with int. The solution for prints is, I believe, architecture-specific to little-endian systems only, with no way to get a general solution without complicated endian-detecting hackery. There was also possibly an issue for the frame pointer offset - it could be negative, but since addresses are 16 unsigned bits, there could be overflow if it tried to represent a number small enough.

    I also wasn't really sure what the purpose of the cool language was - before I looked at the project properly, I thought that it would be writing a compiler for cool because of how much it seemed to be emphasised. While the cool language admittedly was useful in reverse-engineering the behaviour of the sample solution, just providing us with the assembler would probably still be sufficient for the project.
    Thanks for your detailed comment. It's clear that you would have benefited from your past C++ experience but, as you'll see from this feedback, about half our cohort found it difficult to impossible. Knowledge of pointers wasn't required for this 1st project, by design, but will be essential for the 2nd project. Reverse-engineering was never a factor for this project.

  • The project was very difficult, I was okay with it, but looking at other people struggle with it or not being able to comprehend the project description on the CITS page made it look like the project wasn't easy. The unit page was very concise, but I think it was too concise, almost this whole unit so far just relied on "assumed knowledge", stuff wasn't explained in great depth and people seemed to struggle to understand the concepts.

    I don't know if the problems lie with the students or the teaching, but I have talked to people from previous years and almost all of them (the ones that were kind of new to programming) said it was a very hard unit.

    For people that have had coding experience before and have done more than one language or multiple projects, it's not too difficult for them, but this unit only had a prereq of one programming unit and for some, they started programming in the first sem of uni.

    It is hard to teach programming, or actually teach how the computer works because there aren't great analogies, but what I found useful while helping other peers that were stuck on understanding something was, trying to not use too much jargon, while it's great to know the jargon for future references it's not helpful to start knowing them from the get-go. Instead of complex diagrams, a simplistic diagram with step-by-step procedures and less jargon or abbreviations (software engineers seem to just love abbreviations) would be more beneficial for a student learning, the jargon can come in later. It's the student's job to make sure they do the in-depth reading to understand the names, it's the professor's job to make sure the students understand.

    The help2002 was really great, loved the collaborations and people helping each other out, but again the same problems, people read the help2002 but didn't quite get it because complex things were explained with more of the jargon - which gets confusing, and the student doesn't want to start a new thread on the same topic (unless they are desperate) or ask for clarity on the whole thing because they will look dumb, or be told to read it again.

    The lectures were okay, it felt like all the lecturer did was just read off the lecture sheet and called it a day. So a few people including myself just stopped attending the lectures and read off the lecture sheets ourselves. The purpose of the lecture sheet is so that the students can go over it again and take notes or strengthen their understanding, but if you read a new topic for the first time straight off the lecture sheets to the students without breaking the bits down or elaborating then there is no point because everyone knows how to read.

    But overall, in my opinion, I found the first project quite interesting, it was cool to understand how the computer works. The student community is great and very helpful. But I believe my prior programming knowledge definitely helped me out, and understanding the project page was okay because it matched the way I like to retain or read information.
    Thanks for your extensive comment. I appreciate that many students find this unit and its projects difficult (every year), but I don't have great concerns about that. Personally, I'm more motivated by projects being interesting (which makes them easier), and whether much is learnt in completing them. As you'll see from this feedback, a roughly equal number of students found it as easy as others found it difficult. Somewhere in degree of 24+ units you'll hit unit(s) that are difficult to you, but not to others, and vice-versa in other units. Difficulty is not, itself, a bad thing. And if you do come across terms that you feel are just jargon, it's really your responsibility to investigate them or clarify their meaning.

  • Was really hard to get my head around what was being asked of me at first but after the workshop explaining the project and spending a good amount of time analysing the task page, the project became fairly reasonable to complete.
  • It took about a week for me and my partner to figure out what the project actually wanted us to do. Clearer instructions would be nice :3 !
  • The project itself was amazingly fascinating and extremely interesting that made me completely abandon and forget about my other 3 units for one whole week. It pushed me beyond my limits like never before and taught me so many things about memory, the relationship between OS and hardware, and just programming in general.

    However, I do definitely recommend one thing, the project (especially the "FIRST" project) has to be much more related and doable than this project (because this project was seriously difficult, although interesting), because we only learn 4 weeks of material which would barely prepare us enough for tackling such a level of difficulty, and then you might decide to give us a littler harder second project with 4 weeks (instead of 3 weeks) to complete, that would prepare us in a much better way for both projects and the unit as well in general. Also, in my humble opinion, I really think that this project wasn't that much related to what we have learnt in the first 4 weeks (except workshop 4), as 70% of my self-teaching about this project came from watching several youtube videos, reading a LOT from textbook and online sources and maybe only 10% from first 4 weeks' materials and 20% from workshop 4.

    But apart from that, it was a fantastic project.

  • The project covered an important topic and was interesting. I learned a lot about the workings of main memory, CPU registers and the basics of memory caching. However the brief while providing lots of background information, was very sparse in what was actually expected for the assignment.
  • Project took a lot of time initially to understand, not solely due to the concepts but what the project wanted us to do. A lot of group discussion was needed.

    The workshop using the starting code was really useful when getting started

  • After finishing the project, it feels like 'all the dots finally connected together'.

    I think starting the project was extremely difficult for someone that is a beginner programmer. I felt that the aim of it was difficult to understand, and it felt like the topic of caches/memory was only lightly covered in lectures (comparing to how much we needed to know for the project).

    The coding part was fairly simple, however I feel that you really needed a lot of background knowledge to even begin the project. I understand that this is a "2nd level unit" but the jump from 1st year projects to this is a little too much.

    Once you start getting the hang of it, its an interesting project but it was really difficult to wrap my head around what was being asked and how to execute it. Most of the lab facilitators were helpful though, especially the Thursday labs (super super helpful!).

  • I enjoyed the project - I liked that we weren't immediately given all the answers and that some independent learning/investigation was required. It was very satisfying when I got important parts of the program working, and definitely deepened my understanding of operating systems and programming as a whole.
    Glad that you enjoyed the opportunity for some independent learning, and believe that you learnt a lot from it.
  • Even though the workshop 4 was related to the project it wasn't as helpful as having the labs and asking specific questions on particular sections. I found that I understood most of the project and the requirements, but over the study week, I would work on the project at the start, but after a few hours I was permanently stuck on a simple issue which required a lot more time for me to complete
  • This workshop was actually very fun and interesting, I procrastinated doing other units' projects & assignments with this one.
  • I understand that the project is not based exactly on the "week1-4 content" but some more lectures (perhaps 1 more) on memory (like week3 lecture 1) would've been a more subtle introduction of whats to come.
  • It requires a very deep understanding of the unit material. You need to do extra research to understand the project.
    Agreed; that's a primary motivation for setting projects.


Q12: Do you have suggestions/comments to assist the planning of the 1st CITS2002 project for next year?

  • Perhaps adding some resources to help students with debugging larger programs.
  • It would have been better if the students were taught more about the computer itself before the project was handed out. I am aware that we had lectures about the computer but the lecture mostly discusses the history of how computers came about and it was very low level (talked about complex material). I would have preferred if there was a very basic explanation about how computers worked (as I am doing this unit as a first year).
    One of the primary goals of the project was to expose you to some of how a computer works, as there's so little space in our degree/major structure for this (current 'hot-topics' grab all the limelight). That said, I'm frequently surprised that many students undertaking a computing-focused degree don't have the curiosity to investigate the basic workings of a computer's hardware and CPU outside of their formal studies.
  • I think that the project next year should be more difficult and probably make more use of systems programming core concepts. I also think that while the specification should be made more explicit and unambiguous, the reverse engineering aspect of the project should be emphasised more, and so less help on edge cases should be given.
    Please read through other students' comments, and you'll see that half the class found the project sufficiently difficult. I'm comfortable with it being half. It's very difficult to get that balance right. Also, there was no reverse-engineering aspect to this project.
  • I feel like the project was made haphazardly. New information and updates kept coming throughout the project. I would say the project should be planned much earlier on, and the facilitators or coordinators should definitely keep proofreading it, or have someone in the department (someone who didn't take any part in making the project) attempt the project from the draft, and see how they comprehend it, and fix errors if any arise from the draft (maybe repeat this to make sure you aren't missing anything?) Because when you are making something, it makes sense to you because you made it, but it might not be fully clear to others.
  • Not really, perhaps emphasise that not EVERYTHING in the project will be fully covered in the lectures, and so directly tell people they will have to research some stuff themselves (like caches in this project).
    By second year, I believe that students should know that a core role of projects is not simply to reiterate lecture material, to earn marks, but to learn and demonstrate their understanding of new material. It's unclear to me where this important message is being lost.
  • (assuming a similar project in the future) I think more attention could be given to the nature of some of the concepts required for the project. While the actual coding was relatively simple, some more focused resources could have been very helpful so wading through a sea of information would be more like a lake. There is a lot of information out there on caching and it was hard to figure out exactly what was expected as we were only emulating cache, rather than actually implementing it. I will end with this; While there was a lot of stress in the beginning, once everything clicked the experience was very rewarding in terms of learning.
  • I hope that the projects are easier to understand and the aims are more clear.

    Also, I feel that lectures or workshops should relate more to the topics of the project or vice versa.
    The knowledge required to successfully complete a project doesn't all all have to be presented through in-class sessions. Projects can require you to learn and demonstrate an understanding of new material, too.

  • I think the project was well structured, with two major milestones (working instructions with matching reads/writes, and cache implementation). Definitely a step up in difficulty from 1st year units but I enjoyed the focus on independently designing a solution to a programming problem rather than just blindly typing code.

    More face to face meetings with lab coordinators in order to solve small complications

  • The project is designed to introduce us to how computers work emphasizing the stack and cache. The lectures IMO provide an OK description of the coding required (in terms of syntax etc) but even with the skeleton code, the project is not straightforward but still manageable. The cache portion however required you to understand the functionality of it online (other websites etc) as it was quite vaguely and poorly described on the project description. Im not sure if this was intended but due to this many students were unsure of the cache implementation and how to get started or get it working. Also, a lot of previous knowledge was assumed (even though it states that no prereq) in this unit with the lecturer mentioning content from the Data structures and java units a couple of times.
    It would be interesting to hear what previous knowledge was assumed for this project, other than introductory programming experience gained through completing any of the Advisable Prior Studies units.
  • I was confused, along with others, about the significance of matching the program statistics of the sample solution exactly. The fact that the assessment outline said 50% of the marks came from automatic marking that was looking for the statistics to match exactly fed into this. If this was adjusted so that the automatic marking was checking if certain benchmarks were matched or exceeded, I would commend the project as a whole.
    The project outline never said that your numeric outputs had to match the sample solution exactly, and the Clarifications re-iterated this.
  • i think that the lecutres should try to teach more complex things about the language as i was looking back at lecutres for little tips to try and complete what i needed to and was struggling to find anything rly advanced

    It was a very huge topic to handle. I would like to get more direct and intuitive projects.
    It would be interesting to hear what more advanced language features you felt were required for this 1st project. As you can see from the sample solution, all required C11 features were presented by the time the project was released (end of Week-4). Given the breadth of students' backgrounds and interests, it would also be interesting to hear what a more intuitive project would involve.

  • I feel this project could have been a little harder, though I haven't talked to other students to see how they did.


The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Presented by [email protected]