[qcc] Hello world.

[Rob Landley]

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.

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. It should be a simple,
fast, portable pure C reference compiler.

> One man can develop such thing, but it will be endless work.

What else is new?

> Or there is not so much work needed?

Yes and no. That's a whole separate email though. :)

> Maybe qcc should have higher priority than toybox (or at least equal)?

Toybox has a natural goal line. Not an "end point" but a pont at which I
can say "It does what it set out to do, now it goes into maintenance
mode" and then takes up less time. Getting toybox _to_ that point
quickly makes sense, so that's what I'm doing. _Then_ I can worry about qcc.

Aboriginal Linux is in that mode after its 1.0 release, although I've
sadly held off on two maintenance releases (which should come around
when each -rc1 ships) because I have a couple of really time consuming
bugs I don't want to ship without fixing. (One's a build break that only
happens on Fedora, and the other is a package that's building wrong
under my uclibc/kernel configuration.) Neither is easy to debug on my
current netbook, part of the reason I got a new (slightly less
underpowered) netbook.

> 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.

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.

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.

Everything else is a bonus. :)

> Maybe BSD guys will be interested in qcc? They try to get pcc to work,
> but I still see old gcc and binutils in OpenBSD's base. The problem is
> binutils probably (still there is no replacement for it).

Tinycc has a linker but binutils also provides an assembler, strip,
objcopy, objdump (which includes a disassembler), readelf, and a few
miscelaneous things.

See todo/commands.txt for a triage of all that.

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...

> 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.

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.

Rob

-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

 1340646869.0