On Fri, Feb 17, 2012 at 6:25 AM, JMGross <msp...@grossibaer.de> wrote: > > ----- Ursprüngliche Nachricht ----- > Von: Peter Bigot > Gesendet am: 16 Feb 2012 16:22:53 > > >>> I think (even though we both didn't try) that an instruction >>> with symbolic mode for source and destination, would have the source >>> off by 4 and the destination off by 2.
This has been verified. >> The existing inconsistency between jmp 0/jmp $+0 and jmp 2/jmp $+2 will >> also be preserved in the regression suite. > > What inconsistency do you mean? Not worth arguing. BTW, the following, which I thought was enlightening, turns out on further thought to be confused: > But the disassembly mnemonics should read 0x1000 in all four cases and NOT > contain the offset as parameter but the offset + PC. As this is what you have > to feed the assembler to get this instruction. The assembler calculates the stored offset based on the constant operand and a temporary guess as to the instruction's location. Because the disassembler can't know what "start of section" might mean if the disassembled code was placed into a source file, it's not possible to provide a constant that can be fed to the assembler to reproduce the instruction. Which is why I return to my position that a symbolic address expressed as a constant should simply put the code-provided constant into the operand and not muck with it. This *would* permit a round-trip asm/disasm/asm. What the assembler does now when the symbolic address is a label is fine, but the constant---no. Does anybody else have an opinion? Is anybody else still there? Peter ------------------------------------------------------------------------------ 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
