3

I understand that sxt is sign extend instruction. But I don't understand how does this really work. For example if my r15 register stores byte 0045, then what sxt r15 would do to it?

haruhi
  • 177
  • 1
  • 13

2 Answers2

4

I've been working on problems that use this instruction a lot. To compress it down to a single function, I would write it (using Pythonic syntax) as:

def sxt(x):
    if x % 256 > 127:    # if top bit of low byte is set
        x |= 0xff00
    else:
        x &= 0x00ff

This could be written more compactly, and possibly more efficiently. This version is intended to be most intuitive for non-asm-natives.

Note also that the function assumes you pass inputs in as two byte words like the sxt instruction operates on, 0xhhhh where h is a hex digit, which you can do in Python.

Silas Barta
  • 403
  • 3
  • 9
  • In C, you can express it as `(int)(int8_t)val` to sign-extend from int8_t back up to a wider width. Python doesn't have narrow integer types so yeah you might want to emulate it with regular Python integers and keep everything signed-positive = unsigned. – Peter Cordes Jan 24 '20 at 02:43
  • 1
    I think you have a bug, though: if `x & 0x80` is zero, you need to *zero* the high bits. So you could do `x &= 0xFF;` / `x |= ((x>>7) - 1) & 0xffff;` if that works in Python. You almost certainly don't want `%` modulo. – Peter Cordes Jan 24 '20 at 02:46
  • @PeterCordes good point! What do you mean about not wanting `%` though? `x % 256 > 127` is equivalent to checking that `x & 80 == 0`, right? They both return true iff the 8th LSB is set, right? Updating answer to account for that case. – Silas Barta Jan 24 '20 at 20:39
  • I was thinking `%` would be slower in Python, not getting optimized to a bit-test. But on 2nd thought [Why are bitwise operators slower than multiplication/division/modulo?](//stackoverflow.com/q/54047100) pointed out that bitwise ops aren't special-cased for small integers so even division is faster than `&`. If negative `x` is impossible, and/or Python `%` gives 0..255 modulo (not remainder) then it's fine for correctness. BTW, you should remove the wrong version from your answer. Edit to make it what you want future readers to see. Talking about edits is for the change note. – Peter Cordes Jan 24 '20 at 21:04
  • Right, the assumption is that `x`'s "type" is the same thing that the MSP430 instruction operates on, which is a two-byte word of the form `0xhhhh`, where `h` is a hex digit. In python, something passed in like that will always be treated as positive, so `%` should behave correctly in the function. – Silas Barta Jan 24 '20 at 22:34
  • 1
    Ok, but that would mean a hypothetical Python emulator for MSP430 couldn't just use `x - y` because that could produce a negative integer. The whole point of sign-extending is that you take a narrow signed input and produce a wider signed output (2's complement encoding in the case of MSP430), so I was assuming you'd want it to work for negative Python integers. (Which might represent a 16-bit integer with *its* high-bit set, in a hypothetical emulator). But sure, it makes sense that you'd just hold the 16-bit bit-patterns as non-negative Python integers. – Peter Cordes Jan 24 '20 at 22:50
  • 1
    I just tested though, and Python 3's `%` does actually work the way you need it to for negative integers. e.g. `(15 - 32) % 256` is `239`, which is the correct result. Same as `(15 - 32 + 65536) % 256`. Python's `%` is a true modulo, not a remainder like in C. – Peter Cordes Jan 24 '20 at 22:53
  • The purpose of my version is to convey what I wish someone had told me (or similar people not well versed in assembly) about `sxt` to get an intuition for it when walking through a debugger and anticipating the effect on MSP430 words. I wouldn't recommend this as a part of an emulator written in python. In any case, thanks for giving the context of `sxt` and looking up the use of `%` in python! – Silas Barta Jan 24 '20 at 23:39
  • Yes, I understand the purpose of writing it this way. That's why I upvoted it. :P I think *I* would find `x & 0x80` more clear (regardless of how the rest is written; yes of course a simple if is good for clarity), but I'm the opposite of your target audience. For me, I have to mentally decode `% 256 > 127` back into checking if the low 8 bits are a negative 2's complement integer, i.e. just checking the sign bit. Writing those constants as hex might help, and/or using `>=`. Like `x % 0x100 >= 0x80`. Hmm, not as clear as I thought it was going to be. I think `x % 256 >= 0x80` looks good – Peter Cordes Jan 24 '20 at 23:47
1

The sxt instruction sign extends a byte into a 16 bit word, i.e. it copies bit 7 into bits 8 to 15 and then updates the flags appropriately.

For your example, sxt would have no effect as the byte 0045 does not have its most significant bit set, so the high byte of r15 stays at zero.

fuz
  • 88,405
  • 25
  • 200
  • 352
  • why does it have no effect? I mean... the 7 bit will still be copied to the 8 bit and since the 7 bit is 1, it does still have some effect right? – haruhi Jan 11 '20 at 12:16
  • Oh i see now, the 7 bit is not 1 but 0 ><. Thank you for your answer! – haruhi Jan 11 '20 at 12:17