1) How can I set the desired stack size to a small amount
such as 256 bytes?
with a stack of 256 bytes I assume you are not interested in a stack with a guard page :) you could simply create your own stack allocator - it needs only satisfy following requirements:
- member functions void * allocate( std::size_t) and void deallocate( void *, std::size_t) - most important the pointer returned by allocate() must be the start address of the stack and because ARM uses descending stacks (I know the instruction set supports ascending instructions too) it must be the highest address - simply calloc()/free() should do it
OK. I have a variety of custom allocators in my collections that will work for these simple first prototyping requirements. I have, for example, a custom allocator based on a chunk of re-usable static RAM allocated as a static array that I can size to anything (such as 256 byte) up front.
2) I do not want cross-build boost right now. Which asm/cpp files should I extract from context for ARM(R) to include as sources in my project? Please don't worry about me or my sanity here, I roll with cross-compilers and builds all the time!
- files fcontext.cpp and fcontext_arm_aapcs_elf_gas.S (headers?)
I will split up the build with the asm/cpp files extracted to my project workspace, whereas the Boost.Context headers will simply remain in boost 1.51. It is unconventional, but it should work for prototyping.
3) How can I disable saving/restoring of the floating-point context in Boost.Context? My target micro does not have an FPU?
If the Cortex-Mx has no FPU so that you do not use the compiler flag --hard-float (or so) to compile your code. The asm preserving the FPU registers is wrapped by:
#if (defined(__VFP_FP__) && !defined(__SOFTFP__)) In your case the FPU preserving instructions will not be compiled. For sanity you could explictly disable FPU preserving via the 4th argument of jump_fcontext().
intptr_t jump_fcontext( fcontext_t * ofc, fcontext_t const* nfc, intptr_t vp, bool preserve_fpu = true);
regards, Oliver
OK, excellent! That all makes sense. Microcontrollers are tricky and sometimes you need to use an in-circuit emulator (ICE) when assembly programming is involved. I will give it my best try in the short time I have and see if it works. It sounds more like a multi-day endeavor. But I only have a day or two. I will report back with the results. Thank you. Sincerely, Chris.