Generated on 09-06-2007 at 22:51:28

At this time, the web pages at http://www.arargh.com/basic/index.html
will usually have the latest information.


---------------------------------------------------------------------------
Extracted from: http://www.arargh.com/basic/differences.html
---------------------------------------------------------------------------

Things that work differently than QB, PDS or QBasic: 


The keyword 'SEG' has been assigned an additional meaning.  If used as a 
function, it returns the address of a SUB or FUNCTION.  This ability is 
needed for API callbacks.  See the sample 'generic' in the distribution 
for an example of this usage.  


INKEY$ blocks - that is, it waits for a key to be pressed.  


Setting the date (DATE$ statement) or time (TIME$ statement) are disabled. 
Retrieving the date or time work the normal way.  


SADD, VARPTR, VARPTR$, SEG, SSEG, and SSEGADD all return a 32-bit near 
pointer to the variable.  


The multiple variable form of NEXT is NOT supported: "NEXT [counter 
[,counter...]]" 
The Syntax supported is: "NEXT [counter]", where [] means optional.  


COMMON and COMMON SHARED and Named COMMON and Named COMMON SHARED work, 
however the association is by name, not position as in Other Basic 
compilers.  The names have to be EXACTLY the same.  (Use an include file). 



The CURRENCY data type is handled as int-64 WITHOUT the bias of 10,000 as 
in MS Basic Compilers.  


PRINT output to the screen may not always wrap the exact same way as DOS 
does.  This is due to the way windows handles the console.  It might be 
possible to make it work the same way, if someone has LOTS of money to pay 
for it.  


Other differences will be listed here as they become known or as I 
remember them.  


---------------------------------------------------------------------------
Extracted from: http://www.arargh.com/basic/nosupport.html
---------------------------------------------------------------------------

BCET - Unsupported Statements and Functions 


The following MetaCommands are recogizned, and ignored:  $LINESIZE: $LIST 
$OCODE $PAGE $PAGEIF $SKIP $SUBTITLE $TITLE 


The BSAVE and BLOAD statements are not supported.  The files they use 
would not be compatible with other versions of Basic.  


The CHAIN statement is not supported yet.  


The CURDIR function is not supported yet.  


'DEF fn' is not supported yet.  Use a real function or sub.  


The FILES statement is not supported.  


None of the Grahpics statements are supported:  LINE, CIRCLE, PSET, 
PRESET, DRAW, VIEW (Graphics), WINDOW, PMAP, POINT, COLOR (Graphics), 
PALETTE, GET (Graphics), PUT (Graphics), PCOPY.  


The INP, OUT and WAIT statements are not supported.  


INPUT <variable list> statement has no runtime code yet.  


IOCTL is not supported in any of it's forms.  


None of the ISAM statements or functions are supported.  


The LPRINT statement and LPOS function are not supported.  


All forms of the 'ON Event' statement are NOT supported.  (CON, KEY, PEN, 
PLAY, SIGNAL, STRIG, TIMER, UEVENT).  


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


The POKE statement and PEEK function are not supported.  


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


The SCREEN statement is not supported.  Since there is only text.  :-)  


The SHELL function is not supported.  The SHELL statement is.  


VIEW PRINT does not yet have any runtime code written.  Other (Graphic) 
forms of the VIEW statement will not be supported.  


The WIDTH statement for the screen is not yet supported.  The WIDTH 
statement for files is not yet supported.  The WIDTH LPRINT statement will 
not be supported. 



---------------------------------------------------------------------------
Extracted from: http://www.arargh.com/basic/problems.html
---------------------------------------------------------------------------

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.  


