ADC Home > Reference Library > Technical Q&As > Legacy Documents > Hardware & Drivers >
Important: This document is part of the Legacy section of the ADC Reference Library. This information should not be used for new development.
Current information on this Reference Library topic can be found here:
Q: I'd like to port some of my
A: In general, we advise against writing PowerPC-native device driver code, with the current emulated Device Manager architecture. Each driver call incurs a Mixed Mode context switch (75-125 microseconds) just to enter the code. The same reasoning applies to interrupt routines.
Depending on how much your driver routines do, it may even happen that the driver with the native code runs slower than the original emulated code. These routines would have to be loaded and called using the Code Fragment Manager and Mixed Mode.
There are a few things that low-level device driver programmers should know:
The 68K instructions that produce indivisible read-modify-write bus cycles do
not produce indivisible bus cycles on the PowerPC. This is because there is no
read-modify-write cycle in the PowerPC ARBus architecture. If you're using TAS
or CAS to do semaphore operations, you should look into software semaphore
solutions. They can also use the PowerPC instructions
Another problem you may run into is bus reordering. The 601 can choose to
reorder bus operations to be more efficient. This means a load from a specific
address followed by a store to a second location could happen in reverse order.
Accesses to the same location are always serialized and will occur in
instruction order. Where this becomes a problem is working with config
registers on hardware devices. Say you have a control register and a data
register on a NuBus(TM) card. Normally, you would write a value to the control
register; this value would then produce a result in the data register which you
would then read with the next instruction. If the 601 reorders the bus
transactions, the read will occur first and you will be provided with bad data.
To prevent this problem, you need to execute a PowerPC
Another change that may affect NuBus developers is Bart. Bart is the code name for the NuBus controller on the 601 systems. Bart has very similar features to MUNI (the controller in the 840av and 660av). One new feature is "dump and run." This means Bart will absorb a ARBus burst write, release the ARBus and then transfer the data to NuBus with a burst or locked multi-beat write. This increases the overall throughput to NuBus and also frees the ARBus for other processing. NuBus and the ARBus therefore work asynchronously with Bart.