Assembler Optimizer

Paragon (1807)

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!

Par Ped7g

Expert (67)

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 ... 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 )

Par santiontanon

Paragon (1807)

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.

Par Ped7g

Expert (67)

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.

Par santiontanon

Paragon (1807)

14-01-2022, 22:14

Glad to help out in sjasmplus

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

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.

Par Huey

Prophet (2694)

25-02-2022, 09:33

Is is also possible to have a Sjasm input file and output the same file in asMSX format?

Par santiontanon

Paragon (1807)

25-02-2022, 15:48

Ah, unfortunately, that is not supported at the moment. It can only translate from a given dialect (e.g., Sjasm, asMSX, etc.) to standard z80 notation. However, for code that just uses basic things like labels and CPU instructions without any assembler specific directives (like asMSX's ".rom", etc.) this should be quite easy to add. I've been wanting to add support for this for a while, so, I'll make a note in my to-do list!

Par santiontanon

Paragon (1807)

07-04-2022, 15:09

Yesterday I released a new version of MDL (v2.4): https://github.com/santiontanon/mdlz80optimizer/releases/tag...

Some of the updates are:
- better support for SDCC/sdasz with a few more patterns and more safety in the optimizations (we iterated a lot with @salute on this to make sure the optimizations generated didn't break his babelz80 project!)
- I added some rudimentary disassembling functionalities (since it was trivial to add, given all the machinery already there). And I disassembled on game with it (a Spectrum game, that I've always wanted to port to the MSX, so, this was my first step: https://github.com/santiontanon/netherearth-disassembly ).
- Lots of small bug fixes, and small improvements here and there (for example, not sure if anyone cares, but I use the -asm+:html flag of MDL a lot for debugging, and I've been improving its output).

Par sergarbes

Expert (115)

07-04-2022, 16:19

I think It's a really good idea!

Par aoineko

Paladin (1004)

30-05-2022, 22:37

It would be great to be able to translate any MSX assembly language to any other.
It's a pity to waste sooooooo much time converting sources manually.

What would be most efficient would be to create an intermediate "universal" format (something scalable like XML), able to store information from any language. Then we would just need to create plugins:
- Importer: Convert a given language into the universal format.
- Modifier: Do some processing on the data in the universal format (optimizer, address shifting, label processing, etc.)
- Exporter: Convert the universal format into a given language.
This way, everything can be combined easily (convert and/or process data).

This is something I had started to do on a completely different subject, the numerous storage formats of hieroglyphs. ^^

MDL should be a good base for such project.