Re: Compiling to C (where C is used as misspelled assembly)

conway@mundook.cs.mu.OZ.AU (Thomas Charles CONWAY)
17 May 1997 00:05:21 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: Compiling to C (where C is used as misspelled assembly) fjh@mundook.cs.mu.OZ.AU (1997-05-16)
Re: Compiling to C (where C is used as misspelled assembly) chase@world.std.com (David Chase) (1997-05-16)
Re: Compiling to C (where C is used as misspelled assembly) darius@phidani.be (Darius Blasband) (1997-05-16)
Re: Compiling to C (where C is used as misspelled assembly) hbaker@netcom.com (1997-05-16)
Re: Compiling to C (where C is used as misspelled assembly) ramb@spring.epic.com (Ram Bhamidipaty) (1997-05-16)
Re: Compiling to C (where C is used as misspelled assembly) dwight@pentasoft.com (Dwight VandenBerghe) (1997-05-16)
Re: Compiling to C (where C is used as misspelled assembly) conway@mundook.cs.mu.OZ.AU (1997-05-17)
Re: Compiling to C (where C is used as misspelled assembly) fjh@mundook.cs.mu.OZ.AU (1997-05-17)
Re: Compiling to C (where C is used as misspelled assembly) monnier+/news/comp/compilers@tequila.cs.yale.edu (Stefan Monnier) (1997-05-17)
Re: Compiling to C (where C is used as misspelled assembly) cdg@nullstone.com (Christopher Glaeser) (1997-05-17)
Re: Compiling to C (where C is used as misspelled assembly) conway@mundook.cs.mu.OZ.AU (1997-05-22)
Re: Compiling to C (where C is used as misspelled assembly) conway@mundook.cs.mu.OZ.AU (1997-05-22)
Re: Compiling to C (where C is used as misspelled assembly) Dave@occl-cam.demon.co.uk (Dave Lloyd) (1997-05-22)
[3 later articles]
| List of all articles for this month |
From: conway@mundook.cs.mu.OZ.AU (Thomas Charles CONWAY)
Newsgroups: comp.compilers
Date: 17 May 1997 00:05:21 -0400
Organization: Comp Sci, University of Melbourne
References: 97-05-183
Keywords: C, assembler

Ray Dillinger <bear@sonic.net> writes:


>However, this will violate every "reasonable" assumption a maker of C
>compiers will have about programming style. It will mean a program is
>compiled into a *single routine* of C code, with Goto destinations
>that might be more than 64K bytes away -- and no templates, no library
>functions linked, no header files, etc etc....
>
>Will modern C systems handle this?
>[Probably not. Machine generated source code always seems to break
>compilers designed for code written by humans. -John]


The Melbourne University implementation of Mercury generates C code.


What we actually generate is C code that uses heaps of macros. We have
different definitions of these macros that allow us to make use of a
variety of different features of the underlying C compiler and OS. For
example, if we are using gcc, we make use of nonlocal- gotos and
machine registers.


In the worst case, we compile each basic block to a single function
which returns a continuation function pointer and use a driver-loop.
The resulting system is almost ANSI C - the only non-ansi assumption
is that there is an integer type and a pointer type between which we
can make lossless coersions (on most machines these are `int' and
`void *').


For more information, check out our website:
http://www.cs.mu.oz.au/mercury


Thomas
--
Thomas Conway conway@cs.mu.oz.au
--


Post a followup to this message

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