From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Cox Subject: Re: New GCC compiler for 8086 cpu's Date: Mon, 19 Jun 2017 14:43:00 +0100 Message-ID: <20170619144300.2b171cbf@alans-desktop> References: Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-8086-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Juan Perez-Sanchez Cc: linux-8086 On Thu, 15 Jun 2017 17:53:20 -0500 Juan Perez-Sanchez wrote: > On Thu, Jun 15, 2017 at 5:19 AM, Edoardo wrote: > > How much smaller? > > The current kernel with a configuration similar to the default > configuration for the 0.1.3 version, > compiled with BCC has a code size of 51216 bytes. With the new > compiler, size is 48288 bytes. > This is 2928 bytes less (5.7%). > > > If I remember correctly, one of ELKS limits was that binaries had to > > fit on a 64KB page, and that was due to the compiler we used (dev86 / > > bcc). > > Actually, code size <= 64KB and separately (data + bss + stack sizes) <= 64KB. > > > Do you think/know if GCC may solve this limit, being able to produce > > multi-page binaries? > > No, those limits still holds. For the kernel it's good enough it could do it with a few helpers. However the big kernel problem space is data (because of the stacks). If an 'export symbol' thing is added and drivers are treated like kernel modules (even if loaded together not on demand) then you can use tools to generate stubs for each module that do a far call into the kernel. You would probably need to disallow callbacks and modules calling each other because while you are sort of doing a far call you need a near call frame. Also because you'd have pointers to functions in other modules that were not far and did not a segment attached. Actually making it work is tricky but doable. I don't think it's needed however - the data segment is the only really big issue. Alan