Re: C as assembly language

"Joachim Durchholz" <joachim_d@gmx.de> schreibt:


>Hmm... there are a few additional cases where C is simply inappropriate:


C was /designed/ as a replacement for assembly language, and IMO this
goal is reached nowadays, too. No real assembler will define or deal
with exceptions and like constructs, which are beyond the creation of
CPU instructions.


AFAIR one of the strongest arguments and restrictions of the language
specification was, that the assembly programmer should be able to
exactly predict the native instructions, created by the C
compiler. This expectation cannot hold, when the instruction set
prevents the creation of such a unique instruction stream from a C
primitive (statement or expression), as is true for current
"incompatible" (Intel or RISC) processors. Similarly every assumption
about "improved" parameter passing, overflow handling etc. is out of C
scope.


It should be clear, that no single high-level-language can replace an
assembler for /all/ current processors. So the usablity of C IMO
depends on the way, how the /compiler/ can be /adopted/ to a specific
set of processors. Some extensions of the C language can be handled in
the preprocessor, others must be built into the language and compiler
itself.


C++ or C# are far away from C and processors, and establish their own
model of execution on the target machine. Better use C or any other
HLL instead, which better suits your expectations on OO programming.




IMO it's easier to make an assembler understand C, than to make an C
compiler understand machine specific constructs. No smilie here,
opposed to my first intention. C was designed for a specific set of
processors, existing at that time (many decades ago), not at all for
processors in general.


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.