Assembler fails when assembling PDOS's sapstart.asm

[wxwisiasdf]

asma.py Copyright (C) 2014-2020 Harold Grovesteen
Phase 'pass0_1' INTERNAL ERROR WHILE PROCESSING THIS STATEMENT
    [471] *
Traceback (most recent call last):
  File "/home/superleaf1995/src/SATK/asma/asmoper.py", line 394, in getMacro
    mte=self.macros[macname]
  File "/home/superleaf1995/src/SATK/asma/asmoper.py", line 725, in __getitem__
    return self.macros[name]
KeyError: 'CVT'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "../tools/asma.py", line 419, in <module>
    ASMA(tool,dm).run()
  File "../tools/asma.py", line 149, in run
    result=self.assembler.assemble(filename=self.source)
  File "/home/superleaf1995/src/SATK/asma/assembler.py", line 1525, in assemble
    return self.SP.run(self,filename)
  File "/home/superleaf1995/src/SATK/asma/assembler.py", line 3464, in run
    return self.process()   # Return the result of last phase run
  File "/home/superleaf1995/src/SATK/asma/asmbase.py", line 1657, in process
    self.result=phase(self.asm,fail=self.asm.fail)  # Execute it!
  File "/home/superleaf1995/src/SATK/asma/assembler.py", line 3310, in Pass0_1
    self.getStmts0_1(asm,fail=fail,debug=debug)
  File "/home/superleaf1995/src/SATK/asma/assembler.py", line 3257, in getStmts0_1
    ln=self.IM.getLogical(debug=debug)
  File "/home/superleaf1995/src/SATK/asma/asmline.py", line 1115, in getLogical
    logical=self.__getLogical(debug=debug)
  File "/home/superleaf1995/src/SATK/asma/asmline.py", line 996, in __getLogical
    self.categorize(logical)   # Determine the logical line's operation type
  File "/home/superleaf1995/src/SATK/asma/asmline.py", line 1028, in categorize
    oper=OMF.getOper(oper,mbstate=mbstate,macread=True,\
  File "/home/superleaf1995/src/SATK/asma/asmoper.py", line 588, in getOper
    oper=self.getMacro(opcode,macread=macread)
  File "/home/superleaf1995/src/SATK/asma/asmoper.py", line 400, in getMacro
    oper=self.getMacLib(macname)
  File "/home/superleaf1995/src/SATK/asma/asmoper.py", line 344, in getMacLib
    r=asm.MP.run(asm,macname)
  File "/home/superleaf1995/src/SATK/asma/assembler.py", line 3709, in run
    result=self.process()
  File "/home/superleaf1995/src/SATK/asma/asmbase.py", line 1657, in process
    self.result=phase(self.asm,fail=self.asm.fail)  # Execute it!
  File "/home/superleaf1995/src/SATK/asma/assembler.py", line 3598, in MacLib
    self.getStmts(asm,fail=fail,debug=debug)
  File "/home/superleaf1995/src/SATK/asma/assembler.py", line 3560, in getStmts
    macdefn=mb.defining(s,debug=False)
  File "/home/superleaf1995/src/SATK/asma/asmmacs.py", line 1716, in defining
    stmt.Pass0(self.asm,macro=self,debug=ddebug)
  File "/home/superleaf1995/src/SATK/asma/asmstmts.py", line 1478, in Pass0
    if parm.keyword:
AttributeError: 'NoneType' object has no attribute 'keyword'

[s390guy]

That is ugly. I will take a look at this. It might be something simple. If not I will need the assembler source code to reproduce it.

[wxwisiasdf]

Here are the mclib used https://sourceforge.net/projects/mvs380/files/mvs380/MVS_380%202.0/ for compiling

[kerravon86]

Hi Harold. Long time no see. Paul Edwards here, not sure if my name shows up.

I have been waiting to see what your asma looks like, and spent a lot of time trying to port Python 3.3 so that I can run your 30,000 lines of lovingly handcrafted Python code. I have a Windows executable built against PDPCLIB, but it doesn't run properly yet.

Anyway, the opportunity arose that SuperLeaf wanted to do IBM mainframe work and I pointed him to both sapstart.asm and SATK, but it didn't quite work. We've made a lot of progress together though to get to that point with Hercules 3.13.

I noticed that SuperLeaf didn't give you pointers to other code you need if you need to reproduce the problem. Here is what is being assembled:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/sapstart.asm

And here are most of the macros:

https://sourceforge.net/p/mvs380/mvs380/ci/master/tree/source/maclib/

(apart from the modgen.zip that SuperLeaf already pointed you too).

I hope everything is going well in your life. I'm having non-stop fun myself. See you around! :-)

[kerravon86]

Hi Harold. While trying to debug a separate problem:

[22] @[22]-1 COPY operation file name not recognized

We got an exception that we think was caused by this saying "tracing" instead of "trace":

asma/asmstmts.py: asm._check_cur_sec(debug=tracing)

Not a definite bug, just a question.

Thanks. Paul.

[s390guy]

All Python exceptions are bugs. They should not occur. Hopefully this debug=tracing issue is merely a typo.
I will look at that one first.

FYI, Python is an interpretive language. So, some exceptions are only caught when the Python code is executed. This makes code coverage during testing to be quite important. Nevertheless, with something as large as ASMA, there is inevitably situations that only users seem to find, LOL.

Harold

[s390guy]

On a personal note, I am doing fine. Puttering along with SATK mostly. Trying to stay healthy (no COVID). So far so good. Retired. Huge stress reliever! So pretty much normal, well for me anyway.

I noticed you moved to a new email group for Hercules 390. I did not join it. Too much change and too much discussion for me to keep up. I was to the point of getting some of your changes into Hercules when you guys went on to more changes.

Glad you are giving SATK a whirl. PDOS would seem to be a natural a place to try it out. I can see some places where some collaboration (besides exceptions) could be valuable. ASMA is not a clone of any proprietary assembler. It is very similar, but not identical. You may find the need to make some code changes for PDOS to work with ASMA. There are quirks of any implementation that may not work with a different implementation. Hope you are open to making such changes.

There is presently no linking or relocation in SATK. SATK expects a single assembly to create its output. I am presently working on a tool that allows for both linking and relocation. This is not yet full object module creation, but is half way there. This may prove of use to you. I am building it for some testing I want to create for simh, but it is still under development. The goal is binary code reuse. I generally do not "pre-announce" additions to SATK, but thought, considering what you are doing, it would be useful for you to know. This is particularly true for when you start to bring GCC into the picture. This new tooling might allow you to use it more "naturally". Just a thought. Contact me directly and we can discuss this more completely if of interest or on the regular SATK email list: satk@groups.io

That goes for anyone else who might be reading this issue.

Harold

[s390guy]

The issue with "debug=tracing" is indeed as you suspected. It has been fixed and pushed to the repository.

[s390guy]

I have looked at the CVT macro.

Phase 'pass0_1' INTERNAL ERROR WHILE PROCESSING THIS STATEMENT
[471] *

The comment itself should not be a problem. All of ASMA macros in libraries (which is what CVT is from ASMA's perspective) have comments preceding the MACRO operation. These comments document the licensing for the macro.

Further, the exception call stack indicates that it is trying to parse a macro prototype statement for CVT. And yet the error seems to be occurring while it is processing a comment. I strongly suspect that the comment is actually occurring before the CVT macro is called. ASMA "tries" to indicate where it is having the problem when these types of errors occur. "Tries" is the operative word and in some cases it just knows about the preceding statement rather than the one it is working on. So that is the one that gets identified by this message.

As a test, please, use COPY to bring the statements of cvt.mac into the assembly from the file and report back the results.

Why ASMA is encountering a Python None object is not at all clear either. This is the actual bug triggering the exception.

ASMA has two line formats: variable length lines and 80-column fixed lines. The code supplied by ASMA uses variable length
lines. The 80-column fixed line format, used by CVT, is considered experimental. Translation, not well tested. This may be part of the problem. Or of course a combination of problems is possible that finally result in the exception.

I will continue to set up a test bed for PDOS... Hopefully I can find a minimal amount of statements that trigger the exception. Easier to resolve that way. I do not honestly expect any user to be able to do that with this type of error.

Harold

[s390guy]

How are you handling the conditional assembly contained within sapstart.asm? As found on source forge, this code will not assemble with ASMA. And it is the code that is calling CVT.

Conditional assembly statements (ANOP, AGO, AIF, etc.) are only supported within a macro statement. ASMA's recommendation for this situation is to "wrap" the program, or portions that need it within a single macro definition. This allows the conditional statements to be processed as part of the macro.

[kerravon86]

Hi Harold.

The "COPY PDPTOP" will bring in this:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/pdptop.mac

which has the all-important:

&ZSYS SETC 'S380'

If SATK doesn't allow this syntax then it would seem to be
expedient for us to just delete the S/370 and S/380 targets
and only have S/390, which is what SuperLeaf is targeting
with GCC 11.

But I'll let him decide whether he would prefer to keep
the logic within a macro. I think I know how to do that,
based on Gerhard's use of macros in mvssupa.asm.

Note that I have answered your other post here:

https://groups.io/g/satk/message/37

[s390guy]

There is no need to get rid of the conditional assembly is sapstart.asm. sapstart.asm simply needs to be a macro defined inline, COPY'd or from a library. That will allow it to examine the variables set by pdptop.mac and alter its assembly sequence. PRINT can be used to control listing size.

[wxwisiasdf]

ASMA does not seem to correctly report lines AND columns - it's saying line 70 is having an error, but line 70 is a comment? - This is with the a sapstart.asm file (but without conditionals)

ASMA: [70:25] is not a unary operator

Line 70: * into the problem. (20 chars)
Line 25: YREGS (15 chars)

Full error output: https://pastebin.com/40TEffHW
Source code for reproducing error: https://pastebin.com/NXgHSvVq

[s390guy]

Not clear why my assembly resulted in different line numbers, but assembling sapstart resulted in:

                                          52          DC    (CODESTRT-*+ORIGIN)X'00'
    ** [52:25]  is not a unary operator

Line 52 is not a comment (although line 53 is). The 25 points to the * as being the source of the problem.

By design ASMA treats addresses as a different type of data than it treats numeric values. Line 35 in my assembly defines:

CODESTRT EQU 1024 Start of our real code

CODESTRT is an integer. You can not subtract an address (which is how * is defined) from an integer.

I moved the definition of CODESTRT to the first unnamed CSECT so that * is defined like this. This turns the previously defined integer into an address.

                                                                                        CSECT

000400 000001 39 CODESTRT EQU *+1024 Start of our real code

• is not defined if a CSECT is not in existence.

There is definitely a parsing issue with regards to the duplication factor. ASMA does not tolerate the * within the a duplication factor. To get around this, I added, preceding the DC for X'00' s, this statement and adjusted the DC accordingly:

0003F8 000001 52 FILL EQU CODESTRT-*
000008 00000000 00000000 53 DC (FILL)X'00'
000400 59 POSTIPL DS 0H

This gets you to your expected starting location. The value for FILL (an integer) results from the subtraction of two addresses now and works.

Ideally, the EQU for FILL should not be needed. But moving the expression into the duplication factor triggers the toleration issue mentioned above.

This results in a working assembly for these statements. Part workaround and part source correction for ASMA's design.

I am leaving the rest of the clean up to you.

The ASMA documentation (doc/asma/ASMA.pdf or doc/asma/ASMA.odt) discusses address arithmetic on pages 42 and 43.

The output format you are expecting, a binary file, is described in the ASMA doc on pages 27, and 28, "Using the Image File".
An image file is output when the --image command-line operand is used (see page 15). Page 15

[s390guy]

Any further discussion of PDOS should be in a separate issue. Initially, I thought we were dealing with one issue, but it turns out to be two.

SuperLeaf1995, can we close this issue?