"We Never Use Assembly Language"
in [ASM]
|
From: o//annabee on 15 Mar 2006 18:28 P? Wed, 15 Mar 2006 14:09:00 +0100, skrev Betov <betov(a)free.fr>: > o//annabee <fack(a)szmyggenpv.com> ?crivait news:op.s6gcjrnace7g4q(a)bonus: > >> To tired to answer this now. But one immidiate thing that strikes me >> is that the new RosAsm macro declarations, the # is about as >> unreadable as the other assemblers. Macros are in general quite >> unreadable in my view. If they get complicated they are simply >> impossible. > > :)) > > Read them again after some good sleep. #If &&0<>0 #If &&0<> '0' #Error 'Unpaired If' #End_If #End_If &&0= '0' you think this is easy ???? ah.... I got it. each "if" increment the counter, and each "end_if" decrements it. So when it have unfolded the inner IF / END_IF the counter must be '0' (its initial value) or some unpairing has occured. Okey now I understand the purpose if the ".If" / ".End_If" It surrounds the multilevel ifs in a boxed security that will prevent errors developing. It look nice _now_, when I understand it. Even if I think it could be put to better use elsewhere. Multilevels if as RARE. > :)) > > The '#' stuff is nothing but very usual convention, > in the various Macros Systems. That is, you need some > char, to make the difference, say, between some '#If', > that belongs to the Macros System vocabulary, and some > 'If', that can, as well, be a nested Macro Evocation, > belonging to the user's Macro. Yes. I assume you have tested all possibilities. Its not horrible. I did in fact be able to understand. But its not like I really wanted to :)))) I dont think I will ever become good at macrowriting. Espesially not at complex macros. > Of course, the more powerfull, the more complicated to > use. But, on the other hand, as long as this kind of effort > is usually done "once for all", at this level of complexity, > this is no more a matter of "everyday usage macros System", > but a matter of collectively, and slowly, developped Macros. Yes. Anyway, I think the | is a good way to structure code, along with the indentation feature. Asm is readable enough in several cases. Like you seem to say, a 4 level deep If statement is close to unreadable. In the code I write I use to spread those on diffrent named macros. Like this for instance ifAssigned D?esi + Window.Caption mov edi D?esi + Window.Caption call GUI.WMKeyDown if D?LastGoodSectionHit <> 0 mov edi D?LastGoodSectionHit Section.VirtualCall vExecute ret end_if EndIfAssigned Both the macros do the same thing, but I find it more readable like this than having two pairs of either. > You know, the "New Macros" Set has been started several > _months_ ago, and is still not finished. There is no hurry > with this. Are you sure, you could fully understand the > actual (or the new...) Macros Set for "Proc"? I am sure > not, because this was some long job to do. No. I was refering to the old Proc/EndP Those wore HARD to understand when I started with RosAsm programming. Because I did not understand how the stack worked. > When i say that the RosAsm Macros System is _easy_. I of > course mean, in the simple practical way, you do use it > yourself, for your everydays developments. But, of course, > developing a complete, and coherent set of default Macros > is another story... > Betov. > > < http://rosasm.org > > > > > > >
From: o//annabee on 15 Mar 2006 19:28 P? Wed, 15 Mar 2006 15:07:49 +0100, skrev Dragontamer <prtiglao(a)gmail.com>: > > o//annabee wrote: >> P? Wed, 15 Mar 2006 04:55:14 +0100, skrev Isaac Bosompem >> <x86asm(a)gmail.com>: >> >> > I do think it is a very good idea to use a scripting language to code >> > game logic. It makes it easy to debug and maintain. >> >> The only scripting language for games should be assembly language. I >> think >> assembly language should be the scripting language for Visual Basic as >> well. >> >> I'd like to add a smiley, but I am serious. > > Assembly don't got the dynamic capabilities of scripting languages. > Sure; you can do function pointers and stuff like that; but you can't > start up > co-processes or new threads that easily in comparison to say... Lua. > It is difficult to create a function during runtime as well with > assembly > without the use of an embedded interpreter/compiler. And heck; even > then, you wouldn't get the power of say Lisp where you can compile > code that would create more code for the macros during runtime; which > can write code that writes code that writes code. > This enables you to create code that otherwise cannot be written with > traditional macros. > And as a scripting language; there is 0 emphasis on speed. > So half of > the instructions avaliable for assembly language would be a waste. > There is a heavy importance on a lack of logic errors and bugs, along > with very big integers in games... Sure; assembly can do 64-bit > arithmatic with some ease (but not as easily as Scheme, Python, Lua > which > automatically convert numbers to bignums whenever they are needed, > which > implies 0 overflow errors that you'd have to check otherwise in > Assembly or > really; most general languages today); but unlike Scheme, there is no > automatic capabilities to create the "Data pyramid" between rational > numbers, and real numbers, bignums (big integers), fixnums (32-bit > integers), > etc. etc. > > Because of Scheme's data pyramid, this makes all rational computations > 100% accurate. (3 / 2 * 2 == 3; not 2 in assembly)... I'm not sure of > Lua... > but there probably is similar capabilities. I know C++ can do it cause > of operator overloading and stuff... but probably not the data-pyramid. > > (unless a "everything" class was made :) ) > > ============================ > > As for the original comment... how Scripting languages make it easier > to > track bugs... that assumes you got the scripting language set up > correctly :) > > There is a "critical mass" for games where a scripting language would > obviously > take longer than building the game itself. So don't use it, lol :) > > --Dragontamer > Examples please. I am tired of hearing myself speaking. Please provide some content or get lost.
From: sevagK on 15 Mar 2006 20:19 o//annabee wrote: > På Wed, 15 Mar 2006 04:55:14 +0100, skrev Isaac Bosompem > <x86asm(a)gmail.com>: > > > I do think it is a very good idea to use a scripting language to code > > game logic. It makes it easy to debug and maintain. > > The only scripting language for games should be assembly language. I think > assembly language should be the scripting language for Visual Basic as > well. > > I'd like to add a smiley, but I am serious. On a related note, it is a good idea to have a scripting language built *into* a game. One of my all time favorites "Hearts Of Iron" has a nice scripting language that helps to easily set up new scenarios. It's because of that the game is still on my HD (that and you don't need the damned CD to run it). -sevag.k www.geocities.com/kahoinor
From: o//annabee on 15 Mar 2006 20:59 P? Wed, 15 Mar 2006 17:49:51 +0100, skrev randyhyde(a)earthlink.net <randyhyde(a)earthlink.net>: > Closer, but still no cigar. > Care to try again? I am glad you noticed the error. I have corrected the code. When doing the alignment properly, we get a speedup, of both loops. As you can see, yours is still slower. Also, as a by-product I get actually IDENTICAL timings for several runs. Which I havent really seen before. Note that I rearrange the code I test. I move the loop I test to the top of the procedure, and I test from executing a menuitem, when the app is in an IDLE state. This greatly enhances the accuracy of timings, compared to putting them at the main: label. And if I just restarted the debugger by F6 for timing the next loop, the timings would be severely wrong. So therefore, I test one, write the timings in the magin, and then rearrange the code before running again. The diffrence _is_ in favor of my code. Whereas in the orginal post, you claimed mine (or rather RosAsm's) while macro to be slow, because it has the test at the top. Even if the timings wore in your favor, would not change the fact that the RosAsm macro does very well. So even it is a small point, it proves you boasted out some definite error, in your attempt to scare people from using the RosAsm macros. This test definitly prove that there are no reason not to use the RosAsm While macro. Actually. since the timings are both steady, and the diffrence very small, this might even be due to an initial payment in your routine, because of a few misinterpeted jumps by the CPU. The diffrence is BAh - 45h which is 75h or in decimal 117 cycles. This is for 10000 iterations. Lets see what happens for 2 iterations: 9E in total for yours. and 29 for the RosAsm while macro. The diffrence is then 75, which is 117 cycles as before. hmm. I do not know why but seems a few branch mispredictions may be at the cause of this. And they happen in _your_ code. Not in the RosAsm While macro. ---- This was tested on an AMD 64, 3700+ running win2000, TestProc: cpuid rdtsc | push eax mov ecx D$n xor eax eax jecxz L0> Align 16 L0: add eax ecx dec ecx jnz L0< L0: rdtsc | pop ebx sub eax ebx int 3 ;/4EBA cpuid rdtsc | push eax mov ecx 10000 xor eax eax Align 16 while ecx > 0 add eax ecx dec ecx End_While rdtsc | pop ebx sub eax ebx int 3 ;4E45 > Cheers, > Randy Hyde > P.S., oh, and btw, you need a serializing instruction before the last > rdtsc instruction in these sequences, too. And it would also help if > you moved the rdtsc *after* the align operation, as you don't > particularly want to measure a varying number of NOPs between the two > sequences. More bla bla ? lol.
From: sevagK on 15 Mar 2006 20:59
o//annabee wrote: > > > > See the statement labelled "Here is the limitation." The "I&&0" token > > generates an RosAsm local label by concatenating "I" with the current > > string value of &&0. However, these local labels in RosAsm are limited > > to the range I0..I9, hence there is a limit ten levels of nesting > > before you run into problems with this scheme. > > I am not sure 9 is the true limit, but if it isnt it should be. A couple of questions: Is this limit just for if..endif macros nesting or does the limit include nesting a combination of macros? eg: if... if... while... forever.... if.. ... endif endfor endwhile endif endif If one macro uses a variable &&0, and another macro also uses that same symbol, does Rosasm generate unique local symbols for each macro that uses the &&0 variable or does the whole thing get arsed when some macro nested somewhere in another macro overwrites an &&x variable? -sevag.k www.geocities.com/kahlinor |