•
•
•
•
What is DaniWeb IT Discussion Community?
You're currently browsing the Assembly section within the Software Development category of DaniWeb, a massive community of 422,819 software developers, web developers, Internet marketers, and tech gurus who are all enthusiastic about making contacts, networking, and learning from each other. In fact, there are 3,338 IT professionals currently interacting right now! Registration is free, only takes a minute and lets you enjoy all of the interactive features of the site.
Please support our Assembly advertiser: Programming Forums
Views: 4559 | Replies: 26
 |
•
•
Join Date: Jan 2007
Posts: 49
Reputation: 
Rep Power: 2
Solved Threads: 0
Light Poster
•
•
•
•
Originally Posted by Ancient Dragon 
C language, for example, is portable as long as (1) the programmer sticks to ansii C standard functions and (2) there is a c compiler targeted for the platform.
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.
•
•
Join Date: May 2006
Location: Bellevue, WA
Posts: 1,548
Reputation:
Rep Power: 8
Solved Threads: 51
•
•
•
•
Originally Posted by Ancient Dragon
>>If we confine our discussion to x86 hardware
claiming a program is portable makes no such restriction, and neither do I.
I believe Evenbit's argument arose from this phrase, which implies a focus on OS rather than hardware:
•
•
•
•
Originally Posted by Ancient Dragon
If you are looking for portability between operating systems, such as *nix and MS-Windows, then you should stay clear of assembly -- it ain't portable.
Last edited by Ancient Dragon : Jan 10th, 2007 at 5:50 pm. Reason: edit was mistake
•
•
Join Date: Aug 2005
Location: near St Louis, Missouri, USA
Posts: 11,116
Reputation: 
Rep Power: 38
Solved Threads: 929
*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)
I think it's about time we voted for senators with breasts. After all, we've been voting for boobs long enough. ~Clarie Sargent, Arizona senatorial candidate
Those who are too smart to engage in politics are punished by being governed by those who are dumber. ~Plato
Those who are too smart to engage in politics are punished by being governed by those who are dumber. ~Plato
•
•
Join Date: Jan 2007
Location: jena/germany
Posts: 4
Reputation:
Rep Power: 0
Solved Threads: 0
Newbie Poster
•
•
•
•
Originally Posted by Ancient Dragon
*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?
•
•
Join Date: May 2006
Location: Bellevue, WA
Posts: 1,548
Reputation:
Rep Power: 8
Solved Threads: 51
•
•
•
•
Originally Posted by howlingmadhowie
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)
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.
•
•
Join Date: May 2006
Location: Bellevue, WA
Posts: 1,548
Reputation:
Rep Power: 8
Solved Threads: 51
•
•
•
•
Originally Posted by Ancient Dragon
*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)
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):
include $ ls acpi asm-frv asm-m68k asm-s390 asm-v850 media sound asm asm-generic asm-m68knommu asm-sh asm-x86_64 mtd video asm-alpha asm-h8300 asm-mips asm-sh64 asm-xtensa net asm-arm asm-i386 asm-parisc asm-sparc config pcmcia asm-arm26 asm-ia64 asm-ppc asm-sparc64 linux rxrpc asm-cris asm-m32r asm-ppc64 asm-um math-emu scsi
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.
•
•
Join Date: Jan 2007
Location: jena/germany
Posts: 4
Reputation:
Rep Power: 0
Solved Threads: 0
Newbie Poster
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.
•
•
Join Date: Jan 2007
Posts: 15
Reputation:
Rep Power: 2
Solved Threads: 0
Newbie Poster
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
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
•
•
Join Date: May 2006
Location: Bellevue, WA
Posts: 1,548
Reputation:
Rep Power: 8
Solved Threads: 51
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.
•
•
Join Date: Jan 2007
Posts: 15
Reputation:
Rep Power: 2
Solved Threads: 0
Newbie Poster
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
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
|
•
•
•
•
•
•
•
•
DaniWeb Assembly Marketplace
•
•
•
•
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
Linear Mode
- Previous Thread: urgent i have only 24 hours
- Next Thread: MC68000/..332 Calculator
