C has issues a programmer needs to keep in mind if they want truly portable code that go well beyong the RTL.

The standard is full of the weasle words "implementation defined" and "behavior is undefined".

One of the biggest issues is non-crisp semantics for data types. That was something ADA took on directly and actually resolved in its spec. ADA semantics are dictated 100%. C punts quite often - you don't even know if a 'char' is going to be signed or unsigned by default in any given C implementation.

People who write genuinely portable code for a living get around most this with lots of synthetic types, extensive use of limits.h, sizeof() and a keen eye to where some snip of bit banging code might not be word endian neutral or word size neutral. The vast majority of C programmers in the world don't exhibit that kind of dicipline though.

I believe Evenbit's argument arose from this phrase, which implies a focus on OS rather than hardware:

*nix often does not run on the same hardware as MS-Windows. For example we have a lot of linux systems that run on Sun workstations with RISK processors (I think they are RISK)

the sparc architecture is a RISC architecture with pipelining. the pipelining leads to real problems trying to write assembler for it if you're used to the x86 type (which i am used to)

one of the problems is that the pipelining means that assembly for sparc systems knows what's going to happen before it happens. basically, the address of the next command is fetched before the current command is executed. so a jump like this:
a=3;
b=2
goto some_label;

would be in sparc assembly:
mov 3, register_for_a
jmp some_label
mov 2, register_for_b

because the address for the last instruction would already be in memory before the second instruction is executed.

wierd, huh?

You do realize that a Pentium 4 has something like 40 pipeline stages, don't you? Pipelining is one of the most basic ways to increase throughput on a processor, though it does add a good deal of complexity to the design.

I think a more correct phrasing would be that Windows does not run on the same hardware as *nix...

While the statement is true, you should also consider that Windows comes as a binary installer for x86, whereas Linux sources (which I'm most familiar with in the *nix family) have separate source codes for different architectures. For instance, here's the contents of the $(SOURCE)/include directory (where ./asm/ is a symbolic link to the local architecture):

You'll notice if you download an image of a linux installation (e.g. for a live CD) that you do have to choose the approriate image for your architecture.

yep, i knew that theoretically, but practically, i've never taken it into account while coding. maybe that explains why my assembler programms are so slow.

Hi,

After having developed software using HLL's for years, now I use Assembly Language for ALL my programming needs: small and very fast applications, no bloat, no dependencies (huge dll's), VERY easy to develop http://www.codeproject.com/script/im...miley_wink.gif and above all, I can do anything I want without facing any HLL limitations. You can give a look at this article: http://www.codeproject.com/useritems...bleriseasy.asp

Regards,

Antonis Kyprianou

I would bring into question your programming needs. Most HLLs will tradeoff optimal efficiency for greatly reduced development time or increased code readability. Furthermore, assembly will limit your program to a specific architecture and OS, whereas with Java for example, you can take your code (or your .class file) and run it anywhere with a JVM.

My programs are intended to be used under Windows 32-bit or 16-bit DOS. Others target linux or other OS's, but yes, I don't develop cross platform applications. Other than that, I am able to develop small and very fast applications, no bloat, no dependencies (huge dll's), VERY easy to develop http://www.codeproject.com/script/im...miley_wink.gif and above all, I can do anything I want without facing any HLL limitations.

Code readability is another myth against Assembly. Microsoft Macro Assembler (MASM), for example, looks VERY similar to C code and is no harder to learn. I would say that it is easier.

Final point. Among others, I used VB (one of the easiest to learn and quickest to develop with languages) a lot before switching to Assembly and found no real problems to do so.

Regards,

Antonis