Is there something like SPARC or other RISC architectures?
See the RISC-V User-Level ISA Specification v2.0 [1]. It's more detailed but still fairly easy reading.
A fundamental introduction to x86 assembly programming
41–50 of 78 posts
Re: A fundamental introduction to x86 assembly programming
#42Earlier quoted context omitted.
Yes there are... I wouldn't recommend starting with SPARC Asm though, it's nowhere near as fun as a CISC like x86, nor as easy as MIPS (which tends to be the "boring" go-to architecture CS courses use.) ARM is more interesting than MIPS and easier than x86.
I've done a little bit of x86 and I have to say I'm not very impressed by some of it. It seems like the lowest common denominator where nothing 'fun' happened. ARM has a few ecosystem problems that I'd rather not deal with. From what I understand there is a lack of hardware discovery. ARM is more embedded then 'user' computer. Nothing is swapable.
You might find these size-optimisation challenges more fun:
http://www.hugi.scene.org/compo/compoold.htm
The 256B and below categories in the demoscene are also sources of interesting x86 Asm programs:
Re: A fundamental introduction to x86 assembly programming
#43Is there something like SPARC or other RISC architectures?
Yes, The SPARC architecture manual. Punch that into Google or DuckDuckGo and it should be the second link (you want the SPARC V9 instruction set architecture). I would post the link I found, but since I actually have the physical book, I'm uncertain as to whether posting a link to a PDF of a possibly copyrighted book would get me in trouble with Hacker News or not. I've done some SPARC assembler programming for fun,…
It shouldn't be a problem to link to it, because you can find a newer version of it sitting on Oracle's site as well as SPARC's official site:
http://sparc.org/technical-documents/specifications/
are generally known to be slow when it comes to non-parallelized, number crunching performance
I think that's due to a similar set of design decisions that lead to the Itanium also being an amazing benchmark performer, but dismal in "general purpose" code. IMHO SPARC and Itanium are architectures that have optimised heavily for the sort of massively parallel, predictable/few branches, predictable-memory-access-pattern that "high performance computing" benchmarks show off, but at the expense of the small, branchy, less predictable "serial byte/bit manipulation" that tends to be common in other, more general-purpose code. To use a car analogy, it's like a dragster vs. a rally car.
Re: A fundamental introduction to x86 assembly programming
#44I was surprised to read that x64 apparently doesn't allow pushing or popping 32-bit values. I have a language that uses 32 bits as the basic unit for all values and I'm working toward x64 code generation. Should I just promote values to 64 bits and waste half the stack? Should I use mov instructions instead of push/pop? What solutions are other compiler-writers using?
Re: A fundamental introduction to x86 assembly programming
#45A very nice book about assembly programming is "Assembly Language Step-by-Step: Programming with Linux, 3rd edition" ( http://www.amazon.com/dp/0470497025 ). The nice thing about this book is that it guides the reader at understanding how the machine works first, and only then to assembly programming. The sad thing about this book is that it references 32 bit intel-compatible processors. My guess is that the original…
amd64 is essentially a superset of the 32-bit version, and so it makes sense to understand 32-bit first. Actually, it's more like a half-64-bit extension because not everything is consistently 64-bit and a lot of things like operand sizes and registers actually default to being 32 bits.
Re: A fundamental introduction to x86 assembly programming
#46Isn't it disingenuous to call esp/ebp (or rsp/rbp) general purpose registers considering there are instructions that implicitly assume esp/rsp is the stack pointer (push, pop, call, ret, ...).
Re: A fundamental introduction to x86 assembly programming
#47If you want to learn x86 assembly, I recommend one of my favorite books Programming From The Ground Up: http://savannah.nongnu.org/projects/pgubook/ (free pdf!) This is a practical book and teaches assembly programming on Linux. Author Jonathan Bartlett wrote this book because he was frustrated to no end with the existing books. At the end of them he could still ask, "How does the computer really work?" and not have…
For "How does the computer really work?" questions, I recommend this book:
Re: A fundamental introduction to x86 assembly programming
#48I was surprised to read that x64 apparently doesn't allow pushing or popping 32-bit values. I have a language that uses 32 bits as the basic unit for all values and I'm working toward x64 code generation. Should I just promote values to 64 bits and waste half the stack? Should I use mov instructions instead of push/pop? What solutions are other compiler-writers using?
> I was surprised to read that x64 apparently doesn't allow pushing or popping 32-bit values.
A simple way to circumvent this problem (I don't claim it is the best) is
sub rsp, 4
mov eax, [rsp]
Re: A fundamental introduction to x86 assembly programming
#49Isn't it disingenuous to call esp/ebp (or rsp/rbp) general purpose registers considering there are instructions that implicitly assume esp/rsp is the stack pointer (push, pop, call, ret, ...).
> Isn't it disingenuous to call esp/ebp (or rsp/rbp) general purpose registers
In the sense of instruction encoding they are. Additionally, the x86-64 call convention typically does not use ebp as frame pointer (except when you use something like alloca). Instead functions typically allocate their nessesary stack amount at the begin. So ebp is generally used as a general purpose register by most compilers in x86-64.
Re: A fundamental introduction to x86 assembly programming
#50I was surprised to read that x64 apparently doesn't allow pushing or popping 32-bit values. I have a language that uses 32 bits as the basic unit for all values and I'm working toward x64 code generation. Should I just promote values to 64 bits and waste half the stack? Should I use mov instructions instead of push/pop? What solutions are other compiler-writers using?
x86-64 is really oriented around integer values being 64-bits. For example, 32-bit operations will zero-extend the result to write the full 64-bit integer register. The ABI also assumes integral values are promoted to 64-bits and the stack is 64-bit aligned on calls.
That said, as long as you keep RSP aligned you can do whatever you want. Consider this code:
extern void value(int* a, int* b, int* c);
int main() {
int a, b, c;
value(&a, &b, &c);
return a+b+c;
}
subq $24, %rsp
leaq 20(%rsp), %rdi
leaq 16(%rsp), %rsi
leaq 12(%rsp), %rdx
callq value
movl 16(%rsp), %eax
addl 20(%rsp), %eax
addl 12(%rsp), %eax
addq $24, %rsp
retq