Known Tool Problems

Below is a list of known problems with the ECEn 425 tools. You will want to watch out for these so that they don't adversely affect you as you work on your labs. Please pay special attention to the problems with C86. If you find new problems, please notify the instructor.

C86 Compiler

C86 does not support the more recent C feature of being able declare and initialize local variables anywhere in a function body. It follows the older C convention. All local variables should be declared at the beginning of their function and initialized separately (except for static local variables, which should be initialized where they are declared).

The error messages the compiler gives when you forget this are a bit ambiguous. For example, if I declare a variable "int i;" in the middle of a function, the compiler simply reports the error "unexpected symbol 'i' found".

For example, instead of

void MyFunction(void)
{
    Func1();                               /* BAD! Don't put code before variable declarations. */
    int j;
    .
    .
    for(int i = 0; i < 100; i++) Func2();  /* BAD! Don't declare i here. */
    char c = 'X';                          /* BAD! Don't declare c here. */
    .
    .
}

Write the function like this:

void MyFunction(void)
{
    int j;                             /* GOOD! All declarations go here. */
    int i;
    char c;
    
    Func1();                           /* GOOD! Start code after declarations. */
    .
    .
    for(i = 0; i < 100; i++) Func2();  /* GOOD! Declaration for i not in for(). */
    c = 'X';                           /* GOOD! Don't initialize c here. */
    .
    .
}

There is a problem with the compiler's register allocation unit that causes it to use registers improperly when doing complex arithmetic statements. To avoid problems, break up statements so that you use only one operator per statement. For example, instead of

	result = 10 - myVAr / myNum;    /* BAD!! */

Break it up as:

	result = myVar / myNum;

	result = 10 - result;

The compiler has a problem with multiple instructions on the same line (separated by a semicolon). If you use a macro that expands to multiple instructions (to keep your code concise), this can be a problem, particularly if the instructions occur in the body of the "then" or "else" clause of an "if" statement. This bug is readily apparent by studying the flow of control through if-then-else code blocks as they are generated by the compiler.
Avoid long and unsigned long variables, except when absolutely necessary (which is probably never). These are 32-bit operations and the compiler's support for them is not very reliable. Also, 32-bit operations can require from a few to very many instructions to complete because the 8086 doesn't support them directly.

If you must use them, avoid mixing long and int types in multiplication and division operations. For example, instead of
```
	int result;
	long bigNumber;
	...
	result = (int)bigNumber / 3;    /* BAD!! */
```
Do the following:
```
	int result;
	long bigNumber;
	...
	result = (int)bigNumber;
	result = result / 3;
```

Avoid multidimensional arrays.

NASM

None

Emu86

None