OK, I know this thread will degenerate quite quickly but there is just
a chance that the first wave of responses will have some value. I am
not new to assemby language but it has been decades since I indulged
in that particular flavor of masochism. At that time they were 8 bit
devices that were very limited in function but readily accessible - it
was possible to be familiar with almost every byte of the OS (securely
locked away on ROM - no service packs to deal with in those days -
they even threw in a basic interpreter). More importantly, there was
often a choice of one when it came to editor/assemblers.

When I first surveyed the availability of assemblers, I was pleasantly
surprised at the many that out there - I was even more pleased at
their price. So I subscribed to this newsgroup, hoping to glean which
assembler was most popular and thus the best supported by fellow
mosochists. The few books on the subject suggested that it would
probably be NASM. Your topics of discussion, while rarely condenming
NASM, had very little to say on that product.

What am I looking for in an assembler? Well, I do not have any
predeliction against the HLA approach, seeing that as being no less
purist than taking advantage of a comprehensive library of macros.
However, given my rustiness with assembler and my niavety with X86
machine code, I suspect that the ability to integrate with a symbolic
debugger might be more productive than speedier code generation.

I would hope that most of my programs would be in the Win32
environment. Though, some would use the console interface.

So, which is the best: GoASM, NASM, MASM32, RoASM? or did I miss the
best one? BTW, I did scan the FAQ but the latest version is almost
four years old and i suspect that the field of Win32 ASM is a rapidly
changing field at the moment.

Thanks in anticipation,

Michael

"WillofIrony" <spamtrap@crayne.org> wrote in message 
news:1191768951.559261.226510@o3g2000hsb.googlegroups.com...

> So, which is the best: GoASM, NASM, MASM32, RoASM? or did I miss the
> best one? BTW, I did scan the FAQ but the latest version is almost
> four years old and i suspect that the field of Win32 ASM is a rapidly
> changing field at the moment.

There are 6 assemblers that one might consider: FASM, GAS, GoASM,
MASM, NASM, and YASM.  The others aren't 64-bit capable and are
irrelevant.

-- 
write(*,*) transfer(0.64682312090346863D-153,(/'X'/));end

On Oct 7, 4:48 pm, "James Van Buskirk"  <spamt...@crayne.org> wrote:
> "WillofIrony" <spamt...@crayne.org> wrote in message
>
> news:1191768951.559261.226510@o3g2000hsb.googlegroups.com...
>
> > So, which is the best: GoASM, NASM, MASM32, RoASM? or did I miss the
> > best one? BTW, I did scan the FAQ but the latest version is almost
> > four years old and i suspect that the field of Win32 ASM is a rapidly
> > changing field at the moment.
>
> There are 6 assemblers that one might consider: FASM, GAS, GoASM,
> MASM, NASM, and YASM.  The others aren't 64-bit capable and are
> irrelevant.
>
> --
> write(*,*) transfer(0.64682312090346863D-153,(/'X'/));end

I would recommend FASM.

I wrote a lot of Fortran programs for console interface execution
under Windows and DOS.

I call a library of about 130 assembler routines to do useful things,
including full colour and cobtrol screen TUI interface. (For native
Windows execution, I just change the library to a same-routine API
calling library).

All the assembler routines were written for 16-bit register use and
were/are assembled (originally by the 1982 MS assembler), by the
1990-1999 MS assembler, and work perfectly in the DOS-in-windows and
DOS environments on 386 and up Intel and Athlon cpu's to date (single
core so far).

Although my experience in almost entirely 16 bit usage, I am sure 32-
bit usage of the same assembler, using the extension register syntax,
would alos be just as useful.

I note that any disassembly I have recently performed yields 16-bit
code that can be re-assembled with this assembler. So the major usage
around is still 16-bit.

But I have to assume any intended 64-bit usage would require a
different, newer assembler version.

WillofIrony <spamtrap@crayne.org> wrote:
>[etc...]
> 
> So, which is the best: GoASM, NASM, MASM32, RoASM? or did I miss the
> best one? BTW, I did scan the FAQ but the latest version is almost
> four years old and i suspect that the field of Win32 ASM is a rapidly
> changing field at the moment.
> 
> Thanks in anticipation,
> 
> Michael
> 
 I use NASM because it has a simple, consistant Intel type syntax,
 and because it works well for me (so far). 

 The 'offset(label)'  command is never needed with NASM. 
 NASM doesn't do type checking (an advantage from my viewpoint). 

 There are recent 64 bit CPU versions of NASM out there. 

 Steve            www.ml1compiler.org

Steven Nichols  <spamtrap@crayne.org> �crivait news:fec14m$v3e$1
@venture.svpal.org:

> I use NASM because it has a simple, consistant Intel type syntax,
>  and because it works well for me (so far). 
> 
>  The 'offset(label)'  command is never needed with NASM. 
>  NASM doesn't do type checking (an advantage from my viewpoint).

You are right. The most important point with choosing an Assembler,
is with selecting one conforming to the actual Syntax, as hopefully
redefined by NASM. Once the Assemblers conforming to the actual
Syntax are known, the final choice is simplified down to the question:

"What do i mean to program with it?".

Some Assemblers are a better choice for this and for that.


Betov.

< http://rosasm.org >

On Oct 7, 7:55 am, WillofIrony  <spamt...@crayne.org> wrote:
> OK, I know this thread will degenerate quite quickly but there is just
> a chance that the first wave of responses will have some value. I am
> not new to assemby language but it has been decades since I indulged
> in that particular flavor of masochism. At that time they were 8 bit
> devices that were very limited in function but readily accessible - it
> was possible to be familiar with almost every byte of the OS (securely
> locked away on ROM - no service packs to deal with in those days -
> they even threw in a basic interpreter). More importantly, there was
> often a choice of one when it came to editor/assemblers.

A bit outdated, but you might want to read:
http://webster.cs.ucr.edu/AsmTools/WhichAsm.html

>
> When I first surveyed the availability of assemblers, I was pleasantly
> surprised at the many that out there - I was even more pleased at
> their price. So I subscribed to this newsgroup, hoping to glean which
> assembler was most popular and thus the best supported by fellow
> mosochists. The few books on the subject suggested that it would
> probably be NASM. Your topics of discussion, while rarely condenming
> NASM, had very little to say on that product.

NASM was very popular when the project was first begun in the middle
to late 1990s. When its authors abandoned it, it began a slow decline
in popularity (with many people switching to FASM, instead). Recently,
there has been a group of people working on it again, so we're
starting to hear more about it.

NASM's primary feature is that it's portable. It runs on just about as
many OSes as Gas (it's written in C, so it will even run on some non-
x86 platforms  [though still generating only x86 code], however, I
don't know about endian issues).

NASM's biggest drawback is that it is a bit slow.


>
> What am I looking for in an assembler? Well, I do not have any
> predeliction against the HLA approach, seeing that as being no less
> purist than taking advantage of a comprehensive library of macros.
> However, given my rustiness with assembler and my niavety with X86
> machine code, I suspect that the ability to integrate with a symbolic
> debugger might be more productive than speedier code generation.

If you want to integrate with a symbolic debugger, I would recommend
against NASM (and derivatives, such as YASM) and FASM. They do not
generate symbolic debug information.  Your main options MASM (under
Windows), Gas (preferably using Intel syntax) under Linux, or HLA.


>
> I would hope that most of my programs would be in the Win32
> environment. Though, some would use the console interface.

I would recommend MASM or HLA for this purpose. In addition to
symbolic debugger capabilities, the bulk of the tutorials you're going
to find for Win32 programming (e.g., http://webster.cs.ucr.edu/Page_win32/index.html)
are going to use MASM or HLA).


hLater,
Randy Hyde

"rhyde@cs.ucr.edu"  <spamtrap@crayne.org> �crivait 
news:1191858039.614008.122400@r29g2000hsg.googlegroups.com:

> A bit outdated, but [...]
> 
> If you want to integrate with a symbolic debugger, I would recommend
> against NASM (and derivatives, such as YASM) and FASM. They do not
> generate symbolic debug information.  Your main options MASM (under
> Windows), Gas (preferably using Intel syntax) under Linux, or HLA.

The problem, when being late on an answer, is that it becomes more
and more difficult hide the reality, which is, for example, that
the OP might have already taken a look by himself, and seen that
RosAsm is the one and only Assembler, coming with an integrated
Source Level Debugger, dynamic break-points, memory scanner, and
all that stuff.


Betov.

< http://rosasm.org >

On Mon, 08 Oct 2007 08:40:39 -0700
"rhyde@cs.ucr.edu"  <spamtrap@crayne.org> wrote:

> If you want to integrate with a symbolic debugger, I would recommend
> against NASM (and derivatives, such as YASM) and FASM. They do not
> generate symbolic debug information.

This is true for many of the output formats, but it is not true for
either elf32 or elf64, both of which generate symbolic debug
information in stabs format.

-- Chuck

rhyde@cs.ucr.edu wrote:
> 
> NASM's biggest drawback is that it is a bit slow.
> 

Got any specific benchmarks?  I have spent quite a bit of time getting 
rid of NASM performance issues lately, but if there are others, I'd like 
to know about them.

	-hpa

rhyde@cs.ucr.edu wrote:

....
> NASM was very popular when the project was first begun in the middle
> to late 1990s. When its authors abandoned it, it began a slow decline
> in popularity (with many people switching to FASM, instead).

Do you have any evidence for this decline in popularity? The download 
counters on SourceForge don't show it. I'm not aware of any Linux 
distros dropping it...

> Recently,
> there has been a group of people working on it again, so we're
> starting to hear more about it.
> 
> NASM's primary feature is that it's portable. It runs on just about as
> many OSes as Gas (it's written in C, so it will even run on some non-
> x86 platforms  [though still generating only x86 code], however, I
> don't know about endian issues).

Nasm is *supposed* to cover endian issues - generating little-endian 
output, even if run on a big-endian machine. I wouldn't guarantee this 
is 100%, but I haven't *heard* of any issues.. not many people doing it, 
I imagine...

> NASM's biggest drawback is that it is a bit slow.

Yeah. Generally not a "problem", but it isn't too fast. I havent done 
any speed testing on recent versions, but it *should* be a lot faster. 
When we get the bugs out of the lastest versions, we'll worry about speed...

Best,
Frank

On Sun, 07 Oct 2007 14:55:51 -0000, WillofIrony  <spamtrap@crayne.org>
wrote:
<snip>
>I would hope that most of my programs would be in the Win32
>environment. Though, some would use the console interface.
>
>So, which is the best: GoASM, NASM, MASM32, RoASM? or did I miss the
>best one? BTW, I did scan the FAQ but the latest version is almost
>four years old and i suspect that the field of Win32 ASM is a rapidly
>changing field at the moment.
>

I've been very happy using MASM32 for my Win32 code, everything from
small console utilities to a very large application.  MASM32 has a few
quirks, but so far nothing I couldn't easily adapt to.  I suspect
every assembler has its quirks, and it's just a matter of what you can
get used to.  For example, when MASM32 reports error line numbers,
it apparently only allows one word for the number since it wraps at
65535.  There are also some quirks in handling labels, and in what
can be EQUated to what.  Stuff like that.

But the big issue for me is/was the general appearance of the code:
Does it "feel right" when you are looking at it?  Having started out
with the Z80 many years ago, I was used to memory references 
*always* being in brackets.  Then (also many years ago) I started
coding on the 8088 with MASM, and had to adjust to the utterly
insane system of no brackets for memory, and OFFSET for pointers.
(What *were* they thinking with that one??!!!)   But after a while I
got used to it, and now it seems perfectly normal, and everything else
looks a bit strange.  So whichever format you end up with is probably
no big deal, since you'll just get used to it.

Best regards,



Bob Masta
 
            DAQARTA  v3.50
Data AcQuisition And Real-Time Analysis
           www.daqarta.com
Scope, Spectrum, Spectrogram, Signal Generator
    Science with your sound card!

Bob Masta wrote:

....
> I suspect
> every assembler has its quirks, and it's just a matter of what you can
> get used to.

Exactly. *All* software has limitations - the one whose limitations 
don't bother you is "best".

> Does it "feel right" when you are looking at it?  Having started out
> with the Z80 many years ago, I was used to memory references 
> *always* being in brackets.  Then (also many years ago) I started
> coding on the 8088 with MASM, and had to adjust to the utterly
> insane system of no brackets for memory, and OFFSET for pointers.
> (What *were* they thinking with that one??!!!)

:) The authors of Nasm had the same thought. One of the "real" 
differences... Nasm, Fasm, and RosAsm do it "the z80 way" (if we can 
call it that). I think GoAsm and PoAsm (Wasm from OpenWatcom, too?) do 
it the "Masm way" with "offset", "ptr", etc.

> But after a while I
> got used to it, and now it seems perfectly normal, and everything else
> looks a bit strange.  So whichever format you end up with is probably
> no big deal, since you'll just get used to it.

Yup.

Best,
Frank

Frank Kotler  <spamtrap@crayne.org> �crivait news:QL3Pi.1646$yJ2.448
@trndny01:

> I think GoAsm [...] do it the "Masm way" with "offset", "ptr", etc.

No. GoAsm is simply "redundant". That is, is expects such
notation, whereas it could as well been done without. I
never understood why Jeremy did it that way, but it seems
to please some.

So, it may look like MASM, even though it really belongs to
the "NASM-family Syntaxes". At the end, we could say that it
is the one, at the extreeme other end, from the confusions
introduced by the out of logic MASM notation.


Betov.

< http://rosasm.org >

On Oct 9, 12:33 pm, "H. Peter Anvin"  <spamt...@crayne.org> wrote:
> rh...@cs.ucr.edu wrote:
>
> > NASM's biggest drawback is that it is a bit slow.
>
> Got any specific benchmarks?  I have spent quite a bit of time getting
> rid of NASM performance issues lately, but if there are others, I'd like
> to know about them.

If the change is "lately" then the answer is no.
My bechmarks are a year or two old at this point.
hLater,
Randy Hyde

On Oct 9, 1:26 pm, Frank Kotler  <spamt...@crayne.org> wrote:
> rh...@cs.ucr.edu wrote:
>
> ...
>
> > NASM was very popular when the project was first begun in the middle
> > to late 1990s. When its authors abandoned it, it began a slow decline
> > in popularity (with many people switching to FASM, instead).
>
> Do you have any evidence for this decline in popularity? The download
> counters on SourceForge don't show it. I'm not aware of any Linux
> distros dropping it...

I have *soooo* come to the conclusion that these "download counters"
are completely bogus. If they were *halfway* true, we'd see a *lot*
more people programming in assembly language these days. Either those
counters are being tickled by automata, or 90% of the world downloads
software and just throws it away.

As for distros dropping it...
That's an even less reliable metric than a download counter. Every
distro I've gotten has contained *tons* of software I've never used
(indeed, NASM being one of them -- as I've only used NASM under
Windows).

> I imagine...
>
> > NASM's biggest drawback is that it is a bit slow.
>
> Yeah. Generally not a "problem", but it isn't too fast. I havent done
> any speed testing on recent versions, but it *should* be a lot faster.
> When we get the bugs out of the lastest versions, we'll worry about speed...

The right attitude, for sure.
hLater,
Randy Hyde

On Oct 8, 11:02 am, Betov  <spamt...@crayne.org> wrote:
> "rh...@cs.ucr.edu"  <spamt...@crayne.org> �crivaitnews:1191858039.614008.122400@r29g2000hsg.googlegroups.com:
>
> > A bit outdated, but [...]
>
> > If you want to integrate with a symbolic debugger, I would recommend
> > against NASM (and derivatives, such as YASM) and FASM. They do not
> > generate symbolic debug information.  Your main options MASM (under
> > Windows), Gas (preferably using Intel syntax) under Linux, or HLA.
>
> The problem, when being late on an answer, is that it becomes more
> and more difficult hide the reality, which is, for example, that
> the OP might have already taken a look by himself, and seen that
> RosAsm is the one and only Assembler, coming with an integrated
> Source Level Debugger, dynamic break-points, memory scanner, and
> all that stuff.

And, if he's looked closer, he probably discovered that you cannot
link in object files or produce object file that can be linked with
other code, and so he probably passed it up in favor of a better tool.
hLater,
Randy Hyde

randyhyde@earthlink.net wrote:
> On Oct 9, 1:26 pm, Frank Kotler  <spamt...@crayne.org> wrote:
> 
>>rh...@cs.ucr.edu wrote:
>>
>>...
>>>NASM was very popular when the project was first begun in the middle
>>>to late 1990s. When its authors abandoned it, it began a slow decline
>>>in popularity (with many people switching to FASM, instead).
>>
>>Do you have any evidence for this decline in popularity? The download
>>counters on SourceForge don't show it. I'm not aware of any Linux
>>distros dropping it...
> 
> 
> I have *soooo* come to the conclusion that these "download counters"
> are completely bogus. If they were *halfway* true, we'd see a *lot*
> more people programming in assembly language these days. Either those
> counters are being tickled by automata, or 90% of the world downloads
> software and just throws it away.
> 
> As for distros dropping it...
> That's an even less reliable metric than a download counter. Every
> distro I've gotten has contained *tons* of software I've never used
> (indeed, NASM being one of them -- as I've only used NASM under
> Windows).

Okay. So what *is* your evidence for Nasm's slow decline in popularity?

Best,
Frank

On Oct 10, 5:59 pm, Frank Kotler  <spamt...@crayne.org> wrote:
> randyh...@earthlink.net wrote:
> > On Oct 9, 1:26 pm, Frank Kotler  <spamt...@crayne.org> wrote:
>
> >>rh...@cs.ucr.edu wrote:
>
> >>...
> >>>NASM was very popular when the project was first begun in the middle
> >>>to late 1990s. When its authors abandoned it, it began a slow decline
> >>>in popularity (with many people switching to FASM, instead).
>
> >>Do you have any evidence for this decline in popularity? The download
> >>counters on SourceForge don't show it. I'm not aware of any Linux
> >>distros dropping it...
>
> > I have *soooo* come to the conclusion that these "download counters"
> > are completely bogus. If they were *halfway* true, we'd see a *lot*
> > more people programming in assembly language these days. Either those
> > counters are being tickled by automata, or 90% of the world downloads
> > software and just throws it away.
>
> > As for distros dropping it...
> > That's an even less reliable metric than a download counter. Every
> > distro I've gotten has contained *tons* of software I've never used
> > (indeed, NASM being one of them -- as I've only used NASM under
> > Windows).
>
> Okay. So what *is* your evidence for Nasm's slow decline in popularity?

Well, having watched a lot of people shift from NASM to FASM over the
years?
And it's not like there are a *lot* of new people learning assembly
every year to replinish those lost.
hLater,
Randy Hyde

"Betov" <spamtrap@crayne.org> wrote in message 
news:XnF99C3CC9C1E03Fbetovfreefr@212.27.60.40...
> "rhyde@cs.ucr.edu"  <spamtrap@crayne.org> �crivait
> news:1191858039.614008.122400@r29g2000hsg.googlegroups.com:
>
>> A bit outdated, but [...]
>>
>> If you want to integrate with a symbolic debugger, I would recommend
>> against NASM (and derivatives, such as YASM) and FASM. They do not
>> generate symbolic debug information.  Your main options MASM (under
>> Windows), Gas (preferably using Intel syntax) under Linux, or HLA.
>
> The problem, when being late on an answer, is that it becomes more
> and more difficult hide the reality, which is, for example, that
> the OP might have already taken a look by himself, and seen that
> RosAsm is the one and only Assembler, coming with an integrated
> Source Level Debugger, dynamic break-points, memory scanner, and
> all that stuff.

     Doesn't matter what add-me-ons RosAsm (name stolen from another 
development group) features.  If it does not output exactly what the 
programmer specifies, then it is not an assembler.  Can anyone tell me if 
his program does that?  Ratch

Ratch wrote:

> 
> "Betov" <spamtrap@crayne.org> wrote in message
> news:XnF99C3CC9C1E03Fbetovfreefr@212.27.60.40...
>> "rhyde@cs.ucr.edu"  <spamtrap@crayne.org> �crivait
>> news:1191858039.614008.122400@r29g2000hsg.googlegroups.com:
>>
>>> A bit outdated, but [...]
>>>
>>> If you want to integrate with a symbolic debugger, I would recommend
>>> against NASM (and derivatives, such as YASM) and FASM. They do not
>>> generate symbolic debug information.  Your main options MASM (under
>>> Windows), Gas (preferably using Intel syntax) under Linux, or HLA.
>>
>> The problem, when being late on an answer, is that it becomes more
>> and more difficult hide the reality, which is, for example, that
>> the OP might have already taken a look by himself, and seen that
>> RosAsm is the one and only Assembler, coming with an integrated
>> Source Level Debugger, dynamic break-points, memory scanner, and
>> all that stuff.
> 
>      Doesn't matter what add-me-ons RosAsm (name stolen from another
> development group) features.  If it does not output exactly what the
> programmer specifies, then it is not an assembler.  Can anyone tell me
> if his program does that?  Ratch

Like some other assemblers it (RosAsm) too adds a certain amount
of "overhead" to construct a complete executable file. FASM does this
too. Strictly speaking these header data have not been generated from
what the programmer wrote, but nevertheless they are so basic to
successfully executing the object file that they are not usually
regarded as separating a assembler from a compiler.

With other assemblers like NASM, MASM etc., a linker will do this job.

Of course, like most other assemblers like MASM, FASM etc., RosAsm
allows you to use HLL-like macros like IF, WHILE etc., which expand to
generate more code than is immediately visible in the source, but since
nearly all modern assemblers have this ability, it too is usually not
regarded as separating a assembler from a compiler.

What can reasonably be regarded as a "grey area" between assembler and
compiler output, are the built in HLL statements like MASM's INVOKE,
IF, WHILE etc., HLA's HLL control constructs, RosAsm's Pre-Parsers and
others.

In the end what defines an assembler is that, regardless of whether it
supports HLL/VHLL statements, it has at least one operating mode which
allows access to all the machine insructions of the target platform,
and allows creation of object files with exactly one-to-one
correspondence between source and object code, if so desired by the
programmer.

An HLL does not have this ability, i.e., one or more platform specific
instructions are always not directly specifiable and one-to-one
correspondence between source code and output is not possible.

santosh  <spamtrap@crayne.org> �crivait news:filtra$kfm$1
@registered.motzarella.org:

> What can reasonably be regarded as a "grey area" between assembler and
> compiler output, are the built in HLL statements like MASM's INVOKE,
> IF, WHILE etc., HLA's HLL control constructs, RosAsm's Pre-Parsers and
> others.

Right for RosAsm's pre-parsers. They are open door to real HLL(s),
and the fact of being trigered on user's decision leaves the whole
thing untouched, as an Assembler: The red line remains under user's
control. For the other things, they belong to HLL, whatever way we
look at them: An HLL will keep an HLL, even with Asm Inline available
(What HLA doesn't even provide).


Betov.

< http://rosasm.org >

Ratch asked:

> "Betov" wrote:
....
>> The problem, when being late on an answer, is that it becomes more
>> and more difficult hide the reality, which is, for example, that
>> the OP might have already taken a look by himself, and seen that
>> RosAsm is the one and only Assembler, coming with an integrated
>> Source Level Debugger, dynamic break-points, memory scanner, and
>> all that stuff.

> Doesn't matter what add-me-ons RosAsm (name stolen from another
> development group) features.  If it does not output exactly what the
> programmer specifies, then it is not an assembler.
> Can anyone tell me if his program does that?  Ratch

RosAsm produces only the PE-header by itself, everthing else incl. the
decision for using HL-structs&macros is under control of the programmer.

And the often heard missing Link-feature in RosAsm is just valid for HLL
C-source LIBs, I don't have any problems to merge KESYS-produced binaries
into a RosAsm created executable.

__
wolfgang

"Betov" <spamtrap@crayne.org> wrote in message 
news:XnF99C3CC9C1E03Fbetovfreefr@212.27.60.40...
> "rhyde@cs.ucr.edu"  <spamtrap@crayne.org> �crivait
> news:1191858039.614008.122400@r29g2000hsg.googlegroups.com:
>
>> A bit outdated, but [...]
>>
>> If you want to integrate with a symbolic debugger, I would recommend
>> against NASM (and derivatives, such as YASM) and FASM. They do not
>> generate symbolic debug information.  Your main options MASM (under
>> Windows), Gas (preferably using Intel syntax) under Linux, or HLA.
>
> The problem, when being late on an answer, is that it becomes more
> and more difficult hide the reality, which is, for example, that
> the OP might have already taken a look by himself, and seen that
> RosAsm is the one and only Assembler, coming with an integrated
> Source Level Debugger, dynamic break-points, memory scanner, and
> all that stuff.

     Early or late, time does not obfuscate the  truth.  It appears that a 
lot of folks have looked at Rosasm (name stolen from another development 
group) and found it wanting.  Is it able to generate output code exactly the 
way the programmer specified it to be?  Ratch 

"santosh" <spamtrap@crayne.org> wrote in message 
news:filtra$kfm$1@registered.motzarella.org...
> Ratch wrote:
>
>>
>> "Betov" <spamtrap@crayne.org> wrote in message
>> news:XnF99C3CC9C1E03Fbetovfreefr@212.27.60.40...
>>> "rhyde@cs.ucr.edu"  <spamtrap@crayne.org> �crivait
>>> news:1191858039.614008.122400@r29g2000hsg.googlegroups.com:
>>>
>>>> A bit outdated, but [...]
>>>>
>>>> If you want to integrate with a symbolic debugger, I would recommend
>>>> against NASM (and derivatives, such as YASM) and FASM. They do not
>>>> generate symbolic debug information.  Your main options MASM (under
>>>> Windows), Gas (preferably using Intel syntax) under Linux, or HLA.
>>>
>>> The problem, when being late on an answer, is that it becomes more
>>> and more difficult hide the reality, which is, for example, that
>>> the OP might have already taken a look by himself, and seen that
>>> RosAsm is the one and only Assembler, coming with an integrated
>>> Source Level Debugger, dynamic break-points, memory scanner, and
>>> all that stuff.
>>
>>      Doesn't matter what add-me-ons RosAsm (name stolen from another
>> development group) features.  If it does not output exactly what the
>> programmer specifies, then it is not an assembler.  Can anyone tell me
>> if his program does that?  Ratch
>
> Like some other assemblers it (RosAsm) too adds a certain amount
> of "overhead" to construct a complete executable file. FASM does this
> too. Strictly speaking these header data have not been generated from
> what the programmer wrote, but nevertheless they are so basic to
> successfully executing the object file that they are not usually
> regarded as separating a assembler from a compiler.

     The "boiler plate" that an assembler adds to its output file to make it 
a object file is not part of the user program   I should have been more 
specific is defining as assembler as a processor that can outpt the user 
written code exactly the way the programmer wrote it.

>
> With other assemblers like NASM, MASM etc., a linker will do this job.
>
> Of course, like most other assemblers like MASM, FASM etc., RosAsm
> allows you to use HLL-like macros like IF, WHILE etc., which expand to
> generate more code than is immediately visible in the source, but since
> nearly all modern assemblers have this ability, it too is usually not
> regarded as separating a assembler from a compiler.

     That's right.  Just because an assembler has a full or limited 
capability to use HLL, does not disqualify it from being an assembler. 
Unless it does NOT allow the programmer to ignore HLL and code instructions 
and data on a one to one basis.

>
> What can reasonably be regarded as a "grey area" between assembler and
> compiler output, are the built in HLL statements like MASM's INVOKE,
> IF, WHILE etc., HLA's HLL control constructs, RosAsm's Pre-Parsers and
> others.

     Why gray?  Those directives don't have to be used, do they?

>
> In the end what defines an assembler is that, regardless of whether it
> supports HLL/VHLL statements, it has at least one operating mode which
> allows access to all the machine insructions of the target platform,
> and allows creation of object files with exactly one-to-one
> correspondence between source and object code, if so desired by the
> programmer.

     Yes, that is exactly the way I define an assembler.  Not Betov, 
however.  He gets tangled up in whether a assembler has certain features or 
not.

>
> An HLL does not have this ability, i.e., one or more platform specific
> instructions are always not directly specifiable and one-to-one
> correspondence between source code and output is not possible.

     Agreed.  Ratch

P.S. I still have not received a definitive answer as to whether Rosasm 
(name stolen from another development group) can always generate code on a 
one to one basis. 

"Ratch"  <spamtrap@crayne.org> �crivait 
news:vdGdnVoCLaQPeNPanZ2dnUVZ_sejnZ2d@comcast.com:

> I still have not received a definitive answer as to whether Rosasm 
> (name stolen from another development group)

I am a bit surprised that the censorship of CLAX failed to
apply, here, about insults coming from a guy who is perfectly
flaged and known for what he is.

For the whole story, about how and why ReactOS is dead, the
lurkers will read:

< http://betov.free.fr/ReactOS.html >


Betov.

< http://rosasm.org >

"Betov" <spamtrap@crayne.org> wrote in message 
news:XnF99F7DA3F86341betovfreefr@212.27.60.37...
> "Ratch"  <spamtrap@crayne.org> �crivait
> news:vdGdnVoCLaQPeNPanZ2dnUVZ_sejnZ2d@comcast.com:
>
>> I still have not received a definitive answer as to whether Rosasm
>> (name stolen from another development group)
>
> I am a bit surprised that the censorship of CLAX failed to
> apply, here, about insults coming from a guy who is perfectly
> flaged and known for what he is.

     The censorship of CLAX did kick in.  That is why I moved one of my 
responses to ALA.  Ratch

>
> For the whole story, about how and why ReactOS is dead, the
> lurkers will read:
>
> < http://betov.free.fr/ReactOS.html >
>
>
> Betov.
>
> < http://rosasm.org >
>
> 

On Nov 30, 3:15 am, "Ratch"  <spamt...@crayne.org> wrote:

 ...

> Just because an assembler has a full or limited
> capability to use HLL, does not disqualify it from
> being an assembler. Unless it does NOT allow the
> programmer to ignore HLL and code instructions
> and data on a one to one basis.

But is it a hll with an inline assembler or an
assembler with an inline hll?

I use the inline assembler of FreeBasic because FreeBasic
allows me to use the modern hardware for graphics but I
can still write simple assembler code if I so wish.

> > What can reasonably be regarded as a "grey area"
> > between assembler and compiler output, are the
> > built in HLL statements like MASM's INVOKE, IF,
> > WHILE etc., HLA's HLL control constructs, RosAsm's
> > Pre-Parsers and others.

Still if the actual output is predictable, and what you
want, how is that different from the predictable output
of a mnemonic used to produce a single machine code
instruction? Isn't it a kind of short hand which indeed
mnemonics are for the actual numbers? The only issue I
had with the "grey area" was it wasn't spelt out for
the beginner trying to learn windows programming.

I have never understood the passion over these things.
I see no virtue in doing it the hard way. I learnt
assembler back when it had a speed advantage over the
Basic interpreter that came with my first computer
and before that I programmed pure assembler via toggle
switches on the front of a home made hobby computer.
Lots of fun at the time but ...


--
JC

JGCASEY wrote:

> On Nov 30, 3:15 am, "Ratch"  <spamt...@crayne.org> wrote:
> 
>  ...
> 
>> Just because an assembler has a full or limited
>> capability to use HLL, does not disqualify it from
>> being an assembler. Unless it does NOT allow the
>> programmer to ignore HLL and code instructions
>> and data on a one to one basis.
> 
> But is it a hll with an inline assembler or an
> assembler with an inline hll?

I would say that it an assembly language that also has optional support
for high level constructs.

> I use the inline assembler of FreeBasic because FreeBasic
> allows me to use the modern hardware for graphics but I
> can still write simple assembler code if I so wish.
> 
>> > What can reasonably be regarded as a "grey area"
>> > between assembler and compiler output, are the
>> > built in HLL statements like MASM's INVOKE, IF,
>> > WHILE etc., HLA's HLL control constructs, RosAsm's
>> > Pre-Parsers and others.
> 
> Still if the actual output is predictable, and what you
> want, how is that different from the predictable output
> of a mnemonic used to produce a single machine code
> instruction?

It is much less deterministic than an assembler language mnemonic. A
high level language statement expands to an arbitrary amount of machine
instructions (it could be one instruction or a million), that we do not
know when we write the source code. There is no easy way to find out
too, without examining the compiler's source code. Additionally this
output will vary from compiler version to version, compiler to
compiler, and even invocation to invocation (depending on the code
generation switches that you supply the compiler).

Yes the translation process is "deterministic" in the sense that the
compiler does not generate code based on the number of alpha particles
it detected, but at the same time the process is *much* more convoluted
than a simple translation of an assembler mnemonic.

Also the really crucial difference is that with a pure assembler
language the programmer can himself calculate the exact bytes that will
be output for each instruction he writes, as he is writing the code.
With a typical HLL this is practically impossible.

> Isn't it a kind of short hand which indeed 
> mnemonics are for the actual numbers?

Ultimately yes, but there is a large and significant relative difference
between the code generation process for a HLL language and a pure
assembler.

<snip>
 
> I have never understood the passion over these things.

It's a question of desire to understand the processor at it's level.

> I see no virtue in doing it the hard way.

It is true that assembler is needed only in relatively few places, but
wherever it is needed, it is pretty much critical.

> I learnt assembler back when it had a speed advantage over the
> Basic interpreter that came with my first computer
> and before that I programmed pure assembler via toggle
> switches on the front of a home made hobby computer.
> Lots of fun at the time but ...

There are many people who have grown up with Intel computers and only
have access to such machines with modern OSes like Windows or Linux.
However some of them still desire to understand the machine at a low
level, which can be done, though it may not be as simple as it was with
the original IBM PC.

BTW, how is your webcam app coming on?

On Dec 1, 8:27 pm, santosh  <spamt...@crayne.org> wrote:

 ...

> There are many people who have grown up with Intel
> computers and only have access to such machines with
> modern OSes like Windows or Linux. However some of
> them still desire to understand the machine at a low
> level, which can be done, though it may not be as
> simple as it was with the original IBM PC.

To really understand how computers work at the lowest
level you need to understand how logic gates are put
together to make a working general purpose computer.


> BTW, how is your webcam app coming on?

On hold for the moment as I have been playing around
with the problem of image segmentation. I do not have
the windows api knowledge to use assembler so it will
have to be written in FreeBasic or C for which there
is software available to grab images into an array.

--
JC

JGCASEY wrote:

> On Dec 1, 8:27 pm, santosh  <spamt...@crayne.org> wrote:
> 
>  ...
> 
>> There are many people who have grown up with Intel
>> computers and only have access to such machines with
>> modern OSes like Windows or Linux. However some of
>> them still desire to understand the machine at a low
>> level, which can be done, though it may not be as
>> simple as it was with the original IBM PC.
> 
> To really understand how computers work at the lowest
> level you need to understand how logic gates are put
> together to make a working general purpose computer.

I meant at the software level. Machine code (and assembly) are about the
lowest you can go and still be in software land. Logic gates, chip
design and it's associated electronics albeit interesting, are not of
much interest from a software angle.

>> BTW, how is your webcam app coming on?
> 
> On hold for the moment as I have been playing around
> with the problem of image segmentation. I do not have
> the windows api knowledge to use assembler so it will
> have to be written in FreeBasic or C for which there
> is software available to grab images into an array.

Hmm, calling an API from assembler should be trivial, provided you are
aware of the platform's ABI. As for general arithmetic and logic
operations, often assembler (particularly CISC ones like x86) is even
easier to code than in C and so on, which may have additional
restrictions.

On Oct 7, 8:55 am, WillofIrony  <spamt...@crayne.org> wrote:
>
> So, which is the best: GoASM, NASM, MASM32, RoASM? or did I miss the
> best one? BTW, I did scan the FAQ but the latest version is almost
> four years old and i suspect that the field of Win32 ASM is a rapidly
> changing field at the moment.
>
> Thanks in anticipation,
>
> Michael

Most of the comments about NASM being slow/limited are very outdated.
NASM strikes a good compromise between speed and portability. NASM, as
of recent, fully supports the 64-bit architecture expansion of the x86
(x86-64). NASM also employs less ambiguous RIP relative support which
differs from what its spin-offs, such as FASM and YASM, provide.

NASM has quite a few projects/packages that provide macro facilities
to clean up OS-specific details while keeping absolute control of the
program in your hands. One of these projects is called NASMX, which I
and another colleague work on from time to time. LINK:
http://www.asmcommunity.net/projects/nasmx/

Here is my gripe list about the other assemblers that have been
mentioned. These comments are not here to generate a flame war, and
are based on observable events and/or fact. In the end, I would
encourage you to try all of them for yourself and gather your own
opinion.

1.) MASM is (legally) a windows-only thing. The legality of its
biggest supporting package, MASM32, is questionable at best. MASM32
has, tentatively, been found to be an illegal redistribution of
Microsoft licensed software in Germany (DE). Beyond that, the supposed
agreement between the package author and Microsoft was negotiated with
Microsoft Australia (AU) and would only apply to that country/region.
The reality of the situation, however, is that MASM32 promotes
Microsoft material... and manages to stay under the radar despite its
author coupling MASM discussion/support with his extremist political
agendas. MASM32 does have lots of support, examples and tutorials that
would ease you in to Win32ASM development.

2.) FASM will only run on few x86-based operating systems, and a
handful of hobbyist OS projects that have "ported" it. Also, I have
heard that FASM 2 will have macro facilities that will be fairly/
completely incompatible with the current syntax. If I have
misunderstood this, or if this has changed since I was last informed,
please correct this. Other than that, FASM seems to draw upon a
fanatical crowd, for whatever the positive/negative aspects of such
are worth. The FASM user base is great, but the documentation is poor.

3.) YASM has not been through the years of hardening that NASM has.
We've even brought out a few design flaws/bugs in YASM just from
recently developing NASM further. YASM does accept AT&T/GAS syntax
along with NASM syntax; however, this divides development focus and
you have two things that are supported in good manner, whereas NASM
and GAS can focus on doing one thing great. There might be a few
things different about YASM that you may enjoy over NASM and others,
so go ahead and try it.

4.) HLA seems to enable you as much as it will limit you from really
learning assembly language. I have witnessed people, some of which
participate in newsgroups like this one, trying to move from HLA to
full assembly language and they seem to only have a basic
understanding of computers and programming. This might be more of a
reflection upon the user than language, since it allows those with
poor disposition for assembly language to thrive in HLA, but muddle
their way through full assembly language and more advanced programming
concepts in general.

5.) RosASM is constantly being pushed by its author, Rene "Betov"
Tournis, at the level of the previously mentioned assemblers where-as
it is realistically much more of a lower quality/class assembler.
RosASM is Win32/PE specific, does not support standard library
linking, enforces a mono-file (one huge file instead of functionality
divided modules) programming mentality, and it is notorious for
ignoring legitimate bug reports. Despite all of that, RosASM is still
an assembler and its user base does enjoy what it provides, so you may
as well.

6.) I have no opinion of GoASM, but I know a few experienced and
trustworthy programmers that use/like it, so I will proxy their
approval to you. I know the accompanying linker, GoLink, has some bugs
in it that need to be addressed... so keep that in mind if you intend
to use it.

Obviously, my vote is for NASM as it will run just about everywhere
you want it to. More importantly, it has good documentation, plenty of
examples floating around the internet, and it provides a fairly
consistent/intuitive syntax that will keep you focused on the task at
hand.

Having used none of the 'assemblers' listed below, but having been
programming in assembler for 35 years a couple of points can be made.

1.	Higher level languages such as Cobol, Fortran, etc. are useful for
getting massive amounts of code done by people who don't have a clue
about bit twiddling, flags, etc.  This works well for reports and
simpler tasks that don't require an understanding of the underlying
hardware and software.

2.  All three assemblers are available via the WDK which is a free
package from Microsoft.  You can have them all covering 16 & 32 bit
environments, 64 bit AMD and the 64 bit IA64.

3.  All the above being true, if you want to be a bit twiddler you
have to know more than one assembly language.  I started on the
Honeywell 201 (Easycoder) and the IBM ANFSQ7.  I have done Z80
assembler under CP/M, Burroughs and Sperry mainframes, and the 8088
onward.  Learning the various type of assembly languages gives you a
perspective on how the many CPUs vary.  The Intel 8088 chips have a
move instruction that does not affect the flags, but other CPUs may
not and some do not.  Sign extension, overflow, underflow, and stack
presence are some things I have seen that differ.



On Sun, 2 Dec 2007 12:37:48 -0800 (PST), Keith Kanios
<spamtrap@crayne.org> wrote:

>On Oct 7, 8:55 am, WillofIrony  <spamt...@crayne.org> wrote:
>>
>> So, which is the best: GoASM, NASM, MASM32, RoASM? or did I miss the
>> best one? BTW, I did scan the FAQ but the latest version is almost
>> four years old and i suspect that the field of Win32 ASM is a rapidly
>> changing field at the moment.
>>
>> Thanks in anticipation,
>>
>> Michael
>
>Most of the comments about NASM being slow/limited are very outdated.
>NASM strikes a good compromise between speed and portability. NASM, as
>of recent, fully supports the 64-bit architecture expansion of the x86
>(x86-64). NASM also employs less ambiguous RIP relative support which
>differs from what its spin-offs, such as FASM and YASM, provide.
>
>NASM has quite a few projects/packages that provide macro facilities
>to clean up OS-specific details while keeping absolute control of the
>program in your hands. One of these projects is called NASMX, which I
>and another colleague work on from time to time. LINK:
>http://www.asmcommunity.net/projects/nasmx/
>
>Here is my gripe list about the other assemblers that have been
>mentioned. These comments are not here to generate a flame war, and
>are based on observable events and/or fact. In the end, I would
>encourage you to try all of them for yourself and gather your own
>opinion.
>
>1.) MASM is (legally) a windows-only thing. The legality of its
>biggest supporting package, MASM32, is questionable at best. MASM32
>has, tentatively, been found to be an illegal redistribution of
>Microsoft licensed software in Germany (DE). Beyond that, the supposed
>agreement between the package author and Microsoft was negotiated with
>Microsoft Australia (AU) and would only apply to that country/region.
>The reality of the situation, however, is that MASM32 promotes
>Microsoft material... and manages to stay under the radar despite its
>author coupling MASM discussion/support with his extremist political
>agendas. MASM32 does have lots of support, examples and tutorials that
>would ease you in to Win32ASM development.
>
>2.) FASM will only run on few x86-based operating systems, and a
>handful of hobbyist OS projects that have "ported" it. Also, I have
>heard that FASM 2 will have macro facilities that will be fairly/
>completely incompatible with the current syntax. If I have
>misunderstood this, or if this has changed since I was last informed,
>please correct this. Other than that, FASM seems to draw upon a
>fanatical crowd, for whatever the positive/negative aspects of such
>are worth. The FASM user base is great, but the documentation is poor.
>
>3.) YASM has not been through the years of hardening that NASM has.
>We've even brought out a few design flaws/bugs in YASM just from
>recently developing NASM further. YASM does accept AT&T/GAS syntax
>along with NASM syntax; however, this divides development focus and
>you have two things that are supported in good manner, whereas NASM
>and GAS can focus on doing one thing great. There might be a few
>things different about YASM that you may enjoy over NASM and others,
>so go ahead and try it.
>
>4.) HLA seems to enable you as much as it will limit you from really
>learning assembly language. I have witnessed people, some of which
>participate in newsgroups like this one, trying to move from HLA to
>full assembly language and they seem to only have a basic
>understanding of computers and programming. This might be more of a
>reflection upon the user than language, since it allows those with
>poor disposition for assembly language to thrive in HLA, but muddle
>their way through full assembly language and more advanced programming
>concepts in general.
>
>5.) RosASM is constantly being pushed by its author, Rene "Betov"
>Tournis, at the level of the previously mentioned assemblers where-as
>it is realistically much more of a lower quality/class assembler.
>RosASM is Win32/PE specific, does not support standard library
>linking, enforces a mono-file (one huge file instead of functionality
>divided modules) programming mentality, and it is notorious for
>ignoring legitimate bug reports. Despite all of that, RosASM is still
>an assembler and its user base does enjoy what it provides, so you may
>as well.
>
>6.) I have no opinion of GoASM, but I know a few experienced and
>trustworthy programmers that use/like it, so I will proxy their
>approval to you. I know the accompanying linker, GoLink, has some bugs
>in it that need to be addressed... so keep that in mind if you intend
>to use it.
>
>Obviously, my vote is for NASM as it will run just about everywhere
>you want it to. More importantly, it has good documentation, plenty of
>examples floating around the internet, and it provides a fairly
>consistent/intuitive syntax that will keep you focused on the task at
>hand.

On Dec 2, 8:19 pm, dave <spamt...@crayne.org> wrote:
> Having used none of the 'assemblers' listed below, but having been
> programming in assembler for 35 years a couple of points can be made.
>
> 1.      Higher level languages such as Cobol, Fortran, etc. are useful for
> getting massive amounts of code done by people who don't have a clue
> about bit twiddling, flags, etc.  This works well for reports and
> simpler tasks that don't require an understanding of the underlying
> hardware and software.
>

Then it follows that 99.99% of all programming falls under the
"reports and simpler tasks" category and it is not important for most
programmers to worry about "bit twiddling, flags, etc." nor gain any
understanding of the underlying machine.  This is certainly reflected
in the popularity of the heavy use of HLLs both in education and
career.

In most student's eyes, assembly is seen as a "dead language" and "a
waste of time" and I believe there will never be a book, product, etc.
to convince them otherwise.

Nathan.