English Amiga Board


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

 
 
Thread Tools
Old 07 December 2014, 00:11   #1
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,199
cnop

I'm wondering if I should change the way how the CNOP directive currently works in vasm. Its name implies that a NOP instruction might be used for padding, but the most important Amiga assemblers, like Devpac, AsmOne and even PhxAss and vasm always pad with zero-bytes. I remember only A68k and the SNMA assembler which used NOP ($4e71). The latter even has a CNUL directive to pad with zeros.

Does anybody think it makes sense to use NOP instead of zeros? Only for code sections, of course...
phx is offline  
Old 07 December 2014, 00:43   #2
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 675
basm also uses NOPs but in my practice I never needed CNOP producing NOPs. it anyway is only possible if the skip is a multiple of words and the addresses are even.
Wepl is offline  
Old 07 December 2014, 00:45   #3
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,376
PhxAss can use both, NOP = $4e71 or zeros, AFAIK. But you should know better
(It's the PhxAss option Z = zeropadding)

Usually I've configured PhxAssGUI to use zeros for all my projects, but in case you want to align something, like a loop for example, in the middle of a code sequence then you need a real NOP to do that. You can only align with zeros after a gap in the code (after a BRA or a RTS).

Edited: The zeros are like heroes, but their spelling is different.

Last edited by PeterK; 09 December 2014 at 00:44.
PeterK is offline  
Old 07 December 2014, 02:51   #4
Vot
Registered User

 
Join Date: Aug 2012
Location: Australia
Posts: 648
Quote:
Originally Posted by PeterK View Post
PhxAss can use both, NOP = $4e71 or zeroes, AFAIK. But you should know better

(It's the PhyAss option Z = zeropadding)



Usually I've configured PhxAssGUI to use zeroes for all my projects, but in case you want to align something, like a loop for example, in the middle of a code sequence then you need a real NOP to do that. You can only align with zeroes after a gap in the code (after a BRA or a RTS).

Bloody hell after reading a few of your threads on optimisations etc do you fellas sleep with your 68k Programmer's Reference Manual under your pillows
Vot is offline  
Old 07 December 2014, 21:24   #5
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,199
Quote:
Originally Posted by Wepl View Post
it anyway is only possible if the skip is a multiple of words and the addresses are even.
Sure. Odd bytes would still be filled with zeros.


Quote:
Originally Posted by PeterK View Post
PhxAss can use both, NOP = $4e71 or zeroes, AFAIK. But you should know better
Arrrgh! No... I completely forgot. It's more than 20 years...

Quote:
but in case you want to align something, like a loop for example, in the middle of a code sequence then you need a real NOP to do that.
Indeed. Rarely used, but a good example.

I think it doesn't hurt any existing code to implement it...
phx is offline  
Old 09 December 2014, 00:43   #6
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,376
Quote:
Originally Posted by Vot View Post
Bloody hell after reading a few of your threads on optimisations etc do you fellas sleep with your 68k Programmer's Reference Manual under your pillows
No, just enable some optimization options in PhxAss and it will do most parts of this job by using the best possible instructions. The coders, of course, still have to find the optimal programming strategy, which is not explained in any manual.
PeterK is offline  
Old 06 February 2015, 23:38   #7
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,589
Quote:
Originally Posted by phx View Post
I'm wondering if I should change the way how the CNOP directive currently works in vasm. Its name implies that a NOP instruction might be used for padding, but the most important Amiga assemblers, like Devpac, AsmOne and even PhxAss and vasm always pad with zero-bytes. I remember only A68k and the SNMA assembler which used NOP ($4e71). The latter even has a CNUL directive to pad with zeros.

Does anybody think it makes sense to use NOP instead of zeros? Only for code sections, of course...
Absolutely not. CNOP simply allows you to align the next address to byte precision. First number is offset, second is "address AND value". CNOP 0,8 aligns to an address evenly divisible by 8, CNOP 0,2=EVEN, CNOP 1,2=ODD. I agree the directive is not very logically named - I would add an ALIGN alias for CNOP.
Photon is offline  
Old 09 February 2015, 10:50   #8
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,199
Quote:
Originally Posted by Photon View Post
Absolutely not.
Hmm... now it's too late, as I already implemented padding with NOP instructions in a code section. But why do you think so?

Did I miss any important arguments against it, besides compatibility with Devpac and AsmOne?
phx is offline  
Old 15 February 2015, 05:48   #9
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,589
(copy/paste CNOP is just a way of aligning data, a replacement for modifying "*" (program counter) as allowed by older assemblers. In a BSS section, it should become a DS and in code or data sections, it should become a DC of the appropriate size. Or the assembler should just skip a few bytes in memory in all cases, it should not matter to the developer.

It's a silly directive name, anyway. There's no real condition and certainly no CPU NOP instruction involved anywhere.

There are no arguments that I can see for adding support for insertion of NOP statements in code sections when a CNOP is encountered. What would CNOP 1,2 do except cause code corruption? And if you pad a piece of code with n NOP instructions, what's the use case? Without an RTS, you would only make a very slow replacement for a jump table that executes every single branch point in the table if you happen to jump to the first entry.

Convince me. But I think there's just some confusion as to what the directive is supposed to do here. Caused by the silly name in the first place.
Photon is offline  
Old 15 February 2015, 08:16   #10
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Photon View Post
(copy/paste CNOP is just a way of aligning data, a replacement for modifying "*" (program counter) as allowed by older assemblers. In a BSS section, it should become a DS and in code or data sections, it should become a DC of the appropriate size. Or the assembler should just skip a few bytes in memory in all cases, it should not matter to the developer.
A DC needs a Declared Constant value. Do you want it to be 0, NOP or some other value?

This is different than skipping over unitialized data in a code or data hunk which wouldn't be any better if it was possible.

Quote:
Originally Posted by Photon View Post
It's a silly directive name, anyway. There's no real condition and certainly no CPU NOP instruction involved anywhere.
There are NOP instructions in code sections of some old (and not so old) code and assemblers which support it. That means some programmers have probably used CNOP to insert NOPs in their code since some assemblers insert NOP with a CNOP (thus the name). It may not be popular on the Amiga and it certainly isn't a good idea on a 68k CPU except the 68000 but we may not remember code and assemblers from 30+ years ago. My opinion is that CNOP padding with NOP in a code section is the safest and most compatible choice.

Quote:
Originally Posted by Photon View Post
There are no arguments that I can see for adding support for insertion of NOP statements in code sections when a CNOP is encountered.
I have an argument above. I don't know if it's any good but it is more than "no arguments" .

Quote:
Originally Posted by Photon View Post
What would CNOP 1,2 do except cause code corruption?
The Devpac manual which vasm sort of used to follow doesn't give the padding used or tell what would be done in this case. My good old Cape 68k with it's excellent manual covers it though:

"CNOP - Places a series of 2-byte NOP instructions, with any odd filler byte set to 0 in the object file to reach the desired alignment."

It would crash but the manual is clear .

Quote:
Originally Posted by Photon View Post
And if you pad a piece of code with n NOP instructions, what's the use case? Without an RTS, you would only make a very slow replacement for a jump table that executes every single branch point in the table if you happen to jump to the first entry.
It's not about use or abuse, which has and will happen, but about compatibility and predictability. Generating NOP in code sections is the most compatible padding for CNOP.
matthey is offline  
Old 15 February 2015, 15:58   #11
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,183
I agree with matthey. I can't think of any sensible reasons at all for padding with zeroes or random data, whereas padding with NOPs is actually useful and backwards compatible.

The name of the directive clearly suggests what it does, and with A68K and CAPE doing exactly this, and being some of the earliest available assemblers for Amiga, I would consider these to be predicates for how to implement the CNOP directive.

But I would actually insert something like
move.l A7, A7
, which is a true no-op, whereas a NOP can actually incur long unexpected delays. The point of CNOP after all isn't to insert NOPs or some other specific values, but to allow convenient aligning of both code and data.
Leffmann is offline  
Old 15 February 2015, 18:13   #12
matthey
Banned
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
Quote:
Originally Posted by Leffmann View Post
But I would actually insert something like
move.l A7, A7
, which is a true no-op, whereas a NOP can actually incur long unexpected delays. The point of CNOP after all isn't to insert NOPs or some other specific values, but to allow convenient aligning of both code and data.
I am no less a fan of placing NOP instructions in code than you since the 68020+ does a pipeline synchronization (flushes the pipeline) which can take many cycles. However, some code may need this "expected" delay. An example is registers which can't be read at the speed of the CPU so the programmer places a NOP between instructions as delays. This is not uncommon on the Sega Genesis but it is also possible in drivers of old Amiga boards with slow hardware. It would be more flexible if the 16 bit padding of CNOP could be defined either globally or as a 3rd argument to CNOP but that is a little trickier where vasm is using NOP padding in code and 0 padding in DATA and BSS. The way vasm does it now probably gives the best compatibility with various Amiga assemblers without being more configurable. I believe vasm supports other align directives which do allow to select the padding already and maybe Frank doesn't want more bloat from duplicate functionality.
matthey is offline  
Old 17 February 2015, 22:53   #13
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,589
Quote:
Originally Posted by matthey View Post
A DC needs a Declared Constant value. Do you want it to be 0, NOP or some other value?

This is different than skipping over unitialized data in a code or data hunk which wouldn't be any better if it was possible.



There are NOP instructions in code sections of some old (and not so old) code and assemblers which support it. That means some programmers have probably used CNOP to insert NOPs in their code since some assemblers insert NOP with a CNOP (thus the name). It may not be popular on the Amiga and it certainly isn't a good idea on a 68k CPU except the 68000 but we may not remember code and assemblers from 30+ years ago. My opinion is that CNOP padding with NOP in a code section is the safest and most compatible choice.



I have an argument above. I don't know if it's any good but it is more than "no arguments" .



The Devpac manual which vasm sort of used to follow doesn't give the padding used or tell what would be done in this case. My good old Cape 68k with it's excellent manual covers it though:

"CNOP - Places a series of 2-byte NOP instructions, with any odd filler byte set to 0 in the object file to reach the desired alignment."

It would crash but the manual is clear .



It's not about use or abuse, which has and will happen, but about compatibility and predictability. Generating NOP in code sections is the most compatible padding for CNOP.
For an align directive to be useful, in a BSS section, padding bytes should work just like DS, and in a code/data section, it should work just like DC, fill value 0. There's really no other directive to use for controlled alignment, repeated EVENs or ODDs doesn't help.

Anyway, it should be a quick job to test out how the assemblers you want to be compatible with do it.
Photon is offline  
Old 19 February 2015, 22:33   #14
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,962
I think CNOP should with zeros, not NOPs. The reason being, the official/canonical Amiga Macro Assembler by Metacomco works that way.

That's not to say that the ability to pad with some other value isn't useful, but the default behaviour should IMHO match the Metacomco assembler. Also, in cases where CNOP adds only a single padding byte, half a NOP opcode doesn't make much sense.

An assembler could have a directive to either change which word CNOP uses for padding, or implement another directive to pad with NOPs or anything else.
mark_k is offline  
 


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

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 00:37.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.07922 seconds with 12 queries