> 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 ------------------------------------------------------------------------------ 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
