> xor rbp,rbp /* xoring a value with itself = 0 */
Is this faster than a (const) mov ?
Writing C software without the standard library
21–30 of 188 posts
Re: Writing C software without the standard library
#22Fantastic until you need to malloc. You're reimplementing libc, but at least you know what's going on at every level.
Unless you also need to free, it's pretty simple.
Of course.
When I wrote that comment I asked myself should I have written "malloc" or "malloc/free" - surely one implies the other.
Re: Writing C software without the standard library
#23> xor rbp,rbp /* xoring a value with itself = 0 */ Is this faster than a (const) mov ?
Traditionally yes. On the latest CPUs - who knows.
Re: Writing C software without the standard library
#24> Executables are incredibly small (the http mirror server for my gopherspace is powered by a 10kb executable). Is this ever an real issue, even on any embedded system in the last 20 years?
> Is this ever an real issue, even on any embedded system in the last 20 years?
Ask Cisco when they cut the Linksys routers' RAM in half a few years ago. Every byte counts. Component cost savings add up when you make a few million of them.
Re: Writing C software without the standard library
#25Some of the reasons that he mentions for avoiding the standard library could also be mitigated by using another library like dietlibc (I played around with it back in the day, last release seems to be from 2013): https://www.fefe.de/dietlibc/
Re: Writing C software without the standard library
#26Your first paragraph makes me wish this site supported Markdown.
Re: Writing C software without the standard library
#27> xor rbp,rbp /* xoring a value with itself = 0 */ Is this faster than a (const) mov ?
Traditionally yes. On the latest CPUs - who knows.
Probably yes, because Intel knows this is the code every compiler outputs for zeroing a register.
Also, the reason it is "faster" is that the encoding is 1 byte, vs. 9 bytes (in 64 bit) for "mov rbp, 0" - roughly, 1 for "mov rbp,", 8 more for a 64 bit "0".
Re: Writing C software without the standard library
#28This is required if you do systems programming (e.g: kernel development).
Or demo coding on old hardware. I sometimes write demos for the Atari ST (68000-based home computer launched in 1985), and the modern way of doing that is to develop on a modern computer, and cross-compile to a native ST executable. The main loops are all assembler, but the support code is in C, but the C code is used as a more expressive assembler, and linking with libc requires way too much memory. All this means t…
I'm curious what the use case of memcpy is in highly-optimised software. Are there any scenarios where copying bytes is better than using a char*+length tuple?
Re: Writing C software without the standard library
#29He 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.
> He claims that your code will be easy to port but then goes straight to Linux system calls. Many linux developers believe "code is portable" means "can run on different linux distros". Edit: To be fair, he said architectures, and i think he meant CPU architectures, i.e. AMD64 and i386.
But still, Linux syscalls are different on each architecture.
Re: Writing C software without the standard library
#30This is required if you do systems programming (e.g: kernel development).
Or demo coding on old hardware. I sometimes write demos for the Atari ST (68000-based home computer launched in 1985), and the modern way of doing that is to develop on a modern computer, and cross-compile to a native ST executable. The main loops are all assembler, but the support code is in C, but the C code is used as a more expressive assembler, and linking with libc requires way too much memory. All this means t…
[deleted]