PROJECT: C(onvert) To Assembly (CTA0)

OBJECTIVE

With a basic pong game bootstrapped in C, commence an implementation in Vircon32 assembly, in two parts. In this first part: look to tackle the basic display of assets on the screen (no need for a fully interactive, finished game; that’s part 2).

EDIT

You will want to go here to edit and fill in the various sections of the document:

https://lab46.g7n.org/notes/comporg/fall2023/projects/cta0

CTA0

Assembly

Text Area

I'll be honest, I have no clue which aspect of the project “Text Area” refers to. Surely it isn't the vim editor.

Data and Registers

Data in assembly is stored within one of the available registers or within the stack.

In Vircon32, there are 16 available registers to store data within:

0-10 — General Purpose Registers
11-13 (CR, SR, DR) — String Registers
14-15 (BP, SP) — Stack Registers

The stack is the organization of memory in which we can throw in and pull out data in a “Last in, First out” method. The stack starts at the highest address in memory grows downward (towards the lowest address). The stack can only directly interact with other registers, no value can be immediately placed into it.

We use two registers to keep track of where we are within the stack. The Base Pointer (BP) and Stack Pointer (SP). The BP typically always points towards the top of the stack (The first value put into the stack) while the SP points towards the bottom (the latest value put into the stack). The push and pop instructions automatically increment or decrement the SP so that it remains in place.

BP and SP can be moved to other places though. When creating a function in assembly, the BP is pushed to the top of the stack, and SP is moved to its current position. This effectively creates a sub-stack in which the contents of the function doesn't mess up the stack outside of the function. Functions in assembly are followed up by a return function, in which BP and SP are moved in such that the original stack is reassembled.

Instructions

Vircon32 comes with 64 assembly instructions available to use:

0-1 — CPU Control (Control Flags)
2-6 — Jump Instructions
7-12 — Integer Comparisons
13-18 — Float Comparisons
19-24 — Data Movement
25-27 — String Operations
28-31 — Data Conversion
32-37 — Binary Operations
38-46 — Integer Arithmetic
47-55 — Float Arithmetic
56-63 — Extended Float Operations

These instructions are used to shuffle data between the Registers and the Stack, as well as perform the individual steps that higher-level functions do automatically (If statements, loops, etc.).

SUBMISSION

To be successful in this project, the following criteria (or their equivalent) must be met:

Project must be submit on time, by the deadline.
- Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
Executed programs must display in a manner similar to provided output
- output formatted, where applicable, must match that of project requirements
Processing must be correct based on input given and output requested
Output, if applicable, must be correct based on values input
Code must be nicely and consistently indented
Code must be consistently written, to strive for readability from having a consistent style throughout
Code must be commented
- Any “to be implemented” comments MUST be removed
  - these “to be implemented” comments, if still present at evaluation time, will result in points being deducted.
  - Sufficient comments explaining the point of provided logic MUST be present
No global variables (without instructor approval), no goto statements, no calling of main()!
Track/version the source code in your lab46 semester repository
Submit a copy of your source code to me using the submit tool by the deadline.

Submit Tool Usage

Let's say you have completed work on the project, and are ready to submit, you would do the following:

lab46:~/src/SEMESTER/DESIG/PROJECT$ submit DESIG PROJECT file1 file2 file3 ... fileN

You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.

RUBRIC

I'll be evaluating the project based on the following criteria:

26:cta0:final tally of results (26/26)
*:cta0:beginning effort in assembly [13/13]
*:cta0:successfully displays assets on screen [13/13]

Pertaining to the collaborative authoring of project documentation

each class member is to participate in the contribution of relevant information and formatting of the documentation
- minimal member contributions consist of:
  - near the class average edits (a value of at least four productive edits)
  - near the average class content change average (a value of at least 1024 bytes (absolute value of data content change))
  - near the class content contribution average (a value of at least 1kiB)
  - no zero-sum commits (adding in one commit then later removing in its entirety for the sake of satisfying edit requirements)
- adding and formatting data in an organized fashion, aiming to create an informative and readable document that anyone in the class can reference
- content contributions will be factored into a documentation coefficient, a value multiplied against your actual project submission to influence the end result:
  - no contributions, co-efficient is 0.50
  - less than minimum contributions is 0.75
  - met minimum contribution threshold is 1.00

Additionally

Solutions not abiding by spirit of project will be subject to a 50% overall deduction
Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction

Table of Contents