271–280 of 283 posts
Earlier quoted context omitted.
I hear it sorta works, but nix-shell doesn't. Regardless, while it's cool and useful, it's not really actual Windows support.
true. Didn't take you for a Windows guy, hehe
It's due to video games... but I'm actually enjoying Windows 10.
Earlier quoted context omitted.
There are thousands of vendor intrinsics and no compiler that I'm aware of is able to just automatically use all of them in a reliable way. The idea that "Rust needs explicit SIMD due to bounds checking" is very wrong.
Because SIMD ins throughput is highly processor specific? Rust will also not 'automatically use all of them' there is no magic abstraction would make any compiler use some of the really fancy and useful SIMD ins.
Earlier quoted context omitted.
Because SIMD ins throughput is highly processor specific? Rust will also not 'automatically use all of them' there is no magic abstraction would make any compiler use some of the really fancy and useful SIMD ins.
I don't know what you're talking about unfortunately. My statement about compilers and SIMD isn't Rust-specific. My point was that "rust needs explicit SIMD due to bounds checking" is factually wrong.
Earlier quoted context omitted.
> C doesn't "let you do what you mean", it has no knowledge of special registers, interrupts, timers, DMA, etc. Special registers are just slots at specific memory addresses. As far as the rest is concerned, not a single language in the world will provide you with primitives for that and make them portable across a thousand architectures with a million different peripherals. That's the role of libraries and OSes with…
> Special registers are just slots at specific memory addresses. > As far as the rest is concerned, not a single language in the world will provide you with primitives for that and make them portable across a thousand architectures with a million different peripherals. I'm well aware, that's why I said. > When you're dealing with the hardware architecture level you need more detail than C (or any PL) can reasonably p…
I'm confused in that, it's true, I've seen the macro system abused. But for working with things like memory mapped registers and interrupts you don't _need_ to abuse it. It actually looks really nice with with memory-mapped structures that ply on the register structure. Maybe I'm just missing something.
Earlier quoted context omitted.
Your issue with intrinsics are that the different ISAs have different specs. Fine. But if that was your only issue, then your use case is that you're manually vectoring hot loops correct? Assuming that's true, you want to maximise performance by using as much of the parallelism that vectors give you. So if you're dealing with [4 x int32], on a 128 bit vector ISA you would be fully utilising your vector registers, but…
I want to do math with 2,3, or 4-element vectors. These will typically represent 2d or 3d coordinates or velocities. 4-element vectors may be used for homogeneous coordinates or similar. My point is that these are very common mathematical entities and should be explicitly supported by the language. How these map to any particular processors resources is not my problem - though the three major vector extensions today…
On ARM you have specialised load and store instructions that can de-interleave into vector registers such that register a contains VecType.x and register b has VecType.y etc, but are a bit slower.
If you don't care about SIMD performance then fair enough, but if you care enough about this issue to want the compiler to generate SIMD instructions, you better be willing to change your code to be performant on your particular target because even small changes can impact whether or not it's worth vectoring vs leaving it as scalar code.
Earlier quoted context omitted.
You don't need a library to allocate memory in C. For example on Linux, use sbrk() system call to grow the heap, then start using it. But your larger point still stands.
I think that the point was more that heap allocation is not a standard language primitive in C. And indeed, it would be ludicruous to require dynamic allocation support from freestanding implementations (no standard library because typically your platform doesn't even have an OS).
Earlier quoted context omitted.
I don't know what you're talking about unfortunately. My statement about compilers and SIMD isn't Rust-specific. My point was that "rust needs explicit SIMD due to bounds checking" is factually wrong.
No it isn't, it is one of the reasons that rust is getting SIMD, if it cannot eluide the bounds checking then obviously it will not vectorize the code in question.
Earlier quoted context omitted.
.split_at_mut is a method on a slice ... one is free to implement their own abstractions that ultimately terminate in an unsafe { block } that enable multiple mutable borrows. fn split_at_mut(&mut self, mid: usize) -> (&mut str, &mut str) { // is_char_boundary checks that the index is in [0, .len()] if self.is_char_boundary(mid) { let len = self.len(); let ptr = self.as_ptr() as *mut u8; unsafe { (from_raw_parts_mut(…
What does Rust have Ocaml doesn't? If Ocaml solves the problem why Rust? Rust was made to solve the problem Ada solves.
Earlier quoted context omitted.
These things originate in hardware variations. Apparently all architectures use binary the same way so unsigned overflow just drops the MSB. But signed integers aren't always two's complement, so there is variation. See, no tedious rules to remember, you just have to understand how computers work. But the C standards call such things "undefined behaviour" rather than "platform specific" behaviour, and then try to pre…
At least one extant (or recently extant) system has to emulate unsigned, modulo arithmetic. This can be handled by the C compiler transparently, however. From the C compiler documentation: | Type | Bits | sizeof | Range | +---------------+------+--------+----------------------------------------+ | ... | | unsigned long | 36 | 4 | 0 to (2^36)-2 (see the following note) | ... Note: If the CONFORMANCE/TWOSARITH or CONFO…
I wonder if it still does end-around carry...