8086 Development tools

[Deprecated]

Before the invention of dirt I used an operating system called OS-9, an 8 bit multi-user, multi-tasking, Unix like RTOS that ran on the Motorola 6809. Recently a couple friends and myself were reminiscing about the good old days when the topic of platform wars came up. By the end of the discussion we had agreed on three things -

• OS-9 had the potential to displace MS-DOS.
• We'd like to create an open version for modern processors. I plan on detailing this at some point in the OS Design forum. (Note - A modern version called Enhanced OS-9 is available from Radisys but not typically to the general public - and it's expensive).
• It should if at all possible run on the Intel 8086 CPU.

Since I'm the one insisting on 8086 support I get to evaluate the tools for building the beast. For modern processors we have already settled on using GCC but for 8086 things get a bit more challenging. Below is a list of tools that I have either already evaluated or am in the process of evaluating. I've also included some notes on my thoughts so far. I'm hoping to get some feedback on other users experiences using them along with notes on any modifications they've made to address their own project requirements. I'm also interested in any techniques they've come up with to better utilize the tools for their projects.

• GCC-8086 (links below). I haven't had a chance to look at this too much yet. Unfortunately it seems to be incomplete, is not actively being developed anymore and would likely require an older version of GCC. If anyone has information on the status of this project I would definitely like to know.
  
  http://www.opensubscriber.com/message/l ... 42861.html
  http://git.etherboot.org/people/hpa/i86 ... onfig/ia16
• Dev86/BCC (Bruce's C Compiler). The entire Dev86 package is a good contender, at least for initial development. The tools included (BCC in particular) have been used in the past for other operating systems (ELKS) and is small enough to be adapted to new projects. Unfortunately it's still living in the days of K&R and lacks simple modifiers such as 'const'. The biggest downside is that even with peephole optimization BCC produces horrendously bad code.
• LCC. I've used LCC for other projects and am quite fond of it's small footprint. Although it currently doesn't have a backend code generator for the 8086 I'm familiar with it's BURG implementation and could write one. It generates fairly decent code and is easily modified. Creating a code generator for it wouldn't be difficult but would be somewhat time consuming. The amount of time could potentially be reduced by basing it on the existing 32bit x86 code generator however.
• Open Watcom. So far this is my top pick although I must admit I'm still getting familiar with their entire tool chain. The biggest plus to me is that it seems to produce very optimized 16 bit code. It also supports far calls which may come in handy in reducing the amount of glue code required to perform certain tasks. This will help keep the code base clean and provide a bit more flexibility at the kernel level. Having a C++ compiler in the toolset is also a bonus but applies more to user space, at least for now. It also seems to be well supported by Code::Blocks providing a nice cross-platform IDE for development.
  
  The downside is that it's part of a must larger project, most of which isn't required or even usable for OS development.

Comments, questions, etc. are definitely welcome. I would also like to know of any other tools that I might to consider that aren't already listed in the Wiki.

(And yes, I'm documenting the results of my evaluations for inclusion in the Wiki.)

[Love4Boobies]

The most recent version of the Turbo C compiler that can output 16-bit code and is freely available is 2.01 (clicky!); you may want to try it out (perhaps using DOSBox). It was released in May 1989 so it obviously doesn't support C99 but with some luck, it may be C89-compliant. Note that Turbo C++ 2.01 is also free but probably less useful due to its age; the first version of C++ to be standardized was C++98. I've also checked Borland C++ 5.5 but, unfortunately, this one only outputs 32-bit code.

However, think carefully before deciding on 8086 support:

• Will this OS ever actually be ran on an 8086 CPU? Are you sure? There's a lot of work ahead, you don't want even more.
• Supporting 8086 CPUs is useless unless you also support the hardware that 8086 boxes have (or had), such as MCA buses; MDA, CGA, and EGA; etc.
• You've already mentioned a version for modern CPUs (Intel386+) and a version for old CPUs (8086/8088, maybe even 80186). What about Intel 286? If you decide to also support the latter, you'll have to maintain 3 versions of your OS.

[Solar]

I beg to differ. By the time they're done, virtually all modern CPUs from the "IBM compatible" line will be amd_64. That makes 4 CPU architectures to support.

@ Deprecated: Do you have any real 8086 hardware to test on? Any idea of anyone who might still have one in running condition? Adding support for an ancient CPU just so that people could run it in their ancient-CPU-emulator isn't really good business sense...

[Love4Boobies]

I beg to differ. By the time they're done, virtually all modern CPUs from the "IBM compatible" line will be amd_64. That makes 4 CPU architectures to support.

Oops. Nice catch

[Deprecated]

Turbo C isn't even being considered. Requiring an emulator to run a tool in the build process is like drinking tequila out of a sippy cup.

Will this OS ever actually be ran on an 8086 CPU? Are you sure? There's a lot of work ahead, you don't want even more.

Do you have any real 8086 hardware to test on? Any idea of anyone who might still have one in running condition?

Yes. All 3 of us as well as several people we know have either 8086 PC's or development boards. I even have an old Big Trak modified to accept different control boards. Add into that the people we know who are hobbiest robotic enthusiasts with older 8086 hardware (or FPGA programmers) it will at the very least have a decent test group.

Supporting 8086 CPUs is useless unless you also support the hardware that 8086 boxes have (or had), such as MCA buses; MDA, CGA, and EGA; etc.

The MCA bus was specific primarily to the IBM PS/2. Overall the number of MCA bus machines was tiny compared to that of ISA and isn't much of a concern.

I still have a stack of old hardware including monochrome video, VGA, SoundBlaster, MFM controller with working hard drive, IDE controller, modem and a few NE2000 compatible network cards. All cards are in working order, clean, and bagged.

What about Intel 286? If you decide to also support the latter, you'll have to maintain 3 versions of your OS.

Not true. Only those portions of the OS which require specific CPU or platform interaction will need to be independently maintained. That discussion however is better suited for the design section of the forum.

Adding support for an ancient CPU just so that people could run it in their ancient-CPU-emulator isn't really good business sense...

We have a very specific target audience and as well as intended usage for the project but that's completely irrelevant to the questions in my original post.

[Solar]

Sorry. We're somewhat accustomed of 95% of people coming up with really "strange" ideas being noobs (or, at least, newbies), who haven't really thought it through. It seems you have. I think the naysayers will shut up now.

/me shuts up.

[Love4Boobies]

Fair enough.

Turbo C isn't even being considered. Requiring an emulator to run a tool in the build process is like drinking tequila out of a sippy cup.

Not sure what to say about that. Most people on this forum who develop under Windows use Cygwin. It's not very different.

What about Intel 286? If you decide to also support the latter, you'll have to maintain 3 versions of your OS.

Not true. Only those portions of the OS which require specific CPU or platform interaction will need to be independently maintained.

Unfortunately, that means a huge chunk of code, as you will soon see.

We have a very specific target audience and as well as intended usage for the project but that's completely irrelevant to the questions in my original post.

It's a good thing that you've considered your target audience---a lot of people people don't.

[Deprecated]

Sorry. We're somewhat accustomed of 95% of people coming up with really "strange" ideas being noobs (or, at least, newbies), who haven't really thought it through.

No worries mate. I've done it myself lol

[OSwhatever]

[*]Open Watcom. So far this is my top pick although I must admit I'm still getting familiar with their entire tool chain. The biggest plus to me is that it seems to produce very optimized 16 bit code. It also supports far calls which may come in handy in reducing the amount of glue code required to perform certain tasks. This will help keep the code base clean and provide a bit more flexibility at the kernel level. Having a C++ compiler in the toolset is also a bonus but applies more to user space, at least for now. It also seems to be well supported by Code::Blocks providing a nice cross-platform IDE for development.

I've done system programming (bare bones) with Watcom and I like that toolchain a lot. Watcom's linker is not as versatile as the GCC linker. I found that the elf-output of the Watcom linker was the most appropriate for bare bones. Watcom has a list of romable library function calls for the which is very helpful.

[qw]

Turbo C isn't even being considered. Requiring an emulator to run a tool in the build process is like drinking tequila out of a sippy cup.

Do you really need an emulator? I ran Turbo C successfully on XP SP2.

[Love4Boobies]

Turbo C isn't even being considered. Requiring an emulator to run a tool in the build process is like drinking tequila out of a sippy cup.

Do you really need an emulator? I ran Turbo C successfully on XP SP2.

Long mode doesn't support vm8086 like protected mode does. Hence, 64-bit OSes need emulators; you were running a 32-bit version of XP.

[Brendan]

Hi,

I beg to differ. By the time they're done, virtually all modern CPUs from the "IBM compatible" line will be amd_64. That makes 4 CPU architectures to support.

I'm not seeing a need to support long mode here - it would be enough to use protected mode, with PAE to access the full physical address space on "64-bit capable" CPUs (and still use virtual8086 mode).


Cheers,

Brendan

[OSwhatever]

The lower end x86 for embedded will not be 64-bit for any foreseeable future. Right now Vortex x86 SoC, RDC SoC and other clones are basically 486s. The reason for this is that all 486 patents have expired. The Pentium patents will expire very soon so expect the x86 clones to be updated being Pentium clones instead of 486. There will be many years until the AMD64 patents will expire.

[Deprecated]

I've done system programming (bare bones) with Watcom and I like that toolchain a lot. Watcom's linker is not as versatile as the GCC linker. I found that the elf-output of the Watcom linker was the most appropriate for bare bones. Watcom has a list of romable library function calls for the which is very helpful.

So far my experience with it has been fairly great. It natively supports most of the constructs necessary for easily dealing with segmented memory which will help keep the source code relatively clean. The __far and __loadds modifiers alone will help tremendously in allowing the code to target both 16 bit and 32/64 bit platforms.