Linux / Windows GUI application with assembly
in [ASM]
|
Prev: TMA Assembler?
Next: pshufb
From: Betov on 8 Nov 2006 10:44 Herbert Kleebauer <klee(a)unibwm.de> ?crivait news:4551D084.740C0D06 @unibwm.de: >> Believing that C is a usable Language is way over my head: I can't >> believe it, but, so is it. > > That's nothing you have to believe. Try it and you will see it. You mean... i have to convert, and i will see a god? Oh! My goat! Why am i trying to convert all Jehova Witness, knocking at my door, to budhism? :) Betov. < http://rosasm.org >
From: T.M. Sommers on 8 Nov 2006 13:10 Herbert Kleebauer wrote: > 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. That's just what I've been saying to you. -- Thomas M. Sommers -- tms(a)nj.net -- AB2SB
From: ?a/b on 9 Nov 2006 10:52 On Wed, 08 Nov 2006 13:41:40 +0100, Herbert Kleebauer wrote: >Betov wrote: >> Believing that C is a usable Language is way over my head: I can't >> believe it, but, so is it. > >That's nothing you have to believe. Try it and you will see it. i tried C language, but many functions are easier in pure assembly not in C; sscanf, printf, numerical conversion routines, many numerical functions etc are some of them
From: T.M. Sommers on 10 Nov 2006 05:47 ¬a\/b wrote: > On Wed, 08 Nov 2006 13:41:40 +0100, Herbert Kleebauer wrote: >>Betov wrote: >> >>>Believing that C is a usable Language is way over my head: I can't >>>believe it, but, so is it. >> >>That's nothing you have to believe. Try it and you will see it. > > i tried C language, but many functions are easier in pure assembly not > in C; sscanf, printf, numerical conversion routines, many numerical > functions etc are some of them That's just silly. Things like printf are trivial to use in C, and just as trivial to call from assembler. On the other hand, implementing them in assembler is definitely non-trivial. -- Thomas M. Sommers -- tms(a)nj.net -- AB2SB
From: T.M. Sommers on 10 Nov 2006 06:33
Herbert Kleebauer wrote: > "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. By documentation I meant all documentation, including books and tutorials, not just the 'official' documentation. In this particular case, note that it says in the Acknowledgments, "This document does not attempt to provide the rationale or pragmatics required to fully understand the protocol or to place it in perspective within a complete system." It is clearly intended for implementors of X, not users, and thus presumes knowledge of how X works. If you really want to learn X at a low level, you should start learning how to use Xlib and Xt. After you learn that, and only after that, you can think about reimplementing them. Trying to implement them without even knowing how to use them is a sure recipe for frustration and failure. >>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. Yes, it is cheating, and no, it isn't reality. Reality is that all learning takes time, and that time is limited. The only fair comparison between two methods is to start them out at the same place, not to give one a head start. > We spend the first 25-30 > years of our life (school + university) with nothing but > acquiring knowledge for our later job. You don't spend those 25 years learning the X protocol. > 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. Sure, knowledge is great; no one says otherwise. But the question under discussion is the best way to start using a previously unknown system or library or whatever. >>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? > > Suppose you write a graphics program using a HL graphics library but > the program is to slow. You are making a number of unspoken assumptions, here. You assume that the cause of the slowness is the library. You assume that is is possible to do something about it if it is. You assume that you are competent to do something about it. You assume that you will be allowed to do something about it. Finally, even if my program is slower than I'd like, it is infinitely faster than yours, because you are still not finished reimplementing Xlib, and haven't even started on the application. > You can say: it's not my fault, the library > is to slow. Sometimes you have to. The use of the library might not be a decision you can change. You probably would not be allowed to fiddle with the library, either, even if you could. Programming is a branch of engineering, and tradeoffs are always a part of engineering. > If you know nothing about the internal working of the > graphics library you will have a hard day to speed up your program. Assuming that the problem is with the internals, and not with your own code or design. Also notice that almost no one outside of Microsoft knows about the internals of Windows, yet people still manage to develop usable apps with that system. > 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. And when knowledge of the internals of the library becomes important would be the appropriate time to delve into them. -- Thomas M. Sommers -- tms(a)nj.net -- AB2SB |