A89: Re: 'memory violation'

[Prev][Next][Index][Thread]

A89: Re: 'memory violation'


Scott Noveck writes:
 > 
 > >>LINE 1111 EMULATOR
 > >
 > >Does the 89 ROM have emulation detection software?
 > 
 > No.  According to Interrupts.txt (from the doors zip), it's unused by the
 > OS. I think I read somewhere else (possibly in something by Jimmy Mardell?)
 > that the Line 1010 and 1111 Emulator stuff refers to some stuff used when
 > there's a coprocessor present. . . it has nothing to do with actual
 > emulation.

If you have a coprocessor in your system (68020 and up) the
coprocessor's instructions became part of the insns of the CPU. That
is, you can write things like this:

   move.d   <operand1>,fp0
   add.d    <operand2>,fp0
   sqrt     fp0
   
which adds <operand1> and <operand2> as IEEE double-precision float
numbers together in the math. coproc. register fp0 then gets the
square root of that number.

The way it works is that when the CPU decodes a coprocessor insn, it
tries to talk to the coprocessor, transparent to you. If it finds the
coproc, then massive communication starts between the CPU and the
coproc, again, invisible from a software point of view. It can go
parallel with the normal CPU operations: for example, in the previous
example, the math.co. starts calculating the squate root of fp0
(which is in the coproc) while the main CPU is free to do its integer
stuff. When you actually need the result (you want to refer to fp0)
the CPU and the math.co. will synchronise (i.e. the CPU will wait if
the coproc is not finished the sqrt() yet). There all sorts of other
things involved, especially for precise error management (think about
it: the coproc signals a divide by zero error but your integer code is 
already several insns beyond the insn which actually caused the error
- you are in an inconsistent state which is quite messy to clean up).

All coprocessor instruction words start with the bit pattern 1111 or
1010 (also called line-F and line-A insns). The CPU does not
understand them, it just realises that they are coprocessor
instructions and using one more field from them, it decides which 
coproc to talk to. (Youy can have up to 8 coprocessors beside the CPU).

Now the 1111 emulation and the 1010 emulation is for emulating the
coprocessor in software. When the CPU has to execute a coproc insn and 
realises that there is no coprocessor, it will do an exception (a SW
interrupt) so that the exception handler *can* emulate the
functionality of the coprocessor. If you have that emulation in place, 
you can write code using the coprocessor and if it is there, it will
be used. If you remove the coproc, then every coproc insn will turn
into an exception and in the exception (emulation) code the CPU will 
do whatever the coproc would do, albeit much slower.
Therefore, your software won't notice that there's no coprocessor, it
will run as normal, although much much more slowly.
One more possible use is if you have coproc but you run on something
smaller than the 68020. In that case you can't connect the coproc to
the CPU directly, but using the emulation mechanism, you can still
employ the coproc, with relative small SW overhead (let's not go into
details now, it would be far too long).

On the TI of course there's no coprocessor *and* there's no emulation
code either. Therefore, executing a coprocessor insn is a fatal error, 
(in all practical purposes, equivalent to an unimplemented insns) 
that's why you get the 1111 or 1010 emulation exception.

Getting the 1111 exception error usually indicates that your program
went beserk, it fetched an instruction from (that is, your PC points 
to) a place where there's no real code in memory or, more probably, an 
address which does not have memory at all (but is decoded, thus doesn't
signal a bus error). If noone drives the bus, it is usually pulled 
up by some resistors, hence you always read 0xffff from it - which,
as an insn, will cause the above exception.

Regards,

Zoltan
References: