32-bit movs, lods, stos ES:EDI and DS:ESI ?
Advanced Warming Systems Research and Development
I am writing a data analysis application using "real big " or "unreal"
mode - which requires 32-bit registers and allows a segment to be
greater than 64K.
When performing a 32-bit movs, lods, or stos will the index register
be 16 or 32-bit? In other words, is this possible?
;// ES:EDI points to some place in real big memory.
cld
mov cx, 1000H
mov eax, 12345678H
stosw eax
repnz
Will the above code mow through my conventional memory (as would
happen if the most significant 16 bits were ignored and just DI was
addressed)?
Asuuming this code works and stores 12345678H 4096 times in extended
memory, can I use ECX to specify > 64K operations? For example,
;// ES:EDI points to some place in real big memory.
cld
mov ecx, 0001F000H
mov eax, 12345678H
stosw eax
repnz
I suspect that only DI and CX will be used, but any comments will be
greatly appreciated.
Brett Moore
Director of Research
Advanced Warming Systems
aw...@sat.net
John Tessin
: I am writing a data analysis application using "real big " or "unreal"
: mode - which requires 32-bit registers and allows a segment to be
: greater than 64K.
: When performing a 32-bit movs, lods, or stos will the index register
: be 16 or 32-bit? In other words, is this possible?
As I understand it, the encoding of the command determines whether the
extended registers are used. The only problem I can see is that you have
to override the default assumptions of the assembler and explicitly
specify the regs to use.
These fragments worked for me.
; zero the buffer data
cld
xor eax, eax
mov edi, eax
mov ecx, 80000h
rep
stos DWORD PTR ES:[EDI]
...
mov edi, 0 ; set pointer to offset 0
mov ecx, 100000h ; set number of reads
mov dx, Cam_IO_Base ; get port address
REP
INS WORD PTR ES:[EDI], DX ; read 16 bits
...
WriteBufferBlock PROC NEAR
push cx ; save cx
mov cx, DiskXferBufferSize/4 ; move data 4 bytes at a time
lea edi, DGROUP:DiskBuffer
cld
REP
MOVS DWORD PTR ES:[EDI], GS:[ESI] ; mem block move capture
; buffer to disk xfer buffer
mov ax, 4000h ; write the block to disk
mov bx, DGROUP:FileHandle
mov cx, DiskXferBufferSize
lea dx, DGROUP:DiskBuffer
int 21h
pop cx ; restore cx
RET
WriteBufferBlock ENDP
: I suspect that only DI and CX will be used, but any comments will be
: greatly appreciated.
BTW - It was trying to get DPMI, which is what I was using then, to work
that led me to throw up my hands and buy Watcom with the Dos4gw
extender. My 386max worked great, but the code hated the quarterdeck
product. (I found out later you have to load dpmi support seperately.)
This code was in a 16 bit code segment, but the data was being written
into 32 bit data segments. These were allocated via DPMI calls. It's
possible that the selector flag denoting the segments as 32 bit was what
made these work. OTOH - don't you have to redefine some selectors into
32 bit mode to get un-real mode to work?
FWIW - I hope this helped.
--
jte...@netcom.com
CIS: 71774,1731
http:\\www.geocities.com\CapitolHill\1685
===============================================================
If ye love wealth better than liberty, the tranquility of
servitude better than the animating contest of freedom, go
home from us in peace. We seek not your counsels or arms.
Crouch down and lick the hands which feed you. May your
chains set lightly upon you, and may posterity forget
that ye were our countrymen." -- Samuel Adams
===============================================================
Vince Bridgers
>
> I am writing a data analysis application using "real big " or "unreal"
> mode - which requires 32-bit registers and allows a segment to be
> greater than 64K.
>
> When performing a 32-bit movs, lods, or stos will the index register
> be 16 or 32-bit? In other words, is this possible?
>
>
> cld
> mov cx, 1000H
> mov eax, 12345678H
>
> stosw eax
> repnz
>
> Will the above code mow through my conventional memory (as would
> happen if the most significant 16 bits were ignored and just DI was
> addressed)?
>
> Asuuming this code works and stores 12345678H 4096 times in extended
> memory, can I use ECX to specify > 64K operations? For example,
>
> ;// ES:EDI points to some place in real big memory.
>
> cld
> mov ecx, 0001F000H
> mov eax, 12345678H
>
> stosw eax
> repnz
>
> greatly appreciated.
>
> Director of Research
> Advanced Warming Systems
processor requires an address override prefix in order for EDI and ESI to be used for addressing rather than DI and SI. The
REPn prefix for string instructions uses CX by default in a 16-bit code segment unless the address-size attribute is
overridden by an address-size override (67h). Some language tools will insert the necessary bytes into the code stream to
perform this operation. Check your manual for appropriate syntax. The following example works in a 16-bit code segment, and
assembles using MASM or TASM.
.model small, c
.code
.386
... (section ommitted)
xor eax, eax
mov es, ax ; set es to 0 (we are in real-big mode)
mov ecx, 10000h ; set count to 64K
mov edi, 100000h ; start at 1M
db 67h ; tell processor to use EDI, and ECX (address-size override)
rep stosd
... (section ommitted)
If you have access to an instruction set manual, consult the pseudo-code description of instruction behavoir. This can be
most useful in coding more obtuse operations. For instance, the STOSD instruction is described like:
IF AddressSize = 16
THEN use ES:DI for DestReg
ELSE (* AddressSize = 32 *) use ES:EDI for DestReg
FI;
IF byte type of instruction
....
(remainder not repeated for brevity)
From the first few lines, one can see that in a 16-bit code segment, or in real mode, ES:DI will be used. It is possible,
however to override that behavoir with an address-size override prefix (67h). In that case, the processor will recognize the
instruction as one with an address size attribute of 32-bits.
As for the REPn prefix, the pseudo-code description is :
IF AddressSize = 16
THEN use CX for CountReg
ELSE (* AddressSize = 32 *) use ECX for CountReg
FI;
...
(remainder not repeated for brevity)
If the instruction associated with the REPn prefix has an address size attribute of 32-bits, then the ECX register will be
used. Otherwise, the CX register will be used.
Hope this helps.
=====================================================================================================================
Vince Bridgers
AMD Austin Development Center
vince.b...@amd.com
Std Disclaimer applies - I only speak for myself (I'm told I should probably say that)
=====================================================================================================================
Bob Smith
jte...@netcom.com (John Tessin) wrote:
>George C. Lindauer (gcli...@starbase.spd.louisville.edu) wrote:
>
>: Yeah, but I don't recall whether you can get the STOS to use ECX as the
>: count register rather than CX while in real mode.
>
>I looked into the manual and the implication is that ECX is always used
>for count. But then, I don't use un-real mode. Considering this from a
>usefulness standpoint, not always a good idea, the decision by the
>processor to use cx or ecx should be based upon the target segment. Of
>course the work around is to use a loop or branch based upon ecx. Not as
>pretty, but at least it will be cached.
>
>You know, I'm almost certain I used ecx, when testing the read/write
>routines, to fill a multi-meg buffer with known values. OTOH - I was
>also in a virtual machine and not un-real mode.
If you always use the full form of the instruction, it's easier to see
which registers are used. For example,
rep stos byte per es:[di]
addresses data via ES:DI counting with CX, regardless of the CPU
mode and the USE16/USE32 attribute of the code segment.
rep stos byte ptr es:[edi]
addresses data via ES:EDI counting with ECX, also independent of the above
attribute.
----------------------------------
Bob Smith -- bo...@access.digex.net
Jim Neil
>
>Advanced Warming Systems Research and Development (aw...@sat.net) wrote:
>: When performing a 32-bit movs, lods, or stos will the index register
>: be 16 or 32-bit? In other words, is this possible?
MASM 5.1 and above support the following:
Movs es:[edi],ds:[esi]
Lods ds:[esi]
Stos es:[edi]
etc...
I don't know about other assemblers.
Jim Neil