I think most of what you responded to was superseded by a followup email. The way it works is how it is now documented on the wiki at https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Gcc46:Symbolic. I believe there are no ambiguities remaining.
Peter On Wed, Mar 7, 2012 at 11:40 AM, JMGross <msp...@grossibaer.de> wrote: > ----- 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 ------------------------------------------------------------------------------ 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
