Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
willbritton opened this issue Dec 10, 2023 · 5 comments

Comments

@willbritton
Copy link

willbritton commented Dec 10, 2023

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
Copy link
Contributor

maxim-zhao commented Dec 27, 2023

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
Copy link
Owner

vhelin commented Jan 21, 2024

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 added a commit that referenced this issue Feb 5, 2024
@vhelin
Copy link
Owner

vhelin commented Feb 5, 2024

I hope the latest commit fixes this issue: I made generate_sizeof_label_definitions() 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
Copy link
Owner

vhelin commented Feb 5, 2024

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

@vhelin
Copy link
Owner

vhelin commented Feb 5, 2024

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants