"CP/M compatible" vs. "MS-DOS Compatible" machines?

[Holger Veit]

Chuck Guzis schrieb:
>> Date: Tue, 05 Feb 2008 20:25:07 -0500
>> From: Allison 
>>     
>
>   
>> Maufacturing no. Design yes. back then there was little if any automated
>> chip design so anything to save time or transistors on the die was good.
>> The redundant moves are simple example of not decoding all possible
>> states. Saves transistors at a time when getting things on that much
>> silicon was still hard.
>>     
>
> My point was "documentation" of these instructions as such was 
> unnecessary.  Had the documentation simply said "---", they wouldn't 
> have been used, freeing the codes for later exploitation.  But once 
> documented as valid moves, there's no going back.  
>
> 00H was the only *documented* no-op as such.
It does not help not to document those instrs in the hope that they can 
later be reused when more transistors become available. Those 
"undocumented instructions" *were* used  in  any software product where 
the  programmers  became aware of ., and be it only for the reason to 
make it harder to understand the code by competitors (thus have 
disassemblers stumble on them). Typical example were the Z80 "mov 
xx,reg" instructions where xx is IXL,IXH,IYL,IYH which are side effects 
of adding a DD/FD prefix to "mov L,reg" or "mov H,reg" which were, from 
my own disassembly activities frequently used in Z80 CP/M code. 
Admittedly, the inplace moves like "mov B,B" are often only useful for 
alternative NOPs, but I remember having seen also creative uses of such 
codes as part of some data structure which happened to have a suitable 
pattern to execute as some code - again to obscure the program logic to 
interested hackers. Typical was also to use a three byte instr like "lda 
xxyy" where xx,yy formed another instruction like a short jump which is 
executed on PC+1, but skipped on PC+0 (location of lda).

Almost every 8 bit CPU of that time had one or more "undocumented 
opcodes" resulting from don't cares in the instruction decoding logic.

-- 
Holger