Mindboards

I'm not sure how you (someone) would go about it. I do remember hearing about how messy the FW is though, so it might be possible. John said that it would take a ton of work to rewrite it, and he doesn't have the time to attempt something like that. If you really need faster processing, there are options available.

matt,
thanks, but this is my wish (or actually a question to John) for the wish list, not for a discussion thread.
I found that RobotC works really faster (min 10x) in direct comparison and I remember correctly that they "have stolen much from the NQC API" (ref: John Hansen) so I'm curious if NXC can get some profits of it's techniques.

doc-helmut wrote:so I'm curious if NXC can get some profits of it's techniques.

Nope (for the "10x fast") - that would mean modifying the firmware. It can, however, be optimized to 3x fast by improving the output of the NBC code. I'd prefer that method to the firmware changing.

EDIT: Adding to my non-expert guesses.

doc-helmut wrote:is there a chance to speed up the enh FW in relation to the std FW ?

Well, he has added natively supported bitwise operations, but short of changing a whole bunch of internal stuff, and rewriting the FW, I doubt it.

muntoo,
I'm not sure if you're such an expert for the VM and FW details, so I'd like to hear something from a "real specialist" - even if the answer should be coincidentally the same as yours ...

doc-helmut wrote:is there a chance to speed up the enh FW in relation to the std FW ?

Proper support for the following: Not necessary, but a few more ideas: NXC should be able to determine and "disambiguate" this, even without pointers!

Static electricity!

support for
volatile
to prevent the compiler from faulty optimizations

As Spiller describes in this post:

spillerrec wrote:As shown in muntoos post, you have to be very careful when you are dealing with large strings/arrays because it ends up making temporary variables.
To make matters worse, in NBC there is no such thing as scope, all variables are global/static so even when it goes out of scope in NXC it does not get cleared. And it is "impossible" to clear them, since you don't have access to them. (Well, there is a dirty trick, run the function again but with an empty array, depending on the function you might be able to clear most of them.)

This is something that should be fixed - it limits our memory use significantly. Could you generate NBC code which reinitializes the arrays only in scope of the block at the end of the block? To:

Is it possible to add the possibility to manually limit FontTextOut() when using DRAW_OPT_FONT_WRAP?
If you want to make something like a border around the text, or a scrollbar in the right side for example it is fairly important to prevent the text overlapping this.

But this is actually not what I want to use it for (since I already have implemented this in my word-wrapping library (which also makes it possible to control which lines should be drawn)). I often use FontTextOut() to replace certain GraphicOut() operations but I often end up having to do the wrapping manually. In my slide puzzle game I needed to repeat FontTextOut() for each line because I wanted my 64x64 sized grid to start at the left edge. In my tile engine (for NXT RPG) it needs to draw it just before the screen starts and stop just after the screen ends to properly show animation. Again I had to repeat FontTextOut() for each line since DRAW_OPT_FONT_WRAP is fixed on screens right edge.

[quote=muntoo]This is something that should be fixed - it limits our memory use significantly. Could you generate NBC code which reinitializes the arrays only in scope of the block at the end of the block?[/quote]Could this be enabled/disabled with a keyword? Sometimes performance is more important than memory usage.

spillerrec wrote:Could this be enabled/disabled with a keyword? Sometimes performance is more important than memory usage.

That's what static is for. (I asked for that a little while ago.)