-gen GCC and 64bit exes

General discussion for topics related to the FreeBASIC project or its community.
marcov
Posts: 3462
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Post by marcov »

Sannaj wrote:
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.
Possibly. but an year ago the Windows state of LLVM was pretty sorry too. Same problem as gcc, basically.
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.
As useful as cgen now. I named CLANG/LLVM more as a possible combo that might avoid some of the problems of GCC (buildsystem, bad windows support). I didn't mean to suggest we should go the bytecode way. (IMHO that is as dangerously optimistic, maybe even worse as cgen)
Sannaj
Posts: 27
Joined: Dec 19, 2010 16:39

Post by Sannaj »

marcov wrote: Possibly. but an year ago the Windows state of LLVM was pretty sorry too. Same problem as gcc, basically.
You might be right, since llvm is splitt up in different programms and I don't know somthing like MinGW for this framework
We would probatly need to use our own port of the framework, like we do with the Windows Versions of as/ld/ar/etc.
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.
As useful as cgen now. I named CLANG/LLVM more as a possible combo that might avoid some of the problems of GCC (buildsystem, bad windows support). I didn't mean to suggest we should go the bytecode way. (IMHO that is as dangerously optimistic, maybe even worse as cgen)
I don't get you point. What's the problem with llvm bytcode? It is not comparable with things like Java or .Net bytcode. Llvm bytcode is only used as a plattform + language independent form of representation during the optimisation stage. GCC has got something similar, but it is compiler programm internal there.
From my point of you using clang as a backend would be only usefull to use the cgen backend with llvm.
marcov
Posts: 3462
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Post by marcov »

Sannaj wrote:
marcov wrote: Possibly. but an year ago the Windows state of LLVM was pretty sorry too. Same problem as gcc, basically.
You might be right, since llvm is splitt up in different programms and I don't know somthing like MinGW for this framework
(and IMHO msys/mingw is already sub-par)
We would probatly need to use our own port of the framework, like we do with the Windows Versions of as/ld/ar/etc.
That's exactly the stuff I'm hinting about. What you gain in "getting optimization cheaply", you loose on other fronts.
I don't get you point. What's the problem with llvm bytcode? It is not comparable with things like Java or .Net bytcode. Llvm bytcode is only used as a plattform + language independent form of representation during the optimisation stage. GCC has got something similar, but it is compiler programm internal there.
Nothing an sich. More that it is yet another dimension more work, and thus less likely to succeed.
From my point of you using clang as a backend would be only usefull to use the cgen backend with llvm.
Correctly. I was talking about the hidden costs of cgen, and that gcc was not as ideal (since fairly bad on windows, half of the PE features are not supported, e.g. thread and TLS tables?).

So I was talking about switching out gcc for clang for cgen purposes, to show that even with the "other" free/portable C compiler Windows is underwhelmingly supported.

The point being that Windows, the most used FB target might actually decrease sharply in usability and quality, because some want portability (if only on paper) at all costs.

Making an LLVM or gcc frontend is a different discussion. (and has been done on this forum already)
albert
Posts: 6000
Joined: Sep 28, 2006 2:41
Location: California, USA

Post by albert »

Hi Guys!

After reading over all the FB-SOURCE / Compiler/*.* files , I see that the assembly output is hard-coded in. It would take alot of work to port it to other processors. And since alot of the newer esoteric 128/256bit instructions are Intel only or AMD only.???

I've got an AMD processor,So I went on AMD's website and they've only got Linux devtools.

Intel has a complete devtool set,but its like $1900 U.S. dollars for a single person liscense. Too much for just farting around, learning and testing.

On the MASM32 websites, Iczelion's , Hutch's pages and tutorials have many BASIC-Keyword macros.
But i guess thats why not many people use assembly, because its not multiprocessor portable. And from reading the docs and toots, X86-32 cannot be easily ported to X86-64, the advice from the experts was thow out your 32bit code and rewrite it from scratch in 64bit.

On my AMD_x2 64 2.0GHZ with 2GB ram it takes almost an hour for GCC to compile the Linux Kernel.
My old 386 40Mhz I would start the compile at 4:30am got to work and come home and it would finaly get done around 6-7pm.
marcov
Posts: 3462
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Post by marcov »

albert wrote:Hi Guys!

After reading over all the FB-SOURCE / Compiler/*.* files , I see that the assembly output is hard-coded in. It would take alot of work to port it to other processors.
True, but any solution is hard work. The trouble is that there is no free lunch. (see my reply to Sannaj above). What you gain in easier codegenerator maintenance, you loose on other fronts (non unix compatibility and feature support, packaging, increasingly complex versioning, extra build system dependencies etc)

That's my whole point in this discussion. These are currently stepped over easily, since devels work on *nix, or know how to handle mingw, and still do relative small experiments with cgen. But they will come out when it will be rolled out broadly, and the issues start pourring in.
And since alot of the newer esoteric 128/256bit instructions are Intel only or AMD only.???
Those are generally not used by compilers. Mostly only by certain specific routines coded in assembler or intrinics. (which is another form of assembler), mostly compression, encryption code or (audio/video) codecs.
I've got an AMD processor,So I went on AMD's website and they've only got Linux devtools.

Intel has a complete devtool set,but its like $1900 U.S. dollars for a single person liscense. Too much for just farting around, learning and testing.
Such compilers are for the scientific number crunching applications. They are not terribly useful for crafting end-user applications.
And from reading the docs and toots, X86-32 cannot be easily ported to X86-64, the advice from the experts was thow out your 32bit code and rewrite it from scratch in 64bit.
That depends. But there is some truth in it, certainly, specially if your compiler is totally geared toward x86. (in our case, the x86 cg was cleaned up a lot due to PowerPC support, which in turn was inspired by a 3rd party "hack until it works" m68k port in a previous version)
My old 386 40Mhz I would start the compile at 4:30am got to work and come home and it would finaly get done around 6-7pm.
On a _modern_ kernel? I'm surprised it can actually still compile it, I thought most distributions were at least 586+.
Sannaj
Posts: 27
Joined: Dec 19, 2010 16:39

Post by Sannaj »

marcov wrote:
Sannaj wrote: I don't get you point. What's the problem with llvm bytcode? It is not comparable with things like Java or .Net bytcode. Llvm bytcode is only used as a plattform + language independent form of representation during the optimisation stage. GCC has got something similar, but it is compiler programm internal there.
Nothing an sich. More that it is yet another dimension more work, and thus less likely to succeed.
From my point of you using clang as a backend would be only usefull to use the cgen backend with llvm.
Correctly. I was talking about the hidden costs of cgen, and that gcc was not as ideal (since fairly bad on windows, half of the PE features are not supported, e.g. thread and TLS tables?).

So I was talking about switching out gcc for clang for cgen purposes, to show that even with the "other" free/portable C compiler Windows is underwhelmingly supported.

The point being that Windows, the most used FB target might actually decrease sharply in usability and quality, because some want portability (if only on paper) at all costs.

Making an LLVM or gcc frontend is a different discussion. (and has been done on this forum already)
Now I'm getting you Point. Expaning cgen to other compilers might be a good Idea. Cgen doesn't use many language extentions, does it. Sp the main point would be showing fbc, how to use different C compilers. I would suppose some sort of configuration file, witch contains the c compiler call prototypes.
marcov
Posts: 3462
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Post by marcov »

Sannaj wrote:
Now I'm getting you Point. Expaning cgen to other compilers might be a good Idea. Cgen doesn't use many language extentions, does it. Sp the main point would be showing fbc, how to use different C compilers. I would suppose some sort of configuration file, witch contains the c compiler call prototypes.
More or less. But by ruling out LLVM getting up to production quality(*) on Windows anytime soon, that effectively means MSVC (or BCB).

So the question of cgen based Windows development reduces to the availability of a suitably licensed redistributable cmdline MSVC (the one in the platform SDK?), and its ability to compile C parts of the runtime libs (if any), and to compile cgen generated code.

(Despite being a Borland user for decades, I'm not to familiar with the C++ lines, so I can't say much about that, except that Borland used to provide more C++ tooling as PD and trials than they did Delphi. So it might be worth checking into.)

The real point being is that a decision what to do with Windows development should be factored into major decisions about the future. If you postpone that decision, and go for the Unix centric solution, it is essentially a kiss of death.

(*) I'm thinking about first citizen's access to Windows features like TLS, ActiveX (client and server), native GUI etc. I'm not saying the devels should actively pursue this, but they should make choices that at least keep that option seriously open for a win-centric develper to build on.
albert
Posts: 6000
Joined: Sep 28, 2006 2:41
Location: California, USA

Post by albert »

If you wade thru the GCC source code its full of defines and if statements.

if processor = ?? then ?
if OS = ?? then ?

Maybe FB could be done that way?

If the FB coders could port the functionality of C to FB then GCC could be compiled by FB. (Just a thought.)
marcov
Posts: 3462
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Post by marcov »

albert wrote:

If the FB coders could port the functionality of C to FB then GCC could be compiled by FB. (Just a thought.)
Yes, and if you save a penny 100 billion times, you have a BILLION DOLLARS! Just a thought (and about as achievable)
albert
Posts: 6000
Joined: Sep 28, 2006 2:41
Location: California, USA

Post by albert »

I started with just wondering if the FB coders were ever going to port FB to Win64 , Linux64.

I see the prejudicial remarks all over the internet, where C, C++ coders bash BASIC because the "B" means its for beginners and they don't want to be thought of as beginners, they don't realize that BASIC can be made to do anything that any other high or low level language can do.

I've even seen on a few C,C++ coder sites that stated that C++ classes and polymorphism couldn't be done in Assembly language. (I thought how then do the classes and polymorphism compile and assemble into machine code? Of course; you can have classes and objects in assembly language.)
marcov
Posts: 3462
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Post by marcov »

albert wrote:I started with just wondering if the FB coders were ever going to port FB to Win64 , Linux64.

I see the prejudicial remarks all over the internet, where C, C++ coders bash BASIC because the "B" means its for beginners and they don't want to be thought of as beginners, they don't realize that BASIC can be made to do anything that any other high or low level language can do.
Such argumentation can be made for any feature that some C/C++ compiler has (SSE4 intrinsics, GUI designers, automated COM support and wizards, CUDA, OpenCL, OpenMP etc).

But I think we will agree that if FB tries to cover those all, we will spread the small resources too thin :-)

The trouble is deciding what things to do, not which things one could do
Richard
Posts: 3096
Joined: Jan 15, 2007 20:44
Location: Australia

Post by Richard »

One characteristic of multi-platform languages is that they are, at best, a compromise solution. The inability to define, or the failure to achieve perfection, is a positive human characteristic, not the “knell of doom”.

Picking a development path that avoids the biggest problems, while finding solutions to more tractable problems, is the job of a skilled development team. Listing all the problems that might possibly be encountered is the job for a Devil's Advocate. A Devil's Advocate cannot be involved in the high-level planning of a successful project because the focus on failure, precludes any advance.

A decoy, like this thread, draws the fire of enemy snipers thereby protecting the developers and speeding success of the project. Sniping from the sidelines is no more than a tactical distraction, the main assault will continue and will reach it's objective. There will be costs and casualties, but with competent developers the strategic objective will be achieved, elsewhere.

If you are not part of the solution then you are part of the problem. “Devil be out”.
marcov
Posts: 3462
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Post by marcov »

Richard wrote:One characteristic of multi-platform languages is that they are, at best, a compromise solution. The inability to define, or the failure to achieve perfection, is a positive human characteristic,
So if I keep this up for another few msgs, ANY failure probably will be represented as a "positive human characteristic" :-)

As far as the devil goes, it is in the details. I discussed some of the issues in depth, while you stuck to a few "positive" platitudes.

I assume the reader can make up his own mind, and ward of the devil where boundless optimism fragments and damages the project. (and that doesn't need to be the ultimate “knell of doom”, a few years set back is painfull too).

Finally, as far as the devels go, the only thing I ask is for honest communication.

If they adapt unix centric visions, and put windows on the backburner in the hope that someone will fix it, it is their right to do so, and I even understand it on some level.

But please communicate honestly about it, and avoid sustaining false hopes and people investing time in doomed aspects.
A Devil's Advocate cannot be involved in the high-level planning of a successful project because the focus on failure, precludes any advance.
This particularly stung me. Just because I'm not a starry eyed dreamer that thinks we can compete with something as gigantic as C++, I'm "focussed on failure"? Now who is biassed here.......

And I'll stick my neck out again, and risk being accused of a negative attitude again, but can you say "succesful project" with a straight face? Look around, FB is pretty much in the same state as 2 years ago. Some minor evolutionary progress has been made, but can you really say any of the wild plans of that period have bore fruit and are in production?

Anyway, this is my last post on the subject.
albert
Posts: 6000
Joined: Sep 28, 2006 2:41
Location: California, USA

Post by albert »

I just think it would be nice to have Win64 and Linux64 exes.

I copied all the QB64 mingw tools to a substitute FB/bin directory and tried -gen GCC -r and sure enough it spit out a 69KB C file from a 7KB .bas file.

But i can't get it to compile with the QB64 mingw tools. I think i need some sort of windows batchfile shell script to pass params to GCC.??
pestery
Posts: 493
Joined: Jun 16, 2007 2:00
Location: Australia

Post by pestery »

You could use the verbose compiler option ( -v ) to see how fbc compiles for GCC normally. It might help you get the right commands for your 64bit compiler.

Also, you could use the -Wc option to pass parameters to the GCC compiler.
http://www.freebasic.net/wiki/wikka.php ... pilerOptWc
Post Reply