Most portable compiler: llvl llc or pcc or gcc rtl?

[Ir. Hj. Othman bin Hj. Ahmad]

After reading about The history of Unix, portable c compiler, pcc contributed to the dominance of C over other languages because it is available
quickly and cheaply, while maintaining reasonable performance.

We now have Magnusson's C99 pcc.
Can it match the portability of gcc? Gcc's portability could be due to its use of RTL, but its RTL is not accessible, and
despite my earlier assumption, RTL is actually of higher level than LLVM IR.

Llvm IR is accessible, and is compiled by llc compiler. Looking at its source code,
it appears to be that of a machine independent code. The machine dependent is not specified by the docs that I had
read, unlike pcc, wher machine dependent parts are well identified and described, with lots of papers describing them.

My bet is in llc. I shall try to produce a PIC 16 code generator.

 

[Noob]

[Most portable compiler: llvl llc or pcc or gcc rtl?]

Were you looking for comp.compilers?

 

[Walter Banks]

After reading about The history of Unix, portable c compiler, pcc contributed to the dominance of C over other languages because it is available
quickly and cheaply, while maintaining reasonable performance.

We now have Magnusson's C99 pcc.
Can it match the portability of gcc? Gcc's portability could be due to its use of RTL, but its RTL is not accessible, and
despite my earlier assumption, RTL is actually of higher level than LLVM IR.

Llvm IR is accessible, and is compiled by llc compiler. Looking at its source code,
it appears to be that of a machine independent code. The machine dependent is not specified by the docs that I had
read, unlike pcc, wher machine dependent parts are well identified and described, with lots of papers describing them.

My bet is in llc. I shall try to produce a PIC 16 code generator.

I have written two PIC 16 C compilers. It is not a trivial undertaking.

Walter Banks
Byte Craft Limited

 

[jacob navia]

Le 09/10/12 19:05, Walter Banks a écrit :

I have written two PIC 16 C compilers. It is not a trivial undertaking.

Walter Banks
Byte Craft Limited

You can say that because you know what you are talking about: you have
written two PIC 16 C compilers.

He hasn't, so he thinks it is easy, just filling in the blanks in some
portable C compiler.

As if you could translate from a preemptive 32/64 bit architecture to a
PIC 16 without rewriting everything.

In general I have found that most open source code compilers are just
too bulky for small machines, much too full of hidden assumptions for
cramped environments.

Even lcc was too big when I ported it to an analog devices 16 bit DSP,
and that was a machine that wasn't at all as difficult as the PIC 16!


jacob

 

[Chad]

I've helped write on compiler along with it's associated interpreter. All I can say is that it was long, tedious, and difficult.

Chad

 

[Walter Banks]

The PIC16, on the other hand, is a brain-dead cpu that fits very badly
with the structure used by most compilers (open source or otherwise) -
it really needs a very specialised compiler to get good object code.
The same applies to cores like the 8051, the COP8, and many small DSP
devices.

Your point is well taken but...

C can map quite well on the extended 14 bit ISA used in some of the
PIC16 micros. The problem with most of the generic compiler implementations
is they are designed for a different type of processor and most of the
generic optimizations don't apply. An example is register spilling when
a processor has a primary accumulator and maybe an index register
doesn't map very well. They are other code generation approaches
built around data flow that have good mapping to micros. One specific
issue that rarely gets mentioned is that there are compilers that do port
quite well between embedded systems processors but are generally found
as part of commercial tools companies IP.

As an example a few weeks ago some one forwarded a link to
DCPU 16 a virtual 16 bit processor http://0x10c.com/doc/dcpu-16.txt.
In 3 or 4 evenings I created a C compiler port for this ISA using our
tools that beat many benchmarks for several commercial processors. It
was a reasonable implementation even before ISA specific optimization.
It is possible to create generic tools that are oriented to the
architectures found in embedded systems.

Walter Banks
Byte Craft Limited

 

[BartC]

As an example a few weeks ago some one forwarded a link to
DCPU 16 a virtual 16 bit processor http://0x10c.com/doc/dcpu-16.txt.
In 3 or 4 evenings I created a C compiler port for this ISA using our
tools that beat many benchmarks for several commercial processors.

Since this seems to be an imaginary processor, how did your run your
benchmarks? And how did your compare the timings with real processors?

 

[Walter Banks]

That looks like a /much/ nicer cpu than the PIC16! It should be
well-suited to generic tools, and would not be a big challenge for a gcc
port either. (I'd expect more than a few evenings for a gcc port, but
nothing compared to making a good PIC16 port.)

It is an interesting ISA at a lot of levels. It would be expensive ti implement
in silicon, although I am sure it could be even at a commercial level
and be competitive.

Probably the most ignored main stream 16 bit processor is XGATE a
co processor used with some of the Freescale parts. It is a risc processor
that optimizes well and achieves higher code density that many cisc
processors.

Walter Banks
Byte Craft Limited

 

[Walter Banks]

Since this seems to be an imaginary processor, how did your run your
benchmarks? And how did your compare the timings with real processors?

We have a development tool that simulates ISA's. As well as creating a code

generator I wrote a simulator model accurate down to to instruction
timings.
The link I posted and a few others on the site document the instruction
timing.
I was looking at code density and competitive timing given the same clock
rate.

How do you know a programmer who likes his work? When 5am is time to
go to bed and not time to get up.

I started writing compilers 40+ years ago. Someone sent me an the DCPU 16
ISA I read the message about 9PM. Interesting says I and wrote a simple
table driven macro assembler to look at a couple common C constructs. Next
thing I know it is 2 am. The next couple evenings I hacked together a code

generator for our compiler tools, ran a test suite through it got some
size
information and couldn't resist "finding out" just how good the code was
and "had to" implement a simulator to run some benchmarks.

I spent one evening a week or two later looking at ISA specific
optimizations

There is hope my wife explains to friends that all nighters are less common

now than they once were

w..

 

[Philipp Klaus Krause]

My bet is in llc. I shall try to produce a PIC 16 code generator.

If you just want to have a free C compiler for the PIC 16, I recommend
having a look at sdcc, which has an existing PIC 16 backend. While the
PIC16 backend it is used by some people, it is still considered in
development, and not up to the quality of the other backends, and help
to improve it, fix the bugs it has, etc would most likely be welcome.

Philipp

 

[Philipp Klaus Krause]

There is, in fact, an open source compiler that is suited to such cpus -
SDCC. But it is harder to port to new architectures than gcc or llvm,
and is not renowned for producing top-class code (though it is still
good enough for many people). It might be the OP's best bet for a PIC16
compiler, however.

Well, it is improving. For Z80 (and the related Z180, Rabbit 2000/3000,
Rabbit 3000A and LR35902), sdcc mostly seems to able to generate better
code compared to any other compiler except IAR
(https://sourceforge.net/apps/trac/sdcc/wiki/z80 code size). For the
HC08 and S08 there were substancial improvements recently
(https://sourceforge.net/apps/trac/sdcc/wiki/hc08 code size), but
commercial compilers still generate much more compact code for them. The
pic ports, somewhat popular among users, still need more work though.

Philipp

 

[88888 Dihedral]

Philipp Klaus Krauseæ–¼ 2012å¹´10月11日星期四UTC+8上åˆ10時30分20秒寫é“：

If you just want to have a free C compiler for the PIC 16, I recommend

having a look at sdcc, which has an existing PIC 16 backend. While the

PIC16 backend it is used by some people, it is still considered in

development, and not up to the quality of the other backends, and help

to improve it, fix the bugs it has, etc would most likely be welcome.



Philipp

Nowadays people are more interested to write programs in c for really cheap
and working DISP/CPU/MCU cores in the embedded systems in the development
stages.

Thus, a c compiler with the assembler support like GCC and PCC are
popular.

But be careful about the license conditions in the commercial usese.

In schools of USA non-commercial projects are charged very very low
or even free in the tools.

I worked out my own assemblers for 2 riscs before.

 

[Les Cargill]

Philipp Klaus Krauseæ–¼ 2012å¹´10月11日星期四UTC+8上åˆ10時30分20秒寫é“：

Nowadays people are more interested to write programs in c for really cheap
and working DISP/CPU/MCU cores in the embedded systems in the development
stages.

Thus, a c compiler with the assembler support like GCC and PCC are
popular.

But be careful about the license conditions in the commercial usese.

So far as I know, there is absolutely no encumbrance on commercial
projects compiled and linked with GCC.

 

[Ir. Hj. Othman bin Hj. Ahmad]

I have written two PIC 16 C compilers. It is not a trivial undertaking.

Walter Banks
Byte Craft Limited

Writing is very different from porting.
Porting should be easier.
It also depends on the kind of compilers.
All of them are c99 compatible and growing.

 

[Ir. Hj. Othman bin Hj. Ahmad]

Le 09/10/12 19:05, Walter Banks a crit :






You can say that because you know what you are talking about: you have
written two PIC 16 C compilers.

He hasn't, so he thinks it is easy, just filling in the blanks in some
portable C compiler.

As if you could translate from a preemptive 32/64 bit architecture to a
PIC 16 without rewriting everything.

There are examples such as avr and dsps as guides. Lots of
documentations to follow and learn.
To get a good job is equivalent to a MSc thesis, because some of them
did it for their thesis.

However, I am only interested to do the basics, just as limiting the
data types to just a few.
If I can get some form assembler sources, it will be enough.
The first stage is just to compile and generate cross assemblies
first.

I have got a feeling that current compilers are getting portable. They
just need more documentatiions to enable people
to port to many architectures. The techniques can be improved further.
Instead of just for speed, we can optimise for
portablility. Just like the old pcc, and now resurrected.

In general I have found that most open source code compilers are just
too bulky for small machines, much too full of hidden assumptions for
cramped environments.

It may be bulky but machines are so fast, they become so
insignificant. We are working with Terabytes now.

 

[Ir. Hj. Othman bin Hj. Ahmad]

Philipp Klaus Krauseæ–¼ 2012å¹´10月11日星期四UTC+8上åˆ10時30分20秒寫é“：
















Nowadays people are more interested to write programs in c for really cheap
and working DISP/CPU/MCU cores in the embedded systems in the development
stages.

Thus, a c compiler with the assembler support like GCC and PCC are
popular.

But be careful about the license conditions in the commercial usese.

In schools of USA non-commercial projects are charged very very low
or even free in the tools.

I worked out my own assemblers for 2 riscs before.

Assemblers should be easier but C will allow us to write more code.

GCC and PCC appear to be equivalent. LLVM appear to be promising but I
am having problems compiling it.
LLVM is written in C++ but that could contribute to the problems.

LLVM has abandoned PIC support. GCC does not have any at all, only
AVR.
PIC is well supported with free C compilers but they are limited. They
are not even compatible with the latest versions of C.

And yet there are many PIC in the world. They get more and more
powerful while maintaining its price and low power consumption. That
is why I chose the PIC as a starting point. It is accumulator based,
so some techniques for i386 should apply.

 

[Walter Banks]

I worked out my own assemblers for 2 riscs before.

Our typical implementation time budget for an 8 bit macro
assembler is 10 man hours, for a C compiler port that
has working code generation within a couple man weeks
and V1.0 release after 10 to 12 man months.

Walter Banks
Byte Craft Limited

 

[Ir. Hj. Othman bin Hj. Ahmad]

Our typical implementation time budget for an 8 bit macro
assembler is 10 man hours, for a C compiler port that
has working code generation within a couple man weeks
and V1.0 release after 10 to 12 man months.

Walter Banks
Byte Craft Limited

If you're still active, you may compare porting using these 3 portable
but optimising techniques. I bet you can get a workable compiler with
just one man-month. For commercial use, pcc and llvm licensing terms
are preferable, but you may be out of date if you don't sync with the
main developers. Just my guess.

Is there any commercial C compilers that can overcome significantly
gcc? When even apple has gone the gcc approach.

 

[jacob navia]

Le 11/10/12 15:20, Ir. Hj. Othman bin Hj. Ahmad a écrit :

Is there any commercial C compilers that can overcome significantly
gcc? When even apple has gone the gcc approach.

Yes. In general, Microsoft compilers outperform gcc by a wide margin

And Intel's compilers outperform Microsoft's by a wide margin too

 

[Rui Maciel]

Yes. In general, Microsoft compilers outperform gcc by a wide margin

And Intel's compilers outperform Microsoft's by a wide margin too

Your definition of "wide margin" appears to be a bit exaggerated, and also
the "outperform" part. At least according to this:


Impact des compilateurs sur les architectures CPU x86/x64
http://www.hardware.fr/articles/847-1/impact-compilateurs-architectures-cpu-
x86-x64.html


The general idea that is conveyed by those benchmarks is that the
performance difference between compilers is only significant in a hand full
of very specific cases where specific code compiled by Intel's compiler is
executed on a specific processor from Intel. Even in those cases, it's
debatable whether these performance differences are meaningful at all.


Rui Maciel