.386 directive
or
.686

hmm why not?
why yes?

and what of .486 and .586?

I use .586 instead of .386 and it seems faster... tho it may just be memory caching doing its thing.
Posted on 2003-03-18 10:01:36 by Homer
.186 - Enables assembly of instructions for the 80186 processor; disables assembly of instructions introduced with later processors. Also enables 8087 instructions.
.286 -Enables assembly of nonprivileged instructions for the 80286 processor; disables assembly of instructions introduced with later processors. Also enables 80287 instructions.
.286P - Enables assembly of all instructions (including privileged) for the 80286 processor; disables assembly of instructions introduced with later processors. Also enables 80287 instructions.
.287 - Enables assembly of instructions for the 80287 coprocessor; disables assembly of instructions introduced with later coprocessors.
.386 - Enables assembly of nonprivileged instructions for the 80386 processor; disables assembly of instructions introduced with later processors. Also enables 80387 instructions.
.386P -Enables assembly of all instructions (including privileged) for the 80386 processor; disables assembly of instructions introduced with later processors. Also enables 80387 instructions.
.387 - Enables assembly of instructions for the 80387 coprocessor.
.486 - Enables assembly of nonprivileged instructions for the 80486 processor.
.486P - Enables assembly of all instructions (including privileged) for the 80486 processor.
.586 - Enables assembly of nonprivileged instructions for the Pentium processor.
.586P - Enables assembly of all instructions (including privileged) for the Pentium processor.
.686 - Enables assembly of nonprivileged instructions for the Pentium Pro processor.
.686P - Enables assembly of all instructions (including privileged) for the Pentium Pro processor.

.MMX - Enables assembly of MMX or single instruction, multiple data (SIMD) instructions.
.XMM - Enables assembly of Internet Streaming SIMD Extension instructions.


The selection of the processor guarantees that the instructions will be available for that processor (i.e STOSD is 486+) and I think that the compiler also does a little optimization of the high level contructs like .IF and .WHILE depending on the processor you select. For the most part you can ignore everything under 486 because that is the minimum practical processor for Windows.

Donkey
Posted on 2003-03-18 10:10:36 by donkey
Thanks for the thorough explaination.

I guess one might as well always use .686P? Even if you don't use the special instructions.
Posted on 2003-03-18 10:20:38 by Homer
Select the minimum processor that supports you features or that the program is meant to run on, I have decompiled some simple programs compiled under .486 and .586 found no difference. I am not sure if there is a problem related to .686P, I don't use priviledged instructs so I have never used it.
Posted on 2003-03-18 10:37:23 by donkey
Off the subject, does code continue executing beyong a loop while the loop is still running?

              

;nice code roticv gave me
lea esi,buffer
mov ecx,128
loop1:
mov DWORD PTR [esi],0
add esi,4
loop loop1


invoke BitmapFromFile, addr buffer
mov hBitmap,eax
invoke InvalidateRect,hWnd,NULL,TRUE


Well the loop seems to keep my image from showing for more then a nano second.
A MessageBox after InvalidateRect will force the image to display until I click 'ok.'
But otherwise it's gone in a blink of an eye.
Posted on 2003-03-18 10:45:30 by Homer
Nope, that takes multithreading. The processor will only execute one instruction at a time. You should use jmp instructions, there is no opcode that is less optimal than loop though in the case you have given it will not save a noticable amount of time. The reason your messagebox keeps the image on the screen is because it pauses execution until it is closed so your window doesn't get the WM_PAINT message.
Posted on 2003-03-18 10:50:53 by donkey
could i use the wait command here?
Posted on 2003-03-18 11:03:38 by Homer
No, the wait command is just to instruct the processor to wait until the co-processor is finished the current operation, not to stall a program, it's effect is virtually nill on integrated the co-processors from the 486 up. You could use the Sleep function from Windows if you want to wait a specific amount of time
Posted on 2003-03-18 11:10:03 by donkey
masm doesn't do optimizations. it's an assembler, not a compiler (though it has a whole bunch of high-level constructs). as donkey already said, the processor directives control which instructions you can use, though.
Posted on 2003-03-18 12:16:49 by f0dder
MASM says it optimizes code for the high level contructs, that's the point I was trying to make. I was not sure if it did this type of optimization based on the specific properties of the processor.
From the MASM32 reference

.ENDIF closes the current .IF, .ELSEIF, or .ELSE code block.
The assembler optimizes to get the best possible code. For example,

.IF ax==0
performs the comparison with:
or ax,ax
which is more efficient than:
cmp ax, 0


Donkey
Posted on 2003-03-18 12:37:10 by donkey
I debugged the problem code with PrintError and PrintString

They seem to be working in the correct order. So why does the image vanish?


The operation completed successfully.
buffer = C:\app\sharilyn.jpg
Posted on 2003-03-18 15:23:31 by Homer
You have shown that you have the right file name in buffer. When you use InvalidateRect the window is invalidated and erased and redrawn as soon as a WM_PAINT message is received by your main message loop. How are you drawing the image on the window?

Donkey
Posted on 2003-03-18 15:31:03 by donkey


.ELSEIF uMsg==WM_PAINT

invoke GetClientRect,hWnd,addr rect
invoke BeginPaint,hWnd,addr ps
mov hdc,eax
invoke DrawText, hdc, addr StatusText,-1, addr rect,\
DT_BOTTOM or DT_SINGLELINE
invoke CreateCompatibleDC,NULL
mov hMemDC,eax
invoke SelectObject,hMemDC,hBitmap
invoke BitBlt,hdc,0,0,rect.right,rect.bottom,hMemDC,0,0,SRCCOPY
invoke DeleteDC,hMemDC
invoke EndPaint,hWnd,addr ps
.ELSE
Posted on 2003-03-18 15:38:22 by Homer
Your routine looks fine Homer, have you checked for a valid bitmap handle. Is the hBitmap handle global ? Besides that I can't think of anything but that you are overwriting the handle somewhere or deleting the bitmap.

Donkey
Posted on 2003-03-18 19:21:22 by donkey
i threw a jump in after the buffer loop to a uMsg method
that worked... dunno why. but ur jmp idea came thru
Posted on 2003-03-19 00:07:48 by Homer
homer,

Unless you want to use instructions that only became available on later processors, you are safe to stick to .486.

If for example you want to use MMX instructions, you will need to use the .MMX directive otherwise the assembler will produce an error.

The system is designed to protect you from using instructions that will not work on some machines.

.386 will not allow you to use "align 16" where .486 will.

Basically pick the level of instructions that you want to use and set the processor model to suit. This way you will not accidentally use an instruction that does not work on an older machine.

Regards,

hutch@movsd.com
Posted on 2003-03-19 02:40:32 by hutch--