«

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.

Ir. Hj. Othman bin Hj. Ahmad wrote:

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

Were you looking for comp.compilers?

"Ir. Hj. Othman bin Hj. Ahmad" wrote:

> 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

Le 09/10/12 19:05, Walter Banks a écrit :
>
>
> "Ir. Hj. Othman bin Hj. Ahmad" wrote:
>
>> 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
>

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

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

David Brown wrote:

> 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

"Walter Banks" <> wrote in message
news:...

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

--
Bartc

David Brown wrote:

> On 10/10/2012 16:26, Walter Banks wrote:
>
>
> >
> > 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.
> >
>
> 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

BartC wrote:

> "Walter Banks" <> wrote in message
> news:...
>
> > 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?

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

On 09.10.2012 21:39, Ir. Hj. Othman bin Hj. Ahmad wrote:

> 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