Question about ELKS ABI and a possible PyDOS port

[bencz]

Hi,

I am the maintainer of PyDOS: https://github.com/bencz/PyDOS

PyDOS compiles a subset of Python into native 8086 programs. The compiler is written in C++ and built with OpenWatcom.

I would like to add ELKS as a target.

The DOS-specific parts should not be a major issue. PyDOS has a runtime layer, so I can implement an ELKS-specific version using ELKS libc and system APIs while keeping the same interface for generated programs.

My main questions are about the ABI and build process:

1. Is there documentation for the ELKS userspace ABI?
2. Which calling convention should OpenWatcom programs use?
3. Which memory models are supported or recommended?
4. Should new OpenWatcom applications use the OS/2 executable format?
5. Are there any important restrictions involving far pointers, code segments or data segments?
6. Is C++ supported if the program does not use STL, exceptions or RTTI?
7. Is there an existing OpenWatcom project that would be a good reference?

My first goal would be to compile a simple program like:

print("Hello from ELKS!")

The compiler would initially run on another system and generate an ELKS executable. Only the generated program and its runtime would run inside ELKS.

Any guidance on the ABI, linker configuration or recommended approach would be very helpful.

Thanks.

[ghaerr]

Hello @bencz,

Thanks for your interest in ELKS.

A quick look at your project shows 16-bit support requires far pointers, and thus likely large model OpenWatcom. You could also possibly build programs in the much-easier-to-write MINIX a.out executable format created through the standard ELKS ia16-elf-gcc toolchain, but that would require always outputting char __far *p for all pointer declarations, and malloc would still be limited to 16 bits. In OWC large model malloc still allocates from the near heap, so you'll need some trickiness to handle out-of-process memory allocation, since that will require fmemalloc (see below). You've got some work cut out for you to make sure your programs don't run out of memory.

Is there documentation for the ELKS userspace ABI?

It's pretty much POSIX/Linux. See the C library headers in libc/include/.

Which calling convention should OpenWatcom programs use?

You can use the register calling convention, the ELKS OWC C library is compiled using quite a few options, see libc/watcom.inc for more details.

Which memory models are supported or recommended?

We support small, large, compact and medium for OWC, small and medium for GCC.

Should new OpenWatcom applications use the OS/2 executable format?

You will have to, as it doesn't support a.out format output.

Are there any important restrictions involving far pointers, code segments or data segments?

Not so much, but as mentioned above, memory allocation is tricky. We ported the C86 compiler to ELKS, its in the 8086-toolchain project. See the file compiler/mem.c for details on tricky malloc replacement. I recommend designs that don't require segment arithmetic in pointers (which then limits allocations to 64K each allocation).

Is C++ supported if the program does not use STL, exceptions or RTTI?

No C++ support. Not all OpenWatcom C compiler helper calls or system calls are supported either, but most are. See libc/watcom/ for details.

Is there an existing OpenWatcom project that would be a good reference?

Yes, the C86 compiler and other tools, see above. The 8086-toolchain/compiler/Makefile.elks would be a good choice, look through the other tools to see other OWC builds.

Thank you!

[bencz]

Thank you for the detailed answer!

The plan is to keep the PyDOS compiler running on the host and only generate the executable and runtime for ELKS, so the lack of C++ support inside ELKS should not be a problem.

I will start by looking at the C86 port, especially compiler/mem.c, compiler/Makefile.elks, libc/watcom.inc and libc/watcom/.

The memory allocation details are very useful. PyDOS already has a platform-specific runtime layer, so I can implement an ELKS backend and handle far memory allocation there without changing the compiler frontend or the interface used by generated programs.

I will experiment with OpenWatcom large model and the OS/2 executable format first.

Thanks again for pointing me in the right direction!

[ghaerr]

Also, you'll have to build the ELKS C library for OWC as well: that can be done using "make owlibc" from ELKS top level, after getting OWC installed using libc/wcenv.sh.

[toncho11]

https://github.com/ghaerr/elks/wiki/Using-OpenWatcom-C-with-ELKS
Wow very nice project :)