doug@cornell.UUCP (Douglas Campbell) (12/03/84)
Thanks to all who responded to my concerns about Intel's new 286 microprocessor. This is what makes the net so useful - you're never sure if you are missing something fundamental unless you can get lots of other people's input. In response to the question most asked: I have to use the 286 for economic reasons (writing commercial IBM-compatible software). To recap, I sent out an article which pointed out some major problems with the 286 viewed as a 32 bit address virtual memory machine. I asked whether my concerns were valid, and whether there were solutions. I have seen 9 responses to my original article, via mail and news. Seven of the responses confirmed my findings and blasted the 286. One response (from someone at Intel) supported the 286, but it was apparent that he didn't understand the issues. The other response made a useful comment about microprocessor performance and success in general. The agreement seems to be that yes, the 286 segmentation scheme does make large address spaces very ugly and slow, but there are at least fairly reasonable ways to do it. Compilers can remove most of the performance penalties introduced by segmentation. Code can be divided into <64K segments that explicitly call each other, incurring no real penalty. Data <64K is no problem. Generating a true 32-bit address is only necessary for structures >64K. Here, I believe that the segment part of a 32-bit address can be tested for equality with the current segment register so that the segment register is reloaded only when necessary. This does require some test, shift, and mask instructions because of the non-conforming low-order bits in the segment register, but the penalty for this is probably less than that for reloading the entire segment descriptor. Thus, with any good locality of reference properties, using the 286 as a 32-bit virtual address space might not be so bad after all. This conclusion is an example of the commentary article's point. In his words, > Good tight assembly code can make an average microprocessor a > huge success and poor code can ruin the performance of a good one. If we assume the 286 is `average' then we can put this to the test. I suspect that the 286 used in the way described above could be the heart of a reasonably impressive *nix machine. Done carelessly, however... I certainly hope Microsoft is listening. Doug Campbell doug@cornell.{UUCP|ARPA}