Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rtech.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!tektronix!hplabs!amdahl!rtech!mark
From: mark@rtech.UUCP (Mark Wittenberg)
Newsgroups: net.micro.68k,net.arch
Subject: Re: FLAME!!! Re: EA orthogonality
Message-ID: <467@rtech.UUCP>
Date: Wed, 5-Jun-85 12:46:44 EDT
Article-I.D.: rtech.467
Posted: Wed Jun  5 12:46:44 1985
Date-Received: Sun, 9-Jun-85 01:58:03 EDT
References: <419@oakhill.UUCP> <6415@boring.UUCP> <557@terak.UUCP> <6417@boring.UUCP> <572@terak.UUCP> <6431@boring.UUCP>
Organization: Relational Technology, Alameda CA
Lines: 30
Xref: watmath net.micro.68k:887 net.arch:1344

> For example:
> 	a += b;
> orthogonal:
> 	add	b(r5),a(r5)
> non-orthogonal:
> 	mov	a(r5),r4		<-- AND MAKE SURE IT'S FREE!!
> 	add	b(r5),r3
> 	mov	r3,a(r5)
> Now, in cycles, the first one would result in 4 memory cylces and
> 3 additions, and the second in 6 memory cycles and 4 additions (PLUS
> an additional 2 instruction decodes).
> 
> -- 
> 	Jack Jansen, jack@mcvax.UUCP
> 	The shell is my oyster.

And furthermore, the orthogonal sequence is normally atomic;
in an OS kernel the non-orthogonal sequence might easily have to
be protected by a "disable/enable interrupt" sequence around it,
or "test-and-set" or some such in a multi-processor system 
(e.g., "a" and "b" might be global vars).
Multi-process user-programs would need "enter/exit monitor" or
"block-on-semaphore" sequences.  Besides being a pain (sometimes
a royal pain) this has the potential for eating a lot of CPU time.
-- 

Mark Wittenberg
Relational Technology
zehntel!rtech!mark
ucbvax!mtxinu!rtech!mark