[sdcc-devel] [ sdcc-Bugs-1666106 ] hc08: wrong adressing mode for sloc's

[SourceForge.net <no...@so...>]

Bugs item #1666106, was opened at 2007-02-22 13:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1666106&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: hc08 port
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: kosmonaut_pirx (kosmonaut_pirx)
Assigned to: Nobody/Anonymous (nobody)
Summary: hc08: wrong adressing mode for sloc's

Initial Comment:
in using sdcc "as-it-is", generation of sloc happens quite often. adressing of these memories is done totally wrong. unfortunatly, this cannot easily reproduced, since  sloc's are generated by the compiler itself.

see the open thread in the help forum for this:
https://sourceforge.net/forum/forum.php?thread_id=1513006&forum_id=1865

sdcc put's sloc's in the data section. as for this is best, direct adressing mode is used in any accesses. what's going wrong is when the sloc is already out of data section (or better: zero-page section) because of it's address exceeds direct adressable data section.

as already mentioned before, the problem arises with bigger programs. smaller code sizes let each DATA entries be situated in zero-page, so there's no trouble with direct mode. but it is very annoying to scan the map-file for misplaced slocs.

1. sample
#define MAX_DB_NUM 0xF0
#define IDX 0x2C
#define IDX2 0x2E

data char dummy_bytes[MAX_DB_NUM];
xdata unsigned int i;

void main( void )
{	
  for ( i = 0; i <  MAX_DB_NUM; i++){
    dummy_bytes[i] = (char) i;
  }
  dummy_bytes[IDX2] = dummy_bytes[IDX]; 
  while(1);
}

2. sdcc-cmd
sdcc --stack-loc 0x044F --data-loc 0x0050 --xram-loc 0x0100 --model-large --no-peep  -I.  -mhc08 --out-fmt-s19 --verbose -V --debug -c main_s.c

and linking 
sdcc --stack-loc 0x044F --data-loc 0x0050 --xram-loc 0x0100 --model-large --no-peep  -I.  -mhc08 --out-fmt-s19 --verbose -V --debug -o ldhx_bug.s19 main_s.rel

already tryed the --model-large option of the mcs51, but to no avail.

3. sdcc -v
SDCC : hc08 2.6.4 #4638 (Feb 21 2007) (UNIX)
(yesterdays svn snapshot)
also
SDCC : hc08 2.6.0 #4309 (Nov 16 2006) (UNIX)
(current stable release)

any sdcc version compiled from source with everything
disabled but hc08 with
--disable-mcs51-port --disable-gbz80-port
--disable-z80-port --disable-avr-port
--disable-ds390-port --disable-pic-port
--disable-xa51-port --disable-ds400-port
--disable-ucsim --disable-pic16-port 

4. error
taken from asm output
;	-----------------------------------------
;	 function main
;	-----------------------------------------
_main:
	C$main_s.c$14$1$1 ==.
;main_s.c:14: for ( i = 0; i <  MAX_DB_NUM; i++){
	clra
	sta	_i
	clra
	sta	(_i + 1)
00104$:
	lda	(_i + 1)
	sub	#0xF0
	lda	_i
	sbc	#0x00
	bcs	00113$
	jmp	00107$
00113$:
	C$main_s.c$15$2$2 ==.
;main_s.c:15: dummy_bytes[i] = (char) i;
	lda	#_dummy_bytes
	add	(_i + 1)
	sta	*(_main_sloc0_1_0 + 1)
	lda	#>_dummy_bytes
	adc	_i
	sta	*_main_sloc0_1_0
	lda	(_i + 1)
	ldhx	*_main_sloc0_1_0

the last instruction is wrong. looking in the map file:

Area                               Addr   Size   Decimal Bytes (Attributes)
--------------------------------   ----   ----   ------- ----- ------------
DSEG                               0050   00F0 =    240. bytes (REL,CON)

      Value  Global
   --------  --------------------------------
     0050    G$dummy_bytes$0$0
     0050    _dummy_bytes

Hexadecimal

Area                               Addr   Size   Decimal Bytes (Attributes)
--------------------------------   ----   ----   ------- ----- ------------
OSEG                               0140   0002 =      2. bytes (REL,OVR)

      Value  Global
   --------  --------------------------------
     0140    Lmain$sloc0$1$0
     0140    _main_sloc0_1_0

the used spilling location is out of the data section where direct adressing mode is apply-able (from address   0 - 0xFF).

there's no idea why the linker doesn't complain about this. absolutely (mis)placed variables (resulting in ABS-entries) are recognized without any problems.

5. email
joe...@gr...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1666106&group_id=599