1. Translator and ANSI C
Hey, Rob.
I thought that C was an ANSI standard. So I don't understand why 7 different
compilers require so much support. I mean I can understand that different
compilers have different command-line options but why are the .c files different
and why do the runtime libraries have to be different?
When trying to compile some translated C files with an unsupported compiler, I
did get an error that the compiler couldn't cast an int * to an int **
implicitly. If this is an error with one compiler, why is it not an error with
another?
j.
2. Re: Translator and ANSI C
Jason Gade wrote:
>
> Hey, Rob.
>
> I thought that C was an ANSI standard. So I don't understand why 7 different
> compilers
> require so much support. I mean I can understand that different compilers
> have different
> command-line options but why are the .c files different and why do the runtime
> libraries
> have to be different?
>
> When trying to compile some translated C files with an unsupported compiler, I
> did
> get an error that the compiler couldn't cast an int * to an int ** implicitly.
> If
> this is an error with one compiler, why is it not an error with another?
That is the main reason I left C. For some reason
what worked on one compiler almost never works on
another. Different compilers have some different
features.
>
>
> j.
>
3. Re: Translator and ANSI C
Think of the "C" that the translator outputs as an
intermediate language, not as a standard language.
Rob might have chosen a p-code or an assembly language,
and they aren't standard either. The end result is
compiled machine instructions and if his choice of
compiler was good the final exe can be pretty spiffy.
4. Re: Translator and ANSI C
> Think of the "C" that the translator outputs as an
> intermediate language, not as a standard language.
> Rob might have chosen a p-code or an assembly language,
> and they aren't standard either. The end result is
> compiled machine instructions and if his choice of
> compiler was good the final exe can be pretty spiffy.
We have an assembler written in Euphoria right? Why don't we just skip
all this C mumbo-jumbo and translate drictly to Assembly and into
machine code? (Oh, wait, that would be a compiler, nevermind...)
~Greg
5. Re: Translator and ANSI C
Jason Gade wrote:
> I thought that C was an ANSI standard. So I don't understand why 7 different
> compilers
> require so much support. I mean I can understand that different compilers
> have different
> command-line options but why are the .c files different and why do the runtime
> libraries
> have to be different?
The core C language is standardized, though there are some gray areas.
Some operations are left up to the compiler implementer to define,
e.g. whether a right shift fills with 0's or 1's, etc.
The include files supplied with the compiler and the
less-common library routines can vary. The way that the
storage allocator works can be very different, which affects
Euphoria because I make a few low-level assumptions about that.
The (machine-level) calling conventions,
and object file formats, are not well standardized.
This makes it difficult to
call a C routine compiled by one compiler from code
compiled by another, or link object files from
different compilers. So that means I have to build a version
of the Translator run-time library using each different
C compiler, and of course re-test it each time I make some changes.
The code to support the dir() function and others,
is different with each compiler,
yet I want to present a standard result to the Euphoria user.
> When trying to compile some translated C files with an unsupported compiler, I
> did
> get an error that the compiler couldn't cast an int * to an int ** implicitly.
> If
> this is an error with one compiler, why is it not an error with another?
C started off as a very loose, sleazy, language regarding
type checking. It was intended as a replacement for
assembly language, for use in developing code for
an operating system. Later it became more fashionable to
be strict about types. Each C compiler has a different standard
for warning and error reporting. One compiler may "let it go",
while another issues a mild warning, while a third calls it an
error and refuses to compile it.
The example you give might be corrected in the
Translator by adding a "cast" to convert an int* to an int**
or it could be a symptom of some other problem.
With the 7 supported compilers the generated C code
should compile cleanly, without errors /warnings.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
