Jim Leonard wrote: That's an easy one ... IBM insisted on two sources for the 8088. AMD made an 8088 clone under license from Intel, and was the second supplier used by IBM. Unlike the V20, it was an exact duplicate. Mike www.brutman.com/PCjr

Jim Leonard wrote: ... Of course you meant "SP" not "SS" in second of each of the MOV pairs above. I recall reading a book back in 1982 or so written by Stephen Morse, one of the architects on the 8086. The book was 8086 Primer, I think. Anyway, he explains the addressing modes and instructions and such, but along the way drops a few nuggets like the one you mentioned above. He also mentioned that the architects called the sign extend instruction SEX, but management wouldn't have it. Motorola apparently was less stodgy. After some digging, I have found the book (it isn't the same copy I read in 82; a few years ago I happened upon a copy for $1 and snagged it). On page 89 he says: An 8086 Mistake (... describes what Jim Leonard discusses ...) This mistake was not discovered until after the 8086 was designed and built. After the mistake was discovered, the 8086 was modified so that it will not accept any interrupts immediately after executing an instruction that moves a new value into SS. On page 94 there is a section called "A Postscript on Prefixes" where he describes some of the prefix byte quirks. After mentioning some, he says: "The combination of a prefix with a repeat prefix will make it impossible to restart the string operation after being interrupted. To understand why .... This is a flaw in the 8086 design! On page 54 he says: "The 8086 provides instructions (Fig. 3.29) to facilitate the task of sign extension. These instructions were initially named SEX (Sign EXtend) but were later renamed to the more conservative CBW (Convert Byte to Word) and CWD (Convert Word to Double word). ... On pages 97-98 he is discussing flags and DAA. He mentions that the only flag that really needs to be changed on a DAA is the carry flag, but to increase compatibility with 8080 code, they set all five flags like the 8080. DAS does as well. Then he says how boolean operations affect flags. Then "One Boolean instruction, NOT, is missing from the list of Boolean instructions that affect the flags. NOT does not afect the flags. This was the result of an oversight (I goofed!) when the processor was being defined." There might be some other tidbits in there, but I don't particularly want to read it to find them.

This story told us, that CPU's have bugs. x86 bugs are known because x86's are widely used, and many are fixed. Your favorite CPU, 16032, 32016, z8000, 65816...... might have bugs that you don't know. That's why my favorite CPU is x86 (besides VAX) vax, 9000

Chuck Guzis wrote: No, but I can't download it from there. ... Good retrocomputing has it ... Arg!!! unix only!

J.C. Wren wrote: It gets me confused before it returns. I think I've seen the same code in the 386 book I have. If it is the program segment I am thinking of that is a cute trick if it returns AL as a ascii character.

I thought I saw all the postings in this thread, but I missed where you posted that, Chuck. Sorry. The advantage of the method, and yours below, is that they're deterministic. Another is that it's position independent. Now, admittedly, in 25+ years of writing software, I've only had one occasion where I needed it to be deterministic, and it was on a 8051 (same method works on any processor with DAA). I've never had to worry about it having to be PIC. I like using the DAA method for testing job candidates. It's not a pass/fail sort of thing, but if they can get reasonably close to figuring out what it's doing, they've earned points. I usually throw in some other little questions like "What is Duffs Device" and a few others, just to see how in-depth they are (I've never seen Duffs used in real-world code, but it's useful trick to be aware of, and indicates a good understanding of the way C can be twisted). --jc Chuck Guzis wrote:

J.C. Wren wrote: Chuck Guzis already posted that one yesterday towards the start of this (sub)thread: Miraculously I've been able to avoid learning the x86 instruction set, but that is probably 8 bytes (the same sequence would be on an 8080 or z80). But you can do z80 code like: add a,'0' cpi '9' + 1 jr n,foo add a,'a'-'0' foo: which is also 8 bytes. yeah, there is a branch in it, and it doesn't have the coolness associated with the tricky way, but it is clearer, probably runs at about the same speed. So you can't really justify DAA using this example. DAA was for doing BCD math; and that is the start and end of the justification. I know that the TI CC-40 and TI-74 calculators (and I'm sure there are others) used base 100 arithmetic -- two digits per byte like bcd, but in some ways more straightforward. When they normalized their mantissa there was two digit granularity. One thing a bit puzzling is rather than using the msb of one of the mantissa bytes to indicate the sign (since a byte holds on only 0-99, the msb is free), instead they indicate such by 1's complementing the first mantissa byte. I'm sure there is a reason why for their given instruction set this is superior (test msb and clear it before preforming mantissa operation would seem simpler than test msb and conditionally complement, but whatever).

or: AND AL, 0Fh DAA ADD AL, 0F0h ADC AL, 40h or: AND AL, 0Fh ADD AL, 0 ADC AL,28h DAA and, of course, it can be extended to 16 bits with screen display by: MOV CX, 0404h ; CH and CL are independent N1: ROL AX, CL PUSH AX AND AL, 0Fh DAA ADD AL, 0F0h ADC AL, 40h MOV AH, 0Eh ;displays char in AL at cursor position INT 10h POP AX DEC CH JNZ N1 -- Grumpy Ol' Fred cisin at xenosoft.com

On Sat, 10 Dec 2005, J.C. Wren wrote: Sorry, don't remember. These all work with 80x86

On 12/10/2005 at 12:09 PM Chuck Guzis wrote: What? No takers? I'll post my solution tomorrow if no one beats me to it. Uses only AL (or A) register, no jumps, no tables and will work on x80 and x86. Cheers, Chuck

On 12/10/2005 at 11:10 PM Dave Dunfield wrote: Good job! That's pretty much the idea, my solution uses addition (here's the 8086 version) and one fewer instruction (you could o the same by changing the value on that "SBI 0): AND AL,0FH ADD AL,0F6H ADC AL,0AH ADD AL,0F6H ADC AL,0AH ADD AL,0F6H ADC AL,0AH ADD AL,0F6H ADC AL,0AH ADD AL,0F6H ADC AL,0AH ADD AL,0F6H ADC AL,0AH ADD AL,0F6H ADC AL,3AH Next bit twiddler challenge--can anyone do this in fewer instructions? Cheers, Chuck

After looking at what I posted in my previous response, I realized that I could do the adjustments in single instructions by alternating ACI and SBI instructions - took a little bit of head scratching to work through the carries and come up with the right numbers, however this little sequence will do it in only 8 instructions (plus the ANI 15 which isn't really part of the algorithm if you need it): ANI $0F ADI $F6 ACI $0A SBI $09 SBI $F5 ACI $F6 ACI $0A SBI $09 SBI $C5 I don't think you can get any fewer instructions using this algorithm, because you need to adjust the alphanumerics by an offset of 7, and you need one extra instruction to set the inital carry flag boundary, which makes 8 in total. There will be an equivalent sequence beginning with a SUI 10 and reversing the operations all the way down. Regards, Dave -- dave04a (at) Dave Dunfield dunfield (dot) Firmware development services & tools: www.dunfield.com com Collector of vintage computing equipment: http://www.parse.com/~ddunfield/museum/index.html

Chuck Guzis wrote: Anyone who wants to implement the nybble-to-hex functionality in a lot shorter space, maybe? :-) This: AND AL,0FH ADD AL,0F6H ADC AL,0AH ADD AL,0F6H ADC AL,0AH ADD AL,0F6H ADC AL,0AH ADD AL,0F6H ADC AL,0AH ADD AL,0F6H ADC AL,0AH ADD AL,0F6H ADC AL,0AH ADD AL,0F6H ADC AL,3AH ...is 30 bytes (accumulator forms included). This: mov bx,offset hextable and al,0fh xlat bx hextable: db '0123456789ABCDEF' ...is a total of 22 bytes including the hex table. (I love xlat.) But our DAA solution: and al,15 add al,90h daa adc al,40h daa ...is only 8 bytes. If DAA were slow, I'd say ditch it. But DAA is only 4 cycles and according to my real-world 8088 timings (slow night tonight), the DAA approach is only just a hair slower than the XLAT method. So I guess there *is* a need for DAA ;-) -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Want to help an ambitious games project? http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/

On 12/11/2005 at 1:41 AM Jim Leonard wrote: Mind you, I'm not even a fan of XLAT, as a simple indexed load is probably faster on the Pentium-class machines. I prefer something a bit more orthogonal in its use of registers. I'm going to make a leap here and suppose that the original intention of the DAA was to enable addition in packed BCD arithmetic. That it can be used in a hoary old "neat trick" to convert a nibble to an ASCII representation is a red herring. That being the case, does it really have a place in an architecture where it's faster to do 32-bit BCD addition in, say, XS3? (Assuming that is, that anyone really has a need for it on a Pentium-class machine). Or is DAA simply the feed bag that's been left for "compatibility" purposes on a turbocharged V12 road machine just in case someone wants to hook old Dobbin up? Cheers, Chuck

Jim Leonard wrote: I thought XLAT was a real hack!

On 12/11/2005 at 3:28 PM Jim Leonard wrote: And Jim Leonard replied: Often, when we're given an instruction or any other resource, we attempt to incorporate it into a solution automatically. Thus, if I'm doing BCD addition, my thought is that DAA must be part of the answer, since it's in the instruction set and it MUST be there for just such a purpose. It's also true that we use what we're used to. I cannot claim to have ever used a CMPXCHG instruction, although it seems as if it might have some real use--it just never entered my mind to use it. Cheers, Chuck

Fred Cisin wrote: Both are the same speed and size, and quick timing shows that they are now the same speed as the XLAT method. (I assume that's what you were asking) -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Want to help an ambitious games project? http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/

On Sun, 11 Dec 2005, Dave Dunfield wrote: These are 9 instructions taking 18 bytes. How about this: SET R1,#$F0 LBI R2,#$F9 SLE R1,R2 SUB R1,#$39 Four instructions, eight bytes, EBCDIC character as output! Now guess what machine this is for. Hint: the machine has no flags and no stack. Christian

Chuck Guzis wrote: ; convert a nibble in A to an ascii hex character using only ; a single register, no DAA, no branches, ; and no tables. ; ; the crux of it is to drive a wedge between the values 0-9 ; and A-F. this is done by adding the right amount to always ; generate a carry for the higher group of numbers, then do ; an "adi 0" to increment only the higher numbers. ; ; we need to wedge them apart 7 times to account for the ; ascii difference between '9'+1 (0x3A) and 'A' (0x41). ani 15 ; isolate lowest nibble ; wedge step 1 adi 246 ; 0-9 are 246-255 with cy=0 ; A-F are 0-5 with cy=1 adc 0 ; A-F are now 1-6 ; wedge step 2 sui 246 ; 0-9 are 0-9 again with cy=0 ; A-F are now 11-16 with cy=1 adc 0 ; 0-9 are 0-9; A-F are now 12-17 ; wedge step 3 adi 246 adc 0 ; wedge step 4 sui 246 adc 0 ; wedge step 5 adi 246 adc 0 ; wedge step 6 sui 246 adc 0 ; wedge step 7 adi 246 adc 0 ; convert to ascii adi '0'-246

I've heard a similar story about DEC -- the engineers wanted to call the sign extend instruction on the PDP11 SEX, the management objected and insisted it was called SXT The engineers got their own back when the VAX was released. The register that holds the address used in a transfer on the Unibus that times out is called the Failed UniBus Address Register (FUBAR). And that one did get into manuals, printests, etc. -tony