Assembler Optimizer

Pagina 49/49
42 | 43 | 44 | 45 | 46 | 47 | 48 |

Van thegeps

Paladin (849)

afbeelding van 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)

Van Ped7g

Resident (35)

afbeelding van 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:

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

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 )

Van santiontanon

Paragon (1433)

afbeelding van 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!

Van ToriHino

Paladin (719)

afbeelding van 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.

Van santiontanon

Paragon (1433)

afbeelding van 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

Pagina 49/49
42 | 43 | 44 | 45 | 46 | 47 | 48 |