wishlist for NXC

[mattallen37]

Well yeah, I would rather that for sure, but right now I2C errors (like not being plugged in) crash the program. I'm sure there are other errors that are dealt with without notice, but I just don't like the NXT to jam (I can deal with a program crashing).

I like ROBOTC in that it doesn't just say error -1 (you can actually, easily debug).

[bungeshea]

Support for elseif.
http://www.cplusplus.com/doc/tutorial/control/

[muntoo]

I would be pretty surprised if else if() were not supported already.

[bungeshea]

I would be pretty surprised if else if() were not supported already.

Well I guess you could write as else if, but I ment the elseif statement like in PHP.

[HaWe]

elseif is not ANSI C standard.
NXC should be like standard C :
if () { ;}
else if () { ;}
else if () { ;}

and in this special case it already is.

Of course you may use #define as well and define your own elseif. In this case NXC also already is like C:

Code: Select all

#define elseif else if

task main() {
  int a=5;

  if (a<0) TextOut(0,0,"negative");
  elseif (a==0) TextOut(0,0,"zero");
  elseif (a>0) TextOut(0,0,"positive");
  
  while(true);
}

But what for...?
(anyway, elseif is php but not C, the same says your cplusplus tutorial: http://www.cplusplus.com/doc/tutorial/control/)

[mattallen37]

A while ago I think I mentioned somewhere my wish for dual screen buffers. Well, according to the HDK, the standard FW is supposed to already support it (the way I understand it). Here is a quote from the HDK manual (page 11, version 1.00).

There is an SPI interface from the ARM7 microcontroller to the display's LCD-controller UltraChip 1601. The SPI interface is running at 2MHz within the standard LEGO firmware and two full memory maps are set aside within the firmware for updating the display. The display is continueously updated in a line sequence requiring 17 mS for a total display update.

LCD data is allocated within memory as a two dimensional array, Normal[8][100](Normal[Y/8][X]). Data is sent to the LCD controller in the following order: the first byte controls the first 8 pixle vertical (starting at (0,0)) and the second byte controls the next 8 vertical pixle horzontal.

The pixels within the display are allocated as follows:

0,0________________


______________99,63

Was this just another mistake in the HDK (I found several)? Was it written before-hand as a reference to how they wanted the FW? If there really is an extra 800 byte memory area setup to be used as another screen buffer, I would really like to take advantage of it.

Another question: why is 0,0 said to be top left, instead of bottom left (like it is in NXT user-code)?

[HaWe]

it would be very handsome if we could pass variables to tasks as well (by value and/or by reference)...

[spillerrec]

A while ago I think I mentioned somewhere my wish for dual screen buffers. Well, according to the HDK, the standard FW is supposed to already support it (the way I understand it).

It might be the "popup" display, which you can switch to and start drawing on instead. I didn't play around with it that much because of lack of documentation of what it actually was...

It is a long time ago since I tried using it, but after reading the documentation I think you need to use SetDisplayFlags() to switch to it like this:

Code: Select all

SetDisplayFlags( DISPLAY_ON | DISPLAY_REFRESH | DISPLAY_POPUP );

doc,
Passing variables by reference to a task is not possible, as it is not possible to copy the value of the temporary variable back to its original when there is no returnee. While passing by value when using Precedes could theoretically work, the syntax would be even more messy/confusing than it is currently, so I don't think it is a good idea...
For now simply do it yourself with global variables. Sure, they are in global scope, but this is what would happen behind the scenes anyway...

[pepijndevos]

An OP_JMP that does a variable lookup. My guess would be something like

Code: Select all

case OP_DYNJMP:
    {
      gPCDelta= (SWORD)cCmdDSScalarPtr(Arg1, 0);
      Status = NO_ERR;
    }

Just copy-pasted OP_JMP with what I think is the code to get a variable. Would something like that work? With that, one can implement all sort of nice tricks. If you had that for OP_SUBCALL as well, you basically have the most interesting parts of pointers.

[afanofosc]

As of version 1.32 of the enhanced NBC/NXC firmware you should be able to use a few new opcodes:

Code: Select all

#define OP_FINCLUMPVAR   0x90 // clumpID
#define OP_SUBCALLVAR    0x91 // subroutine, callerID
#define OP_STOPCLUMPVAR  0x92 // clumpID
#define OP_STARTCLUMPVAR 0x93 // clumpID

#define OP_JMPABSVAR     0x94 // pcvar
#define OP_BRCMPABSVAR   0x95 // pcvar, src1, src2
#define OP_BRTSTABSVAR   0x96 // pcvar, src

I still need to change the compiler to support these new opcodes. In theory, I will have the compiler support a clump name or a label name as the 2nd argument to OP_SET. It will replace the clump name with a clump ID number and the label name with the absolute PC of the statement where that label is defined at compile time.

I have also added firmware support for 2 new array operations which are demonstrated below, along with support for drawing text to any Y value.

Code: Select all

string test = "Lorem Ipsum Dolor Sit";

task main()
{
  string upper, lower;
  asm {
    arrop 0x07, upper, test, NA, NA
    arrop 0x08, lower, test, NA, NA
  }
  TextOut(0, LCD_LINE1, test);
  TextOut(0, LCD_LINE2, upper);
  TextOut(0, LCD_LINE3, lower);
  for (int j=0; j<8; j++)
    TextOut(6*j, LCD_LINE6+j, "X");
  TextOut(0, LCD_LINE7, "WWWWWWW");
  TextOut(0, LCD_LINE8, "OOOOOOO");
  while(true);
}

The firmware can be grabbed from http://bricxcc.sourceforge.net/test_releases/

John Hansen