Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site sdchema.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!decvax!ittvax!dcdwest!sdcsvax!sdchema!donn
From: donn@sdchema.UUCP
Newsgroups: net.lang.c
Subject: Re: structure and array and string comparisons
Message-ID: <1097@sdchema.UUCP>
Date: Mon, 26-Mar-84 02:43:49 EST
Article-I.D.: sdchema.1097
Posted: Mon Mar 26 02:43:49 1984
Date-Received: Tue, 27-Mar-84 01:27:21 EST
References: <266@opus.UUCP> <2831@brl-vgr.ARPA> <392@hocda.UUCP> <100@down.UUCP> <1056@druxy.UUCP> <365@denelcor.UUCP>
Organization: Used Softwear Jobbers, Inc. (Clandestine Computer Services)
Lines: 61

This debate is over the wrong issues.

What I hear some people saying is, 'Wow!  My machine has a whiz-bang
block compare instruction!  If only my compiler could generate it, my
code would be SO much faster!'  People on the one side of the fence
seem to think that the only way to get this into the compiler is to
make a built-in language construct like structure comparison, while
people on the other side are willing to live with a function call if it
means keeping the syntax of C safe from questionable additions.

How about meeting halfway?  The Berkeley folks often use a
post-processing 'sed' script which takes nasty things like splx() and
ntohl() and produces in-line code.  While I'm sure we all groan at the
grossness of this kind of intervention, why not take the grossness away
and let the compiler have access to a 'library' of in-line assembly
language functions?

A macro-like syntax for these functions could be developed so that
there would be a standard way of adding to the library when desired.
No C compiler would be required to implement the functions in-line;
thus no C syntax or semantics would change.  Any compiler that didn't
implement in-line functions would simply cause programs to use the
standard C library.

Thus we might see pseudo-C definitions like:

/*
 * strlen( s ) -- Return length of s.  VAX inline code.
 */
inline int strlen( s ) {
	register r

	movl	s,r
	locc	$0,$0x7fffffff,(r)	/* Search for null char in s */
	subl2	r,r0			/* Subtract s from addr of end of s */
}

(The intent of the 'register' declaration would be to ask the compiler
to make a register available, by using one that is free or by saving
one on the stack and restoring it later.)

This would make string manipulating 'functions' just as fast as the
proposed string operators, but the idea is more general and C's syntax
doesn't suffer.  Structure comparisons would be done quickly by a
simple bcmp(), which might cause an in-line 'cmpc3' instruction to be
emitted on a VAX or a subroutine call on a PDP11.  (Or a tight loop --
the arrangement is flexible enough that anything you could code
yourself in assembler, you could make available to the compiler to
improve your C code.)  No smarts are needed in the compiler to spot
loops that could be compiled into exotic instructions.

I was hoping to hear that this sort of thing was possible with PCC 2
when I went to Steve (?) Johnson's talk at Uniforum, since there was
something in the abstract that looked like it might be it.  Nothing
came up in the talk and things were too busy afterwards for me to get
to buttonhole him in the hall.  Is anyone out there familiar enough
with PCC 2 to say whether in-line assembler functions are present?

Too much wishful thinking,

Donn Seeley    UCSD Chemistry Dept.       ucbvax!sdcsvax!sdchema!donn