Re: Just what makes an architecture "C Friendly"?

Darin Johnson wrote:
But "C friendly" means several things. When GCC says this, I'm pretty
sure it means "friendly environment in which to implement a GCC
compiler". So you've got several meanings here:

Yes. I think the GCC definition for C practice is expressed by a
growing number of people. I do think it is a stretch for embedded
use, but it is becoming an option more often to take the library
and file system and OS from development platform to the embedded
target with the minimal effort.

I don't live in that space, but I see more and more people offering
that point of view, so I commented that I think C does mean somewhat
different things to different people. I intended to enumerate several
meanings.

There is another thread about the most unfriendly-for-C architecture
for which people actually use C. And architectures for which no
one has used C are probably those that are WAY too small for
something like GCC. If you are working with an embedded
design that has only a few words of ROM, no RAM or a few words
of RAM, no general purpose registers, non-byte address, non-power
of two bus width, no hardware error traps, no interrupts, etc. type
architecture for which there is no C compiler you probably consider
it C un-Friendly enough to not make the effort to try to use C.

And even if you are just generating a small bit of embedded code
for that environment by running Linux and GCC quite happily on a
PC you probably were not thinking of running GCC out of a dozen
words of target ROM.

Friendly for a C programmer to use as the destination platform.
Friendly for C compiler writers (as a destination).
Friendly for running a C compiler on.

I'm pretty sure that the third wasn't what the original question was
asking. The second is interesting of course, but there are far more C
users than C compiler writers.

Yes. But I wasn't really refering to compiler writers but compiler
users.
Of course compiler writers are compiler users, so they are a subset
of the people who might want to run a C compiler.

I was just pointing out that some C compiler users want to stick
to architectures, even for embedded systems, that are C compiler
hosting friendly, not just C comiler target friendly.

One responder said that 'C Friendly' was about the quality of
code generated by the C compiler compared to the quality of
code generated some other way. I first thought that sounded
very circular.

But as you point out, there are more compiler users than compiler
writers, and most will decide if something is C friendly based on
how good a job some other people have done in writing the compiler
for them so they can focus on describing a problem solution in
C code and getting it to work properly.

So I think we have discussed quite a range of different types
of C programmers from those who want to stay at the Linux
level on embedded targets, those who want to stay at the
C level in embedded targets, those that mix C and assembler
or other things in their embedded targets, and those who
sometimes say that an architecture that they programmed
was just too C unfriendly to use C at all.

But too much unfriendliness for the
compiler writers can translate into unfriendliness for the compiler
user (or the compiler writers may just decide that it's not worth the
time and money to implement some feature if the expected audience
isn't likely to use it).

Yes. I think that's a good way to see the idea of 'C friendly.'

It's also not clearly defined what "friendly" means. All features of
C most certainly can be implemented on the PIC16 family, but few would
classify it as C friendly. The snag is that many of the features
come with limitations or efficiency costs (size or speed). So I'd say
that "friendly" means that the author of C code runs into a minimum of
snags and gotchas. Fewer limitations, less effort involved in
getting fast or small code, fewer workarounds, etc.

Yes, That's what I was thinking too.

When I worked at the iTV Corporation they started work on a C
compiler that had layer of compromise upon layer of compromise
until almost no one would be willing to put up with the snags and
the gotchas and hopelessly slow and bloated code. The architecture
was unfriendly enough to C that a great deal of effort would have
been required to anything decent out of a C compiler.

For instance, the C compiler for the PIC I sometimes use seems to
have a lot of features, and the code it accepts if very much like C.
But it is more difficult for me to maintain the PIC C code in my
job than it is to maintain the 32-bit RISC C code. That's because
of the C style necessary to get fast and small code on the PIC.
It has lots of global variables, long unfactored functions,
miscellaneous unique keywords, and so forth. Some may be due to
the small size of code space, but much is due to other limitations.

Yes. That is what I was thinking too.

If you had a tiny ROM/RAM, or no RAM at all or something like that
you probably would not try to generate the code with C if that was
going to mean lots of global variables, long unfactored functions, etc.

Not that with enough effort it could not be done. And friendliness
is related to the effort to use C vs something else.

So the C compiler for the PIC is unfriendly because in order to use
it efficiently one must be careful of how they write the code and be
aware of the limitations - reading the compiler manual thoroughly is
mandatary, and examining generated output code is highly recommended.

And if no one had written a C compiler for the PIC even more people
would see the PIC as even more unfriendly to C.

While the PIC assembler writer may have to jump through the same
hurdles as the PIC C compiler writers or C writers, assembler writers
know up front that they're writing non-portable code and what the
various snags are. C authors generally use the language as a tool to
express their application in, and may often find out much later that
what looked like decent code has contributed to bloat or slowness.

And if they didn't notice it until later, it might not have even been
all that important that code was bloated or slow compared to how
small or fast it might have been. If it did what it needed to do,
and the architecture was friendly enough to make C a viable option
it might not have made sense to bother optimizing it further.

So "C friendly" may mean that you can just start writing without
worrying about the target processor and still get a reasonable result.

I think so.

Here's something to think about from a philosophical point of view.
If a C compiler has to jump through hoops and use lots of instructions
to do something that would be simple on comparable processors, but the
equivalent human written code in assembler has to jump through the
same hoops, then is the C compiler unfriendly?

Yes, but if it is not friendly to anything else either it is not the
sort of
thing I have talked about. Sure there are crazy architectures done
as experiments by students, built with tinker toys or whatever, or
that use one opcode with memory locations that perform ALU
operations. And they are going to be pretty unfriendly to programming
in general.

For instance,
accessing constants that are stored in code space. On one hand there
are hurdles for the C programmer, and possible a restricted style of
C has to be used. But on the other hand it may still save a lot of
time and be more maintainable than writing in assembler. The
processor might be considered unfriendly to all programmers, not just
C programmers.

Of course. A one-bit one-opcode processor might be fun for some
student to design, but it is not likely to be very friendly to any
programmers.

If you look only at architectures that are friendly to C it might be
easy
to think that if an architecture is not freindly to C that it is just
not
friendly to programming.

But that isn't true where I live as I have worked on a lot of Forth
machines.
We tended to think that Forth programming was easy and friendly. And
we wanted to have easy to program and fast and cheap hardware too.
And we didn't need all the things that a processor needs to be friendly
to C to be friendly to Forth.

Without going to what an architecture needs to be friendly to GCC and
sticking to the embedded and tailored C on PIC there is still a list of
what C needs. And that list is very different than the list of say
what
Forth needs.

If you have the minimum hardware that you need for C you can do a
good Forth. But if you have the mininum hardware that you need for
a good Forth it may be well below the level of the minimum hardware
that you need for an architecture to be C Friendly.

Consider that the inventor of Forth says two stacks are essential
and that addressable registers are nice if you can afford them
(since they are more architecturally expensive than stack registers)
and that Forth is word oriented both semantically and architecturally.
So it only needs word addressing, while C wants bytes.

Since Forth only needs stacks which can be fast LIFO registers,
not stack frames with pointers into slow memory and arrays for
locals as typcially done in C, hardware stacks that resemble
those on a PIC are perfectly friendly for Forth but not for C.

And if the instruction set of the processor are the primtives in the
Forth
language so that instead of needing dozens of words of memory and
many processor cycles to execute each Forth primitive they become
tiny native opcodes then the code can become very dense, very
fast, and the architecture can be low cost and low power. And it
just can't get much more language friendly than to have 80% of
a language directly mapped to native opcodes. Compilers and
applications get really small and simple that way. Yet that same
architecture that is as friendly as possible to one language is
also seen as very C unfriendly.

So while I would acknowledge that not being C friendly does in
some cases mean not being software friendly at all. But I would
also point out that in the sort of cases that I talk about, from the
perspective that I talk about, being C friendly is not the
same as being software friendly at all.

We tend to think that for the sort of programs that we write
that Forth programs on Forth hardware is about as simple
and friendly as language/architecture can get.

We also think that it takes quite a lot in comparison to make
an architecture C friendly. What makes something cheap and
fast and easy to program in Forth might make it rather
unfriendly to a C software approach.

People tend to forget how much effort was required by how
many people for how long on both the hardware and software
over the years to allow programmers to use GCC with
a minimal amount of effort on their part. Once the money
has been spent, once you have learned it, once it becomes
a habit and a comfortable tool you tend to forget that it
became friendly because of a lot of effort in the past.

.

Relevant Pages

  • Re: port gcc for c51 step by step
    ... you cannot use gcc because it does not support ... If this is a compiler course, it would probably be of greater ... lcc is simple and strictly divided into ... architecture independent and dependent parts (and reasonably well ...
    (comp.arch.embedded)
  • Re: Hard Sci-fi?
    ... *programmers* can't really circumvent it. ... the world's computers are ever used for compilation. ... Most computers with a Java VM installed have a compiler. ... Harvard architecture, or any other compiler-unfriendly architecture, then ...
    (rec.arts.sf.science)
  • Re: Ping from C/C++ doesnt work properly using either System() or popen()
    ... The only correct result, on *any* architecture, is 1. ... but quoting the ANSI standard is a red herring. ... guarantee a given compiler will even be ANSI C compliant. ... No assumption about ANSI C compliance should be made... ...
    (comp.os.linux.networking)
  • Re: Apples poor positioning for the age *after* x86
    ... You know what I'm on about: The OS will be able to support abstracting CPU like we can do GPUs now, ... Apple's technique is to kill the old architecture so developers have no choice. ... I'm not talking about .NET compilers, I'm talking about the compiler you use to build the runtime. ... They realized the only way to achieve platform independence was to develop a software platform for the lowest common denominator. ...
    (comp.sys.mac.advocacy)
  • Re: Future of programming
    ... but even harder for the compiler programmers. ... my current compiler (gcc) cannot even optimize this function: ... Note, it works if i use an int, rather than a short int. ...
    (alt.lang.asm)