Possible Endianness Issue with char Function Arguments in EM Code on MC6800 Port

[zu2]

I am currently porting to MC6800 ( https://github.com/zu2/ack-6800 ).

It seems that the generated EM code assumes a little endian environment, which causes an issue when function arguments are of type char.

Here is a sample program:

int func(unsigned char a, unsigned char b)
{
    unsigned char c, d;

    a = &c - &d;
    b = &a - &b;

    return b;
}

The following EM code is generated:

loc 1   !  (&c-&d)
lal 4
sti 1
loc -2  ! (&a-&b)
lal 6
sti 1
  :

For the function arguments a and b, integral promotion is performed at the time of the function call, so they are treated as 2-byte integers. Thus, it makes sense that &a - &b results in -2.

However, when assigning values to a and b, only the first byte of each is written, which causes problems on big endian architectures.

When char is used as a local variable, only 1 byte is allocated, so this issue does not occur.

Is there an existing solution or a recommended way to handle this situation?

[zu2]

I checked the minix68k code and noticed that it adjusts the position of byte arguments at the beginning of the function.

Is it possible to implement this in cg, or would it require using ncg?
Since I'm currently working with cg, I'd prefer to handle it there if possible.

_func:
link	a6,#-2
tst.b -40(sp)
move.w 8(a6),d0
move.b d0,8(a6)
move.w 10(a6),d1
move.b d1,10(a6)

[davidgiven]

I (and I think everyone else) know very little about cg. Are you writing the 6800 backend from scratch? If so, you may have just nominated yourself as the expert!

You're right that there's an issue here. AFAIK em itself doesn't mandate that parameters get promoted, so the char->int business must be done by the C frontend. But the frontend never gets told whether it's generating code for a bigendian or littleendian system and a quick look doesn't show any code in it for generating such code.

I'll take a more detailed look in a bit but this is very puzzling.

[zu2]

Thank you for your feedback.

The reason I'm using cg is that I am referencing the implementations for the 6500 and Z80.

Previously, I developed a backend C compiler for the 6800 (https://github.com/zu2/chibicc-6800-v1).
At that time, I also modified the frontend to pass parameters as char without promoting types during function calls.

I would like to take a look at the C frontend as well.
Could you advise me on which parts I should investigate?

[zu2]

linuxppc code also adjusts the position of byte arguments.

lwz r4,8(fp)
stb r4,8(fp)
lwz r5,12(fp)
stb r5,12(fp)

[zu2]

The issue has been clarified. The C compiler outputs EM code for char-type arguments, as seen with the m68k and z8000. In contrast, this process is intentionally omitted in the cg/table for the 6500, which is appropriate because the 6502 is little-endian.

lol lal sti $1==$2 && $3==1 | | | | | /* throw away funny C-proc-prolog */

To handle char arguments on the MC6800, I've modified the table as below. This results in some instruction overhead, but it is necessary.

/* lol lal sti $1==$2 && $3==1 | | | | | /* throw away funny C-proc-prolog */
lol lal sti IN($1) && $1==$2 && $3==1 | |
		"! Code to adjust the byte order."
		"! lol lal sti IN($1) $2 $3"
		"\tldx LBl"
		"\tldab BASE+$1+1,x"
		"\tstab BASE+$1,x"
					 | | |
lol lal sti $1==$2 && $3==1 | |
		"! Code to adjust the byte order."
		"! lol lal sti IN($1) $2 $3"
		"\tldab <LB+1"
		"\tldaa <LB+1"
		"\taddb #[$1].l"
		"\tadca #[$1].h"
		"\tstab TMP+1"
		"\tstaa TMP"
		"\tldx TMP"
		"\tldab 1,x"
		"\tstab 0,x"
					 | | |