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 the syscall wrappers. And thanks to POSIX standardising this mechanism, the alternative will likely never get much adoption; of course, if you write your own syscall wrappers like this article, then you can skip that bloat.
For now this guide is linux-only, but I will be writing a windows version when I feel like firing up a virtual machine.
Unfortunately the Windows syscalls are not officially documented and even less stable than on Linux, changing even between service packs.
> 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 supported interface to the kernel is the standard library. OSX does not allow statically linking libSystem for that reason for instance.
IIRC raw syscalls are an officially supported kernel API
The term you are looking for is We don't break userland. Once a systemcall goes live it is engraved in stone. This is why if you look though the syscall table you see call, call2, call_ext.
You're implying that exposing syscalls as the ABI instead of a higher level ABI is the only way to get backwards compatibility but that's not true. OS X can change its syscalls without breaking userland in exactly the way GP says: don't allow static linking of e.g. libSystem and its ABI is the ABI you're expected to use instead of directly calling syscalls.
Sure, Linux makes promises about its syscalls. But that's not the only way to get robust backwards compatibility and as GP says it's the oddity in that respect.
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:
Yeah the linked issue (16570) is the most interesting one, with the Go runtime breaking multiple times in the runup to Sierra as Apple changed the ABI of the underlying gettimeofday syscall.
Wow, that seems like a really bad approach for Go to take. So is anybody actually using Go on OS X? I guess maybe not, if all the real Go deployments are on servers running Linux.
Aha, that's kind of what I'd figured. Work on Mac, deploy on Linux.
It makes me think twice about e.g. using Go as part of the build workflow in a big project if it's going to randomly stop working on various OS X versions.
> What would have been the reasons for targeting syscalls directly instead of the C standard library?
Since the standard library probably assumes (and requires) a C stack, linking against the standard library would require cgo (or some other specific workaround) on non-linux platforms.
I'm guessing it has to do with the fact that you can build go binaries not linked with libc, they also expose syscall.RawSyscall anyway that all the other syscall wrappers call out to last time I looked
Another example: for OpenBSD part of the manual upgrade procedure (not the recommended method, but useful if you don't have a console to run the installer) is to make a copy of /sbin/reboot, because there's a good chance that the new /sbin/reboot you're about to install will have the wrong syscalls for the running kernel.
> Unfortunately the Windows syscalls are not officially documented and even less stable than on Linux, changing even between service packs.
You can get pretty close though; it's possible to skip the C runtime and most of the other user space libraries and call into ntdll directly. Many of the functions it exports are fairly thin wrappers over the system calls.
ntdll.dll is still not a stable API - if you use anything exported from it (excepting a few documented ones), you basically have zero guarantee that your app will still be working with the next Windows update.
I didn't see it mentioned at a cursory glance of the comments, but syscalls != standard library. Standard Libraray for C is that which is defined by the ISO C standard. syscalls are whatever *nix decides them to be. Additionally Standard Library != posix.
Sure, there may be some overlap or interleaving between Standard Libraries, syscalls, and posix, but they are definitely not the same.
Can you elaborate on how "errno"'s design is rooted in the fact that there was no multithreading at the time? I am not understanding the connection. Thanks.
Multithreading usually means that threads share the address space and so can (inadvertently) stomp on each other's "errno". (Hence making it Thread-Local Storage to solve that issue. Doesn't solve the reentrancy issue, though.)
If multithreading were pervasive nobody in their right mind would choose to use a global variable for error status codes.
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.
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.
This dates back to how Linus did the first non-x86 port of Linux to the DEC Alpha. Rather than copying the x86 linux syscall conventions, he used the DEC OSF/1 syscall conventions to ease bootstrapping. This is a perfectly sane approach. But he probably should have reverted to a native syscall numbering rather than leaving this bootstrapping hack in place.
Different platforms have different sets of registers and alignment requirements. You want to pass things in registers if possible. If you want to avoid inefficiency, you need platform differences. And this is all hidden from users and even developers anyway.
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 discovered a little book by him after wading thru recursive descent parsers chapter by Herb Schildt... I don't want to get down on Schildt, I enjoyed that too, he showed some cool stuff..
but Plauger had me thinking that programming could be a craft, an art, a noble intellectual pursuit.
I've written Windows programs without the std library. The Win32 has plenty of replacement functions you can use instead though so it's much less work than what's presented here.
You can get reduced executable size and a lack of dependencies on various msvc*.dlls, without giving up much of the functionality of the C standard library and without having to write it all yourself.
On windows nt, ntdll gets loaded in all processes, it's hardcoded in the kernel (http://gate.upm.ro/os/LABs/Windows_OS_Internals_Curriculum_R...). That's where the loader resides, so you can't go without it. And that's where all the Zw/Nt* functions/ i.e. where the syscalls are.
Suppose you want to port to some architecture not supported by libc. If you were using libc you would have to find a replacement that works and targets that arch or port libc yourself.
If you wrote everything from scratch, instead, you just have to read the specification and add support to your code.
That's what I meant.
Of course, if your target archs are all supported by libc, porting is much easier with libc.
Well, not if you expect that you will have exactly the same time/space behaviour and pre/post conditions.
This is why lots of embedded, secure and defense software doesn't use standard libraries, and printf will instead be called sio04583 or something....
Also.. Don't forget that you can get gcc to get rid of unused code when compiling static executables, and use sstrip (yes, two 's' - it's a different program) to strip even more, if it's an ELF binary...
Depending on the scope of your project porting libc itself might be good idea. Then you simplify porting any tools you need that also use libc. Then you can port a few extra dependencies, then more tools...
But at least now you know what's in there, what's going on behind the scenes. And on top of that, it's filled with all sorts of brand new bugs and vulnerabilities! ;-)
Not exactly syscall ids: I built network services (telnet daemon, snmp client and server, DNS) that compiled without change for win32 (both on Windows and some embedded win32 compatible abomination) and Linux with just a handful of defines and function wrappers as part of a contract once. A lot of apps can get away with very narrow interfaces to the OS.
That's not portable even across versions of the same OS, many OS don't support raw syscalls and don't make any guarantees about them. That's why you can't statically link libc on OSX for instance, libSystem is literally the system's interface and necessarily dynamically linked.
It doesn't abstract anything, if the syscall changes your "abstract a bit" will be broken all the same. On many if not most OS the machine code side of the syscalls can change with no notice, Windows has changed syscalls in minor revisions, Go broke several times during the Sierra beta due to syscall changes (because it handrolls gettimeofday(2) whose assembly calling convention changed).
The proper abstract interface on non-linux systems is the standard library.
The userspace/kernel interface for invoking syscalls which the OP calls with assembly code is obviously not portable. Not even between similar OSs on one architecture and absolutely not between architectures.
POSIX only specifies a set of C library functions. Once you stop using them, you are on your own.
* The space savings are moot as other processes such as the daemons are going to load libc into virtual memory anyway, and the kernel shares libc's page among all processes.
* This adds a lot of LOC you have to maintain, instead of shoving it off on the compiler/libc vendor, this increases the chance of bugs.
* This will prevent the use of VDSOs to optimize high volume system calls like gettimeofday.
* It's still probably good to know how these happen, even if you're not doing them yourself.
* The only place this would really see benefit is in a single process environment, however in those cases I would suggest a unikernel anyway for simplicity sake.
I'd be interested to see benchmarks to consider point one. At face value, I fully agree with your point and doubt it has any benefit. However, it is less that has to be swapped in for your program to run. Would be curious if this has an odd cache friendliness for an application.
The tooling answer to this, it seems, would be to support statically linked libraries. But again, I would want to see numbers before personally worrying about this.
So a few things to consider in regards to point 1:
* Your executable is going to be loaded as a whole page regardless of how large it is, on most platforms this means you'll need at least 4k of User VM.
* You'll need a page table, which has its own overhead. If someone was going to push back on the libc assertion I'd expect it here, a the PTEs for libc and and the VDSOs cannot be shared between processes (as far as I'm aware).
* I would expect it to in theory RUN faster assuming it was a small toy program like the example, this is because there is less work to be done even with shared pages.
Right, my question is along the lines of avoiding the pages of libc. An easy question here would be how many pages libc takes up. I'm assuming not many, but more than one.
I think there is a strong argument that this page is often already paged into memory from everyone using it. However, if the function you used from it would have fit in the pages you were already using for your application, I could imagine some benefit.
I continue to stress, though, that this is just imagined. Numbers would be first thing I would have to collect before acting on this. (And I hope it doesn't sound like I am tasking you or anyone else with this. That is not my intent.)
At least two is the best answer I can give without specifying a specific libc and architecture. Something to think about is that the binary size of libc is only half the story. Even if the executable portion of libc fits in a single page. A libc implementation has a lot of per thread and per process statics it holds onto.
A good libc developer could actually put these into separate pages based on how often they change. In other words, if a static only is ever set once then coalesce it into a page with other statics that are only set once and are not process dependent.
Why that's important: because of fork, when fork creates a new process it sets the parent processes pages read only and then preforms copy on write when they are modified. In theory you can share both the binary and some of the statics between all the processes.
He spoke about the space savings of the binary itself (which must be debug things and statically linked code). There is no sharing of that , unless multiple processes run that same binary.
Unless the binary size exceeds VM page size this has no real value even in the unshared case. Because the OS is still going to have to map a full page for the executable to be loaded into.
That said techniques to allow a binary to fit under page size do have value; as the unused extra page can be used for other things.
The OS may map a full page for the binary but I'd expect that the time to load the binary from disk to memory would be saved. And once in memory the program would certainly take up fewer cache lines when executed.
That's totally true, and there is more overhead associated to processes. 8K executables are negligible. Some other languages produce executables in the dozens of megabytes.
Because the code that knows how to call the VDSOs is in libc, and how VDSOs work is very architecture dependent. Not saying you couldn't in theory do it. But at that point you might as well just load libc.
I find myself agreeing with him 100%. Not just on Gopher (although i did write a Gopher client some time ago - http://runtimeterror.com/tools/gopher/) but on the entire rant about wasting resources, UIs that waste screen real estate and become unusable in smaller resolutions, fonts that only look good with anti-aliasing and have weird misplaced pixels with antialiased disabled (which i also do), websites that make reading things harder and waste unnecessary resources on bling and fluff with all those javascript frameworks slowing them down, pagination often being replaced with "endless scrolling" which makes it hard not only to skip large bits of content but also hard to see how much content is there in the first place. And of course the newest worst trend of all - using an entire web browser as a UI framework for a text editor (i mean honestly, how people decided that HTML and CSS are the best technologies to use as the foundation for user interfaces?).
The only bit i'd disagree would be with games, at least on AAA games since i have some experience there and -at least at the engine level- there is still a lot of low level wizardry being done there.
> I've even seen functionality regression for the sake of modern and
> "responsive" design in many cases.
>
> For example, you used to be able to browse youtube favorites in
> pages. Whoops, not anymore! Now you need to scroll down and
> painfully wait for the site to make its stupid animation and load
> the next page.
> What's worse is, you can't just skip through pages. You have to
> load EVERYTHING and it all stays loaded, so after 10-20 pages the
> browser starts to lag and hog cpu just to scroll.
I see this issue more and more, scrolling is broken in so many sites,
even popular ones like FB.
Plus, often search doesn't look in the "scrollable" content, i.e. you
need to load (=scroll) all these "pages" and rely on the browser
search function.
Many small things like this, e.g. snippets of code that don't fit the
DIV box and you need to scroll horizontally. And news pages lagging on
a i7 w/ 16Gb or RAM. It's all so sad.
> Plus, often search doesn't look in the "scrollable" content, i.e. you need to load (=scroll) all these "pages" and rely on the browser search function.
That's a feature. They want all this valuable search data so the make you search via the site instead of the browser.
I agree that most of software stack seems bloated and wasteful, but there are good reasons for it. The IT has exploded in last few decades and it's no longer just engineers and computer scientists writing code. If they were, software would maybe be of higher quality, but it would be rare, expensive, and insufficient to support all industries.
Web is especially good example. With all its short-comings, it's still sandboxed and portable platform with very capable (and ugly) programming language for delivering same codebase across desktop and mobile devices (even servers, unfortunately). There are many hits and misses like TODO apps built on Electron, but that's to be expected with any technology and isn't a reason to dismiss all the good applications.
To me, consuming all the hardware resources of each new generation seems to be the price we have to pay to build more complex software in larger and larger quantity.
What's bothering me is that it doesn't seem to be converging in desired unification of different applications and services. Everyone is building their own stacks and environment without much care for interoperability. For example, few years ago it seemed clear that XMPP is a way forward in chat clients that everyone should adopt to enable federation. Nowdays we are expected to have 3+ chat clients installed on phone and remember which contact is on which service. I really don't understand how users put up with it.
That ground is mostly unexplored. IMHO, the sane middle ground between Electron and the 70s isn't shoving an entire browser inside a desktop app. It's using modern programming and compiler techniques to get close to the metal without having to deal with all of the shortcomings of C/C++. It's also using UI libraries that make creating desktop UIs as easy as making a website, but with better performance.
Sadly, neither of the things I mentioned above exist yet. People are working on languages that fit that space, but most of them aren't done yet. Nim is the only one that's officially released.
As for desktop UI libraries, your choice these days seem to be between bad and worse. I'm working on my own desktop UI library, but I don't know what the hell I'm doing. It'll be a learning experience, if nothing else.
You would be well-served to use Qt and Cocoa enough to get familiar with them. You may or may not like the language, but the organization and consistency of both are excellent. In particular, QT's signals/slots, naming consistency, and layouts make writing UIs easy without looking at the documentation (once you've used it a bit). Cocoa is well thought out, but a bit dated. (UIKit is not so well thought out, and forces MVC on you, which is often unnecessary and unhelpful, and then it completely botches UITableView by muddling up the M, V, and C. Qt's QTableView is much saner.) Unfortunately, it's also hard to write a UI in code in Cocoa, since you have to write the positioning system yourself due to no layouts. How they handle different screen resolutions is brilliant, though.
You might also want your UI library to be cross-platform, which will limit your choice of languages, especially if you ever want to port to mobile.
I agree. Something like QML is sort-of what we need, but that is still too closely tied to C++ and not mature enough.
I'm hopeful about Go GUIs though. Go is an easy language to use and performant enough for complex GUI apps. Google abandoned gxui but it seems like they are backing Shiny at least a little.
> The only bit i'd disagree would be with games, at least on AAA games since i have some experience there and -at least at the engine level- there is still a lot of low level wizardry being done there.
He explicitly calls out people "writing poorly performing code on top of pre-made engines". I'm pretty sure he's aiming most of his ire at non-indies using Unity3D or Unreal.
Indie games do this too. My favorite examples are:
Hatoful Boyfriend (remake that uses Unity), a simple graphical choose your own adventure with no animation at all that is painfully slow on my 3-4 year old laptop (although this must be intentional for some reason, it is hard to imagine how that could be achieved purly by abuse of unity)
Lethis - Path of Prgress a 'hipster retro' sim city in a steam punk world that fails to work at all with Intel integrated graphics.
I can get behind some of that, I do hate the argument "it doesn't matter if it's inefficient, modern computers are fast" because everyone taking that stance results in things staying the same speed. When you do encounter modern software that's well optimised and not bloat, it's a real pleasure to be in awe at it's speed (Redis is an example I can think of off the top of my head)
That being said, I'm happy the web isn't still just plaintext or minimally styleable
The comment section where gcc puts in ident info can be omitted with -fno-ident and syscall(2) is usually a very thin wrapper[0]. If you follow the musl syscall(2) it simply maps errors to errno[1] and uses the fancy count-args-in-macro[2] to call off the respective $arch/syscall_arch.h[3] syscall$n numbered functions.
A little self promotion but mostly because it addresses some of the other commenters concerns about malloc (or the lower-level api around sbrk): a couple years ago I wrote rt0 [0], a small (mostly minimal) C runtime for i386 & amd64 that makes it easier to replace libc & crt0 (as long as you have the kernel headers installed). Also, as part of the examples, I wrote wrappers around the sbrk syscall. Pretty easy to do and all documented in the repo. I expect to eventually port the lib to arm (raspberry pi) and aarm64. There's also lots of references to other small c runtimes. I'll be adding this one as well.
You're getting down-voted (Which is unnecessary IMO) but you're really not wrong. `gcc` itself provides `stdint.h`, it's not actually part of libc - or rather, you can use it without actually having a libc in place. Generally this is a good move, because you can always write a `stdint.h` replacement on arch's that don't have one, but on ones that do you're guaranteed to get the types correct.
I'm not interested in the language lawyering, because yes I know the standard provides more freedom to compilers. I just think those definitions are very universal for any real computer that would otherwise run my software. Please don't bring up Windows 3.1, that's about as relevant to most of us a PDP-11.
And for what it's worth, using typedefs based on the above provides more readable printf strings. This is hideous:
Well there's a few things to keep in mind. For one, `sizeof(char)`is guarenteed to be `1` - the standard simply says so. That doesn't mean that a `char` is 8-bits long, however. On certain systems, like TI DSP's, `char` is 16-bits long, and thus `sizeof(short)` is also 1. `sizeof(int)` may be either 1 or 2, I can't recall (both are standards compliant).
All that said, POSIX requires `CHAR_BIT == 8`, which then basically ensures what you wrote to be true. So if you're willing to target POSIX (or POSIX-supporting systems) then such a thing is perfectly fine.
The `stdint.h` types are still better though, IMO, because they make your intentions a lot more clear.
I haven't programming on the PS4, but an 8-byte `int` sound very suspect and fairly unlike (but not impossible). That said, it wouldn't be a huge issue. `short` could either be a 2-byte or 4-byte int (Either would be standards compliant), and `char` would presumably still be byte-sized (Not doing so would be a fairly big issue to deal with).
That leaves out either the 2-byte or 4-byte int from the standard data-types, but you can gain that back by simply using a compiler attribute or compiler-defined type to allow access too it. While that sounds non-standard, it really wouldn't be that bad because it could simply be used in `stdint.h` to expose the standard `int16_t` and `int32_t` types, which could be used like normal.
A lot of good programmers do that and the reason given is that types in stdint.h have ugly long names like uint32_t.
"_t" thing rubs a lot of people the wrong way so I am not surprised they change it to something more pleasant. I like using uint64, int32 etc. but the convention where it's u64, i32, f32, f64 is something I would get behind.
> When we learn C, we are taught that main is the first function called in a C program. In reality, main is simply a convention of the standard library.
Well, I've already learned something new. I assumed that convention was from the compiler. This is a great resource.
While this seems mainly useful as an academic exercise, the `printf "#include <unistd.h>" | gcc -E - | grep size_t` bit to easily grep in header files was worth the read.
It's interesting to read the sources[1] of lots of djb's[2] code, as he often works around problems with (or perhaps dislikes the style of) standard libraries by re-implementing parts.
On a side note, isn't the choice of exactly four unrolls very architecture specific? As in, it works, but may be sub-optimal for your specific machine. I've done the exact same thing myself, and IIRC its performance varied a lot between which ISA it was compiled for.
This is almost what Duff's device solves, except then you need to know the length beforehand.
Absolutely. It's a (possible) optimisation that is either based on evidence (seems likely, because DJB) or hope. Actual behaviour is impossible to predict on untested platforms.
My assumption is that DJB tested this locally and found enough of a speedup that it was worth it, considering the very low added complexity and risk of major degradation / defects on untested platforms.
`malloc`'s not really that bad. There's a few different approaches you can take, but none of them are terribly complicated since the two basic memory allocation interfaces, `sbrk` and `mmap`, are fairly simple in terms of usage for generic allocations. But getting it all working and bug free still takes time. Same with stuff like `printf` and `scanf` (Though I'd actually argue those are harder to write then `malloc` if you're looking to be feature complete. `printf` has billions of features and I'm pretty sure `scanf` requires some extra black-magic internally).
There's no doubt that this is a fun project though - if you or someone-else enjoys this type of stuff, you should definitely try your hand at writing a simple Unix kernel or similar, you'd probably enjoy it.
On that note though, the writers aversion to inline assembly is unfortunate. It's a necessary evil for this type of programming. The syntax is ugly, but it's not really that hard to get used too (Especially since the large majority of inline assembly is just a few lines long, or even just one line long). In particular, the syscall wrappers can be done in a one-line piece of inline assembly, and then you can avoid the function-call overhead for the syscall by placing the inline assembly in a `static inline` function in your headers (Or a macro if you prefer), as well as avoid the extra .S file (Which IMO is the better part - it's always easier when you don't have to mix different languages like that).
I would also add that, while I used to share the aversion for AT&T asm syntax the author does, virtually all of the assembly code out there related to linux is written in AT&T, so it's worth it to get used to it and at least be able to read it. On that note, you can use the Intel syntax in inline assembly though, if you prefer, so even if you hate AT&T with a passion you can still write inline assembly ;)
You can get surprisingly far without using libc's malloc/free. E.g. TeX, the typesetting system by Knuth, implements its own dynamic memory handling. It has a large static array of bytes, and allocates from that when needed.
Arenas are really nice if you're allocating a lot of objects of the same size, whereas malloc() must be prepared to handle a lot of different memory usage patterns.
I don't think it is. Differently sized objects can be allocated and released individually. Have a look at part 9 of [1]. In an arena based allocator you typically deallocate all the objects in an arena at once.
TeX basically uses a special purpose implementation of malloc/free, with a static array as backing instead of memory requested from the OS with mmap(2) or sbrk(2). The main reason is portability (the original version was released in 1978 using WEB/Pascal).
FreeRTOS also provides a few malloc implementations backed by static arrays (not dependent on sbrk), which can be useful for running malloc-based test code on embedded platforms without native malloc: http://www.freertos.org/a00111.html
While one of the benefits of an arena allocator is to be able to deallocate everything at once, it's not that unusual to have an arena allocator that you can deallocate from "early" if needed.
For short-lived processes that do lots of allocations and where you can rely on the OS to release resources, just leaving out the deallocations is often faster.
Of course, you need to be careful as if you write code like that in a language without garbage collection, it's inherently not reuseable - retrofitting deallocation is often really painful because it gets easy to adopt patterns that make object ownership etc. unclear when you don't have to ensure it's easy to deallocate in the right order.
Not surely. Many programs are written in a way that allocates all the needed heap space at startup, and just reuse it forever. And those are overrepresented on the minimal-system kinds of environment.
malloc() isn't particularly hard; K&R provides a working implementation using a freelist and sbrk in about a page of code. It's printf() that's the horrendous feature-crammed nightmare.
Some 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/
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 that I don't even have things like memcpy() available. In a way it's a quite liberating way to program, since you are in full control of the hardware.
I guess yesterday's computers is today's embedded hardware.
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?
There can be hardware-driven requirements that force you to simply have data in a particular place in memory, and if you want that data to hang around you might need to manually move it somewhere else.
There's also the case where your API accepts a pointer and a size, but you don't want to have lingering pointers into the caller's memory, so you have to copy the data over to the "inside" of the API. This kind of design is perhaps less common in demo software, but certainly plausible in embedded products which at least try to be somewhat optimized.
That is exactly it. For example, on the Atari ST you display graphics by copying the bitmaps to the screen address.
Much of the C code is used during precomputation of data before the actual time-critical code is run. This involves copying lots of data in order to set it up so that as little computation as possible is performed in the actual time-critical parts.
I have seen colleagues have to do very similar things on embedded platforms, when there is a large pressure on price, a smaller amount of flash on an MCU will make the MCU cheaper.
> 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.
This is true, but the stdlib provided by the compilers aimed at these chips is usually very bare bones and size-optimized to begin with. So it's likely hard to save much space by reimplementing subsets of it.
Honestly, if I can, I try to cut down on sizes of compiled binaries and even minified and combined web app code. Sure many times it's unnecessary but if I can save on bandwidth and memory typically that means I'm including less crap that can have problems, too. I see it as including far more benefits than simply getting a file size smaller.
But sometimes it can take so much extra work that it's not worth it. So gotta do the cost benefits analysis or hell if it's something you're interested in doing just do it anyway.
Yes, executable size is still a modern day problem. Imagine you're shipping an OS; do you want the hundreds of thousands of executables in your system to all be a few percentage larger when you're trying to ship to a customer who may only have 16 or 32 GB of storage space?
Of course, removing libc won't be your first (or second or third or ...) step for removing bloat from a mature codebase.
If you'r trying to reduce bloat in this OS would be dynamically linking anyway wouldn't you? I've installed those 300MB printer drivers so I'm all for reducing bloat. This just seems to be on the extreme end of things.
All modern platforms have decreasing stacks, so just AND it with ~(alignment-1).
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?
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".
Technically you could get by with 5 bytes for "mov ebp, 0".
Another reason why it was faster was that the processor recognized it and avoided partial flags stalls after an "inc". But in 64-bit code you rarely have "inc" at all, so it matters less. On the other hand, a few years ago XOR had a false dependency on the register you're clearing; I'm not sure it is still that way on more recent processors.
Yeah off topic but if HN supported markdown (and GitHub's flavor of markdown so we could take different types of syntax with their language) would be amazing. There would be a ton more coding examples and discussion, in my opinion, if this were to happen.
Code coloration wouldn't be that useful (if the snippets are that long they should probably go in a separate pastebin or a proper repository, reddit's comments do just fine without)
On the other hand backslash escaping (the lack of it and emphasis clusterfuck drives me nuts), block quotes, inline code/monospace and links I really miss.
Section titles, lists and tables would be nice as well, though not deal breakers.
Considering the maintainers have repeatedly refused to make any improvement to comment formatting in almost 10 years since HN was created, I'm not holding my breath though, it's obvious nobody cares about comment authorship and craft.
Then in a few years when someone is reading old posts the links to old services are broken or the service is gone. If the code is central to the comment, why would you put it some place other than the comment? If it's not small enough you can collapse it inline and if it's so large that you don't want it with the comment then perhaps you should be rethinking what you are posting.
tldr; practicality and longevity should trump netiquette.
I agree and this was my original thought. For example Reddit, for most of its life, relied on imgurl for hosting images. Before the single place images constantly broke after services died. With imgurl being third party even it has led to broken images at times (though with significantly less frequency). Now reddit is doing their own.
Hacker News is very technical and code heavy. Seems to make sense to me that some may want to communicate / discuss code itself. I could even see it opening up more conversations like "this is my implementation of X; thoughts?" or "do this in any other language" challenges.
A lot of web/internet filters block ASM related content. My company uses Barracuda Networks filter and most ASM references/content are blocked, Reason: Hacking
They're not technically wrong... it's just 'hacking' in the traditional black magic/voodoo manipulation of actual systems components sense. That is, literally taking a hacksaw to a circuit board and altering it or making a new board.
An essential function of stardard library is to wrapper the syscalls. Besides that, you can make a live without the library. But why would you do that?
Myth busted : printf("Hello world") is simple and is a relevant C program for a beginning.
The "hello world" example is just the first step to annihilate your capacity of understanding how thinks works by relying on institutional black magic, that maybe wrong
(see all the scanf bugs that have been living in C code for so long and all bugs coming from respecting the old's man wisdom)
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 the syscall wrappers. And thanks to POSIX standardising this mechanism, the alternative will likely never get much adoption; of course, if you write your own syscall wrappers like this article, then you can skip that bloat.
For now this guide is linux-only, but I will be writing a windows version when I feel like firing up a virtual machine.
Unfortunately the Windows syscalls are not officially documented and even less stable than on Linux, changing even between service packs.
http://j00ru.vexillium.org/ntapi/
http://j00ru.vexillium.org/ntapi_64/
At least on Linux the first few (i.e. the oldest, most common and useful) syscalls have not really moved around over the years:
https://filippo.io/linux-syscall-table/