Bunch O' Updates

The SystemC-on-RTOS thing has been executing on top of POSIX for a while now, so I finally have been able to play with the whole concept a bit more fundamentally than I was able to do previously. FreeRTOS doesn't come with multicore support out of the box; there is a working implementation out there somewhere, supposedly - I haven't been able to find it with the cursory amount of searching I've done so far, which means that I have to test in single-threaded mode on my slow-as-shit old Linux/Ubuntu development box, and it is therefore running extremely slowly during testing. Nevertheless, I have finally been able to do some non-trivial runs using GDB, which has shown me the next problem: testing execution in userspace using a single statically-compiled binary blob crashes in libstdc++, somewhere in memory allocation code. I still haven't figured out how to fix the bug and debugging it using GDB is slow and a real PITA in general, although I also took a while off coding to ruminate. I guess need to get that code running bare-metal in an emulator or on test hardware to get a faster build-debug cycle (or to maybe get lucky and find that it is a multithreading issue in the RTOS code). I need to track down that FreeRTOS multicore support code... anyway, that's the zeitgeist over here.

I REALLY wish that I could have justified continuing to try to use SpecC on this project. If nothing else, this whole situation has really reminded me with a sharp stick of why I hate using C++ at the system level. It is SO easy to lose scary amounts of performance over seemingly trivial architectural decisions made using OOP design practices. The OOP-related intricacies of both the libstdc++ and the SystemC reference simulator code are painful to handle and very obviously are potentially going to lead to problems with performance in general. Some of that will be removed if I stick to using the standard SystemC objects as merely allocation and nonvolatile-type state containers for threads instead of more abstract containers for dynamic allocation of signals and other such ephemeral state data, but it is still going to be a bitch to deal with. I probably won't be able to pin down how much of a problem this all is until I get the multiprocessing code, test on bare metal with more hardware cores, turn the -O option on GCC up more, etc etc etc. It is still going to be a while before that type of profiling is possible, unfortunately, and I can only hope that I don't end up wasting more time than fixing the wierd SpecC showstopper bug I quit using SpecC in favor of SystemC over would have taken. Oh well, many software development projects' architectural design descisions have turned on issues such as this throughout history - all you can do is keep putting one foot in front of another until you get the quarters and mills dialed in.

Onward!