Maarten, thanks for your trouble. I think we have established that this not maybe realy a bug, although a warning message would be nice. Also would be nice if the manual would explain this and elaborate on how and when the compiler uses the spill registers.
But the importan thing is that I can now go on. br Kusti >>> "Maarten Brock" <[EMAIL PROTECTED]> 27.1.2008 14:57 >>> Kustaa, > 0013 A6s00 150 lda #>__str_0 > 0015 B7*00 151 sta *_main_sloc0_1_0 > 0017 A6r00 152 lda #__str_0 > 0019 B7*01 153 sta *(_main_sloc0_1_0 + 1) > Sorry for being ambiguos, what I mean is that both using data-loc $40 > and data-loc $140 both produce STA $40 The hc08 has very few registers so it often needs to put intermediate results in so-called spil-locations (sloc). For optimality these slocs need fast and short access and thus reside in 'data' memory which ends at 0x00FF. Apparently SDCC or its linker do not check the --data-loc value or the addresses of variables in data memory for the hc08. > >Have you tried without --data-loc? > > > Good point, had not tried it before your email, but now I have: > > Without data-loc the those variables we are talking about are allocated > at $0080 so the code becomes STA $80, which is correct or at least works. This > however implies that the compiler is not using the valuable RAM between $40 - $7F. Correct. > Also this raises further questions: > > What are the limitations here, does the compiler ever need more that > the what is available on page zero (128 bytes if it starts at 0080)? Yes, it might need more. The limit is what's available in the zero- page. > What happens if it runs out of space? One would hope that it generates errors or warnings, but I'm not sure that it actually does. > > Shouldn't the data-loc to enable use of RAM beyond zero page? No. It enables you to tell the compiler where the special function registers (or whatever they're called in hc08 lingo) end and where normal ram starts. The ram beyond the zero-page is called xdata by SDCC. > Or warn at least if it is set outside the page? > > br Kusti ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
