Re: New GCC compiler for 8086 cpu's

[Alan Cox <alan@llwyncelyn.cymru>]

On Fri, 16 Jun 2017 23:03:26 +0930
"David O'Shea" <dcoshea@gmail.com> wrote:

> Hi Juan,
> 
> Thanks for the link!  Some questions below:
> 
> On Fri, Jun 16, 2017 at 8:23 AM, Juan Perez-Sanchez <lithoxs@gmail.com> wrote:
> > On Thu, Jun 15, 2017 at 5:19 AM, Edoardo <eddyx89@gmail.com> wrote:  
> >> 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.  
> 
> I guess there are both limits in the compiler and limits in ELKS itself, right?
> 
> Alan kindly explained to me in the last few days in the thread
> http://www.spinics.net/lists/linux-8086/msg00813.html what kind of
> complex things ELKS would need to do to handle processes with multiple
> code segments and/or multiple data segments, and those restrictions
> are still there, so simply using GCC doesn't make them go away.
> 
> The "Getting Started Guide" for this new IA16 GCC actually mentions a
> few limitations in this area that the new compiler has:
> 
> - Section 3.2 says "Although this version of Sourcery CodeBench Lite
> uses ELF as its internal object format, it produces executables in DOS
> COM format."  DOS .COM format implies a single 64KB segment for
> combined code and data, i.e. tiny memory model, right?  That's more
> restrictive than ELKS.

The compiler generates .COM but the rest of it can built split I/D
"small" model binaries with the same limits as DOS small model and ELKS
split I/D. That limit is that function pointers don't work totally
strictly to the C standard - but not in a way that ever matters.

In particular

	void *p = &function;

gives a 16bit offset relative to CS: for which there might exist a
different object (a variable) with the same address relative to DS. That
also means that

	uint8_t *p = (uint8_t)&function;
	*p = 4;

doesn't write over the function code as you'd expect 8)

None of this matters in the real world because comparing function
pointers, calling functions by pointer and all the normal uses work
just fine.

Alan