| BASIC V for Unix, DOS, Windows and RISC OS: We talk to author Dave Daniels about the spirit of Brandy BASIC |
|
Published: 6th Dec 23:32:28GMT Source: Drobe News
By Chris Williams
|
| Page 1 of 1 |
|
|
|
BASIC V is a powerful implementation of BASIC supplied as part of the RISC OS operating system. BASIC is notorious for being mainly an interpretted language and isn't considered cross-platform friendly. However, one software writer who goes by the name of Dave Daniels has been developing a project that allows BASIC V to be used on all computers and thus extending the reach of BASIC V beyond the RISC OS community. Brandy BASIC is a BASIC V interpretter that has been compiled for RISC OS, NetBSD/arm32, NetBSD/i386, Linux, DOS and Windows. Brandy BASIC achieves this by being written in 100% ANSI C, total portability. We were intrigued by the development of Brandy and after noticing the stir it caused in the RISC OS newsgroups, we contacted author Dave Daniels to find out what makes Brandy BASIC tick.
Why did you personally decide to write the interpreter?
I have been interested in compilers and interpreters for a long time and writing my own Basic interpreter is an idea that has intrigued me for ages. Many years ago I looked at how a couple of interpreters worked (the semi-compiled Basic on the Grundy Newbrain and Locomotive Basic on the Amstrad CPC machines) and spent many absorbing hours exploring them. I can also remember going to a talk at Imperial College given by one of the authors of Locomotive Basic which was most instructive. The seed was therefore sown the best part of twenty years ago.
I started writing a Basic interpreter in the early 1990s but never finished it. However, the experience gained proved to be very useful when it came to writing Brandy, mostly telling me what not to do.
The motivation for Brandy itself was Acorn shutting down the workstation division and cancelling Phoebe in September 1998. I did not think that the outlook for RISC OS computers was looking very rosy and that they would become just another entry in the history of personal computers like machines such as the Amiga and Atari. The idea struck me that I could write my own BBC Basic interpreter that was platform independent. It seemed to me that something from RISC OS would live on, even if nobody else ever used it. I thought I had a deep enough knowledge of BBC Basic and enough experience of using it to be able to write my own interpreter for it without too much difficulty.
I have worked on the program on and off since September 1998. My notes on the program say:
'Version 0.01 01/12/98.
Ran very first program at 18.12 on 14/12/98. Quick speed comparison showed that Acorn Basic is between ten and twelve times faster. :-('
It has improved since then.
Were there any problems or insights during development?
The project was more complex than I thought it would be. I realised that I had to make the program as compatible with the Acorn interpreter as possible, but there were a lot of undocumented features and details, for example, the following INPUT statement is perfectly valid:
INPUT abc , ; , ; , def ;; ghi$
The manual does not say this. A fair amount of experimentation was needed to uncover this sort of thing.
I developed the program in parallel on a number of machines. I worked on it under RISC OS, NetBSD/arm32, NetBSD/i386, Linux, DOS and Windows. This taught me a lot about writing code that will run on different types of machine but I got it wrong in that the program does not work very well on any other type of processor. This is what I am trying to sort out at the moment.
Graphics was a big problem. Under RISC OS it is easy but it has proved to be a major headache on other machines. Consider, for example, NetBSD or Linux. There are two ways to support graphics: firstly, you write your program as an 'X' application, but then your program is limited to running under X windows. This is most decidely not what is wanted with Brandy. Alternatively, you can use a graphics library such as svgalib. The snag here is that many people do not like svgalib and see it as a security risk. This is because a program has to have root priviledges in order to be able to carry out any graphics operations as it needs direct access to the hardware. The only way to do this is to give the program root priviledges, but this also means that the program has complete access to everything else on the machine. For this reason many people consider libraries such as svgalib as unusable. Because of things like this I do not have a satisfactory answer as to how to provide the graphics support even after two years.
One of the problems was performance. The Acorn interpreter has a reputation for speed and I felt I had to uphold this tradition with my interpreter. The quote above shows how the program started and it has been a constant struggle to improve it.
The main reason why interpreters are slow compared to a compiled language is the overhead of decoding and executing the same statement every time it is reached. variables and arrays have to be searched for in the symbol table on every reference.
Expressions have to be type checked each time they are evaluated. Finding the next statement to be executed when a branch occurs, for example, when looking for the 'ELSE' part of an 'IF' statement means the program has to be searched. All of this takes time. One of the main design goals was to eliminate as much of this overhead as possible in order to improve the performance. The approach I took was to embed pointers in the Basic program wherever possible, so that, for example, the interpreter would not have to search the symbol table for variables except the first time a statement is seen. After this it uses the pointer to reference te variable's value immediately. The same trick is used to speed up branches in the program, for example, in an 'IF' statement there is a pointer to the 'ELSE' part of the statement to avoid the overhead of finding it. One useful side effect of the embedded pointers is that their presence can be used to indicate that at least part of a statement is syntactically correct and that the interpreter can proceed at full speed without any checks. I am sure that there are more possibilities for tricks like this in the program but I have yet to figure them out. (Aside: it would be interesting to see how fast Acorn's interpreter ran if it used embedded pointers.)
It has taken a great deal of effort to make the program run as fast as it does and I am always looking for ways to improve its performance.
I have added a number of extensions to BBC Basic in Brandy. The main one is that strings can be up to 65536 characters long instead of the 255 characters that Acorn's interpreter allows. The other main change is to allow libraries to have their own private variables, something that I thought was a major omission in Acorn's interpreter. Apart from that I have added two functions, ARGC and ARGV$ and extended the OSCLI statement so that the output from commands issued can be passed back to the program as I believe that these make the language more useful as a lightweight script language. Apart from that, I do not propose to keep adding features for the sake of it; indeed, I would prefer to get rid of some, for example, the sound system statements, which are really only of any relevance on an Acorn computer.
Brandy has a different philosophy to Acorn's interpreter. In my view, Acorn's interpreter has its roots firmly set in the days of the BBC micro, when Basic ruled and there was a need to provide access to the machine's facilities from Basic. Some of the statement types, such as those for controlling the sound system, reflect that way of thinking. I do not think that they would be included today. Also, with Acorn's interpreter, Basic programs are mostly dealt with in their tokenised form. You can load and save programs that are in plain text but they are normally tokenised. Again, in the days of the BBC micro, this saved space and meant that program handling was faster. My view is that we should move away from this. I also consider line numbers largely irrelevant. They are only needed to identify lines in error messages and when editing a program within the interpreter, that is, unless the program contains GOTO, GOSUB, ON GOTO and ON GOSUB statements and some versions of the RESTORE statement. Brandy is written to work with Basic programs that are stored as plain text and wihout line numbers. To be truthful, experience has shown that the current version (1.05) still needs some work in this area. There is a greater emphasis on procedures and functions, as in the traceback of procedures and functions called when an error occurs. The aim, really, is to make the interpreter and language more usable, not just on other platforms but under RISC OS too.
What kind of feedback have you had so far regarding the interpreter?
It has been very positive. A number of people have written to me congratulating me for writing the program, which was a most unexpected suprise. It has been very gratifying after all the effort I have put into the program. Sophie Wilson uses the program and has publically endorsed it [Sophie was the key developer of Acorn BASIC and is still remains a very respected person to the majority of RISC OS users in the know- Ed]. Could anyone ask for more in the RISC OS world?
Are you looking to write any more platform independant applications?
Not at the moment. I am not the world's fastest programmer, nor do I spend all of my life in front of a keyboard and monitor. Brandy is not finished yet. It is not as platform independent as I thought (to steal somebody else's joke, it is portable 'for small values of portable'). The bugs reported have fortunately all been minor but I have a list of problems and weaknesses to attend to.
It could be argued that writing a portable BBC Basic interpreter gives people another reason to leave the RISC OS platform. This could be true, but I do not see it as problem. It could also be argued that it would encourage people to stay, knowing that they can run the same programs under RISC OS and other operating systems they use. A decent Basic such as BBC Basic might also change some people's opinions of the language and might tempt the curious to see what RISC OS is like. However, the deed is done and cannot be undone, so I just hope people find the program useful.
Many thanks go to Dave for his contribution to this article, we wish him all the best and we look forward to future Brandy developments.
Contacts
Brandy BASIC: www.brandy.riscos.org.ukRelated articles
Show your love for RISC OS on Facebook
New release of RISC OS Firefox available
USB in latest RISC OS 5 source release
This article has been linked to, or is available in the following formats:
|
| |
|
|
|
|
