VOGONS


GCC for 8088/8086

Topic actions

First post, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie

Today I've released a thing I've been working on lately, that may be of interest to programmers here: GCC for 8088/8086. If you've been planning to make a demo or game for pre-386 PCs but wanted to be able to use the latest C11 or C++14 standards or wanted some state-of-the-art compiler optimizations, this is the tool you need.

It's not perfect yet, but it does already generate better code than Watcom, Borland or Microsoft compilers for these machines in many circumstances (mostly because of the advanced target-independent optimizations previously mentioned). I'm planning to continue adding features and improving the code generation, and upgrading it to later GCC versions as they are released. Enjoy!

Reply 2 of 21, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

Next, GCC for abacus.

All hail the Great Capacitor Brand Finder

Reply 3 of 21, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
gdjacobs wrote:

Next, GCC for abacus.

I don't know about that - the abacus ISA is *really* difficult to describe in the sort of detail that a compiler needs in order to be able to target it. 😀

Reply 4 of 21, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

RISC processors always offload logic onto the compiler 😀

All hail the Great Capacitor Brand Finder

Reply 5 of 21, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie

Any chance for DJGPP binaries, that would run on DOS (on 386+ of course)?

Reply 6 of 21, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
Azarien wrote:

Any chance for DJGPP binaries, that would run on DOS (on 386+ of course)?

If that would be useful for you, I'll see what I can do. You're not the first person to suggest this, though - I'm surprised that people are interested in targeting <386 DOS from >=386 DOS, but perhaps I shouldn't be!

Reply 7 of 21, by Scali

User metadata
Rank l33t
Rank
l33t
reenigne wrote:

I'm surprised that people are interested in targeting <386 DOS from >=386 DOS, but perhaps I shouldn't be!

I suppose there would be some benefit to being able to run both the toolset and the compiled code from the same environment. Either a 386+ emulator like DOSBox, or a 'real' 386+ machine. I suppose a modern version of GCC is quite memory-hungry during compile?

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 8 of 21, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
Scali wrote:

I suppose there would be some benefit to being able to run both the toolset and the compiled code from the same environment.

True, though I'm not sure it's a massive benefit over running the compiled code in an emulator running on the same machine. If nothing else, reboots will be quicker when pointer bugs in the compiled code inevitably crash the target machine.

Scali wrote:

I suppose a modern version of GCC is quite memory-hungry during compile?

It depends what you're compiling, but yes, it can be. The compiler executable itself is a big program for a DOS machine (15-16MB).

Reply 9 of 21, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

So effectively this is a cross compiler for 8086? Man this is awesome! I've been waiting for something like this for a long time to help with my emulation efforts.

Any chance of tasm/tlink (or equivalent) that can work on a modern machine? Yes they can be run in Dosbox but I would still have to deal with dos shortcomings.

Thank you Reenigne!

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 10 of 21, by Scali

User metadata
Rank l33t
Rank
l33t
vladstamate wrote:

So effectively this is a cross compiler for 8086? Man this is awesome! I've been waiting for something like this for a long time to help with my emulation efforts.

There was always OpenWatcom, which is a cross-compiler for Win32, linux, OS/2 and DOS.

vladstamate wrote:

Any chance of tasm/tlink (or equivalent) that can work on a modern machine?

Newer versions of MASM are 32-bit Windows applications, which can still generate 16-bit code, and if you get just the right version of LINK.EXE, you get a 32-bit Windows application with support for DOS.
You can find both MASM and 'LINK16.EXE" included in the free MASM32 package, which gets the job done: http://masm32.com/download.htm
I've been using that since the late 90s for both DOS and Win32 assembly coding.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 11 of 21, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie
Scali wrote:

Newer versions of MASM are 32-bit Windows applications, which can still generate 16-bit code, and if you get just the right version of LINK.EXE, you get a 32-bit Windows application with support for DOS.
You can find both MASM and 'LINK16.EXE" included in the free MASM32 package, which gets the job done: http://masm32.com/download.htm
I've been using that since the late 90s for both DOS and Win32 assembly coding.

Excellent pointers, thank you Scali.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 12 of 21, by M-HT

User metadata
Rank Newbie
Rank
Newbie

nasm and alink should also work. I haven't used them to generate code for DOS, but I used them to crosscompile from Linux to Windows.

Reply 13 of 21, by Scali

User metadata
Rank l33t
Rank
l33t
M-HT wrote:

nasm and alink should also work. I haven't used them to generate code for DOS, but I used them to crosscompile from Linux to Windows.

Yes, I've used NASM to cross-assemble (you can't compile with an assembler, since it's not a compiler) to DOS from Windows.
But NASM has its own undocumented syntax which makes me not like it very much.
TASM in non-ideal mode is basically a clone of MASM. And even ideal mode only differs on certain details, most of it is still the same syntax and keywords. So switching from TASM to MASM (the original) shouldn't be that difficult.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 14 of 21, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
Scali wrote:

But NASM has its own undocumented syntax which makes me not like it very much.

It is documented: http://www.nasm.us/doc/.

Reply 15 of 21, by ryoder

User metadata
Rank Newbie
Rank
Newbie

Hey reengine, I'm a huge fan of yours and am doing off and on development for Tandy 1000 specifically.
I just got your GNU C++ compiler working on CodeBench and am trying to create a hello world program. Whenever I call printf it hangs using DOSBox. I can do other basic things such as malloc, strcpy but printf hangs. Any ideas?

Also, when will far pointers and 640k be supported if at all? Thanks!

Reply 16 of 21, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
ryoder wrote:

Hey reengine, I'm a huge fan of yours and am doing off and on development for Tandy 1000 specifically.
I just got your GNU C++ compiler working on CodeBench and am trying to create a hello world program. Whenever I call printf it hangs using DOSBox. I can do other basic things such as malloc, strcpy but printf hangs. Any ideas?

Also, when will far pointers and 640k be supported if at all? Thanks!

Glad to you have you as a fan! Sorry I haven't done much work on GCC IA16 lately, but TK Chia has taken the reins and implemented far pointers. I'm not sure why printf hangs offhand but try it with their toolchain and see if they've fixed the problem. If not you may have some debugging to do!

Reply 17 of 21, by retardware

User metadata
Rank Oldbie
Rank
Oldbie

Thanks for necroing 😀
So I got aware of this GCC. Great thing!
And the last post indicates it even supports near/far pointers.
I ask because I want to modify the driver for Headland HTK340 chipset I wrote in the mid-1990s, and maybe extend its support to the similar HT12 286 chipset.
Could I use the old code written for MSC8 with some near/far addressing and inline assembly without substantial modifications?

Reply 18 of 21, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
retardware wrote:
Thanks for necroing :) So I got aware of this GCC. Great thing! And the last post indicates it even supports near/far pointers. […]
Show full quote

Thanks for necroing 😀
So I got aware of this GCC. Great thing!
And the last post indicates it even supports near/far pointers.
I ask because I want to modify the driver for Headland HTK340 chipset I wrote in the mid-1990s, and maybe extend its support to the similar HT12 286 chipset.
Could I use the old code written for MSC8 with some near/far addressing and inline assembly without substantial modifications?

It depends on how substantial the inline assembly is, I expect. GCC's inline assembly format is different to MSC's. Depends also if your driver uses other low-level libraries that aren't currently implemented in the GCC toolchain and which would have to be ported.

Reply 19 of 21, by retardware

User metadata
Rank Oldbie
Rank
Oldbie

Great! I have downloaded the package, will install and try the next days.
Inline assembly is very simple, just some critical sections with a few instructions that set some chipset registers and then release interrupts again. So I guess the modifications effort necessary would be probably very limited.

Will report back in a few days 😀