English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 02 February 2013, 20:19   #1
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 211
Assembler that generates all M68k opcodes

Hello, for curiosity and for the sake of explanation of the relationship between assembly language and machine code, I would like to know if there are Amiga assemblers that allow to generate all m68k opcodes.

It seems to me that ASM-One (at least v 1.4x) does not generate some of them, for instance ADD #im, Dx (ASM-One "optimize" it with ADDI #im, Dx).

What about PhxAss, Devpac, vasm?
TheDarkCoder is offline  
Old 02 February 2013, 22:29   #2
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,499
Quote:
Originally Posted by TheDarkCoder View Post
It seems to me that ASM-One (at least v 1.4x) does not generate some of them, for instance ADD #im, Dx (ASM-One "optimize" it with ADDI #im, Dx).
It's the other way 'round, ASM-One allows you to write the less strict add #im,x instruction (which does not exist) and automatically translates it to the correct addi instruction. It is not any kind of optimisation, it actually is just support for lazy coders!
StingRay is offline  
Old 03 February 2013, 13:51   #3
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,265
Quote:
Originally Posted by TheDarkCoder View Post
Hello, for curiosity and for the sake of explanation of the relationship between assembly language and machine code, I would like to know if there are Amiga assemblers that allow to generate all m68k opcodes.

It seems to me that ASM-One (at least v 1.4x) does not generate some of them, for instance ADD #im, Dx (ASM-One "optimize" it with ADDI #im, Dx).

What about PhxAss, Devpac, vasm?
I don't know if vasm honors all instructions like this, but it does encode both ADD #Im,Dx and ADDI #Im,Dx correctly, so it's worth taking a look.
Leffmann is offline  
Old 03 February 2013, 14:32   #4
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,499
Quote:
Originally Posted by Leffmann View Post
but it does encode both ADD #Im,Dx and ADDI #Im,Dx correctly
ADD #IM,DX = ADDI #IM,DX

Strictly speaking, ADD #IM,DX is not a valid instruction (i.e. does not exist) but most assemblers handle it automatically since it is clear that an immediate value should be added.
StingRay is offline  
Old 03 February 2013, 17:51   #5
thor
Registered User
thor's Avatar
 
Join Date: Mar 2006
Location: Germany
Posts: 898
Quote:
Originally Posted by StingRay View Post
Strictly speaking, ADD #IM,DX is not a valid instruction (i.e. does not exist) but most assemblers handle it automatically since it is clear that an immediate value should be added.
ADD.W #$1234,D0 -> D07C 1234
ADDI.W #$1234,D0 -> 0640 1234

If destination is a data register then there is ADD #IM,Dx AFAIK
thor is offline  
Old 03 February 2013, 19:12   #6
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,499
You are correct, add.x #IM,Dx is indeed allowed, I checked the reference manual. It's somewhat ambiguous though IMHO.
StingRay is offline  
Old 05 February 2013, 10:08   #7
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 211
Quote:
Originally Posted by StingRay View Post
You are correct, add.x #IM,Dx is indeed allowed, I checked the reference manual. It's somewhat ambiguous though IMHO.
yeah, before digging into this issue (just for the sake of explaining ASM, not becose I needed) I also believed that the very dense m68k instruction encoding did not have redundand opcodes.
Indeed, the only redundancies I have discovered up to now, are all related to the xxxI variants using a data register as destination operand:
ADD # , Dx / ADDI # , Dx
SUB # , Dx / SUBI # , Dx
CMP # , Dx / CMPI # , Dx.
AND# , Dx / ANDI # , Dx.
OR # , Dx / ORI # , Dx.

In contrast, there are no redundancied between ADD/ADDA, SUB/SUBA, etc.

Well, another one is that you can use MOVEM to copy just 1 register, but I regard this as anavoidable.

Please, let me know if you know others.
TheDarkCoder is offline  
Old 05 February 2013, 10:10   #8
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 211
Quote:
Originally Posted by Leffmann View Post
I don't know if vasm honors all instructions like this, but it does encode both ADD #Im,Dx and ADDI #Im,Dx correctly, so it's worth taking a look.
Let's see if Frank Wille is willing to give a qualified answer!
TheDarkCoder is offline  
Old 05 February 2013, 16:14   #9
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,689
Quote:
Originally Posted by Leffmann View Post
I don't know if vasm honors all instructions like this, but it does encode both ADD #Im,Dx and ADDI #Im,Dx correctly, so it's worth taking a look.
I can only guarantee that I tried my best to support all of them. When I missed something, tell me, and I fix it in a few minutes. It was important to me to differentiate between ADD and ADDI, because I wanted to make sure vasm works well with reassemblers and generates identical code.

Vasm's 68k backend supports all known 68000-68060, 68851, 6888x, CPU32 and ColdFire V2-V4e instructions.

I remember just one ambiguous instruction: PFLUSHA. It exists for 68030, 68851, 68040 and 68060. The 68040/060 version has a different opcode, so the resulting code depends on the current cpu options.
phx is offline  
Old 05 February 2013, 18:31   #10
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by TheDarkCoder View Post
In contrast, there are no redundancies between ADD/ADDA, SUB/SUBA, etc. Well, another one is that you can use MOVEM to copy just 1 register, but I regard this as unavoidable. Please, let me know if you know others.
Another "redundancy" is ASL and LSL. It would have been easy enough to have the assembler use an alias for ASL that encodes an LSL.
Quote:
Originally Posted by phx View Post
I can only guarantee that I tried my best to support all of them. When I missed something, tell me, and I fix it in a few minutes. It was important to me to differentiate between ADD and ADDI, because I wanted to make sure vasm works well with reassemblers and generates identical code.
Vasm works great for reassembling code and I wouldn't change a thing. However, the M68000PRM has a note after the ADD instruction that says:
Quote:
ADDA is used when the destination is an address register. ADDI and ADDQ are used when the source is immediate data. Most assemblers automatically make this distinction.
It doesn't say that assemblers "should" make the distinction so I guess vasm is ok . It does sound like Motorola intended assemblers to convert ADD #,Dn to ADDI #,Dn though. ADD #,Dn is supported by all 68k processors and was generated by some 68k assemblers so it can't be removed now. I think it's safe enough to use it in vasm with the advantage of more accurate reassembled code.
Quote:
Originally Posted by phx View Post
I remember just one ambiguous instruction: PFLUSHA. It exists for 68030, 68851, 68040 and 68060. The 68040/060 version has a different opcode, so the resulting code depends on the current cpu options.
I hadn't noticed. Good to know.
matthey is offline  
Old 06 February 2013, 09:02   #11
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 211
Quote:
Originally Posted by matthey View Post
Another "redundancy" is ASL and LSL. It would have been easy enough to have the assembler use an alias for ASL that encodes an LSL.
As you probably know, (but let's state it for the beginners ) ASL and LSL are different in the way they affect the V flag.
I agree that it's almost useless to have both, but what I mean with the term "redundant" instruction is two different opcodes that have exactly the same semantics, for whatever values of the operands.

I agree on your comment


Quote:
Originally Posted by phx View Post
I can only guarantee that I tried my best to support all of them. When I missed something, tell me, and I fix it in a few minutes. It was important to me to differentiate between ADD and ADDI, because I wanted to make sure vasm works well with reassemblers and generates identical code.

Vasm's 68k backend supports all known 68000-68060, 68851, 6888x, CPU32 and ColdFire V2-V4e instructions.

I remember just one ambiguous instruction: PFLUSHA. It exists for 68030, 68851, 68040 and 68060. The 68040/060 version has a different opcode, so the resulting code depends on the current cpu options.
thanks phx, that's what I wanted to know, I really like the choice of supporting all instructions.
Has PhxAss the same behavior, if you remember?

Last edited by prowler; 06 February 2013 at 21:28. Reason: Back-to-back posts merged.
TheDarkCoder is offline  
Old 06 February 2013, 09:46   #12
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,689
Quote:
Originally Posted by TheDarkCoder View Post
I really like the choice of supporting all instructions.
BTW, although vasm differentiates between ADD and ADDI it will still translate ADD silently into ADDI, but only then when the addressing mode doesn't exist for ADD.

Quote:
Originally Posted by TheDarkCoder View Post
Has PhxAss the same behavior, if you remember?
It's a long time ago. But from looking at the source it seems so.
It was probably also required because of reassembling. I worked closely together with Tim Rühsen in the mid-90s, who based his IRA reassembler on PhxAss.

Last edited by prowler; 06 February 2013 at 21:29. Reason: Fixed quotes.
phx is offline  
Old 07 February 2013, 10:37   #13
TheDarkCoder
Registered User
 
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 211
Quote:
Originally Posted by phx View Post
BTW, although vasm differentiates between ADD and ADDI it will still translate ADD silently into ADDI, but only then when the addressing mode doesn't exist for ADD.
ok, that's fine.
Thanks again for the info!
TheDarkCoder is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Csound 3.481 on m68k squidbass Amiga scene 5 21 July 2013 21:29
Rewriting m68k code RobSis Coders. Tutorials 1 26 January 2013 16:15
m68k-amigaos-ld.exe bug ? FrenchShark Coders. General 2 30 November 2009 09:54
#M68k @ Amigaworld.net Iznougoud Amiga scene 0 06 October 2007 16:35
Carrier Command: fuel opcodes..? Thrash911 support.Games 38 28 May 2007 01:45

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 03:30.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.07923 seconds with 13 queries