I am looking for a way to have pointers to functions so I can stick 'em in an array. I know this is possible in regular C, however, before I go down that road, does RobotC have support for this?I'd like to make a generic framework for subsumption based robot "brains", unfortunately the way I had envisioned that would involve said pointers.

There is an alternative implementation that is a little less elegant that might work for you. Instead of storing a function pointer store a numerical index. Then where you would normally "execute" the function, you would call a function that does on a switch on this index and it calls the appropriate function.

Another limitation within ROBOTC that you might run into is that it does not support recursive function calls. I'm not sure if this is a problem with a subsumption architecture.

Are there any plans to include pointers or recursion as part of the functionality offered by RobotC?

I guess RobotC is slowly growing to be a more advanced platform, not just reserved for people wanting to learn C, but also for people who want to do more advanced things. Perhaps you could make this kind of functionality part of the advanced settings, thereby hiding it from the novices.

I used to run from pointers, but now I kind of miss them My guess is you will make Ford Prefect a very happy man if you give him recursion, then he can finally calculate his Fibonacci numbers!

I can see your point but RobotC is designed to control robots. Designers of RobotC have limited resources. They might work on pointers to functions, or recursion -- or they might work on support of new sensors, more stable bluetooth, better documentation for beginners and intermediate users etc etc.

I can imagine that RobotC might come with somethink like call to a native machine code subroutine in which we can do really CPU-intensive tasks with recursion etc. Written in machine code, like in the good old days of Commodore VC 20

L

Mon Oct 06, 2008 1:36 pm

Ford Prefect

Guru

Joined: Sat Mar 01, 2008 12:52 pmPosts: 1030

Re: Pointers to functions

elemes, in the last time you haven’t really made any a positive contribution -just try to think more positive!

Some history on ROBOTC development explains some of the current limitations.

The NXT is the most powerful platform available to end users for ROBOTC. [It runs on other non-public platforms as well). The NXT has a 32-bit CPU and relatively lots of memory.

ROBOTC also runs on small 8-bit CPY platforms with 2K of RAM and 32K of flash.

Some of the CPUs (those from Microchip and Atmel) are Harvard architectures which means separate data busses for RAM and RON/Flash with separate instructions for RAM access and ROM/Flash access. [This is an oversimplification but satisfactory for here]. This introduces a lot of complexity to the ROBOTC VM for pointers when compared with architectures where RAM and ROM are in a single linear address space; you have two different pointer types requiring separate instructions to access.

Originally:[list=][*]All platforms had nearly identical features[*]16-bit was the standard for "int"[*]Pointers all fit within 16-bit.[*]char variables were not supported. Or were treated as 16-bit short.[/list]

The vast majority of end users did not experience any limitations with these restrictions.

'char' size variables have been added.

Data pointers have been added. I expect there are some latent bugs someone, but none that are reported and unresolved. The data pointers are implemented as 16-bit variables. This required a bit of a kludge in that 'const' data variables are located in RAM. Their initial values are stored in flash but on program startup these are all copied to RAM.

ROBOTC programs are stored in flash and the instruction set is designed so that they are relocatable without any address fixup.

Both of the above two points are not conducive to "function" pointers.

Theye require 32-bit pointers

Function addresses are not compile time constants. They must be determined dynamically at run-time.

Function pointers are currently a low-priority for implementation.

For a similar set of "reasons", temporary variables and function parameters are statically allocated and not stored in a stack. This is why recursion is not available. This limitation impacts very few end users. It is a restriction that would be nice to limit and it is a low priority background development item.

Even with the above, you'll still find ROBOTC is the most feature rich of the available development environments for the NXT>

Thanks for taking the time to explain the reasons behind some of the limitations. It makes a lot more sense now.

Sooooo....when did you say they'd be implemented? *grin*

Just kidding Keep up the great work you guys are doing on RobotC.

Xander

PS: Elemes, I know all about software and systems design and how resources are (almost) always limited to some degree. I've been a Linux software and systems project engineer for over 14 years now. However, I also know that as long as you have customers, you will have feature requests. It's all part of the game called software development. In the end it is all about priorities and you can only ever have one number one priority, despite what your customers might think!

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum