PDA

View Full Version : GCC for 8088



reenigne
March 31st, 2017, 11:47 PM
Here's something I've been working on lately: GCC for 8088-80286 (https://blogs.mentor.com/embedded/blog/2017/04/01/announcing-sourcery-codebench-lite-for-ia16/). 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.

Xacalite
April 1st, 2017, 12:04 AM
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.

nestor
April 1st, 2017, 03:24 AM
Very nice, just tested a Hello World and it generates a working .com file

eeguru
April 1st, 2017, 03:41 AM
The Doom source code seems to build just fine as well. Though admittedly it does run about .5 fps on my 5150.

Scali
April 1st, 2017, 04:40 AM
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.

reenigne
April 2nd, 2017, 04:42 AM
The Doom source code seems to build just fine as well. Though admittedly it does run about .5 fps on my 5150.

You had me fooled for a few minutes there!

eeguru
April 2nd, 2017, 05:20 AM
You had me fooled for a few minutes there!

Same back at you....

Scali
April 2nd, 2017, 05:22 AM
Same back at you....

He is actually for real though, although I don't think the date was a coincidence :)

cr1901
April 2nd, 2017, 06:45 AM
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 (https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00028.html)).

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.

deathshadow
April 3rd, 2017, 08:50 PM
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?

commodorejohn
April 3rd, 2017, 09:03 PM
...and am I the only one who snickers when he sees the words "Performance Optimized" in a heading talking about GCC?
No, sir, you're not :lol:

reenigne
April 4th, 2017, 12:12 AM
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.

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.


Reenigne, have you given any thought as to how to access more than 64kB from a 286 segment in PM?

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.


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

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.

reenigne
April 4th, 2017, 12:26 AM
What are the memory targets like? Does it have an option for "Tiny" with everything (code+data+stack) isolated to a single segment?

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


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?

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.


Side note, damn that site has accessibility woes galore... EM, use 'em!

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.


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

Ah, the joys of corporate marketing...

Tor
April 5th, 2017, 03:28 AM
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?

reenigne
April 5th, 2017, 03:46 AM
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?

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.

Tor
April 5th, 2017, 05:02 AM
Thanks! Somehow I overlooked that Source TAR link - even this time. I had to scan over the list a few times. Got it now!