When backend-byte is enabled, the access to the global variables of 6800 becomes strange.

[zu2]

When backend-byte is enabled, the access to the global variables of 6800 becomes strange. I'm looking for the cause of this, but I can't find it.

I made the following modifications to the current latest fizix CC for testing.

--- ../Fuzix-Compiler-Kit/be-codegen-6800.c	2024-11-22 02:02:22.472094724 +0000
+++ be-codegen-6800.c	2024-11-22 02:04:05.088549955 +0000
@@ -31,7 +31,10 @@
 #include "compiler.h"
 #include "backend.h"
 #include "backend-6800.h"
+#include "backend-byte.h"
 
+void dump_tree(register struct node *n, unsigned depth);
+void byte_label_tree(register struct node *n, unsigned opt);
 
 /*
  *	Helpers for code generation and tracking
@@ -74,6 +77,7 @@
    propagation */
 struct node *gen_rewrite(struct node *n)
 {
+	byte_label_tree(n, BTF_RELABEL);
 	return n;
 }

sample program:

char	x[8];

int main(int argc, char *argv[])
{
	char	k=7;

	for(k=0; k<8; k++){
		x[k]=-1;
	}

	return 0;
}

Before applying the byte_label_tree change to be-codegen-6800.c.

seems good.

        tsx
        ldb 0,x
        clra
        addb #<_x+0
        adca #>_x+0
        staa @tmp
        stab @tmp+1
        ldx @tmp
        ldab #255
        stb 0,x

After applying the byte_label_tree changes to be-codegen-6800.c

The address cannot be calculated correctly because adca #0 is missing.

;:load:
;T_EQ v0 t8 f6 NORETURN, UCHAR
;    T_PLUS v0 t8 f1  UCHAR
;        T_NAME v0 t9 f0  UCHAR x
;        T_CAST v0 t18 f0  USHORT
;            T_DEREF v0 t8 f0  UCHAR
;                T_LOCAL v0 t8 f1  UCHAR        k
;    T_CONSTANT vffffffffffffffff t8 f0  UCHAR
;:rewritten:
;T_EQ v0 t8 f706 NORETURN,BYTEROOT,BYTEOP, UCHAR
;    T_PLUS v0 t9 f301 BYTEOP, UCHAR
;        T_NAME v0 t9 f800 BYTETAIL, UCHAR      x
;        2003 v0 t8 f800 BYTETAIL, UCHAR        k
;    T_CONSTANT vffffffffffffffff t8 fb00 BYTEOP,BYTETAIL, UCHAR
        ldb #<_x+0
        lda #>_x+0
;make local ptr off 0, rlim 255 noff 0
        tsx
        addb 0,x
        staa @tmp
        stab @tmp+1
        ldx @tmp
        ldab #255
        stb 0,x

[EtchedPixels]

Looks like the rule for T_EQ is wrong in backend-byte. T_EQ isn't a byteroot, the right hand node of T_EQ assign to char is what ought to get marked as byteroot.

[zu2]

Enable byte_label_tree in the current version, cmp_direct generates incorrect code, and the sample program goes into an infinite loop.

Even though __cclt is called, only one byte is pushed from the left side.

;:rewritten:
;T_BOOL v0 t10 f820 
;    T_LT v0 t10 ff00 
;        2003 v0 t8 f800        k
;        T_CONSTANT v8 t10 fb00 
;make local ptr off 0, rlim 255 noff 0
        tsx
        ldb 0,x
        pshb
        clra
        ldab #8
        jsr __cclt
; enter T_BOOL
;
        jeq L1_b
        jmp L1_n

Correcting cmp_direct makes the error go away, but I think there is a better solution.

--- ../Fuzix-Compiler-Kit.head/be-code-6800.c	2024-12-01 23:55:16.420397677 +0000
+++ be-code-6800.c	2024-12-02 09:25:04.142803577 +0000
@@ -5,6 +5,7 @@
 #include "compiler.h"
 #include "backend.h"
 #include "backend-6800.h"
+#include "backend-byte.h"
 
 unsigned label;		/* Used to hand out local labels of the form X%u */
 
@@ -983,12 +988,23 @@
 	return load_r_with('u', r, off);
 }
 
+unsigned is_simple(struct node *n);
+
 unsigned cmp_direct(struct node *n, const char *uop, const char *op)
 {
 	register struct node *r = n->right;
+	register struct node *l = n->left;
 	register unsigned v = r->value;
 	register unsigned s = get_size(r->type);
 
+	if ((n->flags & BYTEOP) && is_simple(r)){
+		op8_on_node(r,"cmp",0);
+		printf("\t%s %s\n", jsr_op, (l->type==UCHAR)?uop:op);
+		n->flags |= ISBOOL;
+		invalidate_b();
+		return 1;
+	}
+
 	if (r->op != T_CONSTANT)
 		return 0;
 	if (r->type & UNSIGNED)

[EtchedPixels]

I'm slowly working through stuff with some test ports but rewriting stuff byte sized (especially conditionals) does have some other effects that need resolving further in a lot of places. It will take some time so I don't want to touch the stable ports until I have 6502 and the other test cases for it working.