"We Never Use Assembly Language"
in [ASM]
|
From: Betov on 15 Mar 2006 04:09 "Isaac Bosompem" <x86asm(a)gmail.com> ?crivait news:1142394914.080283.265440 @j52g2000cwj.googlegroups.com: > congratulations Randall! > > I believe in abstraction. Coherent. :) Betov. < http://rosasm.org >
From: Frank Kotler on 15 Mar 2006 05:48 o//annabee wrote: .... > Hei! Is this sort of "before I have asked, you have answered trick? > Will this run compile as win32 file? I check it out. Thanks. > >> global _start Well, no. Windows isn't going to be happy with the int 80h's :) With some modification - replace the I/O and the sys_exit... The difficulty is with the dread word "linker"... I've done a few things using Anthony Williams' Alink. Uses Nasm's "-f obj" output format. It *can* be linked with "win32.lib", but if the API's are declared right, you don't need it... I'm not sure this is right... ; nasm -f obj hwcons.asm ; alink -oPE hwcons.obj extern WriteFile import WriteFile kernel32.dll extern ExitProcess import ExitProcess kernel32.dll section _TEXT use32 class=CODE ...start push dword 0 push dword num_chars push dword MSGLEN push dword msg push dword -11 ; ??? - works IIRC call [WriteFile] exit_ok: push dword 0 exit: call [ExitProcess] section _DATA use32 class=DATA num_chars dd 0 msg db 'Hello, Console.', 13, 10 MSGLEN equ $ - msg ;-------------------- Another, more "modern" option would be to use "-f win32". Link with polink, or... no, you wouldn't like that one :) An option I think you'd like is to use "-f bin" mode and get your executable directly - no linker. It involves include files - unless you wanna spell out the whole thing like Herbert does. Too much cruft to post. RosAsm has all this stuff built in ("Nice work, Guga!") , Nasm doesn't. The only thing I've got using that is Numit_or's "shutdown", with the "dos stub" altered to shut down, instead of claiming we need Windows to do it! :) I'll try to remember to tar that up - zip, I mean - and upload it. Too tired right now - remind me. If you feel like joining a !Yahoo! group, <http://groups.yahoo.com/group/win32-nasm-users> There are a few demos of various kinds in the "files" section... Later, Frank
From: Betov on 15 Mar 2006 08:09 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. :)) 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. 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. 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. 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: Dragontamer on 15 Mar 2006 09:07 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
From: Dragontamer on 15 Mar 2006 09:26
Betov wrote: > Dispiting the insane noises around, not having to care > of the JMPs sizes generated by the Construct Macros is > a major disadvantage. What disadvantage would that be? --Dragontamer |