-gen GCC and 64bit exes

For other topics related to the FreeBASIC project or its community.
albert
Posts: 5927
Joined: Sep 28, 2006 2:41
Location: California, USA

-gen GCC and 64bit exes

Postby albert » Dec 08, 2011 3:50

You guys probably won't like this since its from a competitor.

QB64 spits out C code and has all the C , ASM tools with it
and can supposedly spit out 64bit exe's.

Its confusing theres multiple directories with C,ASM tools. and they seem to have the same names, and i don't know how to tell if its a 64 or 32 bit exe.

The tools might be useable to the -gen GCC ers

It also has a fully functional QBasic PLAY() command. but does not support the ON PLAY() command.
marcov
Posts: 3049
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: -gen GCC and 64bit exes

Postby marcov » Dec 08, 2011 8:43

albert wrote:You guys probably won't like this since its from a competitor.

QB64 spits out C code and has all the C , ASM tools with it
and can supposedly spit out 64bit exe's.


Ok, let's assume htat.

Its confusing theres multiple directories with C,ASM tools. and they seem to have the same names, and i don't know how to tell if its a 64 or 32 bit exe.


Who has multiple directories? QB64? But yes, reusing external tools promise quick development, but one also imports their management and version problems.

The tools might be useable to the -gen GCC ers


If they are usable, they mostly like come from the same source as where the -gen GCCers get them in the first place.

But the FBers will most likely want to get the gcc version the -gen GCC option was tested with.
albert
Posts: 5927
Joined: Sep 28, 2006 2:41
Location: California, USA

Postby albert » Dec 08, 2011 13:31

I myself prefer the .ASM outputs of FB. it makes really small .EXE's

I would prefer if the coders would just make it so FB spits out 64bit .ASM files and then calls "AS".

Probably alot of coding hassles to get it to output 64bit. though.

But the PLAY() command i think they should steal though, since QB64 has stolen many FB sources and put them into QB64.
(if you go thru the QB64 forum you will see many FB sources ported to it.)
counting_pine
Site Admin
Posts: 6237
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Postby counting_pine » Dec 08, 2011 16:58

albert wrote:But the PLAY() command i think they should steal though, since QB64 has stolen many FB sources and put them into QB64.
(if you go thru the QB64 forum you will see many FB sources ported to it.)
I don't think we should steal code from QB64, or anywhere else. Even if QB64 contains code stolen from FB, that doesn't mean FB should contain code stolen from other projects.

Also I don't think that much has been "stolen". The only inspiration I know about is the RND algorithm which I reverse-engineered, but that was probably taken from forum posts, not the final code included in FB. And if people are porting code written in FB to work in QB64, there's nothing we can/should do about that.

And besides, I suspect QB64's Play() function is very much dependent on SDL, which we don't use.

If anyone ever writes a cross-platform version of Sound() and incorporates it into FB, then it shouldn't be too hard to base Play() off that.
Landeel
Posts: 763
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Postby Landeel » Dec 08, 2011 17:42

I don't think "stealing" is the right word.

Open Source is about sharing the code, even for using it in other projects.

QB64 can use FreeBASIC's code and vice versa, as long as the licenses are respected.

Nobody is stealing anything.
AGS
Posts: 1284
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Postby AGS » Dec 09, 2011 1:03

QB64 uses the 64 bit mingw toolchain. fb is using the 32bit mingw toolchain. The problem with the 64bit toolchain is that it's an unofficial one. I has not been created by the creators of mingw.

http://mingw-w64.svn.sourceforge.net/ came about (I think) because the mingw developers did not come up with a 64bit mingw version.
mingw-w64 is still small in terms of number of downloads per week.
'Only' 3000+ downloads per week. Mingw gets downloaded almost 1.000.000 times a week.

The QB64 compiler works a bit like many interpreters out there: it 'dies' at the first syntax error it finds. The FB compiler implements error recovery and can find multiple errors because of error recovery.

Last but not least: the lack of mingw 64bit support could be one of the reasons why a 64bit version of fbc never came about.
There is little point in having a front end that produces code that can be compiled using a 64 bit C compiler/assembler if that C compiler is not available.

I wonder how long it will take the mingw-w64 developers to surpass the 'official' mingw version in terms of downloads. You just gotta love those little 'wars' between clones and originals.

Anyone want to do a fbc clone ;) (just kidding of course).
Last edited by AGS on Dec 13, 2011 0:07, edited 1 time in total.
pestery
Posts: 493
Joined: Jun 16, 2007 2:00
Location: Australia

Postby pestery » Dec 09, 2011 6:39

Just out of curiosity, how hard would it be to adapt the fbc to also generate 64bit code (either for GAS or GCC or both)? For example, would the basic variables like Byte, Short, Integer, etc have to have their code re-written?
Richard
Posts: 3047
Joined: Jan 15, 2007 20:44
Location: Australia

Postby Richard » Dec 09, 2011 7:08

The easiest way to generate 64 bit code would be to finish the C-emitter, then use an optimising 64 bit C compiler.

The data types you define in your source that are less than 64 bits would be handled by the C compiler, your source would not change.

IMHO the problem is the time we take to understand, specify, write and debug source code, not the speed our code runs once compiled.
albert
Posts: 5927
Joined: Sep 28, 2006 2:41
Location: California, USA

Postby albert » Dec 09, 2011 8:42

@Richard I don't know?

I'm using FB because I prefer the BASIC simplicity and syntax.
C,C++ code is not as easily read, it seems to be just to cryptic.

All programming languages that aren't intrepreted eventually compile to machine code.

Basic can be made to do everything that C,C++,Fortran,Pascal can do, its just up to the language coders to put the functionality into it.

Porting the whole standard C libs to BASIC seems a better choice, if you want that functionality.

I'm sure it wouldn't be that hard to write a C lib source porter program.
And GCC could also be ported to compile BASIC instead of C.

Maybe thats a project I should work on. While my Huh-Yuh language chatterbot is on the back burner.
marcov
Posts: 3049
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Dec 09, 2011 8:55

Richard wrote:The easiest way to generate 64 bit code would be to finish the C-emitter, then use an optimising 64 bit C compiler.


If there only were a crossplatform one. GCC is too UNIX centric. Ah well, maybe CLANG/LLVM in time.
Richard
Posts: 3047
Joined: Jan 15, 2007 20:44
Location: Australia

Postby Richard » Dec 09, 2011 11:11

@ Albert. I do not think you fully comprehend the implications of the FB C-emitter. What I think you are contemplating would entrench FB in the present environment, on the unsafe assumption that the present environment will not change again. QB4.5 expired when it's environment changed and it could not be economically evolved to follow those changes. FB needs to adapt to it's environment, while hopefully colonising more platforms, by parasitising C as the interface.

There are very few developers working on FB, there are no resources to rewrite FB every time the external software environment changes, or whenever new platforms become available. The C family has effectively become a standard high level equivalent to assembly code. At present C is the one common code family available for all serious platforms. There are an infinite number of monkeys working on optimising C compilers for 64 bit systems, so the majority of advances will appear first in C.

By using the C emitter, we get to keep the the FB syntax, FB can still be link to C libraries, FB gets the performance advances of C without delay, and others do the development work.

@marcov. If there are not compatible cross-platform C systems, then we can not expect FB to perform on multiple platforms either. Time is the great healer, everything must evolve or die.
marcov
Posts: 3049
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Dec 09, 2011 12:33

Note: I exaggerate some of the problems to make a point. A cynics view against your unbounded optimist view so to say. Still, the main point that the main platform, Windows, is relatively badly supported by this kind of thinking is absolutely valid, and NOT an exaggeration.

Richard wrote:@ Albert. I do not think you fully comprehend the implications of the FB C-emitter. What I think you are contemplating would entrench FB in the present environment, on the unsafe assumption that the present environment will not change again. QB4.5 expired when it's environment changed and it could not be economically evolved to follow those changes. FB needs to adapt to it's environment, while hopefully colonising more platforms, by parasitising C as the interface.


Problem is that FB tries to be something for beginners (mostly on Windows), and a unix like compiler construction kit for advanced programmers at the same time.

Throwing a beast like GCC into the mix, with associated build tools will only aggrevate that.

There are very few developers working on FB, there are no resources to rewrite FB every time the external software environment changes, or whenever new platforms become available.


Windows 32-bit and Linux x86 are still the same, and on an application level probably good for nearly a decade. (since the 64-bit editions happily run 32-bit stuff).

So no, it is not the changing software environment, but a desire to spread themselves too thin that is the problem: A project that can't manage one target wants to be multitarget.

The C family has effectively become a standard high level equivalent to assembly code.


Humbug. Not one development solution worth anything relies on intermediate C code. Only projects that want a patchy but quick multiplatform route go that way.

At present C is the one common code family available for all serious platforms.


True. But do we really want our users to install MSVC ?

There are an infinite number of monkeys working on optimising C compilers for 64 bit systems, so the majority of advances will appear first in C.


But it will also require monkeys doing bloody ungrateful work on the FB side to unlock that potential in FB. Not any generated C is guaranteed to actually unlock that optimizing potential.

And with caching compilers, profiling feedback etc, the build system to actually unlock that potential is still growing. None of which is terribly userfriendly.

By using the C emitter, we get to keep the the FB syntax,


We'll see. Usually quickly the unixisms (like problems with spaces in paths etc) and its build processes are appearing in the non unix ports.

FB can still be link to C libraries,


FB will be linked by default to C libraries. And potentially ones that are not the system C libraries, but POSIX emulation forms.

FB gets the performance advances of C without delay,


My gut says that it is not that easy. (since you must also generate code that IS optimizable). But since I'm not that experienced there, let's wait till there is really extended data about that.

and others do the development work.


... which you exchange for support working, since now your users also must create and maintain a vastly complex C compiler.

@marcov. If there are not compatible cross-platform C systems, then we can not expect FB to perform on multiple platforms either.


There are ways, but they are yet again more work. It is easy to generate C and show everybody a hello world on 20 platforms.

It is g*d*mn hard to create a consistent high quality development system based on a varying and independently versioned patch work of external packages (think gcc, binutils, msvc, make, and the rest )

Time is the great healer, everything must evolve or die.


I think trying to go (more) multiplatform if you are already development resources limited, is equivalent of going to die. IMHO if you go that direction, save yourself the trouble to pretend to support windows.

People will just be coming with more and more incompatibilities, and for every common feature you have to hybridize something between Windows and *nix, eating up resources (*)

If you really buy into this *nix way of thinking, you need to follow it through all the way, and do if the entire world is on *nix.

And all this while FB's direct competitors, the various other Basics are relatively integrated and well rounded development systems.

(*) and I've been doing this for 12 years now, so I know what I'm talking about.
Richard
Posts: 3047
Joined: Jan 15, 2007 20:44
Location: Australia

Postby Richard » Dec 09, 2011 18:06

@ marcov.

It surprises me that you see my partial list of the positive advantages to the FB C-emitter as “unbounded optimism”. There are significant bounds to my optimism. I have seen the same mistakes being made over and over again. I was simply arguing positively against building the FB language in a way that would freeze it in time.

To argue the way you do suggests that you must be strongly opposed to the implementation of the FB C-emitter. My post certainly struck a nerve there. You could have been positive, but the fear, uncertainty and doubt that you cast upon my every statement, in what is clearly a rhetorical attack, suggests that you are embarrassed by your inability to present any real alternative solution that could make FB portable in the longer term.
Sannaj
Posts: 27
Joined: Dec 19, 2010 16:39

Postby Sannaj » Dec 09, 2011 22:09

marcov wrote:If there only were a crossplatform one. GCC is too UNIX centric. Ah well, maybe CLANG/LLVM in time.


LLVM would be a good idea. It will solute the portability problems of fbc. Its a much more modern and easier accessible them gcc.

Clang is only a front end compiling C languages into the llvm-byte code. It won't be very useful to emit C code, witch clang then compiles into llvm-bytecode.
marcov
Posts: 3049
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Postby marcov » Dec 09, 2011 22:59

Richard wrote:
To argue the way you do suggests that you must be strongly opposed to the implementation of the FB C-emitter. My post certainly struck a nerve there.


Definitely. When I heard the umpteenth person recite these platitudes without any nuance, I got terribly depressed.

You could have been positive, but the fear, uncertainty and doubt that you cast upon my every statement, in what is clearly a rhetorical attack,


Ridiculous.

suggests that you are embarrassed by your inability to present any real alternative solution that could make FB portable in the longer term.


I thought that that was clear: don't widen the scope of the project till you have the resources. If you spread yourself too thin, you might actually regress instead of progress. Projects don't grow out of optimism. They grow due to skilled labour.

And aside from that, I have heavy doubts about

1. The work needed to get all the said benefits actually from the C-emitters
2. The work needed to craft and maintain an enduser friendly distribution.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 16 guests