Faulty statement that works "correctly" but gives compiler warning

[+DZ-Jay]

I have a statement that prints a GROM solid block card ($5F, or "\95") on the screen and sets the Color Stack Advance flag.  It works correctly, but the compiler gives me a warning.

 

Here is the statement I was using:

Print At ScreenPos(0, 0) Color CS_RED, "\95" + CS_ADVANCE

 

And here is the warning:

Warning: invalid extra characters in line 192, file "demo/vfx.bas"

 

Now, it took me a while to figure out that the correct syntax seems to be:

Print At ScreenPos(0, 0) Color CS_RED + CS_ADVANCE, "\95"

 

This makes sense, since the advance bit is part of the card attributes, along with the colors (indeed, I later saw in the manual that this is how it should be set). 

 

I changed it and the warning is gone.

 

However, I wonder why the first form works at all.  If it shouldn't work, the warning provides no guidance at all.  If it works, then which character is invalid?

 

I imagine that the compiler accepts the string "\95" and decodes it as $2F8 (i.e., the result of "$5F << 3").  It then seems to perform the addition of CS_ADVANCE (which is actually the value $2000) as expected to yield the correct result.  Therefore, the warning is not only unnecessary, but incorrect -- the "invalid extra characters" seem to be quite acceptable to the compiler. 

 

Does anybody (read: @nanochess) now what's going on?

 

     -dZ.

[+nanochess]

There are only two things that the compiler does on a PRINT statement:

 

1. Is it a quoted string? Process the quoted string. Warn of anything else on the same line.

2. Anything else is processed as an expression.

 

So to answer your question "\95" is processed to put \95 on the screen, and then it warns of the remaining invalid extra characters.

[+DZ-Jay]

56 minutes ago, nanochess said:

There are only two things that the compiler does on a PRINT statement:

 

1. Is it a quoted string? Process the quoted string. Warn of anything else on the same line.

2. Anything else is processed as an expression.

 

So to answer your question "\95" is processed to put \95 on the screen, and then it warns of the remaining invalid extra characters.

I get that, but it also evaluates the expression by adding the advance bit, which is the weird part.  I would expect that such invalid characters would be ignore, no?  If they are evaluated, then they are not invalid.

 

Or perhaps I'm missing something?

 

    dZ.

 

P.S. Thanks for responding! 👍🏻

[+nanochess]

28 minutes ago, DZ-Jay said:

I get that, but it also evaluates the expression by adding the advance bit, which is the weird part.  I would expect that such invalid characters would be ignore, no?  If they are evaluated, then they are not invalid.

 

Or perhaps I'm missing something?

 

    dZ.

 

P.S. Thanks for responding! 👍🏻

It doesn't evaluate the expression. Once it detects a lexical component "String" it parses the string, and calls a standard function to check for end of line.

 

Any extra character on a line is flagged with a warning.

 

This way the programmer can detect parts of code that aren't compiling in any way.

 

[+DZ-Jay]

3 minutes ago, nanochess said:

It doesn't evaluate the expression. Once it detects a lexical component "String" it parses the string, and calls a standard function to check for end of line.

 

Any extra character on a line is flagged with a warning.

 

This way the programmer can detect parts of code that aren't compiling in any way.

 

 

Hmm ... Sorry if I'm being dumb, but I am a little confused.  

 

It looks like the CS_ADVANCE flag is being set by that PRINT statement, so it is doing something with it.  That's the part that confuses me -- I wasn't expecting it to work (adding + CS_ADVANCE), but it does.  Maybe you are explaining it to me and I am not understanding it ...

 

 

[+nanochess]

27 minutes ago, DZ-Jay said:

 

Hmm ... Sorry if I'm being dumb, but I am a little confused.  

 

It looks like the CS_ADVANCE flag is being set by that PRINT statement, so it is doing something with it.  That's the part that confuses me -- I wasn't expecting it to work (adding + CS_ADVANCE), but it does.  Maybe you are explaining it to me and I am not understanding it ...

 

 

No, it is not generated.

 

Maybe you put it there with another statement.

 

Here is a wall of code for your enjoyment:

 

	;FILE test1.bas
	;[1] 	CONST CS_ADVANCE = $2000
	SRCFILE "test1.bas",1
	;[2] 	CONST CS_RED = 1
	SRCFILE "test1.bas",2
	;[3] 
	SRCFILE "test1.bas",3
	;[4] 	PRINT AT 0 COLOR CS_RED, "\95" + CS_ADVANCE
	SRCFILE "test1.bas",4
	MVII #512,R0
	MVO R0,_screen
	MVII #1,R0
	MVO R0,_color
	MVI _screen,R4
	MVII #760,R0
	XOR _color,R0
	MVO@ R0,R4
	MVO R4,_screen
	;[5] 
	SRCFILE "test1.bas",5
	;[6] 	PRINT "HELLO"
	SRCFILE "test1.bas",6
	MVI _screen,R4
	MVII #320,R0
	XOR _color,R0
	MVO@ R0,R4
	XORI #104,R0
	MVO@ R0,R4
	XORI #72,R0
	MVO@ R0,R4
	MVO@ R0,R4
	XORI #24,R0
	MVO@ R0,R4
	MVO R4,_screen

 

[+DZ-Jay]

42 minutes ago, nanochess said:

No, it is not generated.

 

Maybe you put it there with another statement.

 

Here is a wall of code for your enjoyment:

 

	;FILE test1.bas
	;[1] 	CONST CS_ADVANCE = $2000
	SRCFILE "test1.bas",1
	;[2] 	CONST CS_RED = 1
	SRCFILE "test1.bas",2
	;[3] 
	SRCFILE "test1.bas",3
	;[4] 	PRINT AT 0 COLOR CS_RED, "\95" + CS_ADVANCE
	SRCFILE "test1.bas",4
	MVII #512,R0
	MVO R0,_screen
	MVII #1,R0
	MVO R0,_color
	MVI _screen,R4
	MVII #760,R0
	XOR _color,R0
	MVO@ R0,R4
	MVO R4,_screen
	;[5] 
	SRCFILE "test1.bas",5
	;[6] 	PRINT "HELLO"
	SRCFILE "test1.bas",6
	MVI _screen,R4
	MVII #320,R0
	XOR _color,R0
	MVO@ R0,R4
	XORI #104,R0
	MVO@ R0,R4
	XORI #72,R0
	MVO@ R0,R4
	MVO@ R0,R4
	XORI #24,R0
	MVO@ R0,R4
	MVO R4,_screen

 

Hehehe, thanks for that.  I guess I did something strange here.  I should have checked the assembled code.  
 

   dZ.

[+DZ-Jay]

Oh my goodness!  I just saw that I had a POKE statement adding the $2000 flag to that card a few lines down.  That was from an earlier debugging code that I forgot to remove.  DOH!

 

😅

 

I feel even more stupid now.   Sorry for the bother, and thanks for the help, Mr. @nanochess. :)

 

      dZ.