Availability of a Basic Compiler

The source to a BASIC compiler, written in C, under the name of BWB110,
(Bywater BASIC) is available via FTP from the following site (according to
the author):


  duke.cs.duke.edu /pub/bywater/bwb110.zip
                                    /pub/bywater/bwb110.tar.Z


I obtained it from WSMR-SIMTEL20.ARMY.MIL as follows:


      PD1:<msdos.basic>bwb110s.zip Source, and
      PD1:<msdos.basic>bwb110e.zip Executable


The compiler appears to cover a large part of the basic language, and
supposedly can be implemented on a system supporting the C language. Some
features which can't be implemented in a standard method (such as
delimiterless input (INKEY$) and things you can't do easily in the C
language, such as CALL to a machine language program, etc.)


I have not had much opportunity to play with the program, but from the
documentation it points out that it does not tokenize, so it's going to be
slow. It might be worth looking at for use in applications where some
interpreter is needed.


The sources are copyrighted but the restrictions on it are generally
permitting non-commercial and non-military use.


An immediate mode allowing either direct commands (PRINT 12*12 returns 144
on the next line) or the entry of program statements (10 REM). The
interpreter will also accept a program passed to it as a parameter on the
command line. I did some testing using an MSDOS PC.


I tried writing a program from the command line on the order of
1 REM
2 GOTO 1
RUN


This resorted in an endless loop the program did not accept a control
break to get out of. Either the code does not have SIGNAL code to accept
a control break, or the compiler doesn't support it or the method of
blocking it doesn't work well, as typing in a line and doing ^C causes an
error message of "program interrupted at line 0". A command of LIST typed
in with no program present gave an error message of "ERROR in line 0: Line
number 32767 not found".


Control C worked on an input statement. The SAVE command requires a file
name and no default extension is added. The PRINT command appears to
buffer the output, so that a


      PRINT CHR$(210);


statement appears in a program, unless an INPUT statement appears or
something else, pending output when the command prompt appears is
discarded.


Apparently there are bugs in the control-c handler. Two control Cs used
either in response to INPUT or at the command line or for whatever reason
(except, as I stated, that Control C doesn't work if there's no input
prompt) cause the interpreter to terminate.


The MSDOS version defaults to taking any unknown command as a shell
command. The LOAD command to read in another program works, but not if
the file name is one letter. (LOAD HI works but LOAD I does not.)


When entering lines, the command prompt appears after each line. This is
annoying to me as I've used most basic interpreters and they don't print
the prompt when typing in new numbered lines. If a file is read in, the
lines do not have to be numbered, according to the documentation.


One thing I do not like - a feature that the programmer borrowed from the
C language, and that I never liked in the C language either, and that I
like even less in a language that has never used a feature like this - is
that variables are case sensitive, i.e. A$ and a$ are two different
variables.


Paul Robinson
--

Return to the comp.compilers page.
Search the comp.compilers archives again.