Re: [Sdcc-user] STM8 >32kB code fails...?
Am 27.03.2018 um 09:30 schrieb Eric Rullens: > > 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 > With Erik's improvements in the assembler, and a few small improvements in the compiler ans simulator by me, the large memory model should now work much better, so this might be the time for further testing. 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
Re: [Sdcc-user] STM8 >32kB code fails...?
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] 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
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...?
Am 21.02.2018 um 22:34 schrieb Eric Rullens: > > 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 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 -- 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...?
Am 21.02.2018 um 22:34 schrieb Eric Rullens: > > 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. ;-) I would have no idea how to list all STM8 variants on the ST website; AFAIK one can only easily list those marketed under the STM8 name. And for some, I can't even find sufficient documentation to support them in teh free tools (e.g. the STWBC). > > 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 I have opened feature request #556 for this, and alreaedy implemented large parts of it. I suggest you have a look at current SDCC trunk. Since you already have some experience with 24-bit space support, you might be able to provide patches for the still-missing parts. 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
Re: [Sdcc-user] STM8 >32kB code fails...?
> 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] STM8 >32kB code fails...?
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. > I get the > feeling SDCC for STM8 will need a memory model option to target these two > situations. Yes. I guess we'd make the current one the medium model, then add a large model for 24-bit code space, then a huge model for 24-bit data space. 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
Re: [Sdcc-user] STM8 >32kB code fails...?
> Am 18.02.2018 um 07:50 schrieb Georg Icking-Konert: >> hello all, >> >> following a discussion on the updated STM8 SPL license (see >> https://github.com/gicking/STM8-SPL_SDCC_patch/issues/1 ) I happened to >> notice something strange: >> >> 1) build example including all SPL modules, where a pin toggles every >> 500ms >> >> Â Â Â - code adress range is 0x8000 to 0x1000c, i.e. >16-bit address >> range >> >> Â Â Â - according to map file, the topmost function starts at 0xFFE3, >> i.e. >> within 16bit address range >> >> Â Â Â -> code works as expected >> >> 2) build example including all SPL modules, where byte is sent via UART >> every 500ms >> >> Â Â Â - code adress range is 0x8000 to 0x10009, i.e. >16-bit address >> range >> >> Â Â Â - according to map file, the topmost function starts at 0xFFE0, >> i.e. >> within 16bit address range >> >> Â Â Â -> code works as expected >> >> 3) add pin toggling from 1) to 2) >> >> Â Â Â - code adress range is 0x8000 to 0x1002c, i.e. >16-bit address >> range >> >> Â Â Â - according to map file, the topmost function starts at 0x10003, >> i.e. outside 16bit address range >> >> Â Â Â -> no pin toggle, no UART output >> >> >> I am using SDCC 3.6.0 #9615 (Linux) >> >> It appears to me as if code with function start addresses >16b fail, >> while relative calls inside functions can exceed the 16b address >> range...? >> >> Is this just a mistake on my side (e.g. missing SDCC parameter), a known >> limitation, or a bug? I know that the 8051 (w/o long calls) works around >> this using code banking. From hardware side this is not required on the >> STM8, but what about SDCC (coming from 8051)...? >> >> For your feedback thanks a lot in advance! >> >> Regards, >> Georg > > This is a known limitation. Currently, SDCC only supports 16-bit > adresses for STM8, both for data and code. In particular, support for a > larger memory model that uses 24-bit addresses for code or data is not > yet implemented. > Implementing support for 24-bit code addresses wouldn't be that hard. > Implementing support for 24-bit data addresses would be more complicated. > > Philipp 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? 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? I get the feeling SDCC for STM8 will need a memory model option to target these two situations. 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
Re: [Sdcc-user] STM8 >32kB code fails...?
Am 18.02.2018 um 07:50 schrieb Georg Icking-Konert: > hello all, > > following a discussion on the updated STM8 SPL license (see > https://github.com/gicking/STM8-SPL_SDCC_patch/issues/1 ) I happened to > notice something strange: > > 1) build example including all SPL modules, where a pin toggles every 500ms > > - code adress range is 0x8000 to 0x1000c, i.e. >16-bit address range > > - according to map file, the topmost function starts at 0xFFE3, i.e. > within 16bit address range > > -> code works as expected > > 2) build example including all SPL modules, where byte is sent via UART > every 500ms > > - code adress range is 0x8000 to 0x10009, i.e. >16-bit address range > > - according to map file, the topmost function starts at 0xFFE0, i.e. > within 16bit address range > > -> code works as expected > > 3) add pin toggling from 1) to 2) > > - code adress range is 0x8000 to 0x1002c, i.e. >16-bit address range > > - according to map file, the topmost function starts at 0x10003, > i.e. outside 16bit address range > > -> no pin toggle, no UART output > > > I am using SDCC 3.6.0 #9615 (Linux) > > It appears to me as if code with function start addresses >16b fail, > while relative calls inside functions can exceed the 16b address range...? > > Is this just a mistake on my side (e.g. missing SDCC parameter), a known > limitation, or a bug? I know that the 8051 (w/o long calls) works around > this using code banking. From hardware side this is not required on the > STM8, but what about SDCC (coming from 8051)...? > > For your feedback thanks a lot in advance! > > Regards, > Georg This is a known limitation. Currently, SDCC only supports 16-bit adresses for STM8, both for data and code. In particular, support for a larger memory model that uses 24-bit addresses for code or data is not yet implemented. Implementing support for 24-bit code addresses wouldn't be that hard. Implementing support for 24-bit data addresses would be more complicated. 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
Re: [Sdcc-user] STM8 >32kB code fails...?
for an example please contact me via "icking at onlinehome.de", or apply SPL patch https://github.com/gicking/STM8-SPL_SDCC_patch/blob/master/STM8S_StdPeriph_Lib_sdcc.patch and compile "Projects/STM8S_StdPeriph_test_ok" (case 1) and "Projects/STM8S_StdPeriph_test_fail_32k" (case 3) -- 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
