Strange things happening with `E.compiledC`

Hi,

I tried E.compiledC on my Bangle 1 2v16 and see weird things happening. After "Resetting without loading any code", the following

var c = E.compiledC(`
// void init()
// int f()

volatile int a;

void init() {
  a = 0;
}

int f() {
  a++;
  return a;
}
`);

c.init();
setInterval(() => print(c.f()), 100);

gives me

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
1644167202
1644167203
1644167204
1644167205
1644167206
39
40
41
42
43
44
45
46
47
48
268435505
50
51
52
53
54
55
1811939384
57
58
1761607739
1761607740
1761607741
1761607742
1761607743
1761607744
1761607745
1761607746

Prior to that I ran code which wrote to RAM locations where it shouldn't have. So I rebooted and reflashed the firmware hoping it would reset the device and resolve the issues I see. Is there anything I can do? Its a bit scary to run code that might modify any RAM location at any point.

Thanks in advance!

No need to reflash firmware, just rebooting is enough (E.reboot or holding btn1+2), firmware is in flash not ram so you cannot corrupt it by changing ram.

btw you don't need the variable to be volatile. from the sequence it looks like it is incrementing but sometimes the highest byte of the a variable is corrupted. Oh, I think I remember this bug, try to declare it with initialized value like

volatile int a = 0;

that should be safe. Uninitialized variables go to .bss section and that one is not part of the preallocated binary array in RAM so it will corrupt something after the array. It is a bug (or feature) of the compiler.

Or you can put global variables to .text segment, that will work too and will even generate a bit smaller code

__attribute__((section(".text"))) int a;

Thanks, good to know about the reset. Was using a custom build to try things, so reflashing wasn't wasted effort at least :)

Regarding initialized or not, I tried a few variations and it seems that volatile is the culprit. Without it, the counter runs to at least 2000 whether or not it was initialized during declaration. Just initializing didn't fix it. The reason why I used volatile was because I read it here http://www.espruino.com/InlineC.

I'll keep the optimization in mind :)

Oh, forgot that initialization to zero goes to bss segment too, so either the attribute or try =1. volatile should not matter in that code you wrote, you don't access a variable from interrupts. That example possibly uses it because of setWatch with irq:true (?).

You are right, and I was wrong. When I removed volatile in the actual application, the issue was still there. After that, initializing with 1 did fix it in the example as well as in the application (... I hope). Thanks a lot!!

Probably worth to mention somewhere xd

Probably worth to mention somewhere xd

It is a bug so I reported it as https://github.com/gfwilliams/EspruinoCompiler/issues/15

Thanks - I'll get a fix in for this soon