Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site oakhill.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!ut-sally!oakhill!davet
From: davet@oakhill.UUCP (Dave Trissel)
Newsgroups: net.micro.68k
Subject: More on PC relative destinations and a new one on EA orthogonality
Message-ID: <419@oakhill.UUCP>
Date: Mon, 13-May-85 17:31:32 EDT
Article-I.D.: oakhill.419
Posted: Mon May 13 17:31:32 1985
Date-Received: Thu, 16-May-85 02:29:21 EDT
Organization: Motorola Inc. Austin, Tx
Lines: 43


More Thoughts on PC relative destination.  Plus a question on total addressing
mode orthogonality.

A) Since allowing writes to code space would allow overwriting instructions
   which may be in an instruction cache or worse (the instruction pipe) it
   is obvious that altering instruction streams in this manner should be
   disallowed.  (Which is indeed why it was on the original architecture.)

   That brings up the point that we could treat PC based writes as always
   going to data space instead of code space.  This would allow for total
   O.S. compatibility, since as I mentioned before what is NOT expected
   by current operating systems is a write to code space.

   This would, however, create a minor dichotomy in that instructions will
   use different function codes for PC relative modes depending on whether
   a source or destination is involved.

   One solution is to have an option where all operand PC based reads as well
   as the new PC based writes appear only in data space.  This has the added
   advantage of allowing for something not currently allowed in the
   architecture - complete code protection where a user program could execute
   code but be prohibited from examining it in any way.  We have had a few
   request for this feature (but not many.)  And since, as I pointed out
   before, most systems "fold" the code and data spac together anyway this
   would only impact those few systems that specifically don't and base
   O.S. algorithms on that fact.

   Comments?

B) We have tossed about some ideas for including total orthogonality for most
   of the instructions.  Assuming that its workable, we have another problem
   in that looking at over 7,000 instructions generated by
   Pascal and C compilers on the NS32032 we have found very little use
   of any memory to memory operations not already available on the M68000
   family. In fact, the National code (with half the registers of the M68000)
   only uses them about 2 percent of the time. This discourages us from even
   considering such an addition.

   Comments?

Motorola Semiconductor Inc.                Dave Trissel
Austin, Texas                {seismo,gatech,ihnp4}!ut-sally!oakhill!davet