C90 penetration

[kerravon]

I'm interested to know what platforms exist that don't have a free
C90 compiler yet.

Such that a person would be in a position where they can't even
accept a 20-line C program and would need to recode the
functionality in assembler etc, because they can't justify buying
a C compiler to compile a 20-line program they are interested in.


ie how far off are we from having a lingua franca for computers?


Previously the biggest that I knew of was MVS. Then CMS.
But those have recently been covered by ports of GCC. That
means the biggest that I know of is DOS/VS(E).


Is there anything out there with more users/programmers than
DOS/VS(E)?


BFN. Paul.

 

[Eric Sosman]

I'm interested to know what platforms exist that don't have a free
C90 compiler yet.
[...]

You'll have to define "platform" to get a meaningful
answer. The computers in my automobile engine, for example,
probably don't have free C compilers. Not sure about my
mobile phone, my television, my cable modem, ... All these
are programmed, but possibly not in C and possibly not in
C that was compiled by a free compiler.

 

[Stephen Sprunk]

I'm interested to know what platforms exist that don't have a free
C90 compiler yet.
[...]

You'll have to define "platform" to get a meaningful
answer. The computers in my automobile engine, for example,
probably don't have free C compilers. Not sure about my
mobile phone, my television, my cable modem, ... All these
are programmed, but possibly not in C and possibly not in
C that was compiled by a free compiler.

GCC is used as a cross-compiler for a _lot_ of embedded systems,
including auto engines, mobile phones, televisions, cable modems, etc.
I don't have a list of every chip ever used, but all the ones I've run
across so far (11 years in embedded systems) were targetable by GCC. A
lot of that work was done by a company (I forget the name now) that
specialized in adding new backends to GCC, paid for with support
contracts; I don't know if they're still around.

S

 

[Walter Banks]

GCC is used as a cross-compiler for a _lot_ of embedded systems,
including auto engines

This is not currently true. There are lots of issues with GCC for
automotive engine controller applications.

Regards,

 

[kerravon]

I'm interested to know what platforms exist that don't have a free
C90 compiler yet.
[...]

     You'll have to define "platform" to get a meaningful
answer.  The computers in my automobile engine, for example,
probably don't have free C compilers.  Not sure about my
mobile phone, my television, my cable modem, ...  All these
are programmed,

Ok - two definitions.

1. A platform that has a native assembler and editor that
people use to write and compile assembler code.

2. Any system that has assembler code currently being written
for it.


Basically my goal is to make assembler optional instead of
mandatory for non-speed-critical code. Starting with platforms
in category 1. Then doing 2.

but possibly not in C and possibly not in
C that was compiled by a free compiler.

Doesn't need to be free. I just want a free C compiler to
be available, so that people have a choice to not have to
program basic logic in assembler.

BFN. Paul.

 

[kerravon]

Probably nobody has yet bothered to develop a free C90 compiler for most
microcomputers from the 1980s and 1970s.

Which of these is in most widespread use? Especially commercial
use, as in someone writing assembler (or an alternate high level
language) for it and being paid to do it.

BFN. Paul.

 

[kerravon]

I strongly suspect that gcc will run on pretty much any "platform" which
can accept user sessions.

The IBM mainframes have always been the exception to this, a
gap which is only just now being closed with GCCMVS:

http://gccmvs.sourceforge.net

That is closing MVS and CMS. There's still DOS/VS(E) to be
done. And possibly z/TPF. I'll need to double-check that.
And that's the end of what I know of. The other IBM
mainframe platform in commercial use is z/Linux, which is
supported by GCC.

For those platforms that don't such as
embedded chips, EEPROM or CMOS devices etc, the soft- or firmware can be
written on another platform and crosscompiled.


Define "computer" and we can tell...

See above definition of "platform".

BFN. Paul.

 

[kerravon]

Only 11 years in embedded systems?  Almost 3 times that long for me.
Is there a gcc cross for 8085? Z80? 8048? Z8? 6502?

There is for the Z80 in that list:

http://sdcc.sourceforge.net/

The others might be, since I don't know what they are:

"Intel 8051, Maxim 80DS390, Zilog Z80 and the Motorola 68HC08 based
MCUs. Work is in progress on supporting the Microchip PIC16 and PIC18
series. AVR and gbz80 targets are no longer maintained".

BFN. Paul.

 

[kerravon]

I doubt that there's a GCC cross-compiler for the 6502, though there is a
Free cross-compiler specifically written for that processor; namely, cc65..

Thanks for the pointer!

http://www.cc65.org/

It describes itself as "almost ISO C compatible", though that might be a
bit generous:  among the ISO/ANSI C features it does not support include
the float and double datatypes,

Would it be legal for a C90 compiler to define both of
these as a long, and just specify that the "precision"
is such that it "rounds" at 1?

functions returning struct, and passing
structs by value.  

I wonder if these would be difficult to implement, in a
hacky manner?

The other thing is bitfields. I wonder if those can
be legally represented at chars.

Though it's primarily intended for cross-compiling to
1980s microcomputers and game consoles, the author claims that the runtime
library and standard C library are sufficiently portable that they should
work with any 6502 system (presumably including modern-day embedded
systems).

Except for the file I/O of course. Which is the biggest thing.

Between cc65 and sdcc, I think almost all the microcomputers
from the 80s would be covered, if anyone was using them.

Well, there is the non-compliance in some aspects. Interestingly,
SDCC has similar restrictions:

http://sdcc.sourceforge.net/doc/sdccman.html/node182.html

with structures and double. Also K&R style isn't supported.

So does this mean that after DOS/VS(E) and possibly z/TPF,
the next milestones would be bringing SDCC & C65 into
compliance? With possibly some file I/O missing for some
obscure microcomputers?

Or is there some other class (e.g. Supercomputers) that
are lacking a free C compiler (just as with the IBM
mainframes)?

BFN. Paul.

 

[kerravon]

For more than a decade most serious commercial compilers
have not needed assembler for speed critical code. Why is this
myth still being promoted?

C90 is a twenty year old standard. There are better standards
and practices

Not if you're after a common computer language that can
be used as a replacement for assembler.

As you can see from GCCMVS, SDCC and CC65, we still haven't
even achieved C90 compliance yet.

BFN. Paul.

 

[Walter Banks]

Basically my goal is to make assembler optional instead of
mandatory for non-speed-critical code.

For more than a decade most serious commercial compilers
have not needed assembler for speed critical code. Why is this
myth still being promoted?

C90 is a twenty year old standard. There are better standards
and practices

Regards,

 

[Walter Banks]

I am intrigued as to what make AEC apps so special that GCC is
unsuitable for them yet it is for other similar type devices.

For AEC Code generation, compiler support and multiprocessor feature sets.

Regards,

 

[James Kuyper]

Thanks for the pointer!

http://www.cc65.org/


Would it be legal for a C90 compiler to define both of
these as a long, and just specify that the "precision"
is such that it "rounds" at 1?

That's inconsistent with (among many other things) the maximum values
for FLT_EPSILON and DBL_EPSILON specified in 5.2.4.2.2p11.

....

The other thing is bitfields. I wonder if those can
be legally represented at chars.

Any platform which allows implementation of the bitwise operators will
also allow implementation of bit-fields.
A bit-field whose size is CHAR_BIT, can certainly be represented by a
char; bit fields of a larger size clearly cannot be represented as a
single char. Bit fields of a smaller size must behave as if they only
had the specified number of bits: for instance, storing a -1 in an
unsigned bit-field with a width of 3 has to produce a result of 7, not
UCHAR_MAX. This would require bit-wise manipulation just as complicated
as that required to implement bit-field that only take up the specified
number of bits, so there doesn't seem much point to it.

Also, the standard requires that if a bit field with a width of (for
instance) 3 is followed by a bit field with a width of 4, then if
there's enough room in the allocation unit (which is guaranteed to be
the case for those two numbers), they must be allocated in adjacent bits
within that allocation unit; that's pretty hard to do if you implement
them as chars.

Except for the file I/O of course. Which is the biggest thing.

A conforming implementation of C can have file I/O that always fails:
nothing is the standard requires that any I/O function call must
succeed. Of course, the simplest approach is to conform only to the
requirements for a freestanding implementation, in which case the
<stdio.h> portion of the standard library need not be implemented at all.

 

[kerravon]

C90 doesn't do that. C99 plus ISO 18037 can

That doesn't meet the requirements of "common computer
language" given that the above combination is probably
less widely implemented than Cobol 85. Nevermind universally
implemented!

BFN. Paul.

 

[Walter Banks]

Not if you're after a common computer language that can
be used as a replacement for assembler.

C90 doesn't do that. C99 plus ISO 18037 can

Regards,

 

[kerravon]

That's inconsistent with (among many other things) the maximum values
for FLT_EPSILON and DBL_EPSILON specified in 5.2.4.2.2p11.

Ok. Another alternative. Is there anything preventing float
and double being defined as say

typedef struct {
char decimal[100];
} double;

and then implemented as a really crappy C library, but
taking the burden off the compiler, while still meeting
C90 requirements?

single char. Bit fields of a smaller size must behave as if they only
had the specified number of bits: for instance, storing a -1 in an
unsigned bit-field with a width of 3 has to produce a result of 7, not
UCHAR_MAX. This would require bit-wise manipulation just as complicated
as that required to implement bit-field that only take up the specified
number of bits, so there doesn't seem much point to it.

Ok. So no shortcut there.

A conforming implementation of C can have file I/O that always fails:
nothing is the standard requires that any I/O function call must
succeed.

Crikey! Not even printf("hello, world\n"); is portable then!!!

BFN. Paul.

 

[Walter Banks]

I am intrigued as to what make AEC apps so special that GCC is
unsuitable for them yet it is for other similar type devices.

Missed that GCC doesn't support the processors used in AEC's

Regards,

 

[luser-ex-troll]

Not if you're after a common computer language that can
be used as a replacement for assembler.

As you can see from GCCMVS, SDCC and CC65, we still haven't
even achieved C90 compliance yet.

BFN.  Paul.

There are likely to be forth interpreters for most popular processors.
There's a nice article out there that discusses it. Search for
"Porting Forth". Forth has also been used as the BIOS for computers
ranging from the Apple II to the OLPC XO-1 on which I type this.

 

[Keith Thompson]

Or is there some other class (e.g. Supercomputers) that
are lacking a free C compiler (just as with the IBM
mainframes)?

I used to work on a Cray T90 and a Cray T3E. Both had Cray's native C
compilers, but there was no gcc for either of them. The T3E used
Alpha CPUs, so adapting gcc probably wouldn't have been too difficult,
but there probably wasn't enough demand to justify it. Since both
systems already had C compilers, a gcc port would have had to compete
for performance (and if you don't care about performance, you're not
going to use a Cray).

I haven't followed the newer Cray models, but I suspect the situation
is similar.

 

[Stephen Sprunk]

The company was probably Cygnus Solutions.

That's it, thanks!

The company was purchased by Redhat and Redhat kind of destroyed them.
Cygnus had some very useful tools, and Redhat didn't like their tools,
and bought them primarily for their GNU toolchain expertise. Some
developers ended up leaving at that point from what I understood.

That's rather unfortunate, but not uncommon for tech acquisitions...

They were also the makers of Cygwin, which I think is still a somewhat
active project.

It's still active as a community project, but I haven't noticed any
significant progress or improvements (other than updating packages for
other OSS) in several years.

S