> type test.c
#include <stdio.h>

int main() {
        printf("Hello world!\n");
        return 0;
}    

> readelf -h test.o
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          356 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         10
  Section header string table index: 7    

it doesn't appear to be an April Fools joke.

Supposedly, it has up-to-date C language support, so us 16-bit aficionados can finally move up to C11 and leave OpenWatcom behind.

It might only be able to produce COM binaries, so I've heard, but I haven't read too much into it.

Seriously? What did you miss from OW19 that you direly needed? C11 wasn't that useful for DOS, was it? Or do you just mean missing C99 features (not even supported via "-za99")?

Far pointers currently do not work, so accessing memory outside the program's 64kB segment requires the use of assembly (either inline or a separate file that is assembled and then linked into the program).

IA16 GCC does have support for floating-point code, but it does not make use of an 80x87 co-processor. The library is currently quite large so non-trivial programs making use of floating-point types
may fail to link.

Hello! I'm the one responsible for unleashing this monstrosity upon the world. Yes, it does currently have some fairly severe limitations but hopefully it will be useful to somebody. I'm also working on removing those limitations (I was hoping to at least add far pointers and memory models other than tiny before release,

but when one of my colleagues suggested an April 1st release last month I thought that was too good of an idea to pass up.)

Yes, ia16-elf-gcc does currently use elf32 as the intermediate format. This is not *too* bad of a hack since it is theoretically possible to link 16-bit code to 32-bit code. Unfortunately the corresponding dwarf standard for debug information doesn't allow stack offsets that are not 4-byte aligned, so there's no debugger support yet. Using elf rather than OMF as the default object format is important to allow things like link time optimization to work, but I'm hoping to add OMF support (reading and writing) to the linker at some point (I did find a patch to add enough OMF support to binutils for objdump to work). Currently the linker outputs a .com file, but .exe format output is coming.

-masm=intel is a feature of the i386 backend but I'll investigate adding it to ia16 (looks like it's not too much code). I'll take a look at adding gettimeofday() to the BSP as well.

rugxulo, if you point me to your Befunge-93 source I'll see if I can figure out what's going wrong at -O and -O2 (assuming it's not just a 64kB limit problem). Likewise with -march=i80186 and -march=i80286 (I'm afraid I haven't done much in the way of testing with those CPUs - I've been concentrating on 8088/8086).

Thanks for the feedback, and please let me know if you have any questions or feature requests!

Anyways, I don't claim this is truly useful or good code, obviously, but it's fairly small and something I've written for fun (and p.d./FOSS): BEFI_4S.ZIP (see newb93c.txt and beftest.txt)

ia16-elf-gcc -s -Os -DSRAND=nop() -DRAND4=5 -DNDEBUG -DCFG -DOUTINT outint.c befstack.c befunge.c -o befunge.com

It does (mostly) work, so that's already impressive. It's a daunting task, so I don't blame you for limitations.

FYI, not sure if it will help, but DJ Delorie had some 16-bit OMF tools here (e.g. linker, "GNUish").

"objdump -d -M intel,i8086" still works here, IIRC.

My only suggestion, and this is only if you're really adventurous or bored, would be to build a native DJGPP (DOS) cross-compiler (instead of only Linux or Windows). Maybe these will help?

... gives me a .COM of 19150 bytes. Running "befunge guessnew.bef" (or faster "befunge guessnew.bef 1000") under DOSBox shows the correct output. It also passes the B93 subset of the Mycology test suite ("3-clause BSD"), which is the quasi-official test used by most good implementations.

rugxulo wrote:

DJ Delorie had some 16-bit OMF tools here (e.g. linker, "GNUish").

That might be useful as an OMF reference. What I'd really like to do is to add OMF support to gas and ld so you can link together elf+omf and output elf, omf, com or exe.

OpenWatcom has the TIS 1.1 OMF reference here, if you didn't already know.

Thanks - I'll take a look at this. I got the -Os version running correctly in DOSBox, but when I run it under my simulator it just outputs "103 " over and over again, so it seems I've got some simulator bugs to fix first!

I found a minor library bug by trying to run under QEMU. (BTW, DOSBox is better than nothing but far from perfect. It actually hides this bug, though.) It seems to omit printing the all-too-crucial '\r', so the output on the screen is a bit disjointed.

I hate to even mention it, surely you have your own methods of testing, but a VirtualBox tutorial (and even premade FreeDOS 1.2 VM images) are available. To me, that greatly simplifies testing (although I also native boot). Of course, every time I tell someone this, they usually just ignore me. Feel free to do the same.

Yeah, DOSBox does have some rough edges but its debugger and the ability to access the host filesystem directly are really useful.

I was using dosemu for a while for the compiler test suite, but booting DOS for each of the ~200000 testcases was taking a long time

Status update: lately I've been working on switching the calling convention to fastcall. I know I said I would do far pointers next but I hadn't touched that for a while and wanted to get back into the codebase by doing something I thought would be relatively easy and get a decent speed boost.

Unfortunately I was a bit overoptimistic - trying to put parameters in AX, BX, CX and DX made the compiler fail to build libstdc++ (I know why, but I don't know how to fix it yet)

so for now I'm just using AX, CX and DX and I'm still getting 1026 new errors in the testsuite. It gives a 4.5% improvement in speed and a 2.6% improvement in size, which is okay but not as much as I had been hoping for.

The main problem I was trying to solve there is that the floating point library is just so big. I tried an alternate library (GCC has two different ones to choose between) but that one turned out to be even bigger, so I think I'll have to hand-write some soft-FP code in assembly to fix that problem (that's a way off, it's not a high priority).

GCC 7 should be released any day now - when it is, I'll switch over to using that which should hopefully bring some more improvements.