161–170 of 188 posts
If the asm was written a little more cleverly, the syscalls would avoid almost all moves, because the compiler'd put everything in place: _syscall5: mov %r9, %r10 _syscall3: mov %rcx, %rax syscall ret And then: extern unsigned long _syscall3( unsigned long, unsigned long, unsigned long, unsigned long); extern unsigned long _syscall5( unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned…
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…
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 .
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.
Earlier quoted context omitted.
> wasting resources I don't consider variable-width fonts, nice margins and dynamic word wrapping to be a waste of resources. There's a sane middle ground between Electron and the 70s.
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…
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.
An implementation of malloc/free
Functions to parse and print floats (somewhat system dependent)
Assembly implementations of any trigonometric functions used
While there is code that goes to that effort (The Go runtime comes to mind), it's quite a pain for "normal" code.
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…
Sure, there may be some overlap or interleaving between Standard Libraries, syscalls, and posix, but they are definitely not the same.
> 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?
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.
Earlier quoted context omitted.
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 r…
> 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 stay…
That's a feature. They want all this valuable search data so the make you search via the site instead of the browser.
Earlier quoted context omitted.
Fine, but you get this thanks to already being linked with these megagodzillas like kernel32.dll. Try without them.
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. So you can't really go without it.
Earlier quoted context omitted.
I use stdint.h too, but I'm honestly curious if there is any common platform around today where one of the following asserts fails: int main() { assert(sizeof(signed char) == 1); assert(sizeof(short) == 2); assert(sizeof(int) == 4); assert(sizeof(long long) == 8); return 0; } I'm not interested in the language lawyering, because yes I know the standard provides more freedom to compilers. I just think those definition…
I think int is 8 bytes on the PS4. (I just got bitten by this...)
Earlier quoted context omitted.
> 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.
Personally, I don't mind this at all, mostly because they wouldn't be writing anything if it weren't for Unity and Unreal.