Re: VB language extensions wishlist


"Robert Conley" <robertsconley@xxxxxxxxx> schrieb im Newsbeitrag
news:e0e55e64-e82b-4348-ab42-0179a158062b@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Feb 17, 8:43 am, "Schmidt" <s...@xxxxxxxxx> wrote:

Would appreciate it, if we could end up with a true, machine-
code-emitting compiler, able to link BreakPoints to
Basic-Code.

FreeBASIC is moving to using the backend the GCC compiler
which is somewhat language neutral.
AFAIK no - where have you found that in the forums?
Currently they emit Assembly-Code, finally compiled
with the GAC.

So FreeBASIC doesn't emit C++ code but rather whatever
intermediate codes/files needed by the GCC backend.
From what I've read, it is planned, to have an *option*
in the compiler, to emit GCC compilable C-Source - mostly
to be able, to support other (non-X86) processor-architectures
like e.g. ARM-Cores, which are used on the typical HandHelds.

It has a downside in that "new" side of FreeBASIC reflects the
capabilities and limitations of the backend. For example the new
FreeBASIC doesn't have GOSUB RETURN. FreeBASIC
preserve QuickBASIC compatibility via a flag -lang qb and
you get the ability to use GOSUB..RETURN but not the
new stuff.
Yes, that's true - the "new-style" Freebasic doesn't allow
GoSub anymore - but as said, if there'd be a fork - or
better yet, a compiler-enhancement or -switch ('-lang VB'),
then it should be possible, to put this back in, from the
older "-lang qb" codepath.
The GoSub-elimination probably comes from the
capability, to return a Function-Result in "C-Style"
using 'Return Something'. But I've just tested this -
and it gives an compile-time-error, if 'Return' is
used without any Result-Expression - so the compiler
is already capable, to differentiate between a "blank Return"
(usable for GoSub) and returning a Result in C-Style.

The thing with the MONO runtime is that it may be easier
to adapt that to COM than with the GCC Backend.
While .NET isn't backwards compatible it not that different
than how COM does things. Plus using the MONO
runtime will allow the option to ignore the limitations of
COM if a programmers decides to do so.
Yes, going Mono (using an adapted Mono-VB-Compiler)
could also be an option for the future - will have a look
at that too in the next years.

But "going FreeBasic" also has its charme, because of the
really small standalone-Exes, which it is currently able to
create using the GAC (Assembler-compiler).
Greatest lack in the current FreeBasic-features (one can
implement Objects in the meantime) is, that its Obj-Orientation
currently works without using any strict Interface-Definitions
in the sense of "abstract contracts", definable in the language
itself. But coding such a contract outside of FreeBasic
(using MkTypLib or Midl) is possible.
That way one can write a COM-compatible Dll, using
VTable-defines, Properties, Methods, etc. inside FreeBasic.
I've just tested this, compiling the whole thing to a Standard-
Win-Dll and can now use these "lightweight" FreeBasic-Com-
Object" inside VB over the matching TypeLib with full
intellisense.
Creation-Time for 1-Mio smaller COM-Obj-Instances:
0.39sec
(all measured from inside VB - acting as the "consumer")
Destroy-Time of these 1Mio-Objects was even faster: 0.16sec.

Each Obj-Instance only allocating 32Bytes (implemented 4
simple "Long-Properties", only for testing) - so the Mem-Overhead
is currently 16Bytes for an empty COM-Class (that is
ca. 7 times less than an empty VB-defined Class).
All done with full RefCounting in the COM-Implementation
aka "Auto-Destroying built in" - no Mem-Leaks, works
great without using the Registry, because the FB-Standard-Dll,
which hosts the Implementation only exports one Public
Function, which you have to Declare inside VB:

Declare Function NewInstance Lib "FBTest.dll" () as IMyClass.

Nice thing, this refreshed FreeBasic-compiler - will investigate it
further.

Olaf


.

Relevant Pages

  • Re: ASPX unable to find class properties
    ... while the compiled code is in the gac, the .net compiler (when it compiles ... the aspx page) needs additional information that is stored in the dlls. ... where we have the Assemblies loaded in the GAC. ... > actual class property in the ASPX code-behind file, ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Exiting from a Do Loop
    ... Poor Performance with the GoSub Statement ... and slower by quite a bit if compiled to native. ... Why wouldn't an "optimizing" compiler simply inline all the GoSub code where ... Are you optimizing for speed or program size? ...
    (microsoft.public.vb.general.discussion)
  • Re: Exiting from a Do Loop
    ... Poor Performance with the GoSub Statement ... PCode, and slower by quite a bit if compiled to native. ... Why wouldn't an "optimizing" compiler simply inline all the GoSub code where ...
    (microsoft.public.vb.general.discussion)
  • Re: Exiting from a Do Loop
    ... Poor Performance with the GoSub Statement ... and slower by quite a bit if compiled to native. ... Why wouldn't an "optimizing" compiler simply inline all the GoSub code where ... Are you optimizing for speed or program size? ...
    (microsoft.public.vb.general.discussion)
  • Re: Exiting from a Do Loop
    ... Poor Performance with the GoSub Statement ... PCode, and slower by quite a bit if compiled to native. ... Why wouldn't an "optimizing" compiler simply inline all the GoSub code where ...
    (microsoft.public.vb.general.discussion)