Re: C as assembly language

thp@cs.ucr.edu
31 Mar 2002 23:31:44 -0500

          From comp.compilers

Related articles
[13 earlier articles]
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)
Re: C as assembly language joachim_d@gmx.de (Joachim Durchholz) (2001-05-07)
Re: C as assembly language Hans_Boehm@hp.com (Hans Boehm) (2001-05-07)
Re: C as assembly language jthorn@galileo.thp.univie.ac.at (2001-05-13)
Re: C as assembly language david.thompson1@worldnet.att.net (David Thompson) (2001-05-15)
Re: C as assembly language thp@cs.ucr.edu (2002-03-31)
| List of all articles for this month |
From: thp@cs.ucr.edu
Newsgroups: comp.compilers
Date: 31 Mar 2002 23:31:44 -0500
Organization: University of California, Riverside
References: 01-04-027 01-04-085
Keywords: C, design
Posted-Date: 31 Mar 2002 23:31:44 EST

VBDis <vbdis@aol.com> wrote:
[...]
: C++ or C# are far away from C and processors, and establish their own
: model of execution on the target machine.


When I read the underlying models of execution (virtual machines) in
the C and the C++ standards they seem remarkably similar.


: Better use C or any other HLL instead, which better suits your
: expectations on OO programming.


Huh?


[...]
: C was designed for a specific set of
: processors, existing at that time (many decades ago), not at all for
: processors in general.


Which features of C do you see as being specific to those processors
of yesteryear, and "not at all for processors in general"? AFIK, the
C standards committee has gone to great lengths to avoid making
assumptions that would require less-than-optimal code on modern
architectures. For instance, one is not allowed to read a dangling
pointer because certain implementations on certain architectures use
registers that trap when dangling pointers are read.


Tom Payne


Post a followup to this message

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