Re: New GCC compiler for 8086 cpu's

[Alan Cox <alan@llwyncelyn.cymru>]

On Thu, 15 Jun 2017 17:53:20 -0500
Juan Perez-Sanchez <lithoxs@gmail.com> wrote:

> On Thu, Jun 15, 2017 at 5:19 AM, Edoardo <eddyx89@gmail.com> 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