[Feature request] Feature to ensure a certain piece of data is within aligned boundary

[nitro2k01]

This is not really easy to implement, but I though I'd post it before I forget again so it's on the record as a feature request.

The feature requested is the ability to make sure that a certain piece of data (for example a table or a short piece of data to be copied) doesn't cross a page boundary. This would allow optimizations in many cases where 8 bit math can be used without checking overflow, and without the need for hard alignment to a page boundary, which imposes more restrictions on the alignment than necessary. Consider something like:

        ; A contains an index to the table.
        ld      D, HIGH(some_table)
        add     LOW(some_table) ; This is ok because we can assume the table won't cross a page boundary.
        ld      E,A
        ld      A, [DE]

; ....
BALIGN 8
some_table:
        db xx, xx, xx, xx
ENDBALIGN

Or:

small_copy::
        ld      A,[DE]
        ld      [HL+],A
        inc     E  ; This is ok because we can assume DE will not cross a page boundary.
        dec     B
        jr      nz,small_copy
        ret
; ....
        ld      DE,some_data
        call    small_copy

; ....
BALIGN 8
some_data:
        db xx, xx, xx, xx
ENDBALIGN

[Rangi42]

Just use an assert, which will be evaluated at link time for floating data:

some_table:
    db xx, xx, xx, xx
some_table_end:

assert HIGH(some_table) == HIGH(some_table_end - 1), "some_table crosses a page boundary"

[nitro2k01]

That would merely check for the problem, not fix the alignment automatically. Depending on the algorithm for placing floating sections, this could also trigger the assertion far more often than on average once for every 256 bytes of data added.

[aaaaaa123456789]

You have to align the containing section in this case. Which makes sense, because if your section has an alignment requirement, you should be stating it at the top.

[nitro2k01]

You have to align the containing section in this case.

No, the whole point of the FR is to not have to align the containing section. If you align the section, the data will be placed at the start of the section, or at some offset from the start, depending on what comes before the it.

The point of the FR is to give an optimizing section placer more options to place data that doesn't need to be at a fixed offset from an aligned boundary, but also can't cross a boundary, such as the examples given.

[ISSOtm]

There is intra-section align, though.

[nitro2k01]

There is intra-section align, though.

Again, this doesn't fulfill the goal of helping an optimizing section placer. Intra-section align is still just align with some offset. It gives one placement option per alignment page, whereas the FR would give page_size-data_size different placement options per alignment page.

Just so I'm clear about what the FR suggests: For example, a 16 byte table with 256 byte alignment, could currently only placed at $xx00 using the current align. (Or some other specified fixed offset instead of 0.) With the FR, the placer could choose any place from $xx00-$xxF0 which would increase the ability of the placer to place sections compactly without padding. Especially for code that uses such tables heavily.

I don't realistically think this will be implemented any time soon since it would take a lot of effort for a pretty niche use case, but I thought I'd get the FR in for the record anyway.

[Rangi42]

I don't the linker's greedy algorithm for section placement is currently capable of taking advantage of this extra freedom, but it's an interesting idea.