Whats Better ???

What would you guys recommend as a better assembler Compiler : FASM ? TASM ? or MASM :(

thanx

Reply to
Lighthammer
Loading thread data ...

TASM. It can behave as MASM as well (quirk mode) and later versions are object-oriented, if you care.

Vadim

Reply to
Vadim Borshchev

OPTASM. Assemblers are not compilers.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

I prefer the gnu assembler, but I'm probably weird that way.

--
Grant Edwards                   grante             Yow!  And furthermore,
                                  at               my bowling average is
 Click to see the full signature
Reply to
Grant Edwards

I feel like I'm being set up (: I've used MASM for too long and I'm too old to change.

I can recall buying a copy with my brand-new PC Junior right around 20 years ago. It was pretty dreadful then, with phase errors if you looked at it sideways.

TASM and MASM are close to being inter- changeable at this point. I've assembled the same source with both and not had to make any significant changes.

Reply to
Jim Stewart

I've been using NASM for years. I drop kicked MASM to the curb a long time ago. Got irritated with TASM's syntax and stopped using it. Don't know what FASM is.

-->Neil

Reply to
Neil Bradley

I guess so. ;-) The GNU (AT&T?) syntax, um, gives me 'gas'...

If you are going to assemble existing code, you pretty much need a compatible assembler. In most cases, that's TASM (in QUIRKS mode) or MASM. I've never heard of FASM.

At a PPOE, I hade good experience with TASM, writing new code in IDEAL mode, compiling acquired code in QUIRKS mode.

If the only code I had to deal with was new stuff I was going to write myself, I'd look seriously at NASM.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

NASM:

- compiles both 16 and 32 bit

- free (sources are available, it's maintained at sourceforge)

- no weird AT&T syntax

- supports many output formats (can be linked with Borland/Turbo Pascal/C/C++ (intel OMF) and most likely Watcom C/C++ as well (though there you already have WASM (somewhat similar to TASM/MASM), which is also free, btw, since the release of the Open Watcom), and, of course, GCC (COFF, AOUT, ELF, etc)).

- has many nice features (flat binary output, inclusion of binary files as-is, etc etc)

Alex

Reply to
Alexei A. Frounze

.... and what about Randall Hyde's HLA ?

formatting link
formatting link

he has some notes here on MASM/TASM/FASM :

formatting link

and this too...

formatting link

-jg

Reply to
Jim Granville

Thanx for the Help ... and suggestions guys .. but what would you suggest for easier platform independance ??

Interms of moving Code over to different CPU Architectures that use differrent Registers, Calls Ect ?

Could One write a set of functions that is compatible on lets say PC and easily ported to a CELL PHONE or Epprom for PIC DEv ?

MASM i think would not be a good choice here

Reply to
Lighthammer

For portability, use a high level language, say C, and keep all the processor- dependent stuff separate, so you only have to rewrite a few primitives. This won't be ALL the solution- microcontroller archtitectures can be VERY eccentric- and capabilities may be different- e.g. you might have depended on double precision fp, and it's not available for the new compiler. There will also be problems porting to new peripherals etc. But with luck, you can keep most of the original code in a port, and if you are VERY lucky, a moderately complex program can be ported in an afternoon (it happened to me once- it took days of testing to convince me I'd got it right though).

Paul Burke

Reply to
Paul Burke

Surely you're joking --- you can't seriously be raising the issue of

*platform* independence in a comparison of three different *assemblers*, at least two of which are actually for the exact same target platform.

Exactly *no* assembler is going to seriously help you with that, and definitely none of the old PC/DOS ones, which are even more narrow-minded than assemblers really have to be.

In a nutshell, programming in assembler and writing cross-platform portable code are mutually exclusive.

If you want any kind of portability across typical embedded platforms, use C, Forth, or maybe (on a long stretch) Basic.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

There are a couple of ways to interpret "platform independence." One is target and the other is host. If you want to develop *for* x86 on, say, an iMac or on a Sun workstation, NASM might be a viable choice. OTOH, as you point out, if we're talking about target platform independence, my first answer is probably "use C."

I suppose one could argue that gas assists with this slightly, since it is retargetable, but I'd be the first to admit that this a very week argument!

That would be my advice, too.

You didn't mention Java. Oversight? ;-)

Ed

Reply to
Ed Beroset

I have written a number of applications using the PC (386/486) as a simulator and test environment for code that went almost to the target bare-metal. This same code, un-altered, would also run on the Atari Mega-ST4 (68000) system I was using for documentation as well as the intended targets (6809, 6309, Novix NC4000 and RTX2000).

What was shared by all systems was a Forth that was certifiably identical at the surface interfaces used by the application code. Of course, any words that had been highly optimised for a specific processor were not transferrable directly but I always had a high level Forth template for those words which would work, albeit with less performance than the optimised code. Re-use for me is quite easy (so long as I recognise that I already have some code to do a function).

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

... which wasn't in the OP's original list, though. If that 'FASM' he mentioned is any bit like the other two, his list is (essentially) single-platform for both host *and* target.

GNU as is indeed what I had in mind there. It's multi-platform for both host and target, and considerable parts of the assembly language are shared among targets.

Well, that, and lack of conviction that Java is actually applicable for embedded systems. But let's not get into *that* discussion, shall we? ;-)

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

You don't mix up "Hard-Real-Time" and "Embedded" by any chance ?

If you have a look at

formatting link
you see pretty small boards running Java, and probably well suited for embedded applications ...

Reply to
E.S.

Right !! well ok

But aren't C, forth and Basic Programing languages 3rd Gen Languages ?

If So Isn't Assembler a 2nd gen language ? and Opcodes 1st Genration ?

That said how would C be platform independant ?

I'm Confused ??

Reply to
Lighthammer

Yes. But that has quite exactly nothing to do with the issue at hand.

It just is. A C programmer who knows what he's doing can write all parts of a given program that don't have to be platform-dependent in a platform-independent fashion, while still having enough freedom to express the modestly platform-dependent parts, too.

Obviously.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

mmmm ... Friendly Forum

Reply to
Lighthammer

Look, you are exasperating, even for a South African, eh. You asked whether you could program in a different way so that the resulting program would be more portable. You seemed to think that an assembler program could easily be ported. We answered- no. We suggested a whole bunch of ways by which you COULD write relatively portable programs, and you don't seem to like it.

The point everybody has bben making is-

Assemblers are absolutely specific to the particular processors.

High level languages are abstracted from the underlying hardware to a greater or lesser degree.

To write portable code, write as much as possible in high level, and write only the specifics for your processor in assembler.

With the MSP430 and mspgcc, I haven't had to write ANY assembler in two years, and I've ported several programs.

Paul Burke

Reply to
Paul Burke

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.