BCC...

[Eric W. Biederman]

ron minnich <rminnich at lanl.gov> writes:

> On 8 Mar 2004, Eric W. Biederman wrote:
> 
> > 
> > The PCBIOS compatibility code in rombios.c has quite a few warts.
> > Primary among them is that it written in a nasty mix of asm and 16bit C
> > code.  With the biggest problem seeming to be that bcc is a limited
> > 16bit compiler.
> 
> I don't much like this code. 
> 
> > In real mode there is 256K that we can place a real mode BIOS in.  If
> > all we do is stick to what a PCBIOS can do now, and don't attempt to
> > extend it, but just be a good implementation 256K should be enough to do
> > whatever is needed.
> 
> we're back to square one. Why do this when we can do emulation? I think I 
> don't see what you're planning here.

Not for video support.  This is for actually running freedos, freebsd,
and netbsd and windows etc.  All of those unconverted operating
systems.
 
> > I don't know if gcc using 32bit overrides in 16bit mode would be
> > better than a pure 16bit C compiler.  
> 
> one less compiler is always good to me.

Maybe.  It certainly simplifies the tool chain if you can do it.
 
> > So if the issues keeping us from using 16bit C compiler are primarily
> > cosmetic I don't see why they can't be fixed.  Long term I don't even
> > want to touch a compatibility layer.  I want to use something much
> > simpler and much more powerful.
> 
> I don't see the reason long term for rombios.c or 16bit C compilers. I 
> guess I'm missing something.

rombios.c or whatever the PCBIOS compatibility layer winds up being
must be 16bit code, (even if it has 32bit extensions all over the
place).  I'm not certain gcc can be convinced to do a reasonable job
of 16bit C code.

So I guess the first attempt at cleaning up rombios.c should do it
with gcc. 32bit code with 16bit prefixes.  If that does not work we
can get bcc out of the closet and make it usable.

COTS hardware is there and is valued because it does not impose
conversion time tables on software.  This needs to apply to the
firmware as well.  So for the short term we need it.

In the long term we can simply drop that compatibility layer.  But
at the same time we need to spec an interface that distribution makes
can use to make bootable media.  Something we can be certain of
providing on all ports that aim to support general purpose software.

Eric