Language Design: Basis

[Schol-R-LEA]

Since there seems to be a lot of interest in systems programming in languages other than C or C++ in the OS forum I thought I'd start up a thread for one of the three most common ideas: a Basic derivative (the others, a member of the Lisp family and an object-oriented language similar to SmallTalk, will have separate threads). I have given this putative language the tenative name 'Basis', short for 'BASIC for Systems'.

To start things off, we need to know what people want in the language, and to consider which of those 'wish list items' is practical for the sort of low-level language we want. Does anyone have anything to start with?

Also, is there a specific dialect (Qbasic, VB, PowerBuilder, etc.) that you wish to base the design on, or any compromises between dialects? Keep in mind that only a very minimal subset will be possible, and that there will, of necessity, be some considerable changes and additions; In effect, this will be a new dialect in and of itself. If anyone can find any reference material on ANSI Minimal Basic, it could prove useful as a starting point.

[Candy]

Still being of the BASIC-origin camp, I would like to see this . As for suggestions:

I would like to see it start off with QBASIC (or QuickBasic) for starters. Then, some major changes to the usage of the language, but absolutely none to the scripture (the way in which operands interact etc). This would be making it lots easier to use separate files for one project, preferably without headers (just all-compile them). Still, not sure whether leaving out headers is a good thing...

Suggestion for this: INCLUDE "filename.bas", possibly with a user-specified project root, so you could do an INCLUDE "\STANDARD\MATH.BAS" or something similar.

Much easier access to both assembly language and pointer-like things. People scour at pointers because you can make mistakes with them. There's a lot of different ways to do harm with a knife, but without a knife you would lose a lot of elementary functionality. Answer, keep the knife (and, in my opinion, the pointers).

Assembly now requires handcoding it, converting it to machine code (manually or with nasm + hexeditor), putting it in the source, changing it to bytecode again and using some weird hack to jump to it. Make this easier with some form of

Code: Select all

ASM eax=variable1, ebx=var2, edi=count
    ... 
END ASM var3=edx, var4=edi

structure

And finally, lots (and I mean LOTS, variable offset indication, manually relocating functions, auto-alignment of things, stuff like that) of control over the build process plus the final stuff.

If I may suggest one very plain thing, a number of default files that are delivered along called REALLIB for realmode functions, and a number of functions for protected mode that are present nearly identical in each OS (set page table entry, set GDT entry, clear interrupt line, stuff like that).

HTH, Candy (from his brand-new cable connection! with a blistering downstream of 64kbit/s! )

[Kyle]

Out of those three I prefer qbasic the most. (I'm not ashamed that I know basic ;D)

[Tim]

Suggestion for this: INCLUDE "filename.bas", possibly with a user-specified project root, so you could do an INCLUDE "\STANDARD\MATH.BAS" or something similar.

Can we have something a bit clever than just including text line C does? Something like Pascal units or .Net assemblies, please? That is, you compile MATH.BAS into some clever format which describes not only the functions and variables it contains, but also the constants, types, etc.

Much easier access to both assembly language and pointer-like things. People scour at pointers because you can make mistakes with them.

Remember, this language is like BASIC . If you want to be able to shoot yourself in the foot, program in C. If you want to be able to write safe code in a less powerful language, program in this language. Adding an inline assembler is a good idea, but I think pointers should be kept out of the language.

Although an equivalent of C++'s references would be handy. You could say:

Code: Select all

DIM i AS INTEGER
DIM REFERENCE j AS INTEGER
SET j = i
j = 42
PRINT i    ' prints 42

This might be similar to VB's object types.

HTH, Candy (from his brand-new cable connection! with a blistering downstream of 64kbit/s! )

Congratulations!

[Candy]

Can we have something a bit clever than just including text line C does? Something like Pascal units or .Net assemblies, please? That is, you compile MATH.BAS into some clever format which describes not only the functions and variables it contains, but also the constants, types, etc.

That's ok with me... but, if we're going to make some more intelligent include, why not make it some sort of import? Something similar to pointing it to some source file to import all function definitions, constants etc. that are publicly visible?

Remember, this language is like BASIC . If you want to be able to shoot yourself in the foot, program in C. If you want to be able to write safe code in a less powerful language, program in this language. Adding an inline assembler is a good idea, but I think pointers should be kept out of the language.

How would I return a pointer with malloc or new or anything of memory management stuff if I can't make a pointer?

Although an equivalent of C++'s references would be handy. You could say:

Code: Select all

DIM i AS INTEGER
DIM REFERENCE j AS INTEGER
SET j = i
j = 42
PRINT i    ' prints 42

This might be similar to VB's object types.

That might be an idea... Still, I would like pointers.

For setting static references, something like

Code: Select all

SET ADDRESS OF j = i

that might do the trick?

[Tim]

How would I return a pointer with malloc or new or anything of memory management stuff if I can't make a pointer?

BASIC has DIM to allocate memory. IIRC Visual Basic 6 lets you create new objects, something like:

Code: Select all

Set newForm = New Form1

We could have a memory-allocating function return a reference:

Code: Select all

SET i = NEW INTEGER    ' like VB6
' or
SET i = DIM AS INTEGER    ' allocate a new integer
SET i = DIM(100) AS INTEGER    ' allocate an array of integers

For setting static references, something like

Code: Select all

SET ADDRESS OF j = i

that might do the trick?

OK, but is that different from my syntax?

[Candy]

BASIC has DIM to allocate memory. IIRC Visual Basic 6 lets you create new objects, something like:

Code: Select all

Set newForm = New Form1

We could have a memory-allocating function return a reference:

Code: Select all

SET i = NEW INTEGER    ' like VB6
' or
SET i = DIM AS INTEGER    ' allocate a new integer
SET i = DIM(100) AS INTEGER    ' allocate an array of integers

DIM is a function based on the OS. Do away with DIM, or make it redefinable (having my obvious preference).

Some sort of UNDIM would also be nice, similar to freeing memory.

And, if I may, change the syntax of dim to a function called DIM returning the new place for some address or something.

For setting static references, something like

Code: Select all

SET ADDRESS OF j = i

that might do the trick?

OK, but is that different from my syntax?

It does not add another set of variables to the language. That alone would make it worth it to me, it does away with all the pointer, reference, dereference **** and make it as clear as setting the location of a variable to something else. That might also solve the problem with making the memory manager.

[Tim]

DIM is a function based on the OS. Do away with DIM, or make it redefinable (having my obvious preference).

Some sort of UNDIM would also be nice, similar to freeing memory.

And, if I may, change the syntax of dim to a function called DIM returning the new place for some address or something.

OK. Should you be able to write the implementation of DIM without resorting to assembly or C?

It does not add another set of variables to the language. That alone would make it worth it to me, it does away with all the pointer, reference, dereference **** and make it as clear as setting the location of a variable to something else. That might also solve the problem with making the memory manager.

I think we're talking about the same thing.

I proposed a new SET statement, separate from LET:

DIM i as INTEGER
DIM REF j AS INTEGER
LET i = 1 ' assign value 1 to i
LET j = 2 ' crash! j doesn't refer to anything
SET j = i ' make j refer to i
LET j = 3 ' assign value 3 to variable referred to by j, i.e. i

From what I understand from your post, SET ADDRESS OF would do the same thing as SET in this listing. Note I shortened REFERENCE to REF this time -- and I prefer SET on its own to SET ADDRESS OF -- because it's more in keeping with the rest of the syntax. Long words are nice, but that's more like SQL than BASIC. ([me=Tim Robinson]avoids temptation to start a new thread describing an SQL clone )[/me]

[AGI1122]

Add elseif's.

I prefer this:

Code: Select all

if (code) {

}
elseif (code2) {

}
else {

}

instead of this:

Code: Select all

if (code) {

}
else {
  if (code2) {

  }
  else {

  }
}

I think elseif's help keep the code alot cleaner as compared to stuffing tons of if's into the else's.

[Tim]

Um, if you add a space in the middle of the elseif in your first listing, you'd get valid C or C++ code. No need for all the { }.

[Candy]

DIM is a function based on the OS. Do away with DIM, or make it redefinable (having my obvious preference).

Some sort of UNDIM would also be nice, similar to freeing memory.

And, if I may, change the syntax of dim to a function called DIM returning the new place for some address or something.

OK. Should you be able to write the implementation of DIM without resorting to assembly or C?

Don't see why not? You can control a list from within basic, just like within C. You should be able to make it just as simple.

It does not add another set of variables to the language. That alone would make it worth it to me, it does away with all the pointer, reference, dereference **** and make it as clear as setting the location of a variable to something else. That might also solve the problem with making the memory manager.

I think we're talking about the same thing.

I proposed a new SET statement, separate from LET:

DIM i as INTEGER
DIM REF j AS INTEGER
LET i = 1 ' assign value 1 to i
LET j = 2 ' crash! j doesn't refer to anything
SET j = i ' make j refer to i
LET j = 3 ' assign value 3 to variable referred to by j, i.e. i

Didn't notice the S instead of the L Sorry bout that.

ok, but you miss the point. You want to explicitly use references. Isn't it an idea to not make them explicit but implicit, like

Code: Select all

DIM a, b AS INTEGER
LET a = 1
SET b = a
LET b = 2
' a = 2 too

in order to let the basis-users not mess with reference types? Still... wondering how you'd do a memory manager even with this... You would have to have a variable (or pointer, whatever you like most) to the space, and return that as the place for the info. I would still opt for the pointers...

[kyle]

I'm sorry, maybe I'm just stupid but what exactly are you trying to do? Create a low-level language with basic-like syntax?

[AGI1122]

Um, if you add a space in the middle of the elseif in your first listing, you'd get valid C or C++ code. No need for all the { }.

That was only meant as an example, not how the syntax should look.

[Tim]

in order to let the basis-users not mess with reference types? Still... wondering how you'd do a memory manager even with this... You would have to have a variable (or pointer, whatever you like most) to the space, and return that as the place for the info. I would still opt for the pointers...

Mmmm... evil, I like it . So you add the ability to say, "when I ask for this variable, give me this one instead". Then dynamic allocation means assigning making a variable point to some block of memory.

Re the implementation of DIM. You'd need some advanced l33t feature to let you take a pointer from the OS and turn it into a reference. This would let you treat a block returned from the OS's virtual memory allocation function as an array of bytes.

[Schol-R-LEA]

I'm sorry, maybe I'm just stupid but what exactly are you trying to do? Create a low-level language with basic-like syntax?

Exactly. One of the FAQs on the OS-Development forum is whether you can use some Basic or another for kernel programming. This is an attempt to find an answer to it aside from simply, 'no'.