FreeBASIC And/Or Inline Assembly

Started by Donald Darden, June 15, 2007, 12:03:44 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Donald Darden

I finally decided to download FreeBasic from the Internet last night and install it.
After all, it is free, and some examples and discussions have already been presented here on this forum, and there is a version for Windows, and another for
Linux.  So far, that is as far as I've gotten.  There is a lot too it, but where to start is the next issue.

But from other discussions, I know that FreeBASIC is a contender for at least four reasons:  One is that it builds on the syntax introduced by Microsoft in its own BASICs, which should make it a popular choice.  Two is that being free, it offers choice without a major reinvestment. except for time and effort.  Three is that it is supported on Linux, which is not presently an option with PowerBasic.  And four, it supports Inline Assembly code, which many developers look for in their languages of choice.  We don't all need assembly coding for our work, but we usually know that anything lacking in the high level language can still be
supported and obtained through low level coding.  It is something to fall back on.

Now coding in assembly using the inline assembler capability demands that you
know something of the assembler that is being used, and of the interface between the two levels involved.  How do you reference variables and arrays for instance?  What notation is acceptable to the assembler?  Where can I find a
good reference, example code, help, and guidance?  That is hopefully what this forum will come to represent.     

Charles Pegge


Donald, Here is something you will enjoy!

1. write  a very simple program using notepad:
PRINT 42

2. save it as test.bas

3. in the freebasic console, compile it like this


fbc -r test.bas


4. using notepad you will be able to read the resulting test.asm

Voila! This will reveal the internal workings of Freebasic
and show you the syntax used by the 'AS' assembler which Freebasic uses.


And here is a page from the online freebasic manual show you a simple
inline assembler example.

http://www.freebasic.net/wiki/wikka.php?wakka=KeyPgAsm

and the index to the Freebasic online manual is here:

http://www.freebasic.net/wiki/wikka.php?wakka=DocToc

Charles Pegge

#2
Another example posted here in the downloads section, showing the same code in Powerbasic then Freebasic

Pythagoras Number Cruncher:

http://www.jose.it-berater.org/smfforum/index.php?topic=971.0

Donald Darden

#3
Not having delved into FreeBasic before, and having just done a quick overview, I am very impressed with what I've read.  Undoubtedly, many people are going to be happier with PowerBasic because it Integrated Development Editor gives you the ability to compile and run a program, as well as debug it on the fly, and those are mighty inducements to its continued use.  But from what I've read thus far, there is much to like about FreeBasic as well.

Now since this thread is intended to focus some added attention on the use of
the Inline Assembler, it might be of value to look at some of the extracts from the
online FreeBasic manual (the link was provided above):

Syntax
The syntax of the inline assembler is a simplified form of Intel syntax. Intel syntax is used by the majority of x86 assemblers, such as MASM, TASM, NASM, YASM and FASM. In general, the destination of an instruction is placed first, followed by the source. Variables and functions defined by a program may be referenced in an Asm block. The assembler used by FreeBASIC is GAS, using the .intel_syntax noprefix directive, and ASM blocks are passed through unmodified, except for the substitution of local variable names for stack frame references, and commenting removal.

Register Preservation
When an ASM block is opened, the registers ebx, esi, and edi are pushed to the stack, when the block is closed, these registers are popped back from the stack. This is because these registers are required to be preserved by most or all OS's using the x86 CPU. You can therefore use these registers without explicitly preserving them yourself.

Register Names
The names of the registers for the x86 architecture are written as follows in an Asm block:
# 4-byte integer registers: eax, ebx, ecx, edx, ebp, esp, edi, esi
# 2-byte integer registers: ax, bx, cx, dx, bp, sp, di, si (low words of 4-byte e- registers)
# 1-byte integer registers: al, ah, bl, bh, cl, ch, dl, dh (low and high bytes of 2-byte -x registers)
# Floating-point registers: st(0), st(1), st(2), st(3), st(4), st(5), st(6), st(7)
# MMX registers (aliased onto floating-point registers): mm0, mm1, mm2, mm3, mm4, mm5, mm6, mm7
# SSE registers: xmm0, xmm1, xmm2, xmm3, xmm4, xmm5, xmm6, xmm7

'' This is an example for the x86 architecture.

Function AddFive(Byval num As Integer) As Integer
    ASM
        mov eax, [num]
        add eax, 5
        mov [Function], eax
    End ASM
End Function


Note that both FreeBasic and PowerBasic automatically same the same
registers and restore them for you.  Also note that you can lead each assembly
instruction line with ASM for both compilers, or you can use the exclamation
mark as an alternative in PowerBasic, but only FreeBasic provides the use of an
ASM block as shown above.  Another difference is that both compilers support
the use of the keyword FUNCTION for returning a value, but FreeBasic wants it
in a square bracket.  Further, FreeBasic's inline assembler is case sensitive when
it comes to lables, and PowerBasic is not.

Chuck Hicks

QuoteUndoubtedly, many people are going to be happier with PowerBasic because it Integrated Development Editor gives you the ability to compile and run a program, as well as debug it on the fly

There are several IDEs available for FB, as well.  It has many advantages over PB, especially the fact that it's written in FB (PB is written in assembler AFAIK), which is why it has advanced so rapidly.  It also allows the use of the vast number of standard libs, with pre-built headers for many of them, and a tool to build headers for the rest of them.  Using standard libs with PB is a royal pain, requiring countless hours of header conversion (unless Jose or someone else has done them for you).

The fact that FB has long been available under Linux should be a huge embarassment for PB, which has been promising a Linux version "soon" since at least 1998, despite its purported "no vaporware" policy.

About the only remaining advantage PB has is not due to PB itself, but to the excellent third-party GUI builders FireFly and Phoenix.  I would highly encourage their designers to consider expanding their products to use FB.

As for PB's debugger - does anyone actually use it?


Theo Gottwald

#5
Seems, me is the only one using the PB Debugger.

I have taken a look on FB last time and the keyword-list is very complete, has many features I wish I would have with actual PB.
For example Modules, Classes.

Reading the readme to the 3.17b , the authors said "there are sure bugs inside" or something in that sense.
Thats why I have 3 question:

1. How bulletproof are complex FB programms?
2. I am missing the IDE with the integrated Debugger. While there are IDE's, I do not see any reason, why not to use UEdito or UEDIT STUDIO, because the IDE seems not to have any special features which can't be integrated in UEdit (like the PB-Single Step Debugger).
3. Did anyone test the compiled result in terms of speed against PB?

Just from the keyword-list, taken the situation that I would be new to this stuff, I'd actually choose FB before paying for PB with partly significant less features (while I did not see any DDT Commands in FB:-)).

Besides that I saw the FB-Debugger, I personally would have prefered to see a switch in the IDE for "single step" and ... just like its in any normal programming languages starting from the first version of Visual Studio/VB.
Sometimes stepping through a complex programm is a help on finding errors, especially for beginners.

If that would be included, like it is in PB, Freebasic would be an reasonable Alternative - from the first look.

Paul Squires

Quote from: Chuck Hicks on June 18, 2007, 05:35:52 PM
About the only remaining advantage PB has is not due to PB itself, but to the excellent third-party GUI builders FireFly and Phoenix.  I would highly encourage their designers to consider expanding their products to use FB.
FireFly3 will have some level of support for FreeBASIC. You can count on that.  :)
Paul Squires
FireFly Visual Designer SQLitening Database System JellyFish Pro Editor
http://www.planetsquires.com

Paul Squires

IIRC, the FreeBASIC programmers are hard at work converting FB to be a front end language for gcc. Once that happens, gcc will do the actual compiling and, more importantly, code optimizations. FB is an exciting language even given its relative newness. FB does integrate with the InSight Debugger, but I have gotten so used to not using a debugger (since I left Visual Basic, I can not use PB's debugger), that the absence of a debugger does not mean much to me.
Paul Squires
FireFly Visual Designer SQLitening Database System JellyFish Pro Editor
http://www.planetsquires.com

Eros Olmi

#8
Quote from: Theo Gottwald on June 18, 2007, 08:47:20 PM
3. Did anyone test the compiled result in terms of speed against PB?

I did a stupid speed test comparison some time ago about STR$ and remain astonished: on my Core Duo FB is much faster than PB on this specific test.
Again, it is a specific test covering just a single string function so ...  ;) ... you have got it!

The idea was to have a personal impression on how to use FB to write modules (DLLs) for thinBasic. During my tests I got some strange behave like having random GPF solved recompiling again the DLL or inserting few more lines of code close to the point where the GPF occurred. Code was really very simple so no way there was an error from my side.

See attached speed test files.
thinBasic Script Interpreter - www.thinbasic.com | www.thinbasic.com/community
Win7Pro 64bit - 8GB Ram - Intel i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

José Roca

 
Eros,

Your test only shows that the Microsoft OLE string engine is not the more adequate tool to build strings concatenating characters one by one. For dynamic strings, PB uses the OLE engine, whereas those compilers that must work also in LINUX don't. However, they probably will have problems with buffer overruns and passing strings by value, whereas OLE sgtrings are safer. When I need to do many string concatenations, I allocate a big empty string and the use MID$.

Quote
I got some strange behave like having random GPF solved recompiling again the DLL or inserting few more lines of code close to the point where the GPF occurred.

A clear sign of memory corruption. If this happened with PB, everybody will cry: "Bring me the head of Bob Zale" :)

Charles Pegge

#10
For its long term future, Power Basic needs to be more closely aligned to C++, like Freebasic. As a mature product with a more comprehensive set of intrinsics, it still has an edge on the MS platform at least, but not for much longer. Freebasic already has more encapsulation ability needed for more complex projects,  with static library compilation, modules, block scoping and name spaces. (0.16b)

There is also the dilemma of how to survive in a market where most programming languages are available for free, even though PB is modestly priced. Perhaps that is why, there is a reluctance to produce a Linux version. For a console compiler, this would be a very simple, almost trivial task. Same for  the new Macs with the x86 processor.

In PB's favour though, I miss gosubs which I often rely on for fast functions that use a lot parental variables. Also, the inline assembler does not support inline data - db dd dq do not work so you cant directly insert opcodes in there, (where the assembler has no mnemonic for them).

I also find that Freebasic is very particular about the cast of its pointer variables, so if you try to use a byte pointer on an array of longs you get warning messages from the compiler. You have to use unions to get around this.

Donald Darden

#11
I've used PowerBasic through it's many versions, and one of the things that you can count on is that it is thoroughly tested, and if a bug is found, it will be fixed.
If I were writing a commercial application, that would be extremely important, not just to me, but to my customer as well.

FreeBasic is exciting because it is new, and being new it presents a challenge: Just how good is it?  What does it do well?  What are its weaknesses?  I know that given the choice of having a debugger available or not, I would opt for the debugger where possible.  Trying to debug code without one can be trying, and often means writing special code and embedding it in your program to quickly show current variable and registry settings, with pauses to give you time to read them.  You then have to turn around again to remove the excess code when the problem has been found.  If that is the way you are content to debug, then you do not need to use a separate debugger.  But a debugger effectively posts the variables and registers for you, and allows you to set breakpoints or single-step your code to get the same results, and these steps do not mean altering your source code in any way.  That offers you a potential savings in time over writing your own debugging code and inserting it, then carefully weeding it back out again.

Eros Olmi

Being a PB user since many years, I've learned to live without a debugger.
In any case I strongly feel something is missing on this side especially when ytou have to deal with big and complex projects like thinBasic where just core source is about 97000 lines without counting WIN32API.INC

So, persoanally, I would pay something more if I could get a real debugger, let's say like ... VB6  ;D
thinBasic Script Interpreter - www.thinbasic.com | www.thinbasic.com/community
Win7Pro 64bit - 8GB Ram - Intel i7 M620 2.67GHz - NVIDIA Quadro FX1800M 1GB

Paul Squires

Quote from: Eros Olmi on June 19, 2007, 11:28:55 PM
Being a PB user since many years, I've learned to live without a debugger.
In any case I strongly feel something is missing on this side especially when ytou have to deal with big and complex projects like thinBasic where just core source is about 97000 lines without counting WIN32API.INC

So, persoanally, I would pay something more if I could get a real debugger, let's say like ... VB6  ;D
Eros, I agree 100%. All my projects are very large and I gave up using the PB Debugger a long, long, time ago. I'm sure that it works as advertised but it is way too slow and cumbersome for me especially when compared to a debugger like VB6 (its hard to get any better or easier to use than VB's).
Paul Squires
FireFly Visual Designer SQLitening Database System JellyFish Pro Editor
http://www.planetsquires.com

José Roca

 
When I try a new compiler I usually run the debugger once, just to see how it looks, then I use:


' Enable debugging
%ENABLE_DEBUG = 1                 ' 0 to disable debugging, 1 to enable

' ****************************************************************************************
' Macro based in the one posted by Paul Squires:
' http://www.powerbasic.com/support/forums/Forum7/HTML/001963.html
' DebugView or other debugging utility that intercepts OutputDebuigString must be running.
' You can download the freeware SysInternal's DebugView application at:
' http://www.sysinternals.com/ntw2k/freeware/debugview.shtml
' Note: Since OutputDebugString expects an ASCIIZ string, I have added the BYCOPY to allow
' the use of dynamic strings.
' ****************************************************************************************
MACRO DP(st)
  #IF %ENABLE_DEBUG
      OutputDebugString BYCOPY st
  #ENDIF
END MACRO
' ****************************************************************************************


No need to remove anything. Just set %%ENABLE_DEBUG = 0.

And, unlike the PB debugger, it can be used to debug DLLs, and there is no problem to show the values of deferenced pointers.