On Wed, Feb 15, 2012 at 6:43 AM, JMGross <[email protected]> wrote:
> Hi!
> ----- Ursprüngliche Nachricht -----
> Von: Peter Bigot
> Gesendet am: 15 Feb 2012 02:38:08
>
>> I was horribly confused because I first
>> encountered:
>> mov 8, r15
>
> which loads a value from a memory cell 6 bytes behind this instruction.
No, it loads a value from address 8. Which could be an arbitrary distance
from the instruction:
.skip 200
mov 8, r15
mov 8, r15
mov 8, r15
mov 8, r15
assembles to:
c8: 1f 40 3e ff mov 0xff3e, r15 ;PC rel. 0x00008
cc: 1f 40 3a ff mov 0xff3a, r15 ;PC rel. 0x00008
d0: 1f 40 36 ff mov 0xff36, r15 ;PC rel. 0x00008
d4: 1f 40 32 ff mov 0xff32, r15 ;PC rel. 0x00008
>> which does not mean what I would expect
>
> What did you expect? Loading the pointer $+8 into R15?
I expected no translation on the value at all:
c8: 1f 40 08 00 mov 0x0008, r15 ;PC rel. 0x000d2
cc: 1f 40 08 00 mov 0x0008, r15 ;PC rel. 0x000d6
d0: 1f 40 08 00 mov 0x0008, r15 ;PC rel. 0x000da
d4: 1f 40 08 00 mov 0x0008, r15 ;PC rel. 0x000de
if I hand-edited that correctly. I think we agree now that expectation was
mistaken, although it's explained by your pointing out that the disassembly
is wrong (see below).
>> Most of the other errors I mentioned are still relevant, including the
>> off-by-two error in disassembly, which is not related to CPU15.
>
> Not directly. But what causes CPU15 could also have been misinterpreted
> when generating the comment, even if it is not a CPU erratum but intended
> behavior.
It could have, but wasn't. The error was that the address of the next
instruction was consistently used as the base for PC-relative offset,
rather than the address from which the offset was read. If you think of
immediates as being indirect auto-increment of PC (which they are), the
right solution is clear.
>>> .global extern
>>> mov &0x1000, r15
>>> mov 0x1000, r15
>>> mov &extern, r15
>>> mov extern, r15
>
> the produced
>
>>> 6000: 1f 42 00 10 mov &0x1000,r15
>>> 6004: 1f 40 fa 0f mov 0x0ffa, r15 ;PC rel. 0x07002
>>> 6008: 1f 42 00 10 mov &0x1000,r15
>>> 600c: 1f 40 f2 af mov 0xaff2, r15 ;PC rel. 0x01002
>
> looks right for all four cases
>
> 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.
In fact, that probably contributed significantly to my confusion and
expectation that disassembly should produce what was assembled: it wasn't
the assembly that was wrong, it was the disassembly. All makes sense now.
I'll add the bug report for that, and get it fixed.
> Symbolic mode is IMHO the least used feature on the MSP.
> However, with the new 1MB address range, and MSPs with 16k ram,
> the use of relocatable code with relative addressing could become
> useful in future.
That's why I'm validating everything relevant, and creating regression
tests, before adding far code support. Thanks again for preventing a bad
misstep.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
