Assembly Portability

Quote:

---

Taken from http://webster.cs.ucr.edu/ Which Assembler is the Best?

Portability may seem like an oxymoronic term when applied to assembly language. Obviously you're not going to write code with an x86 assembler that runs (natively) on some other processor. However, even on the same processor you can run into portablity problems. For example, if you write a generic x86 assembly subroutine (that is OS independent), can you assemble and use that same code across multiple OSes? For a large part, the question is answered by whether or not the assembler runs under different OSes. For example, a generic NASM subroutine will assemble and be usable under every operating system that NASM supports.

There is one more dimension to portability - can you write a complete application with an assembler and port that code from one OS to another with only a "recompile" of the source code? Currently, only one assembler supports this feature (HLA) through the use of the HLA Standard Library. This is an important consideration, for example, if you want to be able to create Windows and Linux applications in assembly with minimal effort. On the other hand, if you're working with a single operating system and absolutely have no plans to work with any other OS (now or in the future), then this issue may not be important to you.

---

After reading the following about asm and portability i have some questions.

I understand that it's not possible write code with an x86 assembler to run on a different processer with a different instruction set. Also according to what's above it's not possible to write asm code to run across multiple OS's without the assembler being supported for that specific OS. For instance NASM supports Windows, DOS, Linux, BSD, QNX but not OS/2. But then why it it possible to be able to run assembly code written in HLA on an OS that HLA does not support? I don't think this can be correct. HLA supports only Windows and Lunix. So i think the statement

Quote:

---

There is one more dimension to portability - can you write a complete application with an assembler and port that code from one OS to another with only a "recompile" of the source code? Currently, only one assembler supports this feature (HLA) through the use of the HLA Standard Library.

---

only pertains to those OS's that HLA supports. Windows and Lunix

Quote:

---

Originally Posted by Dilenger4

After reading the following about asm and portability i have some questions.

I understand that it's not possible write code with an x86 assembler to run on a different processer with a different instruction set. Also according to what's above it's not possible to write asm code to run across multiple OS's without the assembler being supported for that specific OS. For instance NASM supports Windows, DOS, Linux, BSD, QNX but not OS/2. But then why it it possible to be able to run assembly code written in HLA on an OS that HLA does not support? I don't think this can be correct. HLA supports only Windows and Lunix. So i think the statement only pertains to those OS's that HLA supports. Windows and Lunix

---

Well the first part is true about the x86 langauge. You can only run you're code on a x86 processor (Think of amd and intel).

The 2nd part is very misleading. I can create a program in C++ (Which is considered to be a language that is cross-platform) and not be able to run that code on operating systems the compiler doesn't support. The reason is due to the executeable file layout and other another reason could be useage of API. In other words, a C++ program created with microsoft visual studio will not run on Linux. However I can take the source code and recompile it on linux with GCC and it will run just fine and dandy (Just as long as I'm not using specific apis).

:thumb: Ah ok. Thanks for the help. :)

The problem with HLA is that HLA is not assembler. It's like giving C++ an assembler syntax and telling you that it is assembler. This is where you get the portablility.

And also, it is possible to write assembler that is OS independent as long as you do not use any of the OS interrupts. However, now we are looking at code snippets.

HLA does let you write pure assembly though. Just because it supports high level features i can't see how it would not be an assembler. TASM and MASM
support high level features. So they are not assemblers? You still get full access to the underlying machine instructions.

From my source (AoA,) I do not see a way to drop into the 80x86 (i386) assembly instruction set. It appears that HLA is just a set of function calls (which is much more inefficient than pure assembler.) I am gathering this from the syntax of the langauge:

HLA: mov(source, destination); // obvious C style function
Assembly: mov dest, source // assembler

Furthermore, the AoA explicitly says that HLA should be considered as a compiled language due to the complexity of the language. If mov was just considered as one instruction (which would be mov,) then HLA would be an assembler.

If you have the syntax to explicitly drop into assembler (thereby defeating the purpose of HLA,) may you please post it? I would be rather interested in seeing that. :) However, I would like to see time trials between an 80x86 program and an HLA program for efficiency.

HLA and assembler in general is pretty new to me so i can only go by what is said about HLA from AoA. AoA compares HLA to MASM and TASM both of which are considered according to AoA, high level. I did notice in the HLA setup FAQ that MASM32 is also needed. It's kinda confusing to me because if HLA uses MASM32 then HLA is really on a higher level than MASM32 but AoA still says that you still get access to the underlying machine instructions. :confused:

As for time trials i haven't a clue. He does list his observations on the speeds at which different assemblers execute.

Quote:

---

Taken from http://webster.cs.ucr.edu/ Which Assembler is the Best?

MASM is somewhere in the middle of the pack. For various reasons, MASM has a reputation as a very slow assembler. In fact, for large projects (where speed is most important), MASM actually does better than most other assemblers. Largely, the performance of the MASM assember tends to be related to the advanced features you use in your source code. If you limit the feature set you use to those features found in other assemblers, MASM generally translates the source code at a comparable speed to those other assemblers.

TASM generally seems to run about two to three times faster than MASM, though on really large files using certain features, MASM can edge out TASM.

A(3)86 is purportedly a lot faster than MASM (and possibly TASM, too). But I've never run it personally, so I cannot comment on its performance.

FASM has recently undergone some performance boosts to improve performance (particularly for large projects). So it generally is quite a bit faster than MASM.

NASM is usually slower than MASM for most reasonable sized projects.

SpAsm/RosAsm seems to be all over the map with respect to speed. For certain source files it assembles quite quickly; for others, it runs rather slowly. This is partly due to the fact that it was written in assembly language, however, a large reason it sometimes much faster is because it doesn't incorporate the sophisticated features found in MASM and other assemblers.

On modern machines, the speed of the assembler is almost a non-issue. Assemblers like A(3)86, TASM, and FASM may be very fast indeed. However, on a 300 MHz Pentium II machine, HLA chugs along at a rate of 10,000 lines per second. This means that you can assemble a 20,000 line Win32 application in just a few seconds. True, an assembler like FASM would process such a file almost instantaneously, but in real-world situations, the difference between the two is not going to make a difference. Nevertheless, assembly programmers in particular are sensitive to the speed of the applications they use and some will pick a faster, though less powerful, assembler over a slower one. All other things being equal, this is a good metric; however, when it comes to choosing an assembler, the products are rarely equal except for speed.

---

Quote:

---

Originally Posted by Dilenger4

HLA and assembler in general is pretty new to me so i can only go by what is said about HLA from AoA. AoA compares HLA to MASM and TASM both of which are considered according to AoA, high level. I did notice in the HLA setup FAQ that MASM32 is also needed. It's kinda confusing to me because if HLA uses MASM32 then HLA is really on a higher level than MASM32 but AoA still says that you still get access to the underlying machine instructions. :confused:

As for time trials i haven't a clue. He does list his observations on the speeds at which different assemblers execute.

---

There is 5 high level features that you have in MASM that you can use optionally. Microsoft added a few small things like the ability to say .if, there isn't many though, heck I'll even list them:

Quote:

---

.IF
.REPEAT
.WHILE
.BREAK
.CONTINUE

---

and that's all folks!

How can that be it? :lol: What about the ability to define types other than primatives. Dosen't MASM32 allow the programmer to define Struct's, Unions, and TypeDef's?

Quote:

---

Originally Posted by Dilenger4

How can that be it? :lol: What about the ability to define types other than primatives. Dosen't MASM32 allow the programmer to define Struct's, Unions, and TypeDef's?

---

There is no such thing as a data type in ASM. In other words, the cpu doesn't know the difference between a string and a integer (or even instructions, hince how buffer overflows allow hackers to access computers). All of that has to be kept up with by the programmer.

For example, in visual basic, you cannot assign a string directly to a integer. IE:

dim x as string
dim y as integer
y = x

However in asm, you can. In fact some of the fastest string handling algorithms actually load a string into a long and do test on it. In fact that is how strlen (C++ library function) works internally. Visual basic doesn't use null terminated strings, in fact a visual basic string is really a OLE_SAFEARRAY structure. The len of the stirng is stored in a element in the structure called cElements.

In asm, you don't say what type of a variable you need, you just tell it how much memory you're variable will require.

Example:
db = Define byte 1 Byte of Memory
dw = Define Word 2 Bytes of Memory
DD = Define Double Word 4 Bytes of Memory
DQ = Define Quad Word 8 Bytes of Memory
DT = Define Ten Byte 10 Bytes of Memory

A string for example would require an array of bytes.

There is structures however but that isn't really high level. You could use a label and then put variables under it for example. Which is basically how it works in asm.

Quote:

---

Posted by Maven

There is no such thing as a data type in ASM. In other words, the cpu doesn't know the difference between a string and a integer.

---

I ment primative type as in allocation of memory that is not user defined.

AoA defines byte, word, dword, qword, tbyte, and floating point data types as primatives. I don't know if this is correct to say but it does make sense(at least to me). Middle of the page under data types: http://webster.cs.ucr.edu/AsmTools/WhichAsm.html

Hmmm... I wonder if they are referring to all of those fancy non-assember assembler things included in the assembler (.IF, .WHILE, etc.)

I would just like to see a code snippet composed of:

Code:

---

MOV CX, FFh
BeginLoop:
  MOV AX, AX
  DEC CX
  CMP CX, 0
JNE BeginLoop

---

and try them on different assemblers. If this chunk of code does not run at the same speed on two assembers, then logically, this code snippet is not being translated the same.

Byte, word, dword, and qword are basically the same expect they are different sizes. Floating Points are a little bit more tricky. They have a specific format that defines the data inside. I really do not know what a tbyte is.

I would bet that 99.9% of anything using basic x86 instructions will not only run at the same speed, but be compiled into the same machine code no matter what assembler you use -- assuming there is no optimization done of course.
Each assembly instruction corresponds to one CPU instruction. A MOV can only be a MOV instruction. Even with different addressing modes, each assembly instruction can really only be interpretted one way.

I'm not really knowledgable about x86 assembly, but consider the following snippet of mc68000a asm which compiles to a function which adds the two 32 bit arguments together and returns them in d0:

Code:

---

main:
  link a6,#0
  move.l #8(a6),d0
  add.l #12(a6),d0
  unlk a6
  rts

---

If you were to go through the list of instructions for the mc68000 cpu, you could find only one instruction/addressing mode to use for each line.

Quote:

---

Originally Posted by sunburnt

I would bet that 99.9% of anything using basic x86 instructions will not only run at the same speed, but be compiled into the same machine code no matter what assembler you use -- assuming there is no optimization done of course.
Each assembly instruction corresponds to one CPU instruction. A MOV can only be a MOV instruction. Even with different addressing modes, each assembly instruction can really only be interpretted one way.

I'm not really knowledgable about x86 assembly, but consider the following snippet of mc68000a asm which compiles to a function which adds the two 32 bit arguments together and returns them in d0:

Code:

---

main:
  link a6,#0
  move.l #8(a6),d0
  add.l #12(a6),d0
  unlk a6
  rts

---

If you were to go through the list of instructions for the mc68000 cpu, you could find only one instruction/addressing mode to use for each line.

---

You're basic instructions should get translated exactly yes. Except for a few cases like LEA (Load Effective Address), some compilers may change that to move register, offset label if it can be determined at compile time. The only other thing that could effect how fast it runs is if a compiler aligns you're code.

The thing is that when I think of the term High Level Assembler, I think of C, C++, and Fortran functions. If the MOV is actually a function, then you have the overhead of pushing the registers onto and off of the stack whereas in plain assembler (just a simple translation,) you no longer have that overhead.