Writing C software without the standard library • Hacker News Board

Re: Writing C software without the standard library

#181

Post by rikkus » Wed, Nov 30, 2016, 11:25 AM UTC

csl wrote: post #112

rikkus wrote: post #59

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. [1] https://github.com/abh/djbdns/blob/master/str_len.c [2] http://cr.yp.to/djb.html

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.

Re: Writing C software without the standard library

#182

Post by bogomipz » Wed, Nov 30, 2016, 1:34 PM UTC

lomnakkus wrote: post #180

bogomipz wrote: post #171

Earlier quoted context omitted.

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.

Ah yes that makes sense. Thanks!

Re: Writing C software without the standard library

#183

Post by 77pt77 » Wed, Nov 30, 2016, 4:56 PM UTC

Ace17 wrote: post #175

77pt77 wrote: post #151

Earlier quoted context omitted.

> The syscall/errno stuff has always seemed unusual, inelegant, and inefficient And non-reentrant. errno is usually defined as TLS (thread local storage). It's a mess.

Is TLS actually needed for anything else than errno/GetLastError/SDL_GetError/etc. ?

Thread id :)

Re: Writing C software without the standard library

#184

Post by time4tea » Wed, Nov 30, 2016, 6:28 PM UTC

lolisamurai wrote: post #124

vxNsr wrote: post #4

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.

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...

Re: Writing C software without the standard library

#185

Post by slededit » Thu, Dec 01, 2016, 1:06 AM UTC

Symmetry wrote: post #158

leeter wrote: post #142

Earlier quoted context omitted.

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.

At 4K the majority of the load from disk will be seek time (even on an SSD).

Re: Writing C software without the standard library

#186

Post by vidarh » Thu, Dec 01, 2016, 2:52 AM UTC

pg314 wrote: post #50

majewsky wrote: post #44

Earlier quoted context omitted.

That's an arena allocator: https://en.wikipedia.org/wiki/Region-based_memory_management 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…

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.

Re: Writing C software without the standard library

#187

Post by colin_mccabe » Thu, Dec 01, 2016, 8:08 AM UTC

justincormack wrote: post #40

pdw wrote: post #29

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.

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.

Re: Writing C software without the standard library

#188

Post by DSMan195276 » Thu, Dec 01, 2016, 8:09 AM UTC

I_deny_it wrote: post #169

jblow wrote: post #147

Earlier quoted context omitted.

I think int is 8 bytes on the PS4. (I just got bitten by this...)

How does the PS4 declare a 4 byte int? If that's "short", is there a way for a 2 byte int?

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.