Assembler Optimizer

Página 39/49
32 | 33 | 34 | 35 | 36 | 37 | 38 | | 40 | 41 | 42 | 43 | 44

Por Bengalack

Champion (384)

imagem de Bengalack

29-03-2021, 16:40

SDCC recently turned 4.1.0 and it seems like it has started to generate some parts differently, and my game stopped working with MDL. I finally have had some time to investigate. I found this "po"-replacement which looks a bit dangerous Smile

Por Bengalack

Champion (384)

imagem de Bengalack

29-03-2021, 18:34

(Oh, actually, right side should read "ld bc, (#(_g_ppsPlayerStart))" in case you wonder. I had manually removed the "#" as part of easier spotting the real differences.)

Por syn

Paragon (2043)

imagem de syn

29-03-2021, 23:50

santiontanon wrote:

And one more weird discovery upon comparing the different assemblers, this time something funny happening in tniasm:
- tniam fails to parse lines like this:

ld hl,(10+5)+1

It seems that if the very first character of an expression in an instruction that allows for an indirection is a "(", tniasm already assumes that this is going to be an indirection, and ignores the "+1" when parsing the expression, which then sees as "unexpected extra characters" and fails to parse the line. Funnily enough, this parses fine:

ld hl,0+(10+5)+1

So, now when MDL generates tniasm code, I need to check if the first character of an expression is a "(", and if it is, and MDL knows it is not an indirection, I need to wrap the expression in a "0+(expression)" so that tniasm can parse it. Ow well... hahaha

I discovered a few more interesting differences this weekend (e.g. some assemblers parse 10+"A" fine, while others require you to use single quotes: 10+'A' to recognize "A" as a number. And others even allow you to do 10+"AB", taking "AB" as a 16bit number, while others do not let you do that...), but the tniasm one I found quite funny, since I think it's clearly a bug Smile

You can use just "+" instead of "0+" (its somewhere in the manual) or like 1+(10+5). It's a "bug" because the () indirection support was a hack that was added by user demand. tniASM v1.0 does not have this problem, even tho it supports ()

tniASM's manual is actually very thorough. It should help you implement a lot of things. It also describes treating characters and strings up to 4 characters as numbers.

Por santiontanon

Paragon (1394)

imagem de santiontanon

30-03-2021, 00:02

@Bengalack: oh! thanks for the report! So, the problem is that in the right, it should be "(#g_ppsPlayerStart)" instead of "((#g_ppsPlayerStart))", right?

@syn: Oh, thanks for pointing that out!! I will replace my "0+(...)" trick with a "+". Would you recommend me switching from tniASM 0.45 to tniASM 1.0 in my experiments? or is 0.45 still widely used? I just want to make sure to support the one that is most widespread Smile

Por Bengalack

Champion (384)

imagem de Bengalack

30-03-2021, 07:47

Quote:

@Bengalack: oh! thanks for the report! So, the problem is that in the right, it should be "(#g_ppsPlayerStart)" instead of "((#g_ppsPlayerStart))", right?

This part is handled well by MDL. (i just pointed it out as output in the screenshot was manually fiddled with by me).

The problem is that this part

	ld	c, (hl)
	inc	hl
	ld	b, (hl)

is removed. In the c-code, this is about a pointer to a pointer, that is de-referenced twice. MDL removes the last de-ref.

Por jltursan

Prophet (2505)

imagem de jltursan

30-03-2021, 09:21

o_O'
This is what I call a "Syntax hell"!

"ld bc,((xxxxx))" looks like a pseudo-instruction to me...

Por Bengalack

Champion (384)

imagem de Bengalack

30-03-2021, 09:48

jltursan wrote:

o_O'
This is what I call a "Syntax hell"!

"ld bc,((xxxxx))" looks like a pseudo-instruction to me...

I wonder if you misunderstand? "ld bc,((xxxxx))" is the same as "ld bc,(xxxxx)". That is not the issue here. The issue is that MDL is placing the substitution there in the first place. Left side is original assembly, right side is MDL's assembly. Left side is correct, right side is not.

Por Bengalack

Champion (384)

imagem de Bengalack

30-03-2021, 10:03

Hmm. Maybe you are right! Is that what happens here?

Is MDL trying to add a new instruction here? Not intended of course, but a bit funny. I didn't notice. A double paranthesis for a double de-ref? ha ha. Nice :-)

Por Bengalack

Champion (384)

imagem de Bengalack

30-03-2021, 10:11

Bengalack wrote:
Quote:

@Bengalack: oh! thanks for the report! So, the problem is that in the right, it should be "(#g_ppsPlayerStart)" instead of "((#g_ppsPlayerStart))", right?

This part is handled well by MDL. (i just pointed it out as output in the screenshot was manually fiddled with by me).

And now that I understand what really has happened here... here goes: My previous answer to this, was hung up in the "#"-sign. But yes, you are right, it should be only one parenthesis( #g_ppsPlayerStart).

Usually I wouldn't think of this a problem or symptom as I sometimes use extra parentheses for "inner" calculations myself.

Por santiontanon

Paragon (1394)

imagem de santiontanon

30-03-2021, 19:11

Oh! I see!! Now I understand!!! indeed, that is a bug! the optimization pattern failed to see that in the original "ld hl, (XXX)" there was already an indirection. Noted down to fix!

Página 39/49
32 | 33 | 34 | 35 | 36 | 37 | 38 | | 40 | 41 | 42 | 43 | 44