Hi Boriel,

Changes from Version 1.1.7 to 1.1.9

• ! Fixed a bug for constant string slicing, so
  "0909"(A TO B) now works. Thanks to britlion.
  
• ! Expanded grammar to allow something like "0909"(f)
  or "0909"() which are also allowed in Sinclair Basic. Thanks to britlion.
  
• ! When used expressions like "0909"(f) (like above) might corrupt
  HEAP memory, leading to a program crash. Fixed. Thanks, britlion
  
• ! Fixed a wrong number conversion (type CAST) from signed integers
  to floating point numbers which might cause wrong (random) results.
  
• ! '%' suffix was being ignored.
  
• ! Global string variables were not optimized unless declared
  with '$' suffix. Fixed.

• Bitwise instructions for AND, OR, XOR, NOT
  
• CLEAR to fill memory areas
  
• READ, DATA and RESTORE
  
• SAVE & LOAD

I was playing with some complex code from the "One Liners" stuff. The following program behaves completely differently in basic as opposed to going through the compiler. Actually, it crashes when run compiled. (I tried several different types for f and g). Oddly, at the first PLOT, there appears some other changes to the screen - a few bytes of corruption. Something weird is happening there. There are more brackets than I need - mostly in an attempt to make sure the math functions are coming out clearly. Try it in BASIN and then compile it.

I know the functions are unnecessarily complex. That's the nature of the one liner type code. Nonetheless, it ought to behave when compiled just like the interpreted version. Shouldn't it?

What's new since 1.1.4:

• + Added the ELSEIF construct to the IF THEN ELSE sentence
  
• + Added more optimizations in some jumps
  
• + Added the USR function (both for Strings and Floats). Yes, you can now use USR "a" to get the address of the UDG table (instead of PEEK Uinteger 23675), and also can do RANDOMIZE USR 40000 (if you want to call a legacy machine-code routine; other than that it's useless).
  
• * Optimized some print string generated code (now it's smaller)
  
• ! Fixed many optimization bugs (almost five). Thanks to LCD
  
• ! Fixed ChangeLog file
  
• - Internal refactored code (somewhat)
  
• ! BOLD and ITALIC could not be used as permament attributes,
  only as temporary ones. Now they are allowed as permament.
  
• * Some more syntax compatibility with Sinclair BASIC. Expressions
  like F$(5), F$() or F$(TO) are now allowed. So expressions like PRINT ;;; are.
  
• ! single PRINT sentences were not working (they should print a
  newline).
  
• * Minor grammar corrections.
  
• ! Using a suffix like '$' in a function declaration was being
  ignored. Now this also works ok.
  
• + Added suport for PRINT , (Thanks to britlion and LCD for the
  suggestions and bug detection)
  
• * Fixed a potential optimization bug for SHR and SHL

• Bitwise instructions for AND, OR, XOR, NOT
  
• CLEAR to fill memory areas
  
• READ, DATA and RESTORE
  
• SAVE & LOAD

There are lots of things in the compiler that are mentioned obliquely in changelogs.

Please - at least get the list of reserved words up to date so that we know something is there.

Please, document DIM! This keyword is used in so many different ways - to set types, to dimension arrays, to set constants and to block fill arrays with =>

We're a little in the dark generally - and willing to work with that - but I think I'd like to request documentation and examples for DIM be top of the pile!

Why does

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:

I was rummaging through the .asm code, and I note it's pretty well optimized - though I can see places that could be neater. But that's for another time.

I noticed one of the runtime code blocks was labelled Italics..

So, curious, I tried compiling:

PRINT ITALIC 1; "Italics?"

And it worked perfectly! This isn't documented anywhere! What an awesome little addition to the language.
(It prints the text with the top a pixel to the right and the bottom a pixel to the left, and the middle left alone)

This should probably be added to the reserved words list.

Okay, I confess: I'm not an assembler user. This is why I need a compiler.

That said, I love to nosey into things I don't understand. I often learn from that.

I was looking at an old piece of assembler code I found, when trying (fairly unsuccessfully) to learn Z80 code:

8 Bit number multiply

Rotates Num 1 round to examine it. Rotates Num2 up. Adds HL and DE if the bit is set.
Result is Num1 * Num2 in HL.

LD HL,0
LD DE, (NUM2)
LD A, (NUM1)
LOOP RR A (Divide A by 2 - copying the 1's column bit into the carry flag.)
JR NC, JP1 (Jump over the add if we have to)
ADD HL,DE
JP1 RET Z (Leave when we finish - A has gone to zero)
SLA E }
RL D } Multiply DE*2
JR LOOP


naturally, when I found this again, I couldn't resist comparing it to the 8 bit multiply assembler in the library. I'm not sure which is faster (Boriel's code is a little unclear in the fastcall case which registers are set with parameters; I think it's A and HL tho. I have a suspicion this code is faster, if only because it doesn't loop for a whole 8 bits if A is small - it quits as soon as A hits zero, which might optimize a few loops out.

Anyway, just for your perusal. Like I said, I'm a little beyond my depth on this one; but I love to optimize where I can!

I'm glad LCD mentioned the HISOFT compiler - because I think it does an awesome job. The limitation with it is that it's ON the spectrum, so you need room for basic + compiler + compiled code [though it can be clever and delete the basic as it goes to make more room]. I'm hoping Boriel's compiler will eventually Exceed the speed of Hisoft's - because it can be much cleverer outside the Spectrum than one locked into it!

Not sure whether this is as intended, but it's not quite compatible with Sinclair Basic:

LET K$="1234567890"
PRINT K$(TO 3)
PRINT K$( 3 TO)

All seems to compile - though strings are numbered from 0, whereas Sinclair basic numbers them from 1.

So ZX Basic gives the output:

1234, where Sinclair basic would give the output 123

If the aim is to be able to compile Sinclair Basic, we're not there with that one. (Perhaps a switch, or configurable option?)

Also:

Print K$(3) fails. We would need to use k$(3 TO 3). Is this a bug?

PRINT K$( TO ) also fails, and ZX Basic allows it. It's an unusual corner case, though - it means the same thing as just K$. If it was to be supported for compatibility, a preprocessor tweak ought to be able to optimize it to disappear before the compiler saw it.