What would AArch64 BASIC look like?

There was a book that I found really interesting, containing a commented disassembly of BASIC on the BBC B microcomputer. I think there were two authors but I cannot remember the name(s). It was published by the same press that brought out other books and manuals for Acorn. I am sure it contained more about BASIC than the user guides. Sorry about the poor memory.

Some details here: https://en.wikipedia.org/wiki/BBC_BASIC#Platforms_and_versions

Look also at the Docs folder of the BASIC source for 04versus05, BlackLog, and Changes. And, of course, the CVS/Git history.

If you want a more comprehensible and accurate summary of all the things that have changed in BBC BASIC over the years, I would recommend reading Appendix I of the BBC BASIC Reference Manual (Issue 2, October 2017). Many, many hours of time was spent sorting through everything that’s changed to make this as accurate as possible, and individual keywords in the manual also have sections noting which versions introduced changes.

Sadly the 32016 BBC BASIC manual over on Chris’ Acorns (http://chrisacorns.computinghistory.org.uk/docs/Acorn/Sci/AcornScientific_BBCBASICRM.pdf) is borked. That one would have been somewhere between the Master and Archimedes in functionality. I don’t think it was supposed to see the light of day, Cambridge Workstation trying to be all professional, but we got the MoD interested somehow (used for choosing sites for Rapiers in the Falklands)

Anyone else remember the error: “BASIC tried to die, but Tiny Kernel wouldn’t let it”

Versions between 1.19 and 1.34 differed between the Select fork and RISC OS 5 but after version 1.34 (Select 4) the RISC OS 5 version is the definitive one. Appendix I neatly sidesteps that.

This link seems to work for the 32016 BBC BASIC manual: https://acorn.huininga.nl/pub/docs/manuals/Acorn/32016%20Second%20Processor/AcornScientific_BBCBASICRM.pdf

This link seems to work for the 32016 BBC BASIC manual: https://acorn.huininga.nl/pub/docs/manuals/Acorn/32016%20Second%20Processor/AcornScientific_BBCBASICRM.pdf

Thanks for digging that out. Looks like this was the first one with CALL (MOS routine) emulation. I wonder whether the changes made to BASIC for the hard-float variant (Bas32f?) were ever documented?

This link seems to work for the 32016 BBC BASIC manual: https://acorn.huininga.nl/pub/docs/manuals/Acorn/32016%20Second%20Processor/AcornScientific_BBCBASICRM.pdf

This website is a very good source of informations :)

re Basic specification: the book ‘BASIC ROM user guide’ by Mark Plumbley contains a Backus-Naur syntax definition (p.319). Moreover, it details ROM routines for the various BASIC routines, BASIC stack, expression evaluation etc. etc. for 6502 BASIC. It’s available as one of the 55 books on one DVD from www.dragdrop.co.uk. Whether it’s a specification by way of afterthought or not, does not matter: it elucidates perfectly the inner workings of BASIC, and anyway you have to add the newer commands yourself and devise some statemachine to process (the levels of) multiline statements like REPEAT, WHILE. The various newer BASIC manuals could be used to reverse-engineer things; especially the CALL statement for memory organisation. All ‘imho’.

re Basic specification: the book ‘BASIC ROM user guide’ by Mark Plumbley contains a Backus-Naur syntax definition

Thanks. I knew I had seen that, but among more than 30 books of the period I do not have that one. I have bought the CD, so it will be interesting to look at.

As an aside, while rummaging through the books I came across the BASIC Extensions ROM. The program structure enhancements had some features that were never included in ARM BASIC.

The various newer BASIC manuals could be used to reverse-engineer things; especially the CALL statement for memory organisation. All ‘imho’.

There is a fair amount of reverse engineering in my BASIC StrongHelp manual, and even more within Basalt. ;-)

Versions between 1.19 and 1.34 differed between the Select fork and RISC OS 5 but after version 1.34 (Select 4) the RISC OS 5 version is the definitive one. Appendix I neatly sidesteps that.

That’s a good point, although I’m not sure whether there’s any information available about what changed in the Select fork. Were there any notable changes to BASIC? I’ve done a bit of Googling but can’t find anything.

a Backus-Naur syntax definition [of BASIC II]

I was intrigued by this, so did some studying. Taken as it stands it does not really comply with BNF, and even if it did, it does have quite a few typing errors.

Well, that set a challenge to do better, but I did not realise what I was letting myself in for.

The result is a definition of the grammar of BASIC V as in the latest manual. It is quite extensive, even without dealing with assembler. ;-)

I have chosen to use ISO Extended Backus-Naur Form (EBNF), and so that I could check it I have also written a generator to convert the syntax to a parser, and a test program to use the parser. All that is at http://www.kappa.me.uk/Miscellaneous/swParser010.zip.

I still have to extend it to take a BASIC text file and check it as a whole, but I would be interested in comments from those who can understand what I have done so far.

Whatever, it has been like tackling a giant prize crossword, and very entertaining.

Nice work!

Now you have the fun of playing spot the difference between the spec/manual and reality ;-)

E.g. “.E”, “.E+”, “.E-” are all valid real numbers, which cause fun complications when used in expressions (Want to add some numbers together? “.E+.E” won’t work, but “.E +.E” will, along with “.E++.E”, and “.E-+.E”, and “.E+++.E”)

There is quite a bit of juggling going on already, but your example has caught me.

The most head-scratching I had was over how PROC/FN names with @ and keywords in them work, although that is commented out for the time being, because all keywords have to be checked.

I more or less gave up with PRINT. ;-)

Do let me know of any more.

Brilliant!

Steve, could you give a short example or two of how to use Files.Test?

Either I’m using it wrongly, or it is broken?

When asked for a symbol to test, I entered “num-exp”.
When asked for a definition, I entered “DRAW” and “END”. Both pass, as both have num-exp in the definition?
But entering “LIBRARY” and “ENDPROC”, also passes. Uh…?

At this point, entering random four letter words best not reproduced here, also reported “Passed as XXXX” so… um…?

Doing it the other way around (symbol = FOR, definition some code with a FOR in it) reports a problem with the symbol. Always.

Either I’m using it wrongly, or it is broken?

You have not noted my comment above that keyword checking in names is commented out. So DRAW END etc are recognised as valid variable names. If you really want to, go to the Syntax file Identities section and comment out the ‘simple’ line and uncomment the ‘tricky’ lines, Generate the Parser and then try the keywords again. Let me know how you get on. The Parser will have very big FNs checking for each of the keywords in turn. ;)

The Parser and Test are quite elementary and not of end-user grade. They will not stand much stress.

As far as I can see, one cannot actually make a parser from only EBNF, because that just tells you whether something has the right syntax. I was looking at the example of

IF A = 0 THEN IF B = 0 THEN C = 0 ELSE D = 0

which Rick points out ABC gets wrong. There must be some extra information to plug in because the EBNF doesn’t distinguish between the two interpretations.

Steve, could you give a short example or two of how to use Files.Test?

Rick has just supplied an example, but here is another.

First open the BASIC manual at ‘COLOUR’, because you will need it for all the possible parameter combinations.

At the ‘Symbol to test ?’ prompt input ‘colour-s’ to test the COLOUR statement.

At the ‘Test definition ?’ prompt input ‘COLOUR 1’ the simplest statement.

Continue to input ‘COLOUR’ with combinations of parameters with OF ON TINT etc.

Let me know if you find a valid combination that does not pass. ;-)

Note that the Syntax is not complete, particularly FNs are not dealt with in expressions.

Symbol statement with test COLOUR 1 doesn’t pass

Let me know if you find a valid combination that does not pass. ;-)

How about invalid combinations that pass?

Symbol to test  ?colour-s
Test definition ?COLOUR NEXT FOR END 2020 IS A CRAP YEAR I WANT MY MOMMY WAAAAH
Passed as        COLOUR NEXT
Test definition ?COLOUR COLOUR
Passed as        COLOUR COLOUR
Test definition ?COLOR 1
Failed in        COLOR 1

Hmmm, thus it passes obvious crap that BASIC would reject (statements cannot be assigned as variables!) and faults the American misspelling that BASIC accepts (as is noted in your own StrongHelp manual ;-) ).

As far as I can see, one cannot actually make a parser from only EBNF

Very true. My use of the term Parser is misleading.

because that just tells you whether something has the right syntax.

Yes. That is “all” it does.

I was looking at the example of IF A = 0 THEN IF B = 0 THEN C = 0 ELSE D = 0
which Rick points out ABC gets wrong.

It does not get it ‘wrong’. That is what the ABC dialect does and it is documented.

The IF line is valid in either dialect, but does diferent things.

There must be some extra information to plug in because the EBNF doesn’t distinguish between the two interpretations.

No, because it is valid ARM BASIC.

Symbol statement with test COLOUR 1 doesn’t pass

I will check that, but it may be one of the hanging bits, because I have not done the ‘line’ and ‘program’ properly yet, if ever.

How about invalid combinations that pass?

Did you do the changes to check keywords in variables? If not, then those keywords are valid expressions.

Test definition ?COLOUR NEXT FOR END 2020 IS A CRAP YEAR I WANT MY MOMMY WAAAAH
Passed as        COLOUR NEXT

This is quite correct. COLOUR can take a single parameter, but not 13.

Edit: more importantly, parameters are comma-separated, so everything after NEXT is invalid.

If you were building a true Parser you would deal with COLOUR NEXT and then carry on with the rest of the line.

Test definition ?COLOR 1
Failed in        COLOR 1

I pondered whether to deal with COLOR and I could not be bothered. Change Syntax if you really want it.