Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Print issues (*fixed*)
#1
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.



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.

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.


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.

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.)
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 2 Guest(s)