I wanted to optimize the division with a shr but it's not working.
Agner Fog's example used eax, but I get the same result as using ax.

DETA_it db "Remember the 5 P's - Proper Planning Prevents Poor Performance"
count dw \$ - DETA_it ; length of string

xor cx,cx
mov ax,count ; move count value in prep for division
shr ax,2 ; divide an unsigned integer by 2

int 3
;mov dl,2
;div dl ; al contains result
xor cx,cx
mov cl,al ; limits string to 255 chars max !!

mov si, offset ; address of start-of-strings
xor ax, ax
more:
xor ax,
inc si
inc si
dec cx
jnz more
cmp ax, stored_val ; previously calc'd value of string
Posted on 2004-02-09 23:04:43 by skywalker
mov cx, count ; move count value in prep for division
shr cx, 1 ; divide an unsigned integer by 2

mov si, offset DETA_it ; address of start-of-strings
xor dx, dx
more:
lodsw
xor dx, ax
loop more

cmp dx, stored_val

The only error was using two for the shift count - which results in divide by four.
Posted on 2004-02-10 00:00:18 by bitRAKE

mov cx, count ; move count value in prep for division
shr cx, 1 ; divide an unsigned integer by 2

mov si, offset DETA_it ; address of start-of-strings
xor dx, dx
more:
lodsw
xor dx, ax
loop more

cmp dx, stored_val

The only error was using two for the shift count - which results in divide by four.

Thanks, I misunderstood the formula for unsigned division.

Is it possible to use the flat model and still use my 16 bit instructions. I am ready to start using the
full 32 bit regs, learning about code alignment, etc.

I recall some program someone wrote for me once where I had to run it from a DOS prompt.

Thanks.
Posted on 2004-02-10 11:56:54 by skywalker
The instructions are the same in 16 and 32 bit mode (although 32 bit allows for more powerful addressing modes), only the registers are different. 32 bit adds the 32 bit extended registers (eax etc). But you can still use the smaller registers (al, ah, ax). Mind you that switching back and forth between eax and ax may cause pipeline stalls, and using ax will put an extra prefix-byte in front of the instruction, so your code will get larger.
(Same for all other registers where I said ax etc).
I don't see why anyone would ever want to use 16 bit code though. It's safe to assume that everyone has 32 bit CPUs and OSes these days, and writing 32 bit code is a lot easier and faster.
Speaking of which, things like inc/dec/lodsw are also lots slower these days. Try keeping your code orthogonal, and study the optimization manuals.
Posted on 2004-02-10 12:18:00 by Henk-Jan

The instructions are the same in 16 and 32 bit mode (although 32 bit allows for more powerful addressing modes), only the registers are different. 32 bit adds the 32 bit extended registers (eax etc). But you can still use the smaller registers (al, ah, ax). Mind you that switching back and forth between eax and ax may cause pipeline stalls, and using ax will put an extra prefix-byte in front of the instruction, so your code will get larger.
(Same for all other registers where I said ax etc).
I don't see why anyone would ever want to use 16 bit code though. It's safe to assume that everyone has 32 bit CPUs and OSes these days, and writing 32 bit code is a lot easier and faster.
Speaking of which, things like inc/dec/lodsw are also lots slower these days. Try keeping your code orthogonal, and study the optimization manuals.

You are right. Part of my excuse is that there isn't an equivalent reference source for Win 32 apps like
the interrupt list that Dos programming has.

I have decided to start looking over Hutch's examples and study them.

I think it's neat that many Win32 apps are < 10,000 bytes.
I am running Win 98 and it probably won't be long till it won't support the newer hardware.

Someone in a store told me that Compaq computers hardware will often fail if Win XP is uninstalled and Win 98 put over it.

Thanks.
Posted on 2004-02-10 12:38:26 by skywalker
You are right. Part of my excuse is that there isn't an equivalent reference source for Win 32 apps like
the interrupt list that Dos programming has.

There is, you will be interfacing with the Win32API, and you can find a reference at http://msdn.microsoft.com/library, or use the Win32 hlp file that you can find elsewhere on this board (or download the 3 ISOs with the complete MSDN reference on them from the Microsoft site somewhere).

Someone in a store told me that Compaq computers hardware will often fail if Win XP is uninstalled and Win 98 put over it.

Why would you want to install Win98 when you have WinXP anyway? Especially asm coders should avoid Win9x as the plague, because one tiny bug can kill the entire OS. NT4/2k/XP are much more robust, and you can freely screw up without crashing and rebooting all the time :)
Posted on 2004-02-10 13:14:19 by Henk-Jan
Hi :)

Why would you want to install Win98 when you have WinXP anyway? Especially asm coders should avoid Win9x as the plague, because one tiny bug can kill the entire OS. NT4/2k/XP are much more robust, and you can freely screw up without crashing and rebooting all the time :)

:grin:
Not only that, on Win9X you can crash the whole system from a DOS window, using DEBUG.EXE :rolleyes:
You can trash the IVT with a single command, I think it was something like this --but I'm not going to try it right now...
``````
Crashing Windows 9X for dummies :grin:
1) Open a DOS box
2) Run DEBUG.EXE (at C:\WINDOWS\COMMAND)
3) Type "f 0000:0000 FFFF FF" and hit Enter
``````
Posted on 2004-02-10 16:55:02 by QvasiModo

You are right. Part of my excuse is that there isn't an equivalent reference source for Win 32 apps like the interrupt list that Dos programming has.

You can also get the win32.hlp file, though it's quite outdated it still beats downloading the full SDK...
http://www.cs.virginia.edu/~lcc-win32/
Posted on 2004-02-10 16:57:53 by QvasiModo

You can also get the win32.hlp file, though it's quite outdated it still beats downloading the full SDK...
http://www.cs.virginia.edu/~lcc-win32/

Thanks.
Posted on 2004-02-10 17:26:47 by skywalker

Hi :)

:grin:
Not only that, on Win9X you can crash the whole system from a DOS window, using DEBUG.EXE :rolleyes:
You can trash the IVT with a single command, I think it was something like this --but I'm not going to try it right now...
``````
Crashing Windows 9X for dummies :grin:
1) Open a DOS box
2) Run DEBUG.EXE (at C:\WINDOWS\COMMAND)
3) Type "f 0000:0000 FFFF FF" and hit Enter
``````

Debug is powerful indeed. I don't write things such as protected mode or such.
Win 98 is pretty good about watching what runs.

I did have fun running some protected code I downloaded. It gave some warnings, but I didn't read all the way.
When I ran it, it asked something about running in only in Dos mode. I said yes and on bootup another program in the directory ran and froze. It wouldn't let me boot into Windows. I had to whup out the old Bootdisk, edit out a win.com command out of autoexec.bat and I was back in business.

I don't like XP because of no support for DOS. I don't much care for folks deciding what I can run on MY
computer.

take care.
Posted on 2004-02-10 17:33:40 by skywalker
I don't like XP because of no support for DOS. I don't much care for folks deciding what I can run on MY
computer.

Well XP, like its NT-family cousins NT4, 2k and 2k3 server, are not based on DOS, unlike Win9x, and that's the whole difference.
Win9x is aimed at running DOS applications, while also supporting Win32. But because DOS programs have to run, it is impossible to make the system entirely bulletproof. Certain things cannot be sandboxed/virtualized/whatever, because otherwise DOS programs will break (and still not everything runs inside Win9x, but at least you can reboot to commandline-only... except that DOS 7 requires much more memory than its predecessors, so there are still programs that do not run this way).

The NT-family is entirely based on a protected-mode kernel, and DOS is run in a separate virtual machine, as a sandbox. DOS stuff cannot crash the rest of the OS. If DOS programs were written more cleanly, more of them would run in NT.
Since this was a problem in the early days of Win32, MS offered the Win9x-family so people could migrate to Win32 slowly.
Now nobody needs DOS anymore, so Win9x could finally be ditched without a problem.

I think it's the best thing that ever happened to the PC actually. I don't see why anyone would want to go back to the shaky DOS days.
Posted on 2004-02-10 18:42:31 by Henk-Jan