On 07/10/11 14:11, JMGross wrote: > ----- 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) >
I'm off on holiday very shortly, so I'm going to save people from getting bored! >>> 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. > I didn't know the register window rotated like that - perhaps it varies according to exactly which SPARC you use. Of course, I haven't actually used any SPARCs - only a SPARC-like architecture (the original Altera NIOS). >> 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? :) > Ah, we have slightly different definitions here. When I said a "hardware stack" has dedicated hardware, I was thinking of something like the stack in the PIC (or the register set on a SPARC) where the stack contents itself is in special hardware - not just that the processor has a dedicated stack pointer register. >> 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. > I see what you are getting at now. I concede this point (for now, anyway :-) But you still don't get to do recursion without a stack, or another data structure that is acting like a stack. >>> 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? :) > Efficient data structures for multi-threading is very difficult - as are structures to support things like co-routines which don't follow a nice simple LIFO system. mvh., David ------------------------------------------------------------------------------ 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
