Limits

[JK]

Hi everyone,

i have done some MASM projects many years ago, but recently i wrote mostly inline assembler code for PowerBASIC, so my knowledge about MASM is a bit rusty. I understand, that this is the place for basic questions.

- What is the better choice for projects, which build 32 and 64 bit executables from the same (or almost the same) code: MASM or UASM ?

- Is there a limit for the line length in MASM/UASM? If yes, what is it? What about continued lines?

- Is there a limit in file size or line count for a single code file?

- Does it make a difference for MASM/UASM, if the code of a large project is put all together in one single file (apart from the standard includes), or if it is split into smaller pieces?


Thanks


JK

[hutch--]

At the 32 bit level, UASM is designed to be MASM compatible so it should be very similar to MASM code but you have to be careful with very minor differences if you try to build a source from one to the other, they will not necessarily build correctly. Microsoft did not modify the old 32 bit version to create a 64 bit version, they provided ML64 which is purely a 64 bit assembler and it is different to the old 32 bit version.

In 64 bit, MASM does not use the prototypes that the 32 bit version did while UASM was developed around strong prototyping so it is no longer MASM compatible in 64 bit. This is similar to how the later versions of PB no longer need prototypes which in turn makes include files a lot simpler to construct and why 64 bit MASM has extensive include files that work where UASM does not.

Old MASM has a 256 characters line limit and I think from memory that the 64 bit version has the same where UASM may have a larger limit. Building a single very large source can be done but it is rarely done as MASM/UASM both support making Microsoft COFF library modules which is a lot easier to manage than massive single source.

As far as bugs/glitches go, both have their problems, as UASM is in constant development and some of its user base keep reporting bugs it is yet to be stable while MASM has always been a bad mannered old pig where you have to know its quirks but it is stable enough to use.

I think I have addressed most of your questions but if you have others, we will try and make sense of them

[jj2007]

Hi JK,

Re line length: test it...

include \Masm32\MasmBasic\Res\JBasic.inc        ; ## builds in 32- or 64-bit mode with UAsm, ML, AsmC ##
; this line is 262 bytes long:
a$ db "12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901", 0
Init          ; OPT_64 1      ; put 0 for 32 bit, 1 for 64 bit assembly
PrintLine Chr$("This program was assembled with ", @AsmUsed$(1), " in ", jbit$, "-bit format:")
Inkey Str$("Len(a$) is max. %i bytes", Len(offset a$))
EndOfCode

262 bytes is the limit for ML64, while UAsm tolerates up to 1002 bytes - projects attached. All my 32-bit sources assemble fine with ML, UAsm and AsmC, I have had no compatibility problems for years.

Afaik there is no limit for overall code size or lines of code. The RichMasm source is currently at 21,400 lines, assembling takes 1500 ms on my trusty old Core i5 using UAsm64.exe, and a little bit longer with ML.exe

With regard to 64-bit coding...

Code Select Expand

  .if eax<=127
nop
  .endif
... is fine for UAsm but throws a "syntax error" in ML64. Hutch has written macros that help to overcome the lack of high level syntax in ML64. If I remember well, you have to use brackets to simulate the .if eax<=:

Code Select Expand

  .if eax{=127
nop
  .endif

[hutch--]

You can use the following if you are familiar with symbolic logic.

.if var ~= reg
  ; do whatever
.endif

[hutch--]

Juergen,

If the assembler you have written in PB is late enough to be written in the latest versions, you can generally port it almost directly to MASM. Remove the leading "!" and change any HEX notation from PB &H1122334 to MASM format 1122334h and it will be very close to working. Note with MASM HEX notation that it must start with a number so if you have FFFFFFFFh it needs to have a loading "0" so that you have 0FFFFFFFFh. As I have written PB assembler for many years, I have been able to port assembler code between both PB and MASM with only minor changes.

Now if the assembler code is within a PB function or sub instead of a prefix block, you will have to construct a normal procedure in MASM that handles the registers that need to be preserved but its no big deal to do once you have had a bit of practice and it means you can use a heap of code that you have already written.

[JK]

OK, thanks hutch and jj2007 - next question

... and why 64 bit MASM has extensive include files that work where UASM does not.

that means, there are cases, where ml64 works and UASM doesn´t - or did i get that wrong ?

For MASM there are different sets of include files (32/64 bit), for UASM there is one set, which can be used for 32 and 64 bit (WinInc). Which approach is better? Are there known problems with these includes?

[hutch--]

With ML64 you don't need the argument count or type so the include files are much simpler to create and the available set is very comprehensive, UASM requires prototypes for every API and this includes the arg count and data type. MASM is simpler but it does no type checking so you must pass the correct data to any function you call.

Unfortunately no-one has bothered to support UASM with good quality include files.