Date: Tue, 17 Nov 1998 10:31:36 +0100 From: Marius Bendiksen <Marius.Bendiksen@scancall.no> To: Ruslan Ermilov <ru@ucb.crimea.ua>, Mike Smith <mike@smith.net.au> Cc: Robert Nordier <rnordier@nordier.com>, FreeBSD Hackers <hackers@FreeBSD.ORG> Subject: Re: FreeBSD on i386 memory model Message-ID: <3.0.5.32.19981117103136.009058a0@mail.scancall.no> In-Reply-To: <19981117103925.A16673@ucb.crimea.ua> References: <199811141904.LAA06709@dingo.cdrom.com> <19981114191556.A17660@ucb.crimea.ua> <199811141904.LAA06709@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Could you please explain why it is _faster_ than ``lcall' and what is >the difference between them? This has to do with call gates vs interrupts. >The only difference that I know of at the moment is that ``int 0x80'' >will push EFlags, CS:EIP into stack, while ``lcall'' will only push >CS:EIP pair. Not quite true always. An lcall directly into a code segment which you have proper rights for, will do that. An lcall to a call gate may do quite a number of such operations, and- in the case of task gates- may cause a complete task switch. Similarly, there are multiple kinds of interrupts- trap interrupts, 'true' interrupts and task interrupts. Refer to the Intel 80386 technical docs, available from developer.intel.com >Where is the code that sets up protected mode and defines the layout >of the kernel? I believe this is in the second or third stage boot loader, but I may be mistaken, as I've never had a look at it. The first stage boot loader is too small to do such a thing, unless you use hardcoded offsets for the entrypoints and system structures. Doing it in the actual kernel seems stupid, as that would leave code in the kernel which is useless after bootup. --- Marius Bendiksen, IT-Trainee, ScanCall AS <marius@scancall.no> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.5.32.19981117103136.009058a0>