Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!pyramid!voder!mas1!jda
From: jda@mas1.UUCP (James Allen)
Newsgroups: comp.lang.c
Subject: Re: C vs assembler, or, Here We Go Again
Message-ID: <165@mas1.UUCP>
Date: Fri, 1-May-87 15:02:49 EDT
Article-I.D.: mas1.165
Posted: Fri May  1 15:02:49 1987
Date-Received: Sun, 3-May-87 01:17:55 EDT
References: <213@pyuxe.UUCP> <636@edge.UUCP> <1316@frog.UUCP> <658@edge.UUCP> <6361@mimsy.UUCP>
Organization: Measurex Automation Systems, Cupertino, CA
Lines: 37
Summary: Two More Cents

My $0.02 for the Assembly vs C discussion--

First penny)
	Some control flow techniques -- in particular coroutine
linkage -- are inconvenient in C but achieved elegantly in assembly.
(see JSR_return_address_in_register discussion in another
newsgroup.) To avoid a proliferation of global variables
and/or "gotos" I have seen multitasking:

	pipe (questions), pipe (answers);
	if (fork ())
		get_questions ();
	else
		get_answers ();

used where an assembly language programmer would have invented
coroutines even if he'd never heard of them.  Admittedly
the multitasking design may be more readable; the point is
that the assembly-level option is not readily available in C.
(Ada is better here, although facilities like longjmp extend the
range of control flow techniques of C.)

Second Penny)
	I recently implemented a 68000 OS in C.  The amount of assembly
coding was insignificant.  One interesting anecdote:

	#define	DSK_SEL	*(char *)0xf12345  /* WRITE but dont READ */
		DSK_SEL = 0;

caused a parity error and had to be replaced with
		temp = 0; DSK_SEL = temp;

The code generated was CLR.B and MOV.B respectively.  Can anyone
elucidate?  Notice that here the assembly language programmer might
well have fallen into the same trap as the C compiler.

James D. Allen