These are the bugs I have found in MWC6809.  I should have passed them
on two years ago, when I first found them, but I was too cheap to go
on-line then.


1)      The preferred and portable method of accessing char variables as
unsigned chars, when unsigned chars are not available is as follows is

	0xff & var

Microware C6809 has a habit of using the clra instruction to implement
the mask, which is great for math, but not so great for logic.  An
explicit compare has usually been sufficient to force a following tstb:

	(0xff & var) != 0

Some people say the explicit comparison is good practice.  I seem to
recall having to cast the expression sometimes:

	((int) 0xff & var) != 0

The non-surprise is the cast won't do it by itself.  The explicit
comparison is K&R and ANSI compliant.


2)      MWC6809 seems to have some confusion between the address of an
array and a pointer to its first element.  Code such as the following is
rejected by the compiler:

typedef char * MESS;
MESS errors[] =
{ "disk inserted backwards\n",
  "wrong media in tape drive\n",
  "nincompoop at the keyboard\n",
  NULL
};

I wrote myself a note that the compiler does accept and correctly
evaluate the array of string pointers if no intermediate type is used:

char *errors[] =
 /* etc. */

The compiler rejects arrays of arrays:

typedef char LN[8];
LN board[8];

but accepts and properly compiles multi-dimensional arrays:

char board[8][8];

Pointers to arrays cause the compiler confusion.  Given

typedef char LN[8];
LN *line;

the compiler allocates an array of 8 pointers for line.  It then treats
line as an array of pointers in expressions.  The results are amusing,
but dangerously non-portable.  Again, the -a -c options will
demonstrate how the compiler goes awry.  This would be the bug which
motivates strchar.ar.

3)      This one is rather obscure, but I ran into it right away, since
I like to mix assembler and high-level code.  If a function contains
imbedded assembler and local variables, there must be some high-level
code between the local declarations and the #asm line.  Otherwise,
neither the allocation nor any initializations occur until after the
#endasm line.  Not a surprising bug, really, and probably related to the
goto bug.

4)      The pre-processor simply doesn't handle nesting macro calls into
macro parameters.  I haven't been able to isolate this bug beyond
watching the compiler process wander away when I've tried to do this
thing.  Example:

#define ALLMAC(a, b) ARRTYPE a[b]
#define NOWAY(c) ALLMAC(c, 100)
...
NOWAY(hundred);

5)      The library function fgets(string, n, file) limits its input
strings to length n, rather than the advertised (manual p. 4-13) and
standard n-1.  This means, of course, that the length parameter should
be one less than the maximum length, which is not portable, but can't be
helped.

6)      The MMU does provide some address space separation and
protection from the consequences of overwriting pointers, but the
protection is not complete.

7)      The sbrk() library call does not catch arguments that are too
large.  It sort of attempts to return memory when given an argument
larger than 32k-256, almost as if it were attempting to return memory.
In the meantime, it ends up writing junk into other processes's windows
(similar to one of the Pascal Native code translator's bugs).

8)      I haven't played much with the Multi-Vue library, but I have
found one documentation bug. The Get/Put Buffer Pre-Load call, GPLoad,
is a not a pre-load, but a load (a much more sensible call, anyway).  It
takes one more parameter than the Multi-Vue docs specify; the
undocumented parameter, a pointer to the array holding the image to be
loaded, comes at the end of the list.  This pointer is a (char *), by
the way.

I should note that I have ported a fair bit of code to the Color
Computer 3 with good results, particularly since I isolated these bugs.