afanofosc wrote:I agree with gloomyandy. In the LEGO firmware all variables are global and every subroutine call stores the return address in a global variable at the point of the call and uses that same global variable in the return call within the called routine. That design doesn't support recursion.
John Hansen
thx to andy and John for your explanations!
I understand now the difference of Lego fw opposite to Java fw and the big limitations of the Lego fw a bit better.
So if it would be hard to implement "call/return instructions that use a stack for the return address and ... instructions that expect local variables to be stored on the stack and references them using a stack frame register that points to the current frame" into the Lego fw and keep it Lego-compatible - :
How hard would it be for a IT specialist to keep all the (e)fw and API specifications EXCEPT the memory handling - and rewrite that part so that it won't use a clump/function/method anylonger but from now on a stack/heap design with call/return instructions for the stack and pointer/dynamic mem alloc for the heap (taking into account that it's no longer fully Lego-compatible)?
Is there a programmer around here who feels able to write something like that?
doc-helmut wrote:How hard would it be for a IT specialist to keep all the (e)fw and API specifications EXCEPT the memory handling - and rewrite that part so that it won't use a clump/function/method anylonger but from now on a stack/heap design with call/return instructions for the stack and pointer/dynamic mem alloc for the heap (taking into account that it's no longer fully Lego-compatible)?
Is there a programmer around here who feels able to write something like that?
Yes there are... and they made LeJOS, nxtOSEK, pbLua... If you break compatibility, why bother keeping the lego vm behaviour?
I want to keep the procedural design, the keywords, and the syntax of NXC (far easier task control and far easier API than nxtOSEK, and above all: no object-oriented programming needed like Java - I really hate it )
Simply: be able to keep all the NXC programs as they are, plus the benefit of pointers, mem allocation, and recursion.
(edit: especially your gcc fw compilation could help a lot on that way to a IFW (improved firmware)
I'm sure it is possible, but I suspect that it would be a pretty unpleasant task. The Lego firmware has a rather unique programming style (that is not easy to get to grips with). One of the problems would be that once these (rather large) changes had been made, someone would have to keep the updated firmware tracking the Lego base (as I suspect it will be hard to get Lego to adopt the new code)... Making such changes once could be interesting, making them a second time would be a chore... Good luck to anyone that takes it on!
It would probably be easier to create a standard Lego FW interpreter for something like nxtOSEK or NXOS to get access to the recursion in those firmwares.
- Xander
| My Blog: I'd Rather Be Building Robots (http://botbench.com)
| RobotC 3rd Party Driver Suite: (http://rdpartyrobotcdr.sourceforge.net)
| Some people, when confronted with a problem, think, "I know, I'll use threads,"
| and then two they hav erpoblesms. (@nedbat)
| My Blog: I'd Rather Be Building Robots (http://botbench.com)
| RobotC 3rd Party Driver Suite: (http://rdpartyrobotcdr.sourceforge.net)
| Some people, when confronted with a problem, think, "I know, I'll use threads,"
| and then two they hav erpoblesms. (@nedbat)
Even if the firmware was changed to support pointers and recursion it would leave the also large task of modifying the way NBC/NXC generates code so that it worked with this modified firmware's amazing new capabilities.
I kind of like Xander's idea about implementing an RXE interpreter in one of the alternate firmwares out there. But that won't give NXC the ability to support recursion, etc...
)
