Which assembler should I use.

[alanabbott]

I've looked into MASM32 6.1, installed VC++ 2005 express with MASM 8.0 and also read GoAsm. this last somewhere I sow something that said some instruction operated left to right, this totally confused me. I have an application I wrote 30 years ago for Main-frame, 15 years ago I down scaled to PC. The PC version is 16 COBOL so I want to update it to 32 bits and work under Windows Vista. My idea is also to leave it as neutral as possible. In Main Frame it ran in IBM 370 and up, IBM 36 and AS/400, and NCR Century.
I need speed as the amount of data to go through is considerable and basically it is a combiner and extracted of data to be analysed with some spread sheet.

[donkey]

Hi,

MASM is the defacto standard for assemblers and you will find alot more example code for it than all other assemblers combined. Also there are a number of preprocessors available for it that allow you to use some pretty powerful high level constructs such as ObjAsm32 for object oriented programming. For most people MASM is the choice and version 8 is the version you want to use. GoAsm is a bare bones assembler but in many ways offers features that MASM does not, such as branch hinting and Unicode support as well as better linking and inline file support. GoAsm is syntactically similar (almost identical) to MASM but lacks the high level constructs and is more explicit. I am a GoAsm user and find that I prefer it over MASM for a number of reasons but if you plan on writing code to be maintained by a number of people MASM is probably the way to go in assembly.

[Mark Jones]

If your code must remain "as neutral as possible," then perhaps write the bulk of the application in VC++, since C is the de-facto standard programming language nowadays, and use MASM32 to write a .DLL containing the speed-critical functions. This could all be done in VC++, however it might be more efficient to use the MASM32 code editor to write both the .DLL code, and a small test app, which calls the .DLL functions similar to how the C++ app would; that way the .DLL code could be written and compiled quickly, and tested without switching back-and-forth between that and VC++. Sounds like a fun project, best wishes. :U

[comrade]

Also try FASM - http://www.flatassembler.net/

It has a very active community.

[PBrennick]

When you talk about a combiner and extractor, are you referring to hex encoding/decoding? If you are, there is a lot of code already available for this purpose that could speed up your initial development. The GeneSys Editor has both of those procedures in the Code Librarian (plus a combiner utility which works on d ta with a pre-determined size). The other two work on ASCIIZ strings of any size up to the amount of available memory.

-- Paul

[lingo]

alanabbott,

I worked seven years with Cobol and C on IBM 370, WANG 9600 and HP-9000 RISC machines and agree with Mark's advice, because the most powerful and easiest for use high level constructions are in C++ NOT in MASM.

Hence for example, if you learn and use "high level MASM constructions" from our GeneSys "guru" ****** your programs will be many times slower than your C++ code...  :lol

When you finish your 1st project in C++ and if you need more speed you can return to programming in assembly for speed (not for "easy reading" or for "power high level constructions" or other blah,bla,bla..). Then you can start with the A.Fog's books about speed optimization in assembly and C++  :wink

[hutch]
We will not accept personal criticism of other members.

[alanabbott]

Thank you all for your comments.
I missed out an important detail, we are a small shop I do all the designing, programming, testing and maintenance. I do not need the programming be understood by anybody but my partner.

Alan Abbott

[donkey]

Thank you all for your comments.
I missed out an important detail, we are a small shop I do all the designing, programming, testing and maintenance. I do not need the programming be understood by anybody but my partner.

Alan Abbott

Hi Alan,

Go with GoAsm or FASM, since you are developping what is most likely commercial software you may find the EULA for MASM a bit cumbersome, for example if you use the freely downloadable version of MASM8, you can not develop any commercial software with it and still be in compliance with the EULA. Also many versions of MASM you will find here are restricted to developping device drivers under their EULA since they were originally shipped with the DDK (EULA section 1.a.). For the hobbyist this is perfectly fine, however for a corporation you may find that you have opened a can of worms once you begin violating Microsoft's usage policies. Both GoAsm and FASM have very open licenses and allow cross platform development without restrictions, GoAsm is very similar to MASM while FASM can cost you a few nights sleep if you are expecting a MASM like assembler. I am not much of a FASM user so others will have to talk about it's features but GoAsm offers native Unicode support, a more powerful INVOKE pseudo-macro than MASM, better linking and full C static library support. You would be hard pressed to find a feature in MASM that GoAsm lacks with the exception of parameter checking and macros, GoAsm does no parameter checks and it's macro language is rather limited. For myself these two deficiencies are of little consequence since I rarely have a need for them.

Edgar

[japheth]

Thank you all for your comments.
I missed out an important detail, we are a small shop I do all the designing, programming, testing and maintenance. I do not need the programming be understood by anybody but my partner.

Alan Abbott

You told us that your program currently is written in Cobol, 16bit. Why do you think you need to translate it to 32bit ASM? The 16bit code should still run fine in Vista? And if it was fast enough 15 years ago, then it probably is also fast enough on modern hardware?

the options you have are

- stay with 16bit Cobol, no changes.
- stay with 16bit Cobol, add speed-up by a Win32 dll (VDD) written in ASM or C.
- compile your program with a 32bit Cobol. There are virtually 2 compilers left, Microfocus and Fujitsu.
- convert your cobol source to C or ASM - possibly not the best option IMO.

[hutch--]

Alan,

Probably the best advice has been from Lingo, unless you have a good reason to convert COBOL to X86 assembler code, a C++ compiler (Microsoft) is probably the easiest and most reliable method for what is most probably commercial code from another era. If you need "go fast" bits an assembler is the way to go and your choice is many and most of them are well written but if you want industry standard, then MASM is the tool.

You can mix C++ and asm code as long as the assembler will output a compatible object module format (COFF) and learn the correct prototyping of the assembler module in C/C++ and in fact this is why Microsoft still supply MASM, so you can link in assembler code with your C/C++ code.

[PBrennick]

I also think Lingo said it best. In fact, moving to C++ will be an easier transition for you. I remember the look and feel of COBOL tools so I understand why you are eager to convert it to some sort of WIN32 product. It is always best to make as easy a transition as you csan. Once yo have moved it into C++, if you are still interested in assembly as a solution, you can port ity from C++. Or as Hutch said, just the speed critical stuff.

It would also be helpful, in terms of giving advice, to know the size of the database. It is interesting that you chose COBOL over RPG, for example. If I remember correctly, there were(or are) migrating tools for porting code to C++ At SA when we moved away from the AS-400, we ported an enormous database that was in Shelby (RPG).

-- Paul

[hutch--]

I have split the rest of the postings of this thread to the Colosseum as they no longer addressed Alan's original question.