ASM programming, which type of processor is popular now?

[Pixel_Outlaw]

With the demoscene virtually unknown in the US, you guys are my best resource for information.

What processors are most ASM programmers making demos for? Granted I understand that everyone has their favorite.

64 bit is the norm now with computers but are the ASM coders still working heavily with the x86?
One other question, since the assembly code very low language, how dependent on the OS is it?
I'm hardly on a Windows PC anymore and it would be nice to code ASM that ports easily! When you work with ASM are you still confined to the OS HAL or do you bypass that?

[hellfire]

On PC assembly got almost irrelevant for speed with the advent of gpus in the late 90s.
But it's still the only option for *very* size limited stuff like 256 byte dos (16 bit)  intros (example).
For hardware with limited resources (eg Amiga) some bits and pieces of assembly are usually inevitable (even though very good c compilers are available).
8-bit platforms (C64, VC20, Amstrad CPC) are usually asm-only.

On x86 there's the intel- (used under dos and windows) and the at&t-syntax (commonly used under linux).
If you like one of them you usually hate the other.

[Pixel_Outlaw]

Thanks Hellfire.

Do you think that interest has dropped a huge amount in the the area of assembly coding?
Honestly I sort of like the idea of spoonfeeding the processor only what it needs.

I did purchase a book with dipped into assembly on the x86 processor but I noticed when I decompiled the C program it didn't quite match what the author had. (Hacking: the Art of Exploitation) Must be a difference in the tools or something. I was shocked to see a simple "Hello World" compiled in C balloon out into hundreds of lines of ASM!

[hellfire]

Do you think that interest has dropped a huge amount in the the area of assembly coding?

Yes, absolutely.
For several reasons:

1. We've got very good compilers which generate pretty good code within nanoseconds.
Even for a relatively trivial task an experienced programmer would take a couple of minutes to come up with equally good code.
But this doesn't make sense for absolutely uncritical parts of your code.

2. CPUs got increasingly complex and everyone has it's own optimization rules
Nowadays a CPU consists of many parallel arithmetic units and it's extremely difficult to track the availability at any given moment to minimize stalls.
Even if you've got a perfect hand-optimized solution for one processor, it might run like crap on another.

3. The CPUs don't execute cisc
On x86 half of the processor just handles the pre-processing of the incoming cisc assembly-code and converts it into risc micro-operations which match the actually available units. They even get reordered to take the best advantage of the given resources.
So what you think is the "lowest level" is actually two levels on top.

Nevertheless it's a big plus to understand what's happening on the assembly level.
And there are still many case where the compiler needs some help because it just can't see the obvious.

I noticed when I decompiled the C program it didn't quite match what the author had.

That depends very much on the compiler and the optimization settings you're using.
If you've got a rather simple loop in C the compiler usually unrolls a few iterations to have more possibilities to reorder instructions.
This makes the assembly code look horrible and adds another bit of overhead because you have to handle the rest of the elements which didn't fit into the unroll.

[Jim]

asm != speed.
asm == complexity

I've written MILLIONS of lines of assembler in my career, for a good variety of cpus.  Mostly because there wasn't a compiler available.
Latterly I've written assembler to deal with embedded hardware that needed that kind of attention.
Today, I'd hardly even consider getting anywhere near an assembler.

Jim

[Stonemonkey]

asm != speed.

Not always but it can sometimes, while I don't know much about a lot of the optimizations (and pitfalls) the cpu makes while running the program I can fairly easily beat FB and have been able to improve a bit on C++.

asm == complexity

Completely agree, only when you are happy that your c++ or whatever code can't be taken further and does exactly what you want then write in asm, once written in asm it's difficult to change what the routine does to much extent but it is possible to optimize how it does it.

With my obsession with doing things in software it definitely helps and I'm sure what I write could be improved a lot more with the right knowledge.

Michael Abrash's black book has some interesting things about it in it. A lot of it's from his work with older x86 cpus but some of it's still relevant.

http://www.phatcode.net/res/224/files/html/index.html

[jace_stknights]

asm != speed.
asm == complexity

I've written MILLIONS of lines of assembler in my career, for a good variety of cpus.  Mostly because there wasn't a compiler available.
Latterly I've written assembler to deal with embedded hardware that needed that kind of attention.
Today, I'd hardly even consider getting anywhere near an assembler.

Jim

hmmmm I don't agree completly with the speed! Like you I've also coded millions of lines on several cpus, and for optimisations reasons compilers are not so good. For examples, on 68030 I was playing with the order of opcode to make the rout work in the cache (it was a torture for the reading). On Powerpc for mac 8-9, you can also make the code running fast if you making the part of memory acces together (I don't remember now how it was working, I've done it one time ) I don't speak about 68000 on Atari, I think I will never be able to make such code on other processor!
But I must admit that on "nowadays" cpu, it is more and more difficult to make optimised routines fastest than the compilers. But it you want to make a specific rout, that runs lot of time in a frame, I think you can still grab some cycles here and here... for the fun  The actual cpus are designed to run several task, in a multitask environment...

 

[Pixel_Outlaw]

So anymore the main value in ASM is to modify already compiled programs without source?

[jace_stknights]

It's a pain to modify actual programs (from Windows, Linux, OSX) in pure assembler: if they have been written in a hight level language as C/C++ they are very BIG, and the code can be in several bin and dependancies everywhere.

You can make this easily with small code like demos, 4k and so on (the source code will be reasonable). For myself, disassembling a program was usefull for me to get my sources back after a disk crash on old computers.

This is used also by crackers to remove some part of code by puttin "nop" opcode(No OPeration) instead of the protect rout.

I think if you're not making stuff on old computers (where assembly IS the language), this could only be a "way of coding", a back to the roots  ... A way to understand completly how the things are running truely. But it will be for small projects.