Wohoo!! Awesome!!
haha, I know what that weird optimization is. I just forgot to update the message being printed for a couple of patterns haha, my bad! I just pushed a commit that fixes it, when I upload a new version tonight with a few other things I want to add first, that should be fixed
Wohoo!! Awesome!!
haha, I know what that weird optimization is. I just forgot to update the message being printed for a couple of patterns haha, my bad! I just pushed a commit that fixes it, when I upload a new version tonight with a few other things I want to add first, that should be fixed
I tested the latest build and everything works 100%.
Good to know!! Thanks a lot for testing
I am feeling like I am an annoying pest, but I have a new (or maybe not new?) idea. I was doing some optimizations and came across a few data tables that were fully or partially overlapping. I removed two of them and then used another existing table as a partial replacement. So my question is... Is it possible to search for data tables and see if they are fully or partially the same? For example, if HL/IX/etc points to some areas, compare those areas for complete or partial overlapping.
So your suggestion is to move tables and fuse them to gain bytes. Cool, but the optimizer has to check if some of them are aligned, else the code could fail
It happens usually with trigonometric functions where cos and sin tables overlap for a large part
It's an interesting idea! Maybe rather than having the optimizer actually do something, there could be just a suggestion for something to consider by the programmer. There is currently a flag to enable MDL to suggest "potential optimizations" that MDL cannot verify are safe, but the programmer can inspect and decide (-popotential). Maybe something like that could be done?
Thinking about how to detect this, maybe MDL could go over the different data blocks in the code and detect if there is significant continuous overlap, for example as ARTRAG was saying, when the end of the sin table is identical to the beginning of the cos table, and they can be combined into one.
It's an interesting idea! Maybe rather than having the optimizer actually do something, there could be just a suggestion for something to consider by the programmer. There is currently a flag to enable MDL to suggest "potential optimizations" that MDL cannot verify are safe, but the programmer can inspect and decide (-popotential). Maybe something like that could be done?
Thinking about how to detect this, maybe MDL could go over the different data blocks in the code and detect if there is significant continuous overlap, for example as ARTRAG was saying, when the end of the sin table is identical to the beginning of the cos table, and they can be combined into one.
I believe it should be just a suggestion. There is the possibility that a program will have the same tables located in different ROM pages so they must be duplicated. Only the programmer could know that. As an example, MDL could look for DB/DW blocks and see if their bytes overlap. And to be useful a complete table should fit in the other table because it is impossible to split the table in two (except for ARTRAG's example when the end of one table could be the beginning of another). Also, I think this kind of optimization should be done when a program is close to completion because in the early stages many tables can change and if you overlap them it will be harder to adjust the code.
Yeah, makes sense. I am thinking that maybe as a starting point, there could be 3 things that are easy to look for, given two tables A and B (Assuming a "table" is some data block that starts with a label, and ends with another label, for example, and that have at least some minimum size, e.g. 8 bytes (configurable))
- A is contained in B
- The end of A overlaps with the beginning of B (the sin/cos example)
- "A reversed" is contained in B (this happened to me when working on "Tales of Popolon", as I had two tables that were pretty much the same table, but in reverse order! )
Yeah, makes sense. I am thinking that maybe as a starting point, there could be 3 things that are easy to look for, given two tables A and B (Assuming a "table" is some data block that starts with a label, and ends with another label, for example, and that have at least some minimum size, e.g. 8 bytes (configurable))
- A is contained in B
- The end of A overlaps with the beginning of B (the sin/cos example)
- "A reversed" is contained in B (this happened to me when working on "Tales of Popolon", as I had two tables that were pretty much the same table, but in reverse order! )
The reverse one is a good find. But it will require code to be changed in order to get stuff from the table in reverse order.
I think that search should start looking where a label and data are located (DB/DW/DS/ETC...) but finish not on the next label but when you reach a label with assembler code or just assembler code. Because there is a possibility that a block of data has some pointers in the middle of it for various reasons.