101–110 of 188 posts
"It's often necessary to either push useless data or simply align the stack pointer when the pushed values don't happen to be aligned."
That's kind of hand-wavy. How do we "simply align the stack pointer"?
He claims that your code will be easy to port but then goes straight to Linux system calls. Still I like the idea. This is something that should be covered in a CS 102 type course. I know way to many cs guys who have no idea how to debug, let alone how their is being implemented.
When I was learning C, I loved Plauger's book on the standard library for just that reason; it's very informative to be guided through the implementation of the whole thing, not only to see how it works, but it's also a good way just to be introduced to everything in it without any magic. It's an excellent 2nd book on C, I think.
I had a question about this sentence: "It's often necessary to either push useless data or simply align the stack pointer when the pushed values don't happen to be aligned." That's kind of hand-wavy. How do we "simply align the stack pointer"?
Earlier quoted context omitted.
When I was learning C, I loved Plauger's book on the standard library for just that reason; it's very informative to be guided through the implementation of the whole thing, not only to see how it works, but it's also a good way just to be introduced to everything in it without any magic. It's an excellent 2nd book on C, I think.
What is the title of the book by Plauger you are referring to?
I had a question about this sentence: "It's often necessary to either push useless data or simply align the stack pointer when the pushed values don't happen to be aligned." That's kind of hand-wavy. How do we "simply align the stack pointer"?
Of course, you now need to keep track of the old stack pointer so you can restore it. Most code saves the old stack pointer into the fp, so you can just do sp = fp to undo any pushes without needing to care about how much was pushed; but it's cleaner and more efficient to have the compiler arrange things on the stack so that everything's already aligned and you don't need to do it programmatically.
...why, yes, I have spend the past couple of months with my head buried inside a compiler backend; why do you ask?
A value in the range between -4095 and -1 indicates an error, it is -errno. The syscall/errno stuff has always seemed unusual, inelegant, and inefficient --- instead of just returning a negative error code directly, the function returns the vague "an error has occurred" -1, and you have to then check errno separately after that. It only adds insult to injury when you realise that the kernel itself isn't doing it, but…
> At least on Linux the first few (i.e. the oldest, most common and useful) syscalls have not really moved around over the years IIRC raw syscalls are an officially supported kernel API, that's why you can have alternate libc implementations (e.g. musl), and Linux is an oddity in that, on most systems even if the syscalls are fairly stable there are no actual guarantees with respect to them, and the only officially s…
Earlier quoted context omitted.
> At least on Linux the first few (i.e. the oldest, most common and useful) syscalls have not really moved around over the years IIRC raw syscalls are an officially supported kernel API, that's why you can have alternate libc implementations (e.g. musl), and Linux is an oddity in that, on most systems even if the syscalls are fairly stable there are no actual guarantees with respect to them, and the only officially s…
golang also targets syscalls instead of the C standard library (or other libraries except for windows, and maybe others), which is interesting on e.g., Darwin: https://github.com/golang/go/issues/17490
Earlier quoted context omitted.
> At least on Linux the first few (i.e. the oldest, most common and useful) syscalls have not really moved around over the years IIRC raw syscalls are an officially supported kernel API, that's why you can have alternate libc implementations (e.g. musl), and Linux is an oddity in that, on most systems even if the syscalls are fairly stable there are no actual guarantees with respect to them, and the only officially s…
golang also targets syscalls instead of the C standard library (or other libraries except for windows, and maybe others), which is interesting on e.g., Darwin: https://github.com/golang/go/issues/17490
Earlier quoted context omitted.
But still, Linux syscalls are different on each architecture.
Indeed, stupidly different. Different syscall numbers, different argument orders, different values for constants, different struct layouts, ... Some architectures, like MIPS, are particularly bad, with nods to Irix compatibility thrown in. The BSDs are all exactly the same for every architecture, sane.
The guy is definitely a fan of old-school minimalism: http://weeb.ddns.net/0/articles/modern_software_is_at_its_wo... I have to say I miss the old days of Gopher, too. It was so much easier to focus on the content back then.