I understand that MASM32 and HLA do not use optimization when they use
user32 functions from user32 library such as WinMain, CreateWindow,
ShowWindow, UpdateWindow, DestroyWindow, DispatchMessage, and
TranslateMessage including WindowProc.  It looks like total 8 functions that
we need to use.  It is why MASM32 only show 2-3K size rather than 38K on
pure C runtime.
    MASM32 and HLA do not use optimization, but it always improve
performance because it has the shorest 8 routines as functions that we need.
Optimization is used to take out some x86 instructions that they are not
needed.
    Is it correct that optimization is defined to reduce the byte size by
removing some unneeded instructions or extra instructions?  Do you think
that I am satisifed with MASM32 and HLA that it can run much faster with
only 8 functions.  I prefer to use MASM32 as my programmer.  Why do I have
to move to HLA?  Is it because HLA is much easier for reading than MASM32?
It does not mean that it is good to use HLA for the beginning, but it is
useful for both beginners and advanced users.  Please advise.

-- 
Bryan Parkoff

"Bryan Parkoff" <nospam@nospam.com> wrote in message
news:ar2ob.6536$D87.6360@twister.austin.rr.com...
>     I understand that MASM32 and HLA do not use optimization when they use
> user32 functions from user32 library such as WinMain, CreateWindow,
> ShowWindow, UpdateWindow, DestroyWindow, DispatchMessage, and
> TranslateMessage including WindowProc.  It looks like total 8 functions
that
> we need to use.  It is why MASM32 only show 2-3K size rather than 38K on
> pure C runtime.
>     MASM32 and HLA do not use optimization, but it always improve
> performance because it has the shorest 8 routines as functions that we
need.
> Optimization is used to take out some x86 instructions that they are not
> needed.

There is no performance improvement. Visual C++ automatically links in the C
runtime library. MASM and HLA do not. It is also possible to write code in
Visual C++ that does not use the runtime library, and it will be just as
small. Use /nodefaultlib and /entry to remove the runtime libraries and set
your main function.

The size of the executable will affect the amount of time it takes to load,
but otherwise it does not affect the performance of the application. The
difference between 36 KB and 2-3 KB is so small that it is not noticeable.

>     Is it correct that optimization is defined to reduce the byte size by
> removing some unneeded instructions or extra instructions?  Do you think
> that I am satisifed with MASM32 and HLA that it can run much faster with
> only 8 functions.  I prefer to use MASM32 as my programmer.  Why do I have
> to move to HLA?  Is it because HLA is much easier for reading than MASM32?
> It does not mean that it is good to use HLA for the beginning, but it is
> useful for both beginners and advanced users.  Please advise.

HLA is useful both for the beginner and for more experienced assembly
programmers. My personal preference is either nasm or inline assembly.

MASM does not modify your program. The assembly instructions you write are
outputted as-is. (To be technically correct, MASM used to convert one form
of the lea instruction to a mov. I am not sure if it still does.) The
difference in size is due to the runtime libraries. When you include the
runtime libraries, your executable gets a lot of code added to it.

-Matt

    I do understand your comments, but it does not answer my question.  The
size of 4 to 32KB is not important.  Lets discuss the topic -- Optimization.
Do optimization mean to REMOVE UNNEEDED instructions that can improve the
performance?
    I do understand that it can affect performance while it is loading
binary information from storage into memory before it will not affect
performance while it is in memory.  Does it make sense what I mean?

-- 
Bryan Parkoff
"Matt Taylor" <para@tampabay.rr.com> wrote in message
news:fa7ob.55435$RP2.8367@twister.tampabay.rr.com...
> "Bryan Parkoff" <nospam@nospam.com> wrote in message
> news:ar2ob.6536$D87.6360@twister.austin.rr.com...
> >     I understand that MASM32 and HLA do not use optimization when they
use
> > user32 functions from user32 library such as WinMain, CreateWindow,
> > ShowWindow, UpdateWindow, DestroyWindow, DispatchMessage, and
> > TranslateMessage including WindowProc.  It looks like total 8 functions
> that
> > we need to use.  It is why MASM32 only show 2-3K size rather than 38K on
> > pure C runtime.
> >     MASM32 and HLA do not use optimization, but it always improve
> > performance because it has the shorest 8 routines as functions that we
> need.
> > Optimization is used to take out some x86 instructions that they are not
> > needed.
>
> There is no performance improvement. Visual C++ automatically links in the
C
> runtime library. MASM and HLA do not. It is also possible to write code in
> Visual C++ that does not use the runtime library, and it will be just as
> small. Use /nodefaultlib and /entry to remove the runtime libraries and
set
> your main function.
>
> The size of the executable will affect the amount of time it takes to
load,
> but otherwise it does not affect the performance of the application. The
> difference between 36 KB and 2-3 KB is so small that it is not noticeable.
>
> >     Is it correct that optimization is defined to reduce the byte size
by
> > removing some unneeded instructions or extra instructions?  Do you think
> > that I am satisifed with MASM32 and HLA that it can run much faster with
> > only 8 functions.  I prefer to use MASM32 as my programmer.  Why do I
have
> > to move to HLA?  Is it because HLA is much easier for reading than
MASM32?
> > It does not mean that it is good to use HLA for the beginning, but it is
> > useful for both beginners and advanced users.  Please advise.
>
> HLA is useful both for the beginner and for more experienced assembly
> programmers. My personal preference is either nasm or inline assembly.
>
> MASM does not modify your program. The assembly instructions you write are
> outputted as-is. (To be technically correct, MASM used to convert one form
> of the lea instruction to a mov. I am not sure if it still does.) The
> difference in size is due to the runtime libraries. When you include the
> runtime libraries, your executable gets a lot of code added to it.
>
> -Matt
>
>

Hi Bryan

Optimization by example:

Consider the following mindless, but instruction function:

void Multiple(int *block,int count)
{
for(int i = 0; i < count; i++)
   block[i] *= 30;
}


Generated code:
---------------

; Stack frame
push	ebp
mov	ebp,esp
push	ecx

; for(int i = 0; i < count; i++) {
xor	eax,eax
mov	[ebp-4],eax
mov	edx,[ebp-4]
mov	ecx,[ebp+12]
cmp	edx,ecx
jnl	label1

; block[i] *= 30;
mov	eax,[ebp-4]
mov	edx,[ebp+8]
imul	ecx,[edx + eax*4],1eh ; going nowhere fast!
mov	[edx + eax*4],ecx

; }
inc	[ebp - 4]
mov	eax,[ebp - 4]
mov	edx,[ebp + 12]
cmp	eax,edx
jl	label2

pop	ecx
pop	ebp
ret

Example optimized code:
-----------------------

push	...		; only what is necessary. No stack frame.


mov	esi,[esp + 4]	; block (assumes nothing pushed, adjust as necessary)
mov	ebx,[esp + 8]	; count
shl	ebx,2		; ebx doubles as offset address and counter

..REPEAT
	mov	eax,[esi + ebx - 4]
	mov	ecx,[esi + ebx - 8]
	mov	edx,eax
	shl	eax,6	; x32
	shl	edx,1	; x2
	sub	eax,edx ; x30
	mov	edx,ecx
	shl	ecx,6	; x32
	shl	edx,1	; x2
	sub	ecx,edx	; x30
	mov	[esi + ebx - 4],eax
	mov	[esi + ebx - 8],ecx
	sub	ebx,8
..UNTIL ZERO?

pop	...		; only what was pushed
ret

Optimizations take many forms.
* No stack frame if the function is simple
* Multiple interpretations of a register (ebx is counter and offset)
* The generated code has a memory counter, the example has ebx
* Exploiting structure. This example assumes count is even, and 
     processes two items per loop in count/2 repeats
* The generated code has horrible loop control with two exit points
* The generated code uses a dog-slow imul whereas the example uses very 
fast shifts/subs (of course, I chose 30 to illustrate my point)
* The generated code uses slower operate-on-memory instructions
eg inc [ebp-4]
* Optimized code can use some of the special registers (eg esi/edi) 
which generated code usually avoids

The above example is by no means optimum, since loops can be unrolled 
etc, but it should give you a good idea of some optimizing 
possibilities.  By careful scheduling, the loop instructions can be 
re-organized to get more of it to run in parallel.

Hope that helps.

Regards
Andrew

"Bryan Parkoff" <nospam@nospam.com> wrote:
>
>    I do understand your comments, but it does not answer my question.  The
>size of 4 to 32KB is not important.  Lets discuss the topic -- Optimization.
>Do optimization mean to REMOVE UNNEEDED instructions that can improve the
>performance?

Sometimes.  It can also mean redesigning a sequence of code to work in a
smarter way.  It can also mean ADDING instructions: for example, in many
cases, you can speed up a loop by repeating the code a number of times and
reducing the number of loops.  That results in more bytes.

However, before you go off on a wild goose chase, there are some things you
need to know.  Optimization is something you do to code that runs slowly.
There is NO POINT in optimizing code that is only executed a few times, or
code that is just calling Win32 APIs.  First, you decide whether your
progam NEEDS optimization -- whether it is executing unacceptably slowly.
Next, you figure out WHERE your program is spending your time.  Then, you
optimize that section.  If you have a piece of code that takes 5% of your
program's time, even if you optimize it so well that it takes no time at
all, you will only have improved your performance by 5%.

(Trivial Pursuit clue: that last point is called "Amdahl's Law".)
-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.