UP ONE LEVEL: ENCM 369 Winter 2004 Course Handouts

ENCM 369: Computer Organization
Lab 1 - for the week of January 19, 2004

Author: Steve Norman
Paper copies handed out: Tuesday, January 20, 2004
Last modified: Tue Jan 20 17:24:15 MST 2004

Contents


Updates / Corrections

See the revised Exercise G instructions for a clarification about the C code you were given.

[back to top of document]


This is an Individual Assignment

Each students should complete the assignment independently.

[back to top of document]


Introduction

Most of the programming you will do in this course will be in the MIPS assembly language described in Appendix A of Patterson and Hennessy. However, you will also do some C programming. The primary purpose of the C programming you do will be to give you some insight into relationships between assembler and high-level languages. An important secondary purpose will be to introduce some features of C that did not make it into ENCM 339.

All the Lab 1 exercises are C programming exercises; they serve both of the purposes given above.

[back to top of document]


Due Dates

The Due Date for this assignment is 1:30pm, Monday, Jan. 26.
The Late Due Date is 1:30pm, Tuesday, Jan. 27.

The penalty for handing in an assignment after the Due Date but before the Late Due Date is 3 marks. In other words, X/Y becomes (X-3)/Y if the assignment is late. There will be no credit for assignments turned in after the Late Due Date; they will be returned unmarked.

[back to top of document]


Marking scheme

A: 3 marks
D: 3 marks
G: 5 marks
H: 6 marks
total: 17 marks

[back to top of document]


How and where to hand in your assignments

Make a cover page with your name and lab section number on it in large, easy-to-read handwriting or printing, and staple your assignment together. Assignments held together by paper clips or by folding corners of pages together will almost certainly fall apart in the collection boxes, and teaching assistants are not responsible for finding missing loose pages.

Put the staple in the upper right corner of your assignment. (If you put it in the upper left corner, it is likely to go through important code on your printouts.)

Hand in your assignment in the box for your lab section in the west hallway on the 2nd floor of the ICT Building.

[back to top of document]


Notes on Compiler Warning Messages

This section is taken from an old ENCM 339 Lab 1 handout. I thought it might be useful for you to review it before trying to compile and run C programs.

When the compiler finds a problem in your source code it generates one of two types of messages: errors and warnings. If the word warning appears in the message, it is, logically enough, a warning. Otherwise it is an error, even if the word error does not appear.

An error means that something in your code violates the rules of C, meaning that the compiler cannot translate the source code. In the case of an error it is obvious that your program must be fixed.

A warning, on the other hand, is generated when the compiler finds something that is legal in C but is bad style or has a meaning that is probably not what you intended. If there are warnings but no errors, the compiler will translate your source code.

The command gcc339 is a version of the gcc (GNU C compiler) command; gcc339 generates a lot more warning messages than gcc does without any warning options turned on. The command

   gcc339 myprog.c
is equivalent to
   gcc -g -Wall -ansi -pedantic -Wstrict-prototypes \
   -Wmissing-prototypes myprog.c
Obviously the former command is easier to type.

The gcc339 command was set up on the Electrical and Computer Engineering Linux systems to help ENCM 339 students deal with some of the mistakes and misunderstandings that beginning C programmers often make.

[back to top of document]


Creating input/output records with termrec

This section is also from an old ENCM 339 Lab 1 handout. Read it if you haven't used termrec for a while and could use some help with it.

termrec is a utility which allows you to make a record of your program input and output.

Information on the use of termrec can be obtained in an old ENCM 339 course Web site. Click on the link to Recording a terminal session with termrec .

[back to top of document]


Exercise A: External variables

Read This First

Most variables you saw or created in programs in ENCM 339 were local variables. A local variable can be directly accessed only within function definition in which it appears. (A local variable of one function can be indirectly accessed by another function, if that other function has a pointer to the variable.)

C variables declared outside of all function definitions in a C source file are external variables. Unlike local variables, external variables can be directly accessed from many different function definitions.

External variables are often called ``global variables''. I have chosen to use the term external variable to be compatible with the book The C Programing Language, by Kernighan and Ritchie.

There are two kinds of external variables: those declared to be static and those not declared to be static. External variables declared to be static can be directly accessed by all functions in the source file where the variable is declared. (This use of the keyword static is confusing, because it has nothing to do with static memory allocation.) External variables not declared to be static can be directly accessed by all functions in a program.

(If you are working on a program where an external variable is in fact accessed from more than one source file, you need to know the rules regarding the extern keyword. See a good C text for details, and read carefully.)

External variables, regardless of whether they are declared as static, are always statically allocated. So, according to rules you should have learned in ENCM 339, external variables are found in the static storage region, are allocated and initialized before main starts, and remain allocated as long as the program runs.

Unlike variables in activation records, external variables that don't have initializers are initialized to zero. For example, consider this variable declaration:

  int foo[5];
If foo were local to some function, you could not count on the elements of foo to have any particular values. But if foo were an external variable, its elements would all be initialized to zero.

What to do

Copy the file /local/courses/encm369/lab1/exA/externals.c
Study the file and make ENCM-339-style memory diagrams for points one and two.

Hand in your diagrams.

[back to top of document]


Exercise B: goto statements

Read This First

goto statements are available in C and C++, and their equivalents are available in most programming languages.

You can have a long career writing high-quality C and C++ code for a huge variety of applications and never once use a goto statement. Just about everything you can do with goto can be done more clearly some other way. Use of goto tends to make code unreasonably hard to understand and debug.

Nevertheless, it's useful to know what goto does, for the following reasons:

It's this last reason that makes the goto statement relevant to ENCM 369.

Consider the following simple program:

#include <stdio.h>
int main(void)
{
  int i;
  for (i = 0; i < 4; i++)
    printf("i is %d.  ", i);
  printf("\n");
  return 0;
}
Obviously, the output is
i is 0.  i is 1.  i is 2.  i is 3.
Here is an equivalent program written using goto statements:
#include <stdio.h>
int main(void)
{
  int i;
  i = 0;
 loop_beginning:
  if (!(i < 4)) goto past_loop_end;
  printf("i is %d.  ", i);
  i++;
  goto loop_beginning;
 past_loop_end:
  printf("\n");
  return 0;
}
The output is exactly the same as that of the earlier program with the for loop.

The identifiers loop_beginning and past_loop_end are examples of what are called labels. A label is used to name a paticular statement; a colon must appear between a label and the statement it names. A goto statement has the following syntax:

goto label;
A goto statement causes the flow of statement execution to jump to whatever statement is named by the label. This should be reasonably clear from the example.

What to do

Determine the output of the following program by tracing its execution line by line with a pencil and paper.
#include <stdio.h>
int main(void)
{
  int outer, inner;
  outer = 3;
 outer_loop:
  if (outer == 0) goto quit_outer_loop;
  inner = 0;
 inner_loop:
  if (inner > outer) goto quit_inner_loop;
  printf(" %d", 100 * outer + inner);
  inner++;
  goto inner_loop;
 quit_inner_loop:
  printf(" **\n");
  outer--;
  goto outer_loop;
 quit_outer_loop:
  printf("*****\n");
  return 0;
}
Check your work by typing in the program, compiling it, and running it. (If it doesn't compile, goes into an infinite loop when it runs, or crashes, you have made a typing error.)

There is nothing to hand in for this exercise.

[back to top of document]


Exercise C: Goto-C and if/else statements

Read This First

From now on in this course, the term ``Goto-C'' refers to a programming language that is C with the following modifications: As you will soon see, Goto-C is an annoying language, significantly harder to read and write than normal C. However, working with Goto-C will help you learn how to code algorithms in assembly language.

Consider the following simple fragment of normal C:

  if (x >= 0)
    y = x;
  else
    y = -x;
The above is illegal in Goto-C for two reasons: the if statement is not in an acceptable form, and the banned keyword else is used. One way to translate the fragment to Goto-C is as follows:
  if (x < 0) goto else_code;
  y = x;
  goto end_if;
 else_code:
  y = -x;
 end_if:

What to do

Copy the directory /local/courses/encm369/lab1/exC
Read the file temperature.c. Make an executable and run it. The recode the function report in Goto-C. Make sure that the output of your modified program exactly matches the output of the original program.

There is nothing to hand in for this exercise.

[back to top of document]


Exercise D: Switch statements in Goto-C

What to do

Copy the directory /local/courses/encm369/lab1/exD
Read the file switch.c and follow the instructions in the comment at the top of the file.

Hand in a printouts of your completed program and a termrec file showing the program output.

[back to top of document]


Exercise E: Simple loops in Goto-C

Read This First

Simple C while and for loops are easy to code in Goto-C. You need a statement of the form
if (condition) goto label;
at the top of the loop to skip past the end of the loop when appropriate and you need a statement of the form
goto label;
to jump backwards after the loop body has been executed. For example, this code:
  while (i >= 0) {
    printf("%d\n", i);
    i--;
  }
can be written as:
 loop_top:
  if (i < 0) goto past_end;
  printf("%d\n", i);
  i--;
  goto loop_top;
 past_end:
Remember that the condition to quit looping is the opposite of the condition to continue looping.

What to do

Copy the directory /local/courses/encm369/lab1/exE
Read the file simple_loop.c and follow the instructions in the comment at the top of the file.

There is nothing to hand in for this exercise.

[back to top of document]


Exercise F: && and || in Goto-C

Read This First

You should recall from ENCM 339 that short-circuit evaluation is used when the && and || operators are encountered in C (and C++) code. For example, the right-hand operand of && is not evaluated if the the left-hand operand is false. It's quite easy to translate expressions with && into Goto-C. For example,
  if (y > 0 && x / y >= 10) {
    foo(x);
    bar(y);
  }
can be coded as
  if (y <= 0) goto end_if;
  if (x / y < 10) goto end_if;
  foo(x);
  bar(y);
 end_if:
Expressions with || are a bit trickier.

What to do

Copy the directory /local/courses/encm369/lab1/exF
Read the file logical_or.c and follow the instructions in the comment at the top of the file.

There is nothing to hand in for this exercise.

[back to top of document]


Exercise G: A more complicated loop in Goto-C

Read This First

This exercise asks you to take a program with a somewhat complicated loop and translate it into Goto-C.

What to do

Copy the directory /local/courses/encm369/lab1/exG
Read the file newton.c carefully. Make an executable using the following command:

   gcc339 newton.c -lm
(The -lm option is needed to tell the linker to search the math library for machine code for sin and cos. That's a lower-case L, not a number 1.)

Clarification added Tues Jan 20 about 5:20pm: The original newton.c file contained a section of commmented-out code, which was confusing. You were not supposed to translate that code to Goto-C. I have edited the file to remove the confusing comment. The rest of the C code is totally unchanged.

Run the executable four times, using the following text as input:

Translate the definition of main to Goto-C. Be careful to translate every use of a C feature that is not allowed in Goto-C.

Test your modified program with the same input given above for the original program. Make sure it always generates exactly the same output as the original program.

Make a termrec recording of your program runs with the four specified inputs, and hand that in a printout of that along with a printout of the final version of your source file.

[back to top of document]


Exercise H: Nested loops in Goto-C

Read This First

This exercise gives you a chance to write a Goto-C program ``from scratch''.

What to do

Write a Goto-C program that draws a plus sign out of stars, spaces and newlines. Here is an example dialogue with the program:
How many lines in your + sign?
7
Here is your picture ...
   *
   *
   *
*******
   *
   *
   *
Here is another example dialogue:
How many lines in your X?
5
Here is your picture ...
  *
  *
*****
  *
  *
The number of lines must be odd; the minimum number of lines allowed is 3 and the maximum is 21. If the user enters an out-of-range integer or an even integer or input that can't be converted into an integer, then the program should print an error message and not try to draw a picture.

Hint: First write the program with regular C loops and if-statements. Make sure it works. Then make a copy of your program under a new name and start translating it to Goto-C.

Hand in printouts of your completed source file and a termrec file demonstrating several runs of your program.

[back to top of document]