vhelin / wla-dx

WLA DX - Yet Another GB-Z80/Z80/Z80N/6502/65C02/65CE02/65816/68000/6800/6801/6809/8008/8080/HUC6280/SPC-700/SuperFX Multi Platform Cross Assembler Package
Other
546 stars 98 forks source link

[documentation] _sizeof generated inside .section even without following label #618

Open willbritton opened 9 months ago

willbritton commented 9 months ago

This is a minor observation I made accidentally, but potentially a little bit of clarification could be added somewhere in the docs about how _sizeof symbols are generated.

Here's what I think:

  1. Outside of .section blocks, _sizeof symbols are generated between one non-child label and another non-child label, as described here.

e.g.

.my_first_label:
  .db $55
.my_second_label:
  .db $aa

In this case, a symbol _sizeof_my_first_label is generated with value 1

  1. Outside of .section blocks, no _sizeof symbol is generated for the very last label in the source, e.g.:
    .my_last_label:
    .db $33
    ; end of file

A symbol _sizeof_my_last_label is NOT generated in this case.

  1. Inside a .section block, a _sizeof symbol is generated as in case 1 above between two labels:
    .section "MySection" bank 0 slot 0 free
    .my_first_label:
    .db $55
    .my_second_label:
    .db $aa
    .ends

    (also _sizeof_my_second_label is generated here: but see below)

In this case, a symbol _sizeof_my_first_label is generated with value 1.

  1. Inside a .section block, a _sizeof symbol is generated between the last label and the end of the block, unlike in case 2 above:
    .section "MySection" bank 0 slot 0 free
    .my_last_label:
    .db $33
    .ends

In this case a symbol _sizeof_my_last_label IS generated.

Hope I have this correct! Assuming it's intentional, perhaps the docs should reflect it more clearly.

EDIT: I should say that I prefer the behaviour within sections, i.e. that wla infers the end of a label by virtue of the fact that there are no more in the same section. Personally I feel like the same ought to be true of a label outside of a section but I'm sure there's a good reason that it doesn't work like this.

maxim-zhao commented 9 months ago

I seem to remember this was added at my request, as else I had to add labels to make it work; and that it actually just makes "invisible" labels at the end of each section. I concur that the end of the assigned data ought to act the same way, so for example it wouldn't include any unassigned (empty) bytes in the size of that last label, or if any "gaps" are left due to use of .org to move the insertion point around.

I guess in this case:

.org 0
label1: .db "Hello world"

.org $100
label2: .db 0

_sizeof_label1 ought to be 11; is is actually 256 now?

vhelin commented 8 months ago

Ok, looking at write.c:generate_sizeof_label_definitions() in wlalink I can say that the sizeof calculator only uses labels, but by rewriting that function I could make it look into the ROM usage array to see the used and unused bytes of the output. Not 100% sure at this point if the final information is available at the time we generate sizeof labels, but I'll dig into this next week.

vhelin commented 8 months ago

I hope the latest commit fixes this issue: I made generate_sizeof_labeldefinitions() in WLALINK to stop when it encounters gaps in the output outside .SECTIONs (.SECTIONs don't have gaps inside them). I can still see that the function calculates _sizeof\* labels for definitions, which I guess it should not, but I'll fix that next.

Also sorry for my absense, I've been doing other things, taking a break from WLA DX, but I'll try to devote more time to WLA DX in the near future...

vhelin commented 8 months ago

My latest commit has a bug it seems, but I'll try to fix it tomorrow...

vhelin commented 8 months ago

Ok, if you download the latest sources the problems mentioned in this issue should be gone. I also updated the documentation to tell what happens with labels outside .SECTIONs (gaps in output that follow the labels)