FastBasic 4.6 cross-compiler tips, tricks, quirks, and oddities?

[+yetanothertroll]

1 hour ago, dmsc said:

Note that in FastBasic, taking the address of an array/data/string and storing it in a variable is slower than using it directly. "&STR$" (or "ADR(STR$)") is compiled to just loading the address from the var, just one token.

 

Have Fun!

 

So am I barking up the wrong tree by trying to treat a string as a byte array when I'm using characters in the string in lookup tables and such? Is Len(X$) better than, say, Peek(&X$) and Asc(X$[i,1]) or even Asc(X$[i]) better than Peek(&X$ + i) ? How deep does the optimizer go in the cross-compiler?

[dmsc]

Hi!

4 hours ago, yetanothertroll said:

So am I barking up the wrong tree by trying to treat a string as a byte array when I'm using characters in the string in lookup tables and such? Is Len(X$) better than, say, Peek(&X$) and Asc(X$[i,1]) or even Asc(X$[i]) better than Peek(&X$ + i) ? How deep does the optimizer go in the cross-compiler?

 

String or Arrays store the address of the data in the variable. This means that "$(MYVAR)" is compiled to the same code as "MYSTR$".

 

So:

- LEN(X$) is compiled to exactly the same as "PEEK(&X$)", see https://github.com/dmsc/fastbasic/blob/57031df27402d83d9976104af3ab56915ec2d6c0/src/syntax/basic.syn#L185

- ASC(X$) is compiled to PEEK(&X$+1), see https://github.com/dmsc/fastbasic/blob/57031df27402d83d9976104af3ab56915ec2d6c0/src/syntax/basic.syn#L187

- ASC(X$[N]) is optimized to PEEK(&X$+1+N), but only for constant N, see https://github.com/dmsc/fastbasic/blob/57031df27402d83d9976104af3ab56915ec2d6c0/src/compiler/peephole.cc#L1293

 

The string-indexing operations are relatively slow, they copy the original string to a new place, as they need to construct the new string including the new length at the start.

 

The optimizer is not very good, only performing simple replacements on the generated bytecode. Most of the transformations are done in the parser/compiler, so are shared between the PC compiler and the Atari IDE.

 

You can inspect the generated code to see the bytecode.

 

Have Fun!

 

[+yetanothertroll]

When reading from diskette text files in Atari DOS II 2.0S and 2.5, reading the last line of the file results in error code 3, other times 136, with the last line making it into the string variable apparently unmangled. Is there a reliable way to distinguish the real EOF from a last line that just so happens to be zero length? The error 3 is not seen when reading from cassette.

' Program FBError3

 Input "File?"; F$

 Print "Opening """; F$; """... ";

 Open #1, 4, 0, F$
 e = Err()

 Print "e = "; e

 Do

  If Not (e = 1) Then Exit

  L$ = "#NULL#"
  Input #1, L$
  e = Err()

  Print "e = "; e; " """; L$; """";

  If Len(L$) = 0
   ' no op
  ElIf 1 ' Not 32 < Asc(L$[Len(L$),1])
   Print " "; Asc(L$[Len(L$),1]);
  EndIf
  Print

  If (e = 3) Or Len(L$) Then e = 1

 Loop

 Print "Closing... ";

 Close #1
 e = Err()

 Print "e = "; e

 Print
 Print "OK"

 While Key() : Get X : Wend

 Get X

End

 

 

NB: The Stats Test.atr contains Atari DOS II 2.0S and the Atari Statistics I CX4013 BASIC program. Is this a possible copyright issue?

 

 

Stats Test.atr FBError3.cas FBError3.bas

[dmsc]

Hi!

16 hours ago, yetanothertroll said:

When reading from diskette text files in Atari DOS II 2.0S and 2.5, reading the last line of the file results in error code 3, other times 136, with the last line making it into the string variable apparently unmangled. Is there a reliable way to distinguish the real EOF from a last line that just so happens to be zero length? The error 3 is not seen when reading from cassette.

 

From the Altirra Programmers reference:

- Error 3 ($03): Succeeded with imminent EOF. Returned by DOS if a get request succeeds in its entirety, but the next read is guaranteed to return an EOF.

- Error 136 ($88): End of file. The end of the file or input stream was reached. For the keyboard or screen editor device, this can be forced by a Ctrl+3 key press. CIO does not interpret EOF errors and does not remember the EOF state or close the I/O channel, and depending on the device handler it may be possible to successfully resume I/O after an EOF error.

 

You are using INPUT, this calls CIO to read until an end-of-line ($9b), or the buffer length (128 bytes in FastBasic), or until end-of-file. So, the error returned will be 3 if you read the last line of the file, or 136 if the last line did not have an EOL at the end.

 

In your case, the "CUSTOMER" file does have an "♥" at the end, followed by a EOL, so it correctly returns error 3 in the last line, but your "ORDINARY.TXT" file does not have the EOL at the end, so the last line returns error 136.

 

Have Fun!

 

[+yetanothertroll]

2 hours ago, dmsc said:

Hi!

 

From the Altirra Programmers reference:

- Error 3 ($03): Succeeded with imminent EOF. Returned by DOS if a get request succeeds in its entirety, but the next read is guaranteed to return an EOF.

- Error 136 ($88): End of file. The end of the file or input stream was reached. For the keyboard or screen editor device, this can be forced by a Ctrl+3 key press. CIO does not interpret EOF errors and does not remember the EOF state or close the I/O channel, and depending on the device handler it may be possible to successfully resume I/O after an EOF error.

 

You are using INPUT, this calls CIO to read until an end-of-line ($9b), or the buffer length (128 bytes in FastBasic), or until end-of-file. So, the error returned will be 3 if you read the last line of the file, or 136 if the last line did not have an EOL at the end.

 

In your case, the "CUSTOMER" file does have an "♥" at the end, followed by a EOL, so it correctly returns error 3 in the last line, but your "ORDINARY.TXT" file does not have the EOL at the end, so the last line returns error 136.

 

Have Fun!

 

 

I see, Atari BASIC uses error 3 for "Value error," not imminent EOF. I can kind of see why the cassette handler and perhaps other mass storage devices or for that matter the serial port can't detect or report an imminent EOF, so that's definitely not something to rely on!

 

That NUL is indeed supposed to be there, followed by an end of line. That's how data files used by Atari Statistics I CX4103 are formatted for whatever reason. And that NUL has to be there and has to be followed by an end of line or the program rejects the file, possibly considering it truncated or otherwise corrupted. Why not a checksum or something useful instead of a line with just a NUL? No idea

Edited Sunday at 05:27 PM by yetanothertroll
Transposed digits, not great in either coding or statistics!

[dmsc]

Hi!

8 hours ago, yetanothertroll said:

I see, Atari BASIC uses error 3 for "Value error," not imminent EOF. I can kind of see why the cassette handler and perhaps other mass storage devices or for that matter the serial port can't detect or report an imminent EOF, so that's definitely not

something to rely on!

Atari BASIC and FastBasic share the same errors, as both use CIO and the OS mathpack. The difference is that Atari BASIC does not TRAP on CIO errors less than 128, so you have to check the CIO error in your code, see:

     

 

The program correctly shows that the last line read return the error code = 3. If you try with a file without the last EOL, you would see the ERROR 136:

 

Have Fun!

 

[flashjazzcat]

The salient point might be that imminent EOF isn't really an 'error' at all - more a status code, and any return code that doesn't have bit 7 set (since a negative value denotes an error) can be ignored unless you're specifically looking for the imminent EOF indicator (which not every DOS supports; IIRC, it was only recently that SDX's ATARIDOS.SYS driver implemented it).

 

BMI error, BPL OK, generally speaking.