Next Up Previous Contents Index
Next: Details--What about the Up: Before Autodesk Previous: Background--Why not the

Background--Why not the Z8001?

Since OS has converted most of our software to the Z8002, it would be far less painful to go to the Z8001 CPU. In addition, off the shelf Multibus systems exist with Z8001 CPU, memory management, and all the large memory and support boards at excellent prices. The basic problem with the Z8000 is that it is not a general large address space processor. The Z8000 addressing is split up into ``segments'' from 0 to 127, and ``displacements'' from 0 to 64K.[Footnote] You can address 8 megabytes by concatenating the segment and displacement into one address. Segmented mode programs can do this in both direct address pointers and in index register pairs. The problem comes in how indexing and autoincrementation is handled. When addresses are added in the processor, only the displacements are added, and the carry is discarded. Thus, if you are indexing through an array and cross a segment boundary, you wind up back at the start of the segment you were in, not at the next one.

As a result, you can simulate large addressing only by manually computing addresses in software, bypassing the index hardware. This is grossly inefficient. You can ignore the problem if the linker never places a module across a segment boundary and dynamic allocation never splits a buffer across segment boundaries. This doesn't help you if the user simply declares an array larger than 64K.

Further, it seems that most vendors who have looked at the Z8000 for our type of general purpose application have shied away from it and are now working with the 68000. We've had it with trying to push unpopular products.

Editor: John Walker