----- Ursprüngliche Nachricht ----- Von: Peter Bigot Gesendet am: 18 Apr 2011 16:50:17
> I vaguely recall from when I first started with gcc in the early '90s > that the gcc developers disavowed correctness for unoptimized code, > saying they always used -O. Well, the unoptimized code seems to be correct usually. Yet not optimized :) However, optimization is sometimes causing bugs. And I didn't say that the code is not correct. It is. It is just not taking care of the fact that the assembly instructions were using 20 bit registers while the compiler did not kow of 20bit registers at all. > That may be apocryphal, and is certainly > not true for the msp430 back end while I'm responsible for it. We expect no less from you :) > However, gcc's internals are significantly simplified by generating > the most obvious code possible from what the front-end requires. >Without -O, that's what you're going to get, even if it involves >moving a value from one location to another six times before returning >it. Sure. Each instruction taken for its own. That's simple. And that was the problem in this case. > It's not being stupid; it's just doing what you told it to do. Well, not exactly. But it's what the compiler undestood. I told to provide a target register and then use it as source in the next instruction. I didn't tell that this register variable needs to be stored in a memory location. However, without optimization, it's difficult for the compiler to decide whether to use an auto-register variable or a 'real' one. I think just to use a register and declare it clobbered had lead to the correct behavior - with the risk of any compiler added code breaking the use of this variable across asm instructions. (but then, why should it add code in between?) >Doesn't there need to be a nop between the clear of GIE and the >following move? The DINT instruction description in the manual >implies that without it the interrupt could still occur during the >first movx. That's what I always though too. And in the very first version of this code, it was. However, people kept telling me that it is not true and the interrupt logic will take care of this. So I dropped it. And never noticed a problem. However, this is a field that should be investigated. Maybe it's only happening for unsynchronized interrupts (exernal or from a source clocked by a clock that is not synchroneous to MCLK) DINT is immediately active when the GIE bit is cleared. However, the moment the bit is cleared, the next isntruction word is already fetched. So the question is, if there's an interrupt at this moment, is the next instruction still executed or is the already fetched instruction dropped. If it is executed, what happens to the interrupt latency? In the datasheet it is given as a fixed number of cycles. Not a 'from-to' depending on the up to 5 additional cycles executed from the currently executed instruction. The manual isn't clear on this. Also, what happens if you enter LPM? Is the next instruction frozen before entering LPM and executed when the system wakes up - before the SR is saved to stack and the LPM bits cleared? And what happens on return from an LPM interrupt? Normally, the CPU will execute at least one instruction before the next interrupt happens. However, RETI will enter LPM again and main is NOT expected to continue one instruction per interrupt in LPM. But then, RETI has PC as target of the last instruction cycle, so no instruction fetch happens interleaved. And I guess the CPU freezes before the return address is even fetched (but when SR is restored). The manual is a bit 'spongey' about those internals. But thanks for pointing this out. I knew I read it somewhere, just didn't remember where, so I was persuaded by those who questioned it. JMGross ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
