Grading Requirements

The assessment has three components: the two programming tasks, and the final exam.  The final mark for the unit will be calculated by combining the marks for all assessment tasks according to the percentage weightings shown in the assessment summary.

Requirements to Pass this Unit

To pass this unit you must:

• Achieve a total mark equal to or greater than 50%
• There is no other hurdle requirement

Programming Tasks (Labs)

Throughout the semester you will engage in two programming tasks that are assessed individual work. These tasks develop your skills and assess your progress. These programming tasks are to be done in your own time, but you may also use workshop time to work on them and to seek assistance from the teaching staff.  They are due as specified on iLearn for each task. 

The programming tasks are designed to be completed over several weeks.  Do not leave them until the last week.  

Release Dates

Programming Task 1 will be released no later than 1 August (Friday of Week 1).

Programming Task 2 will be released no later than 12 September (Friday of Week 7).

Programming Tasks are Individual Work

The programming tasks are set as individual work and each one is personalised for a particular student. 

The University's academic honesty policy will be enforced. You may assist your fellow students with general concepts, pointers to resources and useful tools or commands that are publicly available. You may not become involved in any way in helping a fellow student to find the solution to their particular task, nor may you share with them any aspect of the solution of your particular task. If you decide to develop or modify a tool (including software tools, procedures or methods) to assist you in solving your programming task, you may not provide that tool to your fellow students, nor may you publish it.  Each practical task will include additional specific instructions to help you understand what is acceptable and what is not.

Each programming task must be the sole work of the student turning it in. Any cheating will be handled under the University's Academic Honesty Policy.

The following are guidelines on what collaboration is allowed for programming tasks and what is not [adapted from CS:APP website]

What is Cheating?

• Sharing code or other electronic files: either by copying, retyping, looking at, or supplying a copy of a file from this or a previous semester. Be sure to store your work in protected directories, and log off when you leave any lab computer, to prevent others from copying your work without your explicit assistance.  Don't use a public repository (such as github) for your programming task files.
• Sharing solutions, quizzes or exams: Looking at, copying, or supplying a programming task solution, quiz or exam.
• Sharing procedures, methods or tools that have been developed to solve challenges of a programming task. If you wish, you may develop your own procedures, methods or tools to assist you in the tasks, but you may not share them with others, publish them or store them in a public repository such as github.  If you find someone else's procedures, methods or tools, you may not use them -- if in doubt, ask the teaching staff of your registered class or the unit convenor.  For example, you may not provide or use somebody else's sequence of steps that can be followed to solve (or partially solve) a programming task. Similarly, you may not provide or use somebody else's program that is designed to solve (or partially solve) a stage of a programming task.
• Using other's code: Using code that you did not write yourself. You may not use code from courses at other institutions, or from any other non-COMP2100 source (e.g., software found on the Internet, such as ChatGPT).  You may, however, use the Internet and other sources to learn useful concepts, ideas, and programming idioms.  If you find helpful ideas on the Internet or in other sources, you should acknowledge them in comments in your code.  For Internet sources, a URL is sufficient acknowledgement.
• Looking at other's code. Although mentioned above, it bears repeating. Looking at other students' code or allowing others to look at yours is cheating. There is no notion of looking ''too much,'' since no looking is allowed at all.

What is NOT Cheating?

• Clarifying ambiguities or vague points in class handouts or textbooks.
• Helping others use the computer systems, networks, compilers, debuggers, profilers, or other system facilities.
• Helping others with high-level design issues.
• Helping others with high-level (not code-based) debugging techniques.
• Using code from the CS:APP website or from the COMP2100 iLearn pages.
• Learning programming idioms and techniques from examples.
• Reading Unix manual pages, forums, etc in order to find out how to perform particular tasks (e.g. set a breakpoint in a debugger) or use programming language/library features (such as printf).
• Asking for help from the practical demonstrator, teaching staff or lecturer.  You may also seek help from the School of Computing's Drop-In Centre.

Be sure to store your work in protected directories, and log off when you leave any lab computer, to prevent others from copying your work without your explicit assistance.

Programming Task Submissions

Submission instructions for programming tasks will be provided on iLearn. The two tasks contain differing forms of automatic assessment and feedback tools that will assist you during the task.  The automated feedback will help you identify your mistakes, but does not replace your own analysis of the problem, debugging and testing.  The automated assessment contributes strongly to our understanding of your performance in the task. 

Each programming task will specify a particular due date. The due time will be 11:55pm on the due date unless otherwise specified.

Late submissions

Submissions in Data File Lab are made through the lab command;  submissions in Binary Bomb Lab are made automatically as you progress through the task of analysing and executing the "binary bomb" program.

Special Consideration

If you experience serious and unavoidable difficulties that affect your ability to meet the due dates for progress or the closing date of a programming task, you may apply for special consideration as explained at https://students.mq.edu.au/study/my-study-program/special-consideration. If the request is accepted, the action may be to grant an extension of the relevant due date(s), or it may be to require you to submit an alternative assessment item.  Extensions, if granted, are managed through the automated assessment system that you access via the lab command. 

If you apply for special consideration, please note:

• Apply promptly.  Late applications may make it impossible to sensibly offer an extension, and you may risk having to complete a different assessment task which would mean starting from scratch.  For example, if you are ill for two days just before the due date, an extension of two days would be reasonable, but that extension cannot be granted more than two days after the due date since the extension end date would have already passed!
• Contact your TA, the senior TA or lecturers if you have questions about extensions.

Late Assessment Policy

For any late submission of time-sensitive tasks, such as scheduled tests/exams, performance assessments/presentations, and/or scheduled practical assessments/labs, students need to submit an application for Special Consideration.

Our Late policy is summarized below.

Assessments where Late Submissions will be accepted 

In this unit, late submissions will be accepted as follows: 

• Labs - NO, unless Special Consideration is Granted (after the free three extension days as previously described in the section on Programming Task Submissions
• Exams - NO, unless Special Consideration is Granted

Assessment Tasks

Name	Weighting		Due
Final Examination	40%		In exam period
Data File Lab	30%		Sun 7 September 23:55
Binary Bomb Lab	30%		Sun 2 November 23:55

Final Examination

Assessment Type ¹: Examination Indicative Time on Task ²: 26 hours. Due: In exam period. Weighting: 40%

Online examination

On successful completion you will be able to:

• Use a command line interface to control the computer.
• Produce code that utilises system software to provide controlled access to system resources.
• Analyze machine representations of data, such as integer and floating point.
• Analyze assembly code fragments.  Trace execution and re-express with higher level descriptions.
• Identify security flaws that can arise from program execution.
• Explain how the hardware impacts on software performance and how software can interact directly with the hardware.

Data File Lab

Assessment Type ¹: Programming Task. Indicative Time on Task ²: 30 hours. Due date: see table. Weighting: 30%.

Develop C programs to manipulate data files.

On successful completion you will be able to:

• Use a command line interface to control the computer.
• Produce code that utilises system software to provide controlled access to system resources.
• Analyze machine representations of data, such as integer and floating point.

Binary Bomb Lab

Assessment Type ¹: Programming Task. Indicative Time on Task ²: 30 hours. Due date: see table. Weighting: 30%.  

Use debugging tools to understand the behaviour of a precompiled program. Find input strings that will be acceptable to the program (i.e. defuse the binary bomb). 

On successful completion you will be able to:

• Use a command line interface to control the computer.
• Analyze machine representations of data, such as integer and floating point.
• Analyze assembly code fragments.  Trace execution and re-express with higher level descriptions.
• Identify security flaws that can arise from program execution.

¹ If you need help with your assignment, please contact:

• the academic teaching staff in your unit for guidance in understanding or completing this type of assessment
• the Writing Centre for academic skills support.

² Indicative time-on-task is an estimate of the time required for completion of the assessment task and is subject to individual variation

Week One

We introduce the class, go over the unit guide, and begin delivering technical content in the lecture and workshops. Workshops start in Week 1.

Text Book

"Computer Systems: A Programmer's Perspective" 3rd edition, R.E. Bryant and D.R. O'Hallaron, Pearson 2015.

You are required to read set sections of the text book each week.  The text book is available in electronic form in the library, or you can purchase a printed copy from a book seller of your choice.

Recommended Text

"The C Programming Language" 2nd edition, Brian W Kernighan and Dennis M Ritchie, Prentice-Hall 1988.

This small book is the classic reference on C programming.

iLearn Web Site

All learning materials will be published on iLearn including lecture slides, programming tasks and other explanatory documentation.  We will also be making key announcements via iLearn as well as answer questions in the unit's Forum.

Lectures

Lectures are a core learning experience where we will discuss the theoretical underpinnings and concepts that are essential to this unit. Key ideas for the programming tasks will be discussed from time to time in lectures. 

Lectures will be provided in person.  Participation in lectures is not required but is highly recommended. Lecture recordings will be provided on echo360.

Workshops

Each week it is important to attend your workshop.  We will be using the workshop to cover important concepts that may be useful to solving weekly questions, programming/lab issues, and/or exam questions.  Workshops also provide an opportunity to discuss specific questions related to any aspect of the unit: the lecture content, the programming tasks and the set practical questions.

Workshops provide an opportunity for you to develop your skills in systems programming and your understanding of the key concepts of the unit. Workshops combine discussion with practical programming experience.  Your workshop teaching staff will provide you with individual assistance and may also from time to time address the entire class to provide useful information to assist with programming tasks.

Unit Forum

A forum for unit discussions is provided on iLearn. Students are free to post questions, comments or hints in relation to any aspect of the unit, except that you should avoid posting any questions, hints, comments or solutions that could be interpreted as cheating (see above). Civility is essential in all such postings and interactions.

Don't post your code, or anyone else's code, on the forums!

If you see a post from another student that appears to be cheating, please email the senior TA (to be specified on iLearn), and we will remove the offending post.

General Communication and Contact

Apart from contacting teaching staff in-person before/after the lecture and/or workshops, and at a pre-arranged time, the main way of communication is via the iLearn forums. For general administrative questions relating to the unit, personal queries, etc. please email the lecturers and the Senior TA for the unit. Clearly identify in the title of your email "COMP 2100: ". 

For specific technical questions, first contact your TA, use the Unit Forum and/or use either the announced weekly consultations time for the Senior TA in COMP2100, or the School of Computing's Drop-In Centre.  If your technical question still cannot be resolved, email the convenor.

The detailed unit schedule will be available on iLearn. The unit is roughly organised as follows:

Week 1-6: C programming, Command line interface, Data representations (integer and float), some system API.

Weeks 7-12: Assembly code and how C programs appear in the machine, Operating System features and implementation.

Changes from the prior offering include the following:

• Remove mid-semester exam

• Remove Lab assignment 2's assembly language Mastery Quiz

• Create cumulative Final exam

• Remove progress marks from lab assignments 1 and 2

• Add Lab 2 viva

• Remove weekly quizzes

• Reduce the number of free extensions for labs

• Remove hurdle requirement based on two labs