----- Ursprüngliche Nachricht ----- Von: Peter Bigot Gesendet am: 15 Feb 2012 14:47:48
>>> 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: Right - and wrong. I was assuming that the code starts at 0, Which it indeed does not when there is code before, or a .skip or .org etc. However, it does not refer to the absolute 0x0008, but to the _current_ 0x008 in the context of the current assembly pass. Well, if you give the code a fixed position with .org, this becomes a rather absolute relation :) >> 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 > 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). I see. As I already pointed out, it would be really difficult (and therefore useless for not automatically generated code) if you had to know and enter the offset in your assembly source, rather than the address. What woudl happen if you place a resolvable symbol instead of the offset? Is then the value the symbol resolves to is taken as offset? Wouldn't be of much use :) >> Most of the other errors I mentioned are still relevant, including the >> off-by-two error in disassembly > 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. Indeed. And 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. Digging deep in my memories, I think i discovered this too when analyzing some things year ago. But I didn't care since I knew the +2 offset then (but didn't think of the possible +4 offset), and it was of no relevance for my current problem anyway. :) > 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. Thanks for all your efforts. >> 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. You're welcome. It's a give and take. Even though I collected quite a lot MSP related knowledge in the last years, I too still learn new things every day - or are encouraged to look at them form a new angle. >From this topic, I got the idea of loadable dynamic link libraries, using symbolic mode into jumptables. Maybe it will lead to something useful later. ------------------------------------------------------------------------------ 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
