Bad habits
in [ASM]
|
From: o///annabee on 6 Feb 2006 12:23 På 6 Feb 2006 06:59:39 -0800, skrev Dragontamer <prtiglao(a)gmail.com>: > > \\\o///annabee wrote: >> På 5 Feb 2006 20:59:03 -0800, skrev Dragontamer <prtiglao(a)gmail.com>: >> > Basically: use the right tool for the job. >> Anyways, I am not writing for profit, so I do not have the burden of >> short term thinking. To efficiently use my time, is not my first >> priority. > > Nor is mine. Which is why I can spend so much time exploring these > other languages... and playing games :-p Then, explore assembly you dumass! > > OT: > Starcraft rocks btw. I love the Zerg... but I never use them > efficiently. > I can only win games with the Terrain. But I hate how they look, and > how cliche they are. But... you use what you can to win. Its "write like hell" day :) I was never a really good player of starcraft. When I play I like to relax, because this is my "free time" from programming, so I dont play only to win. I like the war to continue, an hour long standtill, a day long fight, so when playing Starcraft, I spent long days at creating large maps where I could do this. My favorite is to create a large map where I can defeat as many AI as possible in a long and weary fight, where many things happen at once. My friend, who is more of a gamer(tm) can use a few zergs and win a game, effectivly using theese small resources to destroy the enemy before he figured the fight had begun. I think he is smarter then me, but I also think I have more fun. To him its like end of the world or something to loose, so he usually wins, to me, i have to build up and spent a lot of time with it before I get the feeling of having anything to loose :)) In fact, in the general case, I like the games I can play for just a few minutes/an hour. Like Motorracing games. I like most car games, and games where I can play fighter pilot. Or games like Quake Actions mod and such. When it comes to strategygames, the one that I had most fun with was Empire Earth, playing against many computers, for 6-8 hours straight. Also, of course a long time favorite of mine was Red Alert 2, and the Yuri version. Pluss countless other I no longer remember. > > [snip] > >> My "avantage" over many asmers, is maybe that I really _did_ do HLL for >> most of the time, and that I can see the topic from both sides. > > But you can't use one HLL to judge the rest. As said in my experiance: > each language has its own feel, its own pros and cons. Maybe, but well, I do not program to get accquinted with languages anymore. > C++ for instance: I may hate the language, but 99% of programmers > have at least heard of this language, and most can write in it. Its > "momentum" is its advantage more than anything else, allows you > to get more manpower on a project. 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? They write the same functionality almost totally diffent, and diffrent from the original code. This richness of choise in asm is not seen in any other language I have tested. But well, as I feel that a few years is at least required to fairly judge a language, I havent really seen that many. I have used, over the years, basic, in various versions, including for c128, sharp, amiga, and for dos, and also for windows (VB). I have used various versions of pascal, and some 5th generations tools like Lotus Notes, for work, and even something called, yeas!, I forgot. I have been doing some SQL in various forms, some script and batch programming. But all theese other things does not count when compared to the time spent with Pascal. Which I am starting to forget now. 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. > 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? > > [snip snip] > >> When I run that game on a bit older hardware (GforceFX5200/AMD1500), it >> clips all the nice graphic, and it still is unplayable. It seems like >> the >> game is useless on older hardware. >> So when the game itself is playable on this new hardware, why do I have >> to >> wait so bloddly long for it to respond to input? >> >> Because it is written in a HLL by HLL thinking people. (Actually Python, >> which i do not know, i think). > > 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. > Second, games today have more artists and musiciansthan > programmers on their dev teams. That tells you where the companies > wanna spend their money :-/ And the program comes to show for it. True. The gaming industry needs content. i wonder if there will ever be a day when they say ; This is enough details, we can now created games with more detail then movies. lets burn the FULL gameengine to a rom chip, and reuse it in there. They are allready closer to virtual _reality_ than even I had figured some time back. In fact, some of the lastest game engines are truely masterpieces. One of my female friends, have trouble getting done anything administrative in windows, but once she get inside a virtual gameworld, she flourishes. The usually very nice lady, becomes a visious and brutal killer, with a real talent for it as well. :) > >> Because they, rightfully, thought that the game is more important than >> the >> UI? And of course it is. But could they not be able to create this game, >> or a game just as cool looking without the latest in hardware? I am very >> convinced that they really could. And I am very convinced that they >> could >> do their next game _faster_ (in less time) if they had written the first >> one with RosAsm. I am convinced that they could have created, even their >> first game in asm a lot faster then with their current tools, if they >> only >> could tell themself that the initial troubles would pass after just a >> few >> months. > > I dunno about that. Complete Lack of a write->compile->run cycle and > the abilities for your manager to tinker with code using an embedded > interpreter seems much more useful than what RosAsm has to offer. 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. > Lack of compile->run can be done by using an interpreter for the > HLL code required. > >> I am also sure, that if written in ASM there would be no waiting time. >> Just start the game, click click click and your good to go. When you use >> Beth logic and multiply the time per user, you get to save life times. > > Not necessarily. Use a good amount of data-oriented programming so > you can write a program to make your maps to the game instead of > coding your maps by hand and I becha it'd take a while to load the > game; even in Assembly. Yes, maybe. If the maps really require 500.000 megas, like it seems this games really does, yes. You may have a point. > 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. > >> They didnt even need to have an installer. You do not need an installer >> to >> install a game. That fact alone is a saving. The time the developers >> waised at logging in and out of the game could also be saved with a fast >> UI. I see plenty of efficiency reasons for using asm only. > > ?? Installer and HLL have nothing to do with each other... No, but theese companies PAY money no? For using the installer, and they also PAY someone to create the installation. Theres no need for those, if you plan to not have them, so that money is out the window, plain and simple. It also takes time to do the installer, and to test the installation and such? 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. For windows itself, the story doesnt make any sense at all. Windows runs allmost better on the slower machine. > > 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 am also 100% convinced, that the game itself would have been better, >> and >> would have done a little more frames, and would have a lot nicer feel to >> it, if written in asm from the start, and that the time they think they >> saved from using a HLL, would be more than compensated by other factors >> that comes from the experience of using asm. > > Framerate is nearly entirely determined by the graphics card... and > then > limited by the monitor's refresh rate (cap at like, 70 FPS) Anything > more > is "wasteful optimization". 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. > Not really anything assembly can speed up. I beg to differ. RosAsm is close instant, in its user interface, whenever possible. This gives a tremendous positive feel. It gives PC what they allways seem to lack. The easyness they should have. Its the having it your way, asap. All the things that makes us angry and stressed out, is when we have to spend a great deal of time waiting. We can work faster, and move on much faster when we do not have to suffer all this waiting. We say that computers are fast, but that is not what we experience in the everyday apps we use. Delphi loads in 7 seconds on my 1500 mhz AthonlonXP. I could load RosASM like 400 times in that frame of time. (If you want me to stop posting this again and again, bring some gad damn new arguments to the table yourself first). Theese seconds seems not a long time maybe, for one users, but Beth is fully correct that all theese seconds adds up. And what is more worse, they really DO add to stress. And they are not needed. 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. 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. But seeing the truely _insane_ byte code, I have no illusions that reason will ever win this war. >> 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. 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? > Beyond that of even Nasm's macro capabilities. Can you give a good example please? > In fact, Scheme and Lisp programming is mainly building your own > "language" above the base. Yes. So is ASM. And RosAsm is the best at _exactly_ this. This is also what I read about lisp. > >> > Another example: Scheme is a language that is a favorite among AI >> > programmers. However, Scheme doesn't work well with external >> > libraries, and its many implementations don't give it really any >> > libraries >> > for it to work with. >> >> Asm will work with libraries in DLL or EXEfiles. > > So mix the Dll with the program. Thats the point. 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. > > >> I am not really thinking one tool to "rule them all". But we are doing >> programming on a CPU that in most cases are a x86 derivative. And in >> most >> cases the Os is really windows. So for this case, a unifying tool should >> be appropriate, if what we want is to write code that performs well. In >> my >> view, each HLL is a derative of asm. They are asm "builded up", to sort >> of >> be easier to other programmers. Just as you say, they each make certain >> compromises. To use asm is to make only _your_ own compromises. It is to >> take full responsibility of you code. There is nothing that can be done >> on >> a windows plattform, by a HLL, that cannot be done many times better in >> asm. And manyh times easier to DO as well. > > 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. > > --Dragontamer (was in rush... gtg for now) >
From: o///annabee on 6 Feb 2006 12:33 P? Mon, 06 Feb 2006 10:27:08 -0500, skrev Frank Kotler <fbkotler(a)comcast.net>: >> Yeah... I'm biased btw. > > "I have preferences. You have biases. He/she has prejudices." > > The main difference is between folks who *know* they're biased, and > those who think their "preferences" are a law of nature! You forgot those that know the preferanses are the law of nature and who also at the same time *know* they are biased, and still sleeps all night :) > > I'm a Nasm bigot... I mean "devout Nasmist"... but that Fasm looks > awfully good! > > Best, > Frank
From: o///annabee on 6 Feb 2006 12:42 P? Mon, 06 Feb 2006 10:50:05 -0500, skrev Frank Kotler <fbkotler(a)comcast.net>: > Herbert Kleebauer wrote: >> Frank Kotler wrote: >> >> >>> do_string: >>> lodsb ; get a character into al >> >> >> But don't forget to clear the direction flag. > > Whoops! Right you are. I always (usually) forget to do that. *I* never > set the damn thing down, and it's "almost always" a safe bet that it's > up when you get it... The direction flag is cleared by default in windows. My apps assume this across all windows OS. Havent seen any problems because of it. the only routines that uses the flag are reverse scanning ops. So much not to worry about in a monosource :) > but it would screw things up royally if it *was* set down, and it's > easy enough to do "cld". > > If we touch the direction flag in a subroutine, I suppose we should > save/restore caller's flags (in case they've got it set down). Is this > worthwhile, in your opinion? Is there a "convention" on it? Yes. std reverse_scan/Copy etc cld > > Thanks for catching that, and proving once again, "Herbert doesn't miss > much!" > > Best, > Frank
From: o///annabee on 6 Feb 2006 12:44 P? 06 Feb 2006 16:12:12 GMT, skrev Betov <betov(a)free.fr>: > Frank Kotler <fbkotler(a)comcast.net> ?crivait news:WsednUfq-eiR9nreRVn- > gA(a)comcast.com: > >> 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 did not really studied the NASM Macros, but i can say > that when i saw what C_the_Guy did with them, i was simply > stuck. > > 'Powerfull", in matter of Macros Engine does not mean that > much. You have to consider "Powerfull at what cost". That > is, implementing a Macros Engine doing marvels is not that > difficult, but, implementing a Macros Engine that is simple > to program, efficient enough for the regular tasks, is a real > hard job. > > In almost all Assemblers, developping a simple and trivial > Macro is almost always a long and difficult job, most usually > done by several programmers. > > Now, considering FASM Macros Engine with these spectacles, > here is an example of a same Macro for FASM and for RosAsm > (Sorry, no example of the NASM version, but, if i recall > well, what C_the_Guy did was very close to this...): > > This is a Macro defining a one Intruction conditional. A > one like "If/End_If", if you like, to be used, for example, > under the form of: > > On eax = &TRUE, call Something, Param1, Param2 > > > The FASM version, first: > > ------------------------------------------------------- > macro .on [args] > { common > local ..on > __ON equ ..on > match =ARGS v1=s>==v2 =, inst, ARGS args ; .on v1 s>= v2, > instruction > \{ cmp v1,v2 > jl __ON > inst > ARGS equ \} > match =ARGS v1=s<==v2 =, inst, ARGS args ; .on v1 s<= v2, > instruction > \{ cmp v1,v2 > jg __ON > inst > ARGS equ \} > match =ARGS v1=s<v2 =, inst, ARGS args ; .on v1 s< v2, instruction > \{ cmp v1,v2 > jge __ON > inst > ARGS equ \} > match =ARGS v1=s>v2 =, inst, ARGS args ; .on v1 s> v2, instruction > \{ cmp v1,v2 > jle __ON > inst > ARGS equ \} > match =ARGS v1>==v2 =, inst, ARGS args ; .on v1 >= v2, instruction > \{ cmp v1,v2 > jb __ON > inst > ARGS equ \} > match =ARGS v1<==v2 =, inst, ARGS args ; .on v1 <= v2, instruction > \{ cmp v1,v2 > ja __ON > inst > ARGS equ \} > match =ARGS v1==v2 =, inst, ARGS args ; .on v1 = v2, instruction > \{ cmp v1,v2 > jne __ON > inst > ARGS equ \} > match =ARGS v1<>v2 =, inst, ARGS args ; .on v1 <> v2, instruction > \{ cmp v1,v2 > je __ON > inst > ARGS equ > \} > match =ARGS v1>v2 =, inst, ARGS args ; .on v1 > v2, instruction > \{ cmp v1,v2 > jbe __ON > inst > ARGS equ \} > match =ARGS v1<v2 =, inst, ARGS args ; .on v1 < v2, instruction > \{ cmp v1,v2 > jae __ON > inst > ARGS equ \} > match =ARGS v =, inst, ARGS args ; .on reg/var, instruction > \{ if v eqtype 0 > if ~ v > jmp __ON > end if > else if v eqtype eax > test v,v > jz __ON > else > cmp v,0 > je __ON > end if > inst > ARGS equ \} > __ON: > restore __ON > restore ARGS } > ----------------------------------------------------------- > > And now, here is the RosAsm version: > > [On | cmp #1 #3 | jn#2 M1> | #4>L | M1:] > > ... which also requires having declared the general purpose > Equates: > > [= e, < b, > a, <s l, >s g, =< be, <= be =>, ae >= ae, <> ne] > > > Once this is said, it is evident for anyone having given > the FASM Macros system a try, that it _can_ do incredible > things, that the RosAsm Macros System could not do... if > one wants to pay the cost... > > :) Ouch :))) You kill the guy! > > Betov. > > < http://rosasm.org > > > > > > > > > > > >
From: o///annabee on 6 Feb 2006 12:49
P? Mon, 06 Feb 2006 18:22:02 +0100, skrev Herbert Kleebauer <klee(a)unibwm.de>: > Betov wrote: >> Frank Kotler <fbkotler(a)comcast.net> ?crivait news:dLKdnQ5dmcP57XreRVn- >> >> > If we touch the direction flag in a subroutine, I suppose we should >> > save/restore caller's flags (in case they've got it set down). Is this >> > worthwhile, in your opinion? Is there a "convention" on it? >> >> No. Inside an Application, there is absolutely no reason >> for taking any care of the Direction Flag. Its default >> is off. > > 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? if its off in some version of windows, its off! End of story. - for 300 years at least :) >> Once a Routine sets it On, it MUST set it off >> before leaving. We should consider any violation of this >> rule as an error as dramatic as forgetting to pop what >> we have pushed. > > You can do this for your own subroutines, but any call to a > library function (DLL or statically linked) can modify the > direction flag. Yes, but I never seen this. |