@lachlansneff, thanks for the answer, btw!
Also, isn't there any kind of interrupt we can make to call the MMU directly for it to make a conversion for us?
Yeah, there's no instruction to ask the mmu to translate an address.
@phil-opp not sure if you've seen it before, but this project might be a tool that's useful/instructive for this work: https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/
(since it's a kvm based microvisor)
so perhaps might provide a base that is more basic than what qemu provides by default
A wonderful blog you've written and I look forward to future updates.
I've been working with your code and better understanding it. I've added some features and even just overhauled some parts to fit my preferences.
I'm coming from doing a lot of embedded development for micro-controllers in C++, so this isn't too out of the norm for me, but I must say. I have quickly fallen in love Rust.
I've been working with your code and better understanding it. I've added some features and even just overhauled some parts to fit my preferences.
I'm coming from doing a lot of embedded development for micro-controllers in C++, so this isn't too out of the norm for me, but I must say. I have quickly fallen in love Rust.
I've modified the bootloader to initialise a VESA framebuffer, and added a vesa_buffer module to the kernel which can print to the screen using the font8x8 bitmaps. Now I'm trying to draw to the screen. Plotting a pixel was trivial, so I've gone on to implement Bresenham's line drawing algorithm - except that any form of floating point division causes a double fault. My understanding of the soft-float option was that this should be working and implemented using integer arithmetic functions - any ideas?
Example code to reproduce in main.rs:
println!("Gradient of y = x / 2 = {}", get_gradient(0, 0, 100, 50));
fn get_gradient(x1: usize, y1: usize, x2: usize, y2: usize) -> f64 {
let dx: isize = x2 as isize - x1 as isize;
let dy: isize = y2 as isize - y1 as isize;
dy as f64 / dx as f64
}
Doing some more digging, it seems to be related to the casting from isize to f64 as part of the division. If dx and dy are already f64 the operation does not crash the kernel.
As a result I have now got my line drawing working, but I'm still stumped as to why the example code above would be causing a double fault
As a result I have now got my line drawing working, but I'm still stumped as to why the example code above would be causing a double fault
Oh wow, this is really strange. The double fault occurs because of a stack overflow. Looking at the disassembly, it becomes clear why:
000000000022a260 <__floatdidf>:
22a260: 50 push rax
22a261: e8 fa ff ff ff call 22a260 <__floatdidf>This is an endless recursion. I have no idea why LLVM generates such code.
I created https://github.com/phil-opp/__floatdidf-issue for reproducing the issue. I think I'll open an issue in the rust repo, maybe someone knows what's going on
I'm now trying to draw antialiased lines using Xiaolin Wu's line drawing algorithm, which requires getting the fractional part of a number.
However, calling
However, calling
1.75_f64.fract() leads to a linker error:note: rust-lld: error: undefined symbol: fmod
>>> referenced by arith.rs:560 (/Users/aaron/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/src/rust/src/libcore/ops/arith.rs:560)
>>> /Users/aaron/Development/x86/curi_os/target/x86_64-curi_os/debug/deps/curi_os-317ecf0cf7f99e86.5fqxd6e0jeohqd9.rcgu.o:(_$LT$f64$u20$as$u20$core..ops..arith..Rem$GT$::rem::h09842b402db57bb3)
I thought it might be something the
num_traits crate isn't providing, but the linker error is against arith.rs in the core
Seems to be true for any of the functions on f64 that return a modified float -
floor, round, trunc, etc.
looks like there's a PR stream to make some of those functions available in num_traits via libm: rust-num/num-traits#99
Also, has anybody been able to get a graphics library working?
Hi @nebrelbug sure. The bootloader code is on my public Github, and the vesa drawing code is in curi_os in the vesa branch.
I can't claim credit for the vesa mode init and framebuffer printer code though - Philipp and jabedude wrote most of that and you can see that here: https://github.com/jabedude/bootloader/tree/vesa
I can't claim credit for the vesa mode init and framebuffer printer code though - Philipp and jabedude wrote most of that and you can see that here: https://github.com/jabedude/bootloader/tree/vesa
One thing that limits the effectiveness of a lot of this is the lack of float math in the kernel, as discussed above. I have written my own versions of functions to truncate floats and return the fractional part (actually most of those functions can be written as variations on fmod, which can be solved in a stupid way by moving closer to 0 by 1.0 in a while loop until you have a number smaller than 1.0)
I was finally able to figure out how to create a double buffer by creating a lazy_static Vec<u16> using the allocator code (had to bump the heap size). This should mean I can add some mouse support or a proper scrolling vesa writer implementation that shifts the characters up as the screen fills