Dense placement by linker about rgbds

[aaaaaa123456789]

I'm pretty sure this is a restatement of one of the famous NP-hard problems...

That being said, there are a few slight improvements that can be achieved over a simple "descending order of size" placement:

• Check if a section fits exactly in a "hole" (i.e., available allocatable space). If it does, place it there — it's known to be an optimal solution.
• You might play a bit with the definition of "exactly" there. Perhaps also place immediately sections that leave one byte of slack, or two bytes... those aren't known optimal solutions, but the cases where they aren't optimal are typically artificially constructed.
• If the sum of the sizes of the sections you're trying to assign to a bank is not larger than the size of the bank, but they still don't fit (which can only happen due to alignment constraints), consider shuffling them. For instance, consider the following size@alignment pairs: $2840@1, $11cf@$100, $5b3@$10. If you try to place them in that order in a ROM bank, you'll try to place the first section at $4000, the second one at $6900, the third one at $7ad0, and error out because the bank size would be $40b3 bytes. However, they do fit in the bank: place them in the order first-third-second, and you'll get the first section at $4000, the third section at $6840, the second section at $6e00 and a total bank size of $3fcf.

I'll post more ideas if I have some.

[ISSOtm]

Isn't this bascially an open-shop problem? Nope, as mentioned above, this is bin-packing. See below also. :P

[meithecatte]

If the sum of the sizes of the sections you're trying to assign to a bank is not larger than the size of the bank, but they still don't fit (which can only happen due to alignment constraints), consider shuffling them. For instance, consider the following size@alignment pairs: $2840@1, $11cf@$100, $5b3@$10. If you try to place them in that order in a ROM bank, you'll try to place the first section at $4000, the second one at $6900, the third one at $7ad0, and error out because the bank size would be $40b3 bytes. However, they do fit in the bank: place them in the order first-third-second, and you'll get the first section at $4000, the third section at $6840, the second section at $6e00 and a total bank size of $3fcf.

This is basically sorting by descending alignment. Of course, this breaks down when a section has a fixed address.

Perhaps it would make sense to put the sections in place "hardest first"? We could play with various heuristics for hardness here. For example, the worst-case space required, i.e. alignment + size. A vague notion of "average" space required could be represented with alignment/2 + size.

Alternatively, after each section is placed, find the next section by minimizing the alignment slack required, breaking ties by greatest size first. This has the disadvantage of easily going quadratic without a clever datastructure. Also, I'd think that the high-alignment sections are most often the largest, which would make this strategy leave them for last and then fail because all the ROM space is fragmented already.

Isn't this bascially an open-shop problem?

What would be the workstations, and what would be the jobs? I don't see it.

[ISSOtm]

Stations being the banks and jobs being the sections.

[meithecatte]

Stations being the banks and jobs being the sections.

That would only be the case work if alignment, fixed sections, and any-bank sections weren't a thing. Moreover, only one workstation would have a value greater than zero, reducing this to the bin packing problem.

[ISSOtm]

After more discussion, we will drop this.

• The current behavior is good enough in typical cases; there are typically some small sections that do fit "in the gaps", as you can see. And if there aren't, the programmer should be encouraged to make some (opinionated? Acceptably so imo.)
• Code to find an optimal solution to the bin packing problem would be slow, and I do not want to make most users pay for it, especially in a linker, which is the pass that is always run after every single edit.
• Mitigating the slowness would likely add significant code complexity, and it's unlikely we'd be able to maintain it and make it follow any advances in the field.
• If someone were to absolutely require the optimal solution, they can do it "externally":
  1. Parse all object files to generate a list of sections; this can be done using rgbds-obj, or a custom parser, since the format is simple and well-documented.
  2. Feed that to a problem solver.
  3. From its solution (assuming there is one), generate a linker script.
  4. Pass that linker script to RGBLINK, who will dutifully follow its instructions.