Re: [Sdcc-user] STM8 >32kB code fails...?

2018-02-21 Thread Eric Rullens 
> Am 19.02.2018 um 10:50 schrieb Maarten Brock:
> > 
> > Do I understand correctly that your STM8 has code memory 
> above 0x? 
> > So the problem is that SDCC only generates 16 bit jump/call 
> > instructions and thus cannot reach 0x1 and above, but 
> it can 'overflow' into that area.
> > 
> > Does the STM8 have separate 24 bit jump/call instructions?
> 
> Yes. They are mostly ok, but function calls get awkward. 
> Where it gets really awkward is data above 64K.
> 
> > Or is it a
> > special mode like on the DS390? Or is one supposed to use 
> bank switching?
> > And are there also STM8 versions with only memory below 64k?
> 
> Only very few STM8 have memory above 64K.

All STM8 parts with more than 32 kB flash currently cannot be used to their
full potential with SDCC.

Looking at the ST website, at the moment this means 58 of the 138 variants.
Including the interesting ones of course. ;-)

A while ago I did some experiments (sadly not completed yet) by adding a 24
bit mode to the SDCC STM8 port. Instead of CALL/RET, CALLF/RETF are emitted
and the stack calculations need to cope with 3 instead of 2 bytes for the
return. For the constants section I cheated a bit and made an option to
place this segment before the code segment, so for most (of my) programs  no
further changes would be needed.

 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

Re: [Sdcc-user] How to deal bytewise with 24-bit symbols in asxxx x?

2018-04-06 Thread Eric Rullens 
Dear Phillipp,

Yes, you are absolutely right: for relocatable symbols things go awry. When
attempting my previous tests on a relocatable symbol more issues can be
seen:

  010050123 _test1:
124 ;   test.c: 126: __endasm;
125 ;   Assembler test: loading
0xhhmmll (high, mid, low) bytes into x and a.
   332211   126 pattern = 0x332211

127 ;   Load mid and low.
  010050 AE 00 50 [ 2]  128 ldw x, #_test1
  010053 9D   [ 1]  129 nop
  010054 9D   [ 1]  130 nop

131 ;   Load low byte (xh is set to
0).
132 ;   Does not seem to work with
relocatable symbol (relocation error).
  010055 AE 00 11 [ 2]  133 ldw x, #pattern
  01005D 9D   [ 1]  139 nop
  01005E 9D   [ 1]  140 nop

141 ;   Load high and mid. Gives
incorrect result and overwrites next memory location.
  01005F AE 80 AB [ 2]  142 ldw x, #(_test1>>8)
  010062 C2   [ 1]  143 nop
  010063 9D   [ 1]  144 nop

145 ;   Load high (xh is set to 0).
Gives incorrect result.
  010064 AE 00 50 [ 2]  146 ldw x, #(_test1>>16)
  010067 9D   [ 1]  147 nop
  010068 9D   [ 1]  148 nop

149 ;   Load low.
  010069 A6 50[ 1]  150 ld  a, #_test1
  01006B 9D   [ 1]  151 nop
  01006C 9D   [ 1]  152 nop

153 ;   Load mid (2 methods).
  01006D A6 00[ 1]  154 ld  a, #(_test1>>8)
  01006F 9D   [ 1]  155 nop
  010070 9D   [ 1]  156 nop
  010071 A6 00[ 1]  157 ld  a, #>_test1
  010073 9D   [ 1]  158 nop
  010074 9D   [ 1]  159 nop

160 ;   Load high.
  010075 A6 01[ 1]  161 ld  a, #(_test1>>16)
  010077 9D   [ 1]  162 nop
  010078 9D   [ 1]  163 nop

Still a few challenges left...

 Eric



> -Oorspronkelijk bericht-
> Van: Philipp Klaus Krause [mailto:p...@spth.de]
> Verzonden: vrijdag 6 april 2018 14:24
> Aan: sdcc-user@lists.sourceforge.net
> Onderwerp: Re: [Sdcc-user] How to deal bytewise with 24-bit symbols in
> asxxx x?
> 
> 
> Am 06.04.2018 um 14:12 schrieb Eric Rullens:
> > Dear Philipp,
> > 
> > Apologies for bumping into this conversation (and thank you 
> very much for
> > all the work!), but I think the assembler does what it should do.
> > 
> > Please consider the following:
> > 
> > […]
> > 
> >   124 ; Load high and mid.
> > 00804E AE 33 22 [ 2]  125   ldw x, #(pattern>>8)
> 
> This one is the problem.
> 
> void main(void)
> {
> __asm
>   nop
>   ldw x, #(_main >> 8)
>   nop
> __endasm;
> }
> 
> results in this listing (comments removed):
> 
> _main:
>   00 9D   [ 1]   87   nop
>   01 AEr00r00 [ 2]   88   ldw x, #(_main >> 8)
>   04 9D   [ 1]   89   nop
>   05 87   [ 5]   94   retf
> 
> And this binary:
> 
> :04F08200F00892
> :1DF00800AE2707724F5A26F9AE2709D6F02AD75A26F7CCF004F9
> :04F00400AC00F02547
> :06F025009DAE00F0C28761
> :0001FF
> 
> As you can see, the second nop got overwritten by 0xc2. Whenever I use
> #(sym >> 8) where a 16-bit value is expected, I see the following
> instruction being overwritten.
> 
> 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

Re: [Sdcc-user] How to deal bytewise with 24-bit symbols in asxxx x?

2018-04-06 Thread Eric Rullens 
Dear Philipp,

Apologies for bumping into this conversation (and thank you very much for
all the work!), but I think the assembler does what it should do.

Please consider the following:

  116 ; Assembler test (r10380): loading
0xhhmmll (high, mid, low) bytes into x and a.
 332211   117   pattern = 0x332211

  118 ; Load mid and low.
008045 AE 22 11 [ 2]  119   ldw x, #pattern

  120 ; Load low byte (xh is set to 0).
008048 AE 00 11 [ 2]  121   ldw x, #pattern

  124 ; Load high and mid.
00804E AE 33 22 [ 2]  125   ldw x, #(pattern>>8)

  126 ; Load high (xh is set to 0).
008051 AE 00 33 [ 2]  127   ldw x, #(pattern>>16)

  128 ; Load low.
008054 A6 11[ 1]  129   ld  a, #pattern

  130 ; Load mid (2 methods).
008056 A6 22[ 1]  131   ld  a, #(pattern>>8)
008058 A6 22[ 1]  132   ld  a, #>pattern

  133 ; Load high.
00805A A6 33[ 1]  134   ld  a, #(pattern>>16)

The operators manipulate the symbol value, and not the memory contents. So
ldw x, #pattern loads the lower 16 bits of the symbol value (and not the
first two bytes of the symbol if it were to be placed in memory). Seems to
make sense to me?

 Eric


> -Oorspronkelijk bericht-
> Van: Philipp Klaus Krause [mailto:p...@spth.de]
> Verzonden: vrijdag 6 april 2018 11:01
> Aan: sdcc-user@lists.sourceforge.net
> Onderwerp: Re: [Sdcc-user] How to deal bytewise with 24-bit symbols in
> as?
> 
> 
> Am 02.04.2018 um 14:35 schrieb Maarten Brock:
> > 
> > In the generated code I see that the lower 16 bits are 
> loaded into x, not
> > the upper. And the most significant byte is loaded into a 
> by using # > but that seems to fail. If you instead use #(sym>>16) it 
> seems alright to
> > me.
> > 
> > Maarten
> 
> void f(void)
> {
>   void (*p)(void) = 
>   (*p)();
> }
> 
> compiles to:
> 
>   ld  a, #<_f
>   ldw x, #_f
> ; test.c: 4: (*p)();
>   push#(00103$)
>   push#(00103$ >> 8)
>   push#(00103$ >> 16)
>   pusha
>   ld  a, xl
>   pusha
>   ld  a, xh
>   pusha
>   retf
> 00103$:
> ; test.c: 5: }
>   retf
> 
> The lower 16 bits are loaded into x (but it should be the upper 16
> bits). The lower 8 bits get loaded into a correctly.
> 
> I guess I'll implement some workaround that makes the 
> register allocator
> not want to use x for the upper 16 bits in such an assignment (but I
> don't like having code geneation need workarounds for 
> assembler issues).
> 
> 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

Re: [Sdcc-user] STM8 >32kB code fails...?

2018-03-27 Thread Eric Rullens 
> -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 

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)
008068132 _test1:

Returns to address 0x458045 (0x008045 expected) in sstm8. Issue with >>
operator?
008039 4B 45[ 1]  100  push  #(00111$ >> 16)
008045108 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

Re: [Sdcc-user] STM8 >32kB code fails...?

2018-03-28 Thread Eric Rullens 
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 
> 
> 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)
> 008068132 _test1:
> 
> Returns to address 0x458045 (0x008045 expected) in sstm8. 
> Issue with >>
> operator?
> 008039 4B 45[ 1]  100  push  #(00111$ >> 16)
> 008045108 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
>

Re: [Sdcc-user] How to deal bytewise with 24-bit symbols in asxxx x?

2018-03-29 Thread Eric Rullens 
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
> > as?
> > 
> > 
> > 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
> > >>>> movdptr,#___fail_PARM_2
> > >>>> mova,#___str_3
> > >>>> movx@dptr,a
> > >>>> mova,#(___str_3 >> 8)
> > >>>> incdptr
> > >>>> 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 #> 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

Re: [Sdcc-user] How to deal bytewise with 24-bit symbols in asxxx x?

2018-03-29 Thread Eric Rullens 
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
> as?
> 
> 
> 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
>  movdptr,#___fail_PARM_2
>  mova,#___str_3
>  movx@dptr,a
>  mova,#(___str_3 >> 8)
>  incdptr
>  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 #> 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

Re: [Sdcc-user] SDCC 3.7.0 Release Candidate 1

2018-02-27 Thread Eric Rullens 
Long time MCS51 and more recently STM8 user here.

For STM8 I've noticed that "random" code is generated for the following:


int sum(int a, int b, unsigned long d)
{
  return a + b / d;
}

int main(void)
{
  return sum(1, 2, 4);
}


This is using the 3.7.0 #10228 snapshot on Windows 10.0.16299.125.

Compiling ten times as follows, and generating a checksum on the resulting
images:


sdcc -mstm8 test.c
md5sum test.ihx


034855cad4e8eb12209ad31c9ccd7f9b *test.ihx 034855cad4e8eb12209ad31c9ccd7f9b
*test.ihx
069a62e6676bd940cb01a36ab3a7f787 *test.ihx
069a62e6676bd940cb01a36ab3a7f787 *test.ihx 034855cad4e8eb12209ad31c9ccd7f9b
*test.ihx 034855cad4e8eb12209ad31c9ccd7f9b *test.ihx
069a62e6676bd940cb01a36ab3a7f787 *test.ihx 034855cad4e8eb12209ad31c9ccd7f9b
*test.ihx 034855cad4e8eb12209ad31c9ccd7f9b *test.ihx
069a62e6676bd940cb01a36ab3a7f787 *test.ihx

The differences occur just after the call to divulong, as can be seen in the
assembly code from runs 2 and 3.

The assembly code for "sum" from run 2:


;   test.c: 1: int sum(int a, int b, unsigned long d)
;   -
;function sum
;   -
_sum:
sub sp, #6
;   test.c: 3: return a + b / d;
ldw y, (0x0b, sp)
clrwx
tnzwy
jrpl00103$
decwx
00103$:
ld  a, (0x10, sp)
pusha
ld  a, (0x10, sp)
pusha
ld  a, (0x10, sp)
pusha
ld  a, (0x10, sp)
pusha
pushw   y
pushw   x
call__divulong
addwsp, #8
ldw (0x03, sp), y
ldw y, (0x09, sp)
ldw (0x01, sp), y
addwx, (0x01, sp)
;   test.c: 4: }
addwsp, #6
ret


The assembly code for "sum" from run 3:


;   test.c: 1: int sum(int a, int b, unsigned long d)
;   -
;function sum
;   -
_sum:
sub sp, #6
;   test.c: 3: return a + b / d;
ldw y, (0x0b, sp)
clrwx
tnzwy
jrpl00103$
decwx
00103$:
ld  a, (0x10, sp)
pusha
ld  a, (0x10, sp)
pusha
ld  a, (0x10, sp)
pusha
ld  a, (0x10, sp)
pusha
pushw   y
pushw   x
call__divulong
addwsp, #8
ldw (0x01, sp), y
ldw y, (0x09, sp)
ldw (0x05, sp), y
addwx, (0x05, sp)
;   test.c: 4: }
addwsp, #6
ret


It looks like this may have been reported before for MCS51 as well:

https://sourceforge.net/p/sdcc/mailman/message/35171634/

But for the example above I don't see the issue for MCS51.

Any thoughts?

 Eric Rullens

 

-Original Message-
From: Philipp Klaus Krause [mailto:p...@spth.de] 
Sent: zondag 11 februari 2018 10:09
To: Development chatter about sdcc; Sdcc-User
Subject: [Sdcc-user] SDCC 3.7.0 Release Candidate 1

Dear SDCC developers and users,

Today the first Release Candidate (RC1) for SDCC 3.7.0 has been created.
As always it has been put online in our SourceForge File section.
https://sourceforge.net/projects/sdcc/files/

If you have the time, please verify it and report back with the positive or
negative results.

Since we are having some troubles with some machines in our compile farm,
for 3.7.0 no binaries will be released. The release candiate consists of
source and documentation tarballs only. Also, Maarten, who has been the
release manager for a few years, is currently too busy to manage the 3.7.0
release. We hope to be back to normal for a 3.8.0 release later this year.

There have been a lot of improvements, both features and bug fixes since
SDCC 3.6.0. The full ChangeLog is at
https://sourceforge.net/p/sdcc/code/HEAD/tree/tags/sdcc-3.7.0-pre1/sdcc/Chan
geLog.

The following is a list of particularly noticeable new features.

* Changed putchar() prototype from void putchar(char) to int
putchar(int) to improve standard-compliance and allow error reporting.
* Various speed improvements in stm8 backend - Dhrystone score more than
doubled, resulting in SDCC achieving the highest Dhrystone scores among
STM8 C implementations.
* Various speed improvements for multiplications resulting in SDCC achieving
the highest Coremark scores among STM8 C implementations.
* Declarations in for loops (ISO C99).
* 64-bit integers (long long) for the mcs51 and ds390 backends (now long
long is fully supported in SDCC except for the pic14 and pic16 backends).
* Full _Bool support for mcs5

Re: [Sdcc-user] STC8A8K64S4A12 UART?

2020-06-07 Thread Eric Rullens 
Just a wild guess after browsing the manual: the UART pins can be selected
via S1_S[1:0] in P_SW1, and this setting does not seem to have a default?

 Eric


> -Original Message-
> From: Philipp Klaus Krause [mailto:p...@spth.de] 
> Sent: zondag 7 juni 2020 16:01
> To: Sdcc-User
> Subject: [Sdcc-user] STC8A8K64S4A12 UART?
> 
> I'm trying to get a simple "Hello world" running on a 
> STC8A8K64S4A12 Development Board.
> However, so far, I've gotten nowhere.
> 
> I see no activity on the serial lines (the board has LEDs 
> attached to P3.o and P3.2, the RxD and TxD pins, so if there 
> was any activity, I should at least see the LEDs flickering, 
> but I see nothing.
> 
> I've tried both the sample code in section 14.7.3 of the 
> datasheet, and my own code from other STC devices 
> (http://www.colecovision.eu/mcs51/STC89%20DEMO%20BOARD%20Seria
> l.shtml).
> 
> Even if I haven't gotten the speed right yet (both code 
> samples are actually for 11.0592 MhZ system clock) I should 
> at least see the LEDs flicker (like they do when writing 
> using stcgal).
> 
> Philipp
> 
> 
> ___
> Sdcc-user mailing list
> Sdcc-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
> 


___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] STC8A8K64S4A12 UART?

2020-06-11 Thread Eric Rullens 
Is there anything connected (e.g. a USB connector for programming) to P3.0
and P3.1? Both IAP15W4K58S4 and STC8A8K64S4A12 seem to be able to switch
these pins to some kind of USB mode for programming. For STC8A8K64S4A12 the
manual mentions P3.2 needs to be at low level at powerup for this to work.

The IAP15W4K58S4 manual mentions both P3.2 and P3.3 in this context and the
Windows ISP screens show a programming option that also affects the UART1
pins.

I think the stgal documentation also mentions these programming options
under the option keys section.

https://github.com/grigorig/stcgal/blob/master/doc/USAGE.md

Unfortunately I do not have any of these microcontrollers, as otherwise I
would be happy to experiment a bit as well.

If not already done: maybe a very simple test like clearing P3.0 or P3.1
using the normal P3 register or direct bit access can show if the GPIO
function does work as expected?

 Eric


> -Original Message-
> From: Philipp Klaus Krause [mailto:p...@spth.de] 
> Sent: donderdag 11 juni 2020 16:45
> To: sdcc-user@lists.sourceforge.net
> Subject: Re: [Sdcc-user] STC8A8K64S4A12 UART?
> 
> Am 07.06.20 um 22:22 schrieb Philipp Klaus Krause:
> > Am 07.06.20 um 21:41 schrieb Eric Rullens:
> >> Just a wild guess after browsing the manual: the UART pins can be 
> >> selected via S1_S[1:0] in P_SW1, and this setting does not 
> seem to have a default?
> >>
> >>  Eric
> > 
> > Interesting find, but when I try explicitly setting it to 0, it it 
> > doesn't make a difference.
> > 
> > Philipp
> 
> Looks like I can't get the UART to work on IAP15W4K58S4 
> either, tried the following there (the IAP15W4K58S4 is being 
> calibrated to 24 Mhz):
> 
> #include 
> 
> __sfr __at(0x88) TCON;
> __sfr __at(0x89) TMOD;
> __sfr __at(0x8b) TL1;
> __sfr __at(0x8d) TH1;
> 
> __sfr __at(0x98) SCON;
> __sfr __at(0x99) SBUF;
> 
> int putchar(int c)
> {
>   while(!(SCON & 0x02));
>   SCON &= ~0x02;
>   SBUF = c;
>   return (c);
> }
> 
> void main(void)
> {
>   unsigned long int i = 0;
> 
>   // Configure UART for 9600 baud, 8 data bits, 1 stop bit.
>   TMOD = 0x20;
>   SCON = 0x40;
>   TH1 = 256 - 24.0 * 1000 * 1000 / 12 / 32 / 9600 + 0.5;
>   TCON |= 0x40;
>   SCON |= 0x02;   // Tell 
> putchar() the UART is ready to send.
> 
>   for(;;)
>   {
>   printf("Hello World!\n");
>   for(i = 0; i < 147456; i++); // Sleep
>   }
> }
> 
> Philipp
> 
> 
> ___
> Sdcc-user mailing list
> Sdcc-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
> 


___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] STC8A8K64S4A12 CLKDIV?

2020-06-07 Thread Eric Rullens 
The manual shows several samples for doing this. The main trick seems to be
to enable access to the "special special" function registers in XRAM space.

"The following special function registers are expanded SFR and logical
address is located in the XDATA area. Before accessing, the P_SW2 (BAH)
register's highest position (EAXFR) is placed to 1. Then MOVX A, @DPTR and
MOVX @DPTR, A instruction are used to access."

E.g.

P_SW2 = 0x80;
CKSEL = 0x00; // Select the internal IRC (default)
P_SW2 = 0x00; 

I don't have access to this particular chip, but hope it helps anyway...

 Eric

 

> -Original Message-
> From: Philipp Klaus Krause [mailto:p...@spth.de] 
> Sent: zondag 7 juni 2020 13:58
> To: Sdcc-User
> Subject: [Sdcc-user] STC8A8K64S4A12 CLKDIV?
> 
> I'm trying to get some simple demo programs to work on an 
> STC8A8K64S4A12 board.
> 
> But it seems I don't understand CLKDIV.
> 
> * According to the datasheet, at system startup, the main 
> clock is 24 Mhz, and the system clock is the main clock 
> divided by CLKDIV, which has a reset value of 8, so I think 
> the system clock should be 3 Mhz.
> However, when I set up timer 0, which AFAIK is driven by the 
> system clock, to deliver intervals at a constant rate, it 
> behaves as if driven by a 24 Mhz clock.
> 
> * I don't know how to change SYCLK. According to the 
> datasheet, this is a memory-mapped register at address 
> 0xfe01. So I tried #define CLKDIV (*(__xdata uint8_t 
> *)(0xfe01)), but no matter what value I assign to it (tried 
> leaving it at the default that should be 8, tried setting to 
> 1, tried setting to 255), my program runs at exactly the same 
> speed (tested using an infinite loop of unsigned long 
> divisions and toggling LEDs based on the number of iterations).
> 
> Philipp
> 
> 
> ___
> Sdcc-user mailing list
> Sdcc-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
> 


___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] ucSim instruction cycle counts - where defined?

2020-07-22 Thread Eric Rullens 
Hi Basil,

Maybe it is not that simple. The STM8 has a prefetch buffer (for flash
access) and also sports pipelined execution. Under certain conditions the
pipeline is flushed and the CPU may be stalled. Then execution time is not
simply the sum of the (nominal) number cycles to execute an instruction. The
programming manual (PM0044) has more information on this.

Maybe due to the used addressing modes and looping strcspn() this is
particularly sensitive to these effects? If so, carefully arranging and/or
aligning instructions might help.

 Eric


> -Original Message-
> From: Basil Hussain [mailto:ba...@stasisleak.uk] 
> Sent: woensdag 22 juli 2020 15:11
> To: SDCC User Mailing List
> Subject: [Sdcc-user] ucSim instruction cycle counts - where defined?
> 
> Hi all,
> 
> In ucSim, where or what defines how many simulated cycles 
> each instruction takes? Specifically, I am looking at the 
> STM8 simulator.
> 
> I recently got around to running the benchmark of my assembly 
> implementations of some string.h functions (see patch #333 
> for details) on physical hardware and was surprised to find a 
> significant discrepancy for one piece of code in the 
> relationship between cycles measured by ucSim and execution 
> time on real hardware.
> 
> When plotted on an equivalent scale, sim cycles vs. H/W exec 
> time corresponds very closely everywhere, except for my 
> strcspn routine, where ucSim cycle count is significantly 
> lower compared to the H/W execution time.
> 
> I have a feeling ucSim might not be using the correct number 
> of cycles somewhere. Not sure where, though, because I'm not 
> using any unusual instructions in the strcspn assembly code 
> that aren't used elsewhere.
> 
> Regards,
> Basil Hussain
> 
> 
> ___
> Sdcc-user mailing list
> Sdcc-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
> 


___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] RAM program

2020-12-07 Thread Eric Rullens 
Just a question on this topic: why use the STM8 built-in bootloader routines
at all (other than for bootstrapping your own bootloader code)?

The flash/EEPROM controller is documented in the reference manual(s) and it
is very easy to code the few instructions that are required for erase/write
control.

Eric

 




From: Georg Icking-Konert [mailto:ge...@cream-tea.de] 
Sent: zaterdag 5 december 2020 08:55
To: sdcc-user@lists.sourceforge.net; Hynek Sladký
Subject: Re: [Sdcc-user] RAM program



Hi,

thanks a lot! Basil and me are now trying to replace the ST RAM
routines and use standard erase/write BL commands, instead of using the GO
command. Reason is that jumping back to BL after a GO command is unreliably
and apparently not intendended by STM.

Unfortunately passing of parameters between ROM BL and RAM routines
is not documented, so I am currently reverse-engineering this. Progress is
slow but we'll get there...  :-)

Thanks again!

Georg  





Am 05.12.20 um 08:11 schrieb Hynek Sladký:


Hi,

I tried to study bootloader code a bit...

As far as I can see there, 'Go' command in bootloader jumps
to user code using JPF [0x8A] instruction; at 0x8A it stores 24-bit part of
received address. There is no official support for return to bootloader...
But what about jumping back to 0x6000 address to start
bootloader again? Or maybe use illegal instruction opcode to force MCU to
reset?

Bootloader does some measurement and calculation for getting
real communication speed. Results are stored in RAM but I am not sure if
these values are retained after bootloader finishes.

BR,
Hynek




Dne 28.11.2020 v 08:19 Georg Icking-Konert napsal(a):


Hi Basil, 

(as always) thanks a lot for your feedback! Indeed I
had missed that information in the BL manual. 


Using your input I checked if returning to
bootloader is possible with a simple return. Here's what I did: 

  - my test device (STM8S105K6) has 2kB RAM, RAM
routine is at 0x500, i.e. well above bootloader 

  - I removed everything from the RAM routine except
return 

  - after "GOTO 0x500" (-> call RAM routine) the PC
waits a bit, and then tries to resume communication with the bootloader 





Strangely after return to STM8 bootloader the UART
baudrate has changed. Please see the screenshots of Rx/Tx stored at

https://c.1und1.de/@519544109849910202/-RlrrTShRRajv5CbUE1lOA
 

  - PC communicates with 19.2kBaud 


  - before RAM execution, the last STM8 reply
(="ACK" for "GOTO 0x500") is at 19.2kBaud -> ok (see GOTO_0x500.png) 

  - after return from RAM, the PC sends a "READ"
command at 19.2kBaud -> ok (see READ_CMD_PC.png) 

  - STM8 reply "ACK" is sent at 133.3kBaud, i.e. 7x
higher than before RAM execution -> NOK (see READ_RPLY_STM8.png) 


Additional information: 

  - neither changing CLK_CKDIVR nor UART2_BRR1/2
prior to the return has an impact on the reply baudrate 

  - bytes sent by the RAM routine use 19.2kBaud if
CLK_DIV is set to 0x00 -> issue occurs during the jump back to ROM
bootloader 


Any idea how to proceed? As always thanks a lot in
advance! 

Georg 




 
 
___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user




___
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Re: [Sdcc-user] RAM program

2020-12-07 Thread Eric Rullens 
Hi Georg,

Yes, that is exactly what I mean: load your own loader code in RAM and from
there you are free to do as you please. For example use a more efficient
protocol, and/or change to (higher) baudrates that are not supported by the
built-in bootloader.

I do this for NXP LPC and STM32 controllers and it works very well (adding
STM8 is on the wish list, but not with high priority at the moment). I would
not bother trying to write a "one size fits all" bootloader, just make
specialized ones for UART, SPI, CAN as required. Even 1 kB of RAM should be
plenty this way.

Aside from internal flash I also added loaders that can program external
EEPROM or serial flash. This is quite convenient to have.

In my case all the loaders have an option to reset the chip and restart the
built-in bootloader, so the whole process can be repeated (e.g. to first
program an external EEPROM and then the internal flash).

Eric


-Oorspronkelijk bericht-
Van: Georg Icking-Konert [mailto:ge...@cream-tea.de]
Verzonden: dinsdag 8 december 2020 07:41
Aan: Eric Rullens; 'sdcc-user@lists.sourceforge.net'; Hynek Sladký
CC: Basil Hussain
Onderwerp: Re: [Sdcc-user] RAM program


hi Eric,
the STM8 ROM bootloader does all the protocol handling and device specific
tests. Only the actual write and erase is executed from RAM. The routines
for this have to be uploaded to RAM first. This is described in the STM8
bootloader manual (UM0560). The repective hexfiles for various devices are
available from the ST homepage. However, as Phillip pointed out, they are
not OS but under a proprietary ST license. Unfortunately the parameter
passing from/to ROM<->RAM is not documented, so we have to reverse engineer
it.

But I guess that's not your question...!? If I understand correctly you
propose to use the ROM-BL only to upload a custom RAM bootloader which then
handles the communication, write/erase etc.. IMHO the main obstacle is RAM
size. As far as I can see the smallest device with ROM-BL has 1kB of RAM,
the biggest 6kB. The smaller ones only support UART, the larger ones UART,
SPI and CAN.
But apart from that I like the idea! Let me think about this and play around
a bit. If it can be made to fit RAM, that would also solve another issue,
namely that read-out in "UART reply mode" is extremly slow  :-)
Georg



Am 07.12.20 um 21:04 schrieb Eric Rullens:

Just a question on this topic: why use the STM8 built-in bootloader routines
at all (other than for bootstrapping your own bootloader code)?

The flash/EEPROM controller is documented in the reference manual(s) and it
is very easy to code the few instructions that are required for erase/write
control.

Eric

 




From: Georg Icking-Konert [mailto:ge...@cream-tea.de] 
Sent: zaterdag 5 december 2020 08:55
To: sdcc-user@lists.sourceforge.net; Hynek Sladký
Subject: Re: [Sdcc-user] RAM program



Hi,

thanks a lot! Basil and me are now trying to replace the ST RAM
routines and use standard erase/write BL commands, instead of using the GO
command. Reason is that jumping back to BL after a GO command is unreliably
and apparently not intendended by STM.

Unfortunately passing of parameters between ROM BL and RAM routines
is not documented, so I am currently reverse-engineering this. Progress is
slow but we'll get there...  :-)

Thanks again!

Georg  





Am 05.12.20 um 08:11 schrieb Hynek Sladký:


Hi,

I tried to study bootloader code a bit...

As far as I can see there, 'Go' command in bootloader jumps
to user code using JPF [0x8A] instruction; at 0x8A it stores 24-bit part of
received address. There is no official support for return to bootloader...
But what about jumping back to 0x6000 address to start
bootloader again? Or maybe use illegal instruction opcode to force MCU to
reset?

Bootloader does some measurement and calculation for getting
real communication speed. Results are stored in RAM but I am not sure if
these values are retained after bootloader finishes.

BR,
Hynek




Dne 28.11.2020 v 08:19 Georg Icking-Konert napsal(a):


Hi Basil, 

(as always) thanks a lot for your feedback! Indeed I
had missed that information in the BL manual. 


Using your input I checked if returning to
bootloader is possible with a simple return. Here's what I did: 

  - my test device (STM8S105K6) has 2kB RAM, RAM
routine is at 0x500,