From: ?a/b on 6 Feb 2006 04:41 On 5 Feb 2006 21:05:29 -0800, "Dragontamer" <prtiglao(a)gmail.com> wrote: >?a\/b wrote: >> >Yes, I know gets is dangerous, but I couldn't figure out how to supply >> >stdin to fgets... >> >> easy, you write in a c file for your favorite c compiler >> >> "fgets(array, 256, stdin);" >> >> and you say to compiler that you want the assembly file out >> then you see in the assembly file the name the compiler traslate >> "stdin"; than use that name > >stdin is only pointer to a fstream in C, so all you have to do is > >extern stdin (or _stdin for windows) > >and then supply stdin to fgets. > >If i remember correctly... well, try it anyway. > >--Dragontamer wrong stdin here is a macro; in stdio.h file #define stdin (&std::_streams[0]) #define stdout (&std::_streams[1]) #define stderr (&std::_streams[2]) I know only here stdin==__streams does it mean that here stdin ==__streams stdout==__streams+4 stderr==__streams+8? problem with c compiler that i see are only the define macro for c code and perhaps the initialisation code for the c routines that could be in a c program (don't know if the linker add that code too)
From: o///annabee on 6 Feb 2006 08:39 P? 5 Feb 2006 20:59:03 -0800, skrev Dragontamer <prtiglao(a)gmail.com>: > > \\\o///annabee wrote: >> P? Sun, 05 Feb 2006 21:55:21 +0100, skrev Herbert Kleebauer >> <klee(a)unibwm.de>: >> >> > James Daughtry wrote: >> > >> > But because it doesn't make any sense to write >> > an application in assembler, RosAsm is useful for ...? >> >> I agree with many things you say Herbert, but the above sentance is >> really >> untrue. Have you tried writing something with RosAsm? >> >> It is not only that RosAsm, of course, is the best tool for learning >> assembly. But it is evidently also the best tool for doing Windows >> programming. You _cannot_ see this without trying. Its impossible to >> find >> all the goodies of RosAsm when not using it over time. >> >> RosAsm doesnt have any other shortcommings, then the ones it was never >> designed for. For windows programming it is simply the very best tool >> yet >> available. > > This is one of the points I like to debate on because I follow a > strange philosophy. > > I feel the best tool for the job is the best *language* for the job, > and that > tools should be built to allow easy interphasing between languages. > > Multi-language programming, in essence. > > The reason is simple: Assembly is by far the best thing to use if you > need > speed (especially with these MMX and SSE instructions), but rewriting > a game into Assembly for speed isn't smart if graphics are slowing you > down. Rewriting the program to use DirectX or OpenGL would create > a much bigger increase in speed than Assembly. > > Basically: use the right tool for the job. Yes. This reminds me of many things. It espesially reminds me of the later years focus on "efficiency", inside, it seems to me, like the whole of sosiety. Short term profit thinking. Asm may not _seem_ best short term language, because it has a rather steep _initial_ learning curve, but it is more then ten times as efficient, long term. And HLLs need you to learn a lot as well to use them. 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. For instance : I used close to 5 years for writing the stuff I do now, in Delphi. Theese are "hobbylevel" 5 years of course, where I spend sometimes months at playing games. For instance, Starcraft, Diablo I and II, All Quake versions, wolfenstein, Empire Earth, Red Alert, Battlefield 1, Homeworld I and II, Halflife, BattleZone2, Counterstrike, HalfLife2, Doom3, and now recently Battlefield2 (which I found boring after just 2 weeks). Just to name the games I can remember. But spending so much time playing games, is something I allways did, all the way back since "Jumpman junior" :)) But to port the hobbylevel 5 years to assembly took 2 years, which are also hobby time, some longer periods of code, and some month where you rarly write something. The resulting code is maybe 100 times faster in the general case, 10 times as maintainable, gives me an energykick for just knowing how incredible easy it was to do, and is 3 times as easy to expand. I now have ported allmost all of the stuff I needed from Delphi, like for instance path management routines, and much of the trivial, boring, but needed stuff that we take for granted in a HLL. What I call utilityrutines, that are very useful, but not that interessting to do. MemoryManagement, String manipluation, FileAccess, Directories ect. I am now basically ready to take up on the stuff I added to Delphi, and add that to my asm code, and continue from there. It has been a breeze the way I see it. It is actually rediculous to look back and see how easy it was. Actually, it so crazy that I allmost get soft for thinking about the poor man and woman, struggling with HLLs. 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. The reason I eventually went to assembly, is that I for many years bought the HLL myth. I used the HLL "objects" as much as possible, beeing lazy, and wanted to have as much of the work done for me. But I am a creative person, I want also to add, at least some, stuff. it happend many times during thoose roughly ten year (together) with Pascal, and Delphi, that I trashed my code, and jumped on to the "new" stuff comming with the upgrade of the compiler. Each time I had learned all the new stuff, I added something to this new stuff, in the 6 month until the next upgrade. But the tool I used developed as well. Sometimes they did, allmost the exact same things as I had done, slightly diffrent, more proffesional looking, but basically, they had drawn the same conclusions that I had done. In short, each upgrade of my tool wrecked much of my previous work, if I wanted to upgrade the tool, or that the older objects could not account for the new realities, and larger data sets. Or that an object could not do, efficiently, a few task it was not espesially designed for. My solution : Get rid of the VCL (similar to MFC) and start all over at the lower level. I started with the TObject foundation. This basically allowed me to use the stringfunctionality, and the memorymanager, and also the OOP functionality. After some years with Delphi in this state, I now had learned a lot of new things. I learned about the windows API, and I learned that some of the Graphical objects of Delphi was flawed. I learned enough to see that allthough the Delphi memorymanager was fast, it could be made faster for the spesific task I was doing, and I also found errors in it. At this stage, I was beginning to see slowdowns. I was in need of a rewrite anyway, and so, when I took not that much functionality away from Delphi, why not redo it in asm. In Basm? This was my first thought. Then I discovered RosAsm. What I discovered, ran counter to everything I thought I knew, but also, the BU_ASM reflected in many ways a lot of my own thinking. You know, my memorymanager took 3 days to get to a state where it could start having some use. It has been upgraded and reamped much since then, so maybe as much as a month or maybe two have been spent with it in total, but it was useful after only 3 days. Since then, I have been in awe. Assembly programming with RosAsm is way less trouble than doing Delphi. And the code I write, that is even maybe not very good compared to compiler output, is much faster than the Delphi version of my library. In fact, the Delphi version ran best on earlier hardware, and each time I run it now, I am amazed that it does not run many times faster, because I now have many times faster hardware. It is simply horrible, compared to the newbie RosAsm assembly code. So what can I say? How can I not be very eager to state and restate this incredible diffrence? In fact, I may have just gotten lost in a endless loop, because I am now thinking of rewriting my RosAsm stuff :))) It can be done seriously better and faster. What to do? Follow my sickness of striving for perfection, or just go out the back and shot myself :)) My idea, was to create a GUI that could be used as well for a game as for a Desktop app. This is as nonspesific as fully possible I guess. I got the idea when playing now ancient "unreal tournament". It was such an awsome game, but had an incredible sucky userinterface. This strange thing puzzled me. Why cannot theese incredible game programmers be able to create a GUI? And lo and behold, even now in Battlefield 2, which is technically, and at least visually, some of the most awsome game I have seen, the UI, is still incredible sucky, have plenty of bugs, and a latancy worthy an old dement. I mean, on my new hardware, I have 1000 megabyte of fast ram, nvidia chipsset, a AMD 64 3700+ and a whole megabyte of cache, and I still have to wait for the UI to respond? :)))) The WHOLE of RosAsm fits in the cache !! 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). 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 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. 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. 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. (Puh). 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. > 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. > The solution? Write the majority of the program in C/C++/ObjC, > and then *embed* Scheme into C. Write the AI part in Scheme, and > everything else in C (or C++). Because most Schemes are > interpreters, this gives even a greater advantage as you no > longer have to compile your program to make a significant > change. So to change the AI to your chess game or > whatnot would not require 5 minutes of recompiling, while > you can still write in portable GTK+ library (or wxWidgets > for C++), which would give you somewhat portability, easy > modifications, > and using the languages to their maximum potential. > > Need a quick-and-dirty solution? Use TCL/tk (for Unix/Linux > users) or Visual Basic (for you Windows users) which lets you > create a GUI in minutes. (and in the case of TCL/tk, no need > for a compile cycle makes it a joy. I personally haven't done > VB so... yeah...) Use perl for a quicky text application, > or awk or sed even if it is simple enough. Batch or shell files > are great here too. > > And with Visual Basic.NET avaliable, you can mix VB.Net code > with C# on the new .NET or Mono platforms. And for *nix, TCL > and perl interphase with C/C++ fine (just like Scheme example) > > Portability a major concern? Use Java, Python, Ruby. > > Web development? PHP, ASP.NET, with some sort of SQL library. > > Prototyping? Python, Obj-C (Cocoa or GNUstep), or VB again. > Use a point-and-click wizard avaliable for and impress your client. > If They don't like how the window looks, it is a point-and-click away. > > This is why I cannot believe there to be one "windows application" > tool, > because there will always be a case where one of these tools will > out-perform another tool. > > I don't believe in a "one language to rule them all" to any programming > problem. 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. My main view here is that the reason we have so many diffrent HLLs is because we rejected asm, which would solve our problems in much lesser time then to test out and learn all these other tools. Each programmer tried a HLL, gave it up, to find something better. Because he wrongfully thought, because of propaganda, that there are free lunches in programming. The only free lunch is to start with a good assembler, and for windows, the best one is called RosAsm, and this is an OBJECTIVE truth. The only thing that doesnt make me hate myself for saying it, is because it is true, plain and simple. This time its not just hype, its the OVERWHELMING facts. > > --Dragontamer >
From: Dragontamer on 6 Feb 2006 09:59 \\\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. > > Yes. This reminds me of many things. It espesially reminds me of the later > years focus on "efficiency", inside, it seems to me, like the whole of > sosiety. Short term profit thinking. > Asm may not _seem_ best short term language, because it has a rather steep > _initial_ learning curve, > but it is more then ten times as efficient, long term. And HLLs need you > to learn a lot as well to use them. > > 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 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. [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. 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. 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) [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) 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. > 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. 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. 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. > 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... I don't need an installer for my C/C++ stuff, nor python or whatever I use. > 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". Not really anything assembly can speed up. > 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. Beyond that of even Nasm's macro capabilities. In fact, Scheme and Lisp programming is mainly building your own "language" above the base. > > 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. > 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. --Dragontamer (was in rush... gtg for now)
From: Dragontamer on 6 Feb 2006 09:59 \\\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. > > Yes. This reminds me of many things. It espesially reminds me of the later > years focus on "efficiency", inside, it seems to me, like the whole of > sosiety. Short term profit thinking. > Asm may not _seem_ best short term language, because it has a rather steep > _initial_ learning curve, > but it is more then ten times as efficient, long term. And HLLs need you > to learn a lot as well to use them. > > 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 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. [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. 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. 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) [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) 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. > 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. 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. 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. > 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... I don't need an installer for my C/C++ stuff, nor python or whatever I use. > 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". Not really anything assembly can speed up. > 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. Beyond that of even Nasm's macro capabilities. In fact, Scheme and Lisp programming is mainly building your own "language" above the base. > > 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. > 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. --Dragontamer (was in rush... gtg for now)
From: Frank Kotler on 6 Feb 2006 10:27
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? > If you look at the rest of the features themselves, Nasm and Fasm > are nearly clones. Well... Fasm has 64-bit support, Nasm doesn't. Fasm has "direct-to-executable" output formats "built in" that reqire an external macro file to do (conveniently) with Nasm. Nasm has more "exotic" output formats - as86, aout, aoutb... even weirder ones... One that will soon be useful is "macho" (for x86 Macs). It isn't in a released version yet (get it off CVS if you need it). I think I heard that Fasm will do "macho" (???). I'm under the impression that Fasm won't do OMF (Nasm's "-f obj"). Is that correct? Either will do the "common" formats that you're actually likely to want... (except, possibly, the Borland users) > So just stick with Nasm for now (really) until you start writing > complex macros, He already needs a better "invoke" macro... > and then try Fasm vs Nasm. You honestly won't find a big > difference till then... Lessee... Nasm specifies output format on the command-line. Fasm specifies it in the source. (an "ideal" assembler might allow either) Nasm has other command-line options... The vaunted "-O" switch just enables stuff that Fasm does by default (I think ???). We can "preprocess only" or "assemble only" (skipping the preprocessor). We can produce a list file... The makefile for Chuck's "axgame.asm" looks like it produces a list file, but only produces a "usage" message for me. How *do* you produce a list file from Fasm? (if at all...) The way sections are declared is different. AFAIK, they just look different - you can do all the same things with either(?). Fasm "remembers" what size you said a variable is, Nasm does not. With Fasm, you can do: foo dd 1 .... inc [foo] Nasm would complain that the size of the operation isn't specified - you have to say "inc dword [foo]"... There's "resb" (etc.) vs "rb" (etc.), but that's trivial. Probably more differences... those are the ones I can think of. Besides... > Actually, I prefer how Fasm handle's structures to Nasm... but it is > through a macro (kinda... not really...) Mmmm... structures are apparently controversial... Nasm does structures via a macro, but it's a built-in macro. Or you can use the "xstruc" macros (available at SF in the "contributions" section) I haven't looke at 'em - the "built-in" stuff works okay for me. Of course, they aren't "true" structures. I don't know if Fasm's structures are "true" or not. (I suspect only HLA has "true" structures :) > As for the future: Fasm is much more activly developed than Nasm. Right. Nasm's good enough that it doesn't *need* a new version every few days! :) > So more features are bound to come to Fasm. Arguably, it already blows Nasm away. (I count that 64-bit support as a "high value" feature, even though I have no use for it at the moment) At *some* point, "more features" is *not* an improvement! I don't think Fasm's there yet... another matter of opinion, I suppose. > 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! I'm a Nasm bigot... I mean "devout Nasmist"... but that Fasm looks awfully good! Best, Frank |