IT IS in the file submitted
comp5570-assign3 COMP5570 Assignment 3 Writing an Assembler Copyright 2021 David J. Barnes Version 2021.12.04.08:00 You may notify me of errors or seek clarifications either via the anonymous question asking page now available from the Assessments section on the Moodle page, or via email to
[email protected] Introduction This assignment is designed to provide you with a practical understanding of the task of writing an assembler. Date set: 22nd November 2021. Date due: 13th December 2021. Deadline 23:55. You will write an assembler for a low-level language called Shack (Simplified Hack). Shack is a language designed by me for this particular assessment so you should not expect to find any additional information about it elsewhere on the Web/Internet. This document is the definitive definition/description of Shack. Shack offers a way to write programs for the Hack architecture in a form that is slightly higher level than Hack assembly code. In other words, each instruction in Shack will often map to more than one Hack instruction. This makes it slightly easier to write commonly occurring operations. Rather than outputting Hack binary, your assembler will output equivalent Hack assembler code which you can then run on the Hack CPU Emulator if you wish. You may ask questions about this assessment via email to
[email protected] or via the COMP 5570 anonymous question asking page, a link to which may be found in the Assessments section on the module’s Moodle page. The sections below describe the Shack language, the equivalent Hack instructions, and the requirements of the assembler you must write. It is possible that corrections might need to be made from time to time to this assessment, so please keep an eye on the Version date at the top of this page to ensure that you have the latest version. Outline requirements • You must submit the source files of a program that translates from Shack assembler to Hack assembler. The submission will be via an Upload area in the Assessments section of the module’s Moodle page. • It must be possible to run your program from the command line on raptor. Ferrae Thompson Ferrae Thompson Ferrae Thompson Ferrae Thompson • Your program must take a single command-line argument which is the name of the Shack source file to be translated. • The assembler must only accept source files with a ‘.shk’ file suffix. • The assembler must write the translated Hack version to a file whose name has the same prefix as the Shack source file but a ‘.asm’ suffix. The file written to must be in the same directory/folder as the Shack source file. • You may implement the program in a language of your choice under the constraints that the language must be available to the marker on raptor and it must be possible for the marker both to compile (where required by the language) and execute your code without having to install a particular IDE or any other software, such as libraries or build tools. These constraints are important. Any libraries required must either be bundled with your submission or already pre-installed and accessible to the marker. • It is essential that your submission includes sufficiently detailed instructions to allow the marker to run your programs, particularly if it is written in a language other than Java. Further details of what this will mean in practice will be provided before the deadline. Plagiarism and Duplication of Material The work you submit must be your own. We will run checks on all submitted work in an effort to identify possible plagiarism or other academic misconduct, and take disciplinary action against anyone found to have broken the University’s rules on academic integrity. You are also reminded that seeking assistance from external ‘homework’ sites is not permitted and might constitute ‘contract cheating’ which is forbidden by the University. Some guidelines on avoiding plagiarism: • One of the most common reasons for programming plagiarism is leaving work until the last minute. Avoid this by making sure that you know what you have to do (that is not necessarily the same as how to do it) as soon as an assessment is set. Then decide what you will need to do in order to complete the assignment. This will typically involve doing some background reading and programming practice. If in doubt about what is required, ask a member of the course team. • Another common reason is working too closely with one or more other students on the course. Do not program together with someone else, by which I mean do not work together at a single PC, or side by side, typing in more or less the same code. By all means discuss parts of an assignment, but do not thereby end up submitting the same code. • It is not acceptable to submit code that differs only in the comments and variable names, for instance. It is very easy for us to detect when this has been done and we will check for it. • Never let someone else have a copy of your code, no matter how desperate they are. Always advise someone in this position to seek help from their class supervisor or lecturer. Otherwise, they will never properly learn for themselves. • It is not acceptable to post assignments on sites such as Chegg, Freelancer, etc. and we treat such actions as evidence of attempted plagiarism, regardless of whether or not work is paid for. Ferrae Thompson Ferrae Thompson Further advice on plagiarism and collaboration is also available. We reserve the right to apply checks to programs submitted for assignment in order to guard against plagiarism and to use programs submitted to test and refine our plagiarism detection methods both during the course and in the future. Ferrae Thompson The Shack language: lexical and syntactic conventions Shack programs are stored in files with a ‘.shk’ suffix. The assembler must translate a single .shk file on each run. Any additional arguments must be ignored. Comments: As in both Java and Hack, text beginning with two forward-slash character (//) up to the end of the line on which it occurs is a human-readable comment and requires no translation. Comments are ignored by the assembler. Whitespace: Blank lines are ignored by the assembler. Each Shack instruction must be written on a single line. Unlike in Hack, whitespace is used to separate an instruction mnemonic from its operands. Except where restricted below, additional whitespace may be used anywhere within a line, for instance to indent instructions or enhance readability. Numeric constants: Numeric constants must be positive integer values, written in decimal notation, in the range 0-32767. Labels: Labels are used as symbolic names for memory addresses. They consist of 1 or more alphabetic, numeric and underscore characters starting with an alphabetic character. Shack distinguishes between labels for ROM instruction addresses and those for RAM data addresses. All labels for RAM data addresses must be ‘declared’ in advance in a ‘data section’ that appears before the instructions which appear in a ‘code section’ (further details below). ROM labels are ’declared’ by using them to label the following instruction. A label may not be used for a ROM address if it has been declared in the data section as a RAM label. A label that matches a Shack instruction name (opcode) must not be used. Instruction mnemonics: All instruction mnemonics are either 3 or 4 case-sensitive alphabetic characters long, entirely in upper-case. The Shack language: declarations and instructions A Shack source file has two parts: a declaration section, for listing the names of RAM labels, and a code section. The RAM labels in the declaration section would be translated as variables in the Hack version. These names would ultimately be turned into sequential addresses starting at 16 in the Hack binary version but the Shack assembler does not translate them into their numeric equivalents. Note that ‘translation’ of the .dec section does not directly result in any code being generated because Hack variables are not declared. The following short example shows both sections and how they are introduced in a Shack source file: .dec sum x y .code LOAD D x ADDD y STO D sum The RAM declarations are introduced by the symbol ‘.dec’ which must be on a line by itself. If there are no declarations then the declaration section may be completed omitted. If present, there must be zero or more names for RAM locations, each on its own line. The instructions are introduced by the symbol ‘.code’ which must be on a line by itself. If there are no instructions then the code section may be completed omitted. If present, there must be zero or more instructions, each on a separate line. The Shack language: instruction labels Instruction labels may only appear in the code section. A label must be followed by a colon character, without any separating spaces. The label name does not include the colon symbol. A label must appear on a line by itself but multiple labels, on successive lines, may be used to label the same instruction. For instance: start: loop: LOAD D x ADDD y STO D sum JMP loop It is not permitted for an instruction label to be the same as a RAM label. The Shack language: instructions This section describes the instructions available in the Shack language and their translations into equivalent Hack assembly code. Please note the following definitions of operands which are used in the desriptions: • An ‘addr’ operand refers to a RAM address and ‘addr’ may be either a number (such as 2476) or a variable label (such as sum). An addr operand is always translated as a reference