3 ms·

I am probably going to get downvoted for this, but let me try. I am assuming, this is related to VirtualBox using the OpenWatcom compiler [0] for BIOS because i

I am probably going to get downvoted for this, but let me try. I am assuming, this is related to VirtualBox using the OpenWatcom compiler [0] for BIOS because it is the only reasonable way to handle x86 segmentation from C. So this ticket is basically asking the VirtualBox maintainers to take a reliably working part of the product and to port it to a different compiler, retest everything, fix any bugs caused by differences between compilers and update the build process as well. So as an end user of VirtualBox, I would either notice no difference at all (BIOS isn't a performance bottleneck really), or will get a regression due to bugs. With all due respect to the free software community, I would say switching the compiler used in a stable product without an apparent improvement noticeable by the users would not serve their best interests. It is also a bit strange to see it not in a form of "hey, we really care about free software, so we ported this part to use a free compiler, here's the performance comparison, here are the unit tests, here are the build instructions", but rather in asking someone else to spend considerable effort on implementing this. [0] https://www.virtualbox.org/ticket/12011 https://www.virtualbox.org/ticket/12011

yuhong 8y ago
Yea, this is not about performance. This is about license problems. For code like BIOS, pretty much any good 16-bit C compiler should work.
Ace17 8y ago
> So as an end user of VirtualBox, I would either notice no difference at all (BIOS isn't a performance bottleneck really), or will get a regression due to bugs. Yeah, but we're already getting VirtualBox for free, so we can't only take into account the benefits of the end-users ; if the developers find it more convenient to use this new compiler, so be it.
zerr 8y ago
> using the OpenWatcom compiler [0] for BIOS because it is the only reasonable way to handle x86 segmentation from C. Can you elaborate?
- yuhong 8y ago
  It is not impossible to use gcc to generate 16-bit code, but it lacks support for things like near and far pointers.
atomicnumber1 8y ago
>It is also a bit strange to see it not in a form of "hey, we really care about free software, so we ported this part to use a free compiler, here's the performance comparison, here are the unit tests, here are the build instructions", but rather in asking someone else to spend considerable effort on implementing this. I seem to see this shift in ideology from People.
rwmj 8y ago
> because it is the only reasonable way to handle x86 segmentation from C. That's nonsense, both GCC and Clang handle this perfectly well. It's how we handle compiling 16 bit option ROMs in qemu: https://git.qemu.org/?p=qemu.git;a=blob;f=pc-bios/optionrom/linuxboot_dma.c;h=4754282ad736ac3be6459d59dcca6edb64d3f4ed;hb=HEAD https://git.qemu.org/?p=qemu.git;a=blob;f=pc-bios/optionrom/...
- geofft 8y ago
  This is the thing I don't get. qemu / SeaBIOS seem to build fine with a normal compiler like gcc or clang, as far as I know, and they're in Debian main. Why is VirtualBox different? What user-visible feature does its BIOS have that qemu doesn't - does it support booting OSes that qemu doesn't, or something? Can VirtualBox just switch to SeaBIOS?
- yuhong 8y ago
  Notice the special routines required for reading and writing from segments. A true 16-bit DOS compiler handles this for you.

yuhong 8y ago

Yea, this is not about performance. This is about license problems. For code like BIOS, pretty much any good 16-bit C compiler should work.

Ace17 8y ago

> So as an end user of VirtualBox, I would either notice no difference at all (BIOS isn't a performance bottleneck really), or will get a regression due to bugs. Yeah, but we're already getting VirtualBox for free, so we can't only take into account the benefits of the end-users ; if the developers find it more convenient to use this new compiler, so be it.

zerr 8y ago

> using the OpenWatcom compiler [0] for BIOS because it is the only reasonable way to handle x86 segmentation from C. Can you elaborate?

yuhong 8y ago
It is not impossible to use gcc to generate 16-bit code, but it lacks support for things like near and far pointers.

atomicnumber1 8y ago

>It is also a bit strange to see it not in a form of "hey, we really care about free software, so we ported this part to use a free compiler, here's the performance comparison, here are the unit tests, here are the build instructions", but rather in asking someone else to spend considerable effort on implementing this. I seem to see this shift in ideology from People.

rwmj 8y ago

> because it is the only reasonable way to handle x86 segmentation from C. That's nonsense, both GCC and Clang handle this perfectly well. It's how we handle compiling 16 bit option ROMs in qemu: https://git.qemu.org/?p=qemu.git;a=blob;f=pc-bios/optionrom/linuxboot_dma.c;h=4754282ad736ac3be6459d59dcca6edb64d3f4ed;hb=HEAD https://git.qemu.org/?p=qemu.git;a=blob;f=pc-bios/optionrom/...

geofft 8y ago
This is the thing I don't get. qemu / SeaBIOS seem to build fine with a normal compiler like gcc or clang, as far as I know, and they're in Debian main. Why is VirtualBox different? What user-visible feature does its BIOS have that qemu doesn't - does it support booting OSes that qemu doesn't, or something? Can VirtualBox just switch to SeaBIOS?
yuhong 8y ago
Notice the special routines required for reading and writing from segments. A true 16-bit DOS compiler handles this for you.