"Oracle VM VirtualBox, the world's most popular open source, cross-platform, virtualization software" According to the VirtualBox developers it is not possible to build the VirtualBox BIOS with gcc or any other Free Software compiler. Quote VirtualBox developer https://www.virtualbox.org/ticket/12011 "We would be glad to fix this, but we lack the resources to do so as our BIOS code has simply outgrown what bcc (which we were using before and which was always very limiting) can do. We have failed to find another free 16-bit x86 C compiler up to the job," "generating 16-bit code is one thing, but supporting e.g. far/near pointers" It is currently compiled using the Open Watcom compiler which is under the Sybase Open Watcom Public License license. That license is not FSF approved. https://en.wikipedia.org/wiki/Sybase_Open_Watcom_Public_License Even stated it being a nonfree license. https://www.gnu.org/licenses/license-list.html#Watcom The VirtualBox BIOS source code can be found here: * https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/PC/BIOS * https://github.com/mirror/vbox/tree/master/src/VBox/Devices/PC/BIOS feature request: Could you please develop a 16-bit x86 C compiler that supports compilation of VirtualBox BIOS / any BIOS?
> Could you please develop a 16-bit x86 C compiler that supports compilation of > VirtualBox BIOS / any BIOS? A bug bounty might be useful here since I highly doubt this will be done otherwise.
Can you or anyone guestimate / speculate how big a bounty in USD value would be required to get this ticket implemented in gcc as well as getting a patch merged at VirtualBox starting to use this?
I've no idea whether the (not merged) ia16 port can do this, or whether the person currently maintaining a version of that port for GCC 6 is covered by an FSF copyright assignment. https://gcc.gnu.org/legacy-ml/gcc-patches/2017-04/msg00009.html https://gcc.gnu.org/legacy-ml/gcc/2018-06/msg00103.html https://github.com/tkchia/gcc-ia16
(In reply to joseph@codesourcery.com from comment #3) > I've no idea whether the (not merged) ia16 port can do this, or whether > the person currently maintaining a version of that port for GCC 6 is > covered by an FSF copyright assignment. > > https://gcc.gnu.org/legacy-ml/gcc-patches/2017-04/msg00009.html > https://gcc.gnu.org/legacy-ml/gcc/2018-06/msg00103.html > https://github.com/tkchia/gcc-ia16 cc-ing people from these threads to see if they can help fill us in here
Hello all, > I've no idea whether the (not merged) ia16 port can do this, or whether > the person currently maintaining a version of that port for GCC 6 is > covered by an FSF copyright assignment. I am the maintainer behind the https://github.com/tkchia/gcc-ia16 fork. Yes, I have done the copyright assignments for my IA-16 patches for GCC (in 2017) and also for Binutils (in 2018). I believe that the previous developers, Mr. Lambertsen and Mr. Jenner, have also made the needed copyright assignments. The current gcc-ia16 code can produce code to run on an 8086, 80186, or 80286 machine, and also has support for far pointers --- including far function pointers. The texinfo documentation has been updated to lay out the features that the IA-16 port has. Thank you!
Hello Andrew, > A bug bounty might be useful here since I highly doubt this will be done > otherwise. The gcc-ia16 port is working, but internals-wise, some parts of the IA-16 patches are still rather hacky --- some of the changes affect the machine-independent middle-end in not-so-elegant ways, or depend on undocumented (and unreliable) properties in the middle-end. So I guess it might still be useful to have some sort of bounty(s), if this means someone could help rethink the changes and reduce technical debt. Thank you!
Hello Andrew, Incidentally, the patches for binutils-ia16 (https://github.com/tkchia/binutils-ia16) to support IA-16 relocations (https://github.com/tkchia/build-ia16/blob/master/elf16-writeup.md), could perhaps also benefit from a rethink. Thank you!
Hello Patrick, > Can you or anyone guestimate / speculate how big a bounty in USD value would > be required to get this ticket implemented in gcc as well as getting a patch > merged at VirtualBox starting to use this? Offhand, I would guess that the effort is at least comparable to other efforts to modernize GCC internals, e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 , so a comparable bounty is likely needed. But perhaps someone who is more knowledgeable about GCC internals can provide a better estimate. Thank you!