Print issues (*fixed*)

[boriel]

Big issue: I notice print doesn't support commas.

Print "1","2" doesn't line up in columns. It won't even compile!

Print "1"+CHR$(6)+"2" does compile, but the print routine seems to ignore the tab.

I'm not sure how to work around this for spectrum programs that format text out in columns, or use commas to hop to the next line.

I forgot to implement the comma. Will try to implement it this evening.

Regarding the tab, it IS implemented (try TAB). If you want to use TAB with char codes, according to the ZX Spectrum manual, it is a 16 bit (two chars) sequence. So TAB 25 is: PRINT CHR$(6) + CHR$(25) + CHR$(0)

The apostrophe (') is also used in the ZX Spectrum, for "newline", but it won't be implemented, since that character is also used for comments. You will have to use CHR$(13) for that.

Optimization freak (I am. If I can save one assembler instruction, that's at least a byte saved!)

I notice that:

PRINT "1";
PRINT "2"

and PRINT "1";"2"

Produce exactly the same assembler code! Bravo. But

PRINT "1"+"2" is quite a lot shorter - the compiler sees it can combine the strings into one label.

True, the latter is preferable when dealing with constants. But the compiler recognizes *every* constant string, and tries a memory optimization for them, mapping the same string constants to the same memory location. Look:

Code:

PRINT "This is a string "; "Hello world"
PRINT "Hello world"

You could optimize this as :

Code:

PRINT "This is a string Hello world" + "Hello world"

But look what it gives in asm...

You will see that in the 1st example, the "Hello world" example has been "compressed". The compiler knows "Hello world" has been used twice and will compile it as if "Hello World" were something like:

Code:

CONST internal1$ = "Hello World" : REM Internal constant string
PRINT "This is a string "; internal1$
PRINT internal1$

Similarly:

PRINT INK1;"BLUE";INK 2;"RED"

is quite a lot longer in assembler than:

PRINT CHR$(16)+CHR$(1)+"BLUE"+CHR$(16)+CHR$(2)+"RED"

Your print routine parses both the above lines identically. The second, while far less decipherable to a human), to the compiler is a whole 14 bytes shorter in the assembler. Given how common print and combined color codes are in code, I suspect there is a notable size optimization that could be made in compiled code.

I will have a look to this. However, direct color codes should be a little faster (some t-states less).

Off this post's topic:
The other one I noticed would be not storing a variable in a register if we don't need to:

Code:

LET A=A+1
LET A=A*2

Does Load, increment, store, multiply, store.

Are you compiling with the -O3 (peephole optimization) flag? -O3 should do what you are suggesting

First up, I noticed it doesn't reload from store in the middle. It also recognizes multiply by two, and does the bitshift. That's very cool. It doesn't need to store in the middle tho!

(Is it worth optimizing double and triple bitshifts for *4 and *8 and so on? These are common multipliers, if only for screen coordinates.)

It should. Either for the division.