Dear Philipp,
I see you have been busy fighting the assembler (devil, details)... I also
could not get it to extract the high byte of a 24 bit word (.msb is not
available), but I could trick it into generating useful code like in the
example below.
===================
; Write AC ah am al.
jpf _test2
; Change jpf (AC) into ld a, #ah (A6 ah).
. = . - 4
.db 0xA6
. = . + 1
; Bytes am al can be overwitten with subsequent instructions.
===================
The result file:
===================
174 ; Write AC ah am al.
010080 AC 01 00 94 [ 2] 175 jpf _test2
176 ; Change jpf (AC) into ld a,
#ah (A6 ah).
00805C 177 . = . - 4
010080 A6 178 .db 0xA6
00805E 179 . = . + 1
180 ; Bytes am al can be
overwitten with subsequent instructions.
181 ; test.c: 112: return x + 1;
010082 .. .. [ 2] 182 ...
===================
A bit confusing to read, but it works for this little test. Do you think it
can also work with the code generator?
Eric
> -----Oorspronkelijk bericht-----
> Van: Eric Rullens
> Verzonden: dinsdag 27 maart 2018 09:31
> Aan: '[email protected]'
> Onderwerp: Re: [Sdcc-user] STM8 >32kB code fails...?
>
>
> > -----Oorspronkelijk bericht-----
> > Van: Philipp Klaus Krause [mailto:[email protected]]
> > Verzonden: zondag 25 maart 2018 20:06
> > Aan: [email protected]
> > Onderwerp: Re: [Sdcc-user] STM8 >32kB code fails...?
> >
> > Work on the feature request
> > (https://sourceforge.net/p/sdcc/feature-requests/556/) has been
> > progressing well.
> >
> > You can try it using current source (revision 10340 or
> > newer). To enable
> > support for the 24-bit space, use --model-large. Since you
> > have previous
> > experience with modifying SDCC for this, your comments (and possibly
> > patches) would certainly be helpful.
> >
> > Philipp
>
> Dear Philipp,
>
> I made a small test program and investigated the generated
> result file and
> sstm8 behaviour. Below is the source with comments on points
> where I see
> some issues.
>
> ====================
> /*
>
> Compiled with r10342 snapshot:
>
> sdcc -mstm8 --model-large
>
> Startup code uses jp instructions. Suggest using jpf
> instructions for the
> large memory model, for maximum flexibility.
>
> 008021 CC 80 04 [ 2] 67 jp __sdcc_program_startup
>
> 008004 73 __sdcc_program_startup:
> 008004 CC 80 24 [ 2] 74 jp _main
>
> */
>
> #include <stdint.h>
>
> uint32_t test1(uint32_t x);
> uint32_t test2(uint32_t x);
>
> int main(void)
> {
> uint32_t (*test)(uint32_t x) = test1;
>
> while (1)
> {
> /*
>
> Jumps to address 0x688068 (0x008068 expected) in sstm8.
> Issue with >>
> operator?
> 00802B A6 68 [ 1] 89 ld a, #(_test1 >> 16)
> 008068 132 _test1:
>
> Returns to address 0x458045 (0x008045 expected) in sstm8.
> Issue with >>
> operator?
> 008039 4B 45 [ 1] 100 push #(00111$ >> 16)
> 008045 108 00111$:
>
> */
> test(100);
>
> /* Call, return and stack frame look ok for below two
> functions. */
> test1(0xDEADBEEF);
> test2(0xBEEFDEAD);
> }
> }
>
> uint32_t test1(uint32_t x)
> {
> __asm
>
> ; Seems sstm8 has an issue with decoding 'jpf' (opcode
> 0xAC). Executing
> instruction looks ok.
> jpf $1
>
> ; Burn some flash.
> .ds 32 * 1024
>
> $1:
>
> __endasm;
>
> return x + 1;
> }
>
> const uint8_t
> flashfill[1024] = { 0, 1, 2, 3, 4, 5, 6, 7 };
>
> uint32_t test2(uint32_t x)
> {
> uint32_t
> temp1 = x * 2,
> temp2 = x * 4;
>
> /*
>
> Causes sdcc to enter 'infinite' loop. Ok when placed
> outside function
> scope (as above):
>
> const uint8_t
> flashfill[1024] = { 0, 1, 2, 3, 4, 5, 6, 7 };
>
> */
>
> /*
>
> Since 'flashfill' is placed after code and ldw uses 16 bit
> addressing,
> incorrect results are obtained here.
>
> Expected as constseg placement is not yet adjusted.
>
> */
> return temp1 + temp2 + flashfill[7];
> }
> ====================
>
> It looks like the basiscs are almost working (but as they
> say: the devil is
> in the details). I would like to work on a few patches, but
> currently time
> is limited. I would be able to have some experiments done on a larger
> project once the above issues are taken care of.
>
> Eric
>
> --------------------------------------------------------------
> ----------------
> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
