sdcc-user — Help and Discussion for SDCC users
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(27) |
Apr
(107) |
May
(32) |
Jun
(45) |
Jul
(79) |
Aug
(61) |
Sep
(94) |
Oct
(89) |
Nov
(133) |
Dec
(45) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(81) |
Feb
(57) |
Mar
(85) |
Apr
(80) |
May
(79) |
Jun
(85) |
Jul
(97) |
Aug
(104) |
Sep
(60) |
Oct
(82) |
Nov
(49) |
Dec
(57) |
| 2002 |
Jan
(46) |
Feb
(80) |
Mar
(112) |
Apr
(93) |
May
(72) |
Jun
(89) |
Jul
(118) |
Aug
(130) |
Sep
(67) |
Oct
(49) |
Nov
(58) |
Dec
(99) |
| 2003 |
Jan
(281) |
Feb
(141) |
Mar
(231) |
Apr
(109) |
May
(128) |
Jun
(166) |
Jul
(243) |
Aug
(64) |
Sep
(44) |
Oct
(67) |
Nov
(70) |
Dec
(68) |
| 2004 |
Jan
(71) |
Feb
(88) |
Mar
(60) |
Apr
(84) |
May
(79) |
Jun
(168) |
Jul
(92) |
Aug
(72) |
Sep
(51) |
Oct
(102) |
Nov
(35) |
Dec
(73) |
| 2005 |
Jan
(65) |
Feb
(48) |
Mar
(86) |
Apr
(64) |
May
(107) |
Jun
(93) |
Jul
(40) |
Aug
(117) |
Sep
(82) |
Oct
(65) |
Nov
(63) |
Dec
(85) |
| 2006 |
Jan
(36) |
Feb
(81) |
Mar
(74) |
Apr
(131) |
May
(92) |
Jun
(71) |
Jul
(71) |
Aug
(54) |
Sep
(26) |
Oct
(77) |
Nov
(55) |
Dec
(55) |
| 2007 |
Jan
(112) |
Feb
(88) |
Mar
(105) |
Apr
(46) |
May
(28) |
Jun
(53) |
Jul
(29) |
Aug
(34) |
Sep
(74) |
Oct
(83) |
Nov
(67) |
Dec
(39) |
| 2008 |
Jan
(40) |
Feb
(105) |
Mar
(42) |
Apr
(25) |
May
(91) |
Jun
(32) |
Jul
(47) |
Aug
(128) |
Sep
(188) |
Oct
(54) |
Nov
(19) |
Dec
(41) |
| 2009 |
Jan
(145) |
Feb
(88) |
Mar
(117) |
Apr
(38) |
May
(53) |
Jun
(9) |
Jul
(47) |
Aug
(10) |
Sep
(28) |
Oct
(65) |
Nov
(97) |
Dec
(36) |
| 2010 |
Jan
(55) |
Feb
(87) |
Mar
(81) |
Apr
(30) |
May
(37) |
Jun
(15) |
Jul
(85) |
Aug
(31) |
Sep
(1) |
Oct
(69) |
Nov
(69) |
Dec
(32) |
| 2011 |
Jan
(37) |
Feb
(49) |
Mar
(55) |
Apr
(27) |
May
(67) |
Jun
(30) |
Jul
(43) |
Aug
(73) |
Sep
(65) |
Oct
(89) |
Nov
(59) |
Dec
(15) |
| 2012 |
Jan
(27) |
Feb
(48) |
Mar
(14) |
Apr
(18) |
May
(38) |
Jun
(59) |
Jul
(46) |
Aug
(11) |
Sep
(21) |
Oct
(28) |
Nov
(18) |
Dec
(51) |
| 2013 |
Jan
(35) |
Feb
(68) |
Mar
(56) |
Apr
(21) |
May
(62) |
Jun
(43) |
Jul
(12) |
Aug
(34) |
Sep
(28) |
Oct
|
Nov
(11) |
Dec
(33) |
| 2014 |
Jan
(15) |
Feb
(36) |
Mar
(33) |
Apr
(45) |
May
(8) |
Jun
(52) |
Jul
(30) |
Aug
(7) |
Sep
(38) |
Oct
(76) |
Nov
(19) |
Dec
(26) |
| 2015 |
Jan
(67) |
Feb
(42) |
Mar
(6) |
Apr
(12) |
May
(13) |
Jun
(17) |
Jul
(10) |
Aug
(9) |
Sep
(26) |
Oct
(24) |
Nov
(8) |
Dec
(2) |
| 2016 |
Jan
(19) |
Feb
(2) |
Mar
(33) |
Apr
(56) |
May
(10) |
Jun
(12) |
Jul
(38) |
Aug
(69) |
Sep
(10) |
Oct
(7) |
Nov
(20) |
Dec
(26) |
| 2017 |
Jan
(10) |
Feb
(10) |
Mar
(4) |
Apr
(4) |
May
(16) |
Jun
(13) |
Jul
(16) |
Aug
(25) |
Sep
|
Oct
(28) |
Nov
|
Dec
(1) |
| 2018 |
Jan
(31) |
Feb
(24) |
Mar
(38) |
Apr
(18) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Casainho <casainho@gm...> - 2018-04-15 22:06:47
|
Thank you Raphael. After testing, the main issue still persist. I will fill the bug. cas@...:~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ make -f Makefile_linux sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_itc.c StdPeriphLib/src/stm8s_itc.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_clk.c StdPeriphLib/src/stm8s_clk.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_iwdg.c StdPeriphLib/src/stm8s_iwdg.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_gpio.c StdPeriphLib/src/stm8s_gpio.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_exti.c StdPeriphLib/src/stm8s_exti.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_uart2.c StdPeriphLib/src/stm8s_uart2.c Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp4. Please contact sdcc authors with source code to reproduce. sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_tim1.c StdPeriphLib/src/stm8s_tim1.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_tim2.c StdPeriphLib/src/stm8s_tim2.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_adc1.c StdPeriphLib/src/stm8s_adc1.c Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp1. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp1. Please contact sdcc authors with source code to reproduce. sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_flash.c StdPeriphLib/src/stm8s_flash.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -owatchdog.c watchdog.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -ogpio.c gpio.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -outils.c utils.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -ouart.c uart.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oadc.c adc.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -obrake.c brake.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -opas.c pas.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -owheel_speed_sensor.c wheel_speed_sensor.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -otimers.c timers.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -opwm.c pwm.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oeeprom.c eeprom.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -omotor.c motor.c Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp152. Please contact sdcc authors with source code to reproduce. sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oebike_app.c ebike_app.c ebike_app.c:165: warning 110: conditional flow changed by optimizer: so said EVELYN the modified DOG Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp13. Please contact sdcc authors with source code to reproduce. ebike_app.asm:4826: Error: <r> relocation error Segmentation fault (core dumped) Makefile_linux:79: recipe for target 'ebike_app.rel' failed make: *** [ebike_app.rel] Error 1 cas@... :~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ Raphael Neider <rneider@...> escreveu no dia domingo, 15/04/2018 à(s) 21:52: > Hi, > > I spotted > > ebike_app.c:315: warning 156: symbol name too long, truncated to 64 chars > > in the falling output but not in the working one. Could this be the cause? > Can you try using a short identifier (static uint16_t a = 100;) and try > again? If that still fails, can you try to also shorten the identifier of > the function (like com_ctl())? > > Best regards, > Raphael > > > Maarten Brock <sourceforge.brock@...> schrieb am So., 15. Apr. 2018, > 21:41: > >> > Hi Marteen. >> > >> > I am using the stable version 3.7.0. >> > I am on Linux and I can build some developent version and test before >> > write on bug tracker - what do you recommend? >> >> 3.7.0 is recent enough to file this as a bug. >> >> 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@... >> 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@... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Cumprimentos, Jorge Pinto E-mail: casainho@... Telemóvel: 927145983 |
|
From: Raphael Neider <rneider@we...> - 2018-04-15 20:51:47
|
Hi, I spotted ebike_app.c:315: warning 156: symbol name too long, truncated to 64 chars in the falling output but not in the working one. Could this be the cause? Can you try using a short identifier (static uint16_t a = 100;) and try again? If that still fails, can you try to also shorten the identifier of the function (like com_ctl())? Best regards, Raphael Maarten Brock <sourceforge.brock@...> schrieb am So., 15. Apr. 2018, 21:41: > > Hi Marteen. > > > > I am using the stable version 3.7.0. > > I am on Linux and I can build some developent version and test before > > write on bug tracker - what do you recommend? > > 3.7.0 is recent enough to file this as a bug. > > 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@... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
|
From: Maarten Brock <sourceforge.brock@ds...> - 2018-04-15 19:41:19
|
> Hi Marteen. > > I am using the stable version 3.7.0. > I am on Linux and I can build some developent version and test before > write on bug tracker - what do you recommend? 3.7.0 is recent enough to file this as a bug. Maarten |
|
From: Casainho <casainho@gm...> - 2018-04-15 19:09:04
|
Hi Marteen. I am using the stable version 3.7.0. I am on Linux and I can build some developent version and test before write on bug tracker - what do you recommend? A domingo, 15/04/2018, 19:46, Maarten Brock <sourceforge.brock@...> escreveu: > Hello Jorge, > > Did you use a recent version of SDCC? If so, this looks like a bug so > please post this to our bug tracker. Dot not forget to mention the SDCC > version you're using. > > Regards, > Maarten > > > Hi. > > > > I can't use static variables inside functions or I get "Error: <r> > > relocation error". My solution has been avoid them and use as global but > > the firmware is growing and it makes a mess to read and understand... > > Please see bellow the examples of how it fails and the build error. > > > > This is my first message to SDCC mailing list I would you like to give a > > BIG <3 THANK YOU for everyone involved!! I started a project to develop > > (the very first) OpenSource firmware for Bicycle/EBikes, popular, cheap > > and Chinese motor controllers and for the success of the project we need > > to use > > free tools so more developers can join, which happened and was a great > > success. Again, thank you for helping us working towards a better green > > environment <3 > > Project page: https://opensourceebikefirmware.bitbucket.io > > > > When I build with for instance a static variable initializing with a > > value: > > > > void communications_controller (void) > > { > > static uint16_t ui16_battery_current_accumulated = 100; > > > > cas@... > :~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ > > make -f Makefile_linux > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_itc.c > > StdPeriphLib/src/stm8s_itc.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_clk.c > > StdPeriphLib/src/stm8s_clk.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_iwdg.c > > StdPeriphLib/src/stm8s_iwdg.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_gpio.c > > StdPeriphLib/src/stm8s_gpio.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_exti.c > > StdPeriphLib/src/stm8s_exti.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_uart2.c > > StdPeriphLib/src/stm8s_uart2.c > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp4. Please contact sdcc authors with source code to > > reproduce. > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_tim1.c > > StdPeriphLib/src/stm8s_tim1.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_tim2.c > > StdPeriphLib/src/stm8s_tim2.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_adc1.c > > StdPeriphLib/src/stm8s_adc1.c > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp0. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp0. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp1. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp0. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp0. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp1. Please contact sdcc authors with source code to > > reproduce. > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_flash.c > > StdPeriphLib/src/stm8s_flash.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -owatchdog.c watchdog.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -ogpio.c gpio.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -outils.c utils.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -ouart.c uart.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oadc.c adc.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -obrake.c brake.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -opas.c pas.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -owheel_speed_sensor.c wheel_speed_sensor.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -otimers.c timers.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -opwm.c pwm.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oeeprom.c eeprom.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -omotor.c motor.c > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp152. Please contact sdcc authors with source code to > > reproduce. > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oebike_app.c ebike_app.c > > ebike_app.c:165: warning 110: conditional flow changed by optimizer: so > > said EVELYN the modified DOG > > ebike_app.c:315: warning 156: symbol name too long, truncated to 64 chars > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp44. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp44. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp44. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp44. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp32. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp32. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp32. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp32. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp0. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp13. Please contact sdcc authors with source code to > > reproduce. > > ebike_app.asm:4826: Error: <r> relocation error > > Segmentation fault (core dumped) > > Makefile_linux:79: recipe for target 'ebike_app.rel' failed > > make: *** [ebike_app.rel] Error 1 > > cas@... > > :~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ > > > > > > Now without value initialization: > > > > void communications_controller (void) > > { > > static uint16_t ui16_battery_current_accumulated; > > > > cas@... > :~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ > > make -f Makefile_linux > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_itc.c > > StdPeriphLib/src/stm8s_itc.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_clk.c > > StdPeriphLib/src/stm8s_clk.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_iwdg.c > > StdPeriphLib/src/stm8s_iwdg.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_gpio.c > > StdPeriphLib/src/stm8s_gpio.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_exti.c > > StdPeriphLib/src/stm8s_exti.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_uart2.c > > StdPeriphLib/src/stm8s_uart2.c > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp4. Please contact sdcc authors with source code to > > reproduce. > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_tim1.c > > StdPeriphLib/src/stm8s_tim1.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_tim2.c > > StdPeriphLib/src/stm8s_tim2.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_adc1.c > > StdPeriphLib/src/stm8s_adc1.c > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp0. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp0. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp1. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp0. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp0. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp1. Please contact sdcc authors with source code to > > reproduce. > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_flash.c > > StdPeriphLib/src/stm8s_flash.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -owatchdog.c watchdog.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -ogpio.c gpio.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -outils.c utils.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -ouart.c uart.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oadc.c adc.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -obrake.c brake.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -opas.c pas.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -owheel_speed_sensor.c wheel_speed_sensor.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -otimers.c timers.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -opwm.c pwm.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oeeprom.c eeprom.c > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -omotor.c motor.c > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp152. Please contact sdcc authors with source code to > > reproduce. > > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 > --nolospre > > --out-fmt-elf --debug -oebike_app.c ebike_app.c > > ebike_app.c:165: warning 110: conditional flow changed by optimizer: so > > said EVELYN the modified DOG > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp44. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp44. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp44. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp44. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp32. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp32. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp32. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp32. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp0. Please contact sdcc authors with source code to > > reproduce. > > Warning: Non-connected liverange found and extended to connected > component > > of the CFG:iTemp13. Please contact sdcc authors with source code to > > reproduce. > > sdcc -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > > --out-fmt-elf --debug main.c StdPeriphLib/src/stm8s_itc.rel > > StdPeriphLib/src/stm8s_clk.rel StdPeriphLib/src/stm8s_iwdg.rel > > StdPeriphLib/src/stm8s_gpio.rel StdPeriphLib/src/stm8s_exti.rel > > StdPeriphLib/src/stm8s_uart2.rel StdPeriphLib/src/stm8s_tim1.rel > > StdPeriphLib/src/stm8s_tim2.rel StdPeriphLib/src/stm8s_adc1.rel > > StdPeriphLib/src/stm8s_flash.rel watchdog.rel gpio.rel utils.rel uart.rel > > adc.rel brake.rel pas.rel wheel_speed_sensor.rel timers.rel pwm.rel > > eeprom.rel motor.rel ebike_app.rel > > main.c:131: warning 126: unreachable code > > stm8-size main.elf -A > > main.elf : > > section size addr > > DATA 109 1 > > INITIALIZED 335 110 > > SSEG 1 4294967295 > > HOME 99 32768 > > GSINIT 26 32867 > > GSFINAL 3 32893 > > CODE 18289 32896 > > INITIALIZER 335 51185 > > .debug_line 24248 0 > > .debug_loc 22308 0 > > .debug_abbrev 2738 0 > > .debug_info 35791 0 > > .debug_pubnames 11646 0 > > .debug_frame 22693 0 > > Total 138621 > > > > > > stm8-objcopy -O binary -R DATA -R INITIALIZED -R SSEG -R .debug_line -R > > .debug_loc -R .debug_abbrev -R .debug_info -R .debug_pubnames -R > > .debug_frame main.elf main.bin > > cas@... > > :~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ > > > > Regards > > Jorge Pinto > > > > > ------------------------------------------------------------------------------ > 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@... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
|
From: Maarten Brock <sourceforge.brock@ds...> - 2018-04-15 18:45:54
|
Hello Jorge, Did you use a recent version of SDCC? If so, this looks like a bug so please post this to our bug tracker. Dot not forget to mention the SDCC version you're using. Regards, Maarten > Hi. > > I can't use static variables inside functions or I get "Error: <r> > relocation error". My solution has been avoid them and use as global but > the firmware is growing and it makes a mess to read and understand... > Please see bellow the examples of how it fails and the build error. > > This is my first message to SDCC mailing list I would you like to give a > BIG <3 THANK YOU for everyone involved!! I started a project to develop > (the very first) OpenSource firmware for Bicycle/EBikes, popular, cheap > and Chinese motor controllers and for the success of the project we need > to use > free tools so more developers can join, which happened and was a great > success. Again, thank you for helping us working towards a better green > environment <3 > Project page: https://opensourceebikefirmware.bitbucket.io > > When I build with for instance a static variable initializing with a > value: > > void communications_controller (void) > { > static uint16_t ui16_battery_current_accumulated = 100; > > cas@...:~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ > make -f Makefile_linux > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_itc.c > StdPeriphLib/src/stm8s_itc.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_clk.c > StdPeriphLib/src/stm8s_clk.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_iwdg.c > StdPeriphLib/src/stm8s_iwdg.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_gpio.c > StdPeriphLib/src/stm8s_gpio.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_exti.c > StdPeriphLib/src/stm8s_exti.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_uart2.c > StdPeriphLib/src/stm8s_uart2.c > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp4. Please contact sdcc authors with source code to > reproduce. > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_tim1.c > StdPeriphLib/src/stm8s_tim1.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_tim2.c > StdPeriphLib/src/stm8s_tim2.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_adc1.c > StdPeriphLib/src/stm8s_adc1.c > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp0. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp0. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp1. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp0. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp0. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp1. Please contact sdcc authors with source code to > reproduce. > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_flash.c > StdPeriphLib/src/stm8s_flash.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -owatchdog.c watchdog.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -ogpio.c gpio.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -outils.c utils.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -ouart.c uart.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oadc.c adc.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -obrake.c brake.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -opas.c pas.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -owheel_speed_sensor.c wheel_speed_sensor.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -otimers.c timers.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -opwm.c pwm.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oeeprom.c eeprom.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -omotor.c motor.c > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp152. Please contact sdcc authors with source code to > reproduce. > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oebike_app.c ebike_app.c > ebike_app.c:165: warning 110: conditional flow changed by optimizer: so > said EVELYN the modified DOG > ebike_app.c:315: warning 156: symbol name too long, truncated to 64 chars > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp44. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp44. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp44. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp44. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp32. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp32. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp32. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp32. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp0. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp13. Please contact sdcc authors with source code to > reproduce. > ebike_app.asm:4826: Error: <r> relocation error > Segmentation fault (core dumped) > Makefile_linux:79: recipe for target 'ebike_app.rel' failed > make: *** [ebike_app.rel] Error 1 > cas@... > :~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ > > > Now without value initialization: > > void communications_controller (void) > { > static uint16_t ui16_battery_current_accumulated; > > cas@...:~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ > make -f Makefile_linux > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_itc.c > StdPeriphLib/src/stm8s_itc.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_clk.c > StdPeriphLib/src/stm8s_clk.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_iwdg.c > StdPeriphLib/src/stm8s_iwdg.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_gpio.c > StdPeriphLib/src/stm8s_gpio.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_exti.c > StdPeriphLib/src/stm8s_exti.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_uart2.c > StdPeriphLib/src/stm8s_uart2.c > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp4. Please contact sdcc authors with source code to > reproduce. > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_tim1.c > StdPeriphLib/src/stm8s_tim1.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_tim2.c > StdPeriphLib/src/stm8s_tim2.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_adc1.c > StdPeriphLib/src/stm8s_adc1.c > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp0. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp0. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp1. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp0. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp0. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp1. Please contact sdcc authors with source code to > reproduce. > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_flash.c > StdPeriphLib/src/stm8s_flash.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -owatchdog.c watchdog.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -ogpio.c gpio.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -outils.c utils.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -ouart.c uart.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oadc.c adc.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -obrake.c brake.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -opas.c pas.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -owheel_speed_sensor.c wheel_speed_sensor.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -otimers.c timers.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -opwm.c pwm.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oeeprom.c eeprom.c > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -omotor.c motor.c > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp152. Please contact sdcc authors with source code to > reproduce. > sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug -oebike_app.c ebike_app.c > ebike_app.c:165: warning 110: conditional flow changed by optimizer: so > said EVELYN the modified DOG > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp44. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp44. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp44. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp44. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp32. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp32. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp32. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp32. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp0. Please contact sdcc authors with source code to > reproduce. > Warning: Non-connected liverange found and extended to connected component > of the CFG:iTemp13. Please contact sdcc authors with source code to > reproduce. > sdcc -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre > --out-fmt-elf --debug main.c StdPeriphLib/src/stm8s_itc.rel > StdPeriphLib/src/stm8s_clk.rel StdPeriphLib/src/stm8s_iwdg.rel > StdPeriphLib/src/stm8s_gpio.rel StdPeriphLib/src/stm8s_exti.rel > StdPeriphLib/src/stm8s_uart2.rel StdPeriphLib/src/stm8s_tim1.rel > StdPeriphLib/src/stm8s_tim2.rel StdPeriphLib/src/stm8s_adc1.rel > StdPeriphLib/src/stm8s_flash.rel watchdog.rel gpio.rel utils.rel uart.rel > adc.rel brake.rel pas.rel wheel_speed_sensor.rel timers.rel pwm.rel > eeprom.rel motor.rel ebike_app.rel > main.c:131: warning 126: unreachable code > stm8-size main.elf -A > main.elf : > section size addr > DATA 109 1 > INITIALIZED 335 110 > SSEG 1 4294967295 > HOME 99 32768 > GSINIT 26 32867 > GSFINAL 3 32893 > CODE 18289 32896 > INITIALIZER 335 51185 > .debug_line 24248 0 > .debug_loc 22308 0 > .debug_abbrev 2738 0 > .debug_info 35791 0 > .debug_pubnames 11646 0 > .debug_frame 22693 0 > Total 138621 > > > stm8-objcopy -O binary -R DATA -R INITIALIZED -R SSEG -R .debug_line -R > .debug_loc -R .debug_abbrev -R .debug_info -R .debug_pubnames -R > .debug_frame main.elf main.bin > cas@... > :~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ > > Regards > Jorge Pinto |
|
From: Casainho <casainho@gm...> - 2018-04-15 18:25:06
|
Hi. I can't use static variables inside functions or I get "Error: <r> relocation error". My solution has been avoid them and use as global but the firmware is growing and it makes a mess to read and understand... Please see bellow the examples of how it fails and the build error. This is my first message to SDCC mailing list I would you like to give a BIG <3 THANK YOU for everyone involved!! I started a project to develop (the very first) OpenSource firmware for Bicycle/EBikes, popular, cheap and Chinese motor controllers and for the success of the project we need to use free tools so more developers can join, which happened and was a great success. Again, thank you for helping us working towards a better green environment <3 Project page: https://opensourceebikefirmware.bitbucket.io When I build with for instance a static variable initializing with a value: void communications_controller (void) { static uint16_t ui16_battery_current_accumulated = 100; cas@...:~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ make -f Makefile_linux sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_itc.c StdPeriphLib/src/stm8s_itc.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_clk.c StdPeriphLib/src/stm8s_clk.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_iwdg.c StdPeriphLib/src/stm8s_iwdg.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_gpio.c StdPeriphLib/src/stm8s_gpio.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_exti.c StdPeriphLib/src/stm8s_exti.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_uart2.c StdPeriphLib/src/stm8s_uart2.c Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp4. Please contact sdcc authors with source code to reproduce. sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_tim1.c StdPeriphLib/src/stm8s_tim1.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_tim2.c StdPeriphLib/src/stm8s_tim2.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_adc1.c StdPeriphLib/src/stm8s_adc1.c Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp1. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp1. Please contact sdcc authors with source code to reproduce. sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_flash.c StdPeriphLib/src/stm8s_flash.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -owatchdog.c watchdog.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -ogpio.c gpio.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -outils.c utils.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -ouart.c uart.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oadc.c adc.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -obrake.c brake.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -opas.c pas.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -owheel_speed_sensor.c wheel_speed_sensor.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -otimers.c timers.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -opwm.c pwm.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oeeprom.c eeprom.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -omotor.c motor.c Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp152. Please contact sdcc authors with source code to reproduce. sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oebike_app.c ebike_app.c ebike_app.c:165: warning 110: conditional flow changed by optimizer: so said EVELYN the modified DOG ebike_app.c:315: warning 156: symbol name too long, truncated to 64 chars Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp13. Please contact sdcc authors with source code to reproduce. ebike_app.asm:4826: Error: <r> relocation error Segmentation fault (core dumped) Makefile_linux:79: recipe for target 'ebike_app.rel' failed make: *** [ebike_app.rel] Error 1 cas@... :~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ Now without value initialization: void communications_controller (void) { static uint16_t ui16_battery_current_accumulated; cas@...:~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ make -f Makefile_linux sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_itc.c StdPeriphLib/src/stm8s_itc.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_clk.c StdPeriphLib/src/stm8s_clk.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_iwdg.c StdPeriphLib/src/stm8s_iwdg.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_gpio.c StdPeriphLib/src/stm8s_gpio.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_exti.c StdPeriphLib/src/stm8s_exti.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_uart2.c StdPeriphLib/src/stm8s_uart2.c Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp4. Please contact sdcc authors with source code to reproduce. sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_tim1.c StdPeriphLib/src/stm8s_tim1.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_tim2.c StdPeriphLib/src/stm8s_tim2.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_adc1.c StdPeriphLib/src/stm8s_adc1.c Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp1. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp1. Please contact sdcc authors with source code to reproduce. sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oStdPeriphLib/src/stm8s_flash.c StdPeriphLib/src/stm8s_flash.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -owatchdog.c watchdog.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -ogpio.c gpio.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -outils.c utils.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -ouart.c uart.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oadc.c adc.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -obrake.c brake.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -opas.c pas.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -owheel_speed_sensor.c wheel_speed_sensor.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -otimers.c timers.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -opwm.c pwm.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oeeprom.c eeprom.c sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -omotor.c motor.c Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp152. Please contact sdcc authors with source code to reproduce. sdcc -c -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug -oebike_app.c ebike_app.c ebike_app.c:165: warning 110: conditional flow changed by optimizer: so said EVELYN the modified DOG Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce. Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp13. Please contact sdcc authors with source code to reproduce. sdcc -IStdPeriphLib/inc -I. -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug main.c StdPeriphLib/src/stm8s_itc.rel StdPeriphLib/src/stm8s_clk.rel StdPeriphLib/src/stm8s_iwdg.rel StdPeriphLib/src/stm8s_gpio.rel StdPeriphLib/src/stm8s_exti.rel StdPeriphLib/src/stm8s_uart2.rel StdPeriphLib/src/stm8s_tim1.rel StdPeriphLib/src/stm8s_tim2.rel StdPeriphLib/src/stm8s_adc1.rel StdPeriphLib/src/stm8s_flash.rel watchdog.rel gpio.rel utils.rel uart.rel adc.rel brake.rel pas.rel wheel_speed_sensor.rel timers.rel pwm.rel eeprom.rel motor.rel ebike_app.rel main.c:131: warning 126: unreachable code stm8-size main.elf -A main.elf : section size addr DATA 109 1 INITIALIZED 335 110 SSEG 1 4294967295 HOME 99 32768 GSINIT 26 32867 GSFINAL 3 32893 CODE 18289 32896 INITIALIZER 335 51185 .debug_line 24248 0 .debug_loc 22308 0 .debug_abbrev 2738 0 .debug_info 35791 0 .debug_pubnames 11646 0 .debug_frame 22693 0 Total 138621 stm8-objcopy -O binary -R DATA -R INITIALIZED -R SSEG -R .debug_line -R .debug_loc -R .debug_abbrev -R .debug_info -R .debug_pubnames -R .debug_frame main.elf main.bin cas@... :~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ Regards Jorge Pinto |
|
From: Philipp Klaus Krause <pkk@sp...> - 2018-04-13 17:11:06
|
Am 07.04.2018 um 18:31 schrieb Maarten Brock:
>> Am 07.04.2018 um 15:50 schrieb Maarten Brock:
>>
>>> I see in the stm8-large regression that you fixed it by loading the
>>> least
>>> significant word into x and the most significant byte into a and write
>>> those to the function pointer location as you need them. Is this an OK
>>> solution or would you still prefer the most significant word in x and
>>> the least significant byte in a?
>>>
>>
>> The current solution is a bit of an ugly hack, but will certainly be
>> good enough for nearly all users. From this side the issue isn't a big
>> deal any more.
>>
>> However, the >> 8 bug on the assembler / linker side still seems
>> dangerous to me, in case someone tries to use >> 8 in asm code. After
>> all it not just loads wrong data, but also silently overwrites the
>> following instruction.
>>
>> Philipp
>
> Can you check if my commit of today fixes this?
>
> Maarten
It is no longer a silent failure. Compiling
void main(void)
{
__asm
ldw x, #(_main >> 8)
__endasm;
}
Now gives:
***Internal error: C24 out in outrw()
test.asm:83: Error: <r> relocation error
removing test.rel
Philipp
|
|
From: Maarten Brock <sourceforge.brock@ds...> - 2018-04-07 16:56:21
|
> Am 07.04.2018 um 18:31 schrieb Maarten Brock: >>> Am 07.04.2018 um 15:50 schrieb Maarten Brock: >>> >>>> I see in the stm8-large regression that you fixed it by loading the >>>> least >>>> significant word into x and the most significant byte into a and write >>>> those to the function pointer location as you need them. Is this an OK >>>> solution or would you still prefer the most significant word in x and >>>> the least significant byte in a? >>>> >>> >>> The current solution is a bit of an ugly hack, but will certainly be >>> good enough for nearly all users. From this side the issue isn't a big >>> deal any more. >>> >>> However, the >> 8 bug on the assembler / linker side still seems >>> dangerous to me, in case someone tries to use >> 8 in asm code. After >>> all it not just loads wrong data, but also silently overwrites the >>> following instruction. >>> >>> Philipp >> >> Can you check if my commit of today fixes this? >> >> Maarten > > Thanks. I'll check later this week. I'm currently travelling, the > airport WiFi here is a bit slow and doesn't seem to allow svn. > > Philipp Well SF is in a bad shape as well today. Lots of timeouts. Maarten |
|
From: Philipp Klaus Krause <pkk@sp...> - 2018-04-07 16:43:39
|
Am 07.04.2018 um 18:31 schrieb Maarten Brock: >> Am 07.04.2018 um 15:50 schrieb Maarten Brock: >> >>> I see in the stm8-large regression that you fixed it by loading the >>> least >>> significant word into x and the most significant byte into a and write >>> those to the function pointer location as you need them. Is this an OK >>> solution or would you still prefer the most significant word in x and >>> the least significant byte in a? >>> >> >> The current solution is a bit of an ugly hack, but will certainly be >> good enough for nearly all users. From this side the issue isn't a big >> deal any more. >> >> However, the >> 8 bug on the assembler / linker side still seems >> dangerous to me, in case someone tries to use >> 8 in asm code. After >> all it not just loads wrong data, but also silently overwrites the >> following instruction. >> >> Philipp > > Can you check if my commit of today fixes this? > > Maarten Thanks. I'll check later this week. I'm currently travelling, the airport WiFi here is a bit slow and doesn't seem to allow svn. Philipp |
|
From: Maarten Brock <sourceforge.brock@ds...> - 2018-04-07 16:31:55
|
> Am 07.04.2018 um 15:50 schrieb Maarten Brock: > >> I see in the stm8-large regression that you fixed it by loading the >> least >> significant word into x and the most significant byte into a and write >> those to the function pointer location as you need them. Is this an OK >> solution or would you still prefer the most significant word in x and >> the least significant byte in a? >> > > The current solution is a bit of an ugly hack, but will certainly be > good enough for nearly all users. From this side the issue isn't a big > deal any more. > > However, the >> 8 bug on the assembler / linker side still seems > dangerous to me, in case someone tries to use >> 8 in asm code. After > all it not just loads wrong data, but also silently overwrites the > following instruction. > > Philipp Can you check if my commit of today fixes this? Maarten |
|
From: Philipp Klaus Krause <pkk@sp...> - 2018-04-07 14:51:54
|
Am 07.04.2018 um 15:50 schrieb Maarten Brock: > I see in the stm8-large regression that you fixed it by loading the least > significant word into x and the most significant byte into a and write > those to the function pointer location as you need them. Is this an OK > solution or would you still prefer the most significant word in x and the > least significant byte in a? > The current solution is a bit of an ugly hack, but will certainly be good enough for nearly all users. From this side the issue isn't a big deal any more. However, the >> 8 bug on the assembler / linker side still seems dangerous to me, in case someone tries to use >> 8 in asm code. After all it not just loads wrong data, but also silently overwrites the following instruction. Philipp |
|
From: Maarten Brock <sourceforge.brock@ds...> - 2018-04-07 14:16:17
|
> 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:
> 000000 9D [ 1] 87 nop
> 000001 AEr00r00 [ 2] 88 ldw x, #(_main >> 8)
> 000004 9D [ 1] 89 nop
> 000005 87 [ 5] 94 retf
>
> And this binary:
>
> :04F000008200F00892
> :1DF00800AE00002707724F00005A26F9AE00002709D6F02AD700005A26F7CCF004F9
> :04F00400AC00F02547
> :06F025009DAE00F0C28761
> :00000001FF
>
> 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
I see in the stm8-large regression that you fixed it by loading the least
significant word into x and the most significant byte into a and write
those to the function pointer location as you need them. Is this an OK
solution or would you still prefer the most significant word in x and the
least significant byte in a?
I think the problem comes from the fact that Erik only patched outrxb() in
asout.c and not outrw().
I've been looking at the .msb keyword, but that got introduced in asxxxx
v4 to which we have not synchronized yet. That means that we can only use
the right-shift operator and only for targets that use the sdas exception
in asout.c. I don't really know a good reason not to use the exception for
all targets, though.
Maarten
|
|
From: Eric Rullens <e.rullens@ds...> - 2018-04-06 13:25:48
|
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:
010050 123 _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
010058 9D [ 1] 134 nop
010059 9D [ 1] 135 nop
136 ; Load mid byte (xl is set to
0).
137 ; Does not seem to work with
relocatable symbol (relocation error).
01005A AE 00 22 [ 2] 138 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:pkk@...]
> Verzonden: vrijdag 6 april 2018 14:24
> Aan: sdcc-user@...
> 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:
> 000000 9D [ 1] 87 nop
> 000001 AEr00r00 [ 2] 88 ldw x, #(_main >> 8)
> 000004 9D [ 1] 89 nop
> 000005 87 [ 5] 94 retf
>
> And this binary:
>
> :04F000008200F00892
> :1DF00800AE00002707724F00005A26F9AE00002709D6F02AD700005A26F7CCF004F9
> :04F00400AC00F02547
> :06F025009DAE00F0C28761
> :00000001FF
>
> 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@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>
|
|
From: Philipp Klaus Krause <pkk@sp...> - 2018-04-06 12:23:57
|
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:
000000 9D [ 1] 87 nop
000001 AEr00r00 [ 2] 88 ldw x, #(_main >> 8)
000004 9D [ 1] 89 nop
000005 87 [ 5] 94 retf
And this binary:
:04F000008200F00892
:1DF00800AE00002707724F00005A26F9AE00002709D6F02AD700005A26F7CCF004F9
:04F00400AC00F02547
:06F025009DAE00F0C28761
:00000001FF
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
|
|
From: Eric Rullens <e.rullens@ds...> - 2018-04-06 12:12:52
|
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
122 ; Load mid byte (xl is set to 0).
00804B AE 00 22 [ 2] 123 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:pkk@...]
> Verzonden: vrijdag 6 april 2018 11:01
> Aan: sdcc-user@...
> Onderwerp: Re: [Sdcc-user] How to deal bytewise with 24-bit symbols in
> asxxxx?
>
>
> 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 #<sym,
> > but that seems to fail. If you instead use #(sym>>16) it
> seems alright to
> > me.
> >
> > Maarten
>
> void f(void)
> {
> void (*p)(void) = &f;
> (*p)();
> }
>
> compiles to:
>
> ld a, #<_f
> ldw x, #_f
> ; test.c: 4: (*p)();
> push #(00103$)
> push #(00103$ >> 8)
> push #(00103$ >> 16)
> push a
> ld a, xl
> push a
> ld a, xh
> push a
> 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@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>
|
|
From: Philipp Klaus Krause <pkk@sp...> - 2018-04-06 09:01:34
|
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 #<sym,
> but that seems to fail. If you instead use #(sym>>16) it seems alright to
> me.
>
> Maarten
void f(void)
{
void (*p)(void) = &f;
(*p)();
}
compiles to:
ld a, #<_f
ldw x, #_f
; test.c: 4: (*p)();
push #(00103$)
push #(00103$ >> 8)
push #(00103$ >> 16)
push a
ld a, xl
push a
ld a, xh
push a
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
|
|
From: Maarten Brock <sourceforge.brock@ds...> - 2018-04-02 13:43:00
|
>> Am 31.03.2018 um 10:42 schrieb Erik Petrich: >>> >>> I have enabled the assembler to emit 24-bit addresses in the relocation >>> records for stm8 like it does for ds390 and mcs51 (even though mcs51 is >>> only using 16-bit addresses). So this should allow you to reference the >>> individual bytes of the 24-bit address. However, I think additional >>> work >>> will still be needed to reference the upper 16 bits of a 24-bit >>> address. >>> >>> Erik > > I noticed you only changed outrxb() in asout.c and not outrw() which has a > similar exception. > >> Thanks. That makes function pointers already quite useful for the large >> memory model, and I have made the corresponding changes in the compiler >> to enable that use. In particular, calls via function pointers work now, >> as do const global function pointers (initialized by the address of a >> function). >> >> The only thing that doesn't work is assigning the address of a function >> to a function pointer. For that we'd need the upper 16 bits of a 24-bit >> symbol: Code generation wants to load them into 16-bit register x using >> ldw. I have tried to just use #(sym >> 16) where 16 bits would be >> expected. However, that results in broken code: The linker seems to >> write 24 bits into the binary, overwriting the first byte of the >> following instruction. >> >> Philipp > > 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 #<sym, > but that seems to fail. If you instead use #(sym>>16) it seems alright to > me. > > Maarten Correction: The least significant byte is loaded into a by using #<sym. Maybe > was intended? But the documentation states in AT.2.6 that this will take bit 15 down to 8. The documentation there also mentions a .msb directive for the DS80C390 only which configures to use another byte as high byte for >. Funnily enough there is no special assembler source for the ds390 as it uses the as8051. And on top of that the asstm8/stm8pst.c has it, but commented out. Maarten |
|
From: Maarten Brock <sourceforge.brock@ds...> - 2018-04-02 12:35:51
|
> Am 31.03.2018 um 10:42 schrieb Erik Petrich: >> >> I have enabled the assembler to emit 24-bit addresses in the relocation >> records for stm8 like it does for ds390 and mcs51 (even though mcs51 is >> only using 16-bit addresses). So this should allow you to reference the >> individual bytes of the 24-bit address. However, I think additional work >> will still be needed to reference the upper 16 bits of a 24-bit address. >> >> Erik I noticed you only changed outrxb() in asout.c and not outrw() which has a similar exception. > Thanks. That makes function pointers already quite useful for the large > memory model, and I have made the corresponding changes in the compiler > to enable that use. In particular, calls via function pointers work now, > as do const global function pointers (initialized by the address of a > function). > > The only thing that doesn't work is assigning the address of a function > to a function pointer. For that we'd need the upper 16 bits of a 24-bit > symbol: Code generation wants to load them into 16-bit register x using > ldw. I have tried to just use #(sym >> 16) where 16 bits would be > expected. However, that results in broken code: The linker seems to > write 24 bits into the binary, overwriting the first byte of the > following instruction. > > Philipp 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 #<sym, but that seems to fail. If you instead use #(sym>>16) it seems alright to me. Maarten |
|
From: Philipp Klaus Krause <pkk@sp...> - 2018-03-31 11:43:13
|
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 |
|
From: Philipp Klaus Krause <pkk@sp...> - 2018-03-31 11:31:15
|
Am 31.03.2018 um 10:42 schrieb Erik Petrich: > > I have enabled the assembler to emit 24-bit addresses in the relocation > records for stm8 like it does for ds390 and mcs51 (even though mcs51 is > only using 16-bit addresses). So this should allow you to reference the > individual bytes of the 24-bit address. However, I think additional work > will still be needed to reference the upper 16 bits of a 24-bit address. > > Erik Thanks. That makes function pointers already quite useful for the large memory model, and I have made the corresponding changes in the compiler to enable that use. In particular, calls via function pointers work now, as do const global function pointers (initialized by the address of a function). The only thing that doesn't work is assigning the address of a function to a function pointer. For that we'd need the upper 16 bits of a 24-bit symbol: Code generation wants to load them into 16-bit register x using ldw. I have tried to just use #(sym >> 16) where 16 bits would be expected. However, that results in broken code: The linker seems to write 24 bits into the binary, overwriting the first byte of the following instruction. Philipp |
|
From: Erik Petrich <epetrich@iv...> - 2018-03-31 08:58:08
|
On Thu, 29 Mar 2018, Philipp Klaus Krause wrote: >>> 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 I have enabled the assembler to emit 24-bit addresses in the relocation records for stm8 like it does for ds390 and mcs51 (even though mcs51 is only using 16-bit addresses). So this should allow you to reference the individual bytes of the 24-bit address. However, I think additional work will still be needed to reference the upper 16 bits of a 24-bit address. Erik |
|
From: Eric Rullens <e.rullens@ds...> - 2018-03-29 14:55:12
|
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@...' > 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:pkk@...] > > Verzonden: donderdag 29 maart 2018 13:44 > > Aan: sdcc-user@... > > Onderwerp: Re: [Sdcc-user] How to deal bytewise with 24-bit > symbols in > > asxxxx? > > > > > > 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 > > >>>> 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 > > > > 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@... > > 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@... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
|
From: Eric Rullens <e.rullens@ds...> - 2018-03-29 14:26:56
|
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:pkk@...] > Verzonden: donderdag 29 maart 2018 13:44 > Aan: sdcc-user@... > Onderwerp: Re: [Sdcc-user] How to deal bytewise with 24-bit symbols in > asxxxx? > > > 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 > >>>> 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 > > 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@... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
|
From: Philipp Klaus Krause <pkk@sp...> - 2018-03-29 11:56:53
|
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 >>>> 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 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 |
|
From: Maarten Brock <sourceforge.brock@ds...> - 2018-03-29 11:38:37
|
> 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 |
11 messages has been excluded from this view by a project administrator.