S
sfx1999
Guest
What assembler do you prefer? I am learning it and am having some problems with some assemblers over others (mainly being that it is hard to find libraries).
- Status
M
Micky
Guest
I assume you mean for x86? You've got a choice between NASM and binutils. I'm using binutils, because I work a lot on non-x86 platforms and it is trivial to make cross-compilers with it.
Libraries are mostly a feature of the linker, and on a lot of platforms they're just archives of object files with a shared symbol table. In assembler you can use any library you use normally on your platform, it is just a bit more work: each function is just a symbol in the symbol table, and you have to manually set up the correct parameters either in registers or the stack.
Libraries are mostly a feature of the linker, and on a lot of platforms they're just archives of object files with a shared symbol table. In assembler you can use any library you use normally on your platform, it is just a bit more work: each function is just a symbol in the symbol table, and you have to manually set up the correct parameters either in registers or the stack.
M
mirex
Guest
Please explain what "libraries" do you have in mind.
I was using the tasm which was packed to ooold Turbo Pascal / Turbo C++ and it worked for my needs.
I was using the tasm which was packed to ooold Turbo Pascal / Turbo C++ and it worked for my needs.
M
Micky
Guest
By the way, it is normally more efficient (as in time you invest in programming vs. program efficiency) if you write your program as normal in whatever high-level language you prefer and just implement the hot spots in assembler, after profiling and debugging them. This way you only have to worry about the interface between the assembler code and your program, which you can design any way you want, and not about the interface to all the other libraries your program may need. And people from the 100% assembler crowd sometimes have a very poor programming style in general and hide this by writing "optimised" (=unintelligible) code in assembler.
As you want to learn assembler you most likely need some code to read and write files and print some results. Or it may be even better if you prepare the data you want to process in a high-level framework. Then you can use most of the normal debugging environment you'd normally use as well.
As you want to learn assembler you most likely need some code to read and write files and print some results. Or it may be even better if you prepare the data you want to process in a high-level framework. Then you can use most of the normal debugging environment you'd normally use as well.
Last edited:
S
Sukaeto
Guest
Remember people: premature optimization. It's good (VERY good) to learn an assembly language - but I wouldn't suggest trying to write too much useful stuff in it. Most compilers today do "good enough" code improvement, and algorithm improvement gives you far greater performance increases than code improvement ANY day.
C
Cyberman
Guest
Unless it's dealing with SSE SSE2 SSE3 or mmx instructions.
Of which none of the MS compilors do a good job with. The assumption they will is a bad idea.
I don't know if GCC does a very good job with them either. Parallelism and multiple variables etc. being manipulated is a bit difficult for a compilor. Although most code has been well beaten there are still somethings the compilor can't make up for. There are many DSP compilors but all of them have a custom backend for code optimization.
Making clean code does ussually yield the greatest benefit. However I recomend not jetisoning knowledge of the low level machine because 'The compilor will do a better job'. Always compare. First optimize the code then tweak the low level is my policy. I prefer to generate assembler and view what the compilor made then decide wither to Assemble or not.
Cyb
Of which none of the MS compilors do a good job with. The assumption they will is a bad idea.
I don't know if GCC does a very good job with them either. Parallelism and multiple variables etc. being manipulated is a bit difficult for a compilor. Although most code has been well beaten there are still somethings the compilor can't make up for. There are many DSP compilors but all of them have a custom backend for code optimization.
Making clean code does ussually yield the greatest benefit. However I recomend not jetisoning knowledge of the low level machine because 'The compilor will do a better job'. Always compare. First optimize the code then tweak the low level is my policy. I prefer to generate assembler and view what the compilor made then decide wither to Assemble or not.
Cyb
S
sfx1999
Guest
By libraries, I mean it is almost impossible to find GLUT libraries and such. I've looked into the GNU assembler; I didn't like the syntax and it lacks the ability to align data, which I believe SSE requires.
I've tried NASM and I don't like it's inability to output to the PE format. FASM can do this, but it lacks good command line options. I considered MASM32, but I didn't like the license. I looked into YASM, but as far as I can tell, it has the same problems as NASM.
I've tried NASM and I don't like it's inability to output to the PE format. FASM can do this, but it lacks good command line options. I considered MASM32, but I didn't like the license. I looked into YASM, but as far as I can tell, it has the same problems as NASM.
M
Micky
Guest
A lot of things would break if you couldn't align data.
Have a look at ".align" or ".balign" in the GNU assembler. I normally use .balign, because the behaviour of .align depends on the architecture.And I'd like to repeat: It makes more sense to handle any OpenGL or GLUT in a C/C++ framework. You don't gain any speed, and just make it extra hard for yourself, especially if you're learning. But you should be able to use any .lib files that you can use from a C compiler / linker, you just have to set up the procedure calls manually.
S
Sukaeto
Guest
with gcc: just pass the -msse flag. I'm pretty sure there's a -msse2 flag, and probably an -msse3 flag as well.
I never said to completely ignore learning an assembly language. It's good to understand the architecture of the machine you're working with - but that doesn't mean you should ever DO anything in assembly.
Think about it: if you're spending too much time worrying about what to keep in registers and what to store to memory, or making sure things are .aligned properly, you're not going to be able to devote your time to making sure your ALGORITHM is efficient. At the end of the day, Algorithm efficiency gets you way more than code efficiency - the compiler is probably doing a better job than you think it is (or else you need to complain to the writer of the compiler for doing a sh*tty job on it.) A well written algorithm in Java - no wait, scratch that, Java just sucks that bad . . . a well written algorithm in <C, Ada, Delphi, LISP, take your pick> will out-perform a poorly written one in human-generated assembly code ANY DAY.
Why do you think most modern chips (besides the sh*tty x86) are using RISC architectures? They're designed to cater to the compiler, NOT the programmer.
Last edited:
- Status