Kernel requests via page faults

[Owen]

I think the fastest way to do syscalls on x86 is to allocate a callgate with every entrypoint. This will leave all CPU-registers available (no need to use & copy the stack in most (all) cases). It doesn't need to setup function numbers on entry, and it doesn't need decoding functions in the kernel, and eventually to do a call / jmp to the real entrypoint. The only drawback is that GDT selectors are a limited resource.

IIRC the fastest way to do a syscall on 64-bit x86 is SYSCALL/SYSRET, as they've been specially optimised for this case.

Except for exceptions, it is more or less the only way on 64-bit. However, I don't target 64-bit, rather 386+ processors (IA32) only, and I have no plans to switch to 64-bit. There is no need for 64-bit code on embedded platforms.

Then you should use SYSENTER or SYSCALL when available...

[rdos]

Then you should use SYSENTER or SYSCALL when available...

But SYSENTER/SYSEXIT does not fit into my architecture where all parameters are passed in registers. I have no spare register for function numbers, and would need to push context on user stack, validate & access original context from user stack in kernel in order to keep the interface intact. All this will not be faster than a call-gate.

[JamesM]

Except for exceptions, it is more or less the only way on 64-bit. However, I don't target 64-bit, rather 386+ processors (IA32) only, and I have no plans to switch to 64-bit. There is no need for 64-bit code on embedded platforms.

There aren't many embedded intel chips either, compared to ARM, MIPS and PowerPC

[rdos]

Except for exceptions, it is more or less the only way on 64-bit. However, I don't target 64-bit, rather 386+ processors (IA32) only, and I have no plans to switch to 64-bit. There is no need for 64-bit code on embedded platforms.

There aren't many embedded intel chips either, compared to ARM, MIPS and PowerPC

Perhaps not, but there are lots of industrial computers with Intel/AMD/you-name-it chips that runs I32 operating systems. Very few of these are based on ARM, MIPS or PowerPC

Also, there is an expanding market of Mini-PCs that starts to get interesting for such applications as well (typically with Intel Atom CPUs). My only problem here is the network chips from Atheros that seems to lack official documentation.

[JamesM]

Except for exceptions, it is more or less the only way on 64-bit. However, I don't target 64-bit, rather 386+ processors (IA32) only, and I have no plans to switch to 64-bit. There is no need for 64-bit code on embedded platforms.

There aren't many embedded intel chips either, compared to ARM, MIPS and PowerPC

Perhaps not, but there are lots of industrial computers with Intel/AMD/you-name-it chips that runs I32 operating systems. Very few of these are based on ARM, MIPS or PowerPC

Also, there is an expanding market of Mini-PCs that starts to get interesting for such applications as well (typically with Intel Atom CPUs). My only problem here is the network chips from Atheros that seems to lack official documentation.

Those same industrial systems will be running an operating system that has been verified for a particular task - they generally do not upgrade and will almost certainly never change operating system!

Personally I think that the mini-PC (netbook) market will be dominated by ARM based systems (for example the Cortex-A9 or the new Cortex-A15), but I might be being biased