Charles, question for you about FreeBasic

[kryton9]

Charles, I have a question for you. Today Petr and I had a google chat about many things and one of the topics was about FreeBasic and its future.

Being that its goal at the moment is to be a BASIC frontend to the gcc compiler, does this mean that when this goal is met, that it can use c/c++ libraries without a need for wrappers? Or could use the compiled .obj files in your projects and just link to them? This is all confusing to me and I was wondering what the final benefit to being a total gcc compiler front end means for FreeBasic.

Thanks for any insight and I am so glad to see you here doing magic in thinBasic. Now if we can get some of the other PowerBasic gurus on board, woohoo!!

[Charles Pegge]

Hi Kent,

If you download FreeBasic you will see that it has a pretty comprehensive set of library headers translated from the MinGW C++ headers into Basic ones. The translation is, I understand, fully automated using a tool called SWIG.

The Freebasic compiler produces assembler code which is then fed to 'AS', then the output of 'AS' is then linked to static and dll libraries with 'LD'. Both 'AS' and 'LD' are used by GCC in the same way.

'AS' also known as 'GAS' is friendly enough to use directly without the high level language! Experimenting and testing is easy so I suggest this would be a good route to follow for anyone who wants to develop a compiler. :)

FreeBasic is almost C++, already, with the benefits of more readable source code and all the built-in functions that we are familiar with.

The main parts that are currently missing are Inheritance, Polymorphism and templates. But it has all the other bits like overloaded functions and operators, and public, protected and private members.

I find FreeBasic very flexible, but I feel I am riding two horses at the same time and they are moving apart. If I use the OOP features of FreeBasic then porting back to PB in its current state of development would become impractical. But I am very interested in ThinBasic and the way it combines both scripted and compiled elements. So maybe a third horse to the rescue! :)

[ErosOlmi]

Charles,

if you have some spare time, you should try to develop a thinBasic module using SDK for Power Basic. I'm sure you will find it interesting.
The power of a compiled language with the freedom to create your own keywords in the scripted language.
The same apply to FreeBasic even if SDK for it is not at the same level of PB one. But I can work on it if there is interest.

I too find FreeBasic very very interesting. It has our loved syntax but at the same time it is going into some new directions.

Ciao
Eros

[Charles Pegge]

I'll try a freebasic module first Eros. Looking at your sample FBGFX module, I am sure there is enough interfacing to work with. I am about to release another of my experimental languages. This one is very closely related to the machine code strings we have been doing in ThinBasic and I think it could be fitted into a module. All that is needed is to be able to pass BSTRs, then in conjunction with MC_Eval$ it should be possible to acheive tight integration with ThinBasic variables and library functions

[ErosOlmi]

If string is to be passed from script to module BYVAL I think all is already there.
You can use thinBasic_ParseString and a BSTR like in the following (I'm sure your already see it in FBGFX):



sub Exec_FBGFX_Print()
'----------------------------------------------------------------------------
'
'----------------------------------------------------------------------------

Dim ParensPresent As Long

'---Check if open parens is present
ParensPresent = thinBasic_CheckOpenParens_Optional

Dim sBSTR As BSTR
'Dim PBString As String

thinBasic_ParseString(sBSTR)
'---Here you have sBSTR loaded with the string passed by the script engine


Print *cast( Zstring Ptr, sBSTR )

If ParensPresent = TB_TRUE Then thinBasic_CheckCloseParens_Mandatory

End sub


Ciao
Eros

[kryton9]

Thanks for the info Charles. Yes I had Freebasic installed as well as tons of other languages, but my plate got so full I dropped it. So now I am concentrating on c++, but there is no end to it as it is so wide open. I decided after a couple of books to focus on a few key libraries and to see if I can do a project to meet my satisfaction.

It will be nice when FreeBasic reaches a stable release with all the features, I then think I will give it a good try. For my compiled language and thinBasic is already my choice for scripted languages. So things will hopefully be in synch in another year or so.

Another few questions:

Ok the cpu itself operates only in binary. Opcodes in Hex were created to help programmers write faster and easier to read code. Then Assembly was created later to help even further clarity compared to opcodes. Then C on top of that? Does this sound correct? Is there a performance drop off in each step, but made up for in increased productivity?

[Charles Pegge]

Hi Kent,

That is a point of view I would like to probe, There are obvious benefits in using very high level languages like HTML. The source code is easily accessible, and adaptable. HTML is rapidly learned by trying out different things and getting an instant result.

At the other extreme If you try to code in pure opcodes, getting results on small pieces of code is not too difficult either but beyond about 200 bytes , you start to lose track of the code. Without good annotation, the intention of the code is obscure.

I see two main challenges to the orthodox point of view that low level coding is too unproductive to be worth doing.

First is that with the x86 we are dealing with a very clever piece of silicon with an instruction set richer than many high level languages. Even at the individual instruction level it can do strings arrays and pointers, lookup tables, type conversion and parallel execution. Putting a high level language on top of this is often an act of simple substitution.

Second is that block structured programming and other contemporary methodologies can be applied to programming at any level. So why not try it with assembler and hex code, and see what difference it makes.

I found the most difficult part of machine coding is calculating relative jumps. If the code is changed then they all have to be adjusted, which becomes intolerable very early in the coding process. So a linking system is absolutely essential for machine code of any size. (The opcodes themselves are surprisingly easy to learn, at least the commonly used ones.)



'--------------'
' nested loops
'--------------'

b9 nl5
33 c2
(
b8 nl10
(
42
48 7f repeat
)
49
7f repeat
)

8b c2
c3

[kryton9]

First is that with the x86 we are dealing with a very clever piece of silicon with an instruction set richer than many high level languages. Even at the individual instruction level it can do strings arrays and pointers, lookup tables, type conversion and parallel execution.

That really surprised me Charles. I always came away with the idea that the instruction set was just very primitive simple register assignments, simple math and placing and retrieving from memory.

It is interesting research you are doing to find the perfect mix of productivity and power.