Re: modified reverse
- Posted by Robert Craig <rds at RapidEuphoria.com> Aug 07, 2001
- 492 views
rforno writes: > Rob, I do not understand. floor(anything) should > always be an integer. floor(1e12) produces a "mathematical integer" but does not produce a 31-bit "Euphoria integer". > It seems that x being an > integer does not matter. In order to generate fast C code, the Euphoria To C Translator tries to determine at translation time whether an expression must always produce a 31-bit "Euphoria integer". In a for-loop, for i = start to limit by increment do ... the translator will output much better C code if it can "prove" to itself that start, limit, and increment are always going to be 31-bit integers, whenever this loop is started. This is easy when they are all variables that have been declared as "integer". It gets harder when you have expressions involving function calls etc. The interpreter will also speed up very slightly when things are clearly integers. If x is a 31-bit Euphoria integer then floor(x/2)+1 will always be a Euphoria integer, but the translator currently won't recognize this pattern. It does recognize simpler patterns, for instance it assumes that built-in functions, such as length(), getc(), peek(atom), ... etc. always return a Euphoria integer. Note that, in general, x+1 can't even be assumed to produce a Euphoria integer, but a statement like: x = x + 1 can be done using an integer calculation because you have declared the target, x, to be an integer. The translator assumes that your code contains no type errors or other errors that the interpreter can catch. It will assume that for-loop start, limit, and increment values are at least atoms, if not integers. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com