I asked a similar question on the IRC and got the answer that they are aiming for Microsoft C compiler so it would work with natively with system as much as possible. MinGW has some slight issues when launching application IIRC.
By the way, why does Rust need a C compiler anyway?
I admit I am ignorant here because I never cared. I know that many academic/niche programming languages bundle MinGW/depend on a MinGW or even Cygwin installation.. I always assumed that was to cut some corners. I mean, I have used multiple programming languages on Windows which compile to native code and have no dependency on a C compiler.
> By the way, why does Rust need a C compiler anyway?
I'm not 100% sure, but I do know that zero.rs requires 'the following libc functions: malloc, free, abort, memcpy, and memcmp'. So I'd imagine it's that.
Those functions could be easily done via syscalls to the underlying OS or simple Assembly routines, as they are quite simple to implement.
None of those four functions use syscalls, nor are any of them simple to implement efficiently in assembly.
Consider that memcpy, under GCC,
* generates different code based on any known alignment of the source or destination
* generates simpler code if the size is known at compile time
* generates only register accesses if one or both of the arguments live in registers
* is elided entirely if GCC determines that it may do so safely
The other three have similar complex behavior. The Rust developers didn't use them just because they were too dumb to know how to write a for loop in assembly.
They can grok HTML5 page full of JavaScript stuff, but then mix language with implementation, think that strong typing is only possible with VM based languages and faith at the look of Assembly code.
If you are targeting an existing OS, malloc/free can be simple wrappers to OS syscalls for memory allocation. Not very efficient, but pretty straightforward to implement.
If targeting direct hardware, any CS student should have learned how to implement a memory allocator on their compiler design, data structures or OS classes.
Back when I graduated, this would be a home work exercise.
If you want to implement a high performance memory allocator that works under pressure in a multi-core context, then yes it is complex to implement.
Now something that allocates/releases memory with a general purpose algorithm? That is quite simple and many compiler design books even provide such examples.
> If you are targeting an existing OS, malloc/free can be simple wrappers to OS syscalls for memory allocation.
Not really, there's no such thing as malloc/free syscalls. On Linux, you have mmap/munmap (at page granularity) and brk/sbrk (which only extend the current heap). You could implement malloc as either a mmap() of one or more pages, or by using sbrk() to extend the heap by exactly the memory you need, but then freeing that memory becomes much harder.
> Should I write a full tutorial on an HN post how to write memory allocators when anyone can easily search for one?
No, but a memory allocator is more that "simple wrappers".
My point was that OS kernels (Linux/BSDs at least) don't actually provide malloc/free as syscalls, and that you need to implement an allocator in userspace if you want these functions (even if it's a trivial allocator that wastes memory).
malloc/free are part of the C language runtime, not OS syscalls.
A compiler writer can build the memory allocator on top of what the OS provides as syscalls or take a shortcut and use the C runtime library instead while adding a dependency to it.
I know some folks who think of the NT syscall interface as the 'true' OS API and see kernel32.dll as an add-on. I'll ask, but I don't think these folks make a distinction between user32.dll and the msvcrt.dll that ships with the OS.
> I know some folks who think of the NT syscall interface as the 'true' OS API and see kernel32.dll as an add-on.
This is 100% correct, many of the real syscalls are located in Ntoskrnl, while kernel32.dll is actually part of the Win32 subsystem, given the personalities feature from Windows.
So you could be using another subsystem.
However, given that the POSIX and OS/2 subsystems are no longer supported, the only available subsystem is Win32.
Metro is another matter as it uses another architecture not based on the subsystems mechanism.
But in the end these are all OS APIs, not language runtimes.
OK, asking around, the word I get is that the OS team owns the msvcrt.dll in %systemroot%\system32. Although unofficially it might be the case that x86 apps built with VC6 depend on this dll to implement a stable interface, it's not officially recommended to take dependencies on it.
So it (Firefox with Servo) would work on Windows as close to native as possible? It would be funny to start Firefox and have a console windows poping in/out of existence or some other visual quirk.
Rust bootstraps by downloading an existing snapshot of the rust compiler, which it then uses to build the stage0 rust compiler, which then builds the stage1 rust compiler, which then builds the stage2 rust compiler.
