[sdcc-devel] [ sdcc-Bugs-677692 ] Extended Address Record is not correctly generated for DS390

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

Bugs item #677692, was opened at 2003-01-30 11:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=677692&group_id=599

Category: linker
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jan Rejlek (jare)
Assigned to: Jesus Calvino-Fraga (jesusc)
Summary: Extended Address Record is not correctly generated for DS390

Initial Comment:
The linker doesn't generate Extended Linear Address
Record for DS390 when crossing the 64K boundary, even
if the -r option is used. Below is the .ihx file
snippet showing this:

:0EFFD900BCC7C448E5588668A7784008611880
:0EFFE70002282338CCC9EDD98EE9AFF948893C
:0EFFF50069990AA92BB9F55AD44AB77A966AC7
:0E000300711A500A333A122AFDDBDCCBBFFB28
:0E0011009EEB799B588B3BBB1AABA66C877C91
:0E001F00E44CC55C222C033C600C411CAEED91

One possible solution of the problem is in the attached
file. The solution is certainly not quite clean as I
don't understand well the internals of aslink, but it
seems to work OK. (One known bug: If the 64K boundary
is contained within the assembler .ds statement, the
Extended Linear Address Record is not generated)

Jan Rejlek 


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

>Comment By: Jesus Calvino-Fraga (jesusc)
Date: 2003-02-05 22:59

Message:
Logged In: YES 
user_id=603650

Applied newest patch from Jan Rejlek and commited to the 
CVS:

aslink.h 1.14
lkihx.c 1.8
lkrloc.c 1.9


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

Comment By: Jan Rejlek (jare)
Date: 2003-01-31 09:17

Message:
Logged In: YES 
user_id=672939

Hi Jesus,

1)
ihxEntendedLinearAddress(lastExtendedAddress+=overrun);
This is not good:
rst file:
   FFEE 00                65982 	.db #0x00
   FFEF 07                65983 	.db #0x07
   FFF0 FF                65984 	.db #0xFF
   FFF1 FF                65985 	.db #0xFF
   FFF2 FF                65986 	.db #0xFF
   FFF3 FF                65987 	.db #0xFF
   FFF4 FF                65988 	.db #0xFF
   FFF5 FF                65989 	.db #0xFF
   FFF6 FF                65990 	.db #0xFF
   FFF7 FF                65991 	.db #0xFF
   FFF8 FF                65992 	.db #0xFF
   FFF9 FF                65993 	.db #0xFF
   FFFA FF                65994 	.db #0xFF
   FFFB FF                65995 	.db #0xFF
   FFFC FF                65996 	.db #0xFF
   FFFD FF                65997 	.db #0xFF
   FFFE FF                65998 	.db #0xFF
   FFFF FF                65999 	.db #0xFF
   10000 F0                66000 	.db #0xF0
   10001 00                66001 	.db #0x00
   10002 00                66002 	.db #0x00
   10003 00                66003 	.db #0x00
   10004 00                66004 	.db #0x00
   10005 00                66005 	.db #0x00
   10006 FF                66006 	.db #0xFF
   10007 FF                66007 	.db #0xFF
   10008 FF                66008 	.db #0xFF
   10009 80                66009 	.db #0x80
   1000A 00                66010 	.db #0x00
   1000B 00                66011 	.db #0x00
   1000C 00                66012 	.db #0x00
   1000D 00                66013 	.db #0x00
   1000E FF                66014 	.db #0xFF
   1000F FF                66015 	.db #0xFF
   10010 FF                66016 	.db #0xFF
   10011 FF                66017 	.db #0xFF
   10012 FF                66018 	.db #0xFF


ihx file:
:0EFFEE000007FFFFFFFFFFFFFFFFFFFFFFFF0A
:04FFFC00FFFFFFFF05
:020000040002F8
:0A000000F00000000000FFFFFF8089
:020000040001F9                                        
<------- FALSE ! 
:0E000A0000000000FFFFFFFFFFFFFFFFFFFFF2



2)
I have tested it still once and and it seems to me that the
extended linear address record is indeed not generated.

rst file
.
.
   FFE9 C2 02               619 	clr	_fiftymsBit
                            620 ;	test.c:69: fiftyms();
                            621 ;	genCall 
   FFEB C0 02               622 	push	ar2
   FFED C0 03               623 	push	ar3
   FFEF C0 04               624 	push	ar4
   FFF1 12 02 00 1C         625 	lcall	_fiftyms
   FFF5 D0 04               626 	pop	ar4
   FFF7 D0 03               627 	pop	ar3
   FFF9 D0 02               628 	pop	ar2
                            629 ;	test.c:72: _endasm;
                            630 ;	genInline 
   FFFB                     631 	                          
     .ds 8
                            632 ;	genLabel 
   0003                     633 00106$:
                            634 ;	test.c:74: if
(graphDataChanged) {
                            635 ;	genIfx 
                            636 ;	genIfxJump 
                            637 ; Peephole 111   removed
ljmp by inverse jump logic
   0003 30 01 02            638 	jnb  _graphDataChanged,00108$
   0006                     639 00137$:
                            640 ;	test.c:75:
graphDataChanged = OFF;
                            641 ;	genAssign 
                            642 ;	genAssign: resultIsFar = FALSE
   0006 C2 01               643 	clr	_graphDataChanged
                            644 ;	genLabel 
.
.

ihx file
.
:03FFE60030021ACC
:0CFFE900C202C002C003C0041202001CCF
:06FFF500D004D003D0028D
:03000300300102C7
:02000600C20135
:0A00080075C7AA75C755D2D880B09D
.

I will try to find some fix for it


Best regards,

Jan

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

Comment By: Jesus Calvino-Fraga (jesusc)
Date: 2003-01-31 02:00

Message:
Logged In: YES 
user_id=603650

Hi Jan,

I have been testing the changes you posted in the sdcc-user 
list.  They seen to work ok.  Just two things:

1) in line 142 of lkihx.c:

ihxEntendedLinearAddress(lastExtendedAddress+=overrun);

I added a '=' so lastExtendedAddress is updated avoiding the 
potential repetition of an extended linear record (which is 
harmless anyway).

2) I forced the .ds statment to be in the 64k boundary by 
using --code-loc but I was getting the correct extended linear 
record anyhow.  Any idea of what is happening?
 
Best regards,

Jesus

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

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