I cannot imagine that the very significant engineering effort of pulling this off would result in any significant change to the expected battery longevity, unless 80-90% of your awake time is spent without BLE advertising or connection, in which case, if you are going to spend the time to make this work, go all the way and use the 16-MHz internal oscillator instead of the power-hog 32-MHz crystal and get some bang for your buck. I am of course assuming that the TI BLE stack needs the full throughput of the puny 8051 in order to meet the BLE specified timing requirements, so please correct me if I am wrong. But, given this assumption, you will have to very carefully and statefully work around any use of the radio (connection or advertising) when you throttle the clock or switch to 16-MHz. As a general rule of thumb in embedded systems, it is almost always just better to wake-up, run as fast as you can to get whatever you need done as fast as possible, and re-enter sleep, where your truly significant, measurable battery longevity will be achieved. Obviously, you need to get rid of all dumb waits for this general rule of thumb to hold for your system (i.e. use timers and sleep to 'wait' for events, don't just block and sit and spin). So,
1. Yes.
2. I am assuming that the impact is that you cannot use the radio/BLE stack in any clock crippled mode.
3. Everywhere, but especially hal_sleep.c, as I assume you will need a new, stateful design to your system to track whether you are running the BLE or running in slow motion.
