Assembler Optimizer

Page 16/18
9 | 10 | 11 | 12 | 13 | 14 | 15 | | 17 | 18

By Metalion

Paragon (1149)

Metalion's picture

28-07-2020, 19:13

Even with -dialect sjasm I still have errors.
I think your parser has some trouble handling spaces/tabs and their combination.

line:
MAIN	call	GAME

errors:
ERROR: parseRestofTheLine: Cannot parse line main.asm#36: MAIN	call	GAME

I do not have any project on line.

By santiontanon

Paladin (1013)

santiontanon's picture

28-07-2020, 21:33

Ah!! interesting line indeed!!

It's not the spaces/tabs. That is handled fine. The problem is that MDL's parser is thinking that the line is a macro call with a macro called "MAIN" and a parameter "call". Because the label does not have a colon. Since sjasm parses this line fine, I am making a note to allow this line when dialect is sjasm! We were just talking about this yesterday in another thread. Labels without colons lead to very ambiguous syntax and each assembler disambiguates in its own particular way. But this is very useful! Since my work is to figure out exactly the way in which each assembler disambiguates each of these cases, to mimic it in MDL Smile So, finding these cases where I got it wrong is great!

I would be curious to see the line that causes that exception btw if you don't mind sharing!

By Metalion

Paragon (1149)

Metalion's picture

29-07-2020, 09:13

santiontanon wrote:

I would be curious to see the line that causes that exception btw if you don't mind sharing!

Hi Santianon,
I cannot tell you which line caused the exceptions in the command window because, unless I'm mistaken, I cannot see a line reference in the error messages. Do you see one ?

By santiontanon

Paladin (1013)

santiontanon's picture

29-07-2020, 18:12

MDL crashed there, so, indeed there is no error line. But there are hints (that probably only I can recognize haha) in that earlier error where MDL believes "speed_max" is undefined, and that the error happened in the "instantiateMacro" function of the SjasmDialect class, which means that was during the expansion of a "repeat" macro (which is the only sjasm-specific macro I currently have implemented). So, probably if there is any "repeat" that involves "speed_max", that'll be where MDL had troubles Smile

In any case, I have just added some check around the line where the exception was thrown to capture the case where that null pointer exception can happen and give a meaningful error with an assembler line number. This together with many other improvements I have been working on will be added to the next alpha version!

Again, thanks a lot for testing, and please bear with me until MDL becomes robust enough, it's been only about 5-6 weeks since I started coding it, so it's still definitively rough Smile

By Metalion

Paragon (1149)

Metalion's picture

31-07-2020, 10:09

The speed_max symbol is used in different files, so here is the compilation of lines where it appears :

  compute.asm (3 hits)
	Line 473: [speed_max]	byte	-(%+1)*(@#-8)*(centrifuge/8)/speed_max
	Line 473: [speed_max]	byte	-(%+1)*(@#-8)*(centrifuge/8)/speed_max
	Line 474: [32-speed_max]	byte	0
  game.asm (6 hits)
	Line 25: speed_max    = 31	; vitesse maximale [0,31]
	Line 60: go	cp	speed_max*4
	Line 62: 	ld	a,speed_max*4
	Line 153: repeat	speed_max
	Line 154: 	byte	(@#+1)*slide/speed_max,-(@#+1)*slide/speed_max
	Line 154: 	byte	(@#+1)*slide/speed_max,-(@#+1)*slide/speed_max

By santiontanon

Paladin (1013)

santiontanon's picture

31-07-2020, 17:28

I see, interesting, thanks a lot! I'll check if there is anything funny in the parser with any of these cases. I suspect that the problem comes from the fact that when selecting "dialect -sjasm", I turn the parser into "eager mode" instead of the "lazy mode" (the default). In eager mode, the parser expands the macros right away, as they are being parsed, and thus, all constants involved (like speed_max) need to be defined by the time the macro is parsed. Maybe compute.asm is parsed before game.asm, and thus it is not yet defined. This should not be a problem though. So, maybe I need to make my "eager mode" a bit less eager Smile

I'll investigate, thanks a lot again for sharing! (the other problem you mentioned above is already fixed, and should work well in the next release of MDL!)

By Metalion

Paragon (1149)

Metalion's picture

31-07-2020, 17:42

santiontanon wrote:

Maybe compute.asm is parsed before game.asm, and thus it is not yet defined

No, if MDL follows the "includes" as they are coded, then "game.asm" is parsed before "compute.asm".
Otherwise, sjasm would not let me compile the code, as the label would be used before being defined.

No problem for sharing, I'm really eager to see MDL work on my code.

By mzoran

Resident (57)

mzoran's picture

01-08-2020, 09:41

Any chance you could support hex numbers in the form &ff like in built in assembler of winape emulator?

By santiontanon

Paladin (1013)

santiontanon's picture

01-08-2020, 18:36

@Metalion: with the lines you shared, I was able to create a test that reproduces the crash you report! So, I can now debug it Smile Should be fixed later today!

@mzoran: of course! Something that would help me a lot is if there is any available winape-format project available online somewhere, so, I can test with it, and I could add it as another supported dialect.

By mzoran

Resident (57)

mzoran's picture

01-08-2020, 19:31

try my own code at
https://github.com/zmajcenic/Subcommander
I was curious what will be optimized but didn't get very far

Page 16/18
9 | 10 | 11 | 12 | 13 | 14 | 15 | | 17 | 18