Talking only makes yourself look stupid
On Saturday I blogged about not needing new and delete. However it turns out that on Sunday I found out a use for new and delete. Typical.
I have a command line interpreter that has various control and testing commands. It's very simple (and was fairly fast to write) but it's really proven it's worth in testing. So much so that (together with the ability to write back to the PC terminal via the serial port - effectively print) that I haven't bothered to get the GDB debug stub up and running.
Anyhow, I wanted to test out a new class I'd written independently from the classes that use it. Sort of 'unit test an instance of that class'. Obviously with procedural code you just patch in the functions. Not so simple with OO because you need to create one somewhere first. Since it's not in the scope of one function (several commands to exercise it) the stack (i.e. an automatic) wasn't an option. And I don't want the object hanging around as a static either together with it's construction bindings to various input objects.
I guess I could have made it an optional compile as a static - but that means all the compile in and out whenever I make a minor change and want to retest. That isn't ideal.
I looked at what might be involved and it looked fairly trivial. Additionally the dynamic memory allocation might be useful for other things as well. Embedded programmers tend to be very wary - but I guess if either (a) memory usage is fully analysed, or (b) only non-critical (or extra) services use the memory, then there is no reason why dynamic memory shouldn't be included.
I'm still mostly using static objects and automatic-based objects in the design and the dynamic stuff uses any spare RAM, however much there is left ... from end of compiler used memory to end of RAM.
So, on Sunday I started implementing tiny but fully functional chained-list type allocator / deallocator.
On Monday I realised didn't really need that yet. So #if-0'd that out and wrote a braindead allocator based on the article here. It's a very simple allocation scheme ... no free function, just chews up the RAM. Turns out that is absolutely fine - especially with how much this robot gets reset (and hence the memory 'deallocated').
Simple.
Got it working Tuesday. Minor problem with getting access to linker variables from C++ without then being indirected twice ... had to get the address of the extern unsigned int in order to get the actual value I was after ... bizarre, but it works and the assembler listing from the compiler looks OK and it means no need to do anything in the assembler source. Wrote some debug words to test allocator (and return interesting info).
Then I wrote some test words to actually create, use and delete a test object. All works fine! Amazing. As it stands I have over 60K of free store RAM!!! No doubt that will go down as the project progress, but still.
Now I can get one with debugging that new class I wrote to do speed control... oh well, interesting diversion.
I have a command line interpreter that has various control and testing commands. It's very simple (and was fairly fast to write) but it's really proven it's worth in testing. So much so that (together with the ability to write back to the PC terminal via the serial port - effectively print) that I haven't bothered to get the GDB debug stub up and running.
Anyhow, I wanted to test out a new class I'd written independently from the classes that use it. Sort of 'unit test an instance of that class'. Obviously with procedural code you just patch in the functions. Not so simple with OO because you need to create one somewhere first. Since it's not in the scope of one function (several commands to exercise it) the stack (i.e. an automatic) wasn't an option. And I don't want the object hanging around as a static either together with it's construction bindings to various input objects.
I guess I could have made it an optional compile as a static - but that means all the compile in and out whenever I make a minor change and want to retest. That isn't ideal.
I looked at what might be involved and it looked fairly trivial. Additionally the dynamic memory allocation might be useful for other things as well. Embedded programmers tend to be very wary - but I guess if either (a) memory usage is fully analysed, or (b) only non-critical (or extra) services use the memory, then there is no reason why dynamic memory shouldn't be included.
I'm still mostly using static objects and automatic-based objects in the design and the dynamic stuff uses any spare RAM, however much there is left ... from end of compiler used memory to end of RAM.
So, on Sunday I started implementing tiny but fully functional chained-list type allocator / deallocator.
On Monday I realised didn't really need that yet. So #if-0'd that out and wrote a braindead allocator based on the article here. It's a very simple allocation scheme ... no free function, just chews up the RAM. Turns out that is absolutely fine - especially with how much this robot gets reset (and hence the memory 'deallocated').
Simple.
Got it working Tuesday. Minor problem with getting access to linker variables from C++ without then being indirected twice ... had to get the address of the extern unsigned int in order to get the actual value I was after ... bizarre, but it works and the assembler listing from the compiler looks OK and it means no need to do anything in the assembler source. Wrote some debug words to test allocator (and return interesting info).
Then I wrote some test words to actually create, use and delete a test object. All works fine! Amazing. As it stands I have over 60K of free store RAM!!! No doubt that will go down as the project progress, but still.
Now I can get one with debugging that new class I wrote to do speed control... oh well, interesting diversion.
posted by RobZed at 10:37 pm
0 Comments:
Post a Comment
<< Home