wishlist for NXC

[muntoo]

[Post under construction... And it will stay under construction until about a decade from now, when the world will "end".]

Proposed method for "recursion" without pointers:

Code: Select all

/*
Really useless recursion function. I'm pretty sure it's not infinite recursion (which would cause a "stack overflow")
*/
type funcName(unsigned int foo)
{
    // ... code 1 ...

    int bar = foo;

    foo *= foo;
    if(foo > 25)
        return(foo);
    foo++;
    bar = funcName(foo);

    // ... code 2 ...

    bar /= 2;
    bar = funcName(bar);

    // ... code 3 ...

    return(bar);
}

Can be "translated" to:

Code: Select all

// The following prototypes will be implemented in the firmware
void pop(variant arr[], variant& val);
void push(variant& arr[], variant val);


#define DONE 4


struct funcName_Stack
{
    struct args
    {
        // function parameters
        unsigned int foo;
    };

    unsigned long pos;

    struct stack
    {
        // local function variables
        int bar;
    };

    type ret; // the return value of the next recursive function call
}


void funcName_code(funcName_Stack &fns[])
{
    funcName_stack fnsTemp;
    unsigned long i = ArrayLen(fns) - 1;

    switch(pos)
    {
        case 1:
            // fns[i].pos++;
            // ... code 1 ...
            fns[i].stack.bar = fns[i].args.foo;
            fns[i].args.foo *= fns[i].args.foo;
            if(fns[i].args.foo > 25)
            {
                // return(foo);
                fns[i].ret = fns[i].args.foo;
                fns[i].pos = DONE;
                break;
            }
            // "Call" recursive function
            fnsTemp.pos = 1;
            fnsTemp.args.foo = fns[i].args.foo;
            push(fns, fnsTemp);
            break;

        case 2:
            // fns[i].pos++;
            fns[i].stack.bar = fns[i].ret;
            // ... code 2 ...
            fns[i].stack.bar /= 2;
            // "Call" recursive function
            fnsTemp.pos = 1;
            fnsTemp.args.foo = fns[i].stack.bar;
            push(fns, fnsTemp);
            break;

        case 3:
            // fns[i].pos++;
            fns[i].stack.bar = fns[i].ret;
            // ... code 3 ...
            // return(bar);
            fns[i].ret = fns[i].stack.bar;
            fns[i].pos = DONE;
            break;

        case DONE:
        default:
            pop(fns, fnsTemp);
            i--;
            fns[i].ret = fnsTemp.ret;
            break;
    }

    fns[i].pos++;
}


inline type funcName(unsigned int foo)
{
    funcName_stack fnsTemp;
    funcName_stack fns[];

    // Set initial function arguments
    fnsTemp.args.foo = fns[i].args.foo;

    // Set "position"
    fnsTemp.pos = 1;

    // Push initial argument onto stack
    push(fns, fnsTemp);

    while(fns[0].pos < DONE)
    {
        funcName_code(fns);
    }

    return(fns[0].ret);
}

Where the funcName_Stack is a struct of all the variables used in the function, the parameters passed, and the last "position".

-----

Up to John to decide if it's worth his time. (Or he could tell me how the SVN is organized for me to look at the NBC.exe compiler code. ... Especially if the code's in C/C++)

-----

EDIT: Maybe I'll write a simple parser that will convert recursive functions to the above. It'll be even better if John implements pop()/push() within the EF.

[muntoo]

Structs inside structs, with scoping rules obeyed.

Code: Select all

struct fish
{
    struct stats
    {
        int kills;
        int health;
    };

    struct identity
    {
        int age;
        string name;
    };
};

// Legal
fish shark;
fish seamonster;

// Error!
stats dog;

And next muntoo's going to be asking him for full fledged C++ classes...

[HaWe]

(edit2:)

could we probably have
a printf which is written as a function and not as a macro any longer
(could have already been changed since the last update)
a printfxy which prints at (x,y) on the screen, and
a CR/LF "\n" :

Code: Select all

int median(int val[], int sizeofval) {
  //...just for testing
  return val[3];
}

task main(){

  int test[]={1,2,4,8,16};
  printf("%5d\n", test[4]) ;
  printf("%5d", median(test, 5));

  while (true) {
  }
}

best would be if also overloadable with multiple formats and variables and also for strings :

Code: Select all

printf ("%s \n %d %E \n %x %o \n %#x %#o \n", "Some different radixes", 100, 100, 100, 100, 100, 100);

[nxtboyiii]

Be able to make a 3d object and use GL_CULL_BACK and actually make it work, not just look messed up.

EDIT: And also get the glPyramid to work

[mattallen37]

Here is what I would like:

Either:
- A flag system, so the NXT virtual screen on the computer only updates when the running program comes to an update flag. This would eliminate the awful flicker that the virtual screen suffers from.
- A flag system for the NXT (real) screen. So you could use lines like NumOut, TextOut... and it wouldn't do anything until you issue an update command. Thus, you could write to the entire screen, all at once.

Or:
- A dual screen buffer. You would be able to be displaying screen 1, and then draw to Screen 2. Once you are done drawing to screen 2, you update the real screen to displaying screen 2, and then you start building screen 1. You would flip back and forth constantly. This would take care of flickering and many other issues. It would be especially good for games and HUDs.

Also:
- If a dual screen setup would be easy to make, perhaps an unlimited number of screens would be even better (for things like a menu...).

John, please let me know if you understand what I mean, and if any of this is feasible to add to NXC. If you don't understand, then I'll work on a library, and try to make a PoC project (at least for text).

[nxtboyiii]

~mattallen37
That would be so awesome! That would be the best!!!
You should do that John(no pressure )!

[muntoo]

~mattallen37
That would be so awesome! That would be the best!!!
You should do that John(no pressure )!

Yes, you should! (No pressure. )

- A flag system, so the NXT virtual screen on the computer only updates when the running program comes to an update flag. This would eliminate the awful flicker that the virtual screen suffers from.

Your program would theoretically require "insane" amounts of CPU.

- A flag system for the NXT (real) screen. So you could use lines like NumOut, TextOut... and it wouldn't do anything until you issue an update command. Thus, you could write to the entire screen, all at once.

I think this isn't possible, due to hardware limitations.

- A dual screen buffer. You would be able to be displaying screen 1, and then draw to Screen 2. Once you are done drawing to screen 2, you update the real screen to displaying screen 2, and then you start building screen 1. You would flip back and forth constantly. This would take care of flickering and many other issues. It would be especially good for games and HUDs.

Now this is what I'm talking about! Go double buffering! (Time-Space Trade-off... Sort of. )

I think all we need is at least one of the following:

• the ability to set the pointers to the display buffer
• the ability to write to popup memory [with decent speed] before switching to it, and vice versa; I'm not sure if this is already possible

I'll work on a library

You can build upon SCR_File_Lib. (I should put up a Mercurial repository...)

[HaWe]

wish to have a clear and logical motor synchronization.
1 master motor, 1 slave motor.
+100% = 100% synced in the same direction, 100% the same encoder counts
-100% = 100% inverse synced (inverse rotation direction), same with encoder counts
...
75% = slave has 75% speed and encoder target counts related to the master,
-75% the same but inverse rotation direction
...
50% = slave has 50% speed and encoder target counts related to the master
-50% the same but inverse rotation direction
...
0% = 2nd motor stands still (idle)

This is similar to the RobotC definitions and API functions.

use:

Code: Select all

SetMotorSync (   // stores general Master-Slave motor settings
  byte OutMaster,
  byte OutSlave,
  byte syncMode) // 1=set  sync mode, 0= not synched=release sync mode

RotateMotorSync ( // commands only OutMaster, OutSlave is synched by settings of SetMotorSync
  byte OutMaster,   
  char  pwr,   // for  master; slave: automatic adapted  
  long  angle, // for master; slave: automatic adapted
  char  SlaveTurnpercent, // percentage of speed and turn angle related to master, synched to each other
  byte stopmode) // 1=brake, 0=coast

[HaWe]

just a proposal for additional array operator functions:

Code: Select all

inline int ArrayMedian(int src[], int len)
{
  int temp[];
  ArraySort(temp, src, NA, NA)
  return temp[(len-1)/2];
}

Code: Select all

inline void ArrayPush(int &src[], int _new, int len)
{
  for (int i=len; i>0; i--) {src[i]=src[i-1];} // shift up
  src[0]=_new;    // push new element
}

Code: Select all

inline int ArrayPop(int &src[], int len)
{
  int _zero=src[0];    // read [0] element
  for (int i=0; i<len; i++) {src[i]=src[i+1];} // shift down
  return _zero;
}

[muntoo]

min/max

min(a,b) and max(a,b) should be built into the "standard includes" (NXTDefs.h, or whatever).

Code: Select all

#define min(a,b) (a<b?a:b)
#define max(a,b) (a>b?a:b)

push/pop

And I too would love pushing and popping off a stack for any type.

ul_LIFO.zip

(1.96 KiB) Downloaded 321 times

void/variant types

I suppose this is only feasible with inline functions? Or maybe you could attempt some 'firmware hacking'?

Code: Select all

variant add(variant a, variant b)
{
    return(a + b);
}

Or:

Code: Select all

void add(void &out, void a, void b)
{
    out = a + b;
}

(Yeah, I guess I've been spending too much time with JavaScript.)