Drowning myself in toxin

I finally picked up my NXT again to harden myself a bit more against upcoming programming sessions with Java I cannot avoid this time. And what's the best to do then? Right, programming for later Lego projects using it. I was still a bit dreaming cause I slept a few hours right before I started. And I realized how few libraries really exist for leJOS apart from it's standard library. I don't say anything about using it, but it's a bit weird compared to what I'm used to. leJOS has so nice lowlevel functions for accessing everything, almost made to program more complex stuff; I bet it's the fact that the NXC/NBC is, historically, more common to people who worked with previous Mindstorms versions. I also believe that Java is a more exotic choice for engineers working with roboters and embedded designs since it's most of time just not as fast a C code or assembler. However, giving the fact that (with it's limitations) it's ok for very fixed and highly specialized applications, it's no wonder that most beginning programmers choose it for there usually feature-fixed programs.

This made me think (especially in terms of maths-heavy programs): if you provide, for example, a very simple and limited point structure/object with only a few functions that aren't overload or provide only parameters to force creating other, more ressource-demanding structures during runtime, you'll most probably need to write more complex and bigger functions to archieve the thing our simple and small structure can't deliver. So the more you want to, the more useless code you have to write and the more it becomes repetitive to also deliver more comftable overloads of this function. But if you improve the functions/methods that are at the most bottom hirarchy level (means the functions you call the most one or more levels up), you can rely on their flexibility and shorten almost all functions calling them from the upper levels. For example, if our point structures has typical mathematical operations that take only other point structures as parameters, you'll need to create a new point everytime you call them (or atleast create a new variable for it). This rises up to the top-most levels, resulting in a spammed memory if the platform doesn't do garbage collection while program execution (leJOS for example does only collect if there's just no more memory available). In a normal C program, this wouldn't be such extreme, but still a waste cause you create stuff you don't need to. So if you instead provide also scalar and coordinate-wise and other mixed parameter sets (a rectangle for example can take even more variants), you can't simply drop all temporary object creation and put all otherwise allocated ones as parameters and not as new objects. This improves further if you also want to create more overloads of upper-level functions as you don't need to copy the whole code but instead only a few, specialised lines while keeping a perfect "oneliner" overview. In my eyes, this seems as an improvement. I rather prefer risking more stack operations that spamming the memory randomly. Of course, most NXT programs don't do that normally. But if memory is scarce, CPU time limited and a lot of free space needed, it's imho the best variant. I must admit I'm a fan of stack operations. They are simple and flexible to integrate, provide more intuitive mechanics than registers and are relatively easy to cleanup. Plus you usually ot "plenty of memory" compared to registers (even a few kbyte perform better than just a few registers in terms of size).

Oh and if your wondering why I'm again bothering with those wretched non-generating languages: I'm coding a CPU time-friendly 2D rendering system for the NXT. My initial experiments which leJOS' sound possibilities resulted in a Freemind document explaining the benefits of multithreading on the NXT for muldimedia content. I took a look at it today and started to design a graphical system that minimizes pixel drawing using a display list how flashes uses it. I need some point and rectangle geometry for it, the rest is simple pixel putting. I'm currently learning more about how it works internally and it really helps to read through leJOS source code for performance references, what function does work how and so on. I recommend reading the source of libraries one uses everyday. It's instructive and improves your own ability to understand he languages you're working with. In case of leJOS, they combined C and Java code for everything that's not possible or impractical on a VM level (just saying the many system functions you need to get from somewhere into Java). However, the rendering system works by providing a tree of graphical objects that can be rendered with a command. Changes/additions to the scene are applied during the next call of the renderer: it first checks a list for deleting and adding new objects. Depending on what bounding boxes overlap and where to add/remove, it will redraw the affected areas. I think this can be improved by knowing whether the display object does masking, special operations or simply setting pixels without caring about the ones below. I should also add a query for moving objects, so that I can profit from C-implemented bitblit operations (for bigger moving bigger areas it's probably much faster than a Java equivalent). The use of managing all graphical systems this way is that you can call a single render command every x milliseconds with minimal drawing operations to do. Plus I can also take the freedom to implement custom graphical objects that work on the same principles. It's a bit like GUI drawing. This was also the original idea for what I designed it: drawing a GUI or atleast something that doesn't like a pathetic text-only interface. I don't have a problem with text interfaces, but on so small screens it's a complete waste. Interestingly, one could write a mouse-alike input using sensors to get a modern window-based interface done. However, I designed a much better version for inputting whatever many keys one want using distance sensors. So I can create all kinds of buttons by using a single sensor (I guess I mentioned the idea in previous post some months ago). So whatever complex input system I want - 6 buttons and some numbers are enough for numeric input and navigation...

Oh, the time!

No comments: