Mindboards

So if you could use absolute JMPs rather than relative JMPs and you could store the absolute address in a variable that you pass to the JMP what would you use that for and how would you get the address that you stick into the variable?

Describe for me the opcode that would store either a PC value (either absolute or relative) or a Clump ID into a variable. Once your code is compiled there is no such thing as a clump name so it seems like a set opcode where the compiler figures out that you are passing in a label or a clump name and it calculates the right value for the set opcode to use.

Something like
which would probably have to stick an absolute PC address into JumpTarget. Then you could have a single line of code like this:
which would do an absolute indirect jump to the PC address stored in the JumpTarget variable.

Supposing that we make all the firmware and compiler changes to support this capability. How do you see it providing us with any substantial benefit? Draw me a code picture of what it would enable you to do. I'm thinking it would not enable anything that you can't already do but I could be wrong.

With respect to clumps and subroutine calling, I think the goal you are after is something like function pointers. That sounds promising. So you would like to have support in the compiler to take the address (clump ID) of a subroutine like so:
I can imagine how the compiler would generate a number in this case and stick it into FuncPointer using set. And I can also imagine a new opcode that could call a subroutine with a variable instead of a constant clump ID. Can you draw me a code picture of what that would let you do that would be totally awesome? For some reason I keep getting stuck on the notion that it won't let you do anything that you can't already do in some other way.

John Hansen

Yes, function pointers are what I'm after. With jump statements you wouldn't be limited with recursion, but other than that, subroutines are probably easier.

The reason is abstraction and code reuse. You can separate the what from the how. Forth has a concept called make/doer, where you can have 'blanks' in a function.

Imagine a routine that does a task, and notifies the user of its completion. Depending on whoever initiated the task, it might display something on the screen, play a sound, or do something else. You might use 2 different tasks, write an if statement or... pass the pointer to the notification routine. All are fine, but the last is extensible, any caller can implement its own notification. You could even abstract the "do something, notify completion" into a separate routine that takes 2 pointers.

Another common usage is the map function. The map function does something to every element in a collection. One could craft a specific map function for everything you want to do to a collection(i.e. a loop), but you could also pass a routine pointer to the thing that you want to be done to the collection. Functional languages usually contain a whole set of these kind of common operations to apply to a collection.

You could also do continuation passing style, where you pass "the thing to do next" as an argument to a routine. And then you can do call-with-current-continuation, like in Scheme. Forth is commonly implemented like this, where every word definition ends with popping the next thing to do of the stack and going there.

You could implement cooperative concurrency, callbacks, asynchronous motor control… Actually, that would be a really neat! Reactive programming!

So, you have a reactor that just loops around, reading sensors and sending of motor commands, then when certain conditions are met(motor finished turning, sensor pressed), it calls into the code that registered for the event. See Twisted for an example of this.

Need more? I could go on like this for hours All of these super powers, with just a way to store and call functions by reference.

afanofosc wrote:I can imagine how the compiler would generate a number in this case and stick it into FuncPointer using set.

What would be the current behavior for doing that? Doesn't MyTotallyAwesomeFunction just always evaluate to its clump reference?

I'm just going to go ahead and have a look at how I could implement the new subcall. Let me know if you think it's awesome enough to get into NBC and the EF.

afanofosc wrote:For some reason I keep getting stuck on the notion that it won't let you do anything that you can't already do in some other way.

I've been thinking about that, and of course, the NXT is turing complete, so you are completely right. It's basically just a more advanced way to do branching. Maybe clever compiler tricks could get you even halfway there with the current code.

Still, I think the promise of lambdas and reactive programming is more than regular awesome.

Please see this post:

https://sourceforge.net/apps/phpbb/mind ... 150#p12086

The compiler still needs some work before you'll be able to use these.

John Hansen

I found this post about Erlang, describing how Erlang and Forth use labels as values to implement threaded execution.

The loader also turns the BEAM bytecode into threaded code: a list of addresses that get jumped to in sequence. There's no "Now what do I do with this opcode?" step, just fetch and jump, fetch and jump. If you want to to know more about threaded code, look to the Forth world.

Threaded code takes advantage of the labels as values extension of gcc. If you build the BEAM emulator with another compiler like Visual C++, it falls back on using a giant switch statement for instruction dispatch and there's a significant performance hit.

http://prog21.dadgum.com/127.html

pepijndevos wrote:Ok, so GCC is not a good idea. I'll boot up the windows box of my brother, while he's in school.
Why doesn't the enhance firmware work with GCC? Is that a matter of writing a makefile or whatever, or are some enhancements just not compatible?

It works (is my english that bad?). To make it work with GCC, there is some changes related to IAR syntax extensions which are not the same as GCC ones, and also a makefile, a startup file and a linker file. All of this is included in NIF.

pepijndevos wrote:Can I use that NBC debugger or something like that for debugging, or do I really need a JTag cable for that?

Thanks to tcwan, you can use GDB with a simple USB connection, I will add shortly an explanation page on NIF page. The only limitation is that you can not set breakpoints in flash while a JTAG debugger can do it.