davet@oakhill.UUCP (Dave Trissel) (05/14/85)
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!davetjack@boring.UUCP (05/15/85)
In article <419@oakhill.UUCP> davet@oakhill.UUCP (Dave Trissel) writes: > >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. > I think total orthogonality would be *very* useful. The fact that the 32K is totally orthogonal turned me from a Motoroladdict to a Nationalist (sad for you, but true). As a small example (much better ones can be found, no doubt), consider the definition extern int i; register int j; and the statements if( i < j ) foo; if( j < i ) bar; A 68K compiler has to think about modifying the branch condition, etc. A 32K compiler just generates code in the way it sees the statement. Of course, an optimizer might throw everything around again to save registers or whatever, but the inital code generation is much simpler in the 32K case. By the way, if you are going to include total orthogonality, how do you want to do it? I can't imagine any feasible way aside from totally changing object code format (oh nooooooo)... -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
henry@utzoo.UUCP (Henry Spencer) (05/16/85)
> ... 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. Think hard about compiler quality before drawing any major conclusions from such investigations. Exploiting memory-to-memory instructions, in any but the most trivial cases, takes extra work by the compiler writer. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry