davet@oakhill.UUCP (Dave Trissel) (05/11/85)
OK all you 68K gurus out there let's have your opinion on this architectural
change to the family.
Some of us have been considering allowing writes to PC space. The MOVE
instruction with the destination ea of any PC usage is now illegal. This .
means we could easily allow all of the PC modes here. I haven't checked on
the other instructions yet.
So far I have come up with the following conclusions on the matter:
1) MMU systems may have compatibility problems since they may be unprepared
to handle an error on a write to code space. Of course, if they always
set MMU control bits such that code space writes were invalid anyway
they wouldn't notice any difference. Non-MMU systems don't depend on
any protection but they may get tripped up in the bus error
handler if they make the no-write assumption there (such as assuming
a write error must be data space.)
2) High-Level Languages will not be affected in the least nor will there be
any need for them to utilize the newly available modes. This is because
they divide the code and data into two different sections anyway and so
never have a need to perform writes to the code area to begin with.
This leaves the real use in the ballpark of assembler programmers.
3) Many, indeed most, 68K systems do not make a distinction between code
and data space function codes even if an MMU is utilized. (As an example
the following code will work on these systems:
LEA THIS,An Point to code space item
CLR (an) Clear word there
since the address map is not split between code and data.) Or better said
they doubly map the code space into both code and data space function
codes. This would indicate the additional modes would be allowing
functionality already allowed in most systems anyway.
This is all I've come up with so far. Any comments on these or ideas of
your own will be appreciated. Since I presume everyone on this newsgroup
would be interested go ahead and post them here. We especially want to hear
from anyone thinking that this may be a bad idea.
Motorola Semiconductor Dave Trissel
Austin, Texas {ihnp4,seismo,gatech}!ut-sally!oakhill!davetjack@boring.UUCP (05/13/85)
I think allowing PC-mode writes shouldn't be a problem for many
people, although there are undoubtedly *some* people who
used the function codes for some unimaginable weird purpose who
will be angry.
What I wonder is: where would you use it for?
You don't want to facilitate code like
INC.L #0
BEQ ...
I hope :~{ ??
--
Jack Jansen, jack@mcvax.UUCP
The shell is my oyster.edler@cmcl2.UUCP (Jan Edler) (05/15/85)
The pdp11 allows destination operands to use pc-relative addressing. If you want position independent code, that's a good way to do it. It isn't too useful with split I/D space, though. How many 68000-based systems out there actually use split I/D? It certainly seems less necessary than it is for the pdp11! Whether or not it would be wise to make the change in a future 68000 family member is debatable. I suspect certain applications or environments would find it valuable, but most UNIX systems wouldn't use it. Currently, if you need pic, I guess you have to give up an address register. The other problem with pic on the 68000 is the lack of support for 32bit displacements, but I guess that's solved by the 68020. Jan Edler New York University ihnp4!cmcl2!edler edler@nyu.arpa
mark@rtech.UUCP (Mark Wittenberg) (05/23/85)
> What I wonder is: where would you use it for? > You don't want to facilitate code like > INC.L #0 > BEQ ... > I hope :~{ ?? > > -- > Jack Jansen, jack@mcvax.UUCP > The shell is my oyster. Did you ever read UNIX V6 startup assembler? It included inc #-1 bne ... (well, maybe it was #0, or beq, but you get the idea). It startled me when I first saw it. -- Mark Wittenberg Relational Technology zehntel!rtech!mark ucbvax!mtxinu!rtech!mark
jv@tut.UUCP (Jukka Vanhala) (05/29/85)
In article <boring.6412> jack@boring.UUCP (Jack Jansen) writes: > >... although there are undoubtedly *some* people who >used the function codes for some unimaginable weird purpose who >will be angry. >What I wonder is: where would you use it for? > I'm working on a 68k do-it-yourself-PC and the reasoning behind using function codes is simply: - restart vector resides in supervisor code space => it must be burned on PROM (with a very simple monitor program) - other exception vectors reside in supervisor data space and they must be writable (because I'm going to load the operating system from host) => they must be on RAM => so, at least supervisor spaces must be separated Nothing prevents from mapping supervisor data space and both user spaces onto physically same memory. Anyway, I have a 68k chip already, so you can make whatever changes you like :-O jv (Jukka Vanhala) Tampere University of Technology Computer Science Laboratory P.O. BOX 527 Tampere, FINLAND