[qcc] Hello world.

[orc]

On Mon, 25 Jun 2012 12:54:29 -0500
Rob Landley <rob at landley.net> wrote:

> On 06/23/2012 05:32 AM, orc wrote:
> > It seems that we need more developers to beat gcc, how do you think?
> 
> I think we just need to be better. Quality's more important than
> quantity here.

Agreed.

> 
> And I'm not trying to "beat" gcc, I'm trying to provide a viable
> alternative with its own strengths. I don't expect qcc to ever
> optimize better than gcc, because that's not its' thing.

Yes, my mispelling here. But getting Linux kernel to build with qcc
also automatically means that in certain areas we should 'beat' gcc.

> It should be a simple, fast, portable pure C reference compiler.

Strongly agreed. Such things are very helpful in understanding 'how
that all stuff works and linked together'. It also helps to easily hack
things, even if you are in hurry. Because you are understand how it
works (the whole gnu still lacks this, and I think it will. Loose of
freedom #4: hack in hurry).

> > I planned to publish news about future musl release on local sites,
> > nowI think about a draft of new platform based on such nice software
> > as musl, busy/toybox and qcc.
> 
> I've been trying to come up with a 4-package self-hosting system for
> years. My target used to be linux, busybox, uClibc, and tinycc. These
> days linux, musl, toybox, and qcc make more sense.
> 
> > The one sad thing that I still need to use
> > bloated gcc and binutils for building the rest.
> 
> llvm/clang, open64, and pcc are all trying to provide replacements.
> They're not there yet, but they're working on it.

They are not that I (and you maybe) want: easy to modify, understand
and build thing. And not they are all can build Linux kernel.

> 
> And note that the _output_ of qcc is going to be pretty bloated. The
> optimizer of qcc will suck for the forseeable future, because it's
> pretty straight translator of C into machine language, currently
> without even a whole lot of register allocation smarts.

Binaries are only temporary. Someone interested will fix it if needed.
There will be great news about qcc if it will build Linux kernel.

> 
> The optimizer should get _better_, but qcc is not the same _kind_ of
> tool as gcc is. Qcc should work properly and be simple. Simple meaning
> small implementation, easy to understand, and runs fast because it's
> doing as little as possible.

Easy to understand, easy to build, easy to modify/hack. And fast,
because it simple. Agreed.

> What I want to do is have qcc be a swiss-army-knife executable
> providing all the others. In theory breaking out cc -E into a
> separate cpp binary would allow distcc to call a much faster
> preprocessor, which would help aboriginal builds under qemu. That's
> one of the "low hanging fruit" bits of this...

Final system will be a set of things that are swiss-army-knife
exec/library:
musl: combines -l c/pthread/rt/m/dl/util/xnet
toybox: combines useful utilities (coreutils, util-linux, e2fsprogs,
login/init/passwd)
qcc: combines compiler/assembler/linker/elfutils
Linux kernel: self-contained kernel.

Anyone will only benefit from that: things are modular, atomic
upgrades, you always know where and what thing installed, what it does
and which source package needed to modify in order to modify behavior,
add a feature, etc.

> 
> > I planned to publish news about future musl release on local sites,
> > now I think about a draft of new platform based on such nice
> > software
> 
> It would be nice. It's also a lot of work.

Bright future of Linux platform, the new platform.

> 
> The most important thing here is that it's modular. Musl doesn't
> depend on toybox, and vice versa. Similarly qcc should be able to
> replace gcc+binutils at some point in the future, but its absence
> isn't blocking the development of either.

Until that I decided to use old versions of gcc/binutils.

> 
> Rob
> 

Thanks!

 1340690437.0