steve@drivax.UUCP (Steve Williams) (05/17/85)
> > 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? You are in the process of fixing what has always been my biggest gripe about the 68K. Thank you. I have a few points to make: 1. Existing programs on low-end systems do, in fact, write to code space. Look at the sample Macintosh assembly language programs sometime. You'll see sequences of: LEA Label,Ax ; PC-Relative MOVE.x Stuff,(Ax) ; <-- Offensive instruction This effectively prohibits Apple from using the FC0-2 bits to separate code and data memory. On our low-end 68K systems (CP/M and AtariDos), overlays are done by the program itself, another instance of modifying code space. Debuggers also do this when installing breakpoints. High end hardware which runs these applications must not use separate I & D. 2. The principle use for this feature in our view of the world is to write position-independent code for shared runtime libraries. (Makes it easy for the O/S to map the runtime into the user program if it can do so at any point in the user's logical address space). You must have a fixed address for the library jump table, of course. > 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 I found the lack of a generalized compare instruction to be a nuisance. But in general, I agree. You didn't mention how much instruction overhead (in bytes) will be incurred by this extra feature. Assuming it's as large as the 32-bit PC-relative stuff on the 020, you'll find compiler writers scrambling to avoid it. While we're on the topic of architectural changes, I have a couple more: -On the 16-bit chips, how about guaranteeing one instruction to be executed following an interrupt? This would allow simulating the interrupt stack feature of the 020 in software (using the one instruction to disable interrupts). This allows the O/S writer to limit the amount of per-process stack in system state. -How about some hardware queueing / dequeueing instructions? (similar to INSQ/REMQ on the VAX, including support for shared memory). -How about hardware context switching support? But simple, please, no call gates, interrupt tasks, or TSS's. Just a memory area which contains the machine state and two instructions to load and store it. -On chip memory-to-memory DMA. We use message passing in some systems, and this would make a tremendous difference. Add a barrel shifter, and you could get real high-performance graphics (and GEM or the Mac-style user interfaces). Apologies for the verbosity. ------------------------------------------------------------------------------ -Steve Williams {mot,ihnp4,amdahl}!drivax!steve "Pay no attention to that man behind the curtain".
george@mnetor.UUCP (George Hart) (05/24/85)
In <143@drivax.UUCP>, Steve Williams writes... > ... > 2. The principle use for this feature in our view of the world is to write > position-independent code for shared runtime libraries. (Makes it easy > for the O/S to map the runtime into the user program if it can do so at > any point in the user's logical address space). You must have a > fixed address for the library jump table, of course. > ... > ... > > -How about hardware context switching support? But simple, please, no > call gates, interrupt tasks, or TSS's. Just a memory area which > contains the machine state and two instructions to load and store it. > > -On chip memory-to-memory DMA. We use message passing in some systems, > and this would make a tremendous difference. Add a barrel shifter, > and you could get real high-performance graphics (and GEM or the > Mac-style user interfaces). > Good ideas...now add on chip floating point support and you would have *some* chip! Which brings me to another point: why hasn't float support become a standard feature of today's chips? -- Regards, George Hart, Computer X Canada Ltd. {cbosgd, decvax, harpo, ihnp4}!utcs!mnetor!george