Re: A bug in mark_constants () in varasm.c

[Craig Burley <burley at gnu dot org>]

>  > Well, let's say that there is some relevance (smaller functions make
>  > for ease of understanding and maintainance), but nevertheless Per is
>  > right: gcc is vastly more complicated than the Linux kernel.
>Depends on what you're doing.  Having spent time in both the OS
>development world and the compiler development world, some aspects of
>compiler development are *far* easier -- mostly in areas related to
>debugging and not having to deal with async events (like interrrupts)

Both of these can be, and IMO are, correct.  gcc is more complicated than
any OS kernel I've worked on; OS kernel development is much harder
(IMO) than compiler development.

The way I'd put it is, the complicated parts of OS design are "outside
the code", while, for compiler design, the complicated parts have
migrated, especially over the past 15 years or so, to "within the code".

E.g. the gcc architecture includes various ways to describe machine
architectures *and* automatically generate code to do the relevant
compiler cleverness.  That all amounts to directly expressing the
complexity of the relevant stuff in the code itself, which makes
the code itself more complicated, but developing it (hopefully)
easier.

Whereas, last I checked, Linux, and most OSes, don't encode the
knowledge of things like interrupts, maximum service times,
priorities, and so on as abstractions and include automated ways
to generate the kernel from this data base of knowledge.  That
amounts to keeping the code "simpler", but the knowledge base
that the programmer working on it must possesss necessarily is much
larger, and developing the code, especially changing it to cope
with new ports, is much more difficult.

One of the reasons I got interested in compiler design, back when
I was an OS/kernel person, was that I had a theory that kernel
coding architecture could be improved so the code was not only much
easier to maintain, but would produce a system both more robust and
of higher overall speed if it could be based more on cleanly coded rules
and descriptions than on outright coding based on implicit information.
I figured the compiler field would, if that theory held any water,
already be making that transition.  gcc is a pretty good proof of
that, so I would guess that, within 20 years, there'll be one or
two industrial-strength kernels out there that include at least as
much automated code for the "tough parts" as gcc now includes.

        tq vm, (burley)