Technical Q&A DV01

Device Manager

Q: I'd like to port some of my 'DRVR' code to the PowerPC, but I'm worried about the 68K-specific design of the Device Manager. What should I do?

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 lwarx (Load Word and Reserve Indexed) and stwcx. (Store Word Conditional Indexed). These instructions can be used to provide a base for building semaphores. Keep in mind that the memory location locked must be in main memory on the PowerPC computer.

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 eieio (Enforce In-Order Execution of I/O) instruction between the write and read. The emulator will execute an eieio when a 68K NOP is dispatched. So you should insert NOP or eieio instructions between any order critical reads and writes.

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.