Difference of immediate and normal instruction ?

PeterK · 18 January 2018, 14:47

What is the difference and dis/advantage of the immediate instructions like ADDI, CMPI, SUBI, ANDI, EORI, ORI in comparison to ADD, CMP, SUB, AND, EOR, OR with immediate arguments?

Are there any functional or timing differences?

For example: When and why should I use OR.L #$12345678,Dn or ORI.L #$12345678,Dn ?

demolition · 18 January 2018, 15:15

In short, OR/AND/etc gets converted to ORI/ANDI/etc by the assembler when it sees that you are using an immediate.

Thus a very pedantic compiler would complain if you typed 'OR.L #$12345678,<EA>' since there is no OR opcode that takes an immediate..

If you check the output opcodes you will see that the assembler will generate the same output no matter if you specify OR or ORI. It can be used to catch some errors on compile if you always specify ORI when you want the immediate version and then the assembler will complain if you forget to specify the # sign (I have spent too much time trying to find these kinds of bugs in my code).

chb · 18 January 2018, 15:16

If I remember correctly, there is no difference; some assemblers just allow you to use either syntax for convenience.

EDIT: What demolition said. There's no OR.L #$12345678,<EA> officially.

PeterK · 18 January 2018, 15:23

Sorry my example was wrong. The destination should be Dn.

a/b · 18 January 2018, 15:28

Generally speaking... They are 'different' instructions, they have different opcodes, but they do the same thing.
ORI allows a range of target addressing modes (ORI #immed,<ea>), while OR allows a range of source addressing modes (OR <ea>,Dx). So if you put the two together, you have a single overlap:
OR #immed,Dx ; <ea> is #immed
ORI #immed,Dx ; <ea> is Dx
Unless you need specific opcodes, it doesn't matter whether you write an extra "I" or not (I never do that and let the assembler sort it out).

PeterK · 18 January 2018, 15:43

Ok, thanks for your quick answers.

So, there is no functional or timing difference.

chb · 18 January 2018, 15:46

@a/b That's not correct, <ea> stands for <effective address> and can either be a register or a memory address. An immediate value is not an effective address and vice versa. EDIT: It seems it's coded in the instruction like an addressing mode, but is this official or an artifact?
So OR.L Dn,Dn is as correct as OR.L Dn,(A0)+ or OR.L (A0)+,$xxx.l, where in the latter case you supply an absolute address. ORI.L #$xxx.l,<ea> means or-ing the value $xxx to <ea>, while OR.L $xxx.l,<ea> means or-ing the value at address $xxx to <ea>. OR.L #$xxx, Dn has no opcode - needs to be ORI.L #$xxx,Dn. Both instructions have zero overlap.

EDIT: There's a number of things wrong in what I've written above, OR does not have memory-to-memory mode, only <ea>,Dn and Dn,<ea>.

PeterK · 18 January 2018, 16:07

Quote:

Originally Posted by chb

@a/b That's not correct, <ea> stands for <effective address> and can either be a register or a memory address. An immediate value is not an effective address and vice versa.

Yes, <ea> is an effective address. But immediate is also a possible <ea> with the address of the constant in the code.

Quote:

OR.L #$xxx, Dn has no opcode

No, it should have an opcode.

a/b · 18 January 2018, 16:12

As I said, generally speaking. I didn't check every opcode, etc.
Yes, the example for OR/ORI turns out to be bad, it's exactly as you stated. But that's not the case for every instruction PeterK listed. For example, ADD/ADDI:

Code:

  moveq #0,d0
  add.w #$1234,d0 ; $d07c, $1234
  addi.w #$1234,d0 ; $0640, $1234
  rts

d0=$2468

Some instructions are more flexible, some are not. In any case, most assemblers are smart enough to figure it out, and you can ommit "I" in every case (even when the target is CCR/SR or similar).

meynaf · 18 January 2018, 16:22

These forms have two different opcodes, but same effect and same timing.
All immediate are affected except EOR (because there's no eor from mem).

This is what we may call an alias, and is the result of the (imo) not very clever decision of keeping the immediate in the <ea>. Yeah, even 68k has its quirks.

PeterK · 18 January 2018, 16:31

Thanks meynaf, I've overseen that there is no EOR #immediate,Dn.

@a/b
What did you want to show me in your ADD example?

a/b · 18 January 2018, 16:39

It was a reply to chb, regarding the bad example with OR/ORI, which were mentioned in the last few posts beforehand, so I blindly used them in my example, and apparently that wasn't a good idea. Should've used ADD/ADDI right from the start.

PeterK · 18 January 2018, 17:20

Well, I think there was nothing wrong in your post #5.

chb · 18 January 2018, 18:20

meynaf + a/b: I was wrong on a couple of things in my post #7, I've corrected it, thanks for clarification! But are the aliases like "add.w #$1234,d0" official opcodes? Are they documented, apart from the fact that they can be constructed from the instruction encoding? I've never seen a mention in a manual.

meynaf · 18 January 2018, 18:32

If some addressing mode is allowed then it is necessarily considered official because 68k has zero undocumented opcode.

phx · 18 January 2018, 23:56

Also note that some assemblers have their own preference which opcode to use, when you write for example ADDI #x,Dn or ADD #x,Dn. Some will always convert to ADDI, some to ADD and some will do exactly what you wrote.

demolition · 19 January 2018, 08:10

Quote:

Originally Posted by phx

Also note that some assemblers have their own preference which opcode to use, when you write for example ADDI #x,Dn or ADD #x,Dn. Some will always convert to ADDI, some to ADD and some will do exactly what you wrote.

How about disassemblers - can you trust that if it writes ADDI, that is was not really an ADD opcode with an immediate?

meynaf · 19 January 2018, 09:01

Quote:

Originally Posted by demolition

How about disassemblers - can you trust that if it writes ADDI, that is was not really an ADD opcode with an immediate?

Having written my own disassembler years ago, I know that it would be more complicated to identify the ADD with immediate and append "I" than just output ADD/ADDI depending on the opcode.
So unless its author wanted to play smart ass, you can trust a disasm.

Old_Bob · 19 January 2018, 20:01

Quote:

Originally Posted by phx

Also note that some assemblers have their own preference which opcode to use, when you write for example ADDI #x,Dn or ADD #x,Dn. Some will always convert to ADDI, some to ADD and some will do exactly what you wrote.

I guess this is why I see MOVE.L when I'm in the WinUAE debugger, even though my source has MOVEQ. Why would an assembler even have a preference? It surely can't be optimization, at least in this example?

B

18 January 2018, 14:47	#1
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Difference of immediate and normal instruction ? What is the difference and dis/advantage of the immediate instructions like ADDI, CMPI, SUBI, ANDI, EORI, ORI in comparison to ADD, CMP, SUB, AND, EOR, OR with immediate arguments? Are there any functional or timing differences? For example: When and why should I use OR.L #$12345678,Dn or ORI.L #$12345678,Dn ? Last edited by PeterK; 18 January 2018 at 15:24.

18 January 2018, 16:12	#9
a/b Registered User Join Date: Jun 2016 Location: europe Posts: 1,039	As I said, generally speaking. I didn't check every opcode, etc. Yes, the example for OR/ORI turns out to be bad, it's exactly as you stated. But that's not the case for every instruction PeterK listed. For example, ADD/ADDI: Code: moveq #0,d0 add.w #$1234,d0 ; $d07c, $1234 addi.w #$1234,d0 ; $0640, $1234 rts d0=$2468 Some instructions are more flexible, some are not. In any case, most assemblers are smart enough to figure it out, and you can ommit "I" in every case (even when the target is CCR/SR or similar). Last edited by a/b; 18 January 2018 at 16:15. Reason: bad tags

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Exolon Instruction Manual	ransom1122	request.Other	6	18 May 2019 23:32
Difference WHDLoad-Games "normal" & "fast"	pellewolf	project.WHDLoad	3	25 July 2017 15:38
Please help me: one by one instruction needed	JewStrangler	support.WinUAE	15	20 September 2010 18:55
Is this normal	adewakd	support.Other	1	15 March 2008 01:31
$48e70000 instruction	Asman	Coders. General	5	10 February 2006 23:00

18 January 2018, 15:15	#2
demolition Unregistered User Join Date: Sep 2012 Location: Copenhagen / DK Age: 43 Posts: 4,190	In short, OR/AND/etc gets converted to ORI/ANDI/etc by the assembler when it sees that you are using an immediate. Thus a very pedantic compiler would complain if you typed 'OR.L #$12345678,<EA>' since there is no OR opcode that takes an immediate.. If you check the output opcodes you will see that the assembler will generate the same output no matter if you specify OR or ORI. It can be used to catch some errors on compile if you always specify ORI when you want the immediate version and then the assembler will complain if you forget to specify the # sign (I have spent too much time trying to find these kinds of bugs in my code).

18 January 2018, 15:16	#3
chb Registered User Join Date: Dec 2014 Location: germany Posts: 439	If I remember correctly, there is no difference; some assemblers just allow you to use either syntax for convenience. EDIT: What demolition said. There's no OR.L #$12345678,<EA> officially.

18 January 2018, 15:23	#4
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Sorry my example was wrong. The destination should be Dn.

18 January 2018, 15:28	#5
a/b Registered User Join Date: Jun 2016 Location: europe Posts: 1,039	Generally speaking... They are 'different' instructions, they have different opcodes, but they do the same thing. ORI allows a range of target addressing modes (ORI #immed,<ea>), while OR allows a range of source addressing modes (OR <ea>,Dx). So if you put the two together, you have a single overlap: OR #immed,Dx ; <ea> is #immed ORI #immed,Dx ; <ea> is Dx Unless you need specific opcodes, it doesn't matter whether you write an extra "I" or not (I never do that and let the assembler sort it out).

18 January 2018, 15:43	#6
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Ok, thanks for your quick answers. So, there is no functional or timing difference.

18 January 2018, 15:46	#7
chb Registered User Join Date: Dec 2014 Location: germany Posts: 439	@a/b That's not correct, <ea> stands for <effective address> and can either be a register or a memory address. An immediate value is not an effective address and vice versa. EDIT: It seems it's coded in the instruction like an addressing mode, but is this official or an artifact? So OR.L Dn,Dn is as correct as OR.L Dn,(A0)+ or OR.L (A0)+,$xxx.l, where in the latter case you supply an absolute address. ORI.L #$xxx.l,<ea> means or-ing the value $xxx to <ea>, while OR.L $xxx.l,<ea> means or-ing the value at address $xxx to <ea>. OR.L #$xxx, Dn has no opcode - needs to be ORI.L #$xxx,Dn. Both instructions have zero overlap. EDIT: There's a number of things wrong in what I've written above, OR does not have memory-to-memory mode, only <ea>,Dn and Dn,<ea>. Last edited by chb; 18 January 2018 at 18:01.

18 January 2018, 16:22	#10
meynaf son of 68k Join Date: Nov 2007 Location: Lyon / France Age: 51 Posts: 5,323	These forms have two different opcodes, but same effect and same timing. All immediate are affected except EOR (because there's no eor from mem). This is what we may call an alias, and is the result of the (imo) not very clever decision of keeping the immediate in the <ea>. Yeah, even 68k has its quirks.

18 January 2018, 16:31	#11
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Thanks meynaf, I've overseen that there is no EOR #immediate,Dn. @a/b What did you want to show me in your ADD example?

18 January 2018, 16:39	#12
a/b Registered User Join Date: Jun 2016 Location: europe Posts: 1,039	It was a reply to chb, regarding the bad example with OR/ORI, which were mentioned in the last few posts beforehand, so I blindly used them in my example, and apparently that wasn't a good idea. Should've used ADD/ADDI right from the start.

18 January 2018, 17:20	#13
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Well, I think there was nothing wrong in your post #5.

18 January 2018, 18:20	#14
chb Registered User Join Date: Dec 2014 Location: germany Posts: 439	meynaf + a/b: I was wrong on a couple of things in my post #7, I've corrected it, thanks for clarification! But are the aliases like "add.w #$1234,d0" official opcodes? Are they documented, apart from the fact that they can be constructed from the instruction encoding? I've never seen a mention in a manual.

18 January 2018, 18:32	#15
meynaf son of 68k Join Date: Nov 2007 Location: Lyon / France Age: 51 Posts: 5,323	If some addressing mode is allowed then it is necessarily considered official because 68k has zero undocumented opcode.

18 January 2018, 23:56	#16
phx Natteravn Join Date: Nov 2009 Location: Herford / Germany Posts: 2,496	Also note that some assemblers have their own preference which opcode to use, when you write for example ADDI #x,Dn or ADD #x,Dn. Some will always convert to ADDI, some to ADD and some will do exactly what you wrote.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)