cnop

[phx]

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...

[Wepl]

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.

[PeterK]

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.

[Vot]

Originally Posted by PeterK

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

[phx]

Originally Posted by Wepl

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.

Originally Posted by PeterK

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...

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...

[PeterK]

Originally Posted by Vot

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.

[Photon]

Originally Posted by phx

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.

[phx]

Originally Posted by Photon

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?

[Photon]

(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.

[matthey]

Originally Posted by Photon

(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.

Originally Posted by Photon

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.

Originally Posted by Photon

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" .

Originally Posted by Photon

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 .

Originally Posted by Photon

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.

[Leffmann]

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.

[matthey]

Originally Posted by Leffmann

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.

[Photon]

Originally Posted by matthey

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.

[mark_k]

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.