Jump to content
IGNORED

Curious LST formatting


intvnut

Recommended Posts

Another recent thread from INTVPROG that's getting cock-blocked by Yahoo's crappiness.

___________________________

Hi, there,

I just noticed a change in the assembler's formatting of the LISTING file. Whereas each decle was always rendered in its own line, now consecutive decles (like for strings) are arranged on the same line. What's more, these lines appear to be of arbitrary length, making it harder (at least for me) to discern specific words.

For instance, contrast the following original formatting:

; I can follow this vertical stream of words...
500F 0001               DECLE 1,1,1,1,1              ; 500F Initial color stack 0 and 1: Blue
5010 0001
5011 0001
5012 0001
5013 0001
5014 0075               DECLE 2017 - 1900            ; $5014
5015 0043               STRING "Christmas Carol", 0
5016 0068
5017 0072
5018 0069
5019 0073
501A 0074
501B 006D
501C 0061
501D 0073
501E 0020
501F 0043
5020 0061
5021 0072
5022 006F
5023 006C
5024 0000


With the new formatting:

; Looks like a jumble of numbers thrown in a pack...
500F 0001 0001 0001 0001        DECLE 1,1,1,1,1              ; 500F Initial color stack 0 and 1: Blue
5013 0001
5014 0075                       DECLE 2017 - 1900            ; $5014
5015 0043 0068 0072 0069        STRING "Christmas Carol", 0
5019 0073 0074 006D 0061 0073 0020 0043 0061
5021 0072 006F 006C 0000


Line at location 0x5019 seem to pass beyond its "margin," blending into the source.

I find this highly distracting. Is there a way to regain the previous formatting, an assembler directive or option perhaps?

dZ.

  • Like 1
Link to comment
Share on other sites

I had fixed an accounting error in the width calculation for emitted data. Now AS1600 is doing the "right thing," which is to output up to 4 words of emitted data on lines with code, and up to 8 words of emitted data on lines w/out code. The emitted data will always be at the left, separated by single spaces. Previously, the limit was 3 words on the same line as code, and it would try to space things out with tabs, and end up with really wonky formatting!
This isn't new behavior. It was there back in 2002 when I wrote the Lunar MP Demo whose YouTube video I recently posted.

.

                                        ;01234567890123456789
f81c 0020 0043 0047     @@m1    BYTE     " CGE Demo Version  "
f81f 0045 0020 0044 0065 006d 006f 0020 0056
f827 0065 0072 0073 0069 006f 006e 0020 0020 

.

That all got cleaned up a bit in 2013, around the same time as the infamous NOT change.

.

------------------------------------------------------------------------
r1055 | im14u2c | 2013-09-24 22:47:49 -0500 (Tue, 24 Sep 2013) | 1 line

clean up listing file a bit; allow four hex words per assembled line, and move actual listing info over to column 32

------------------------------------------------------------------------

.

I think somewhere along the way, I may have b0rken support for outputting more than one word on a line for DECLE and STRING, while playing with the expression list stuff. That said, I don't seem to be able to find what version caused "one per line."
Right now, these numbers are compiled in constants (and have been for eons).
I'm having a hard time finding what version of the assembler outputs the data in the manner you call "original formatting." I tried the following 25 versions:
jzintv-1.0-beta-x86_64-linux.zip
jzintv-1.0-beta4-x86_64-linux.zip
jzintv-20051204-linux-x86_64.zip
jzintv-20100914-linux-x86-64.zip
jzintv-20101212-x86_64-linux.zip
jzintv-20101213-x86_64-linux.zip
jzintv-20101224-x86_64-linux.zip
jzintv-20150120-linux-x86-64.zip
jzintv-20150213-linux-x86-64.zip
jzintv-20160314-linux-x86-64.zip
jzintv-20160331-linux-x86-64.zip
jzintv-20160615-linux-x86-64.zip
jzintv-20160817-linux-x86-64.zip
jzintv-20170530-linux-x86-64.zip
jzintv-20170530b-linux-x86-64.zip
jzintv-20170708-linux-x86-64.zip
jzintv-20170902-linux-x86-64.zip
jzintv-20171031-linux-x86-64.zip
jzintv-20171113-linux-x86-64.zip
jzintv-20171120-linux-x86-64.zip
jzintv-20171231-linux-x86-64.zip
jzintv-20171231b-linux-x86-64.zip
jzintv-20180108-linux-x86-64.zip
jzintv-20180114-linux-x86-64.zip
jzintv-20180115-linux-x86-64.zip
I tried with the following test case:

.

        ORG $7000
        STRING "Four score and seven years ago...", 0
        DECLE 1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0

.

The output generated was one of two variants:

.

 0x7000                         ORG $7000
7000 0046 006f 0075             STRING "Four score and seven years ago...", 0
7003 0072 0020 0073 0063 006f 0072 0065 0020
700b 0061 006e 0064 0020 0073 0065 0076 0065
7013 006e 0020 0079 0065 0061 0072 0073 0020
701b 0061 0067 006f 002e 002e 002e 0000
7022 0001 0002 0003             DECLE 1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0
7025 0004 0005 0006 0007 0008 0009 0000 0001
702d 0002 0003 0004 0005 0006 0007 0008 0009
7035 0000
 ERROR SUMMARY - ERRORS DETECTED 0
               -  WARNINGS       0

.

or
.
0x7000                                  ORG $7000
7000   0046 006F 0075 0072              STRING "Four score and seven years ago...", 0
7004   0020 0073 0063 006F 0072 0065 0020 0061
700C   006E 0064 0020 0073 0065 0076 0065 006E
7014   0020 0079 0065 0061 0072 0073 0020 0061
701C   0067 006F 002E 002E 002E 0000
7022   0001 0002 0003 0004              DECLE 1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0
7026   0005 0006 0007 0008 0009 0000 0001 0002
702E   0003 0004 0005 0006 0007 0008 0009 0000
 ERROR SUMMARY - ERRORS DETECTED 0
               -  WARNINGS       0

.

I also tried checking out every 10th SVN revision, starting at r53 (the first really stable build in SVN from July 2006) and ending at 1593 (just a few revs from top of tree). None of the versions that compiled successfully (154 total) behave in the way you describe as "original." How far back are we talking here?

Link to comment
Share on other sites

dZ-Jay:

__________

 

It's the version I was using during Christmas Carol development. However, I now seem to recall seeing more than one word per line in the past, hmmm. My guess is that it got broken in one of the builds while we were working on my game and you were fixing bugs and adding features. I never updated after Christmas Carol went out, until recently. (Well, I updated back in 2015, noticed the "NOT" issue, and reverted.)

Anyway, the reason that I noticed is because I am trying to DIFF an old listing file from Christmas Carol with one built with the latest tools to try to find what is broken. I updated Christmas Carol source code to compensate for the updated "NOT" behaviour, but it is all broken and it won't run correctly. :(
Is there any way to make this configurable? I find it very distracting to have lines "eat into" the actual code stream. You say that it emits up to 8 words of data on a line without code, but the problem is that the line before and the line after most likely do have code, making it all very confusing and harder to read. Can we keep it at 4 always?
-dZ.
_______________
Wait, I seem to recall updating at least once after Christmas Carol development but before 2015. I believe you increased the line buffer or something like that because my string search macro was breaking in P-Machinery...

(Or perhaps I worked around it?)

I also see this SVN log entry from February 2015:

Christmas Carol:
-----
Fixed: At some point in time, the assembler changed its behaviour of "PSHR PC" to push the *next* instruction--which is actually correct. However, this caused an "off by one" error in calculating the data argument offset in the DEBUG_HANDLER() routine.
-----

And.... with the power of Time Machine, I retrieved the old version I was using up to last year, and the file has the following timestamp:

Wednesday, May 16, 2012 11:40
438,532 bytes (442 KB on disk)

Anyway, I did have an old version. :\

- j.
Link to comment
Share on other sites

Me:
____________
BTW, regarding this item:
-----
Fixed: At some point in time, the assembler changed its behaviour of "PSHR PC" to push the *next* instruction--which is actually correct. However, this caused an "off by one" error in calculating the data argument offset in the DEBUG_HANDLER() routine.
-----
That wasn't a change in the assembler. The assembler doesn't define the behavior of instructions. jzIntv itself incorrectly implemented MVO@ R7, R6, and that was causing Ms. Pac-Man to fail when run in jzIntv. That was the first game I knew of that was using that instruction.

I'm guessing you never tried DEBUG_HANDLER() on real hardware?

Link to comment
Share on other sites

dZ:

___________

 

Yeah, that was an unfortunate typo. The DEBUG_HANDLER() macro was used only during development, while testing on the emulator. There were a series of macros that saved the state of registers on the stack in order to display machine state on the screen, then HLT'ed.

Anyway, that was just an example to point out that I had updated the SDK tools at some point. :)
- j.
Link to comment
Share on other sites

Me, yesterday:

_______________

 

BTW, I haven't forgotten about this request. I've plumbed the required changes halfway through.
The assembler really doesn't have any infrastructure for changing the details of the listing format from within the assembly itself. All that stuff is compiled in behavior. So I have to plumb a bunch of stuff through.
In particular, the listing gets created in the back half; however, constant expressions get evaluated in the front half. So, if you're changing listing file parameters on the fly, I need to invent a new metadata record to pass from the front half to the back half to tell it "I'm changing a parameter that affects the back half." I also need to invent a keyword to convey that this expression changes an assembler config value, and so on...
It's a simple-to-state request, but slightly less simple to implement.
I suppose I could make it a command line flag, but it doesn't really seem like something that belongs on the command line. It's more like a game title. It seems like it should be part of the source. And even if it's slightly removed, you could do something like I did, and INCLUDE "bldflags.asm", and then use the -I command line flag to point to the directory that holds the appropriate build flags.
For example, Space Patrol included "bldflags.asm", and relied on the outside build-script to add an appropriate -I flag to point to the right bldflags.asm. The production bldflags.asm was effectively empty. It was non-empty, but everything was commented out, making it effectively empty:

.

$ cat ./jzintv/examples/spacepat/bin/bldflags.asm
;DOIDLEHST  EQU 1       ; def/nodef  Enable idle histogram
;DODEAD     EQU 1       ; def/nodef  DEAD instead of dying
;OLDMENU    EQU 1       ; def/nodef  Old, simple menu
;SEEKKEYS   EQU 1       ; def/nodef  Enable seek Keys
;SKIPTITLE  EQU 1       ; def/nodef  Skip title screen
;SKIPHUT    EQU 1       ; def/nodef  Skip course intro w/ hut
;JUMPWORLD  EQU 7       ; 0 .. 7, works only w/ OLDMENU

.

I don't know how many of those options still work. But I do know that you could make a directory that had a copy of this file, tweaked appropriately, and then you could rebuild Space Patrol with -I pointed at that directory, and you'd get a corresponding debug build.
Anyway, I digress... I'm working on it, albeit slowly.
Link to comment
Share on other sites

Ok, I just added the following. It'll be in the next release.

.


------------------------------------------------------------------------------
    LISTCOL expr1, expr2, expr3
------------------------------------------------------------------------------

This directive controls the formatting of the listing file.  Specifically:

    expr1:      Number of hex values shown on lines with source code
    expr2:      Number of hex values shown on lines without source code
    expr3:      Starting column for source code

The defaults are equivalent to LISTCOL 4, 8, 32.

The value for expr3 must be greater than or equal to 7 + 5*expr1.  All three
expressions must be greater than 0.  expr1 and expr2 must be less than 256,
and expr3 must be less than 2048.

Example:

    ORG     $7000
    LISTCOL 4, 8, 32
    DECLE   0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1
    LISTCOL 4, 4, 32
    DECLE   0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1
    LISTCOL 8, 8, 52
    DECLE   0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1

Results in:

0x7000                              ORG     $7000
                                    LISTCOL 4, 8, 32
7000   0000 0001 0002 0003          DECLE   0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1
7004   0004 0005 0006 0007 0008 0009 0000 0001
700C   0002 0003 0004 0005 0006 0007 0008 0009
7014   0000 0001 0002 0003 0004 0005 0006 0007
701C   0008 0009 0000 0001
                                    LISTCOL 4, 4, 32
7020   0000 0001 0002 0003          DECLE   0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1
7024   0004 0005 0006 0007
7028   0008 0009 0000 0001
702C   0002 0003 0004 0005
7030   0006 0007 0008 0009
7034   0000 0001 0002 0003
7038   0004 0005 0006 0007
703C   0008 0009 0000 0001
                                                        LISTCOL 8, 8, 52
7040   0000 0001 0002 0003 0004 0005 0006 0007          DECLE   0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1
7048   0008 0009 0000 0001 0002 0003 0004 0005
7050   0006 0007 0008 0009 0000 0001 0002 0003
7058   0004 0005 0006 0007 0008 0009 0000 0001
 ERROR SUMMARY - ERRORS DETECTED 0
               -  WARNINGS       0
Link to comment
Share on other sites

The overall diffstat wasn't as bad as I'd feared, once I'd made the compile-time values into variables a few commits back.


post-14113-0-69867800-1517381835.png


Also, you can test for the presence of LISTCOL by testing for __FEATURE.LISTCOL. So, if you need your source to compile on older AS1600 versions, you can wrap it in a macro that tests for __FEATURE.LISTCOL.



Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...