User: Password:
|
|
Subscribe / Log in / New account

Microkernels are better

Microkernels are better

Posted Feb 26, 2013 9:18 UTC (Tue) by renox (subscriber, #23785)
In reply to: Microkernels are better by Wol
Parent article: MINIX 3.2.1 released

What I find quite amusing in your post, it's that Intel had (a limitated form of) segmentation(*) whereas most other architectures (PPC, MIPS, ARM) don't have it.

*:in x86-32 mode, it lost it in the x86-64 mode


(Log in to post comments)

Microkernels are better

Posted Feb 26, 2013 9:56 UTC (Tue) by khim (subscriber, #9252) [Link]

*:in x86-32 mode, it lost it in the x86-64 mode

It lost it before that. If you'll try to use segment with non-zero base address on Atom you'll see 4-5x slowdown. Other, larger, cores are not affected as much but still some operations become slower. AMD and Intel keep the segmentation supported for compatibility sake, but in reality it was already pushed to the slow-path before x86-64 was introduced. And situation is the same with fancy high-level instructions like BOUND. It's all uneven, of course: BOUND is fast on most AMD CPUs (may be on all, but I've not measured latest AMD creations) but it's fantastically slow on Intel CPUs.

That's what I'm talking about: fat is squeezed out of fast-path to raise CPU frequency.

Microkernels are better

Posted Feb 26, 2013 10:38 UTC (Tue) by Wol (guest, #4433) [Link]

Didn't Intel use that to get round a small address bus? And wasn't it absolutely useless for security?

iirc, assuming a 4K segment, addressing 4K+1 in segment 1 would get you the first byte of segment 2. On Primes, different segment meant different memory.

Cheers,
Wol

Microkernels are better

Posted Feb 26, 2013 10:46 UTC (Tue) by khim (subscriber, #9252) [Link]

Didn't Intel use that to get round a small address bus? And wasn't it absolutely useless for security?

They are designed to be used for security and, e.g. OS/2 1.x used them for security. Sadly they broken the backward-compatibility on the way: you could use segments solely to extend memory or for security on 80286 — but not simultaneously. 80386 solved that problem but it introduced UNIX-like paging model and everyone forgot about segments.

iirc, assuming a 4K segment, addressing 4K+1 in segment 1 would get you the first byte of segment 2. On Primes, different segment meant different memory.

You can do that on 80386, too: it really depends on how your GDT/IDT/LDT are arganized. You can even change sizes of segments on the fly. Actually this architecture was pretty sophisticated and flexible, but it was pushed to the slow-path (and eventually eradicated in x86-64) when AMD and Intel found out that nobody uses it.

Microkernels are better

Posted Feb 26, 2013 10:51 UTC (Tue) by mpr22 (subscriber, #60784) [Link]

  • real mode: 16-bit segment register; left-shift segment by four bits and add the offset to get a 20-bit physical address.
  • 16-bit protected mode (80286 and later): 16-bit segment register; when loading a segment register, use the top 14 bits to do a table lookup to get the base address of the segment; add the offset to the base address to get a 24-bit physical address.
  • 32-bit protected mode (80386 and later): 16-bit segment register; when loading a segment register use the top 14 bits to do a table lookup to get the virtual base address and size of the segment; add the offset to the base address to get a 32-bit virtual address, which is then resolved to a physical address either on a 1:1 basis (paging disabled) or via the paging unit.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds