I have to correct myself on the "special case" theory in the linker: when I actually use the full msc51 code (as opposed to just setting the same flags) in the assembler, it looks like the linker generates the right relocations for 24 bit stm8 as well.
Eric > -----Oorspronkelijk bericht----- > Van: Eric Rullens > Verzonden: donderdag 29 maart 2018 16:27 > Aan: 'sdcc-user@lists.sourceforge.net' > Onderwerp: Re: [Sdcc-user] How to deal bytewise with 24-bit symbols in > asxxx x? > > > Dear Philipp and Maarten, > > I was just checking and got this far: the assembler contains > a special case > for mcs51 (I think ds390 is essentially the same thing). > After making a > simple general change in the assembler, the rel files look > ok, but the rst > file still is broken. So there probably is a similar special > case in the > linker. But I have not checked that code yet. > > The relevant code in the assembler is in asout.c, look for > R_MSB and R_HIB > handling with thrdbyte(). > > Eric > > > > -----Oorspronkelijk bericht----- > > Van: Philipp Klaus Krause [mailto:p...@spth.de] > > Verzonden: donderdag 29 maart 2018 13:44 > > Aan: sdcc-user@lists.sourceforge.net > > Onderwerp: Re: [Sdcc-user] How to deal bytewise with 24-bit > symbols in > > asxxxx? > > > > > > Am 29.03.2018 um 13:08 schrieb Maarten Brock: > > >> Am 24.03.2018 um 20:21 schrieb Philipp Klaus Krause: > > >>> Am 24.03.2018 um 20:00 schrieb Maarten Brock: > > >>>> How about what the mcs51 back end does: just shift right by 8: > > >>>> ; genAssign > > >>>> mov dptr,#___fail_PARM_2 > > >>>> mov a,#___str_3 > > >>>> movx @dptr,a > > >>>> mov a,#(___str_3 >> 8) > > >>>> inc dptr > > >>>> movx @dptr,a > > >>>> > > >>>> Maarten > > >>> > > >>> I some places the stm8 backend deos the same. But AFAIK > > #___str_3 is the > > >>> full symbol, and onlybecasue of the assignment to a do > > the upper bits > > >>> get thrown away. This might create issues for peephole > rules that > > >>> combine two 8-bit loads into a 16-bit load. > > >>> > > >>> Philipp > > >> > > >> Unfortunately, it seems 24-bit symbols are simply not > > really supported > > >> in the assembler. > > >> > > >> #(s >> 8) gets the middle byte, just like #>s. #(s >> 16) > > gets the lower > > >> byte, jsut like #<s. Using #(s >> 8) where a 16-bit > value is needed > > >> results in the following instruction being overwritten in > > the linker. > > >> > > >> That means that the stm8 large memory model will have to > do without > > >> function pointers. > > >> > > >> Full support for function pointers would need: > > >> 1) A way to get individual bytes of 24-bit symbols > > >> 2) A way to get the upper 16 bits of 24-bit symbols > > >> > > >> Philipp > > > > > > If that is true, then the ds390 target is totally broken > > and the huge > > > model for mcs51 is broken as well. I'm sure this used to work. > > > > > > ISTR that the assembler has support for every odd kind of > > number of bits > > > per address word, including 24 bit. Is the address size > maybe set up > > > incorrectly? > > > > > > Maarten > > > > I had also tested with ds390, and it seemed to work there. > Maybe there > > is some functionality in the ds390 assembler that would have to be > > ported to the stm8 one. > > > > Philipp > > > > > > -------------------------------------------------------------- > > ---------------- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Sdcc-user mailing list > > Sdcc-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > -------------------------------------------------------------- > ---------------- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
