Xref: utzoo comp.os.msdos.programmer:740 comp.sys.ibm.pc.misc:1362 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!orion.oac.uci.edu!ucivax!ucla-cs!valeria.cs.ucla.edu!wales From: wales@valeria.cs.ucla.edu (Rich Wales) Newsgroups: comp.os.msdos.programmer,comp.sys.ibm.pc.misc Subject: Re: TASM bug? (no, not at all) Message-ID: <38580@shemp.CS.UCLA.EDU> Date: 4 Sep 90 05:10:49 GMT References: <4691@bdt.UUCP> Sender: news@CS.UCLA.EDU Reply-To: wales@CS.UCLA.EDU (Rich Wales) Distribution: na Organization: UCLA CS Department, Los Angeles Lines: 45 In article <4691@bdt.UUCP> doug@bdt.UUCP (Doug Asherman) reports a prob- lem when he moves a value from the DL register into a byte in memory, and then later moves this value into AX by casting the address of the variable into a "word ptr". He expected the value in AX to be converted automatically from a byte to a word; was chagrined that this didn't hap- pen; and wonders where he has encountered a bug in Borland's TASM. Doug, you seem to be expecting the assembler to do something at a level above what an assembler is designed to do. You cannot "cast" your variable "__key__" from a byte to a word by pre- fixing it with "word ptr" in your assembly program. All this does is force the assembler (against its better judgment) to generate a word MOV instruction with the address of "__key__" as one of its operands. It does =not= have =any= effect on the data stored in the location named "__key__", nor in the following location. If you want the byte value in "__key__" to be sign- or zero-extended in the AX register, you must specify this via explicit assembler code. No assembler will do this for you; nor, indeed, would you want it to do so -- since, for all the assembler knows, maybe you really do want to load both "__key__" and the variable in the following byte into AX via a single, word-sized MOV instruction. Your "workaround" using a CBW instruction -- mov al,__key__ cbw ; sign-extend __key__ -- is actually not a workaround at all, but is a quite reasonable and efficient way of doing what you want (given, of course, that the "sec- onds" value will be at most 59, and will thus never have a 1 in its high-order bit position). Alternatives to CBW (in case "__key__" could be in the range 128-255 and needed to be treated as unsigned) would be to do XOR AH,AH either before or after loading AL -- or else to do XOR AX,AX before loading AL. This would take one more byte of code, and one more processing cycle, than a CBW; the difference probably isn't important unless the code in question is in the middle of a tight loop. -- -- Rich Wales // UCLA Computer Science Department 3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (213) 825-5683 "You must not drink the tea. It is deadly to humans."