The near space launch went off without a hitch. We launched it at 0640 in the morning and recovered it a few hours later. To see the path the balloon took, please visit the Near Space CONNERY-1 page.
Yes, we really did name our first balloon flight ever CONNERY-1, read the Wiki page for information as to why :-P.
School has started again, I am taking six classes. I am now really gearing up to finally leave UAT and go out into the work force. I have this semester, and two more to go and then comes the decision; graduate school or work? Not entirely sure yet which I want to do, but that is what life is all about, trying to figure out what the best would be, and possibly finding out it was a mistake and growing and learning.
There are others things that have been going on lately, I have been spending much time behind a computer screen programming. The intellectual challenges it provides me with are very enjoyable and great way to stay mentally fit. Also as a perfectionist by nature, it makes it really hard to start working on something and then put it down to go to sleep, it has to be perfect. That is probably also the reason why I now have a 300 line patch set instead of 500 lines. Yay for removing redundant code, and re-thinking the problem/solution.
Other things that I have been working on is a challenge that my room mate Victor (Pancho) gave me. It requires a recursion to complete the problem. In itself this does not generally present a problem, as the max recursion level is going to be limited to a fairly reasonable number, however in C/C++ there is still a massive amount of overhead when doing a function call. This includes things like setting up the stack, creating local variables, and then saving certain states. Extra garbage that you want to eliminate especially in tight loops. The problem however cannot be solved using for/while loops, or at least there is no way that I can figure out (if you want to know what it is that I am working on, contact me. Victor is going to make the challenge public later so I don't want to spoil it for everyone). So I have been writing some self-modifying code that unrolls loops on the fly. I will post code sometime in the near future when I have it partially working, not entirely sure yet how I want to proceed right now. More on that later!
Here is a bit of Intel assembly written in AT&T syntax for GCC to grok for Mac OS X/FreeBSD machines that use a stack based syscall infrastructure:
__asm__("pushl $21;\n" "pushl %0;\n" "pushl $0x1;\n" "movl $4, %%eax;\n" "pushl %%eax;\n" "int $0x80;\n" "addl $16, %%esp;\n" : : "r" (answer) : "%eax");
Note that the length of the string is 21 characters (20 characters, and a
newline which I appended before printing), and that answer is the char *. See
my previous Intel post to
see what the code does, and why. It is exactly the same printing routine, only
difference is the assembly syntax. It really is too bad that GCC for Darwin
does not grok the .intel_style inline assembly, it would have made things much
easier.
You should be able to modify it to accept an integer to push onto the stack, however I have been unable to figure out why the following is not working:
__asm__("pushl %0;\n" "pushl %1;\n" "pushl $0x1;\n" "movl $4, %%eax;\n" "pushl %%eax;\n" "int $0x80;\n" "addl $16, %%esp;\n" : : "r" (length), "r" (answer) : "%eax");</pre>
Assuming length is an integer and answer is a character pointer. It is kind of frustrating, because there are not many good resources out there on the web that explain inline assembly for GCC. The few that I have been found have been rather vague and have not explained very much. Maybe I am just using the wrong words, and or my Google-Fu is not strong enough.
Speaking of inline assembly, I have heard from some friends that are running on 64-bit systems that if you compile 64-bit binaries for Windows in Visual-C++ 2008 you are not allowed to use inline assembly, they have removed support for it. Does that seem wrong to anyone else? That seems like it would frustrate many developers of tight code that runs many times faster in assembly than using compiled code. Sure compilers have been getting better for ages, however at the same time in assembly the programmer has a lot more control over the CPU and where time is going to be spent than any other way.
Oh, Erlang is my new shiny programming language to learn.