CS 3060 Semester Project Fall 2011 Phase 1: Requirements Analysis

Irving Rynning Wednesday, 12th Oct 2011

0.

1.
2. 3. 4. 5.

Introduction. Requirements. Specifications Acceptance Criteria. Feasibility Report. Conclusions.

0. Introduction. This document offers the reader what to expect for the project, a simple assembler for a hypothetical central processor written in C++ and free libraries, and any constraints noted to date. 1. Requirements. The program shall be capable reading an input string, either from file or keyboard, and converting it to an machine code. An option is to read an entire file, assemble it, and load it at a user given address. The optional emulator offers the user a real-time experience, though there are no LEDs to indicate PC and register contents, or memory access or the output of the arithmetic unit before it is gated into a register, I will offer a run experience thru output on the display of such information. It will require quick eyes, but the output will be suitably delayed so the viewer can see the events. There will be jump instructions, and a return to the address successive to where the jump occurred. The usual stack operations shall not implemented in jump instructions, only a simple alteration of the program counter. The programmer must store the registers himself in the first part of the subroutine as required for a return. as there may be only two registers, this should not prove too difficult. 2. Specifications. I will use the Bloodshed environment, on a Windows 7 machine. A standard 101 key unit shall suffice. A file specification is needed, with fields to be defined for the assembly code. A MACRO option may be implemented, allowing user defined macros to be substituted inline, to use the C++ term. 3. Acceptance Criteria. Accuracy is measured by direct comparison; an option of a CPU emulator may be implemented, so that a sample program of memory moves, arithmetic & logical operations, conditional jumps, and even I/O happens with the operations being displayed thru judicious use of characters and time delays. 4. Feasibility Report. One is bounded by the imagination here perhaps only a dozen instructions may be implemented, somewhat freely plagiarized from the 8080 processor, which had more than 100. The emulator may be the hardest part, offering the user a real-time experience, except there are no LEDs to indicate PC and register contents, or memory access or the output of the arithmetic unit. In the loader one may discover the pitfalls; this is not a mere substitution happening, but the result must be manipulated, address operands altered, and jump instructions may be the hardest part. The usual stack operations may be explicitly performed, as there will be only two registers. 5. Conclusions This idea was dreamt in a basic ANSI C class just last year; I have not to date acquired my MIDI expertise with timing and I/O, so this shall substitute. My familiarity, though dated, with third generation hardwarethe 7400 series of logic circuits and processors built with such ICs, suggested this . I have no experience with 8080 programming, so everything is original, even my instruction set. I have no experience with writing compilers or assemblers, so I am exploring new ground, but have the confidence I seemingly lacked for the MIDI Project, which I must take up anyway to graduate in two years.