Linux / Windows GUI application with assembly
in [ASM]
|
Prev: TMA Assembler?
Next: pshufb
From: Herbert Kleebauer on 8 Nov 2006 03:39 "T.M. Sommers" wrote: > Herbert Kleebauer wrote: > > That doesn't matter. It only matters, that you understand the > > principles, not the details. > > And for that you don't have to rebuild it yourself, or reverse > engineer it, or anything like that. Usually reading the > documentation will tell you. I have just read the "CreateGC" documentation in the "X Window System Protocol" documentation a third time, but I still don't understand it. > That is cheating; you are giving yourself a head start by > assuming that all your analysis is free. It isn't. The only > fair test would be with a library not seen by either party before. That isn't cheating, that is reality. We spend the first 25-30 years of our life (school + university) with nothing but acquiring knowledge for our later job. And also later we have to spend a large amount of our time for getting more knowledge. And the more knowledge you have acquired, the better chances you have. > You can't be serious. Do you really think that in order to be a > good programmer you need to be able to prove the Lebesgue > Covering Theorem? Or know all about Cooper pairs and solitons? > Or be able to build an adder out of discrete components? Do you > really think that in order to build a good, solid, reliable, > correct X program you need to know the details of the X protocol? The essential point is, that you need a global (high + low level) view of the problem. Suppose there is a program where only a very small subroutine consumes 99% of the computing power and a programmer gets the task to optimize this subroutine. Now, if this is such a "local view" programmer, he will look what this subroutine does, take the processor manual and tries to find the optimal sequence of processor instructions to do the job. A programmer with a "global view" would first try to understand why we need this subroutine at all. Maybe there is a different approach for a solution where we don't need this time consuming computation. Suppose you write a graphics program using a HL graphics library but the program is to slow. You can say: it's not my fault, the library is to slow. If you know nothing about the internal working of the graphics library you will have a hard day to speed up your program. But if you you have a least a coarse knowledge of the internal working, you maybe can use a different approach (using the same HL graphics library) which will need much less computing power. That's the same as programming in a HLL with or without knowing assembly programming and the internal working of a CPU. If you process a 2-dimensional array in a HLL then the code looks nearly identical whether you do it row or column wise. But if you know how this array is stored in memory and how a cache works, you will know that there is a big difference in these nearly identical code.
From: Betov on 8 Nov 2006 04:45 Herbert Kleebauer <klee(a)unibwm.de> ?crivait news:455197B3.6FD6B0C7(a)unibwm.de: > Suppose there is a program where only a very small subroutine > consumes 99% of the computing power and a programmer gets the task to > optimize this subroutine. Now, if this is such a "local view" > programmer, he will look what this subroutine does, take the processor > manual and tries to find the optimal sequence of processor > instructions to do the job. A programmer with a "global view" would > first try to understand why we need this subroutine at all. Maybe > there is a different approach for a solution where we don't need this > time consuming computation. Nothing but what i am preaching in the desert since years. Now, for doing so, as opposed to the HLLers, you _need_ to know of the low level... this is to say _Assembly_, and if you need the Assembly way of thinking for doing Code Level Optimization, there is no more any reason for HLLs, unless you would love to make your life complicated for nope. One another point, that i am preaching in the desert since years, is that, as soon as you see a post about Code Level Optimization, you can bet you bubbles that this is from an HLLer. One another day, Herbert, you will have to apply the rigid logic you belove to yourself. :) Betov. < http://rosasm.org >
From: Herbert Kleebauer on 8 Nov 2006 05:16 Betov wrote: > Herbert Kleebauer <klee(a)unibwm.de> ?crivait > Now, for doing so, as opposed to the HLLers, you _need_ to > know of the low level... this is to say _Assembly_, and if > you need the Assembly way of thinking for doing Code Level > Optimization, there is no more any reason for HLLs, unless > you would love to make your life complicated for nope. If you want to find a short way to a room in a very big building, then it's always good to know something about the structure of the building and the scheme of the room numbering. But why the hell do you only use the stairs and not the elevator. Yes, I know your answer: I never used an elevator and it is so much easier to use the stairs, just left foot, right foot, left foot, ... and no complicated panel to handle the elevator and you never can't be sure the elevator stops where you told him to stop. > One another point, that i am preaching in the desert since > years, is that, as soon as you see a post about Code Level > Optimization, you can bet you bubbles that this is from an > HLLer. One another point, that i am preaching in the desert since years to you, is that, as soon as you see a post about programing an application, you can bet you bubbles that this is from an HLLer (nobody writes an application in assembler).
From: Laurent D.A.M. MENTEN on 8 Nov 2006 05:48 > One another point, that i am preaching in the desert since > years to you, is that, as soon as you see a post about programing > an application, you can bet you bubbles that this is from an > HLLer (nobody writes an application in assembler). How can you be so sure nobody writes apps in assembler? Because you don't think yourself able to do it? (Notice I don't assume you're not !!!) Or simply because you have not seen one? There has been appications fully written in assembler since the very first day of computers, do you remember there has been a time when there was no HLL at all? HLL themselves have been implemented in assembler before they were able to self-compile. It's a pity most HLLer assume assembly language is just useless because they never work with it. I bet most of them don't know the difference between while(1) and for(;;). Back in time when I was a student I understood C pointers with the help of assembler so, IMHO, pointers are much easyer to use in assembler. Now that assembler courses are becoming rare, I see studends having trouble with the pointers abstraction of C. That's the way it is.
From: Herbert Kleebauer on 8 Nov 2006 06:14
"Laurent D.A.M. MENTEN" wrote: > > > One another point, that i am preaching in the desert since > > years to you, is that, as soon as you see a post about programing > > an application, you can bet you bubbles that this is from an > > HLLer (nobody writes an application in assembler). > > How can you be so sure nobody writes apps in assembler? Because you > don't think yourself able to do it? (Notice I don't assume you're not > !!!) Or simply because you have not seen one? There has been appications > fully written in assembler since the very first day of computers, do you > remember there has been a time when there was no HLL at all? HLL > themselves have been implemented in assembler before they were able to > self-compile. There have been a time when people used a curricle for traveling but in these days they mostly use cars. There are still a few people who use a curricle just for fun, but even these people would use a car if the want to get fast from one point to an other. > It's a pity most HLLer assume assembly language is just useless because > they never work with it. I bet most of them don't know the difference > between while(1) and for(;;). ---------------------------------------------------------------------- volatile int i; main() { for (;;) {i=0;} } ---------------------------------------------------------------------- .file "t1.c" .section .text .p2align 4,,15 ..globl _main _main: pushl %ebp movl %esp, %ebp pushl %eax pushl %eax andl $-16, %esp .p2align 4,,7 L2: movl $0, _i jmp L2 ..comm _i,16 .ident "GCC: (GNU) 3.3.4" ---------------------------------------------------------------------- volatile int i; main() { while (1) {i=0;} } ---------------------------------------------------------------------- .file "t2.c" .section .text .p2align 4,,15 ..globl _main _main: pushl %ebp movl %esp, %ebp pushl %eax pushl %eax andl $-16, %esp .p2align 4,,7 L5: movl $0, _i jmp L5 ..comm _i,16 .ident "GCC: (GNU) 3.3.4" ---------------------------------------------------------------------- Yes, a big difference, the label L2 is replaced by the label L5! > Back in time when I was a student I understood C pointers with the help > of assembler so, IMHO, pointers are much easyer to use in assembler. Now > that assembler courses are becoming rare, I see studends having trouble > with the pointers abstraction of C. That's the way it is. That's what I say, you should learn assembly programming to write better HLL programs and not to write assembler programs. |