🚀 go-pugleaf

>"Several years ago I saw the 386 assembly language output generated by the
>Greenhills C compiler for Dhrystone.  They inlined all the string functions,
>and turned constant strings into fixed length copies (no NUL-character
>recognition).

>I wouldn't be surprised if you're seeing the same thing for the i860
>results."

>Now, according to the letter or the law of Herr Doktor Weicker's Dhrystone 2.1
>writeup, it's OK to in-line strcpy and strcmp.  Unfortunately, in this
>particular case, a set of conditions exists that is not particularly frequent:
>	a) The source of the strcpy is a constant string, so the compiler
>		knows how long it is.
>	b) The target of the strcpy is something whose alignment is known
>		at compile time, or even better, can be aligned as the
>		compiler chooses.  [i.e., NOT a pointer to some unknown place.]
>Given these conditions, you can easily turn the copy into a structure-assignment
>equivalent, that need not inspect any bytes at all.

>1) Does anybody KNOW if the Green Hills compilers do this, in general?
>(or specifically:
>	the 386?

I don't know about Green Hills. But, I use the MicroWay NDPC compiler
on my PC. A discussion with a programmer there about a problem
I had elicited a comment: (This is a paraphrase) 
    "Our front end is basically a 4.3 front end [whether clone or
purchased I didn't ask JDM]. The back end ....
The optimizer we bought. I can't tell you where we bought it, but
it is a company well known in the Unix C field. They seem to make a really
nice optimizer."


>2) Could you post the assembly code, if there is something like this?

Certainly - the .S file is full of things like (to copy 31 bytes 
including the trailing zero:)

        mov     ecx,7
	lea	esi,dword ptr ds:L98
	push	edi
	lea	edi,dword ptr [eax]+16
	rep	movsd
	movsw
	movsb
	pop	edi

For the 386 and one particular compiler (with the -OLM switch),
the smoking gun. 

Doug McDonald