PRINT OFF is not truly being honored

[Fish-Git]

The attached test (reproduced further below) explains everything. The defined macro contains a SPACE statement, which is still being printed even though a PRINT OFF statement immediately precedes the macro invocation:

(EDIT: problem also occurs outside of a macro too. See subsequent comment further below.)  

• ASMATEST.asm.txt
• ASMATEST.list.txt
• ASMATEST.pdf

***********************************************************************
*        Define the macro
***********************************************************************
         SPACE
         MACRO
         OVERHEAD &NUM              &NUM = number of sets
         LCLA  &CTR
&CTR     SETA  &NUM
.LOOP    ANOP
.*
         SPACE
         LM    R1,R4,OPSPERF        Get TRTRE operands
         BC    B'0001',*+4          Not finished
.*
&CTR     SETA  &CTR-1
         AIF   (&CTR GT 0).LOOP
         MEND
         SPACE
***********************************************************************
*        Now USE the macro...
***********************************************************************
         SPACE
         USING *,R0                 (dummy USING for bug report)
*                                   100 sets of overhead
         OVERHEAD 2                 (first 2)
         SPACE
*        .........ETC.........
         SPACE
         PRINT OFF
*
*    Neither these comments NOR any of the 'SPACE' statements
*    generated by the macro should consume any print lines
*    since printing is disabled via the 'PRINT OFF' statement!
*
         OVERHEAD 96                (3-98)
         PRINT ON
         SPACE
         OVERHEAD 2                 (last 2)
         SPACE
OPSPERF  EQU   0                    (dummy value for bug report)
R0       EQU   0                    (dummy value for bug report)
R1       EQU   1                    (dummy value for bug report)
R4       EQU   4                    (dummy value for bug report)
         SPACE
         END

If I change the SPACE statement in the macro to a * comment statement instead, it works fine.

"Spacing" type statements (SPACE and EJECT statements -- and probably even TITLE statements too) -- should not cause print lines to be consumed when PRINT OFF is in effect.

PRINT OFF should mean precisely that: NO PRINTING.

[Fish-Git]

Another simple test that fails, this time without using macros:

*
*    Another simple test, but this time WITHOUT using any macro.
*    This time we'll just insert a bunch of comment statements
*    interspersed with some SPACEs and EJECTs to see how ASMA
*    behaves.
*
*    This first test is with just SPACEs... (SPACE 44, SPACE 88, etc)
*
         PRINT OFF
* yada, yada, yada....
         SPACE 44
* blah, blah, blah...
         SPACE 88
* yada, yada, yada....
         SPACE 44
* blah, blah, blah...
         SPACE 88
* yada, yada, yada....
         SPACE 44
* blah, blah, blah...
         SPACE 88
* yada, yada, yada....
         PRINT ON
*
*    This next test is with a bunch of EJECTs...
*
         PRINT OFF
         EJECT
         EJECT
         EJECT
         EJECT
         EJECT
         PRINT ON
*
*    And finally, a series of EJECTs followed by a SPACE...
*
         PRINT OFF
         EJECT
         SPACE
         EJECT
         SPACE
         EJECT
         SPACE
         EJECT
         SPACE
         EJECT
         SPACE
         PRINT ON
         END

Again, PRINT OFF should mean precisely that: no printing whatsoever.

[s390guy]

I agree that PRINT OFF should work for all operations. For some reason, EJECT and SPACE are not working properly.

I like this test even better!! Who knows. If I get this one to work maybe the macro version works too.

This is a low priority. For time being Patient: "Doctor, it hurts when I do that." Doctor: "Don't do that" applies.

I am trying to maintain momentum on the extended mnemonics.

Please be patient.

[Fish-Git]

This is a low priority.

Agreed.

For time being Patient: "Doctor, it hurts when I do that." Doctor: "Don't do that" applies.

No problem. I've already switched my macros to using * comment statements instead. I would eventually like to use spaces though, but for now comments are fine.

I am trying to maintain momentum on the extended mnemonics.

Understood. That's more important than this.

Please be patient.

No problem.  :)

[Fish-Git]

It's a shame GitHub Issues doesn't support some type of "Priority" value that you can assign to an issue. I think something like that would prove to be quite handy as well as quite popular too. I'm sure many other GitHub users/organizations out there would appreciate something like that. Maybe I should write to them and request it?

[wrljet]

Bugzilla does (did).

[Fish-Git]

Bugzilla does (did).

Yeah, bug Bugzilla sucks.   ;-)

[wrljet]

I still like it. :-)

[s390guy]

Correction to this behavior of SPACE and EJECT has been pushed. Also, the TITLE directive reflects similar behavior, namely the TITLE directive does not cause a new title to appear. However, the NEXT time the title line is printed it will contain the title established by the preceding TITLE directive. ASMA.odt and ASMA.pdf have been updated to explicitly identify this behavior. This issue will remain open until Fish is able to confirm the correction.

[Fish-Git]

This issue will remain open until Fish is able to confirm the correction.

Confirmed!  Works perfectly.

THANK YOU, Harold.  :)