04-28-2009, 10:22 PM
britlion Wrote:Wouldn't it produce faster code to get the preprocessor to do it?Not exactly. The compiler will tray to guess everything at compile time (not runtime). It will guess, f$( TO) --> f$, and will simply ignore the '(TO)' part. The problem with f$(<expression>), e.g. f$(4 + 5*8 - int(sqrt(a))) is it could mean a function call (function named f$) and an alphanumeric variable name f$( x ). But I think it could be done, regardless this little problem: the compiler should be smart enough to do this. I will try to implement it.
That is if the --sinclair flag is on:
turn f$( TO ) -> f$
and f$( 7 TO 10) -> f$(6 TO 9)
before the compiler sees it.
This saves the compiled code from having to make the adjustments at run time, yes?
Quote:Yes - I know, if it's f$(a TO b) - we can't do that so easily, and we'll have to dec the number before we use it; which means that being less compatible will be faster code. But it's a thought to optimization if the string is sliced by constants.That's right. But I wanted to make it FreeBasic compatible. On the other hand, freebasic has a fixed-length string, declared as String(N). We can discuss it in the future, if you find this feature is needed.
You probably can't preprocess f$(7) so easily, because I suspect the preprocessor couldn't know if it's an array or a string variable. In this case, the compiler needs to be able to recognize that's a fair format for string variables, and means a slice of it.
Incidentally, I found out that fixed size strings don't seem to be supported:
The syntactic ambiguity you commented -f$(7)- could be solved by the compiler using semantic information (the variable data type). By default it will take it as a Function call, unless you have previously declared it as an array of strings (using DIM). Function names can also have the dollar sign (it's optional, by the way), for alphanumeric functions.
Quote:Dim a$(10,5) makes a 2D array of variable length strings, not 10 strings of length 5; so you can't access a$(3) as you can in Sinclair basic.That's right. You will have to do something like this:
Code:
DIM a$(10)
FOR i = 0 TO 10 : REM a$ lower bound is 0, higher is 10. Otherwise use DIM a$(1 TO 10) or use the --array-base=1 option.
a$(i) = " ": REM 5 spaces
NEXT i
PRINT a$(3 TO 3) : REM Will try to allow a$(3) in the future
Quote:It's a niggle, but I suspect that there are compiler optimizations that could be made if we know the strings are fixed in length - and, of course, if our aim is ever to be able to straight compile any Sinclair Basic program, it's another incompatibility issue.I will try to implement it. :| But don't know if I could do it. The compiler was targeted at the very first time to game programming (even adventure text games), so I allowed dynamic strings, because having an array of 100 elements of 20 bytes is a waste of memory considering the 48K the ZX has.
Quote:I'm not sure if the compiler should really ever be able to deal with a Sinclair program with no modifications, but it's one possible goal.I try to get closer, but it's almost impossible in some cases. For example, this cannot be guessed at compiler time, so it was to be always interpreted:
Code:
10 LET a = 5
20 LET a$ = "a"
30 IF RND > 0.5 THEN LET a$ = a$ + "+a"
40 PRINT VAL a$
Quote:For the record, Boriel; I come here and post problems and bug issues. It sounds like I only complain.Thanks a lot for your appreciations (really!) . And no problem: I know you are just commenting for improvements. Really, feedback is *VERY* important to me, because many compiler bugs are not detected until someone tries to compile a source code (I've made many many test, but it's not enough; more testing is needed and this is done using it!)
But I'm a BIG fan of the work, I think it's awesome. Don't ever forget that! You've done a fantastic job so far!
BTW: At the moment of writing this, F$(TO) is already done!
UPDATE: Finally I've implemented F(), F(TO), and F(<expression>) for strings. Will be available for 1.1.7