----- Ursprüngliche Nachricht ----- Von: Peter Bigot Gesendet am: 17 Feb 2012 18:34:16
> So everybody can see what we're talking about, here is the gas/symbolic > test program from the tests/next branch of the mspgcc repository. [...] > A couple lines are commented out because the current assembler won't > process them, something I consider to be a bug. I would be interested in > knowing if other tools accept $ as denoting the program location counter in > contexts other than jump instructions, and if so whether it means the > beginning of the instruction or the address of the offset encoded internal > to the instruction. IIRC, old BorlandC DOS compiler inline assembly accepted $ too for read/write instructions. And it was referring to the begin of the instruction. I'm surprised that the assembler currently does not accept jmp $. This is the typical notation in TI documents for what happens when you fetch an instruction while the flash controller is busy, or what you get from vacant memory space. Also, the assembler should accept $ as reference in symbolic mode. It makes less sense in absolute mode or for immediate values. (well, of course the assembler can place a symbol on this line and make the linker resolve it, but "$+x" makes things even more difficult then) A big advantage of supporting this would be some help in the disassembly part: while mov 0x1000, r15 still makes sense after building the object file: 4: 1f 40 fa 0f mov 0x0ffa, r15 ;PC rel. 0x01002 (with 0xffa of course being as wrong as 0x01002) it ceases to make any sense after linking: 6004: 1f 40 fa 0f mov 0x0ffa, r15 ;PC rel. 0x07002 since 0x0ffa (or rather 0x1000), which still would have been 'correct' before, is now horribly wrong. Assembling the code again now, with 0x1000 here, would lead to referencing 0x1000 and not 0x7000. So it should rather read 6004: 1f 40 fa 0f mov 0x7000, r15 ;PC rel. 0x07000 Which is, of course, somewhat irritating. The only solution I can come up with is disassembling symbolic mode (unless there is a symbol available that can be used) as what it is: relative to the program counter. The disassembly would then read 6004 1f 40 fa 0f mov $+0x0ffc, r15 ; PC rel. 0x7000 which is exactly what this instruction does. (See also my comments below to your other post) > Be aware that all PC rel. comments are two bytes too high, due to bugs in > the > disassembly<https://sourceforge.net/tracker/?func=detail&aid=3487360&group_id=42303&atid=432701>. And may even be 4 bytes too high if the instruction has two non-register operands. > I consider the assembly of the instruction at 0x6038 (originally jmp $+0) > to be indefensibly wrong. Indeed. jmp $+0 should be of course equal to jmp $. And the correct binary translation of this instruction is 0x3fff and not 0x3c00. No discussion required. That's an ugly bug. I also agree, that disassembling to $+-offset rather than an explicit address is the better approach. as long a s the comment is correct. As I already proposed for symbolic mode. However, if the target address matches a known symbol, this should be added to the comment. And it might be considered using this symbol in the instruction too. > I consider the fact that you can't pass the output of the disassembler into > the assembler and get back what you put in to be indefensibly wrong. I totally agree. > (As somebody suggested before, this has no relevance to C/C++ programmers > unless you use asm statements, and what we're discussing is exactly how > msp430-as/msp430-objdump/msp430-link/etc should behave.) Well, a while(1); could compile into jmp $ and then you'd get a problem with the current assembler even if not using assembly instructions. I guess the compiler is producing something else (less efficient), since nobody complained so far. ;) ----- Ursprüngliche Nachricht ----- Von: Peter Bigot Gesendet am: 19 Feb 2012 20:37:45 > The mental > model for jmp "operands" will have to remain confusing, though if I > can successfully make non-jump symbol operands work as they did, I may > make "jmp label" and "jmp symbol" consistent again too. (I doubt > anybody has ever relied on "jmp symbol", but it has to have clear > semantics if we're going to make this toolchain robust.) well, the errata sheets of some MSPs list problems if someone does a push SP/POP SP or even a CALL SP instruction. I tried hard to think of any use of it (except trying to fool a virus scanner :) ), but it was obviously considered worthy to make it into the errata sheets. In fact, using SP in an instruction that alters SP (push/pop/call) exposes the same kind of problems as using symbolic mode instructions. And jumps. I agree that, if possible, things should work for all cases consistently. I fit is not possible to do it consistently, then you only have the choice to do it inconsistently or not at all. However, the inconsistent case should be properly documented then. (well, nobody can accuse you to not doing it - but those working on MSPGCC before you seem to have been more lazy with documentation) > The proposal I made below has been implemented. >> However, unless somebody can convince me this analysis is wrong (which is >> part of why I'm posting this), in the next development release of mspgcc the >> original code will produce: >> >> 6000: 1f 42 00 10 mov &0x1000,r15 >> 6004: 1f 40 00 10 mov 0x1000, r15 ;PC rel. 0x07006 >> 6008: 1f 42 00 10 mov &0x1000,r15 >> 600c: 1f 40 00 10 mov 0x1000, r15 ;PC rel. 0x0700e assuming this was the proposal you were referring to, it should rather read: 6000: 1f 42 00 10 mov &0x1000,r15 6004: 1f 40 fa 0f mov $+0x0ffe, r15 ;PC rel. 0x07000 6008: 1f 42 00 10 mov &0x1000,r15 600c: 1f 40 f2 0f mov $+0x0ff4, r15 ;PC rel. 0x07000 as this disassembly reflects the relative character of the instruction and does not morph the linker relocation back into the source code However, if the target is a known label or symbol, this might be used instead. Or at least included into the comment. However, that's partly guessing as it might be pure coincidence that the instruction target falls onto a known label/symbol. Disassembling code from binary inherently lacks some information and therefore introduces some ambiguity. There's nothing you can do about this. JMGross ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
