Author Topic: MSP430 PUSH.B  (Read 1250 times)

0 Members and 1 Guest are viewing this topic.

Online brucehoultTopic starter

  • Super Contributor
  • ***
  • Posts: 4331
  • Country: nz
MSP430 PUSH.B
« on: July 13, 2022, 09:27:22 am »
I've been reading the MSP430 manual, thinking about making an emulator for it. (I know some already exist)  There is one thing that doesn't seem to be made clear. Many of the instructions have very clear diagrams showing sample program bytes, src and dst RAM areas, and the exact changes to the dst area.

An exception is PUSH.B.

The manual is clear that byte operations with a memory src or dst load or store a single byte and do nothing else, while byte operations with a register dst store 0 into the hi byte.

PUSH.B decrements SP then stores the data at @SP.

As the stack must always be aligned, the decrement is by 2, not 1.

Does the write to @SP then modify only that 1 byte, leaving 1(SP) undisturbed?  This seems to follow from the description given. Or is the write done as a 16 bit write, zeroing the hi byte?


Oh. One other thing is not at all clear. R3 seems to be a "throw the result away" register, as any read from it, no matter the addressing mode, gives a constant. Is it legal to use R3 as a destination register for any instruction, even though the result will be invisible?

The NOP mnemonic is shows as generating "MOV #0,R3" (which in turn is encoded as "MOV R3,R3"). Is that a special case, or all instructions with destination R3 should be accepted but basically be no-ops (except for the effect on flags)? What about with addressing mode 1 i.e. offset(R3)? Should the instruction be  accepted? Should the offset be read from the program stream? What should it be added to? Does that give another way of encoding absolute addressing? (Absolute addressing officially uses R2/SR as the apparent base register)

Or, can you use R3 as the dst of an instruction to ACTUALLY store a value there, but it's invisible except if used as a base address for a dst using addressing mode 1?

Similarly, what happens if you use R3 as the src/dst register for a single operand instruction?

I imagine "PUSH R3", "PUSH 0(R3)", "PUSH @R3", "PUSH @R3+" should actually push 0,1,2,-1 respectively i.e. the same as any instruction using R3 as a src. The PUSH instruction specifies that the register is used in SRC mode.

But the other single operand instructions (let's say SWPB) specify that the register is used as a DST, albeit with a 2-bit address mode field. Can all four addressing modes be used?   If so, is the address generated used for both src data and the dst, or is constant generation used for the src?  So should "MOV #1234h,R3; SWPB R3; MOV #1,1(R3)" end up storing 0001h into memory address 3413h?  And "MOV #1234h,R3; MOV #5678h, &1234h; SWPB @R3" ends up with 7856h in memory at address 1234h?

Of course, you're not supposed to write programs like that, but what is a CPU/emulator supposed to do if it executes one?
 

Offline abquke

  • Regular Contributor
  • *
  • Posts: 128
  • Country: us
Re: MSP430 PUSH.B
« Reply #1 on: July 13, 2022, 10:51:29 am »
These seem to be questions only hardware would know...

It makes sense that a PUSH.B would write zeros to the high byte of the stack... but yes it's not clear from the manual what happens.

I'd like to believe that any operation with R3 as DST would basically be a NOP, but now there's a germ of doubt in my brain where there was once trust of my assembler.

Will poke at this
 

Online brucehoultTopic starter

  • Super Contributor
  • ***
  • Posts: 4331
  • Country: nz
Re: MSP430 PUSH.B
« Reply #2 on: July 13, 2022, 11:32:25 am »
These seem to be questions only hardware would know...

Yup. I could test it on an emulator, or read source code, but with little confidence that it matches hardware!

Quote
Will poke at this

Ta.

I suspect you maybe have to hand-assemble some of those instructions!
 

Online Peabody

  • Super Contributor
  • ***
  • Posts: 2106
  • Country: us
Re: MSP430 PUSH.B
« Reply #3 on: July 13, 2022, 03:22:02 pm »
TI has a forum where their techs participate.  You could probably get authoritative answers there.

https://e2e.ti.com/support/microcontrollers/msp430/f/166/

Well, ok, you could probably get *some* authoritative answers there.  But I suspect you'll have to assemble some code to test this stuff.  I recommend the Naken Assembler, which is a small command line assembler.  It also comes with a disassembler and a single-step simulator.  But of course the latter is only his understanding of how these things work, so you'll probably have to run some hardware tests to see what happens.

I assume you have a Launchpad, but if needed I can run tests for you.  I have three G parts - 2231, 2452 and 2553.  I don't have any Fs or FRs.

By the way, I really like these processors.  They're a bit expensive, but they are 16-bit von Neumann chips, which I think is just right.
 

Online brucehoultTopic starter

  • Super Contributor
  • ***
  • Posts: 4331
  • Country: nz
Re: MSP430 PUSH.B
« Reply #4 on: July 13, 2022, 10:50:14 pm »
I assume you have a Launchpad, but if needed I can run tests for you.  I have three G parts - 2231, 2452 and 2553.  I don't have any Fs or FRs.

I don't have hardware [1]. I'm just interested in writing an emulator and running gcc-generated code on it.

Quote
By the way, I really like these processors.  They're a bit expensive, but they are 16-bit von Neumann chips, which I think is just right.

I'm looking at using MSP430 code as a kind of interpreted "bytecode" on 8 bit CPUs with a 64k address space. It's simple, looks simple to emulate, gcc generates pretty compact code for it. I want to see how large/small an emulator is, and how much slowdown there is compared to native. I expect the emulator is a bit bigger than Woz's "SWEET16", but maybe not much, and it might not even be slower because MSP430 instructions each do quite a lot more than SWEET16 instructions (or typical stack-oriented VM instructions such as Java), which means the interpreter overhead gets spread over more useful stuff.

[1] my Digikey order history says otherwise and has "LAUNCHPAD MSP430G2553 EVAL BRD", but I've never used it and have moved house several times since and don't know which box it might be in.
 

Online MK14

  • Super Contributor
  • ***
  • Posts: 4808
  • Country: gb
Re: MSP430 PUSH.B
« Reply #5 on: July 13, 2022, 11:28:48 pm »
Does the write to @SP then modify only that 1 byte, leaving 1(SP) undisturbed?  This seems to follow from the description given. Or is the write done as a 16 bit write, zeroing the hi byte?

Apparently from the TI big manual:

Quote
4.6.2.35 PUSH
PUSH[.W] Save a word on the stack
PUSH.B Save a byte on the stack
Quote
The 20-bit SP SP is decremented by two. The operand is then copied to the RAM word
addressed by the SP. A pushed byte is stored in the low byte; the high byte is not
affected
.

From page 198 of 644.

https://courses.cs.washington.edu/courses/cse466/13au/pdfs/slau144j.pdf

BUT (from another source, please see below), apparently the issue with emulating it (for some things/parts), is.  What happens if you decide to use odd addresses, even though it wants even only addresses?
Because (reportedly), it is not clear, what the outcome would be.

EDIT:  Source for the possible emulation difficulties, here:
Quote
The processor's behaviour when a word is accessed at an odd location is poorly documented. In all current processors the lower bit is just silently ignored. The effect is, therefore, the same as specifying an address which is one less.

http://mspgcc.sourceforge.net/manual/x214.html
« Last Edit: July 13, 2022, 11:35:33 pm by MK14 »
 

Offline abquke

  • Regular Contributor
  • *
  • Posts: 128
  • Country: us
Re: MSP430 PUSH.B
« Reply #6 on: July 13, 2022, 11:46:53 pm »
(mspdebug) md 0x0260
    00260: fb 6d ef f3 ff ff fe ff 35 ff ec f1 ed d7 0e fd |.m......5.......|
    00270: fd db f3 ef 7d 7f 7f fe fb ff 9f fc 7f bf ed 7b |....}..........{|
    00280: 67 45 67 45 a4 00 04 82 02 03 34 60 20 01 12 12 |gEgE......4` ...|
    00290: 4c 70 21 53 40 80 60 09 00 02 e0 14 01 54 82 04 |Lp!S@.`......T..|
(mspdebug) step
    ( PC: 0f82c)  ( R4: 0197b)  ( R8: 0efb9)  (R12: 00000) 
    ( SP: 00282)  ( R5: 0fdba)  ( R9: 0ff7f)  (R13: 0022e) 
    ( SR: 00000)  ( R6: 076b7)  (R10: 0a7bf)  (R14: 00003) 
    ( R3: 00000)  ( R7: 07bbb)  (R11: 0fdf6)  (R15: 00000) 
0xf82c:
    0f82c: 75 40 12 00               MOV.B   #0x0012, R5
    0f830: 45 12                     PUSH    R5
    0f832: 04 43                     CLR     R4
    0f834: 33 40 8c 02               MOV     #0x028c, R3
    0f838: b2 40                     
    0f83a: 78 56                     ADD.B   @R6+,   R8
(mspdebug) md 0x0260
    00260: fb 6d ef f3 ff ff fe ff 35 ff ec f1 ed d7 0e fd |.m......5.......|
    00270: fd db f3 ef 7d 7f 7f fe fb ff 9f fc 7f bf ed 7b |....}..........{|
    00280: 67 45 67 45 a4 00 04 82 02 03 34 60 20 01 12 12 |gEgE......4` ...|
    00290: 4c 70 21 53 40 80 60 09 00 02 e0 14 01 54 82 04 |Lp!S@.`......T..|
(mspdebug) step
    ( PC: 0f830)  ( R4: 0197b)  ( R8: 0efb9)  (R12: 00000) 
    ( SP: 00282)  ( R5: 00012)  ( R9: 0ff7f)  (R13: 0022e) 
    ( SR: 00000)  ( R6: 076b7)  (R10: 0a7bf)  (R14: 00003) 
    ( R3: 00000)  ( R7: 07bbb)  (R11: 0fdf6)  (R15: 00000) 
0xf830:
    0f830: 45 12                     PUSH    R5
    0f832: 04 43                     CLR     R4
    0f834: 33 40 8c 02               MOV     #0x028c, R3
    0f838: b2 40 78 56 8c 02         MOV     #0x5678, &0x028c
    0f83e: a3 10                     SWPB    #0x0002
(mspdebug) step
    ( PC: 0f832)  ( R4: 0197b)  ( R8: 0efb9)  (R12: 00000) 
    ( SP: 00280)  ( R5: 00012)  ( R9: 0ff7f)  (R13: 0022e) 
    ( SR: 00000)  ( R6: 076b7)  (R10: 0a7bf)  (R14: 00003) 
    ( R3: 00000)  ( R7: 07bbb)  (R11: 0fdf6)  (R15: 00000) 
0xf832:
    0f832: 04 43                     CLR     R4
    0f834: 33 40 8c 02               MOV     #0x028c, R3
    0f838: b2 40 78 56 8c 02         MOV     #0x5678, &0x028c
    0f83e: a3 10                     SWPB    #0x0002
    0f840: ff ff                     
(mspdebug) md 0x0260
    00260: fb 6d ef f3 ff ff fe ff 35 ff ec f1 ed d7 0e fd |.m......5.......|
    00270: fd db f3 ef 7d 7f 7f fe fb ff 9f fc 7f bf ed 7b |....}..........{|
    00280: 12 45 67 45 a4 00 04 82 02 03 34 60 20 01 12 12 |.EgE......4` ...|
    00290: 4c 70 21 53 40 80 60 09 00 02 e0 14 01 54 82 04 |Lp!S@.`......T..|
 

Offline abquke

  • Regular Contributor
  • *
  • Posts: 128
  • Country: us
Re: MSP430 PUSH.B
« Reply #7 on: July 14, 2022, 12:00:37 am »
that push at 0xf830 was push.b in my assembly...

Working on R3 stuff. brucehoult was right in that it'll have to be hand assembled. naken_asm assembles "mov   R3,R4" as "clr r4".

"mov #028Ch,R3" assembled as-is, but R3 stayed 0 as it was stepped over:

(mspdebug)
    ( PC: 0f832)  ( R4: 00000)  ( R8: 0efb9)  (R12: 00000) 
    ( SP: 00280)  ( R5: 00012)  ( R9: 0ff7f)  (R13: 0022e) 
    ( SR: 00000)  ( R6: 076b7)  (R10: 0a7bf)  (R14: 00003) 
    ( R3: 00000)  ( R7: 07bbb)  (R11: 0fdf6)  (R15: 00000) 
0xf832:
    0f832: 04 43                     CLR     R4
    0f834: 33 40 8c 02               MOV     #0x028c, R3
    0f838: b2 40 78 56 8c 02         MOV     #0x5678, &0x028c
    0f83e: a3 10                     SWPB    #0x0002
    0f840: ff ff                     
(mspdebug)
    ( PC: 0f834)  ( R4: 00000)  ( R8: 0efb9)  (R12: 00000) 
    ( SP: 00280)  ( R5: 00012)  ( R9: 0ff7f)  (R13: 0022e) 
    ( SR: 00000)  ( R6: 076b7)  (R10: 0a7bf)  (R14: 00003) 
    ( R3: 00000)  ( R7: 07bbb)  (R11: 0fdf6)  (R15: 00000) 
0xf834:
    0f834: 33 40 8c 02               MOV     #0x028c, R3
    0f838: b2 40 78 56 8c 02         MOV     #0x5678, &0x028c
    0f83e: a3 10                     SWPB    #0x0002
    0f840: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
(mspdebug)
    ( PC: 0f836)  ( R4: 00000)  ( R8: 0efb9)  (R12: 00000) 
    ( SP: 00280)  ( R5: 00012)  ( R9: 0ff7f)  (R13: 0022e) 
    ( SR: 00000)  ( R6: 076b7)  (R10: 0a7bf)  (R14: 00003) 
    ( R3: 00000)  ( R7: 07bbb)  (R11: 0fdf6)  (R15: 00000) 
0xf836:
    0f836: 8c 02 b2 40               MOVA    #0x240b2, R12
    0f83a: 78 56                     ADD.B   @R6+,   R8
    0f83c: 8c 02 a3 10               MOVA    #0x210a3, R12
    0f840: ff ff ff ff               AND.B   @R15+,  0xffff(R15)
    0f844: ff ff                     
(mspdebug)

 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2329
  • Country: 00
Re: MSP430 PUSH.B
« Reply #8 on: July 14, 2022, 02:16:12 am »
Check this out

http://www.msp430emulator.com/

What they did?
 
The following users thanked this post: MK14


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf