3 ms·
I messed around with writing OSes when I was around the same age, and I found x86-64 to not have much of an overhead relative to plain x86. Getting into long m
by johncolanduoni 10y ago
I messed around with writing OSes when I was around the same age, and I found x86-64 to not have much of an overhead relative to plain x86.
Getting into long mode itself is just a tiny bit of boilerplate at the very beginning. If you didn't plan on using paging then you need to do a bit more work to identity map everything, but if you already did the extra virtual address space means you can just map all physical addresses (that are hooked up to anything) linearly somewhere and not have to play games with mapping/unmapping things just so the kernel can access them briefly. You lose the ability to have the processor save state on context switch for you via the TSS, but that's not very hard to do yourself either. The ins and outs of running something in compatibility mode are quite complicated, but there's no reason to involve yourself in that if you're writing your own toy OS.
Overall I'd say 32-bit dodges a few things, but I wouldn't call it much easier.
- DSMan195276 10y agoA few things: x86-64 uses a 4-level page-table, which is much more annoying to get right then a 2-level page-table if you're not familiar with paging or haven't dealt with it before. I agree about TSS - nobody really bothers using it anyway. That said, x86-64 has a bit more state to handle when doing a context-switch (Though nothing very extreme) x86-64's calling convention is more complex then x86's calling convention. For this project it doesn't really apply because it isn't followed anyway, but for a C project it would come into play. IMO, another big issue with doing x86-64 is documentation - x86 has tons, x86-64 has comparatively little. I would definitely agree that if you know what you're doing the differences aren't huge, but if you don't know what you're doing I think you'll definitely have an easier time getting stuff working with x86.