Forums

What is the most "C unfriendly" architecture for which a workable C compiler exists ?

Started by Anton Erasmus June 3, 2006
Hi,

Since there is a thread on "C friendly" architectures, I thought it
might be interested to find out what sort of horrible architectures 
compiler writers actually managed to create a C compiler for.
(And what portion of the ISO C standard is/was not supported)
I asked the question (emailed Plauger if I recall correctl) once, on
why there is no "rotate" operator in C. ALL the architectures I have
ever work on had a direct assembly instruction for rotating a
register. The answer was that there were architectures which C
supports on which a "rotate" instruction made no sense. An example
was mention of an architecture that had NO integer support at the
assembly level. Integer operations had to be emulated using floating
point instructions.

Regards
  Anton Erasmus

Anton Erasmus <nobody@spam.prevent.net> wrote:
> Hi, > > Since there is a thread on "C friendly" architectures, I thought it > might be interested to find out what sort of horrible architectures > compiler writers actually managed to create a C compiler for.
CCS and Hi-Tech have "C compilers" for the PIC12. From what I recall, neither support reentrancy, one or t'other doesn't support the right semantics for automatics (treats them as statics). While I'd probably never code in a C-like language on a PIC12 through choice, the option's there. Not sure if there've been C compilers for any 4-bit micros -- I think that's reaching the point where anything you write for such a small machine is likely to be better off in assembly language. It *could* be done, but I think humans will be better at generating code for such CPUs. (Can't remember who observed in the other thread that the richer the register and instruction set of the processor, the less transparent he expected the generated code to be, because the compiler has more options as far as rearranging code, using different registers etc. are concerned - but he's absolutely right - particularly on chips with long pipelines where a lot of reordering goes on to keep them well-fed!) I think the ultimate challenge would be doing a compiler for the old Motorola 14500... if you could make it drive some RAM ;) pete -- pete@fenelon.com "That is enigmatic. That is textboo enigmatic..." - Dr Who "There's no room for enigmas in built-up areas." - N Blackwell
Pete Fenelon wrote:

> Anton Erasmus <nobody@spam.prevent.net> wrote: > >>Hi, >> >>Since there is a thread on "C friendly" architectures, I thought it >>might be interested to find out what sort of horrible architectures >>compiler writers actually managed to create a C compiler for. > > > CCS and Hi-Tech have "C compilers" for the PIC12. From what I recall, > neither support reentrancy, one or t'other doesn't support the right > semantics for automatics (treats them as statics). > > While I'd probably never code in a C-like language on a PIC12 through > choice, the option's there. > > Not sure if there've been C compilers for any 4-bit micros -- I think > that's reaching the point where anything you write for such a small > machine is likely to be better off in assembly language. It *could* be > done, but I think humans will be better at generating code for such > CPUs. > > (Can't remember who observed in the other thread that the richer the > register and instruction set of the processor, the less transparent > he expected the generated code to be, because the compiler has more > options as far as rearranging code, using different registers etc. > are concerned - but he's absolutely right - particularly on chips > with long pipelines where a lot of reordering goes on to > keep them well-fed!) > > I think the ultimate challenge would be doing a compiler for the old > Motorola 14500... if you could make it drive some RAM ;) > > pete
I'm not familiar with that processor, but trying to make an optimizing compiler for the ADSP 21xx would be a challenge -- if you ever need to answer the question "what's a non-orthogonal instruction set" just check that one out. Hand-optimizing assembly code would sometimes involve backtracking 20 instructions to change register choices, then trying it all again. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.html
Tim Wescott <tim@seemywebsite.com> wrote:
>> I think the ultimate challenge would be doing a compiler for the old >> Motorola 14500... if you could make it drive some RAM ;) >> >> pete > > I'm not familiar with that processor, but trying to make an optimizing > compiler for the ADSP 21xx would be a challenge -- if you ever need to > answer the question "what's a non-orthogonal instruction set" just check > that one out. Hand-optimizing assembly code would sometimes involve > backtracking 20 instructions to change register choices, then trying it > all again.
But that sounds the kind of code-gen you could try with all kinds of clever algorithms - anything up to and including the brute-force-and-ignorance of something like GNU superopt (which seems to have died the depth ;)) The problem with the 14500 is that it's a 1-bit controller ;) -- basically a replacement for relays ;) pete -- pete@fenelon.com "That is enigmatic. That is textbook enigmatic..." - Dr Who "There's no room for enigmas in built-up areas." - N Blackwell
Anton,
There are lots of horrible architectures out there and HLL hide a
multitude of their failings. The issues on implementing C on some
architectures becomes less once the intended applications are
well understood. The supporting C compilers often very well
support intended applications. Take the PIC12 mentioned else
where in this thread C removes the one thing that all assembly
programmers do badly with and that is long term maintenance of
ROM and RAM paging. The C compiler can track paging
registers and RAM reuse very well. It is practical to implement
a high level language on this type of processor.

The arguments against using C on the PIC12 include lack of
portability and lack of re-entrant code. (At least one compiler
has implemented re-entrant code on a PIC 12 more as a check
box issue rather than a practical use)

We have found that code is quite portable to processors
designed for a similar applications and less so for other processors.
Very few very small embedded systems require re-entrancy
in their applications  and my experience is that it more of a C
language requirement than an application implementation requirement.

Rotates, adds and subtracts with carry are all instructions that
support extended precision integer operations. It is interesting
that the extensions in ISO C standards for embedded systems
TR18037 makes it easy to create compilers that can support
these instructions without resorting to assembly code.

There have been worse processors than the Microchip PIC12
proposed for use in embedded systems. The PIC 12 found its
niche when it started being used in very small single purpose
applications and then the HLL started to make sense for it.
When we implemented a C compiler for the PIC12 tracking
the paging and instruction side effects were the most time
consuming.


w..



Anton Erasmus wrote:

> Hi, > > Since there is a thread on "C friendly" architectures, I thought it > might be interested to find out what sort of horrible architectures > compiler writers actually managed to create a C compiler for. > (And what portion of the ISO C standard is/was not supported) > I asked the question (emailed Plauger if I recall correctl) once, on > why there is no "rotate" operator in C. ALL the architectures I have > ever work on had a direct assembly instruction for rotating a > register. The answer was that there were architectures which C > supports on which a "rotate" instruction made no sense. An example > was mention of an architecture that had NO integer support at the > assembly level. Integer operations had to be emulated using floating > point instructions. > > Regards > Anton Erasmus
Anton Erasmus wrote:
> Hi, > > Since there is a thread on "C friendly" architectures, I thought it > might be interested to find out what sort of horrible architectures > compiler writers actually managed to create a C compiler for. > (And what portion of the ISO C standard is/was not supported) > I asked the question (emailed Plauger if I recall correctl) once, on > why there is no "rotate" operator in C. ALL the architectures I have > ever work on had a direct assembly instruction for rotating a > register. The answer was that there were architectures which C > supports on which a "rotate" instruction made no sense. An example > was mention of an architecture that had NO integer support at the > assembly level. Integer operations had to be emulated using floating > point instructions. > > Regards > Anton Erasmus >
The AVR tiny micros must be pretty close (the real, ramless tinies). The ISA itself is not too bad (except for the separate code and data spaces), but on the tiny's there is no RAM - only the 32 registers. There is a three-level hardware return stack, but no sensible way to make a data stack (although since the registers are memory-mapped to the data space, the single pointer register could theoretically be used as a data stack pointer). There's a C compiler from ImageCraft, and it's also possible to get gcc to work with it (although it involves a little bit of trickery).
Anton Erasmus wrote:
>Since there is a thread on "C friendly" architectures, I thought it >might be interested to find out what sort of horrible architectures >compiler writers actually managed to create a C compiler for. >(And what portion of the ISO C standard is/was not supported)
HP-1000 mini computers, (16 bit.) I am sure they are not the worst possible architecture for implementing C, but they had their quirks. (They were basically a 16 bit version of DEC's 12 bit PDP-8) A long time ago I ported the Small-C compiler to an HP-2113 and had to overcome the following: (a) Register set: Two accumulators, two index registers. (an architectural improvement over the original, that had only the two Accs) The X & Y index registers provided a few more operations and addressing modes at the cost of one or two more words, and one or two more memory access cycles. After trying a few alternate designs I found out that, in most cases, I could produce smaller and faster code if I did not use the index registers at all. (b) No hardware stack support - Must simulate stacks in software to support recursion or in-stack local variables, etc. (c) Limited addressing range inside the 32Kword address space. Opcodes could directly address operands in the same "page" were the opcode was located, or in page-0. I believe a page was a block of memory 1024 words. It was not a relative address, which would have been a little more usable. Anything else could only be accessed using indirect addressing via a pointer in memory. Setting the MSB in a word address added (in hardware) an extra level of indirection. i.e, trying to fetch the word pointed by 0x8123 will fetch the word whose address was stored at address 0x0123. If that word also had the MSB set one more level of indirection will ensue, and so on. (d) Different addresses for 16-bit words and 8-bit bytes at the same memory location. There were a few byte and string oriented instructions using the index registers mentioned above, but they used a different addressing form. The basic architecture used word addressing. From 0x0000 to 0x7fff words. (32Kwords, 64Kbytes) The byte instructions used 0x0000 to 0xffff. The word at address N contained the bytes at (byte) addresses 2N and 2N+1. Again, after a few false starts trying to save memory, I just made char = int = 16 bit. I got the compiler to work, but after a while I abandoned it and returned to Ratfor, which offered the same or more functionality than the original Small-C. (sans recursion)
David Brown wrote:
> Anton Erasmus wrote: >> Hi, >> >> Since there is a thread on "C friendly" architectures, I thought it >> might be interested to find out what sort of horrible architectures >> compiler writers actually managed to create a C compiler for. > > The AVR tiny micros must be pretty close (the real, ramless tinies).
Those are more or less obsolete by now... Hasn't been any new RAMless tiny's introduced in years
> The ISA itself is not too bad (except for the separate code and data > spaces), but on the tiny's there is no RAM - only the 32 registers. > There is a three-level hardware return stack, but no sensible way to > make a data stack (although since the registers are memory-mapped to > the data space, the single pointer register could theoretically be > used as a data stack pointer). There's a C compiler from ImageCraft, > and it's also possible to get gcc to work with it (although it > involves a little bit of trickery).
-- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
>Since there is a thread on "C friendly" architectures, I thought it >might be interested to find out what sort of horrible architectures >compiler writers actually managed to create a C compiler for.
There was an early C compiler for the GE 635, which had (36-bit) word addressing. Characters (6-bit) and bytes (9-bit) could be addressed only via extra indirection words. Where an ordinary pointer fit in 18 bits and could be in a register, byte or character pointers needed 36 and could only be in memory. On the other hand, it was otherwise pretty conventional - flat address space (unless you were running Multics on a VM-enabled processor), call/return through registers or memory stacks, twos complement. -- mac the na&#2013265935;f
Pete Fenelon wrote:
> Tim Wescott <tim@seemywebsite.com> wrote: > >>>I think the ultimate challenge would be doing a compiler for the old >>>Motorola 14500... if you could make it drive some RAM ;) >>> >>>pete >> >>I'm not familiar with that processor, but trying to make an optimizing >>compiler for the ADSP 21xx would be a challenge -- if you ever need to >>answer the question "what's a non-orthogonal instruction set" just check >>that one out. Hand-optimizing assembly code would sometimes involve >>backtracking 20 instructions to change register choices, then trying it >>all again. > > > But that sounds the kind of code-gen you could try with all kinds of > clever algorithms - anything up to and including the > brute-force-and-ignorance of something like GNU superopt (which seems to > have died the depth ;)) > > The problem with the 14500 is that it's a 1-bit controller ;) -- > basically a replacement for relays ;)
Has anyone actually used the 14500 ? - an example of a real application would be interesting. -jg