BCET Compiler - Known Problems

BCET - What's Broke?

Most things in this list are on the 'to be fixed' list.

There is a limitation with the register allocater in the code generator. When it runs out of registers, it just quits. There is no register spill ability. This is only a problem with long expressions like this sample:

DEFLNG A-Z
DIM a, b, c, d, e, f, g, h, i, j, k, l, m, n
a = b IMP c EQV d XOR e OR f AND g = i + j MOD k \ l * m ^ n

There is a bug in the code generator when using nested array references:

This example causes a call to the wrong version of the array element address routine:
Vt = Expr(Stmt(cS).P0).ResultTyp

This hack causes it to work correctly, or you can break it in two statements:
Vt = Expr(Stmt(cS).P0 + 0).ResultTyp

These are actual examples from the compiler. 'Stmt' and 'Expr' are both arrays of a TYPE.

There is support for "ON [LOCAL] ERROR {GOTO line | GOTO 0}" but not "ON [LOCAL] ERROR RESUME NEXT". But not much tested.

Passing 'name AS ANY' assumes a LONG, and may not work correctly. Passing 'SEG name AS ANY' passes the correct offset.

When using 'lib' in a declare, BCET assumes the suffix, so don't supply one.

Calls to routines using 'VARARGS' is not supported, and may never be.

Not all the compiler command line options work as described.

Static arrays can now be created. The code generator will access one dimension arrays with inline code. This means bigger code, but faster. Later, there will be an option to bypass the inline code.

Bounds checking is always enabled. Later, there will be an option to suppress it.

Passing a Fixed length string to a sub or function works, however any changes made to it are lost.

PRINT USING doesn't work yet. BGEN generates calls to the runtime, however the routines are not yet written.

OPEN with no sharing info seems to want exclusive access. Actually, OPEN has had very little testing, and none of the access options has been tested.

TYPE variables work, and arrays of TYPE variables also. However, for the moment, you can not have a TYPE variable within a TYPE. Well, you can, however you just can not reference it. It's a problem in the compilers 'IdentifyVariable' routine.

Arrays with more than two subscripts don't work yet, as the runtime support remains to be written.

More problems later, as they are found. :-)

Old, fixed or should have been fixed bugs here:

Using NOT causes problems in certain cases. This is a problem in the expression parsing routine. For example:
    "IF NOT [variable] AND [other variable] THEN"
BCET sees it as:
    "IF NOT ([variable] AND [other variable]) THEN"
and PDS seems to see it as:
    "IF NOT ([variable]) AND [other variable] THEN"
to force correct evualation use (this seems to work):
    "IF (NOT [variable]) AND [other variable] THEN"

The problem is how to determine the rules, as the only authority is BC. The only solution is to generate a LOT of test cases, and examine the code.

There is also a problem with uniary minus in some cases.
    for example with these vars:
    a = 5
    b = 0 - 5
This Statements Fails:
    IF -a = b THEN PRINT "OK" ELSE PRINT "ECK"
And this one works:
    IF (-a) = b THEN PRINT "OK" ELSE PRINT "ECK"

FIXED in Beta 002
CDECL, SYSCALL, and STDCALL args are pushed in the wrong order. Back assward. Code generator prob.

FIXED in Beta 002
The code generator does not know about Caller Stack Cleanup. So calls to CDECL (and STDCALL with varargs) routines will trash the stack. This may or may not cause a program to fail.

FIXED in Beta 002
PRINT comma doesn't work correctly. The column counter is broke, and doesn't wrap at the correct place.

FIXED: 06/29/03
STATIC variables in a sub or function. They don't work yet. Use SHARED.