Unwanted multiple blank removal in macro generated assembler statements #35
Comments
|
You can't. You can with symbols that are eight or less but not with symbols of greater length, no. When macro model statements are generated, ASMA aims for the operation field to start in column 10 and operands in columns 16. If you end up using more than that, the generated statement simply inserts a blank between the parsed fields (which looks like gobbling spaces to you) so that the assembler can parse the separate fields. ASMA focuses on field preservation during macro model statement generation, not input column preservation. I am labeling this issue as an enhancement. Will need to look into the code to determine the details. Macros are converted to an internal representation that result in a sequence of Python objects that are "executed" when the macro is expanded. The actual input statement is long gone by the time the model statement is generated. |
Confirmed! Results in: What's even more interesting is that the column the comment field begins in IS preserved! The comment for each statement always starts in column 35, and for each ASMA macro generated statement, the comment field starts in ......... column 35! Which is totally unexpected! If one field (the comment field) can have its starting column preserved, why can't the other fields (operation and operands fields) have their starting column preserved as well? It doesn't make any sense to me!
Then, respectfully, your parsing logic sucks.
Input field preservation has nothing to do with input column preservation. The two are completely different things. One preserves a field's value, whereas the other preserves a field's column.
Here's a quick temporary fix: if the statement doesn't contain any '&' substitution variables in it, output an exact copy of the original statement as-is. The proper fix of course would be to save (remember) the starting column of both the operations and operands fields, and, when generating (constructing) the output statement, append the appropriate number of blanks to reach the saved target (original) column. Personally I can't see how doing that would be too terribly difficult to do either. (It sounds to me like you have the operation and operands field columns hard coded at 10 and 16, which, IMHO, they shouldn't be. They should be variable.) Anyway... Good luck with fixing this bug, ... er, ... I mean, with "implementing this enhancement". Anything you can manage to do would of course be greatly appreciated. Thanks Harold. p.s. I'm trying to develop a set of macros and code to support running stand alone tests in SIE mode, which means I need to be able to define a DSECT for the SIE State Block, and I'm using Hercules's existing SIE1BK and SIE2BK structs, which is why the field names are longer than 8 characters. I really don't want to have to define a whole new set of field names! That would be a PITA! |
|
For what it's worth, IBM's DOS/VS and z/VM assemblers work as expected:
I didn't bother testing MVS's or z/OS's, etc, but I suspect they behave the same way with respect to field column preservation. Now before you say it, I know ASMA was never meant to be an IBM assembler clone or behave the same as any other assembler. It's allowed to behave in its own way. But I suspect most mainframe assembler programmers expect the simple/basic things (such as field column preservation) to behave the same as what they're used to. Other things, sure. They can be unique to ASMA. But something as simple/basic as statement alignment? Sheesh! Feel free to swear and cuss at me. I know I'm being a bastard about this and deserve it (and I apologize for that). But readability is important to me (and I would like to think for other programmers as well). Sloppy hard to read programs breed hard to find bugs. Easy to read programs much less so. |
|
Your points are worth considering and I do agree this should be looked at. Almost NOTHING in ASMA is as simple as you think it is. I will do that when I can. But, ASMA is operating as designed, perhaps not how you would design it, so I look at this as a cosmetic enhancement. Feel free to swear or cuss at me back. LOL. Note the comment will actually move as well provided the model statement operands when expanded force it to do so. Your case simply did not force that situation. It is not clear why you are using a macro. A COPY operation might work just as well and the issue you are experiencing with generated macro model statements goes away. COPY will preserve your readability and allow the structure to be reused in other programs. Just a thought. |
|
Your suggestion related to the & character is also worth looking at. Testing a statement for an & is trivial in Python. Recognizing that no symbol variable substitution is happening could save a ton of processing during macro generation. That too is worth a look. Again, a performance enhancement as far as I am concerned. |
Which is exactly my point! You obviously already have logic that preserves the column where the COMMENT FIELD starts (as well as logic to move it further to the right if/when needed). That exact same logic (handling) should be applied to the operation and operands fields as well (and not just to the comment field only). How hard can that be? The infrastructure obviously already exists to preserve the starting column for the comment field (i.e. you must be passing the comment field's starting column number down to the rest of your code to reach the logic that eventually outputs the generated statement), so how hard can it be to add 2 new values/variables (operations field start column and operands field start column) and invoke the same logic for those two fields as as you're already doing for the comment field?! I understand "Almost NOTHING in ASMA is as simple as you think it is." I get that. But it certainly SEEMS it should be fairly trivial to do given that you're already doing it for one field! (the comment field!) How hard can it be to do the same thing for the other two fields?! Or am I missing something?
Not a half bad idea! I'm so used to using macros (and so rarely use I still would prefer to use a macro however, since I'm likely(?) going to be needing to use macros to generate other SIE handling code besides just SIE State Block DSECT generation. Anyway, I guess we can leave this as a low priority Enhancement request, given that this is a special case situation. In 99%+ of most all other situations, field names are always only 8 characters or less. This situation is unlikely to occur in 99%+ of most normal situations, so looking into it whenever you get the time is fine. No rush. It's just in my nature to want things fixed right away. Little shit like this just bugs the hell out of me. It gets in the way and distracts you from the bigger, more important shit, you know? I mean, just look at the listing I provided in my original problem report! Now imagine several pages of that! Not exactly easy to read, is it?! Anyway.... Do whenever you get around to it. No rush. As always, THANK YOU for providing us with such a great product. You know I'm your biggest fan, right? |
How can I align my macro generated assembler statements exactly the way I code them in ASMA?
Here's a simple repro test case that illustrates the problem:
Which produces:
As you can see, it appears ASMA's macro handling is reducing multiple blanks down to a single blank when it generates (outputs) a non-macro assembler statement, which screws up my desired statement alignment.
Is there some magical ASMA option or syntax that I am unaware of that will do what I want to do? I checked the manual but could not find anything anywhere covering this topic/situation.
Thanks.
The text was updated successfully, but these errors were encountered: