Re: C as assembly language

vbdis@aol.com (VBDis)
12 Apr 2001 02:49:27 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: C as assembly language andi@complang.tuwien.ac.at (2001-04-10)
Re: C as assembly language jmorris2@twcny.rr.com (Morrisett) (2001-04-10)
Re: C as assembly language jacob@jacob.remcomp.fr (jacob navia) (2001-04-10)
Re: C as assembly language felixundduni@freenet.de (felix) (2001-04-10)
Re: C as assembly language fjh@cs.mu.OZ.AU (2001-04-10)
Re: C as assembly language fjh@cs.mu.OZ.AU (2001-04-12)
Re: C as assembly language vbdis@aol.com (2001-04-12)
Re: C as assembly language felixundduni@freenet.de (felix) (2001-04-14)
Re: C as assembly language fjh@cs.mu.OZ.AU (2001-04-14)
Re: C as assembly language rhyde@transdimension.com (Randall Hyde) (2001-04-14)
Re: C as assembly language vbdis@aol.com (2001-04-15)
Re: C as assembly language jim.granville@designtools.co.nz (Jim Granville) (2001-04-18)
Re: C as assembly language joachim_d@gmx.de (Joachim Durchholz) (2001-05-03)
[5 later articles]
| List of all articles for this month |

From: vbdis@aol.com (VBDis)
Newsgroups: comp.compilers
Date: 12 Apr 2001 02:49:27 -0400
Organization: AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com
References: 01-04-027
Keywords: C, practice
Posted-Date: 12 Apr 2001 02:49:26 EDT

"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


Post a followup to this message

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