doc-helmut wrote:
admittedly OT: But if that's too much effort, what about not investing time for that but instead use your free time for writing a non-Lego compatible firmware which e.g. generates genuine ARM7 machine code?
(of course with a close to 100% ANSI compatible C compiler for the Bricxcc IDE, and maybe using a bootloader RAM to keep the std fw on the NXT - but the latter is not a must)
The firmware's role is to be able to run user programs. If John's firmware executes ARM7 machine code, then it is probably better just to use a ARM cross-compiler and download the ARM code directly to the NXT (which can be done today using NxOS).
The missing parts are dynamically linked supporting libraries for the NXC API and a loader/linker to resolve the symbols. But then, I'd suspect ROBOTC or other alternative firmware is already doing something similar for their own API libraries? (Disclaimer: I have not used ROBOTC).
The question is whether it is worth John's effort to support such a configuration.
Just to clarify:
why I suggested to generate machine code and not bytecode was in the first place: speed!
In the 2nd place: ANSI C 99 compatibility (having stack, heap, pointers, recursions, stdio functions).
I actually didn't want NXC to generate ARM code, I want a different compiler to do it, I just wanted the fw to enable that like it does when using nxtOSEK or NxOS in compatible mode.
For reading sensors and controlling motors NXC is surely fast enough, but for pure math calculations I guess machine code could speed it up to more than 100x faster (10,000 percent) or even much more. Also use of pointers for arrays passed to functions would speed it up even more, in the moment the array copy procedures waist lot of time (e.g. passing large arrays to functions "by reference": here is a speed-up of maybe 1000x faster and more conceivable).
To be able to use Bricxcc as an IDE would be great because of it's perfect ease of use, in contrast e.g. to Eclipse by which you may beat someone to death ;)
So the topic title is not quite correct: it should say: "substitute for NXC: embedded ARM C compiler by BCC?"
A different approach might be to use one of the already existing solutions like nxtOSEK or NxOS with a convenient embedded C compiler (+linker+makefile) by BCC.
as I'm no programmer I admit that this is just a rough idea.
