Reference no: EM133051734
55-701163 Digital electronic design - Sheffield Hallam University
Design Assignment
Learning outcome 1: Examine the competitive nature of electronic system procurement and implementation;
Learning outcome 2: Design at appropriate level digital electronic systems;
Learning outcome 3: Debate the relevant technical and economic factors that influence a digital systems design procedure;
Learning outcome 4: Evaluate the selection of hardware description languages and implementation methods;
Learning outcome 5: Critically analyse and compare system specifications;
Background
Low-level machine programs are rarely written by humans. Typically, they are generated by compilers. Yet humans can inspect the translated code and learn important lessons about how to write their high-level programs better, in a way that avoids low-level pitfalls and exploits the underlying hardware better. One of the key players in this translation process is the assembler - a program designed to translate code written in a symbolic machine language into code written in binary machine language.
This project marks an exciting landmark in our Nand to Tetris odyssey: it deals with building the first rung up the software hierarchy, which will eventually end up in the construction of a compiler for a Java-like high-level language. But, first things first.
Objective
Write an Assembler program in Matlab that translates programs written in the symbolic Hack assembly language into binary code that can execute on the Hack hardware platform built in the previous projects.
Contract
There are three ways to describe the desired behavior of your assembler: (i) When loaded into your assembler, a Prog.asm file containing a valid Hack as- sembly language program should be translated into the correct Hack binary code and stored in a Prog.hack file. (ii) The output produced by your assembler must be identical to the output produced by the Assembler supplied with the Nand2Tetris Software Suite. (iii) Your assembler must implement the transla- tion specification given in Chapter 6, Section 2.
Usage
The Matlab assemble program should be invoked using something like "Assem- bler fileName.asm", where the string fileName.asm is the assembler's input, i.e. the name of a text file containing Hack assembly commands. The assembler creates an output text file named fileName.hack. Each line in the output file consists of sixteen 0 and 1 characters. The output file is stored in the same directory of the input file. The name of the input file may contain a file path.
Resources
The relevant reading for this project is Chapter 6. Your assembler implemen- tation should be written in Matlab programming language. Two useful tools are the supplied Assembler and the supplied CPU Emulator, both available in your tools directory. These tools allow experimenting with a working assembler before setting out to build one yourself. In addition, the supplied assembler pro- vides a visual line-level translation GUI, and allows code comparisons with the outputs that your assembler will generate. For more information about these capabilities, refer to the supplied Assembler Tutorial (PPT, PDF)
Proposed Implementation
Chapter 6 includes a proposed, language-independent Assembler API, which can serve as your implementation's blueprint. We suggest building the assembler in two stages. First, write a basic assembler designed to translate assembly pro- grams that contain no symbols. Next, extend your basic assembler with symbol handling capabilities, yielding the final assembler. The test programs that we supply below are designed to support this staged implementation strategy.
Test Programs
Each test program except the first one comes in two versions: Prog.asm is an assembly program; ProgL.asm is the very same program, Less the symbols (each symbol is replaced with an explicit memory address).
Tools
The supplied Hack Assembler shown below is guaranteed to generate correct binary code. This guaranteed performance can be used to test if another as- sembler, say the one written by you, also generates correct code.
Report
The report document should not exceed 3000 10% words. The style guide, provided at the end of this lab sheet, should be used. The following outline can be used to structure the text:
Abstract
What did you do? How did you do it? What did you learn?
Need definition
Why do we need an assembler?
Thesis
Why did you select a specific language? Background
What is the latest in assembler research?
Methods
What design method did you follow? How did you structure your code?
Discussion
Why is your code elegant? Why is your code clear?
What are the drawbacks of the proposed method? What are the limitations of your adopted method?
Conclusion What are the take home points?
IEEE style references
Attachment:- Digital electronic design.rar