Please enable JavaScript to view this site.

A-Shell 6.5 Development Notes

Compiler edit 891: Add new pragma.

++PRAGMA AUTO_LARGE_CONSTANTS <boolean>

As with most other ++PRAGMAs, the <boolean> argument is optional, defaulting to TRUE if not specified.

This pragma causes the compiler to automatically supply the "L" suffix to any integer constant (in any DEFINE or other statement), as "appropriate". By "appropriate", we mean whenever the constant is too large to be perfectly represented as an F,6 without possible loss of significant digits, and not too large to be stored as a 48 bit integer.

For background, A-ShellBASIC normally stores constants in either 2, 4, or 6 byte floating point representation, as needed for accuracy (and for compatibility with AlphaBASIC). But the F6 format can only handle 11 significant digits before you start to risk losing precision. For example, the constant 9999999999999 (13 9's) may well get approximated as something like 10000000000000.00000001 and get treated as 10000000000000 for printing and other purposes. To avoid this, for integer constants with between 12 and 14 digits, you would be better off storing them in the 48 bit integer format.

A-Shell since 6.3.1516 and compiler edit 763 has allowed explicit specification of the 48 bit integer format for literal contants by specifying the "L" suffix, or in a DEFINE statement using &h or &o notation. And that remains the recommended approach, for clarity. But in cases where you aren't sure if you have such constants, the ++PRAGMA AUTO_LARGE_CONSTANTS will use the 48 bit format for those cases where it will improve precision.

Note that this does not apply to literal values with explicit decimal points, or to those too large to fit in the 48 bit integer format. (In that case, it's better to approximate the value as a floating point, possibly resulting in a +1/-1 rounding error, than to have the value wrap around, resulting in apparent garbage.

Also note that for positive values, the compiler assumes you intend to use it or store it as an unsigned value, so it sets the upper limit at 2**48-1. For negative values, the limit is 2**47-1. If you have positive literal values between 2**47-1 and 2**48-1 which may end up getting stored in the I6 format, you may want to explicitly specify a trailing decimal point to force the value to be stored as a floating point, rather than risk the wraparound problem.