sdcc bug

ページ 1/4
| 2 | 3 | 4

By hit9918

Prophet (2927)

hit9918 さんの画像

26-03-2010, 15:53

EDIT:
same bugs with v2.9.0 from sourcefourge!

- - -

I downloaded an SCC, it is a v2.9.7, but I don't remember from where, I think I got it from an MSX site of the sort "list of dev tools". on sourceforge there is 2.9.0, is 2.9.7 an unofficial beta?

char* fp = 0; //mallocstart;
void* f(int n) { void* rv = (void*)fp; fp += n; return rv; }

at the end he forgets to stuff BC into returnregister HL. in HL is something like the address of fp. not the previous content of fp, but the address of fp (+-1) is returned.

_f_start::
_f:
        push    ix
        ld      ix,#0
        add     ix,sp
        ld      bc,(_fp)
        ld      hl,#_fp
        ld      a,(hl)
        add     a,4 (ix)
        inc     hl
        dec     hl
        push    bc
        ld      c, a
        inc     hl
        ld      a, (hl)
        ld      b, a
        ld      a, c
        dec     hl
        ld      (hl), a
        ld      a, b
        pop     bc
        adc     a,5 (ix)
        inc     hl
        ld      (hl),a
        pop     ix
        ret
_f_end::

another one

		tmp = 0; //if this removed, then crash, must be compiler bug
		for (i = 0; i < 2; i++) {
			SETWRT(6144 + i * 32*8);
			len = drawplaneW(testcommand, vdpname, plane, ph, modulo)
			- testcommand;
			if (i == 0) tmp = len;
		}

feels like a bug in the same corner.

Sigh, things are hardcore on 8bit, one got to take care that innocent looking glue code does not eat lots rastertime, one got to take lot care of memory adresses, the built in malloc is fix compiled to maxsize 1k or so, and finally the compiler got bugs in basics.

ログイン/登録して投稿

By nerlaska

Master (166)

nerlaska さんの画像

26-03-2010, 16:05

yes. 2.9.7 has many bugs. For example, I have code that can't be compiled.
I work with 2.9.0. it's more stable.

By Sd-Snatcher

Hero (582)

Sd-Snatcher さんの画像

26-03-2010, 20:15

I find some bugs in the past too, they make me to return to TPascal, later they seems corrected. Is good to know wich version are you using Nerlaska Tongue.

By PingPong

Prophet (4093)

PingPong さんの画像

27-03-2010, 10:13

@hit9918:
what horrible machine code is generated! assuming the 'c' source is aligned to to the machine code, it's not only bugged, also perform a lots of un-needed operations. TongueTongueTongue

for example look at:
ld a, (hl)
ld b, a
could be:
ld b,(hl), saving the need to backup a reg into c.

i think hitech c does a lot better, and even TPascal does.

char* fp = 0; //mallocstart;
void* f(int n) { void* rv = (void*)fp; fp += n; return rv; }


_f_start::
_f:
        push    ix
        ld      ix,#0
        add     ix,sp
        ld      bc,(_fp)
        ld      hl,#_fp
        ld      a,(hl)
        add     a,4 (ix)
        inc     hl
        dec     hl
        push    bc
        ld      c, a
        inc     hl
        ld      a, (hl)
        ld      b, a
        ld      a, c
        dec     hl
        ld      (hl), a
        ld      a, b
        pop     bc
        adc     a,5 (ix)
        inc     hl
        ld      (hl),a
        pop     ix
        ret
_f_end::

By PingPong

Prophet (4093)

PingPong さんの画像

27-03-2010, 12:33

this is the code generated by IAR compiler, for the bugged function. look at the difference.

char* fp = 0; //mallocstart;
2 void* f(int n)
3 {
\ 0000 CD0000 CALL ?ENT_AUTO_DIRECT_L09
\ 0003 FEFF DEFW 65534
4 void* rv = (void*)fp; fp += n; return rv;
\ 0005 2A0000 LD HL,(fp)
\ 0008 DD75FE LD (IX-2),L
\ 000B DD74FF LD (IX-1),H
\ 000E DD6E02 LD L,(IX+2)
\ 0011 DD6603 LD H,(IX+3)
\ 0014 ED4B0000 LD BC,(fp)
\ 0018 09 ADD HL,BC
\ 0019 220000 LD (fp),HL
\ 001C DD6EFE LD L,(IX-2)
\ 001F DD66FF LD H,(IX-1)
5 }
\ 0022 C30000 JP ?LEAVE_DIRECT_L09

By ARTRAG

Enlighted (6923)

ARTRAG さんの画像

27-03-2010, 14:23

actually my Hihtech compiler (v7.8) gives:

  262                           ;FOO.C: 130: char* fp = 0;
  263                           ;FOO.C: 131: void* f(int n) { void* rv = (v
                                oid*)fp; fp += n; return rv; }
  264   0121'                   _f:
  265                           ; _rv allocated to bc
  266   0121' ED 4B 0000'       	ld	bc,(_fp)
  267   0125' 69                	ld	l,c
  268   0126' 60                	ld	h,b
  269   0127' 19                	add	hl,de
  270   0128' 22 0000'          	ld	(_fp),hl
  271   012B' 69                	ld	l,c
  272   012C' 60                	ld	h,b
  273   012D' C3 0000*          	jp	lret

By PingPong

Prophet (4093)

PingPong さんの画像

27-03-2010, 21:43

would be nice to know about z88dk c compiler.

By ARTRAG

Enlighted (6923)

ARTRAG さんの画像

28-03-2010, 15:48

no idea about that compiler, anyway I would have done

ld hl,(_fp)
ex de,hl
add hl,de
ld (_fp),hl
ex de,hl
jp lret

By hit9918

Prophet (2927)

hit9918 さんの画像

28-03-2010, 23:43

@hit9918:
what horrible machine code is generated! assuming the 'c' source is aligned to to the machine code, it's not only bugged, also perform a lots of un-needed operations. TongueTongueTongue

yes it is really strange TongueTongueTongue


for example look at:
ld a, (hl)
ld b, a
could be:
ld b,(hl), saving the need to backup a reg into c.

even more catastrophic:
inc hl
dec hl
LOL!LOL!

it feels like sdcc got many code generators fighting each other.

well, Z80 is by far the biggest register allocation knightmare.
6502 is not, because it practically got no registers.
and 8086 is orthogonal beauty in comparison to z80.

and then yesterday I found a new style when playing with spritesort:
8bit pointers in 8bit registers and HL is permanently reloaded: the upper byte H is loaded immedeate, and selfmodifying code outside of the loop might patch the immedeate bytes.
now that I think of it, I slightly remember having seen such style in some 8080 code. 8080 got no ix iy and no exx.

I needed to store DE thru pointer of lowpri arr or hipri arr, ix iy are slow, no registers left.
and because stuff is in DE an EXX is of no help.

the code is just a sketch, completely untested.

11 pop de
8 ld a,(de)

8 ld h,lut
5 ld l,a
8 ld l,(hl)
8 ld h,scanarr

12 DEC (HL)
11 jp minus,fifth1
5 INC L

12 DEC (HL)
8 jp minus,fifth2

8 ld h,hiarr
5 ld l,c	;c: lo pri arr ptr
8 ld (hl),e
5 inc l
8 ld (hl),d
5 inc l
8 ld c,l

13 dec ixl
11 jp nz,loop
;---------------
fifth1:
inc l
dec (hl)
fifth2:

ld h,loarr
ld l,b	;b: hi pri arr ptr
ld (hl),e
inc l
ld (hl),d
inc l
ld b,l

dec ixl
jp nz,loop

By hit9918

Prophet (2927)

hit9918 さんの画像

29-03-2010, 00:13

actually my Hihtech compiler (v7.8) gives:

  262                           ;FOO.C: 130: char* fp = 0;
  263                           ;FOO.C: 131: void* f(int n) { void* rv = (v
                                oid*)fp; fp += n; return rv; }
  264   0121'                   _f:
  265                           ; _rv allocated to bc
  266   0121' ED 4B 0000'       	ld	bc,(_fp)
  267   0125' 69                	ld	l,c
  268   0126' 60                	ld	h,b
  269   0127' 19                	add	hl,de
  270   0128' 22 0000'          	ld	(_fp),hl
  271   012B' 69                	ld	l,c
  272   012C' 60                	ld	h,b
  273   012D' C3 0000*          	jp	lret

your compilers are the first time that I see an 8bit compiler do real code oO I guess they are commercial?

But what is the jump to lret for? In pingpongs compiler it looked like it was a cleanup for the call to enter which looked like some code size saving stack frame setup. But your compiler goes without a frame, looks like calling convention is first parameter in DE, so why not just RET?

By andrear1979

Expert (97)

andrear1979 さんの画像

29-03-2010, 01:20

Hi guys,

I think I found a rough workaround to the first bug
shown by hit9918. If I tell explicitly how to cast:

void* f(int n){
	void* tmp=fp;
	fp=(void*) ( ((int)fp) + n); // <---------
	return tmp;
}

then SDCC 2.9.7 generates this:

;main.c:6: void* f(int n){
;	---------------------------------
; Function f
; ---------------------------------
_f_start::
_f:
	push	ix
	ld	ix,#0
	add	ix,sp
;main.c:7: void* tmp=fp;
	ld	hl,(_fp)
;main.c:8: fp=(void*) ( ((int)fp) + n);
	ld	iy,#_fp
	ld	c,0 (iy)
	ld	b,1 (iy)
	ld	a,c
	add	a,4 (ix)
	ld	c,a
	ld	a,b
	adc	a,5 (ix)
	ld	b,a
	ld	0 (iy),c
	ld	1 (iy),b
;main.c:9: return tmp;
	pop	ix
	ret
_f_end::

and the generated main.rom printed
the saved fp value as expected.

ページ 1/4
| 2 | 3 | 4