#2155 sdcc for 8051: static var, modulo operator, not optimized hex target?

[Attilio Dona']

I suspect some sdcc problems.

My target is a 8051 chip: CC1110 from TI

I've documented the issues and the build env on a github page:

zakke

For building:

git clone https://github.com/attdona/zakke.git
cd zakke
git submodule init
git submodule update
cd apps/mote
make TARGET=cc1110mdk

Please ask me if the informations are not enough.
Thanks for your support!
Attilio

[Maarten Brock]

Can you please explain what the problem is and why the solution solves that? Can you upload the problematic assembly?

[Attilio Dona']

For convenience I reproduced the loop problem with the gist attached.

I noticed that with that gist also using a local variable i as counter does not work.

The LED on the board never switch on again, so the for loop never exits.
For all i values iptr[i] == "a_fixed_value"

[Maarten Brock]

The generated listing looks ok for a model-large and non-stack-auto compiled code. Is that what you used? And also how the library is created?

Using a local variable is probably not the fix, but using an int8_t probably is. Then it might use the MUL instruction instead of the mulint() function from the library.

[Attilio Dona']

Hi Maarten,

My fault, in the example I forgot the --stack-auto option ...

now it is fixed:
I tried your suggestion, but also with int8_t does not work.

I think it is my sdcc build that is non ok, but no idea of what is wrong.

I followed the docs and then before make the file device/lib/Makefile was edited: small-mcs51-stack-auto was replaced with model-mcs51-stack-auto.

In attach the log of the sdcc make, the device/lib/Makefile, the gist source and assembly generated with:

sdcc.exe -mmcs51 --model-large  --opt-code-size --stack-auto -IC:\cygwin\usr\local\share\sdcc\include  -c main.c -o obj\Release\main.rel
sdcc.exe  -o bin\Release\sdcc_bug.ihx -mmcs51 --model-large  --opt-code-size --stack-auto    --out-fmt-ihx   obj\Release\main.rel

[Maarten Brock]

Can you also give the generated .rst file (.lst after linking)?
Can you verify if xdata is properly initialized?
Does the CC1110 need to enable on-chip xram?
Have you told the linker where the xram is located? (--xram-loc 0xF000)

[Attilio Dona']

ok, I rebuilt sdcc from scratch and checked all the options, now it works!

Definitely a problem of my environment, not a bug.

As last thing I noticed a strange hole of about 2.6k of memory between the random_init() and ctimer_init():

C:   00006D52  _random_rand                       random
C:   00006D68  _random_init                       random
C:   0000776F  _ctimer_init                       ctimer
C:   0000779F  _ctimer_set                        ctimer

I'm not able to see the reason.
In attach all the sources and the build files

Attilio

[Maarten Brock]

Not only the implementation of random_init is in that hole but also the non-external process_thread_ctimer_process. If you enable debug-output you will see some more.

Also, I saw that --xram-size is 0x1000 but in this von-neumann-ized device the last 0x100 are identical to data/idata and you should not give them as xdata to the linker. Use --xram-size 0x0F00.

I will close this now as there was no bug.