Assembler reported ROM use can go over 100%

[maxim-zhao]

In an extreme example:

ROM bank 0 (74740 bytes (456.18%) used)
ROM bank 1 (156486 bytes (955.11%) used)
ROM bank 2 (21124 bytes (128.93%) used)

This is in a translation hack using .background and a mixture of .unbackground and overwrite sections. Experimenting suggests the former works OK but the latter causes double-counting. Example (where PS1-J.SMS is a 512KB file, you can reduce for a simpler case):

.memorymap
slotsize $4000
slot 0 $0000
slot 1 $4000
slot 2 $8000
defaultslot 2
.endme

.rombankmap
bankstotal 32
banksize $4000
banks 32
.endro

.background "PS1-J.SMS"

.org $1000
.section "Overwrite section" overwrite
.dsb 100 0
.ends

Plus:

wla-z80 -v foo.asm

Produces (edited to remove higher banks info):

Pass 1...
Directive checks...
Internal pass 1...
Internal pass 2...
-------------------------------------------------
---                   ROM                     ---
-------------------------------------------------
ROM bank 0 (16484 bytes (100.61%) used)
  - Outside .SECTIONs (16384 bytes)
    - Used space at $0000-$3fff (16384 bytes).
  - Sections (100 bytes)
    - .SECTION "Overwrite section" (100 bytes).
...
-------------------------------------------------
---                   RAM                     ---
-------------------------------------------------
No .RAMSECTIONs were found, no information about RAM.
-------------------------------------------------
---                 SUMMARY                   ---
-------------------------------------------------
ROM: 524388 bytes (100.02%) used.
RAM: No .RAMSECTIONs were found, no information about RAM.

I haven't figured out how it manages to get the >200% figure shown at the top, though.

[maxim-zhao]

Another example without .background:

.memorymap
slotsize 1000
slot 0 1000
defaultslot 0
.endme

.rombankmap
bankstotal 1
banksize 1000
banks 1
.endro

.org 0
.dsb 1000 $ff

.section "Force section" force
.dsb 100 0
.ends

Pass 1...
Directive checks...
Internal pass 1...
Internal pass 2...
-------------------------------------------------
---                   ROM                     ---
-------------------------------------------------
ROM bank 0 (1100 bytes (110.00%) used)
  - Outside .SECTIONs (1000 bytes)
    - Used space at $0000-$03e7 (1000 bytes).
  - Sections (100 bytes)
    - .SECTION "Force section" (100 bytes).
-------------------------------------------------
---                   RAM                     ---
-------------------------------------------------
No .RAMSECTIONs were found, no information about RAM.
-------------------------------------------------
---                 SUMMARY                   ---
-------------------------------------------------
ROM: 1100 bytes (110.00%) used.
RAM: No .RAMSECTIONs were found, no information about RAM.

[vhelin]

Thanks for the report! I'll try to fix this in the following couple of days...

[vhelin]

Another example without .background:

.memorymap
slotsize 1000
slot 0 1000
defaultslot 0
.endme

.rombankmap
bankstotal 1
banksize 1000
banks 1
.endro

.org 0
.dsb 1000 $ff

.section "Force section" force
.dsb 100 0
.ends

Pass 1...
Directive checks...
Internal pass 1...
Internal pass 2...
-------------------------------------------------
---                   ROM                     ---
-------------------------------------------------
ROM bank 0 (1100 bytes (110.00%) used)
  - Outside .SECTIONs (1000 bytes)
    - Used space at $0000-$03e7 (1000 bytes).
  - Sections (100 bytes)
    - .SECTION "Force section" (100 bytes).
-------------------------------------------------
---                   RAM                     ---
-------------------------------------------------
No .RAMSECTIONs were found, no information about RAM.
-------------------------------------------------
---                 SUMMARY                   ---
-------------------------------------------------
ROM: 1100 bytes (110.00%) used.
RAM: No .RAMSECTIONs were found, no information about RAM.

Looking at this I guess the issue here is that the assembler doesn't place any of the .SECTIONs and just reports what's in the object/source file. Try to link this example and the linker will tell that "Force section" goes beyond the ROM size...

To fix this issue I'd rather just make the assembler to understand that the FORCE .SECTION overflows from the BANK 0 and it should issue an error...

[vhelin]

In an extreme example:

ROM bank 0 (74740 bytes (456.18%) used)
ROM bank 1 (156486 bytes (955.11%) used)
ROM bank 2 (21124 bytes (128.93%) used)

This is in a translation hack using .background and a mixture of .unbackground and overwrite sections. Experimenting suggests the former works OK but the latter causes double-counting. Example (where PS1-J.SMS is a 512KB file, you can reduce for a simpler case):

.memorymap
slotsize $4000
slot 0 $0000
slot 1 $4000
slot 2 $8000
defaultslot 2
.endme

.rombankmap
bankstotal 32
banksize $4000
banks 32
.endro

.background "PS1-J.SMS"

.org $1000
.section "Overwrite section" overwrite
.dsb 100 0
.ends

Plus:

wla-z80 -v foo.asm

Produces (edited to remove higher banks info):

Pass 1...
Directive checks...
Internal pass 1...
Internal pass 2...
-------------------------------------------------
---                   ROM                     ---
-------------------------------------------------
ROM bank 0 (16484 bytes (100.61%) used)
  - Outside .SECTIONs (16384 bytes)
    - Used space at $0000-$3fff (16384 bytes).
  - Sections (100 bytes)
    - .SECTION "Overwrite section" (100 bytes).
...
-------------------------------------------------
---                   RAM                     ---
-------------------------------------------------
No .RAMSECTIONs were found, no information about RAM.
-------------------------------------------------
---                 SUMMARY                   ---
-------------------------------------------------
ROM: 524388 bytes (100.02%) used.
RAM: No .RAMSECTIONs were found, no information about RAM.

I haven't figured out how it manages to get the >200% figure shown at the top, though.

This issue surely sounds like it's double counting OVERWRITE .SECTIONs - I'll try to fix this as well...

[vhelin]

Just realized that I cannot do the .SECTION sanity check for FORCE and OVERWRITE .SECTIONs in the assembler as their locations can be changed in the linker.

[vhelin]

Also, for OVERWRITE .SECTIONs it's impossible to tell how much other .SECTIONs they'll overwrite after everything has been linked as the assembler doesn't know the final placements of the .SECTIONs, and other .SECTIONs could come from other files.

I can improve assembler's verbose output a little, but take that as an isolated reference. Only the linker knows the final truth.

[vhelin]

The latest sources should now handle OVERWRITE and FORCE .SECTIONs a little bit better when writing that report at the end of assembling, but if you stuff a ROM bank with more data in .SECTIONs that it can take it will still report values past 100% which I think should be left as it is as it's informative for letting the user know what has happened...

[maxim-zhao]

With the latest changes I still get this: asm.log
You can see I have a lot of sections (it's a translation hack), but they don't add up to the numbers shown. 100% of my code and data is in sections, so the "outside .SECTIONs" parts should refer to the remaining backgrounded data - but in bank 1, I have 456 sections, which cannot logically add up to more than 100% without the linker warning or erroring. The resulting symbol file is in here: ps1jert.en.zip

[maxim-zhao]

Aha, found something. In the assembler log:

ROM bank 1 (155629 bytes (949.88%) used)
...
  - Sections (141553 bytes)
    - .SECTION "Menu data" (3868 bytes).

In the symbol file:

0002c000 0b:0000 8000 00000f1c Menu data

It's in bank $b, not bank 1. The code:

.slot 2
.section "Menu data" superfree
.block "Menus"
MenuData:
.include {"generated/{LANGUAGE}/menus.asm"}
.endb
.ends

So I guess it's counting superfree sections towards the bank that is active when they are defined, because it has no idea where they'll be placed at link time. Confusing, for sure. Maybe they ought to be counted separately at compile time, under a "no bank assigned yet" heading?