C90 penetration

[jameskuyper]

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;

It can't literally be a typedef for a struct, at least not as seen by
user code. A conforming compiler must diagnose code like the
following, for instance:

double d = {"decimal string"};
d.decimal[4] = 'a';

However, a conforming implementation could, in the internals of
functions which implement floating point operations, treat double as
if it were store in a way that is equivalent to the above typedef.

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

That would be possible, depending upon how the char array were used,
which is something you haven't specified. I suspect that you intend to
use it to store a string representation of the floating point number
similar to what sprintf() could create with the appropriate format
specifiers (making implementation of that particular specifier for
sprint() trivial). Before you decide to take that route, I would
recommend looking at section 5.2.4.2.2 very carefully, as well as well
as 7.7 (<float.h>) and 7.12 (<math.h>). I think that, in the end,
you'll find that the easiest way to meet those requirements on a
machine without an FPU is to emulate an FPU in software. Storing
numbers in string format won't make the task easier, it will make it
harder.

 

[Walter Banks]

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!

C90 doesn't have the syntax to replace assembler. It doesn't
meet your stated requirement for

The combination meets this requirement.

Regards,

 

[Walter Banks]

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!

However the installed base of processors using that combination
probably exceeds that of those implemented using C90 compilers.

w..

 

[Ben Bacarisse]

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?[/QUOTE]

Since the compiler in question can't pass structs that would not get
you very far! If that were fixed then, yes, a software library based
on some hidden struct type would be quite possible (the fact that the
type is a struct has to be hidden or illegal fragments like double d;
d.decimal[0] = 1; would be permitted).

 

[Keith Thompson]

On Mar 27, 1:26 am, James Kuyper <[email protected]> wrote:

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?

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?

Since the compiler in question can't pass structs that would not get
you very far! If that were fixed then, yes, a software library based
on some hidden struct type would be quite possible (the fact that the
type is a struct has to be hidden or illegal fragments like double d;
d.decimal[0] = 1; would be permitted).

It might suffice to use a reserved name, for example:

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

Then the compiler would accept
double d;
d._Decimal[0] = 1;
but since the use of the identifier invokes undefined behavior, that's
not a conformance problem.

I think.

 

[jameskuyper]

Keith Thompson wrote:
....

It might suffice to use a reserved name, for example:

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

Then the compiler would accept
double d;
d._Decimal[0] = 1;
but since the use of the identifier invokes undefined behavior, that's
not a conformance problem.

That wouldn't resolve the problem of:

double d = {"I am not a number, I am a free man!"};

 

[Keith Thompson]

Keith Thompson wrote:
...

It might suffice to use a reserved name, for example:

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

Then the compiler would accept
double d;
d._Decimal[0] = 1;
but since the use of the identifier invokes undefined behavior, that's
not a conformance problem.

That wouldn't resolve the problem of:

double d = {"I am not a number, I am a free man!"};

Ah, good point.

In any case, the suggestion was to implement floating-point via "a
really crappy C library". Since there are non-crappy C libraries out
there that do the same thing, crappy libraries should be of no more
than theoretical interest.

 

[kerravon]

There are likely to be forth interpreters for most popular processors.

To be a substitute for assembler, it needs to generate
machine code, not be an interpreter. And I see that that
is what is done by modern Forth engines.

There's a nice article out there that discusses it. Search for
"Porting Forth".

I searched for that, and eventually wound up here:

http://www.complang.tuwien.ac.at/fo...-Cross-Compiler.html#Using-the-Cross-Compiler

where it appears that they use C to implement Forth on
an alien machine.

"true DefaultValue prims \ true: primitives are c-code"

So once again we are back to C being the universal language.
Once you have C in place, you are then in a position to
plonk things like even Cobol (e.g. Open Cobol) on top of it.

BFN. Paul.

 

[CBFalconer]

.... snip ...


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

Sure it is. It just returns a run-time error.

 

[CBFalconer]

.... snip ...

That wouldn't resolve the problem of:

double d = {"I am not a number, I am a free man!"};

If we agree on a set of digits that includes all Latin 1 alpha,
space, comma, and the digits from 0 through 9, and agree that
characters outside that set are to be discarded, the above can
represent a number in base 64. If we also allow the '!', and make
the ',' represent 'e' for exponents, the above also seems to be a
valid floating point value.

Note the magic of definitions.

 

[CBFalconer]

.... snip ...

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.

I haven't checked it, but I thought that gcc (at least the C
compiler) source was compatible with standard C. If so, porting
should be trivial.

 

[kerravon]

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

Would it be true to say that absolutely everyone who bought
a Cray computer had the C compiler with it as well, so that
if you wanted to send some C code to someone to do a task,
he would never come back with "sorry, I can't use that C
code, since our lousy boss didn't buy the C compiler, and
there's no gcc either, so if I want to do that functionality
I'll need to rewrite that in Cray Assembler/Fortran/whatever
my boss is willing to buy"?

BFN. Paul.

 

[kerravon]

C90 doesn't have the syntax to replace assembler. It doesn't
meet your stated requirement for


The combination meets this requirement.

Sorry. I didn't mean to imply totally replace assembler. What
I mean was that portable application logic (e.g. a CRC
calculation) would not have to be written in assembler.

I still expect assembler to be used in some low-level
situations, and to be called from C.

BFN. Paul.

 

[kerravon]

However the installed base of processors using that combination
probably exceeds that of those implemented using C90 compilers.

Sure. I wouldn't dispute that that is a superior thing to
use for programmer productivity.

However, what I'm looking for is to make sure that if I have a
CRC routine written in a particular language, it can be targetted
to that "installed base of processors". Which, being a subset
of the combination you mentioned, it most certainly can.

BFN. Paul.

 

[Keith Thompson]

I haven't checked it, but I thought that gcc (at least the C
compiler) source was compatible with standard C. If so, porting
should be trivial.

At least for the T90, you'd have to write a code generator, which is
hardly trivial. The T3E uses the Alpha processor, which is already a
gcc target, but there would presumably be some differences in what it
would have to generate (I have no idea about the details). See above
for reasons why it probably wouldn't be worth the effort; matching the
optimization performed by Cray's own C compilers would, I suspect, be
decidedly non-trivial.

In any case, the T90 and T3E I worked on were decommissioned some
years ago; I don't know whether any of the beasts are still running.
(A pity; it was fun to watch the waterfall of Flourinert coolant
visible through the front window of the T90.)

 

[kerravon]

In any case, the suggestion was to implement floating-point via "a
really crappy C library".  Since there are non-crappy C libraries out
there that do the same thing, crappy libraries should be of no more
than theoretical interest.

Can you suggest a non-crappy C library that could be
plugged in to cc65? ie that has licence restrictions
no more onerous than the current cc65 ones.

BFN. Paul.

 

[kerravon]

I haven't checked it, but I thought that gcc (at least the C
compiler) source was compatible with standard C.  If so, porting
should be trivial.

The GCC code is full of Unix nonsense. They even open files
with open() instead of fopen(), for no reason that I can
think of for what is after all a text-processing program!

None of this nonsense was available on IBM mainframes (at
least not in their native environments). There was too
much code to change to get rid of this, so what I instead
did was to implement open() in terms of fopen(). This
reduced the amount of code changes required. Then there
were all the ASCII assumptions, which someone else took
care of (mostly).

Then there was the way it called system() (at best) for
the various stages. I converted this into a simple function
call, renamed all the duplicate functions this caused, and
so now, yes, we have a standard C version of GCC.

Almost, anyway.

There are still some things like dependencies on the way
varargs has been implemented, and string literals that are
longer than standard length, but it's close enough. And
since it only needs to compile itself with itself usually,
that is good enough once you have the C library for your
target environment. Also this version doesn't cope with
64-bit ints/longs for some reason.

The above changes can be obtained from:

http://gccmvs.sourceforge.net

Note that the exercise above was done to 3.2.3. An
effort is still underway to repeat for 3.4.6. After
that maybe GCC 4 can be looked at, but it doesn't help
that they decided to delete the entire i370 target
in GCC 4!

BFN. Paul.

 

[Keith Thompson]

Would it be true to say that absolutely everyone who bought
a Cray computer had the C compiler with it as well, so that
if you wanted to send some C code to someone to do a task,
he would never come back with "sorry, I can't use that C
code, since our lousy boss didn't buy the C compiler, and
there's no gcc either, so if I want to do that functionality
I'll need to rewrite that in Cray Assembler/Fortran/whatever
my boss is willing to buy"?

I don't know. I suspect so; the two systems both ran Unicos, Cray's
BSD-based Unix system, and not having a C compiler would seem (to me
at least) to be a bit silly. But for all I know it may have been
optional, or even an extra cost.

 

[luser-ex-troll]

To be a substitute for assembler, it needs to generate
machine code, not be an interpreter. And I see that that
is what is done by modern Forth engines.

Forth is an assembler/disassembler/debugger/interpreter. It does it
all. You may not be employing a very precise definition of
interpreter.

I searched for that, and eventually wound up here:

http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Using-the-Cro...

where it appears that they use C to implement Forth on
an alien machine.

I think the word "they" is leading to sloppy thinking. The first
implementation of forth was on punch cards. He didn't use C to port
it; he used a cardboard box.

"true DefaultValue prims         \ true: primitives are c-code"

So once again we are back to C being the universal language.
Once you have C in place, you are then in a position to
plonk things like even Cobol (e.g. Open Cobol) on top of it.

With all due respect, the fact that gforth is implemented in c is, if
anything, a stronger reason to investigate what micros have a forth
but not C. Then forth could be your lingua franca for all of them.
I misremembered the article I mentioned. It's called "Moving Forth".
So you don't have to search, try here:

http://www.bradrodriguez.com/papers/

And wikipedia has a nice overview of all the wonderful things it does.

http://en.wikipedia.org/wiki/Forth_(programming_language)

hth

 

[James Kuyper]

jameskuyper wrote:
... snip ...

If we agree on a set of digits that includes all Latin 1 alpha,
space, comma, and the digits from 0 through 9, and agree that
characters outside that set are to be discarded, the above can
represent a number in base 64. If we also allow the '!', and make
the ',' represent 'e' for exponents, the above also seems to be a
valid floating point value.

You miss the point; if 'double' were indeed a typedef for a struct
containing a char array, then the above initialization would normally be
acceptable; however, according to the C standard, such code is a
constraint violation for which a diagnostic is required. The compiler
could disallow, or at least diagnose, such code as a special case, but
it would require special-case handling.