Print Page - gBasic

BASIC Developer & Support Resources => Translators => Topic started by: Steve A. on January 26, 2011, 09:34:18 AM

Title: gBasic
Post by: Steve A. on January 26, 2011, 09:34:18 AM

Okay,...
It took me a little longer than I anticipated to work out the kinks (being new to SB).

Here is a link for gBasic v.01 translator:
http://sites.google.com/site/bluntaxebasic/Home/updates/gbasic.zip

Its primative and it's language support is extremely limited, but, many of the translator functions that will be needed down the road are already in place.

In the zip, there is a readme.txt that explains, in some detail, how to use gbasic.bas.

Title: gBasic
Post by: JRS on January 26, 2011, 09:55:28 AM

Nice Job Steve!

This is a huge boost for the project and hope this will get others to join in.

BTW:

CALL is only needed if you reference a SUB before it's declared in your script. I'll do a quick test to validate this comment.

If you put C:\scriptbasic\bin in your environment PATH, you can use scriba from anywhere.

The $ is optional in SB for strings and string functions. It doesn't matter to me if you use them or not.

Thanks for the great effort to get gBasic rolling.

Title: gBasic
Post by: Steve A. on January 26, 2011, 10:16:32 AM

Quote from: JRS on January 26, 2011, 09:55:28 AM

CALL is only needed if you reference a SUB before it's declared in your script.
If you put C:\scriptbasic\bin in your environment PATH, you can use scriba from anywhere.
The $ is optional in SB for strings and string functions. It doesn't matter to me if you use them or not.

Hey John,
Personal preferences:
re: CALL:: I just want to be consistant with other dialects that require CALL,
re: PATH:: Yes, I just don't like adding crap to my environment if I can avoid it.
re: $:: I prefer to specify data types, especially character string data.

Title: gBasic
Post by: JRS on January 26, 2011, 10:58:16 AM

Life is good and your standards are fine with me.

Title: gBasic
Post by: JRS on January 26, 2011, 03:17:40 PM

Here is the first gBasic script translated to C.

Code: Text

'  this is a test
 
'
 
    PRINT "Hello World!"
 
    PRINT "My name is Steve"
 
    END

Code: C

//      ************* gBasic Compiler *************
 
//      Copyright: s.arbayo (c) 2011
 
/*--------------------- DECLARE HEADERS ---------------------*/
 
#include <stdio.h> 
 
#include <stdlib.h> 
 
/*------------------- Function Prototypes -------------------*/
 
/*---------------------- BEGIN PROGRAM ----------------------*/
 
int main(int argc, char *argv[]) 
 
{ 
 
    printf("Hello World!\n");
 
    printf("My name is Steve\n");
 
    return 0;
 
}
 
/*--------- end main ---------*/

jrs@Laptop:~/gBasic/gBasic_01$ gcc test.c -o Hello_Steve
jrs@Laptop:~/gBasic/gBasic_01$ ./Hello_Steve
Hello World!
My name is Steve
jrs@Laptop:~/gBasic/gBasic_01$

7,090 Byte executable.

Title: gBasic
Post by: JRS on January 26, 2011, 04:31:21 PM

I installed MinGWTDM under Wine and compiled Steve's gBasic program.

C:\gBasic>gcc test.c -o Hello_Steve.exe

C:\gBasic>Hello_Steve
Hello World!
My name is Steve

C:\gBasic>

27,527 Byte executable.

Title: gBasic
Post by: JRS on January 26, 2011, 09:19:04 PM

Steve,

I notice this line of code in the translator and wasn't sure if you are trying to concatenate the string.

xstring$ = xstring + ch$

xstring$ and xstring are two distinct variables.

a = 1
b = "2"

c = a + b

This would return 3 as the + indicates to SB that a math operation is being done

c = a & b

This would return "12" as the & tells SB that the two variables are to be concatenated.

SB also supports the following.

xstring$ &= ch$

Title: gBasic
Post by: Steve A. on January 27, 2011, 06:14:24 AM

Ahh!,
habits are hard to break.
I can't tell you how many times that came up, where the code (related to strings) wasn't working, only to find that I had substituted a "+" for a "&".
And, leaving off the "$" in that case was simply a typo.
Thanks for pointing that out.

I spent last evening fixing some other bugs, too.

Title: gBasic
Post by: Steve A. on January 27, 2011, 06:38:28 AM

I've uploaded a new zip with some fixes:
http://sites.google.com/site/bluntaxebasic/Home/updates/gbasic.zip

Repaired some typos that got by me.

Title: gBasic
Post by: JRS on January 27, 2011, 09:42:24 AM

Thanks Steve!

The translator is taking shape and I'm glad your getting comfortable with SB. Looking forward to the next release.

I split the topic at the first release as the thread was getting a bit long.

I encourage those that are interested in the gBasic project to get a copy of SB and MinGWTDM and follow along. If your able to contribute, all the better.

Title: Re: gBasic
Post by: JRS on January 27, 2011, 12:09:43 PM

Code: [Select]

' ----------------------------------------------
' ========== Declare Global Constants ==========
' ----------------------------------------------
    Const BUFSIZE = 256
    Const TOKENLEN = 21
    Const VARNAME = 33
    Const LLEN = 33
    Const IOARRAY = 99
    Const PATH = 129
    Const RECLEN = 128
    Const bTRUE = 1
    Const bFALSE = 0

I noticed your comment of Global Constants and thought I would clarify what GLOBAL means in ScriptBasic.

By default, all variables are global to the module. MAIN:: is the primary module in SB. Unless you declare a variable LOCAL in a SUB or FUNCTION, it is a global variable.

GLOBAL CONST allows you to assign a constant that can be accessed in any module. A typical example of GLOBAL CONST might be to assign a newline escaped sequence to a constant.

GLOBAL CONST NL = "\n"

PRINT "this is a test",NL

BTW: PRINTNL is a shortcut to just print a newline and nothing else.

Title: Re: gBasic
Post by: Steve A. on January 27, 2011, 03:15:18 PM

Quote

I noticed your comment of Global Constants and thought I would clarify what GLOBAL means in ScriptBasic.
By default, all variables are global to the module. MAIN:: is the primary module in SB.

Okay, I'm glad you did.
I was unclear about scope. Generally speaking, in Basic, variables and constants are global, but, after reading the docs I was unclear. The docs are a bit shy on illustrations and examples. I wanted to expedite the process and not take chances of a constant not being recognized.

Quote

Unless you declare a variable LOCAL in a SUB or FUNCTION, it is a global variable.

Ummm..., does that mean that vars declared within a SUB are global in scope, if not declared as LOCAL ?
My assumption (and hope) would be that they would be LOCAL only to that SUB and be destroyed on exiting the SUB, regardless of being declared as LOCAL.
i.e.:
SUB MySub
myint = 100
mystr$ = "hello"
' do stuff
END SUB

...MySub.myint no longer exists.
...MySub.mystr$ no longer exists.

would this be true or not ?

The matter of scope has been a topic of much discussion from the eariest programming languages and seldom agreed upon from one language to the next.

Title: Re: gBasic
Post by: JRS on January 27, 2011, 04:36:13 PM

I'll explain by example.

Code: [Select]

FUNCTION test(arg1, arg2)
LOCAL a,b,c
  a = "one" 
  b = "two"
  c = "three"
  PRINT my_global_var,"\n"
  test = arg1 + arg2
END FUNCTION

a = 1
b = 2
my_global_var = "John"
PRINT test(a,b)

END

This script would display the following.

John
3

I had mentioned that SB supports name spaces. (modules)

Code: [Select]

MODULE Steve

SUB SA()
  PRINT a,"\n"
END SUB

END MODULE

a = 1
CALL Steve::SA()

This would print undef as a is assigned in the MAIN:: name space and not in the Steve name space.

Even though its legal to access variables from other name spaces, it defeats the purpose of coding with modules. (there is always an exception to the rule and breaking it should be a programmers choice)

a = Steve::a

OR

a = MAIN::a

GLOBAL can be used to make a variable or CONST global among all modules.

You can INCLUDE code at any point in your script.

INCLUDE "\scriptbasic\gBasic\myfunctions.bas"

If your using the basic|scriba.conf configuration file, the module (DLLs) and include(module .BAS) directories are defined there. This is normally used for extension modules that contain DECLARE SUB ext_func_name ALIAS "dll_func_name" LIB "lib_name" and any Basic code that supports that module.

IMPORT mysql.bas

The difference between INCLUDE and IMPORT is that IMPORT will only include the file|ext module once.

Title: Re: gBasic
Post by: JRS on January 28, 2011, 12:22:09 AM

I would also like to mention that duplicate label names are allowed if used within context.

Code: [Select]

' Test labels

SUB Test1
  GOTO IT
  PRINT "FYI, I'm in Test1\n"
IT:
END SUB

SUB Test2
  GOTO IT
  PRINT "FYI, I'm in Test2\n"
IT:
END SUB

TEST1
TEST2

GOTO IT
PRINT "FYI: I'm in MAIN\n"
IT:

END

jrs@Laptop:~/SB/test$ scriba testlabel.sb
FYI, I'm in Test1
FYI, I'm in Test2
jrs@Laptop:~/SB/test$ scriba testlabel.sb
jrs@Laptop:~/SB/test$

I remarked the GOTO lines in both subs to show that the SUBS are being called in the first test run and then unremarked the lines for the second run.

Title: Re: gBasic
Post by: JRS on January 28, 2011, 03:41:27 AM

Quote from: Steve

Ummm..., does that mean that vars declared within a SUB are global in scope, if not declared as LOCAL ?
My assumption (and hope) would be that they would be LOCAL only to that SUB and be destroyed on exiting the SUB, regardless of being declared as LOCAL.

I have to disagree on the LOCAL as default being the rule. I find it a pain in the ass to have to pass needed working variables as arguments. To me SUBs & FUNCTIONs are just routines and if I want isolation, a one line LOCAL statement declaring variables used for that purpose is painless. If one desires a more modular approach, use name spaces.

Title: Re: gBasic
Post by: Steve A. on January 28, 2011, 06:29:54 AM

Quote

To me SUBs & FUNCTIONs are just routines and if I want isolation, a one line LOCAL statement declaring variables used for that purpose is painless.

Hmmm, my perspective on SUBs and FUNCTIONs is different.
A flat, linear model where Subs and Functions are merely routines, similar to GOSUB/RETURN, would not allow recursion. As every time a SUB was re-entered the pre-existing (local) var values could be corrupted.

Regardless of name spaces, it's been my experience that data contained within Subs and Funcs should be isolated from the rest of the program. Of course, Subs and Funcs can see and access global variables in existance in the main body, (lowest level of the program). Additionally, Subs can access any variables passed to that Sub/Func.

The scope of a variable, when declared and assigned to in a Sub/Func, should be exclusive to that Sub/Func. Otherwise, data could become corrupted.

Code: [Select]

    globalVar = 1
    CALL MySub()
    PRINT "\nMAIN:output\n"
    PRINT "globalVar=", globalVar, "\n"
    PRINT "localVar=", localVar, "\n"
    END

SUB MySub
    localVar = 2
    PRINT "SUB:output\n"
    PRINT "globalVar=", globalVar, "\n"
    PRINT "localVar=", localVar, "\n"
END SUB

Unfortunately, (using SB) the above illustration displays the same output in both cases.
localvar, created in SUB mysub, is not destroyed upon exiting the SUB.

It remains alive after the Sub has been exited and is visible to the Main Body of the program.

Further tests show that I can force localVar to be exclusively local with:

Code: [Select]

    Local localVar
    localVar = 2

Title: Re: gBasic
Post by: JRS on January 28, 2011, 11:04:02 AM

In ScriptBasic you have the choice if variables are defaulted to global or local in functions/subs. To coin a BK phrase "Have it your way!"

declare option DefaultLocal

You can switch back to global by default with the following statement.

declare option DefaultGlobal

The same concept works for declaring variables and can be turned on / off anywhere in your script.

declare option DeclareVars

To return to ScriptBasic default auto global variable mode at anytime, use the following statement.

declare option AutoVars

This should give you the flexibility to setup your script to work like you want it to.

Title: Re: gBasic
Post by: Steve A. on January 28, 2011, 12:08:27 PM

Okay, that should clear up a few things.

Title: Re: gBasic
Post by: JRS on January 28, 2011, 04:39:55 PM

gBasic comments and feedback:

Code: [Select]

'    CLS

Under Windows the SB CIO extension module is used and under Linux curses is used. I would prefer that by default, screen mnemonics aren't used. I use SB in cron jobs, CGI, redirected output utilities and having screen control characters embedded may produce undesirable results.

Code: [Select]

' ----------------------------------------------
' ========== Declare Global Constants ==========
' ----------------------------------------------
    Const BUFSIZE = 256
    Const TOKENLEN = 21
    Const VARNAME = 33
    Const LLEN = 33
    Const IOARRAY = 99
    Const PATH = 129
    Const RECLEN = 128
    Const bTRUE = 1
    Const bFALSE = 0


' ----------------------------------------------
' ========== Declare Global Integers ==========
' ----------------------------------------------
    pii = 0
    ilen = 0
    ix = 0
    nrows = 0
    ncolumns = BUFSIZE
    epos = 0
    spos = 0
    lineNdx = 0
    token = 0


' ========== Declare Global Strings ==========
' ----------------------------------------------
    SourceFile$ = ""
    SourceTmp$ = ""
    pstring$ = ""
    xstring$ = ""
    sHolder$ = ""
    tHolder$ = ""
    indent$ = ""
    labelOr$ = ""
    wlabelBlock$ = ""


' ========== Declare Global Returns ==========
' ----------------------------------------------
    ireturn = 0
    lreturn = 0
    dreturn = 0
    sreturn$ = ""
    rvarName$ = ""


' ========== Declare Global Flags ==========
' ----------------------------------------------
' ========== Declare Global Arrays ==========
' ----------------------------------------------
    array1$[1] = ""
    labelNam$[1] = ""
    tempProg$[1] = ""
    tempLabel$[1] = ""
    byteArray[1] = 0
    tempByte[1] = 0

If your going to make your SUBs and FUNCTIONs LOCAL by default, then you will want to prefix these CONSTants and variables with the GLOBAL keyword to allow them to be used in your SUB/FUNCTION routines.

Title: Re: gBasic
Post by: JRS on January 28, 2011, 06:49:06 PM

Here is the Hello World of a recursive function example.

Code: [Select]

FUNCTION RF(arg_num)
  IF arg_num <= 1 THEN
    RF = 1
  ELSE
    RF = arg_num * RF(arg_num - 1)
  END IF
END FUNCTION

PRINT RF(5),"\n"

jrs@Laptop:~/SB/test$ scriba recursive_function_test.sb
120
jrs@Laptop:~/SB/test$

A factorial of a number is the product of that number with a number 1 less than that number, this multiplication process continues until the number which is being multiplied, eventually becomes equal to 1.

Code: [Select]

factorial( 5 ) = 5 * factorial( 4 )
               = 5 * ( 4 * factorial( 3 ) )
               = 5 * ( 4 * (3 * factorial( 2 ) ) )
               = 5 * ( 4 * (3 * (2 * factorial( 1 ) ) ) )
               = 5 * ( 4 * (3 * (2 * ( 1 * factorial( 0 ) ) ) ) )
               = 5 * ( 4 * (3 * (2 * ( 1 * 1 ) ) ) )
               = 5 * 4 * 3 * 2 * 1 * 1
               = 120

Here is another example but non-recursive.

Code: [Select]

FUNCTION ITF(arg_num)
  f = 1
  FOR c = arg_num TO 1 STEP - 1
    f = f * c
  NEXT
  ITF = f
END FUNCTION

PRINT ITF(5),"\n"

jrs@Laptop:~/SB/test$ scriba iterative_function_test.sb
120
jrs@Laptop:~/SB/test$

Title: Re: gBasic
Post by: Steve A. on February 01, 2011, 07:24:48 PM

Here's a new upload for gBasic:

http://sites.google.com/site/bluntaxebasic/Home/updates/gbasic.zip

Title: Re: gBasic
Post by: JRS on February 01, 2011, 08:41:07 PM

Quote from: README - (Steve)

This program was written in the ScriptBasic dialect.

To use this program with ScriptBasic:

1) copy gbasic.bas to: /scriptbasic/bin/
2) copy test.bas to: /scriptbasic/bin/
3) open a Dos/Console (command line) window
5) change directories to: C:.../scriptbasic/bin/
4) at the command line type:
C:> scriba gbasic.bas test.bas

The gbasic program will read the file test.bas and translate it into
a C source file and save it to disk as test.c.

At present, this translator will only translate the following keywords:
(also, block-labels:)

Code: [Select]
PRINT "quoted string" LET END LABEL:
however, many of the building blocks, needed to take this language
translator further, are already in place.

Due to time constraints, I have not documented the gbasic code much, yet.

There is a lot of meat on those gBasic bones. Nice job Steve!
I see this coming together at a rapid pace. I hope you agree doing it in ScriptBasic was the right choice.

Code: [Select]

Steps for making a language TO language translator:

Load Source:
	 input: source file
	output: byte code

Header:
	output: program name
	output: copyright information
	output: comments
	output: destination language headers

Prolog:
          scan: global variables
	output: declare global constants
	output: declare global variables

Parser:
	 parse: source byte code
	output: destination dialect

Epilog:
	output: finalize program
	output: write functions

Assemble:
	output: assemble translation
          call: compiler-linker

gBasic.bas (http://files.allbasic.info/gBasic/gbasic.bas.txt)

Code: Text

'  this is a test
'
Start:
    REM  testing
    PRINT "Hello World!"
    PRINT "My name is Steve"
    LET a = 1 + 1
    LET b = 1
    z = a + b
Done:
    END
 

Code: Text

//      ************* gBasic Compiler *************
//      Copyright: s.arbayo (c) 2011
 
/*--------------------- DECLARE HEADERS ---------------------*/
#include <stdio.h> 
#include <stdlib.h> 
 
/*------------------- Function Prototypes -------------------*/
 
/*---------------------- BEGIN PROGRAM ----------------------*/
 
int main(int argc, char *argv[]) 
{ 
    int a;
    int b;
    int z;
 
Start:
 
    printf("Hello World!\n");
    printf("My name is Steve\n");
    a = 1 + 1;
    b = 1;
    z = a + b;
 
Done:
    return 0;
}
/*--------- end main ---------*/
 

Title: Re: gBasic
Post by: JRS on February 02, 2011, 06:36:32 PM

I'm sure everyone has seen this tutorial. For those that missed it ...

Let's Build a Compiler, by Jack Crenshaw (http://compilers.iecc.com/crenshaw/)

This fifteen-part series, written from 1988 to 1995, is a non-technical introduction to compiler construction.

Title: Re: gBasic
Post by: Steve A. on February 02, 2011, 08:12:33 PM

Quote from: JRS on February 02, 2011, 06:36:32 PM

I'm sure everyone has seen this tutorial. For those that missed it ...

Let's Build a Compiler, by Jack Crenshaw (http://compilers.iecc.com/crenshaw/)

This fifteen-part series, written from 1988 to 1995, is a non-technical introduction to compiler construction.

At QDepartment, I did a complete translation (with commentary) of Jack's tutorial, from Pascal/M68x to C/x86.
http://tech.groups.yahoo.com/group/QDepartment/files/

Unfortunately, it took Jack years to write it and he never finished it.
The over all document is well worth reading, but, is rather fragmented due to the time it took to write it.
Jack's book has greatly influenced me in my work since.

Title: Re: gBasic
Post by: JRS on February 02, 2011, 08:20:12 PM

Quote from: Steve A. on February 02, 2011, 08:12:33 PM

Quote from: JRS on February 02, 2011, 06:36:32 PM
I'm sure everyone has seen this tutorial. For those that missed it ...

Let's Build a Compiler, by Jack Crenshaw (http://compilers.iecc.com/crenshaw/)

This fifteen-part series, written from 1988 to 1995, is a non-technical introduction to compiler construction.

At QDepartment, I did a complete translation (with commentary) of Jack's tutorial, from Pascal/M68x to C/x86.
http://tech.groups.yahoo.com/group/QDepartment/files/

Unfortunately, it took Jack years to write it and he never finished it.
The over all document is well worth reading, but, is rather fragmented due to the time it took to write it.
Jack's book has greatly influenced me in my work since.

Outstanding!

For those not a member of the QDepartment Yahoo mailing list/portal, I attached a PDF of Steve's translation here.

Title: Re: gBasic
Post by: JRS on February 20, 2011, 12:47:43 PM

Last I heard from Steve was that he was pretty busy and gBasic is something he will work on when he finds the time.

I'm still hoping Steve finds a second wind and puts out another progress release. The closer he gets, the easier it will be for others to contribute.

AllBASIC Forum

BASIC Developer & Support Resources => Translators => Topic started by: Steve A. on January 26, 2011, 09:34:18 AM