41–50 of 90 posts
Anyway, the hardest step for me in learning a language is when I take some running code and make one change to see what happens. Once I get in the swing of it, it gets much easier, but that first step is still hard to do.
By the way, I would love any feedback on this approach and where I should take this further.
There are a couple of great (free) resources on 32bit x86 assembly I'm aware of:
http://www.drpaulcarter.com/pcasm/ http://www.plantation-productions.com/Webster/HighLevelAsm/i...
There's apparently some plans on upgrading HLA to x86_64 -- I don't know of any good tutorials or guides on working on 64bit assembly specifically I'm afraid.
Just adding "-S" and looking at the source can be helpful of course, although I much prefer nasm/intel syntax, for clang/gcc that should require:
clang -S -mllvm --x86-asm-syntax=intel main.c
gcc -S -masm=intel main.c
It looks like clang might be generating less "noise" for tiny trivial programs, here's a side by-side-diff (in intel syntax) of int main{} vs int main { return 0;} (slightly reformatted):
diff --side-by-side main.s main.no-ret
.file "main.c" .file "main.c"
.text .text
.globl main .globl main
.align 16, 0x90 .align 16, 0x90
.type main,@function .type main,@function
main: # @main main: # @main
.cfi_startproc .cfi_startproc
# BB#0: # %entry # BB#0: # %entry
mov EAX, 0 mov EAX, 0
mov DWORD PTR [RSP - 4], 0 This situation is why there is "hello world"; that program seems trivial but actually has important implications; for instance, that your environment works, that you know how to feed programs to the compiler, that you can actually run the output. I never took "hello world" seriously until I started doing embedded systems work; it's now an extraordinarily important tool for me (I work an anomalously weird number of di…
I once had a particularly slow week at work, and decided to write an article about how "Hello World" works in C. How it really works -- including compiling, linking, system calls, operating system involvement, hardware I/O, communication between ICs, etc. The path from the block of text to photons emitting from the screen, with fairly detailed explanations at every level. I ended up with a 50 page LaTeX document that…
Earlier quoted context omitted.
Are you trying to dispute the fact that `main()` is THE entry point for any C program? I'd be interested in hearing a more comprehensive explanation.
To some extent, _start is ( https://blogs.oracle.com/ksplice/entry/hello_from_a_libc_fre... ), so you can make a working program that has no main(). And in general entry points are a quirky land heavily dependent on OS and compilation stack.
I'm not trying to nitpick but I'm worried newcomers to the language might be misled by your comments, the things you're talking about are not a concern for most coders unless they have to do things like low level embedded code, bootloaders and things like that. And then your entrypoint won't be "start" anyway, it'll be the reset vector or some lower stage jumping to a specific address for instance.
I learned C by reading K and R and doing the book's exercises . . . on paper. At the time I didn't have access to a C compiler, so I wrote them all out in a notebook. A month later I got a job at a shop that was running Unix, and got the chance to type my programs in and try them. I had a lot of things wrong. It took me a while to understand the difference between control-D and EOF, for instance (how embarrassing). B…
People don't like K&R? I can understand it not being suitable for children and the very beginner, but it's one of a very few programming books that is useful, succinct, pragmatic, doesn't get bogged down in APIs, and is written clearly. (The companion book "Programming in the UNIX environment" is the get-you-started guide from the very beginning, although it assumes 1970s terminal defaults)
This situation is why there is "hello world"; that program seems trivial but actually has important implications; for instance, that your environment works, that you know how to feed programs to the compiler, that you can actually run the output. I never took "hello world" seriously until I started doing embedded systems work; it's now an extraordinarily important tool for me (I work an anomalously weird number of di…
I once had a particularly slow week at work, and decided to write an article about how "Hello World" works in C. How it really works -- including compiling, linking, system calls, operating system involvement, hardware I/O, communication between ICs, etc. The path from the block of text to photons emitting from the screen, with fairly detailed explanations at every level. I ended up with a 50 page LaTeX document that…
I learned C by reading K and R and doing the book's exercises . . . on paper. At the time I didn't have access to a C compiler, so I wrote them all out in a notebook. A month later I got a job at a shop that was running Unix, and got the chance to type my programs in and try them. I had a lot of things wrong. It took me a while to understand the difference between control-D and EOF, for instance (how embarrassing). B…
fortunately I wandered into a company that had even less of a clue than me. It's nice to be an expert on day one with only two days' of expertise :)
I learned a hell of a lot in a year. Great year.
Earlier quoted context omitted.
To some extent, _start is ( https://blogs.oracle.com/ksplice/entry/hello_from_a_libc_fre... ), so you can make a working program that has no main(). And in general entry points are a quirky land heavily dependent on OS and compilation stack.
A C program starts at the function "main", what you're discussing here is beyond the scope of the C language. C without the libc or any other form of runtime is not standard C. I'm not trying to nitpick but I'm worried newcomers to the language might be misled by your comments, the things you're talking about are not a concern for most coders unless they have to do things like low level embedded code, bootloaders and…