Basic Q's about the Spin2 Interpreter Size, Content and Loading
I'm using the Propeller Tool ver. 2.5.3. When I press F8 to compile/view info, the popup window reports 4232 bytes being used for the Spin2 interpreter, and those bytes are displayed in the hex viewer on the right and colored pink. About this, I have a few questions (please pardon, but point out, any misconceptions in my phrasing of such questions):
 Will that always be the same total no matter what my program is? I looked at a handful of programs and it appears to be fixed. Perhaps this total could change for a future version of Spin2 (such as with built-in floating point), but my meaning is just for any particular version used for various programs. I would guess that the interpreter "engine" for processing byte codes would have a fixed size (and it seems to have, as mentioned), but I just wanted to check.
 How fixed is the content of those 4232 bytes? I assume that most of it is fixed. But I imagine certain values have to change, such as for the clock speed perhaps. I wonder if there is a certain range of that space that is totally fixed (seems likely). And I wonder if there is any sort of guide with insights into the interpreter, kind of like Cliff Biffle's humorous early Propeller Binary Format PDF guide for the P1 (Yes, I think that the interpreter code is available, but I mean a high-level description or overview for mere mortals).
 When the Prop2 boots (or otherwise loads in a program), will this exact same data load into the hub byte-for-byte starting at hub location $0 of the hub (without any gaps) and "march" upwards, not only for the interpreter, but also for the code/data section next and then the var section? Or do things get rearranged (or some things omitted/added)? That is, is the image that I see in the hex viewer on the right after pressing F8 in the PT the exact same image that will load into the hub? And if not, what are the differences, if I may ask?
 And what portion of this displayed interpreter code gets loaded into cog 0's registers (starting from where in the hub to where in the hub)? I've forgotten (or never fully appreciated) the details, but I think that the Spin2 interpreter utilizes substantial portions of a cog's RAM and LUT. But that's at most 2x512x4 = 4096 bytes (ignoring the fixed registers at the end of RAM), but the above 4232 is bigger than that by 136 bytes. So that means that some of the data just stays in the hub. Also, I assume that such loading is handled by the fixed firmware of the P2 (that is, there's no code in the interpreter (that gets loaded in) that is handling the cog loading). Please correct me if I'm wrong or have over simplified that (though starting byte code address(es) might be an exception, as below).
 And similar to question 2, for other cogs that get loaded (not just cog 0 on booting) with Spin2 interpreters, where are the addresses stored that tell those cogs where to start pulling their byte codes from? And are such addresses fixed upon compiling, or does a portion of the address need to be calculated at run time? Hmm, on re-reading this before posting, it occurs to me that there is probably just one copy of the interpreter code in a complete program's image (no matter how many interpreters it launches). Sorry, I didn't test that, but that seems likely to me to reduce code size. And given that one could tell a cog to fire up different methods, then I guess that the starting addresses for the byte codes must be dynamically calculated (or at least set) at runtime. I guess there's probably just a location in each Spin2 cog's interpreter instance that has this starting address. Of course, for the current chip, at max, only 8 interpreters can run at one time, so there could be one table somewhere for all the starting addresses, but that seems unlikely to me.
 Lastly, and this question diverges a bit from the above theme, are there any special values in the hub image that are acted upon by anything other than a cog? That is, is there anything in either the P2's firmware or even its hardware that directly accesses value in the hub? Or does everything go through a cog? For example, when the clock speed is set (other than the default value) in the P2's hardware, that's done through the "supervision" of a running cog, is it not? But, for example, is there anything in the P2 hardware (that's hardwired in, whether globally or on a per cog basis) that "reaches" into the hub for values (or that changes values in the hub) on its own without explicit direction from running code in a cog? I'm sure that the cogs do almost everything, but do they do absolutely everything? And feel free to mention any exceptional behavior by the firmware during bootup, if any.
I know that these are basic questions for most of you long-term followers, but I've never really given such concepts much thought. And on thinking about them today, I realized that there is a lot that I don't know. Ignorance may be bliss, but it ain't that bliss. Plus, in commenting (should anyone be gracious enough to wade through this), feel free to add anything that's related or that I haven't even thought to ask about. Thanks. --Jim