doug@bdt.UUCP (Doug Asherman) (09/03/90)
I've run into something in TASM that may be a bug, but I'm not sure. The code in question looks somewhat like this (compressed for brevity's sake): cseg segment assume etc. etc. ; data __key__ db ? ; other data ; code ; get the time from dos ; move the seconds into key mov __key__,dl ; dl contains the seconds ;....stuff deleted ; ....then later on mov ax,word ptr __key__ ....I took this through the debugger a few times and ax always ended up as some weird number like 7f1b, or something equally strange. I was able to get around this by doing the following: mov al,__key__ cbw ; sign-extend __key__ Though I'm hardly an assembly language guru, it's always been my understanding that casting a byte variable to a word will sign- extend it automatically. I haven't had a chance to see if MASM behaves the same, so I can't say if MASM does the same thing. If this is a bug, though, Borland should probably know about it. -- .signature: permission denied
wales@valeria.cs.ucla.edu (Rich Wales) (09/04/90)
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 <wales@CS.UCLA.EDU> // 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."jwbirdsa@amc-gw.amc.com (James Birdsall) (09/05/90)
In article <38580@shemp.CS.UCLA.EDU> wales@CS.UCLA.EDU (Rich Wales) writes: >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[...] > [lots of good explanation deleted] > >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. There's also MOVZX, an obscure instruction that is available on all 80x86. It will extend a byte to a word, zeroing the high byte. I don't know how the execution time compares to an XOR/MOV pair, but I suspect it is faster. Unfortunately, the complementary instruction (MOVSX, move with sign extend) is only available on the 386. -- --- James W. Birdsall jwbirdsa@amc.com 71261.1731@compuserve.com Compu$erve: 71261,1731 GEnie: J.BIRDSALL2 For it is the doom of men that they forget. -- Merlin
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (09/05/90)
In article <2953@amc-gw.amc.com> jwbirdsa@europa.amc.com (James Birdsall) writes: > There's also MOVZX, an obscure instruction that is available on all 80x86. >It will extend a byte to a word, zeroing the high byte. I don't know how the >execution time compares to an XOR/MOV pair, but I suspect it is faster. > Unfortunately, the complementary instruction (MOVSX, move with sign >extend) is only available on the 386. MOVZX is only available in TASM in 386 mode, and doesn't seem to work on my 8086. Is there some special encoding that TASM doesn't know about to get it to work there, or do you mean all 80x86 except mine? Duncan Murdoch
toma@tekgvs.LABS.TEK.COM (Tom Almy) (09/05/90)
In article <2953@amc-gw.amc.com> jwbirdsa@europa.amc.com (James Birdsall) writes: > > In article <38580@shemp.CS.UCLA.EDU> wales@CS.UCLA.EDU (Rich Wales) writes: > >[Discusses using CBW or XOR to load 8 bit data into 16 bit registers] > There's also MOVZX, an obscure instruction that is available on all 80x86. [...] > Unfortunately, the complementary instruction (MOVSX, move with sign >extend) is only available on the 386. MOVZX and MOVSX are only in the 80386 or later (80486). Compared to MOV followed by CBW, length is the same, and 1 clock is saved (for either processor). Compared to MOV followed by XOR, 1 byte is saved but no clocks (one clock longer for 80486!). I only use these in 80386 protected mode programs because they are clearer. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
alexande@dri.com (Mark Alexander) (09/06/90)
In article <1990Sep5.013539.22227@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes: In article <2953@amc-gw.amc.com> jwbirdsa@europa.amc.com (James Birdsall) writes: > There's also MOVZX, an obscure instruction that is available on all 80x86. MOVZX is available on the 386 and 486, but not on earlier CPUs. -- Mark Alexander (uunet!drivax!alexande or alexande@dri.com)
bright@Data-IO.COM (Walter Bright) (09/06/90)
In article <2953@amc-gw.amc.com> jwbirdsa@europa.amc.com (James Birdsall) writes:
<There's also MOVZX, an obscure instruction that is available on all 80x86.
No, it only exists on 386/486 processors.jwbirdsa@amc-gw.amc.com (James Birdsall) (09/06/90)
In article <1990Sep5.013539.22227@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes: >In article <2953@amc-gw.amc.com> I wrote: >> There's also MOVZX, an obscure instruction that is available on all 80x86. >>It will extend a byte to a word, zeroing the high byte. I don't know how the >>execution time compares to an XOR/MOV pair, but I suspect it is faster. >> Unfortunately, the complementary instruction (MOVSX, move with sign >>extend) is only available on the 386. > >MOVZX is only available in TASM in 386 mode, and doesn't seem to work on my >8086. Is there some special encoding that TASM doesn't know about to get >it to work there, or do you mean all 80x86 except mine? That's *interesting.* It occurs to me that to date I haven't tried to assemble the file I used MOVZX in, so I have only some docs' word that it's on all 80x86. The real TASM manuals are in one of N boxes (side effect of moving across the continent), so I'm stuck with Tom Swan's _Mastering Turbo Asssembler_, and it sounds like it has some errors... Sorry to have spread misinformation. -- --- James W. Birdsall jwbirdsa@amc.com 71261.1731@compuserve.com Compu$erve: 71261,1731 GEnie: J.BIRDSALL2 For it is the doom of men that they forget. -- Merlin
suwalski@spock (Woody Suwalski) (09/07/90)
In article <2953@amc-gw.amc.com> jwbirdsa@europa.amc.com (James Birdsall) writes: > There's also MOVZX, an obscure instruction that is available on all 80x86. >It will extend a byte to a word, zeroing the high byte. I don't know how the >execution time compares to an XOR/MOV pair, but I suspect it is faster. > Unfortunately, the complementary instruction (MOVSX, move with sign >extend) is only available on the 386. > Sorry, my 8086 book never mentioned MOVZX.... It requires at least a 286 processor... Woody
feustel@well.sf.ca.us (David Alan Feustel) (09/09/90)
Both MOVSX and MOVZX are 386/486 instructions only.
--
Phone: (work) 219-482-9631 MCI mail: DFEUSTEL BIX: FEUSTEL
E-mail: feustel@well.sf.ca.us {ucbvax,apple,hplabs,pacbell}!well!feustel
USMAIL: Dave Feustel, 1930 Curdes Ave, Fort Wayne, IN 46805-2710bright@Data-IO.COM (Walter Bright) (09/11/90)
In article <4310@chengb> suwalski@chengb (Woody Suwalski) writes: <In article <2953@amc-gw.amc.com> jwbirdsa@europa.amc.com (James Birdsall) writes: << There's also MOVZX, an obscure instruction that is available on all 80x86. <Sorry, my 8086 book never mentioned MOVZX.... <It requires at least a 286 processor... Make that a 386. MOVSX and MOVZX are new with the 386.