FreeBASIC 1.08 Development

[marcov]

On Linux I haven't yet seen an llvm package that didn't include llc...

If you include crosscompiling toolchains, the Android NDK for Linux doesn't include it and apparently never has. I just downloaded the latest NDK to check it doesn't have it either. In fact the changelog says that "as" will be removed in a future release, and clang should be used to assemble asm instead! (But presumably llvm-as can be used.)

I can also remember messages on the mac list of FPC, that this happened with a newer OS X or XCode too. (requiring clang to assemble), so probably that is the new norm.

[TeeEmCee]

On Unix it's not too bad, but on Windows I feel uneasy about making fbc invoke an extra commandline program, due to the time it might take. Should we not worry? The lower-overhead alternative is to recover if llc fails to run.


Yes, system "as" on Mac has been llvm-as for a few (XCode?) releases now. That's actually excellent, because the old "as" wasn't gas, it was forked from FreeBSD "as" close to 30 years ago and had been stagnant for most of that time. It didn't properly support Intel syntax. That's the reason that FB's "gas" backend didn't work on Mac; IIRC it does work with recent llvm-as, which is fairly compatible with gas.

So that's slighty different to the NDK replacing GNU binutils with LLVM, although I think forks of some other parts of GNU binutils were used on Mac.

[angros47]

Neither Emscripten seems to include llvm anymore (I had to remove all the references to it to get FreeBasic work with Emscripten)

Also, Emscripten, too, used clang and not gcc

[coderJeff]

At the very least it should be made clear what aspect of C compatibility is meant, ...

There's 3 areas where "gcc/c" and "g++/c++" influence the project.

Language features:
- C like pointers using '*' to dereference
- in some contexts C like arrays / pointer indexing using '[index]' to access
- const qualifiers
- function overloading like in c++ most of the time, but fbc also allows some overloading of types not possible in c++
- in some contexts c++ like references (&) using 'byref' in fbc

As a backend target for compiling:
- instead of emitting to assembly, emit to a C representation using the C compiler as a high level assembler where language constructs are reduced to C using if / goto / call within C procedures and C types and structs for data
- this can be challenging on newer gcc's depending on what C standard the C compiler is enforcing

Linking to external libraries:
- linking to C libraries directly was in fbc from the start, especially with the compiler changing constantly, having the rtlib and gfxlib written in C to start with helped provide some stability and ease for development on the compiler side.
- it would be nice if I could say that linking to C libraries for certain targets work 100%. No wrappers. Just the original C documentation for the API plus a little information on calling procedures, passing arguments and data types.
- linking to some kinds of c++ libraries. I don't think this will ever be 100% compatible. Have tried to make the name mangling 100% compatible. But also using custom features of the name mangling scheme to allow for elements that are possible in fbc code, but not c++.


As for clang, llvm, and emscripten, I'll be honest and say that they are all somewhat of a black box for me currently, not having spent much time with the tool chains. I did get a *very* simple fbc program to compile for me with the llvm (llc.exe) backend on windows this past weekend. So that was exciting. I've tried several other times without success. Of course, lots of fails in the test-suite, so work to do there.

[marcov]

At the very least it should be made clear what aspect of C compatibility is meant, ...

There's 3 areas where "gcc/c" and "g++/c++" influence the project.

Language features:
- C like pointers using '*' to dereference
- in some contexts C like arrays / pointer indexing using '[index]' to access
- const qualifiers
- function overloading like in c++ most of the time, but fbc also allows some overloading of types not possible in c++
- in some contexts c++ like references (&) using 'byref' in fbc

While Pascal uses ^ for dereference (but allows to skip it) and VAR for byref. I can't find one FB specific bit in these examples, since they are nott really C/C++ compatibility but just renderings of general procedural principles presenting with vaguely C related syntax.

But the syntax doesn't count unless you go as far as really interpret C headers and mix-in C/C++ code, since any code will only meet after being translated to assembler.

Btw have two consts even. One purely "thou shall not modify", and one that forces const byref semantics, probably for the same reasons as your "in some contexts" limitations.

A better example might be classes derived from struct. E.g. FPC does not do it, so while maybe not 100% C++, it is at least somewhat less universal a choice. As said variant parameters is another such area.

As a backend target for compiling:
- instead of emitting to assembly, emit to a C representation using the C compiler as a high level assembler where language constructs are reduced to C using if / goto / call within C procedures and C types and structs for data
- this can be challenging on newer gcc's depending on what C standard the C compiler is enforcing

Not a purely FB thing as there is also backend GAS.

Linking to external libraries:
- linking to C libraries directly was in fbc from the start, especially with the compiler changing constantly, having the rtlib and gfxlib written in C to start with helped provide some stability and ease for development on the compiler side.

It was also in FPC from the start linking to go32v1 (yes, v1) early on, over ten years before FB. Keep in mind we are *nix since 1995, and linking to C is quite normal there. We could link to win64 mingw libraries, when mingw64 finally launched on 64-bit, because we were there first.

FB might have some better defaults (so that FB functions are default cdecl, structures are default C packed), but unless you think that that one extra line required in an header really is a fundamental paradigm shift (I don't), that is a detail.

- it would be nice if I could say that linking to C libraries for certain targets work 100%. No wrappers. Just the original C documentation for the API plus a little information on calling procedures, passing arguments and data types.

Just like earlier comments, it is conflating a superficial C orientation with C level hard binary compatibility. You can diverge many things as long as your final interface matches.

Please show one example where FPC needs a wrapper where FB doesn't. I can give you one counter example: FPC doesn't need to have an import library on Windows to call a DLL written in gcc. I also already gave you a few FB pros (default packing and calling convention is C like also GAS backend).

- linking to some kinds of c++ libraries. I don't think this will ever be 100% compatible. Have tried to make the name mangling 100% compatible. But also using custom features of the name mangling scheme to allow for elements that are possible in fbc code, but not c++.

We also have CPPclass which is an attempt to match gcc name mangling for simple calling of gcc C+ classes. We also have such schemes for Objective C interfacing using LLVM.

As for clang, llvm, and emscripten, I'll be honest and say that they are all somewhat of a black box for me currently, not having spent much time with the tool chains. I did get a *very* simple fbc program to compile for me with the llvm (llc.exe) backend on windows this past weekend. So that was exciting. I've tried several other times without success. Of course, lots of fails in the test-suite, so work to do there.

Mostly they are limited, except maybe CLang (as it tries to be fairly gcc compatible). I don't think you can really call it a C backend till you support at least two compilers anyway.

In conclusion, IMHO there are some minor bits left and right, but roughly FB and FPC are equal in compatibility. However for some weird reason FB defines itself as C oriented, while FPC does not. Probably FB does so because it has some more unrelated but more visible syntactic borrowings from C, but that is irrelevant for compatibility.

[coderJeff]

marcov, I agree with everything you say, and I don't think I've ever put down FPC or claimed that FB is better than FPC. I get a weird vibe from your last post that you are trying to change my mind ... but I already agree with you. My responses are as plain and open as possible, but I think I see what happened...

Just like earlier comments, it is conflating a superficial C orientation with C level hard binary compatibility. You can diverge many things as long as your final interface matches.

I looked back at my own posts and see where I screwed up. Sorry, my bad. The question I was responding to had to do with "Mixing of .o files from C and from Fbc." and I was imprecise about the answer. Hopefully the posts since help clear that up. Thank-you with that.

In conclusion, IMHO there are some minor bits left and right, but roughly FB and FPC are equal in compatibility. However for some weird reason FB defines itself as C oriented, while FPC does not. Probably FB does so because it has some more unrelated but more visible syntactic borrowings from C, but that is irrelevant for compatibility.

Probably because we use the "C" identifier generically to mean many C-like things. I feel like some forum members don't know or care about the distinctions. They have their own opinions no matter what we say.

[Lost Zergling]

I personally think that the term "compatibility" is very generic. Are we talking about compatibility seen from the level below (syntax and methods of c, linker, etc.), compatibility from the point of view of the language user (or above, eg Wine), but it all depends on how the user uses FB which allows the addressing of distinct abstraction level already in its only syntax (c, c ++, historical basic style), on the design and the approach that the user has of the language . And there is not necessarily a link between proximity and / or compatibility with C and seniority, for example, I suspect the old -vec2 optimization to be very c-friendly (in the logic of low level optimization), rather than basic friendly. Languages ​​and libraries evolve, and low-level compatibility is no longer enough to offer attractive alternatives. Another aspect of compatibility (which will probably appeal to marcov) concerns performance, seen from the user's point of view: typically, I am thinking of the (relative but real) performance gap between the native pointers of the c and those implemented in FB. I understand that FB is "heavier" and has to "carry", in a way, more functionality, this would be the price to pay.
I come back to my initial point: extended functional scope, variability of uses, evolutions of languages, enrichment of libraries: it is very difficult to define precisely the term "compatibility", the only low level approach, although very relevant , seems to me both too narrow from a technical point of view and conceptually insufficient considering the fact that languages ​​offer more and more functional integration of interoperated levels.

[marcov]

marcov, I agree with everything you say, and I don't think I've ever put down FPC or claimed that FB is better than FPC.

That is not my intention. My intention is to compare FB that advocates a lot of "we are like C" (compatible) sentiment, with FPC that doesn't, to see what the "we are like C" like comments are worth, and to categorize them a bit (in e.g. syntax, features, linking or code porting)

If I a bit fierce that is because I dislike such wide C compatibility statements, knowing that it is more spin then reality. It is just minor annoyance, not an attack.

Probably because we use the "C" identifier generically to mean many C-like things. I feel like some forum members don't know or care about the distinctions. They have their own opinions no matter what we say.

Indeed.

[speedfixer]

marcov, I'm confused.

I learn a lot from you about languages and programming ... style?? (maybe, technique, attitude, history??)

But you are ALWAYS here selling FPC.

The topics here are FreeBASIC.

Compare and contrast - we learn something. A lot of what you have to say is informative and helps many make better decisions.

As gentle as I can say it:
Work to sell FPC over FB, and I think you turn a lot of people off.
We get it: you are an FPC fanboy. But turn down the volume: we don't care.

So - why are you here?
I don't want you to go away; I don't think anyone wants that.
But stop SPAMMING the virtues of FPC.


david

[Lost Zergling]

I hope to have an opinion built in a personal way and whatever one can say about it, nevertheless, on the other hand, that does not prevent me from trying to listen to those of the others (noted the technical proximity between FPC and FBC). To this end, I consider that giving my opinion aims to participate in the debate and not to pretend to have the truth. As proof of this, there is also a post that I opened recently, to call on those who wish to give their opinion on the list engine, as well as to open some of the ins and outs of my reasoning. (I'm currently thinking about the possibilities and best ways to introduce concurrent access or effective hash tables on demand on list items to speed up searches). I also believe that any modern language should be able to provide mid-level data structures, including holistic and consistent overall logic, and I share CoderJeff's opinion that this should be possible via custom libraries. In addition and up to my opinion, the growing integration, or even the merger between llvm and Clang, highlights the challenge for a language to have independent value-added processes if it wants to be able to continue to master its philosophy of use.

[marcov]

marcov, I'm confused.

It happens :-)

I learn a lot from you about languages and programming ... style?? (maybe, technique, attitude, history??)

Good.

But you are ALWAYS here selling FPC.

Comparing to FPC, which is a different thing. I just take FPC as measuring rod.

For two reasons.

1. I know FPC best for some strange reason (*)
2. (specially in "C" discussions), how many languages/toolchains do you know to compare with, that are at least at some distance of GCC/LLVM and not commercial?

The topics here are FreeBASIC.

You'll see I most engage in general software engineering topics, and general FB course/direction. Comparisons are slightly more on topic in such topics.

Compare and contrast - we learn something. A lot of what you have to say is informative and helps many make better decisions.

But if I do I'm told I'm a FPC fanboy. Critical voices are not appreciated, and whatever sets you apart is exploited to beat you with (well, admittedly except some more senior members like Counting Pine and coderjeff with whom I have had this discussion before).

As gentle as I can say it:
Work to sell FPC over FB, and I think you turn a lot of people off.
We get it: you are an FPC fanboy. But turn down the volume: we don't care.

So - why are you here?

The best way to answer that is explaining why I joined mid-2006. FB was a young compiler with an own independent backend even though it still had a legacy RTS. (The latter still hasn't been fixed, and the former, the independent backend, has taken a backseat). Anyway, it was spunky and vibrant and developed itself quickly.

For me initially it was just a way to relive the decisions I had missed with FPC, having joined AFTER the initial period in 1997, also it was kind of kindred spirits.

All slightly different of course, since the options for FB in 2006-7 were different from FPC in the equivalent period 1993-1995. Back then, a win9x system was future tech, AS didn't have an intel mode, and even DJGPP was cumbersome, requiring high spec machines and having low dos compatibility.

Anyway, while I don't like the C backend option, I'm still curious how this works out in practice, since precious little can be found about the details of such technology, specially on non-*nix. It is always the same basic mantra (blabla, get optimization for free), and never a critical sound/downside.

However I am a bit disappointed in that it seems that FB is nowadays going with the flow more(iow implement what is possible with minimal work) rather than set an own course and do whatever needs tobe done to get there. It was what I was afraid of when the C backend emerged (for proof: search the forum).

The problem is that if you have something big and external in your system, going against it becomes painful.

I don't want you to go away; I don't think anyone wants that.
But stop SPAMMING the virtues of FPC.

That is simple then, keep the discussions then to the point, and don't claim things for FB it can't (yet) deliver, and I don't have to compare it unfavourably to other toolchains. FPC or otherwise. Or simply stop seeing minor criticism as spamming.

If somebody claims C compatibility, I expect to be able to copy and paste C code, or at the very least, to use C headers, not having some superficial syntax similarity, and being able to link to C (which is nigh on universal with programming languages nowadays)

(*) which might have to do something with being a (minor) FPC core member.

[jj2007]

I should keep out of this debate, maybe, but just to throw a stone in water: try a Google search with
site:freebasic.net build error compiler

Far too many threads here deal with build problems, with too many toolchains and too many options that are supposed to make FreeBasic "better", whatever that means. IMHO some are desperately trying to mimic C++ features, like Templates, Constructors, Lambda Expressions, Closures, Generics, Exception-Handling, Interfaces/Polymorphism

And yet, when I try to build a very, very simple Windows GUI example, the compiler greets me with lots of error messages that can be "healed" only with significant typecasting acrobatics. This is sick, this is not BASIC.

A BASIC dialect is supposed to be easy to understand, and to do its job without the user having to study a 1000-page manual, as it is the case for C++.

If FreePascal is less complicated, then I wouldn't be surprised if n00bs chose to drop the BASIC idea and learn PASCAL instead. I love BASIC, but there are limits.

[caseih]

And yet, when I try to build a very, very simple Windows GUI example, the compiler greets me with lots of error messages that can be "healed" only with significant typecasting acrobatics.

That's the way I've always felt about win32 programming in any language. In FB's case those acrobatics are required in the native C, and FB is interfacing directly with that C api rather than implementing yet another layer on top of it like you seem to be wanting. In short, win32 programming really isn't a good fit for FB if you want to program using the familiar BASIC language and paradigm. Certainly I wouldn't expect a beginning programmer to attempt even the simplest raw Win32 GUI in FB. And that brings it back around to the age old existential debate about FB. Should FB have a built-in GUI system? Other BASIC systems do, but that comes with limitations regarding platform and look and feel. Often very limited.

I seriously doubt FB is going to bleed users to FPC. Both are niche compilers, used mostly by enthusiasts.

[marcov]

I seriously doubt FB is going to bleed users to FPC. Both are niche compilers, used mostly by enthusiasts.

Indeed. If a user of a niche language changes language, it usually goes overboard on the other end. As commercial and popular as possible.

Still JJ raises some good points, usability is important, specially if you have beginners as a potential target group

About FB orientation, that is indeed a different discussion, and one that I never understood to begin with(Beginners forever? If so, where are they, I only see many old amateurs, but very few real beginners, as in young, new beginners. Making games? In retro (dos, windows shareware) style?)

[jj2007]

Certainly I wouldn't expect a beginning programmer to attempt even the simplest raw Win32 GUI

Code: Select all

GuiParas equ "A full-fledged raw Win32 GUI that can open and save Rtf and plain text files", icon Ball, b Turquoise	; title, icon, background
GuiMenu equ @File, &Open, &Save, -, E&xit, @Edit, Undo, Copy, Paste	; define a menu (only Open & Save are implemented)
include \masm32\MasmBasic\Res\MbGui.asm
  GuiControl RichEdit, "richedit", CL$()			; load what you find in the commandline
  GuiControl Status, "statusbar"
Event Menu
  Switch_ MenuID
  Case_ 0 	; Open (menu entries start with 0)
  	If_ FileOpen$("FB sources=*.bas|Includes=*.bi;*.inc;*.h|Resources=*.rc|All files=*.*") Then SetWin$ hRichEdit=FileRead$(FileOpen$())
  Case_ 1 	; Save
  	FileWrite CL$(), stream:hRichEdit	; save contents of the RichEdit control
  	SetWin$ hStatus=CL$()+" was saved"
  Endsw_
GuiEnd

I'm afraid this 14 lines source builds only on a small share (75%) of the desktop market. If that applies to your machine, here you can download the exe.

specially if you have beginners as a potential target group

Should a BASIC dialect not have beginners as a potential target group? Why?

About FB orientation, that is indeed a different discussion, and one that I never understood to begin with(Beginners forever? If so, where are they, I only see many old amateurs, but very few real beginners, as in young, new beginners. Making games? In retro (dos, windows shareware) style?)

You hit the nail on the head.