QuickBasic compiler clone

Tokenizes and parses QuickBasic code. This is under development.

Latest snapshots of the lexer and parser are available:
qb.l // 2003-11-17 (6 kB)
qb.y // 2003-11-17 (11 kB)

If you are interested in joining the development, please contact me.

To provide tools for running QuickBASIC programs in Linux and other non-MS-DOS -environments.

Several ideas are, what this should become.

• Interpreter

  Pros:

  • Portable

  Cons:

  • No standalone programs

• Compiler / translator, for:
  • Assembler

    Pros:

    • Should be fast

    Cons:

    • Restricted to a certain architecture

  • To C

    Pros:

    • Should become fast
    • Multi-architecture

    Cons:

    • Most certainly unmaintainable
    • Requires a C compiler

  • To Ruby

    Pros:

    • Should be elegant and maintainable
    • Multi-architecture

    Cons:

    • Ruby isn't yet very well-spread
    • Certainly not so fast

These features are often missing from other BASIC implementations, because they are difficult to implement or not seemed as important.

• ON n GOTO/GOSUB
• READ/DATA/RESTORE
• Fully compatible INKEY$
• TIMER function
• Type compatibility (INTEGER must still be 16-bit signed integer etc)
• PLAY/ON PLAY
• DEF FN
• Number printing and stringifying (PRINT, STR$) compatibility
• OPEN: Both syntaxes
• NEXT with comma separated list of variables
• IF: Both syntaxes plus implicit GOTO in THEN and ELSE support.
• PRINT abbreviated as ? support

Some of these features require emulation of PC-style hardware without direct hardware access.

• DEF SEG &HB800/PEEK/POKE support for direct video access in text mode
• IN/OUT support to ports &H388 - &H389 for AdLib support
• SCREEN 12/13, PSET and other drawing stuff

These QuickBASIC features are not seen as important, and will not be supported (unless somebody has too much time).

• All the excessive ERR codes like "String formula too complex" etc
• KEY ON/KEY OFF (dunno about ON KEY)
• FIELD and other obscure file features (some of which were new in QB 7.0)

In modern operating systems, the memory allocation is designed so that the user doesn't have to care about it. We don't have to meddle with EMS/XMS or any other kind of perverse system the hardware requires for memory allocation.
So if you want to say DIM area(1048576) AS INTEGER, it's fine!
Things like VARPTR$ and SADD() will have to be adjusted a bit though.

In *nix systems, all the devices have been designed so that you can use them by just opening the appropiate file from /dev directory. For example, if you wanted to record and play with your soundcard, you could do OPEN "/dev/dsp" FOR BINARY AS #1, and that's fine. You read there (record), you write there (play).
Of course this won't work in Windows systems.
Other examples could be floppy disks, frame buffer consoles etc.
This isn't the whole truth. Some devices require you to do ioctls before you can do anything useful. This will be considered.

There are no plans for extra features yet, but internationalizations like UTF-8 support would be nice.

QuickBasic programs are usually designed to take 100% of the CPU time all the time. This badly fits to multitasking environments we nowadays have in modern operating systems.
But history is history, and we have to support it.
But we don't have to limit ourselves to it. Even if we couldn't detect and convert Ti#=TIMER:WHILE TIMER<Ti#+1:WEND style loops to USLEEP 1000000, we could support things like USLEEP and FORK. Just maybe.
See your favourite POSIX manual if you don't know what those functions mean.

qbc has been written by Joel Yliluoma, a.k.a. Bisqwit,
and is distributed under the terms of the General Public License (GPL).

At least these GNU tools are required: flex, bison, gcc, make.

Then learn programming. It's a slow journey which requires patience and eagerness to learn new things.

If you want to start programming with BASIC, go and see DarkBasic.

The official home page of qbc is at http://iki.fi/bisqwit/source/qbc.html.
Check there for new versions.