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.
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.
I don't know if gcc using 32bit overrides in 16bit mode would be better than a pure 16bit C compiler.
Just looking at rombios.c earlier today the worst of it appears to be that rombios.c is a nasty mess, and that rombios.c does not support pci. So most of it to me does not appear to be a compiler issue at all, just that rombios.c needs to be rewritten in a more maintainable style.
I need to look a little more closely but I suspect getting bcc to accept a fairly complete gcc syntax including inline asm support would not be hard. Nor do I think getting bcc to output to gas assembly instead of it's own assembler would be to bad. Except possibly that gas 16bit support is quite limited.
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.
Eric
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.
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.
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.
ron
ron minnich rminnich@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
On 8 Mar 2004, Eric W. Biederman wrote:
Not for video support. This is for actually running freedos, freebsd, and netbsd and windows etc. All of those unconverted operating systems.
ok. I'll leave windows to you :)
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.
what's wrong with what we did for vga extensions, a 16-bit hook into 32-bit code? It has worked well for those who wanted native vga.
ron
On Tue, Mar 09, 2004 at 08:10:32AM -0700, ron minnich wrote:
On 8 Mar 2004, Eric W. Biederman wrote:
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.
what's wrong with what we did for vga extensions, a 16-bit hook into 32-bit code? It has worked well for those who wanted native vga.
Some OSs call 16-bit BIOS services in VM86 mode. In that case you can't switch to 32-bit mode by yourself.
Eric, how about modifying GCC to generate true 16-bit code?
On Sat, 13 Mar 2004, Takeshi Sone wrote:
Some OSs call 16-bit BIOS services in VM86 mode. In that case you can't switch to 32-bit mode by yourself.
how about we list those OSes, see if they can be fixed, or if we don't care.
what does windows do?
ron
ron minnich rminnich@lanl.gov writes:
On Sat, 13 Mar 2004, Takeshi Sone wrote:
Some OSs call 16-bit BIOS services in VM86 mode. In that case you can't switch to 32-bit mode by yourself.
how about we list those OSes, see if they can be fixed, or if we don't care.
what does windows do?
VM86 mode... At least the windows 9x kernel. NT?
The important point to note is that gas has a directive ``.code16gcc'' which directs gas to assemble 32bit code that runs in 16bit mode and in vm86 mode. So if we can fit everything in 256K we are fine.
So when doing a rewrite of rombios.c that is readable we should try that. 256K is a little tight I admit but if we don't go beyond simple standard features it is enough.
The fundamental point here is that you can write 32bit code that will run in VM86 mode.
Eric
-
ebiederman＠lnxi.com -
ron minnich -
Takeshi Sone