wishlist for NXC

[afanofosc]

The most recent test release has support for the "static" keyword, btw. It makes no difference for global variables and it seems to do the right thing for locals.

John Hansen

[HaWe]

already in fw 1.31?
555

that means - to speak in words of ANSI C - that local variables declared as "static" are getting a fixed memory address so that their locally changed values are stored when re-entering the function again (forgive me for my bad English)

Code: Select all

void testFunction() {
  static int _i;
  ++i;
  NumOut(0,0,_i);
}

task main() {
  testFunction(); // prints 1
  testFunction(); // prints 2
  testFunction(); // prints 3
  while(1);
}

true?

[spillerrec]

Helmut,
Yes, that is correct (other than your typo in the code). The firmware doesn't matter here btw, it is added by extending the compiler, no changes to the firmware is required.
However, as mentioned previously, all variables in the NXT bytecode format do have a fixed memory address already, so dropping the static keyword in your code does not make a difference in NXC and repeat, only in NXC.
It makes a difference in this case though:

Code: Select all

void testFunction() {
  static int i = 5;
  ++i;
  NumOut(0,0,i);
}

task main() {
  testFunction(); // prints 6
  testFunction(); // prints 7
  testFunction(); // prints 8
  while(1);
}

If you drop the static keyword here, it would print 6 each time as it sets i to 5 each time the function is called, instead of only when the program is executed.

[afanofosc]

So I really should have the compiler emit code to initialize non-static local variables to zero when no explicit initial value is provided so that NXC behaves more like real C.

John Hansen

[muntoo]

So I really should have the compiler emit code to initialize non-static local variables to zero when no explicit initial value is provided so that NXC behaves more like real C.

I was just about to say something on that topic.

Don't forget to adjust the output NBC code so that it does initialize to 0 in the global declarations. (The optimizer optimizes this away?)

This:

Code: Select all

static int i = 0;

Generates:

Code: Select all

__count_7qG2_i_7qG2_000	sword	

And this:

Code: Select all

static int i = 42;

Generates:

Code: Select all

__count_7qG2_i_7qG2_000	sword	42

[spillerrec]

A variable is initialized to NULL if no default value is given, so that is why it is removed. That is why:

Code: Select all

void foo(){
  static int i;
  NumOut(0,i*8,i);
  i++;
}

will always start at 0.

[mattallen37]

So let me get this right.

You can use "static int x = 7;" to set integer x to an initial value of 7, but not have the value revert back to 7 next loop, all while still maintaining localization rules?

And as spiller just pointed out, it doesn't work without fist assigning a value. However, what if you specify it to start at 0 ("static int x = 0;")? Is there no way to do it with the initial value of 0?

I have wondered before if there was something like this, but I had no idea what it was I was looking for (not that I ever really needed it... I just ended up using different solutions).

[spillerrec]

So let me get this right.

You can use "static int x = 7;" to set integer x to an initial value of 7, but not have the value revert back to 7 next loop, all while still maintaining localization rules?

Yes. It declares a global variable which is only in scope of that function.
If you followed Helmuts topic about RNG, notice how Legos standard RNG uses a static variable to reseed every 20 calls.

And as spiller just pointed out, it doesn't work without fist assigning a value. However, what if you specify it to start at 0 ("static int x = 0;")? Is there no way to do it with the initial value of 0?

I think you have misunderstood. "static int x;", "static int x = 0;" and "int x;" currently all behave like each other.

Since "int x = 0" is automatically changed into "int x" (which does the same, but is more efficient) muntoo was worried it didn't get initialized properly. This is not the case.

John want to change the behavior of "int x;" so that it initialized to 0 each time the function is called instead of only doing it when the program starts. I don't see an issue with the current behavior though. C puts the responsibility of not using uninitialized variables onto the programmer. Initializing uninitialized variables to 0 is more unlike C that it is to keep the last value imo.
The current compiler will not necessarily remove the automatic initialization either:

Code: Select all

void foo(){
  int i=5;
  Wait(1000);
  i=6;
  i=7;
  NumOut(0,0,i);
}

This results in:

Code: Select all

set __foo_7qG2_i_7qG2_000, 5
wait 1000
set __foo_7qG2_i_7qG2_000, 7

C prefers performance over safety. That is why the whole concept of uninitialized variables exists in C...

The use of uninitialized variables should issue a compiler warning anyway...

[HaWe]

so we could have 2 ways :

as static has not been widly used so far, we can handle it both "logically" and "C-like".

- initialize all variables (global and local and static) to 0 (except program-initialized ones of course) at program start-up (because of legacy reasons)
- re-initialize all local variables to 0 or as program-defined at each call, except when defined as static (because of legacy reasons)
- so local static variables will be never re-initialized after start-up (that makes the difference to non-static, and that makes sense).
- Compiler warnings for static variables which have not been explicitely been initialized.

Other way, like spiller wrote:
- never initialize ANY variable but give compiler warnings which variables need to be initialized probably (name, line).
- The programmer may care - or not. Legacy programs may be changed upon those warnings (or not).
A little less comfortable, but straight.

Both ways would be ok imo.

[afanofosc]

I'm inclined to leave things as they are in NXC wrt uninitialized local variables. With respect to Muntoo's post,

Code: Select all

__count_7qG2_i_7qG2_000   sword   

This kind of variable declaration is how you initialize a variable to zero in an RXE dataspace.

John Hansen