----- Ursprüngliche Nachricht ----- Von: David Brown Gesendet am: 06 Okt 2011 11:20:57 Betreff: Re: [Mspgcc-users] VLA in MSPGCC
On 05/10/2011 18:24, JMGross wrote: >>> Many CPUs allow any register to be used as a stack pointer (even >> Indeed. The MSPGCC compiler often uses a completely different >> register to hold the stack frame pointer. However, usually one >> dedicated register keeps track of the TOS, so push and pop operations >> won't go wild. At least the pop could be implemented on any MSP >> register (MOV.W @Rx+, Ry). The 'real' POP is emulated this way, with >> Rx=R1. > These are details of the implementation of the stack - it's still > logically a stack. I didn't deny that. I was referring to the "many CPUs allow any register to be used as a stack pointer". MSP430 partially allows this too. > Again, that's a stack. The difference is that it only moves in fixed > jumps, and that it was (originally) implemented inside the processor > rather than in memory. The registers work as a window onto the stack. 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. (see the forth mathematical stack) Also, the rotating SPARC register set also rotates the working registers of the processor, which definitely isn't the job of a stack at all. >> Writing a C compiler for this would be a PIA. I had to program it in >> assembly (write a monitor that handled an overflow/underflow of the >> "register wheel" when the code was nested too deep) >That's always the problem with hardware stacks - you have a limit to >their size, and if it's not big enough things get very inconvenient. So the MSPs stack is also a hardware stack. Once you need to grow it beyond the (still very limited on some MSPs) size of RAM you'll get into trouble too. So where ends a hardware stack and where begins a software stack and what's is the effective difference. But we both agree that there is no stack at all needed for local variables (while it usually is used for them), and that not every stack is the same. I don't want to start a flame war about implementations. I just try to fight the impression that the commonly used implementation is the only existing or possible one. This often leads people into trouble, sometimes without even noticing it. >> however, the concept of a stack is only one concept (even if a >> successful and commonly used one) and one commonly used to store >> local variables. But it is not the only one and not the only way to >> deal with local variables. And if you don't have a stack, there is no >> need to simulate one, just to do C. > Actually, you /do/ need to simulate one to do C - there is no other way > to implement recursion (while you could, theoretically, use other > structures such as lists or heaps, you would still be simulating a > stack). Variable argument functions also require a stack to implement > fully. And while these are features that are seldom used in embedded > systems, they are still required for a C implementation. "No" to all of them. Sorry. 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. 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. 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. ----- Ursprüngliche Nachricht ----- Von: Eric Decker An: David Brown Gesendet am: 06 Okt 2011 11:17:45 >>> Just like the idea that you need to have sex to get pregnant. Correct >>> for the very most occurrences but not for all. And not knowing that >>> there are exceptions to the rule makes you more prone to be a victim >>> of these exceptions. >> Perhaps I don't get out of the office enough, but I can't think how one >> could get accidentally pregnant without sex! > I beleive this a nod to the religious concept of immaculent conception. Not only. It is just the most prominent case. After all, it depends on how wide you span the definition of 'having sex'. If you extend it to 'having contact to a male, directly or indirectly', then every possible situation is covered. But the usual difinition is much narrower. For some very much narrower. And if if you exclude cases of medical aid, there are enough other possibilities, extending to using the same toilet (unlikely but not completely impossible). But since this is a public mailing list, I don't want to get into details for the other (more likely) ways. :) >>> As for the PIC: >> I've only programmed them in assembly. It was fun, in a perverse sort >> of way. > Definitely perverse. I used to write micro-code (the stuff below > assembly), but then again I used to design 180 bit wide horizontal custom > processors too. During my time at the university, I once built a 4 bit CPU, including microcode, from plain TTL. Well, you don't get far with only 16 instructions. No DOOM implementation or such. It was just a side project to get a checkmark. However, the whole bunch of TTL and wire-wrap worked well with 400kHz clock speed and executed some calculation programs (that made the LEDs attached to the accumulator register blink a light show). It's been looong ago. :) >> And it is no processor at all. [PIC] > Depends on the definition of processor. Agreed. If you call everything a 'processor' that can process a list of instructions, then it is. > And now back to our regularily scheduled program... :-) I second you with this. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
