char / short locals in MIPS big-endian

[wnayes]

I am running into functional code issues when using char and short (or any type smaller than a word) with MIPS code generation.

Consider the following example:

extern char ReturnAChar();
extern void SomethingWithChar(char);

void main() {
    char x = ReturnAChar();
    if (x == 0) {
        SomethingWithChar(x);
    }
}

When I inspect the output, I see an issue with the handling of x:

	subu	$29, $29, 16
	jal	ReturnAChar
	subu	$29, $29, -16
	sw	$2, -4($30)    # issue!
	lb	$2, -4($30)
	bne	$2, $0, $L3

x gets stored as a word, but is then retrieved as a byte. At least on a big endian machine, this is going to result in an incorrect read.

I tried looking into the callers of GenWriteLocal in cgmips.c, but I am having a hard time tracking down why they might be passing the wrong value for opSz, especially since the loads are being generated fine.

[wnayes]

I located the cause of the issue in smlrc.c:

if (!isStruct)
{
   // This is a special case for initialization of integers smaller than int.
   // Since a local integer variable always takes as much space as a whole int,
   // we can optimize code generation a bit by storing the initializer as an int.
   // This is an old accidental optimization and I preserve it for now.
   // Note, this implies a little-endian CPU.
   stack[sp - 1][1] = SizeOfWord;
}

It may be worth considering a BIG_ENDIAN define or some official way to disable this optimization. Or consider ifndef MIPS around this.

[alexfru]

Yes, that's the place responsible for word-sized initialization of locals.
Off the top of my head, I don't know what else may be broken for big endian CPUs.
There has never been a goal to support big endian CPUs and I should at last document it explicitly.