Reasons to use asm?

[|2eM!x]

Just wondering, can you give me any reasons to try out asm from vb?
ive read some stuff here and dont really understand..there should be a big tutorial somewhere..i know there must

[dglienna]

only for the speed in which it executes. asm is the fastest way to execute code. the drawback is that it is machine specific. VB will run on most every PC, while asm is processor specific. You would want to write something in Asm to learn it. Then go about writing code to replace VB code, I think.
I started out learning BAL (Basic Assembler Language) on the IBM Mainframe, about 25 years ago.

[Maven]

Just wondering, can you give me any reasons to try out asm from vb?
ive read some stuff here and dont really understand..there should be a big tutorial somewhere..i know there must

When you say try out asm from vb, what exactly do you mean? If you're asking do you think learning ASM is useful for a visual basic programmer, then the answer is yes. If you're asking if visual basic supports inline asm, the answer is no. You have to write dll files and call it from visual basic. Only C++ supports inline asm atm.

I started to write a very long post but instead I'll shorten it to this. If you are interested in learning the secrets of a computer then you should definitly learn asm. If you would rather live in a programming world where everything happens magically behind the scenes then live on my brother. In a nutshell, if you are going to take programming seriously then you need to know asm else there should be no need to learn it.

[Maven]

only for the speed in which it executes. asm is the fastest way to execute code. the drawback is that it is machine specific. VB will run on most every PC, while asm is processor specific. You would want to write something in Asm to learn it. Then go about writing code to replace VB code, I think.
I started out learning BAL (Basic Assembler Language) on the IBM Mainframe, about 25 years ago.

Actually asm isn't faster then visual basic but can be made faster. If you wrote the same exact thing as the visual basic code generator then you would produce in theory the same exe file.

ASM can run every where that a visual basic program can run plus more as you can alter asm source and run on linux and other software platforms. Visual basic generates x86 instructions and is most definitly tied to windows forever. A lot of people get confused about asm because the word "Processor Specific is used". If you learn some **** processor asm that nobody has ever heard of nor will ever use then yes you're pretty much fubar. If you're going to learn ASm then you MUST learn the x86 language. Don't go out and buy some book on some speciality kind of processor, make sure it's X86 you're learning. The reason... Just about every computer you see out there, even supercomputers, are all running AMD or INTEL and both are X86 processors. Next time you pick up a game or some kind of software, look at the system requirements... Just about everything you'll ever pick up will say requires either intel or amd bla bla bla processor.

[|2eM!x]

well yes, seeing as i have no hope in getting to college besides art/soccer this would be helpful..
if youd like to help me learn some, what do download and stuff-id greatly appreciate it

[Maven]

Some links to asm stuff...
http://vbforums.com/showthread.php?t=317393

You may want to buy a book on asm. Check out assembly langauge for intel-based computers by irvine.

[twanvl]

IMHO ASM is a waste of time these days when you are not making your own operating system or working on a realtime embedded os.
Most of the speed gained from switching from VB (pre .net) can also gained by switching to C or C++, which is a lot easier.

[Jacob123]

C++ easier then vb? Are you insane?

Powerful, yes.
Easier, hell no.

[twanvl]

I didn't mean C++ is easier then VB, I meant that C++ is easier then ASM and comparible in speed. VB6 is a lot slower then C++ in areas where speed matters.

[szlamany]

IMHO ASM is a waste of time these days when you are not making your own operating system or working on a realtime embedded os.
Most of the speed gained from switching from VB (pre .net) can also gained by switching to C or C++, which is a lot easier.

You are so absolutely wrong!

I agree wholeheartedly with Maven - if you want to be a professional developer (not programmer, coder or hack!) - then you must know assembler.

People who don't know assember do silly things like REDIM PRESERVE on an array of 1000 items to make it 1001. People who don't know assember have no clue why something is slow - or why something is fast! People who don't know assember have no clue what the operating system is doing. No clue how memory works.

[twanvl]

Assambly is not important anymore these days. The only thing ASM is good for is micro optimization. Micro optimization is a thing you rarely need anymore, you can gain much more by profiling and choosing the right algorithms.
You say you need to know what the operating system is doing, I agree that this can be important. But your operating system is mostly written in C, not in asm.
About your REDIM PRESERVE example, this is not explained easily using asm, the reason you shouldn't REDIM PRESERVE is because of the algorithmic complexity of the operation. I would say a modern developer should learn complexity theory instead of asm.
There is also a difference between knowing the hardware and the cost of operations and knowing assambler. You can learn how memory works from using pointers in C or C++ for example. In a higher level language you don't need to know this at all. Most of this knowledge comes gradually as you program, for example the difference between floating point and integer operations, again, no need to know assambly.

[szlamany]

Assambly is not important anymore these days. The only thing ASM is good for is micro optimization. Micro optimization is a thing you rarely need anymore, you can gain much more by profiling and choosing the right algorithms.
You say you need to know what the operating system is doing, I agree that this can be important. But your operating system is mostly written in C, not in asm.
About your REDIM PRESERVE example, this is not explained easily using asm, the reason you shouldn't REDIM PRESERVE is because of the algorithmic complexity of the operation. I would say a modern developer should learn complexity theory instead of asm.
There is also a difference between knowing the hardware and the cost of operations and knowing assambler. You can learn how memory works from using pointers in C or C++ for example. In a higher level language you don't need to know this at all. Most of this knowledge comes gradually as you program, for example the difference between floating point and integer operations, again, no need to know assambly.

Again - I disagree with your point completely.

Knowing machine code - what the "chip" in the computer is "executing" - knowing that there are registers - and not that many of them - knowing that is paramount to understanding what is happening. Programmers think they make a variable - fill it with a value and all of a sudden stuff happens.

ASM exposes machine code - which all third-generation languages get compiled into.

From what I see of programmers trained in colleges today - they have all kinds of knowledge of proper technique - proper programming constructs to use - but have no clue what's going on under the hood.

They can argue why you should never use GOTO (but really have no practical knowledge of why it's bad practice - they would have to maintain a program written by a bad programmer 10 years ago to appreciate that). But they have no clue that JUMP operations are going on at the machine code level constantly. PC's are all about check condition and jump - do some math - check condition and jump.

Being able to develop a meaningful function in ASM to perform a simple operation makes a big difference in my opinion.

[twanvl]

You are right that knowing what's under the hood is very important. I know some asm myself. But I think you only need to be able to read some of it, and know that there are about 6 usable registers on the x86, etc. Writing asm is completely useless (for x86 at least). Also, IMO it doesn't matter what kind of assambly you know, I only understand half of x86 asm, but I have written programs in z80 asm.
Finally, it is not always important, for example when programming in java or .net I think knowing x86 asm is pointless, your code could just as well run on a powerpc, or an itanium. You need to know the cost of operations, but not the exact translation into machine code.

[yrwyddfa]

When you say try out asm from vb, what exactly do you mean? If you're asking do you think learning ASM is useful for a visual basic programmer, then the answer is yes. If you're asking if visual basic supports inline asm, the answer is no. You have to write dll files and call it from visual basic. Only C++ supports inline asm atm.

You can make VB do it, but it's messy. Whack the hex into an array. GlobalAlloc the same size then copy mem array into it and call the WinAPI (which I can't remember) to jmp to the start of the memory block.

[Maven]

I didn't mean C++ is easier then VB, I meant that C++ is easier then ASM and comparible in speed. VB6 is a lot slower then C++ in areas where speed matters.

C++ is not easier then asm. You'll learn ASM a hella lot faster then you will C++, that I promise you!

I don't think you guys are getting that both C++ and VB generate the same thing, that is machine code. ASM isn't faster then either langauge but has the ability to be. With C++ or visual basic, you can only impletement things in certian ways where as in asm, you have more freedom with what you can do.

[szlamany]

I don't think you guys are getting that both C++ and VB generate the same thing, that is machine code.

That is my whole point - magic happens in the computer to those people who do not explore ASM - which exposes the machine code.

That, in my opinion, is a shame.

[NoteMe]

But last time I checked it made pretty much faster code. And C++ also has the ability to use other instructionsets that you can't use in VB.

[szlamany]

But last time I checked it made pretty much faster code. And C++ also has the ability to use other instructionsets that you can't use in VB.

BAck when we evaluated compilers on the mainframe - 20 years ago (when speed really mattered)...

Companies would make claims like "compiles to within 60% of machine code" - or "compiles to within 80% of machine code". Granted they were tough to challenge the accuracy of these...

But also you could not use %-of-machine code comparisons between completely different languages. Some language constructs are closer to machine code "naturally" - thus they get a higher %-age score. They are also harder to use.

[NoteMe]

It is not all about how much machine code the compiler uses. Different techniques for a job makes differnte ASM output after compiled in C++.


And why would Intel and Codeplay use sooo much money to make fast compilers, if the compiler doesn't do a lot of stuff with the code before it makes the machine code so it can be faster. No one would use US$26500 on a compiler if it wasn't faster then the free compilers out there.



ØØ

[NoteMe]

....(when speed really mattered)...

Ohh BTW, so you are saying speed doesn't matter.......I dare you to make a new thread in the game section and see what happens....

[szlamany]

It is not all about how much machine code the compiler uses. Different techniques for a job makes differnte ASM output after compiled in C++.

Huh??

"how much machine code the compiler uses" - what do you mean by that.

Talk slower - I must be having a hard day

[szlamany]

Ohh BTW, so you are saying speed doesn't matter.......I dare you to make a new thread in the game section and see what happens....

I said " (when speed really mattered)..."

That cannot be syntactically changed into me saying "speed doesn't matter"!

[NoteMe]

I said " (when speed really mattered)..."

That cannot be syntactically changed into me saying "speed doesn't matter"!

Well let me try to rephrase it again then. Make a thread in the game section and say that "speed doesn't really matter"....this should be fun...

[NoteMe]

Huh??

"how much machine code the compiler uses" - what do you mean by that.

Talk slower - I must be having a hard day

Different coding styles and theqnices gets optiomised differently on different compilers. If you want the MAX out of your compiler, you have to know what kind of coding style you should apply to let the compiler optimice it to the max. You don't have that opertunity at all in VB, because you only have one big bloated dumb compiler, that is just happy if it can make working code.

C++ compilers have been around for long, and are used for much more time criticle application hence compiler makers have used more time to optimze the compiler then the VB developers ever did, or will do.

And an other thing is that there is many different companies struggling to make the fastest compiler, and more competition makes them work even harder on optimizing it...

[szlamany]

Different coding styles and theqnices gets optiomised differently on different compilers. If you want the MAX out of your compiler, you have to know what kind of coding style you should apply to let the compiler optimice it to the max. You don't have that opertunity at all in VB, because you only have one big bloated dumb compiler, that is just happy if it can make working code.

C++ compilers have been around for long, and are used for much more time criticle application hence compiler makers have used more time to optimze the compiler then the VB developers ever did, or will do.

And an other thing is that there is many different companies struggling to make the fastest compiler, and more competition makes them work even harder on optimizing it...

Ok - you are truly misunderstanding me.

Imagine you have a requirement - to schedule students into classes at a high school. Some kids schedule in 20 iterations - some kids can take 100,000 iterations.

So it's an algorithm - simple actually - but very time consuming.

If you developed it in ASM - using flawless ASM - you could get as close to machine code - as close to the creators of the chip invisioned was possible.

We didn't do that - we put it in VAX-11 BASIC - the language we decided to use back in the 1980's. We were happy that Digital at the time was stating that VAX-11 BASIC compiled to within 60% of machine code (I'm guessing at the figure - I don't remember).

It took several hours to run.

We decided that developing the algorithm in MACRO-11 (the ASM on that machine) was not beneficial.

Instead we looked carefully at where the most time was spent in the code, and made memory pools, better binary searches - developed some MACRO-11 functions to call.

With that we were making incremental speed changes - 2% here, 5% there.

Always knowing that faster chips were coming along - they would show us a 20% or 30% increase in speed every couple of years.

And I must say that you can write poor code in VB that will turn into even worse machine code instructions to the machine - and you can certainly write neat, clean, concise code in VB that will take less machine code instructions to process.

And by faster compiler, you mean speed in turning source into executable file - right? I personally could care less - that's when I look out the window and stretch my eyeballs

[NoteMe]

And by faster compiler, you mean speed in turning source into executable file - right? I personally could care less - that's when I look out the window and stretch my eyeballs

no no no...you are missunderstanding me completly.....we two are from different worlds...

OK, let me have this post, and the 3 next posts to show you.

When you compile a C++ app, you don't get the same ASM output from different compilers. Different outputs gives different speed during RUN TIME. That is what we are talking about. Most don't care too much about the compile time, because you have debug mode and Release mode with most compilers. So it doesn't take to much time to compile while you are just making the darn app.


So lets take an example from my world. A simple function that don't require too many lines of code is to rotate a vector in 3D space. The following post will show you some simple code to roate a vector. Written in C++.

[NoteMe]

Rotate a vector in 3D space:

static void __cdecl RotateVectors (void)
    {
    int i, r, x, y, CentreX, CentreY;
    int temp [4];
    SetRotation ();

    DrawFlag = TRUE;
    SOAFlag = FALSE;
    IntFlag = FALSE;
    for (r=0; r<4; r++)
	{
	for (i=0; i<NUMPOINTS; i++)
	    {
	    TPoints [i] [0] = CameraRotation [0] [0] * Points [i] [0]
			   + CameraRotation [0] [1] * Points [i] [1]
			   + CameraRotation [0] [2] * Points [i] [2];
	    TPoints [i] [1] = CameraRotation [1] [0] * Points [i] [0]
			   + CameraRotation [1] [1] * Points [i] [1]
			   + CameraRotation [1] [2] * Points [i] [2];
	    TPoints [i] [2] = CameraRotation [2] [0] * Points [i] [0]
			   + CameraRotation [2] [1] * Points [i] [1]
			   + CameraRotation [2] [2] * Points [i] [2];
	    Flags [i] = TRUE;
	    __hint__ ((unroll(2)));
	    }
	}
    }

[NoteMe]

Now, if you compile this with the VectorC compiler you get:

_RotateVectors:
        push ebx
        push ebp
        push esi
        mov esi,eax
        mov eax,80
        push edi
        mov edi,esp
        call __chkstk
        mov eax,esi
        and esp,-16
        mov dword ptr 76[esp],edi
        call _SetRotation
        mov byte ptr _DrawFlag,1
        mov byte ptr _SOAFlag,0
        mov byte ptr _IntFlag,0
        mov dword ptr [esp],4
        movss xmm0,dword ptr _CameraRotation + 20
        movss xmm1,dword ptr _CameraRotation + 8
        movss xmm3,dword ptr _CameraRotation + 28
        unpcklps xmm1,xmm0
        movss xmm0,dword ptr _CameraRotation + 32
        shufps xmm0,xmm1,64
        movss xmm1,dword ptr _CameraRotation + 4
        movaps xmm2,xmm0
        movss xmm0,dword ptr _CameraRotation + 16
        unpcklps xmm1,xmm0
        movss xmm0,dword ptr _CameraRotation + 12
        shufps xmm3,xmm1,64
        movss xmm1,dword ptr _CameraRotation
        unpcklps xmm1,xmm0
        movss xmm0,dword ptr _CameraRotation + 24
        movaps xmmword ptr 16[esp],xmm2
        mov di,word ptr __vconst92
        shufps xmm0,xmm1,64
        movaps xmm1,xmm0
        align 32
_$PreHeader99100:
        xor esi,esi
        xor ebp,ebp
        align 32
L18_FOR_SKIPINC:
        movss xmm0,dword ptr 0 + _Points[ebp]
        prefetchnta 152 + _Points[ebp]
        movss xmm2,dword ptr 4 + _Points[ebp]
        movss xmm5,dword ptr 16 + _Points[ebp]
        movss xmm4,dword ptr 8 + _Points[ebp]
        mov word ptr 0 + _Flags[esi],di
        add esi,2
        movss xmm6,dword ptr 20 + _Points[ebp]
        movss xmm7,dword ptr 24 + _Points[ebp]
        shufps xmm0,xmm0,0
        shufps xmm2,xmm2,0
        mulps xmm0,xmm1
        shufps xmm4,xmm4,0
        mulps xmm2,xmm3
        shufps xmm7,xmm7,0
        mulps xmm4,xmmword ptr 16[esp]
        mulps xmm7,xmmword ptr 16[esp]
        shufps xmm5,xmm5,0
        addps xmm0,xmm2
        mulps xmm5,xmm1
        shufps xmm6,xmm6,0
        mulps xmm6,xmm3
        addps xmm0,xmm4
        movhps qword ptr 0 + _TPoints[ebp],xmm0
        addps xmm5,xmm6
        movss dword ptr 8 + _TPoints[ebp],xmm0
        addps xmm5,xmm7
        movhps qword ptr 16 + _TPoints[ebp],xmm5
        movss dword ptr 24 + _TPoints[ebp],xmm5
        add ebp,32
        cmp esi,49999
        jl L18_FOR_SKIPINC
        cmp esi,50000
        jge L13_FOR_INC
        movss xmm0,dword ptr 0 + _Points[ebp]
        movss xmm2,dword ptr 4 + _Points[ebp]
        movss xmm4,dword ptr 8 + _Points[ebp]
        shufps xmm0,xmm0,0
        shufps xmm2,xmm2,0
        shufps xmm4,xmm4,0
        mulps xmm0,xmm1
        mov byte ptr 0 + _Flags[esi],1
        mulps xmm2,xmm3
        mulps xmm4,xmmword ptr 16[esp]
        addps xmm0,xmm2
        addps xmm0,xmm4
        movhps qword ptr 0 + _TPoints[ebp],xmm0
        movss dword ptr 8 + _TPoints[ebp],xmm0
L13_FOR_INC:
        mov ebp,dword ptr [esp]
        dec ebp
        mov dword ptr [esp],ebp
        jne _$PreHeader99100

        mov esp,dword ptr 76[esp]
        pop edi
        pop esi
        pop ebp
        pop ebx
__ReturnProcedure109:
        ret

__EndProcedure110:

It is higly optimized after your choice using MMX, 3DNow, or SSE or SSE2.


And most of all, it is short. Making less cash misses occure duing run time.

[NoteMe]

Now if you compile it using Visual C++, you get more or less 50% longer code, and it is not optimized for MMX, nor 3DNow, nor SSE, nor SSE2, because you didn't write the ASM to do so.

_RotateVectors:
        push esi
        push edi
        call @SetRotation@0
        xor edx,edx
        mov byte ptr [_DrawFlag],1
        mov byte ptr [_SOAFlag],dl
        mov byte ptr [_IntFlag],dl
        mov esi,4
L1:
        mov ecx,12500
        mov eax,16843009
        mov edi,_Flags
        rep stosd 
        xor eax,eax
L0:
        fld dword ptr [_CameraRotation+8]
        fmul dword ptr _Points+8[eax]
        fld dword ptr [_CameraRotation]
        fmul dword ptr _Points[eax]
        add eax,16
        cmp eax,800000
        faddp st(1),st
        fld dword ptr [_CameraRotation+4]
        fmul dword ptr _Points-12[eax]
        faddp st(1),st
        fstp dword ptr _TPoints-16[eax]
        fld dword ptr [_CameraRotation+20]
        fmul dword ptr _Points-8[eax]
        fld dword ptr [_CameraRotation+12]
        fmul dword ptr _Points-16[eax]
        faddp st(1),st
        fld dword ptr [_CameraRotation+16]
        fmul dword ptr _Points-12[eax]
        faddp st(1),st
        fstp dword ptr _TPoints-12[eax]
        fld dword ptr [_CameraRotation+32]
        fmul dword ptr _Points-8[eax]
        fld dword ptr [_CameraRotation+24]
        fmul dword ptr _Points-16[eax]
        faddp st(1),st
        fld dword ptr [_CameraRotation+28]
        fmul dword ptr _Points-12[eax]
        faddp st(1),st
        fstp dword ptr _TPoints-8[eax]
        jl long L0
        dec esi
        jne long L1
        pop edi
        pop esi
        ret 
  
@SetRotation@0:
        sub esp,80
        fld dword ptr [_Rotx]
        fadd qword ptr [__real@8@3ffbccccccccccccd000]
        mov dword ptr 12[esp],0
        mov dword ptr 20[esp],0
        mov dword ptr 24[esp],1065353216
        mov dword ptr 28[esp],0
        mov dword ptr 36[esp],0
        mov dword ptr 44[esp],1065353216
        fstp dword ptr [_Rotx]
        fld dword ptr [_Roty]
        fadd qword ptr [__real@8@3ff8a3d70a3d70a3d800]
        mov dword ptr 48[esp],0
        mov dword ptr 52[esp],0
        mov dword ptr 56[esp],0
        mov dword ptr 68[esp],0
        fstp dword ptr [_Roty]
        fld dword ptr [_Rotx]
        fcos 
        fld dword ptr [_Rotx]
        fsin 
        fld dword ptr [_Roty]
        fcos 
        fchs 
        fstp dword ptr 4[esp]
        fld dword ptr [_Roty]
        fsin 
        mov eax,dword ptr 4[esp]
        mov dword ptr 60[esp],eax
        mov edx,eax
        lea eax,8[esp]
        mov dword ptr 76[esp],edx
        push eax
        lea edx,48[esp]
        fstp dword ptr 4[esp]
        fld st(1)
        mov ecx,dword ptr 4[esp]
        fstp dword ptr 12[esp]
        mov dword ptr 76[esp],ecx
        mov ecx,_CameraRotation
        fld st
        fchs 
        fstp dword ptr 20[esp]
        fstp dword ptr 36[esp]
        fstp dword ptr 44[esp]
        fld dword ptr 4[esp]
        fchs 
        fstp dword ptr 68[esp]
        call @RotateMatrix@12
        add esp,80
        ret 
        nop 
        nop 
@RotateMatrix@12:
        push ebx
        mov ebx,dword ptr 8[esp]
        push esi
        push edi
        add edx,4
        mov edi,3
L3:
        lea eax,12[ebx]
        mov esi,3
L2:
        fld dword ptr 12[eax]
        fmul dword ptr 4[edx]
        fld dword ptr -12[eax]
        fmul dword ptr -4[edx]
        add eax,4
        add ecx,4
        dec esi
        faddp st(1),st
        fld dword ptr [edx]
        fmul dword ptr -4[eax]
        faddp st(1),st
        fstp dword ptr -4[ecx]
        jne short L2
        add edx,12
        dec edi
        jne short L3
        pop edi
        pop esi
        pop ebx
        ret 4

It is for SURE slower.

[NoteMe]

Now over to the last of the big compilers on the selling market. Intels C/C++ compiler. It sells like ****. But on this example you can see that it is nearly making 100% longer code then the VectorC compiler. And it is not that optimized at all. Unless you have a P4 processor that is. But still the VectorC output will beat it to deth.

_RotateVectors:
        sub esp,52
        call _SetRotation
        mov byte ptr [_DrawFlag],1
        xor al,al
        mov [_SOAFlag],al
        mov [_IntFlag],al
        xor eax,eax
        fld dword ptr [_CameraRotation]
        fstp dword ptr 24[esp]
        fld dword ptr [.bss+1650036]
        fld dword ptr [.bss+1650040]
        fld dword ptr [.bss+1650044]
        fld dword ptr [.bss+1650048]
        fld dword ptr [.bss+1650052]
        fld dword ptr [.bss+1650056]
        fld dword ptr [.bss+1650060]
        fld dword ptr [.bss+1650064]
        fstp dword ptr 28[esp]
        fstp dword ptr 32[esp]
        fxch st(3)
        fstp dword ptr 44[esp]
        fxch st(3)
        fstp dword ptr 40[esp]
        fxch st(3)
        fstp dword ptr 36[esp]
L2:
        xor ecx,ecx
        xor edx,edx
        jmp short L0
        mov esi,esi
        lea edi,0[edi]
L1:
        fstp dword ptr .bss+800024[edx]
L0:
        fld dword ptr _Points[edx]
        fld dword ptr .bss+36[edx]
        fld dword ptr .bss+40[edx]
        fld st(2)
        fmul dword ptr 24[esp]
        fld st(2)
        fmul dword ptr 36[esp]
        faddp st(1),st
        fld st(1)
        fmul dword ptr 40[esp]
        faddp st(1),st
        fstp dword ptr _TPoints[edx]
        fld st(2)
        fmul dword ptr 44[esp]
        fld st(2)
        fmul st,st(7)
        faddp st(1),st
        fld st(1)
        fmul st,st(6)
        faddp st(1),st
        fstp dword ptr .bss+800036[edx]
        fxch st(2)
        fmul st,st(3)
        fxch st(1)
        fmul dword ptr 32[esp]
        faddp st(1),st
        fxch st(1)
        fmul dword ptr 28[esp]
        faddp st(1),st
        mov byte ptr _Flags[ecx],1
        add edx,16
        inc ecx
        cmp ecx,50000
        jl short L1
        fstp dword ptr .bss+800024[edx]
        inc eax
        cmp eax,4
        jl long L2
        fstp st
        fstp st
        fstp st
        add esp,52
        ret 
        lea esi,0[esi]
_SetRotation:
        sub esp,124
        fld qword ptr [$2$3_2il0floatpacket$1]
        fadd dword ptr [_Rotx]
        fstp dword ptr 96[esp]
        fld dword ptr 96[esp]
        fst dword ptr [_Rotx]
        fld qword ptr [$2$3_2il0floatpacket$3]
        fadd dword ptr [_Roty]
        fstp dword ptr 96[esp]
        fld dword ptr 96[esp]
        fst dword ptr [_Roty]
        fxch st(1)
        fsincos 
        fstp dword ptr 96[esp]
        fld dword ptr 96[esp]
        fxch st(1)
        fstp dword ptr 96[esp]
        fld dword ptr 96[esp]
        fxch st(2)
        fsincos 
        fchs 
        fstp dword ptr 96[esp]
        fld dword ptr 96[esp]
        fxch st(1)
        fstp dword ptr 96[esp]
        fld dword ptr 96[esp]
        fxch st(2)
        fst dword ptr 24[esp]
        fld dword ptr [$2$3_2il0floatpacket$5]
        fst dword ptr 28[esp]
        fld st(4)
        fchs 
        fstp dword ptr 96[esp]
        fld dword ptr 96[esp]
        fst dword ptr 32[esp]
        fxch st(1)
        fst dword ptr 36[esp]
        fld dword ptr [$2$3_2il0floatpacket$7]
        fst dword ptr 40[esp]
        fxch st(1)
        fst dword ptr 44[esp]
        fxch st(6)
        fst dword ptr 48[esp]
        fxch st(6)
        fst dword ptr 52[esp]
        fxch st(3)
        fst dword ptr 56[esp]
        fxch st(1)
        fst dword ptr 60[esp]
        fxch st(3)
        fst dword ptr 64[esp]
        fst dword ptr 68[esp]
        fst dword ptr 72[esp]
        fxch st(4)
        fst dword ptr 76[esp]
        fld st(5)
        fchs 
        fstp dword ptr 80[esp]
        fxch st(4)
        fst dword ptr 84[esp]
        fxch st(5)
        fstp dword ptr 88[esp]
        fxch st(3)
        fstp dword ptr 92[esp]
        fld dword ptr 24[esp]
        xor eax,eax
        fstp qword ptr 104[esp]
        fstp st(1)
        fxch st(1)
        fstp qword ptr 112[esp]
        jmp short L3
        lea esi,0[esi]
        lea edi,0[edi]
L4:
        fstp dword ptr .bss+1650028[eax]
L3:
        fld dword ptr 60[esp][eax]
        fld dword ptr 64[esp][eax]
        fld dword ptr 68[esp][eax]
        fld qword ptr 104[esp]
        fmul st,st(3)
        fld st(5)
        fmul st,st(3)
        faddp st(1),st
        fld st(6)
        fmul st,st(2)
        faddp st(1),st
        fstp dword ptr _CameraRotation[eax]
        fld st(4)
        fmul st,st(3)
        fld dword ptr [$2$3_2il0floatpacket$7]
        fmul st,st(3)
        faddp st(1),st
        fld st(5)
        fmul st,st(2)
        faddp st(1),st
        fstp dword ptr .bss+1650036[eax]
        fxch st(2)
        fmul st,st(3)
        fxch st(1)
        fmul st,st(4)
        faddp st(1),st
        fxch st(1)
        fmul qword ptr 112[esp]
        faddp st(1),st
        add eax,12
        cmp eax,36
        jl short L4
        fstp dword ptr .bss+1650028[eax]
        fstp st
        fstp st
        fstp st
        add esp,124
        ret 
        mov esi,esi

[szlamany]

So...

I've been saying - in pretty much every one of my posts in this thread...

Knowledge of ASM helps you understand what the computer is doing at the machine code/chip level.

And didn't you just prove that for me with three perfect examples of machine code?

[NoteMe]

As a round up, the vectorC code is more then twice as fast as the Intel output on an average 1GHz machine. And nearly twice as fast as the VS output.


If I had the opertunity to get the asm output for VB doing the same I guess I had to post 999 post just to get all the code posted, and it is not optimized at all. Just working ASM code.



ØØ

[NoteMe]

So...

I've been saying - in pretty much every one of my posts in this thread...

Knowledge of ASM helps you understand what the computer is doing at the machine code/chip level.

And didn't you just prove that for me with three perfect examples of machine code?

No, you don't have to know anything about ASM, to grab a C++ compiler and beat VB with it hands down even without trying that much. And that is my point.

Maven said:

I don't think you guys are getting that both C++ and VB generate the same thing, that is machine code.

Hell yeah, but machine code is not just machine code. As long as VB makes crappy machine code as it does, it will never be comparable with VB. The output is alfa omega, but you don't have to care about it at all.


Learning ASM helps you understand what is going on, but I can't see it help you much in making fast C++ code, because it is more about knowing your compiler, and what it likes then anything else.


ØØ

[NoteMe]

C++ is not easier then asm. You'll learn ASM a hella lot faster then you will C++, that I promise you!

Thats not possible to generalize.

You did maybe.


I used more time to learn ASM with it hard graphics things, and making use of COM is more or less hopeless.

In C++ it took me no time at all.


But that was me, not you.

An other example is that I have really big problems trying to learn Prolog. Kedaman loves it, and know how to find his way around it. For me it is still just a big void in my brain.

[szlamany]

Noteme - I certainly don't want to give you a big head...

...it looks like you have been banging it for eternity

You apparently appreciate the inner workings of the computer - how you arrived there - through C, Games, ASM - whatever - you appear to be there.

But the original post was:

Just wondering, can you give me any reasons to try out asm from vb?
ive read some stuff here and dont really understand..there should be a big tutorial somewhere..i know there must

And I still maintain that if you are a novice, you will benefit from learning ASM - and removing the magic of what goes on inside.

We have a report writer engine that's in our VB6 application. It loops through the rows in a recordset (could be 1000's) and the "report objects" that are being printed (typically 10 or 20, but for a complex report 200 or 300 is possible). That 1000 * 300 is a loop of 300,000 iterations.

So when it comes to the logic to determine the currentx/currenty on the page we actually "duplicate" that logic in each CASE statement (there are nearly 100 case statements).

Some programmers would have written a SUB/FUNCTION for this.

But we know that a SUB/FUNCTION must deal with the stack/frame and thus has outrageous overhead.

A programmer trained in VB only would never consider not using a SUB/FUNCTION.

I believe that our overall knowledge of the inner workings of the computer allows us to "breach" this construct rule (duplicated code - oh my!).

We happen to have arrived at the "it's not magic" through 2 decades of assembler and reviewing how code compiled from BASIC into machine code (along with other things as well).

[twanvl]

Some programmers would have written a SUB/FUNCTION for this.

But we know that a SUB/FUNCTION must deal with the stack/frame and thus has outrageous overhead.

And those programmers would have done the right thing, writing easy, maintainable code. And if they used a half decent compiler the compiler would have inlined the functions for him. Also, when printing, calculating the currentx/currenty will not be a bottlneck, that will be either the printer or the screen. You will have wasted your time copying code a 100 times and reading it a lot of times, possibly copying it again is there is a bug, etc. Until your profiler tells you that this may be a point that needs optimization you shouldn't even think about it.
There are some cases where converting your code into asm is needed, but to get back to the original post:

Just wondering, can you give me any reasons to try out asm from vb?

Only if you have code that has some very often used inner loop, say a image transformation. And even then, you should first consider C or C++, it will be faster then VB, and it will be more portable and easier to maintain then asm. It may be 2 times slower, but that may not matter at all. It is also quite likely that you can find some library that does what you need to do, so you don't need to write it yourself.
Finally, I don't think anyone can honestly say that writting fast asm, i.e. asm with sse, etc., that optimally uses registers, is easier then writing C.

[szlamany]

And those programmers would have done the right thing, writing easy, maintainable code. And if they used a half decent compiler the compiler would have inlined the functions for him. Also, when printing, calculating the currentx/currenty will not be a bottlneck, that will be either the printer or the screen. You will have wasted your time copying code a 100 times and reading it a lot of times, possibly copying it again is there is a bug, etc. Until your profiler tells you that this may be a point that needs optimization you shouldn't even think about it.
There are some cases where converting your code into asm is needed, but to get back to the original post:

Only if you have code that has some very often used inner loop, say a image transformation. And even then, you should first consider C or C++, it will be faster then VB, and it will be more portable and easier to maintain then asm. It may be 2 times slower, but that may not matter at all. It is also quite likely that you can find some library that does what you need to do, so you don't need to write it yourself.
Finally, I don't think anyone can honestly say that writting fast asm, i.e. asm with sse, etc., that optimally uses registers, is easier then writing C.

My point is that having a SUB/FUNCTION was going to "cost too much" - that doing the currentx/currenty logic in-line was the proper method to choose.

I never said calculating the x/y was a bottleneck. I said that calling a SUB/FUNC to do it would be a bottleneck.

Can you appreciate that at all? Do you appreciate the effort (memory and CPU thrashing) that calling a SUB/FUNC does?

This is not a post (nor is this a thread) about converting to ASM for speed.

It's about the benefits of knowing ASM.

[NoteMe]

Noteme - I certainly don't want to give you a big head...

...it looks like you have been banging it for eternity

You apparently appreciate the inner workings of the computer - how you arrived there - through C, Games, ASM - whatever - you appear to be there.

I have no idea what you are talking about, when you talk in codes like that. Speak up, don't use metaphors....it will only make you lose your point when discussing with a foreigner. Because if you just had a point. It was never transmitted through the right channel.

Well enough about teaching away communication skills.

But the original post was:

Yes it was, I just commented on your and Mavens comparing of VB and C++. And that was a lousy comparison.

And I still maintain that if you are a novice, you will benefit from learning ASM - and removing the magic of what goes on inside.


We happen to have arrived at the "it's not magic" through 2 decades of assembler and reviewing how code compiled from BASIC into machine code (along with other things as well).

I still can't see the big point in teaching ASM for this. You will reveal more then enough of that magic by just using an other language that is not a RAD language, like C++. Then you will deal with stacks, and you can look at cach misses, DMA crash and so on and so on. And I can't see one reason why I would need ASM to understand anything of this. I thought it my self much better by teaching about how a computer is buildt up and then use C++ to deal with it as best as I could. And the ASM course didn't bring anything new too it, nor did it teach me more then 10% then what C++ have thought me. But hell yeah, C++ have thought me a lot about structure, maintenance, coding paterns, and pros and cons about how to lay out your code, that VB never thought me.

I said that calling a SUB/FUNC to do it would be a bottleneck.

And twanvl said that a half decent compiler will inline it for you. And I agree. And he also stated that you would see it on a profiler that it should have been inlined, or done in an other way, and I agree.

[szlamany]

I have no idea what you are talking about, when you talk in codes like that. Speak up, don't use metaphors....it will only make you lose your point when discussing with a foreigner. Because if you just had a point. It was never transmitted through the right channel.

"Giving someone a big head" means giving them a compliment - one that is well deserved, but so well deserved it's better not said!

Banging it is something you appear to be doing in your little animated jpg - that was just a silly joke.

I meant nothing but respect for your level of knowledge.

[szlamany]

And twanvl said that a half decent compiler will inline it for you. And I agree. And he also stated that you would see it on a profiler that it should have been inlined, or done in an other way, and I agree.

I already knew what lines of code were required to be "duplicated" and I also knew that VB was not going to detect duplicate code or function usage and in-line it in the machine code executable.

I didn't need a profiler - and never need a profiler - to show me what's going on.

In the past 20 years we have developed in-house RDBMS systems, RPG-like compilers - lots of low-level functionality - so maybe I'm a little one sided on this.

C&D (my 4 year old twins needed to sign their initials!)