Assembler Optimizer

Page 49/58
42 | 43 | 44 | 45 | 46 | 47 | 48 | | 50 | 51 | 52 | 53 | 54

Par thegeps

Paragon (1251)

Portrait de thegeps

01-06-2021, 19:22

Yep, MDL is great!
I've applied almost all the optimization found on output file created with >output.txt
except the "jr to jp" in not critical code (if speed no needed, I'm fine with more free bytes)

Par Ped7g

Expert (67)

Portrait de Ped7g

16-07-2021, 09:52

santiontanon: sorry for not trying myself (too lazy to set up mdlz80 locally), but yesterday I was trying to improve sjasmplus with some interesting snippet of source, and I was wondering what your optimiser would see in such case.

The somewhat tricky source:

  org 0x4000
  disp 0x10000-this1+zac1 ; should become 0xFFFF to produce code "at end of RAM"
  org 0x4000+this1-zac1 ; this should be 0x4001, after the displaced block

The tricky part for sjasmplus 1.18.2 is, that during first pass the symbols are undefined and first DISP does then calculate address as 0x10000, that's first value for `zac1` symbol, then the `nop` wraps around in 16bit device-memory space and lands to 0x0000 and `this1` becomes 0x0001.

So in second pass the DISP goes 0x10000-1+0x10000 -> 0x1FFFF and the symbols get reassigned again to unexpected values 0x1FFFF and 0x0001 or 0x10001 (not even sure, but still way apart), and so on.

In third pass the v1.18.2 will exit with fatal error in device-memory mapping, because of those symbols spanning across ~64ki, making the ORG to try to set negative address -48ki - which hasn't been checked on the ORG implementation level before fix.

Took me some time to realise how to fix this and make it work internally as expected by original author of that snippet... Big smile

The solution is to crop ORG/DISP arguments to uint16_t (with warning, if such cropping happens in third pass), so in the second pass the DISP does set address 0xFFFF instead of 0x1FFFF, then the redefined second-pass values set the symbols to expected 0xFFFF and 0x10000, and the rest of the source then makes sense and there's no issue with further ORG.

The funny part is, that some of this is induced due to "DEVICE" doing that 16bit address space constraint and causing wrap-around. Contrary to that the code snippet works well in non-device mode with `--longptr` option, as then symbols are 1 byte apart already after first pass, and the second+ pass will produce expected values. I guess your optimiser may fall rather into this category, working without any issue and producing expected result. (if you even do bother to calculate symbol values, I'm not sure .... I'm not sure why I'm even posting this, I just found that problem interesting, and I hope it will somewhat amuse you Smile )

Par santiontanon

Paragon (1831)

Portrait de santiontanon

16-07-2021, 14:41

Oh, very interesting test case! This actually fails!

If you rewrite the "disp" line like this: disp 0x10000-(this1-zac1) (which is equivalent), then MDL produces the expected addresses and everything works well. But in the way it is written above it fails!

This is because MDL uses "lazy evaluation", and only evaluates the labels when needed, because of that, evaluating " 0x10000-this1+zac1" creates a circular dependency (we need to know the value of "this1" to evaluate "this1"). I have a special case for when you have things of the form "this1-zac1", where we don't really care about the value of "zac1", just the difference between "zac1" and "this1". But in the way the expression was written, MDL was not recognizing that special case! I'll have to improve my special case handling to correctly parse this case!

Par ToriHino

Paladin (925)

Portrait de ToriHino

16-07-2021, 16:23

One other (very minor) thing, one of the sources I tried MDL on contained the following part:

  ld   a,r
  ld   h,a
  ld   a,r
  ld   l,a

Probably not the best code Tongue, but this is detected by MDL as 'Remove duplicate ld a,r (2 bytes, 11 t-states saved)', while actually r will have a different value the second time.

Par santiontanon

Paragon (1831)

Portrait de santiontanon

16-07-2021, 17:12

oh, good catch! This is easy to fix, I'll add a note to fix for the next version. Thanks ToriHino! Smile

Par albs_br

Champion (499)

Portrait de albs_br

27-09-2021, 15:15

Has anyone already tried this optimizer with the output generated by SDCC (or any other C compiler)?

Par Bengalack

Paladin (802)

Portrait de Bengalack

27-09-2021, 15:33

Yes we have (should be a lot of info in this thread about it).

Par santiontanon

Paragon (1831)

Portrait de santiontanon

27-09-2021, 15:34

Yes! I only used a couple of SDCC examples to work on optimization patterns specific to SDCC code though, so it might not be as great as it could be. But SDCC/sdasz80 syntax is indeed supported Smile

If you want to try it, just make sure to use the "-dialect" command line flag to select "sdcc" (or "sdasz80")

Par max_iwamoto

Paladin (673)

Portrait de max_iwamoto

02-11-2021, 15:56


I have been following the project for a while but had never actually used it until yesterday.

I am using TNIASM and it is listed as a supported assembler. But after I execute the optimizer every time it exits with errors.

The things that it doesn't like are "%res8" / "%res16" and PHASE/DEPHASE... Is it happening because those features are not supported or am I doing something wrong? And is there any way to skip those errors?

Par Uninteresting

Champion (366)

Portrait de Uninteresting

02-11-2021, 22:39

I know TNIASM's last free version and the paid version have big differences. Those keywords sound like they'd be used in the paid version?

(Basically, I'm not sure if the optimizer recognizes the freeware or the paid version, and I didn't feel like going through all the 49 pages to check if this has been mentioned there.)

Page 49/58
42 | 43 | 44 | 45 | 46 | 47 | 48 | | 50 | 51 | 52 | 53 | 54