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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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


Re: What is the most "C unfriendly" architecture for which a workable C compiler exists ?
Quoted text here. Click to load it

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
--
snipped-for-privacy@fenelon.com "That is enigmatic. That is textboo enigmatic..." - Dr Who
                 "There's no room for enigmas in built-up areas." - N Blackwell

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

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: What is the most "C unfriendly" architecture for which a workable C compiler exists ?
Quoted text here. Click to load it

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
--
snipped-for-privacy@fenelon.com "That is enigmatic. That is textbook enigmatic..." - Dr Who
                 "There's no room for enigmas in built-up areas." - N Blackwell

Re: What is the most "C unfriendly" architecture for which a workable C compiler exists ?
Quoted text here. Click to load it

Has anyone actually used the 14500 ? - an example of a real application
would be interesting.

-jg


Re: What is the most "C unfriendly" architecture for which a workable C compiler exists ?
On Thu, 08 Jun 2006 10:39:02 +1200, the renowned Jim Granville

Quoted text here. Click to load it

The real application is for a PLC-like controller. Think ladder logic.


Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: What is the most "C unfriendly" architecture for which a workable C compiler exists ?

Quoted text here. Click to load it
<snip>>>
Quoted text here. Click to load it

  I realise what Motorola  intended it to be used for; I'm curious if
anyone actually did a design using one ?

I have seen PLCs using the Signetics 8X300, which relative to the
14500, was an advanced chip :)

-jg


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

Quoted text here. Click to load it


A customer had a 14500-based PLC board for a packing machine back in
1981-ish when PLCs were expensive. Hex keypad program entry, EEPROM
program memory. I used to write programs for it, using a photocopied
coding sheet. It was an antique way of doing things even then. I've
still got one of them around somewhere.

Paul Burke

Re: What is the most "C unfriendly" architecture for which a workableC compiler exists ?
Quoted text here. Click to load it

Wow, thanks.
Was that x8 EPROM, or wider ?
Did you ever code counters in this ?

I've been mulling over the idea of doing a 14500 in a CPLD,
mainly as a teaching exercise.

I can see simple ladder logic is do-able, but then wondered how to
implement something like a  counter, as the opcodes seem just a little
short on that. No atomic complement data, for example,
SKZ, but not SKNZ, and I'd be tempted to allow longer Skip sizes.....

Maybe it needs a 14500++ :)


-jg



Re: What is the most "C unfriendly" architecture for which a workableC compiler exists ?

Quoted text here. Click to load it

I've just dug it out of the glory hole... the one I've got here is a
very late one, with 85 date codes on the chips. The program store is an
XC2816 with an RS label (that was shortly after they'd stopped being
Radiospares). The RAM is a 2147. Sadly I junked all the circuit diagrams
etc. about 6 years ago.

I never did counters, it was all straightforward relay replacement stuff.

Paul Burke

Re: What is the most "C unfriendly" architecture for which a workableCcompiler exists ?

Quoted text here. Click to load it

You probably thought no one would ever ask about it :)

Quoted text here. Click to load it

Thanks.
I've worked out that counters are possible, with some small extensions.

As time allows, I think I'll code a 14500, then re-map the 16 opcodes to
remove dead spaces...
-jg


Re: What is the most "C unfriendly" architecture for which a workable C compiler exists ?
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:

Quoted text here. Click to load it


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

Quoted text here. Click to load it

Can you clarify this - do you mean you will be (finally)
able to (eg) RotateRight(arg), and RotateRightCY(arg) ?

-jg


Re: What is the most "C unfriendly" architecture for which a workableC compiler exists ?

--------------9FAEB4075ED7A5ABD5420EBF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jim,

TR 18037 allows direct access to the processors registers. If the
condition codes are declared as a

register volatile struct {
       int is_IRQ       : 1;
       int disable_FIRQ : 1;
       int half_carry   : 1;
       int disable_IRQ  : 1;
       int N            : 1;
       int Z            : 1;
       int V            : 1;
       int C            : 1;
   } CC;

then

c = a + CC.C + b;

should now generate a

load  a
adc   b
store c

sequence. Similarily other instructions that
involve condition code access can now be used.

w..






Jim Granville wrote:

Quoted text here. Click to load it

--------------9FAEB4075ED7A5ABD5420EBF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Jim,
<p>TR 18037 allows direct access to the processors registers. If the
<br>condition codes are declared as a
<p><tt>register volatile struct {</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int
is_IRQ&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

: 1;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int disable_FIRQ : 1;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int half_carry&nbsp;&nbsp;
: 1;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int disable_IRQ&nbsp; : 1;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int
N&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

: 1;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int
Z&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

: 1;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int
V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

: 1;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int
C&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

: 1;</tt>
<br><tt>&nbsp;&nbsp; } CC;</tt>
<p>then
<p>c = a + CC.C + b;
<p>should now generate a
<p>load&nbsp; a
<br>adc&nbsp;&nbsp; b
<br>store c
<p>sequence. Similarily other instructions that
<br>involve condition code access can now be used.
<p>w..
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p>Jim Granville wrote:
<blockquote TYPE=CITE>Walter Banks wrote:
<p>> Rotates, adds and subtracts with carry are all instructions that
<br>> support extended precision integer operations. It is interesting
<br>> that the extensions in ISO C standards for embedded systems
<br>> TR18037 makes it easy to create compilers that can support
<br>> these instructions without resorting to assembly code.
<p>Can you clarify this - do you mean you will be (finally)
<br>able to (eg) RotateRight(arg), and RotateRightCY(arg) ?
<p>-jg</blockquote>
</html>

--------------9FAEB4075ED7A5ABD5420EBF--


Re: What is the most "C unfriendly" architecture for which a workableC compiler exists ?
Thanks,
  Sounds like a worthwhile improvement (when supported:) , but it still
does not allow access to RR/RRC opcodes ?

-jg


Walter Banks wrote:

Quoted text here. Click to load it


Re: What is the most "C unfriendly" architecture for which a workableC compiler exists ?

Quoted text here. Click to load it

Would this work if compiler is smart enough?

#define    RRC(c)         CC.C?(c >> 1)|0x80:(c >> 1)
#define    RR(c)            { unsigned short tmp;
                                         tmp = c & 0x80;
                                         c = (c >> 1) | tmp;
                                      }
#define    RLC            CC.C?(c << 1)|0x01:(c << 1)
#define    RL(c)          c = (c << 1) ; c |= CC.C;


I/O accesses seems to be converted to ints before use, this sucks...

        iowr(PORT,iord(PORT) | (1 << bit));

to set a bit :-(

        PORT.bit = 1;

Would be nicer...



--
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.
Re: What is the most "C unfriendly" architecture for which a workableC compiler exists ?

Quoted text here. Click to load it

  Certainly would, it would bring C code to where Modula-2 has been for
over 15 years :)

  I think Walter's example should also expand for Ports, as he creates a
struct of bits
( tho each element is int :1, not bit, which I thought was now C-legal ? )

ie if one can accsss Carry as CC.C, then any port should be accessible
as PortName.BitName ?

-jg





Re: What is the most "C unfriendly" architecture for which a workableCcompiler exists ?

Our C compilers can access PortName.BitName. In the more general case
ports can more than one bit field be typed or mapped on structs.

There was a lot of effort in when TR18037 was written to include those
things that collectively we has some experience with.

Access to the registers and user defined memory have seen a lot of use.

w..



Jim Granville wrote:

Quoted text here. Click to load it


Re: What is the most "C unfriendly" architecture for which a workableCcompiler exists ?
Quoted text here. Click to load it

Many do, but is it "Embedded C"?

Quoted text here. Click to load it

But can you define which register you are using?

The IAR construct:
__no_init __regvar    unsigned char my_register_variable @ 2;
tells you to use register 2.

This is very useful for small applications, allowing global variables in
regusters.


--
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.
Re: What is the most "C unfriendly" architecture for which a workableCcompiler exists ?
We have implemented the parts of Embedded C that are applicable to each of the
compilers we have implemented in the last few years. All of them have fixed
point arithmetic (fracts and accums) and all of them have named address spaces
and named register
storage classes.

Ulf Samuelsson wrote:

Quoted text here. Click to load it

The Embedded TR18037 formally defined this wide spread practice.

Quoted text here. Click to load it

Global variables can be allocated to specific registers or allocated to the next
available register. The compiler sees this as an application constraint and
creates code using the remaining registers for locals and temporaries.

Quoted text here. Click to load it

Agreed.

w..



Site Timeline