-2

The following assember instruction is given:

SUB[R1], 8[-R2]

The form this instruction is calculated:

op1 = op1 - op2

The first operand is addressed "register indirectly". The second one is addressed "register indexed" with pre-decrement ("n[-Rx]").

I have changed that to:

add #7, R2
sub [R1], [R2]
sub #8, R2

I try to explain why I got that:

8[-R2] is written also like this: R2-1+8= R2+7, so I added 7 to R2 at beginning.

Next line is clear.

Last line I remove 8 from R2 because is saying "pre-decrement".


I hope is all ok? I hope I described our personal way of writing good enough (I know there are other ways of writing, notation but we use this...)

This is no homework I only ask to understand it and I make this task for my own learn.

rpbudd
  • 77
  • 9
  • what instruction set is this? – old_timer Aug 24 '16 at 21:51
  • Which syntax also – Ryan B. Aug 24 '16 at 21:51
  • Sry I don't understand what mean? If mean what is #, means we use constant. Before each constant use we write #, so #Constant – rpbudd Aug 24 '16 at 21:53
  • And R2 mean register 2, – rpbudd Aug 24 '16 at 21:54
  • 1
    What kind of CPU is supposed to be able to execute the instructions you've shown? Assembly language isn't a single language, there hundreds of them, so if you can't tell us which assembly language you're using we can't help you. If it helps any, it looks like the assembly language you're using isn't for a real CPU, but an imaginary one used for teaching purposes. – Ross Ridge Aug 24 '16 at 22:32
  • 2
    Is there a question here? You seem to be creating your own assembly syntax for your own CPU. Only you can tell if this assembly matches your imaginary CPU's capabilities. – Chris Dodd Aug 24 '16 at 22:46

1 Answers1

2

I see a couple of problems in your definitions.

First of all, the instruction has [-R2], so the form this instruction is calculated would have to include that side effect:

op1 = op1 - op2
r2 = r2 - 1

The other problem from your instructions is that it does not define the size clearly. It looks like you assume it is a byte. You may want to look at the 68000 processor which has increment and decrement as well as well defined sizes (contrary to the Intel processor which has many implied sizes.)

For example, something as follow to save D1 on the stack, do some work, and the pop the value back out, the .L defines the size (LONG, 4 bytes):

MOV.L D1, -(SP)
...
MOV.L (SP)+, D1

In this case, the SP register will be decrement by 4 and then incremented back by 4 since the instruction is handling a long. In your case, we do not really know.

Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156
  • 1
    "implied sizes" the way you're talking about is a matter of assembly syntax design, not CPU design. If you're talking about the difference between `andi.l #$ffff,d0` and `and eax, 0xffff`, then note that the AT&T syntax (GNU `as`) version of that is `andl $0xffff, %eax` (where `l` specifies 32-bit operand-size). Of course, the existence of 16-bit mode with the same machine-code format as 32-bit mode does mean that in a machine-code / CPU-design sense there is plenty of implicit-size stuff going on in x86. – Peter Cordes Aug 25 '16 at 06:00
  • 1
    ARM addressing modes are interesting, and allow pre/post-increment/decrement by a value other than the element size, IIRC. (Also, all four combinations are allowed in ARM mode, IIRC. Only post-inc and pre-dec in thumb mode, at least with compact encoding.) e.g. `STR R2,[R4],#-16` does `R4-=16` after using R4 as the store-address. – Peter Cordes Aug 25 '16 at 06:04