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: 'sdcc-user@lists.sourceforge.net'
> Onderwerp: Re: [Sdcc-user] STM8 >32kB code fails...?
> 
> 
> > -----Oorspronkelijk bericht-----
> > Van: Philipp Klaus Krause [mailto:p...@spth.de]
> > Verzonden: zondag 25 maart 2018 20:06
> > Aan: sdcc-user@lists.sourceforge.net
> > 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
> 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

Reply via email to