NOP vs WAIT as pipeline fillers

mindrobots · 2014-03-14 13:02

Typically, NOP is used as a pipeline filler if you have nothing productive you can do in that time.

Can a NOPX with appropriate D value be used as a pipeline filler?

Like after a REPD for example, instead of this:

      REPD     D, #1
      NOP
      NOP
      NOP
      NOTP     #0

would this work?

     REPD    D,#1
     NOPX    #3
     NOTP    #0

or does it need a physical memory fetch to satisfy the pipeline?

Could end up saving precious COGRAM if it works.

This may not matter because I can't find NOPX (or WAITX) in the latest opcode lists but then NOP isn't in there either. Has NOPX changed to WAIT now?

Anyway, if the instruction still exists would it work to take up the pipeline time without taking up space?

EDIT: NOPX has become WAIT.

Sapieha · 2014-03-14 13:11

Hi mindrobots.

Test with WAIT #xxx It is same as You describe NOPX #3

mindrobots wrote: »
Typically, NOP is used as a pipeline filler if you have nothing productive you can do in that time.

Can a NOPX with appropriate D value be used as a pipeline filler?

Like after a REPD for example, instead of this:
      REPD     D, #1
      NOP
      NOP
      NOP
      NOTP     #0
would this work?
     REPD    D,#1
     NOPX    #3
     NOTP    #0
or does it need a physical memory fetch to satisfy the pipeline?

Could end up saving precious COGRAM if it works.

This may not matter because I can't find NOPX (or WAITX) in the latest opcode lists but then NOP isn't in there either. Has NOPX changed to WAIT now?

Anyway, if the instruction still exists would it work to take up the pipeline time without taking up space?

cgracey · 2014-03-14 13:42

REPD actually needs three instructions to pass through the pipeline. WAIT D/# (was NOPX) just stalls the pipeline for some number of clocks.

jmg · 2014-03-14 13:58

cgracey wrote: »

REPD actually needs three instructions to pass through the pipeline. WAIT D/# (was NOPX) just stalls the pipeline for some number of clocks.

This is why I think REPD etc need an Assembler fix, so the mnemonic takes two addresses and a count.
(binary opcode is unchanged)

Analog Devices manage their REP opcode this way.

mindrobots · 2014-03-14 14:05

cgracey wrote: »

REPD actually needs three instructions to pass through the pipeline. WAIT D/# (was NOPX) just stalls the pipeline for some number of clocks.

Cool, that's the answer I was looking for! Thanks!

Bill Henning · 2014-03-14 14:38

Do you mean:

1) It uses the two addresses to auto-generate NOP's

2) Change the opcode to take two addresses, and somehow encode them in the bit pattern

If (1)

then I disagree, as that is three wasted longs - people should Read The Fine Manual.

If (2)

then we have a problem, there are not enough bits in the instruction, and how would the cog skip N ahead?

jmg wrote: »

This is why I think REPD etc need an Assembler fix, so the mnemonic takes two addresses and a count.
(binary opcode is unchanged)

Analog Devices manage their REP opcode this way.

Roy Eltham · 2014-03-14 15:04

Bill,
I think he just means in the assembler/compile. You give it two labels and a count, and if there aren't enough gap instructions it can insert NOPs or give you an error on compile. When compiled it will just use the instruction as it currently is...
We can make the tools be helpful in getting users to the correct results.

jmg · 2014-03-14 17:49

Roy Eltham wrote: »

Bill,
I think he just means in the assembler/compile. You give it two labels and a count, and if there aren't enough gap instructions it can insert NOPs or give you an error on compile. When compiled it will just use the instruction as it currently is...
We can make the tools be helpful in getting users to the correct results.

100% correct.

No change at all to the binary opcode, just some small checking code in the Assembler, and the source makes it clear where the LOOP is that the user intended, and is 'edit safe'.

Miss, or change, those three gap instructions, and the assembler generates an error.

I'm also fine with allowing an Assembler to Auto-fill if needed, as an option.
It can show what it did in the LST file, and that is 100% compatible with anyone who wants to do all their own gap-packing,

potatohead · 2014-03-14 22:59

Personally, I like it how it is. I won't be leaving nops in there most of the time. It's kind of great to get it written populate nops, debug, etc... Then on an optimization pass, back fill those nops with useful operations.

This was done all the time on P1 for the hub window accesses, and it's just not that big of a deal.

Dave Hein · 2014-03-15 06:24

jmg wrote: »

No change at all to the binary opcode, just some small checking code in the Assembler, and the source makes it clear where the LOOP is that the user intended, and is 'edit safe'.

Miss, or change, those three gap instructions, and the assembler generates an error.

Even with a count how would the assembler know which instructions are intended to be part of the loop? It would require a "loop-start" label to know if I had the proper number of instructions before the loop. Can you show an example of what you're proposing?

EDIT: OK, so Roy is saying that two labels and a count are specified. I think that would be OK, but I would still like to used the REPD instruction as is, just like instructions using ## could be defined explicitly as 2 instructions. So I suggest keeping REPD as it as, and create another instruction name that generates a REPD and checks labels.

Bill Henning · 2014-03-15 07:34

If there must be optional syntactic sugar, it should be really simple. I suspect someone would have already suggested something as follows:

         REPx #loops    ' where x = 'S' or 'D'
         ' spacer/spacers go here
         LOOP 
              ' instructions go here
         ENDL

This way, only the repeat count is specified (constant or register)

The assembler can figure out how many spacers are needed, if not enough, can add nops + issue warning, if too many, can issue error, and can count number of instructions between LOOP and ENDL

Roy Eltham · 2014-03-15 10:20

When I said count there, I mean the count of how many loops to make, just to be clear.

The reason I said to have the RESx line to specify the labels is that it's easier to compile that. The labels also need to be unique per RESx, either via different names or preceding with : (to make them local). When the compiler is doing PASM stuff, it doesn't really handle dependencies on other lines in the source for compiling a given line (other than symbols identified in the first pass, or specially named ones like _RET labels).

Not saying it couldn't be changed to handle this stuff....

Roy Eltham · 2014-03-15 10:25

Another thing that can be done in the IDE/editor is to visualize the REPx instructions target repeat range of instructions.
Similar to the grey indenting visuals in proptool.

In any case, we can experiment and iterate on this stuff when we get farther along with things.

It should be easy to allow "normal" usage of the instruction as well as "aided" usage.

potatohead · 2014-03-15 10:30

Bill Henning wrote: »
If there must be optional syntactic sugar, it should be really simple. I suspect someone would have already suggested something as follows:
         REPx #loops    ' where x = 'S' or 'D'
         ' spacer/spacers go here
         LOOP 
              ' instructions go here
         ENDL
This way, only the repeat count is specified (constant or register)

The assembler can figure out how many spacers are needed, if not enough, can add nops + issue warning, if too many, can issue error, and can count number of instructions between LOOP and ENDL

If we must do it that way, I like this proposal the best so far.

jmg · 2014-03-15 12:20

Roy Eltham wrote: »

When I said count there, I mean the count of how many loops to make, just to be clear.

The reason I said to have the RESx line to specify the labels is that it's easier to compile that. The labels also need to be unique per RESx, either via different names or preceding with : (to make them local). When the compiler is doing PASM stuff, it doesn't really handle dependencies on other lines in the source for compiling a given line (other than symbols identified in the first pass, or specially named ones like _RET labels).

That is the format Analog Devices uses.

         REPxA  StartLA,EndLA,#loops    ' REPxA is Address based mnemonic 
         ' spacer/spacers go here
         StartLA
              ' instructions go here
         EndLA

To me that is clearer on large code blocks, as generic names do not 'belong' to anything, and a REP with count, also has no clear visual tags of what it will actually DO. It then reads just like a WAIT #Count.

Sure, the REPx opcode can remain, for those who really like counting lines, and running their own syntax checks.

The rest of us, can use simple addresses and let the assembler do the counting, and syntax checks - that's what PC s are for.

Cluso99 · 2014-03-15 15:23

I like the start/end for the REPX count. But this is for the open compiler, not pnut.
May I suggest, if implemented,

    REPx #loops
    ..... 'compiler checks no. of instructions, warning if incorrect
:startrep
    .....
:endrep
    .....

potatohead · 2014-03-15 18:29

That has been my preference too. Pnut should do what it really needs to and no more.

Roy will port it, and lots of goodies make sense then, as does using the features in GAS, like macros...

Secondly, keeping Pnut lean means generally good things when it gets ported on chip. The P2 could very well replace the PC for this task when building P3.

Finally, for lack of a standards process, Pnut is the reference implementation, and on that basis really should be as explicit as possible.

A smarter overall assembler, which I think is a really nice to have, is better done one layer up from where we are right now, IMHO.

NOP vs WAIT as pipeline fillers

Comments