Re: marking mystery code

Toon Moene <toon@moene.indiv.nluug.nl>
16 Feb 1996 23:47:35 -0500

          From comp.compilers

Related articles
Re: marking mystery code dewar@cs.nyu.edu (1996-02-13)
Re: marking mystery code dennison@escmail.orl.mmc.com (Ted Dennison) (1996-02-14)
Re: marking mystery code jmccarty@spdmail.spd.dsccc.com (1996-02-14)
Re: marking mystery code jgj@ssd.hcsc.com (1996-02-16)
Re: marking mystery code hagerman@ece.cmu.edu (1996-02-16)
Re: marking mystery code mnp@compass-da.com (Mitchell Perilstein) (1996-02-16)
Re: marking mystery code toon@moene.indiv.nluug.nl (Toon Moene) (1996-02-16)
Re: marking mystery code preston@tera.com (1996-02-17)
Re: marking mystery code rfg@monkeys.com (1996-02-19)
Re: marking mystery code kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) (1996-02-21)
Re: marking mystery code xanthian@qualcomm.com (1996-02-24)
| List of all articles for this month |
From: Toon Moene <toon@moene.indiv.nluug.nl>
Newsgroups: comp.compilers
Date: 16 Feb 1996 23:47:35 -0500
Organization: Compilers Central
Keywords: GCC



Robert Dewar wrote:
> In GNAT we use ??? for this purpose, and there are
> quite a few ??? around the place. I suspect that nearly
> all large projects have numerous instances of code
> which merits the ??? mark, but they don't get marked.


Ted Dennison wrote:
> When ever I come across such code, I figure out what it
> does and either comment it, or rewrite it more clearly
> (or remove it). Is this an uncommon practice?


Probably not, but it isn't of much use in the gcc backend (i.e. the
part that tries to transform the Register Transfer Language linked
lists of structures into actual machine code). The reason for this is
that this code has to work for a lot of architectures, and the
question marks (FIXME's) often refer to problems with a _specific_
machine type. As long as I don't have at least one of every species
of VAXen, various DSP's, all well-known RISC systems, x86 machines and
m68k's at home, I leave such code alone (of course, the really
challenging thing is to insert _new_ code that depends on
architectural features. The upcoming g77 front end will try to do
this, in order to remedy a case of extremely bad code generation for
adjustable arrays of rank >= 3).


Cheers,


--
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
URL: http://www.knmi.nl/hirlam
--


Post a followup to this message

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