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.
