Bad habits
in [ASM]
|
From: Betov on 6 Feb 2006 13:00 Herbert Kleebauer <klee(a)unibwm.de> ?crivait news:43E785BA.481A4BD3 @unibwm.de: > Is there an official Microsoft documentation which specifies that > the direction flag is cleared when control is given to the first > instruction in a PE executable? :) Feel free to write as many CLD as you want for each and any Api call and/or PE up-loaded, but, for your information, i have never written any CLD, along my many years of Win32 Programming (other than after having "pushed" :]] a STD), and i have never seen one single case, where i could have been proven to make a wrong assumption. I am not a Pshycho maniac, yet. Though, if you insist, maybe i will become one. ;) Betov. < http://rosasm.org >
From: randyhyde@earthlink.net on 6 Feb 2006 15:08 Dragontamer wrote: > > Scheme and Lisp's macro capabilities are beyond that of any language > I have seen of in my life. > > Beyond that of even Nasm's macro capabilities. Take a *good* look at HLA's macro facilities sometime. > > In fact, Scheme and Lisp programming is mainly building your own > "language" above the base. And most of the "HLL stuff" that people complain about in HLA was done exactly this way. It is quite easy to extend the HLA language using its macro facilities. Cheers, Randy Hyde
From: randyhyde@earthlink.net on 6 Feb 2006 15:18 Herbert Kleebauer wrote: > Is there an official Microsoft documentation which specifies that > the direction flag is cleared when control is given to the first > instruction in a PE executable? Yes. I don't have the URL, but MS documentation states that the DF is clear when code comes from Windows, and it must be clear when you call a Win32 API. Cheers, Randy Hyde
From: Dragontamer on 6 Feb 2006 17:52 \\\o///annabee wrote: > Ok. As you may know, I hate C with a passion. Allthough I do not know it, > I can read most of it, a nessesity when on windows, sometimes. But well, > the strange thing is that the "cool tricks" of the C language are nothing > against the cool things you can do in assembly. Like for instance Franks > and Herberts code in the thread? [snip snip] I'd agree. Most C "tricks" are common practice in many other languages. C++ tricks on the other hand, surprise me (well, with a language that big, it is hard not to be surprised). But nothing a little Nasm macro can't do. (and in fact, Nasm macros do surpass... but I think too "lowly" about C++, so I am surprised when it can do something i think it cannot do.) > I never gave a shot to C# or Java, as I know I can do fine with asm, I see > no need for learning it. > I have seen the applets, and they are just another version of the same. > More work, for more nops. > I have transended HLL for ever more now. I just lost interesst in them. Well, here is a little difference between you and me :) I don't consider "HLL" langauges to be of the same group. At very least, interpreter vs compiler should be considered. > > But the much more clean ObjC beats C++ in nearly every department > > in terms of language and features... unfortunatly, it isn't popular > > enough > > so the tools tend to be less stable and unusable for now. (when it gets > > more stable however; I'd switch) > > Hmm. What about code you have written. Do you no fear of loosing all that > work. What kind of apps have you written? Well, this is yet another advantage to writing in C. ObjC can compile anything a C compiler could compile. (so I can consider any C code to really be ObjC :-p ). And there are tools avaliable for C++ in ObjC. Really, a great advantage, easy switch. > > Games of that size cannot be completed *in time* without HLL tools, > > such > > as XML. (actually, I'm not fond of XML myself, I much prefer ObjC's > > file format. But using the "standard" has its advantages) > > I honestly belive that this is not true. Meh, I don't feel like arguing this point. Too much on the table as it is. [snip snip] > Seems. Well, not the way I see it. One could write such an embedded script > engine in assembly. I am going to write such a script engine, for my > 3DModels, so that I can script the models in a 3d editor. When I did this > in pascal, it took at most a couple of days to have such basic scripting > abilities like transformation, scaling, and such. Ah. We are getting somewhere. Why design a language for this script engine: when Scheme, Python, Perl, and Lua are already avaliable? *note, I got more on this later* > > And games have a very small window they aim for: too late and the > > hype for the game would be dead. So that would leave very little > > time to optimize as well. > > Maybe. But my claim is that if theese companies used a good assembler from > the start, and made sure all their programmer learned it and used it, they > would SAVE "time to marked" as they call it. > To me this is not even debatable. I am 100% sure of this. If I can save > time from using assembly, theese gaming geniuses should be able save twice > as much. Rather fine opinion. Other (more interesting points) I'd rather tackle for now. > Also, if their UI is slow, and the games is slow to load, this makes for > more strain to testers. theese people test their stuff millions of times > before shipping? I cannot see how they could loose from having everything > beeing instant, whenever possible. The UI in this game (bf2), is so > unresponsive, that when you give it a few fast escapes, it sometimes go > into loops that load and unload the UI, several seconds after you gave it > the command. On a machine with one GIG of ram, and one MEGAbyte of cache!. > the app doesnt even use all the ram on the machine I think. So why do it > need to be unresponsive? And the installer is worse. Opportunity cost. If you spend 2 weeks optimizing the code, you don't get the realistic explosion or something silly like that. :-p > For windows itself, the story doesnt make any sense at all. Windows runs > allmost better on the slower machine. Lol. So true. Linux == rules (unless you can't get it to run... then it sucks) > > I don't need an installer for my C/C++ stuff, nor python or whatever I > > use. > > Is python a good language, you think? How is it compared to C/C++? I myself don't like it that much. It falls in my eye as "Quick and Dirty". I can probably write a program in Python much faster than I would in C/C++, but the maintanence would kill me IMO. Although, Python can be an embedded scripting language into your program. And it is used in Adonthell, python is used as a scripting engine to read in the Maps, character scripts and so forth. http://adonthell.linuxgames.com/ > Ok. Maybe so. But I am thinking about other things. One of the really nice > things about asm, is that you sometimes discover really cool, totally new, > ideas, just because of the way asm works on your brain. Thats what I am > saying here also. using asm teaches you things, how to do many things, > that you simply wouldnt have thought of using a HLL. You simply wouldnt > have seen it. Is my claim anyway. Off topic again :) But... Haskell is my "thinking language" of choice. When it does the quicksort algorithm in 5 lines, you gotta love it :) qsort [] = [] qsort (x:xs) = qsort smaller_than_x ++ [x] ++ qsort larger_than_x where smaller_than_x = [y | y <- xs, y < x] larger_than_x = [y | y <- xs, y >= x] I have not found a good "use" of this language personally, but I love thinking in it. :) A "translation" to english takes more lines than the code. :) First line is: If qsort is handed an empty list, return an empty list. 2nd line: if you are handed a list with at least 1 element, call the first element "x", the rest of them xs, and then return qsort (recursive call) the list smaller_than_x and a new list created with x, and another list called "larger than x". 3rd line: Where you define... 4th line: "Smaller than X" to be the list of all elements smaller than x 5th line: and "Larger than X" to be the list of all elements greater than or equal to X. [snip] > Mikkesofts line has allways been that "logically" since macines double > capacity, there is no need to optimize anything, but what is the reality? > Even on the 3700+, the windows OS just suck and suck. And that is even > when it is not needed. The basic OS functionality however is quite fast. > (And btw, several orders of magnitude better then Linux)! > > So my guess is that Linux is slow because its written in a HLL mindset, > and Windows later functionalities the same. Windows lower functionalites > are written in asm mindset and therefore is quite fast. The BSDs IIRC runs faster than Linux now. I'd have to say Linux is slow because it has become bloated by contributors. Kinda like Wikipedia, there is a lot of inefficiency when reading articles in wikipedia, because there is no "single force" that is strong enough to trim it down. > Pluss, this bubbly talk from me is much more about something else. While > the HLLs and their kind of money tinking rules, we might end up in a > situation where asm is evetyually decleared officially dead, for good, and > we risk first that it is simply becomes "illegal" to use it on the most in > use OSes, later on, and then maybe even later they move the C libraries > into hardware, and just pull the plug. Then a few years later, it will end > up with just one tool, killing all competition and before you know it, we > all have to pay 3000$ for licences to program theese libraries, at all. > Someday soon they could even try to implement the HLLs directly onto the > CPU clue, and what we have then is frightening. The fact that this will > please both linux people and windows people, makes the whole thing even > more scary. > > This is starting to become techically possible? Hope I am just wrong and > wrong here. Nah. As said before: use the right tool for the job. Assembly has its place. Even in its current state, most programmers agree that you should use assembly for at least speed purposes, and that designing the program takes more time than actually implementing it. (with reading and maintenance as the most important and biggest factor in coding) > >> Now to your assessment that one should use the right tool for the right > >> job. > >> Well, asm is the only tool where you can create the language you need. > >> You do not have to waste time seeing whats out there. You just start at > >> once to form the language needed for the task, using asm as building > >> blocks. RosAsm for instance is a dreamtool for exactly this purpose. > > > > Scheme and Lisp's macro capabilities are beyond that of any language > > I have seen of in my life. > > I read much positive stuff about lips. I never heard of sheme, and I did > not try Lisp. > But what I read about lips, reminded me of assembly in a way, In the sound > of it. Scheme is a varient of Lisp. Designed to be smaller, cleaner, and more "purely functional" than Lisp. But they are very much similar. In fact, some people consider Scheme to be just a "dialect" of lisp. > So why not use ASM? it can assume any language "facility", at great > speeds. And it can assume all the languages yet to be created. Why oh why! > cant we all see and admit to this? As for "Assume all the languages yet to be created", you can write a portable assembly interpreter in C. http://bochs.sourceforge.net/ So C/C++ can "Assume all the languages yet to be created" as well, as you can write assembly in a C/C++ defined interpreter. I don't like the logic btw. Thats why I posted such a silly example. In fact, you can theoretically write everything in Brainfuck. It can assume any language faculty, so why not use it? :-p > > Beyond that of even Nasm's macro capabilities. > > Can you give a good example please? (define (myinterpreter) ;define the function "myinterpreter" (display ">") ;the prompt symbol (write (eval (read))) ; read something, evaluate it, and write it to screen (myinterpreter) ;recursive call There, you just built a scheme-interpreter inside of scheme in 4 lines :) A more solid Example 2: As you may know, Common Lisp is entirely prefix notation. (+ 1 4) Is how you'd write 1+4. And (/ (5 + 5) 2) is how you'd write (5+5) / 2 http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/infix/infix.cl The above is a library for Common Lisp that allows you to do 5 + 5 in Lisp. This is about similar in difficulty of creating a macro in Nasm that allows: eax add ebx or 5 mov ecx It isn't just the language that was changed: no. The whole *syntax* of the language can be changed to your bidding. (Admittingly, Lisp tends to do better than Scheme in this regards) [snippy] > Once you've learned to use asm efficently, with a tool like RosAsm, theres > no more any good arguments of going back to a HLL. You were talking earlier of creating a scripting engine. I'm suggesting that you use Scheme as your scripting engine, instead of writing one from scratch. *more on the why should I use scheme section* > > I really think you should try scheme out. > > Why? Name even one thing about it to convince me. Bring an example to show > what you mean. > Document it. Scripting language example comes up yet again. I am sure you can see the advantages to "embedd" a language into your code. For example: using Scheme as a loading language for your Game Engine, something to load those maps. (or writing a loading language yourself) You can create *extremly interactive* levels, that can be modified without touching a single compiler ever (because the compiler is in your code now, no need for the compile loop... again *sorry to repeat arguments*). You don't need to put all the "interactivness" into your compile cycle. The best place to define how a level is interactive is *inside the level file*, and not in the code. With an interpreter like Scheme, you can do that. A good example of this is Trackballs, a free GPLed game that uses Scheme as an embedded interpreter. The thing to note is how it created an interactive scripting language for loading its levels. http://trackballs.sourceforge.net/readme.html A good example: (switch (real x) (real y) (lambda () on) (lambda () off)) This (defined in the game) would create a switch that would call the function "on" if the player hit it, and the function "off" if the player turned it off, allowing really, anything to happen inside the game. These functions can be defined *inside the level file*, as the level file is just sent into the embedded Scheme interpreter. So now, you don't have to change your code to make a level "more interactive", even if assembly was the best language for doing the job, the best place for the code to be is in the level file, and not embedded into the engine. I'm sure you can see why. Other good places for this: The AI for a boss or the individual units in a game. You can now change the AI completely from map-to-map. (for games like a platformer, where the Boss is *defined* by the AI patturn it has) The AI *should* be defined with the boss data, and not inside the code for the engine. BTW, as much as I love Scheme, Lua is supposedly much more popular. I haven't used it, so I can't comment on it. So check that language out as well. (Then again, "popular" languages tend to be C-like by design... again, I haven't tried lua so maybe it isn't C-like) --Dragontamer
From: Dragontamer on 6 Feb 2006 18:16
Frank Kotler wrote: > Dragontamer wrote: > > ... > > Nasm vs Fasm really is a tossup between the macro language. > > You've stated, in the past, that Fasm's macro language was "more > powerful" than Nasm's. Do you have an example of something Fasm can do, > that Nasm can't? When it comes to syntax... Nasm's macro syntax is > uglier than a bulldog's hind end. Looks like Gas on bad acid! But I > think it's fairly "powerful" (not as much so as Masm or HLA, but > "fairly"...). Says right in the manual it's "powerful"... > > I've only taken a quick look at Fasm's macros - they look a bit cryptic, > too. James just posted an "invoke" macro in Nasm. We'll be wanting > something a little more sophisticated, but for openers, how would that > look in Fasm? I probably made this statement when I was much more competent with Fasm. But I'll try my hand at it anyway :) Fortunatly, this one comes nearly straight out of Fasm documentation (I'm saved!) macro stdcall proc,[arg] { reverse push arg common call proc } "reverse" is a macro convention that... is easily explained by an example. stdcall myproc, 1, 2, 3, 4 Would be turned into: push 4 push 3 push 2 push 1 call myproc [arg] is 1,2,3,4 all together. "reverse" makes a code block repeating over and over again, one time for each in the group. The other thing that Fasm has in terms of macros is the "virtual" directive, which defines data on a register or whatnot... Hard to explain. The easiest way to say i guess would be to create a "union", all you have to do is: mylabel dd 12345, 67890 virtual at mylabel byte1 db ? byte2 db ? byte3 db ? byte4 db ? byte5 db ? byte6 db ? byte7 db ? byte8 db ? end virtual Because you have "virtual data" at mylabel, byte1 would equal whatever was at the first byte. The biggest use of this is in macros, and it is useful in terms of creating a representation of the stack. virtual at ebp parameter2 dd ? parameter1 dd ? end virtual parameter2 in this case would be: "ebp" and parameter 1 would be "ebp + 4" Erm, I haven't done this in a while, but the "concept" is there :) So if the code doesn't run, just take my word that there is code that makes it that simple. :-p --Dragontamer |