• Please review our updated Terms and Rules here

GCC for 8088

R

reenigne

Veteran Member
Joined
Dec 13, 2008
Messages
717
Location
Cornwall, UK
Here's something I've been working on lately: GCC for 8088-80286. Now you can write C and C++ code for your IBM 5150 that uses the very latest C11 and C++14 standards!

I've done a small amount of comparative testing and I think it generally generates better integer code than any other 8086 compiler. Floating point code is a bit heavy as it's software FP emulation only, and the FP library I used emphasises standards-compliance over size. I plan to improve this in the future, but of course if you're writing a game or demo for this platform you'd probably prefer to be using fixed-point calculations anyway. Also there are no far pointers yet - I'm working on it, but didn't get it finished in time for the initial release.
 
Looks promising.
I was looking for some C or Pascal compiler capable of targeting both x86-16 and 68000, in order to do reliable performance comparisions between those two architectures, but couldn't find anything.
Now, this may be the perfect choice.
 
Very nice, just tested a Hello World and it generates a working .com file
 
Very cool!
I'll have to play around with it sometime soon. Although I think many of my current 8088 projects require far pointers somewhere. I still have some 'dead' code from when I switched from Turbo C++to Open Watcom, where certain things didn't quite behave the same way between both compilers (as it turned out, _fmalloc() on Watcom is not like farmalloc() on Turbo C++ for example).
In fact, I'm surprised that DOOM would build and run without them.

Having said that, Watcom was quite a step forward from Turbo C++ in terms of performance and compactness of code. I suppose a state-of-the-art GCC would do even better.
 
Looks like my dream came true after all... now code tied to gcc extensions that's otherwise portable (gforth, for instance) will run on these old machines! Maybe Linux on 286 is possible in theory after all (yes, I know about ELKS) :p. I hope the port gets accepted upstream (seems promising).

Also, needs far pointer support before I can use it. AFAIK, both "near" and "far" are reserved words according to gcc, so at least the parser understands them. Reenigne, have you given any thought as to how to access more than 64kB from a 286 segment in PM?

Lack of EXE support isn't a dealbreaker. If motivated, I could write a converter from (16-bit?) ELF to OMF.
 
Last edited:
What are the memory targets like? Does it have an option for "Tiny" with everything (code+data+stack) isolated to a single segment? Does it have proper options to omit functionality that isn't needed in such an environment and behave more like GCC does for AVR targets?

Side note, damn that site has accessibility woes galore... EM, use 'em! ...and am I the only one who snickers when he sees the words "Performance Optimized" in a heading talking about GCC? No? Just me?
 
cr1901 said:
Also, needs far pointer support before I can use it. AFAIK, both "near" and "far" are reserved words according to gcc, so at least the parser understands them.
Click to expand...

Ack - this is my highest priority for the toolchain. GCC has a "named address spaces" feature which takes care of the front-end stuff - the difficult bit is modifying the internal representation of an address and the parts of the compiler that need to interface with that representation (creating this internal representation and using it in instructions). Also making sure that the register allocator can deal with allocating the segment registers.

cr1901 said:
Reenigne, have you given any thought as to how to access more than 64kB from a 286 segment in PM?
Click to expand...

I haven't, and I confess that my knowledge of 286 protected mode is very limited. I guess that from a compiler point of view the difference would be in how huge pointers are renormalized.

cr1901 said:
Lack of EXE support isn't a dealbreaker. If motivated, I could write a converter from (16-bit?) ELF to OMF.
Click to expand...

I'm hoping I'll be able to add OMF (input and output) support to the GNU linker, but if such a converter is easy to write it would be useful to have in the meantime. The ELF format used by the toolchain is the same as for i386 for now, though I plan to add an extension to mark sections as 16-bit. I'll also need to extend the dwarf format to enable debugging, as the current one requires stack offsets to be multiples of 4.
 
deathshadow said:
What are the memory targets like? Does it have an option for "Tiny" with everything (code+data+stack) isolated to a single segment?
Click to expand...

Tiny model is the only one it has at the moment (I'm working on adding small, medium, compact, large and huge).

deathshadow said:
Does it have proper options to omit functionality that isn't needed in such an environment and behave more like GCC does for AVR targets?
Click to expand...

If you're used to avr-gcc it'll feel very familiar. I'm not sure which options you're referring to specifically but I've spent some time trying to get the minimum executable size as small as possible while still maintaining compliance with C standards. If you want to sacrifice that compliance you can get rid of the remaining dependencies on newlib and/or the argv/env-parsing code by modifying the linker script and/or startup code. I'll write something about how to do that if it would be useful.

deathshadow said:
Side note, damn that site has accessibility woes galore... EM, use 'em!
Click to expand...

I'm not involved with the website side of things (and don't know what EM means) but if you'd like to make some specific suggestions I'll pass them on to the web team. I've heard a number of my colleagues say that our website needs a serious revamp.

deathshadow said:
...and am I the only one who snickers when he sees the words "Performance Optimized" in a heading talking about GCC? No? Just me?
Click to expand...

Ah, the joys of corporate marketing...
 
Interesting. I'm about to re-surrect my old 8086 machine. I was looking around at the site, but I couldn't find which package contains the source?
 
Tor said:
Interesting. I'm about to re-surrect my old 8086 machine. I was looking around at the site, but I couldn't find which package contains the source?
Click to expand...

If you follow the download link to https://sourcery.mentor.com/GNUToolchain/release3298 you'll see a link to download the source packages that were used to build these binary toolchains. I've also got the changes in github (https://github.com/crtc-demos/build-ia16) but there are some differences between those and the ones used for the Mentor toolchains.
 
Thanks! Somehow I overlooked that Source TAR link - even this time. I had to scan over the list a few times. Got it now!
 
You must log in or register to reply here.
Back
Top