Assembler Optimizer

Page 56/56
49 | 50 | 51 | 52 | 53 | 54 | 55 |

By santiontanon

Paragon (1568)

santiontanon's picture

14-01-2022, 03:27

Ah, and mystery of the jerky scrolling solved too! There was a typo in an optimization pattern that caused a wrong optimization. I just fixed it and updated the pre-release (same link as above).

The optimized binary with "-po" works fine now!

By Ped7g

Resident (44)

Ped7g's picture

14-01-2022, 09:29

santiontanon wrote:

I've been looking at this, and I think I know the problem! It seems that even when using the "--longptr" option, sjasmplus clamps all the addresses at "1MB".

That shouldn't be the case? I will take a look into source, what is happening, but the internal expression evaluator is 32bit and --longptr shouldn't be limited to anything extra on top of that IIRC. Doesn't remind me of anything.

But the ROM is 2097152 bytes long and the ds in source is only $100000...

after few minutes of looking at "$" value through the asm file after each "dephase"... that's definitely working in some way I don't expect and understand, seems maybe something about DS inside phase block may actually affect also "physical" pointer or whatever...

smells like bug in sjasmplus, I will spend more time on it to either explain + document it, or fix it, but right now I didn't manage to understand what is happening in that source.

(btw "the project" does assemble from the bundled v1.14.3 up to 1.18.3 without any change, only my WIP version is now refusing to assemble it due to double-directives in that special case Smile ... so 1.18.4 will break it ... but if this is some bug with --longptr, then I'm afraid this may produce even wrong ROM after fixing sjasmplus... :/ not happy about those, but bugs should be fixed Smile )

By santiontanon

Paragon (1568)

santiontanon's picture

14-01-2022, 13:04

If it helps, when I was looking into it I found the exact place in the source where the $ variable wraps around when building with sjasmplus:
- If you print "$" right before line "; block $80", you have $ = 0x00064000
- If now you print it just a few lines below, right before line "; block $81", you have $ = 0x00006000

So, it looks like the "dephase" in line 6563 is carrying over the address from inside of the dephase, to outside (since $ right before that dephase is also 0x00006000). I do not see anything weird in those lines, but maybe something to consider is that the line "ds $6000-$,$ff" just before that dephase is peculiar as $ is exactly $6000 here, and hence, this line is in fact a "ds 0,$ff". So, not sure if that 0 is causing troubles.

By Ped7g

Resident (44)

Ped7g's picture

14-01-2022, 20:37

it's the `DS` for negative/zero length truncating end-addresses to 16b, even in longptr mode.
After DS fix "the project" needs the final DS to be `ds $200000 - totallenght` and fixes of those double-directive lines and that's all, after patching these few lines, it will build the same ROM file. So it somehow didn't affect anything else important, except the final DS to fix cartridge size. I feel a bit uneasy about that, as it could have affected so much more, but I verified with three different diff checkers that the files are identical, so I guess they are.

Thank you for reporting this, so that's unfortunately another quirk .. which will be fixed in next release of sjasmplus.

(EDIT: you can track the current-address even inside phased blocks by `DISPLAY __LINE__," phased: ",/A,$," physical: ",/A,$$$`
if you will do that for example around that DS in block $80 (line ~6560), it will output in 1.18.3:
> 0x19A3 phased: 0x6000, 24576 physical: 0x66000, 417792
> 0x19A5 phased: 0x6000, 24576 physical: 0x6000, 24576
dephase just throw out phased address and "returns" to physical one, but that's now damaged by &= 0xFFFF; after doing DS with length <= 0)

EDIT2: but DS 0 is valid in sjasmplus, it's just "no op" then (after fixing the longptr case to not modify addresses). It's intentionally valid so it can be easily used to pad data to particular size, even if they are already of that size.

By santiontanon

Paragon (1568)

santiontanon's picture

14-01-2022, 22:14

Glad to help out in sjasmplus Smile

And indeed, I'm now considering whether I should add that "quirk" to MDL or not... for now I'll not add that quirk since it does not prevent MDL from generating optimizations for the project (it just generates a wrong binary). But if it becomes necessary for any other code base, I'll consider it Smile

All of these changes are incorporated into the latest 2.3 release: https://github.com/santiontanon/mdlz80optimizer/releases/tag...

It also includes a new experimental "data optimizer" (-do) (which just generates hints, it does not actually do any changes). It looks for replicated blocks of data in the ROM to identify potential reductions.

Page 56/56
49 | 50 | 51 | 52 | 53 | 54 | 55 |