STR$ in BASIC VI not following the documentation
Michael McConnell (8708) 11 posts |
According to https://www.riscosopen.org/zipfiles/platform/common/BASICRefManual.3.pdf?1613981974 STR$ should behave as if @% is &0A00 if the top byte isn’t set to 1. However, and my apologies if I am referencing out-of-date documents, the behaviour within BASIC VI is as if @% is &1100 rather than the documented &0A00. There’s a discussion over here https://distillery.matrixnetwork.co.uk:3004/discussion/10/what-is-the-correct-behaviour-of-0 concerning the behaviour of @%, and I was rather surprised to discover how inconsistent RISC OS is with itself, let alone other implementations of BBC BASIC! |
David J. Ruck (33) 1585 posts |
I would say on any version of BASIC; do not rely on the default output formatting, and specifically request the formatting you require. |
Martin Avison (27) 1479 posts |
Do you really mean that? The second byte &11 is decimal 17, but it should only have values of 1-10, giving the digits in General format, or significant figues after decimal point in Exponent format, or number of digits after decimal point in Fixed format. A code snippet to illustrate your problem would help. |
Michael McConnell (8708) 11 posts |
|
André Timmermans (100) 648 posts |
According to page 367 of that manual: The optional + sign is a switch affecting the STR$ function. If supplied, it forces |
Michael McConnell (8708) 11 posts |
@Andre Timmermans: |
Richard Russell (1920) 95 posts |
@% = “+G0.10” is the same as @% = &01000A00 (i.e. 10 significant figures), is it not? I agree with Michael that the behaviour of BASIC VI (i.e. BASIC64) in producing a value with 17 significant figures seems incompatible with this documentation. |
Martin Avison (27) 1479 posts |
Sorry – I missed the BASIC VI – and there was no mention of floating point. |
Jeffrey Lee (213) 6048 posts |
I’d say this is a documentation error – when BASIC VI was introduced the manual wasn’t updated properly to reflect all the changes. Subsequent updates to the manual have improved things a bit, but it looks like some differences in @% and STR$ still got missed. E.g. for @% the documentation says “Byte 2 (yy), which can take values from 1 to 10, determines the number of digits printed” – 10 digits is the BASIC V limit, not the BASIC VI one. |
Michael McConnell (8708) 11 posts |
Also – (and I think it’s related to https://gitlab.riscosopen.org/RiscOS/Sources/Programmer/BASIC/-/commit/99e7d1205f6e7e981672b23e5257d64ee528c360 ) setting @% to &Bxx appears to be valid in newer builds of the BASIC module. (I’m currently running V1.84 of both BASIC V and VI.) |
Jeffrey Lee (213) 6048 posts |
Very true – I increased the limit from 10 to 11 for BASIC V because 10 was too low for all numbers to have a unique decimal representation. I’ll put together a list of corrections for the manual. |
Michael McConnell (8708) 11 posts |
Taking a further look at this, the documentation states (page 368 in the PDF linked in the original post) the precision can take a value 1-10. We’ve established already that 11 is valid for newer BASIC V and 17 for BASIC VI. However, a value of 0 isn’t mentioned (thus probably “illegal”), but across the board all the way back to the BBC Micro, and in RISC OS BASIC V and VI it has the effect of using the maximum available precision. Is this by chance or by design, and if it is by design, surely this should also be documented as such? Indeed the string parser is quite happy to translate “G0.0” to @%=0. |
Jeffrey Lee (213) 6048 posts |
There is explicit code to handle that case – but without checking for similar code in the 6502 source, it’s hard to say whether it’s by design or just copying a side-effect of the 6502 implementation. TST FDIGS,#255 BNE FCONA TEQ FMAT,#2 ORRNE FDIGS,FDIGS,#MAXDIGS ;if not in format 2 use maximum digits instead of 0 FCONA ; ... remainder of code here (format 2 == ‘F’) |
Michael McConnell (8708) 11 posts |
That gave me a good pointer of what to look for. From Jonathan Harston’s disassemblies of 6502 BASIC 2, we have:
BASIC 1 has similar (but it’s less commented, and maxes at 9 digits instead of 10):
So it does look like this is intentional behaviour, rather than a side-effect that happens to work. |
Stuart Swales (8827) 1323 posts |
This from CMOS BASIC (see https://github.com/stardot/AcornDmosBasic/blob/master/src/DBAS07): FCON LDX VARL+2 ;flag forcing E CPXIM 3 BCC FCONOK LDXIM 0 ;Default to G format FCONOK STX WORK LDA VARL+1 BEQ FCONC CMPIM &0A BCS FCONA ; In G,E formats varl is no. of sig figs >0 ; In F format it is no. of decimals and can be >=0 BRA FCONB FCONC CPXIM 2 BEQ FCONB FCONA LDAIM 10 ;enter here for str$, having set work to 0 FCONB STA WORK+1 |