Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lll-winken!uunet!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: SUN procedure inlining(was i860 Dhrystones)
Message-ID: <6519@cbmvax.UUCP>
Date: 6 Apr 89 00:13:46 GMT
References: <39388@oliveb.olivetti.com> <15475@winchester.mips.COM> <95013@sun.Eng.Sun.COM> <13641@jumbo.dec.com> <95215@sun.Eng.Sun.COM> <4614@pt.cs.cmu.edu> <1356@auspex.auspex.com> <4641@pt.cs.cmu.edu> <GRUNWALD.89Apr4185706@flute.cs.uiuc.edu>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Distribution: na
Organization: Commodore Technology, West Chester, PA
Lines: 17

In article <GRUNWALD.89Apr4185706@flute.cs.uiuc.edu> grunwald@flute.cs.uiuc.edu writes:
>
>The inlining done by the Greenhills compiler could be done by a
>peep-hole phase, but it's unlikely.  When you say
>
>		strcpy(foo, "this is a string")
>
>Greenhills turns this into a block move, because it already knows the
>length of the string. This beats the pants of a ``move-until-null-byte''
>loop.

	Only with the "dhrystone" switch enabled, and the code does NOT
work if the pointer "foo" is odd (on a 68000).  (This is when generating
code for a 68000 - on an '020, it would work, but slowly)

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup