Improve linker scripts a little

[ISSOtm]

Makes some progress towards #1008.

The implementation of FLOATING is a little slapdash, I'll give you that... but it turns out that the entire linker script processor is really assuming that PC is fixed the entire time.

None of this is tested, because it's really meant for experimentation by people who I'd assume would communicate with us in the first place (and I doubt anyone will mind if we tweak/fix the behaviour later on; something something experimental feature gates).

Also, no documentation has been written yet. I intend to fully overhaul rgblink(5) once the behaviour of this PR has been agreed upon and #1271 has been merged, and once that's done I'll unmark this as draft so we can bikeshed the documentation.

So, for the time being, please review the code and the behaviour it implies, and assume the documentation will be written accordingly afterwards.

[Rangi42]

Please review the semantics of floatingAlignMask.

[ISSOtm]

This PR should be marked as ready for merge (which is what I'm using the "draft" status for here; I think the "WIP" label serves the "ready for review" indication better) when rgblink.5 is overhauled.

(That is so we don't merge this PR while forgetting those changes.)

Made the alleged mask into a proper mask

[Rangi42]

This does not implement ROMX/WRAMX FLOATING to allow a linker script equivalent for SECTION "", ROMX/WRAMX without a BANK number. (Just noticed now after trying to test that.)

[Rangi42]

This PR should be marked as ready for merge (which is what I'm using the "draft" status for here; I think the "WIP" label serves the "ready for review" indication better) when rgblink.5 is overhauled.

(That is so we don't merge this PR while forgetting those changes.)

I've always used "draft" to mean "the creator has further intended changes before this should be merged, or maybe even before it can be reviewed". Which matches the use here (docs are to-do). I see the 'WIP" label as redundant given that.

[ISSOtm]

This does not implement ROMX/WRAMX FLOATING [...]

Yeah, I explained why in #1008 (comment). Let me know if that's a deal breaker.

[Rangi42]

This does not implement ROMX/WRAMX FLOATING [...]

Yeah, I explained why in #1008 (comment). Let me know if that's a deal breaker.

Quoting from that:

The semantics of ROMX FLOATING actually kind of suck, because then all assignments in the section have to start somewhere. More useful semantics would be obtained by instead placing all "fully constrained" sections from the object files, processing the linker script (and FLOATING sections would be immediately placed wherever available), and then running the full placement routine with everything remaining.

So, I might be missing something from this. From main.cpp, it looks to me like first the object files are read (including all their SECTION definitions with optional [address] and BANK[num] and ALIGN constraints); then the linker script is parsed (which will agree with or add to the constraints read so far); and then all the placement and checking occurs (obj_DoSanityChecks, assign_AssignSections, obj_CheckAssertions). So I expect ROMX FLOATING to just not do any checking or adding of a BANK constraint on its sections.)

(Just to be clear -- I was expecting ROMX FLOATING followed by "My Section" to be the same as doing SECTION "My Section", ROMX; that does not explicitly make "My Section" have a floating address, it gives all the sections a floating/unspecified bank.)

As far as I can tell, that's doable without meaning that "all assignments in the section have to start somewhere". Please explain to me if I'm still misunderstanding something.

EDIT: After trying to implement this myself and discussing it some more, I understand that the intention is to have one ROMX FLOATING list behave like the proposed #244, placing all those sections in the same bank (and in that specified order/alignment/etc) without defining an exact bank number. This matches my intuition even better of how it ought to work, I just hadn't expected that to be viable. I agree we add it that way, in a later version when we're ready with the right semantics.

[Rangi42]

FLOATING and "Section" OPTIONAL work as expected. 👍 Just needs documentation!

Resolved

[ISSOtm]

OK, I wrote the documentation and pushed it. This makes the PR complete. And as usual for documentation, I'd like to request @aaaaaa123456789's review.

Let's try to aim for merging this in time for Christmas, so we can release on that day? ^^

[Rangi42]

Apart from some phrasing comments, this also does not document the OPTIONAL modifier for section names.

[ISSOtm]

Right; a single sentence stating that "If the section doesn't exist, and error is generated, unless the name is followed by the keyword OPTIONAL." or similar should do the job?

Edited

[Rangi42]

I have no more comments here, everything looks good! 😺 Just need @aaaaaa123456789 to confirm.

[aaaaaa123456789]

All changes so far look OK; I'll review this again when the rest is addressed/closed/ignored.

[ISSOtm]

Done; all of the existing comments should have been addressed.
Merry Christmas!

[aaaaaa123456789]

LGTM