----- Ursprüngliche Nachricht ----- Von: David Brown An: mspgcc-users@lists.sourceforge.net Gesendet am: 06 Okt 2011 15:58:12
> This isn't a flame war, but it is an interesting discussion! I agree. And it shouldn't get into one. However, I fear that people could get bored by a discussion that strays from teh msp topic to a way more general topic and is of rather limited interest for most (yet I appreciate everyone who _does_ listen to this kind of discussion just out of curiosity, takign a chance to learn something or to get his existing knowledge extended, confirmed or proved wrong - including myself) >> It depends on how you define a stack. Bascially, a stack is a LIFO buffer. >> Being able to access elements on the stack that are not on top of the stack >> is not a requirement for being a stack. >That's true. The requirements for a structure to be a "stack" are that >you can add something to the top of it, and you can take something off >the top (LIFO). >In practice, most stacks have other operations, such as detecting stack >overflow and underflow, or accessing data further down the stack >(obviously that's /very/ useful for a stack holding local data). Not just useful, but vital. A stack that's just a LIFO buffer is not suitable for holding local variables. It is, however, suitable for saving registers, so they are free to be used as local variables. But this limites the size of locals. > The SPARC has 32 registers. 8 of them, %g0..%g7, are "normal" registers > in that they hold the same data independent of function calls. > Then you have "in" %i0 .. %i7, "local" %l0..%l7 and "out" %o0..%o7. > These form a 24-register window onto the large register stack. When you > make a function call, this window moves 16 registers in the stack so > that the "in" registers point to the same register stack entries that > were "out" before, and the "local" and "out" registers point to new > registers. I'm not sure about the 32 registers. 32 simultaneously accessible, yes. so 32 register names to be used in instructions. However, the different access 'names' address changeing storage places. I dimly remember, that after a small number of 'rotations', you arrived on the first set again, so the storage locations formed a ring buffer. If a buffer over/underrun happened, an exception was triggered, and it was the job of my monitor software to catch it and save/restore the freshly 'appearing' register contents to/from a fixed location, so the 'stack' size was virtually limitless. Without this code, the similarity with a typical stack was spoiled. > You have a LIFO structure - it's a stack. But you also have a FIFO structure with a fixed storage size. (just like those chain storage buffers used for analog delays half a lifetime ago) >> So the MSPs stack is also a hardware stack. > I'd call it a "software stack" if it is in main memory (as is the case > for the msp430), and "hardware stack" if it is in a dedicated hardware > structure. But the difference can be a bit fuzzy. Indeed. The MSP has a dedicated PUSH operation, that utilizes R1 only, so it is no plain software stack (even if you could simulate it in software completely, with some loss of performance). Also, the interrupt handling is completely in hardware and there is no way to simulate it in software at all. YOu can simulate the call itself in software, but there is no way to exactly simulate RETI, as a software simulation would expose the chance that you get a new interrupt before you execued the return from the last, which increases stack usage and is different from RETI. So it's a hardware-assisted software stack? :) > This I have to challenge - either you are wrong, or I'm in danger of > learning something... I'm exposed to this risk all the time. :) Mos tof my knowledge comes from observation, not from reading books. Books are the second source when observation is not enough or gives ambiguous results when analyzed. >> Of course, if you define a stack as 'a stack is where local variables go', >> then you're right by definition. But it is NOT the only way. And other >> implementations, as scarce as they might be, do not automatically >> implement a stack. >> Take a look at vprintf(). It implements variable parameters without stack. >> What you can do explicitely in your code to use vprintf could be done by >> the compiler implicitely for printf. > vprintf is not a C variable argument function. It is a function with > two parameters - one points to a format string, the other is a structure > holding information about a list of arguments. >> In fact, the typical implementation of printf just passes the current stack >> pointer to vprintf, where the parameters are handled completely >> independent of the storage location. > And where are the variable arguments stored? On the stack. Here you lost the track. When I can turn the stack-stored variable parameter list passed to printf into a fixed parameter list for vprintf (without moving/copying the data!), then there is no reason why I cannot just implement variable parameter lists that way. Flex does it this way: the variable parameter part is passed as an array object to the called function. Well, Flex is ActionScript and as a script language, the usage of a stack for parameter passing is less obvious/desireable. But a compiler could as well take the variable parameters, store them in an allocated space of any kind, and pass apointer to this location as a single parameter. That's basically what printf does before it calls vprintf. Whether the storage location was the stack (as the C compiler usually does) or somewhere else, is just an internal thing of the compiler. > If you /don't/ have a stack, where can you store them? In some cases, > the compiler can determine in advance how many arguments there are and > how much space is needed - it can then store them in statically > allocated memory, The compiler always knows at compile-time. Only the called function does not know how many parameters are coming. The calling function always knows. Sure, one could construct a case where the callign function pushes a variable number of parameters on the stack, based on runtime requirements. But this would require usage of inline assembly and is not in the scope of the C language. As it requires manually dealing with something (the stack) that is not in the scope of the C language at all. So for the called function, instead of implicitely using the stack pointer for access to the variable parameter list, the compiler could just pass the poitner to a fixed or dynamically allocated location, and the called function just uses this pointer for access. Just a compiler implementation thing. >> Even recursion is doable without a stack. Yet I agree (and already did) >> that a stack is the easiest solution, so it is by far the most successful >> one. > As you say, there is no doubt that a stack is the easiest way to hold > data for such code. But I really am curious to know of any other > solution that does not boil down to a logical stack. A typical stack isn't suitable if you have structures where the called function does not immediately return. Multi-treading/tasking is such a situation. Of course you can say 'every thread then has its own stack' and that is how it is usally handled. But if you follow this path to its end, you'll end up with as many stacks as you have data to store and then there is no more difference between a stack and a heap. Usually, stacks for new threads _are_ allocated on the heap dynamically. And even if you allocate them statically, or in hardware, what is it then? A LIFO with the ability to slice-out elements from locations within? :) JMGross ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
