Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!ima!mirror!xanth!kent
From: kent@xanth.UUCP
Newsgroups: comp.arch
Subject: Re: String Processing Instruction
Message-ID: <771@xanth.UUCP>
Date: Wed, 1-Apr-87 03:14:58 EST
Article-I.D.: xanth.771
Posted: Wed Apr  1 03:14:58 1987
Date-Received: Fri, 3-Apr-87 06:48:16 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <909@spar.SPAR.SLB.COM>
Reply-To: kent@xanth.UUCP (Kent Paul Dolan)
Distribution: na
Organization: Old Dominion University, Norfolk Va.
Lines: 30
Keywords: programming costs byte software in word system
Summary: Your posting argues against your views

In article <15325@amdcad.UUCP> bcase@amdcad.UUCP (Brian Case) writes:
>Well, this is so damn long that I'll just post strcpy.

Brian,
	I almost choked when I saw your code, right after seeing the same job
	done in a handful of lines in a posting that hit here a few articles
	earlier.  You couldn't have written a more cogent argument for byte
	level addressing in any hardware which does text processing if it had
	been your intent.  Programmers are _the_most_expensive_part_ of the
	total lifecycle (including execution) costs of all but the most widely
	distributed, embedded code.  Who could afford to pay the staff to
	write code ten or fifteen times as long (I didn't count) to do the
	same job in a comparable time.  The discussion so far has brought out
	quite a lot of evidence that applications level programmers aren't
	using the library string routines much, yet Unix stream files, and
	the masses of editors, word processors, post processors compiler
	parsers and so on in use testify that the job is being done.  The
	implication is that the application programmers are writing the
	string software themselves, to suite the particular case at hand.
	I sure don't want to pay them to write code like that you showed,
	at the application level, to replace
	
		while (*s1++ = *s2++);
	
	Yeeks!
	
	You've talked _me_ into byte instructions and byte addressing.
	Comments?

Kent.							(kent@xanth.UUCP)