From: ?a/b on
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
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

\\\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

\\\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
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