You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Over at ELKS, we have made some progress using OpenWatcom to compile the ELKS C library and user applications using the large memory model, and then adapted the kernel to load the 16-bit OS/2 v1.x NE executable format, allowing large model programs to run, providing they'll fit in ~640k.
There has been some discussion on finding a versatile C compiler that could be made to be hosted directly on ELKS, but it was recently pointed out that a "standard" OpenWatcom installation on DOS requires a 386+ processor and 8MB RAM (I'm guessing and DPMI as well).
The question is: could wcc (the 16-bit compiler, not the wcc386 32-bit compiler) be built to run on ELKS, using large model and the multisegment OS/2 NE executable format? I am looking for someone with enough internals knowledge to gauge with more accuracy whether this might be possible. Actually, wcc, wasm and wlink would need to be able to be ported to large model OS/2 format in order for this to work. The ELKS C library is already compiled and running well with OpenWatcom, so that's not an issue. Access via far memory pointers outside the process address space using external (but non-DPMI) memory functions is also possible.
Hi,
In the past 16-bit versions of main OW tools as C and C++ Compilers, librarian and linker were abandoned.
I think it was in WATCOM era before OpenWatcom.
That it is not possible to build 16-bit versions of these tools now because source code is now only buildable for 32/64-bit hosts.
By example wmake and wasm can be still build for 16-bit but main tool not.
OW is cross compiler that you can use any OW supported platform to cross-compile for 16-bit ELKS.
OW has remote link (used for debugger) that you can adopt it for ELKS that you could be able copy file from OW host to ELKS target directly.
It is possible to use it also for remote debugging of cause with ELKS debug support if any.
Thanks. I'm aware that WCC isn't being built for 16-bit with the current repo, but how big is it? I see rel/binw/wcc.exe is 964k, does that contain a DPMI extender? Obviously 964k executable size doesn't look good for running in an 640k system.
Are there any configuration options that might allow the program code and data fit within say, 640k? If the program code is small enough and WCC doesn't require > 64K heap objects, then it might be able to be ported.
It is nice to hear WASM still fits. Of course, WLINK could be another story, with more modern linkers using lots of memory during linking process, quite a bit more than the size of the executable being produced.
DOS version is now bind with Causeway Extender that size is little bit bigger then if it is without it.
The main issue is that code for 16-bit host requires more specific handling of memory because you can use maximum 64 kB memory block. Next issue is with size of int that we should change it to long then problem on 64-bit NIX system with 64-bit size versus 32-bit size on Windows. We have by example code for Windows which is source for 16/32/64-bit host but it is applications only. All command line tools for 16-bit Windows are 32-bit DOS versions. Wlink is another story it is not big code as compiler but there is problem with output virtual space which must be 32-bit and 64-bit and it is hard to realize on 16-bit pointers that it requires virtual memory manager for at minimum 32-bit but working on 16/32/64-bit host. It requires some memory paging in virtual space and swapping to disk for 16-bit. Therefore it was abandoned in the past because maintenance of such code is hard. WASM and WMAKE are small application which don't need a lot of memory that no problem compile and link for 16-bit.
Thanks for the technical explanations. Yes, I can see that sizeof int brings out problems, which of course would be even worse on ELKS if compiler assumes sizeof int >= 32. And I was worried about wlink virtual space as well.
So, looks like OpenWatcom won't be running directly on ELKS. But it's still a great compiler with fantastic support for all things real mode. Adding OpenWatcom support to ELKS has allowed porting/writing much larger multisegment programs for it, something that wasn't possible with the ia16-elf-gcc/ld.gold compiler/linker combination, which can only support 128k code and 64k data max.
OW code generator supports all memory models small, medium, compact, large and huge for 16-bit architecture and partially for 32-bit segmented architecture. I think only toolchain designed to be specialized only for 16-bit architecture could works on 16-bit OS. OW abandoned this possibility very long time ago that now it is not possible. OW can do efficient cross-compilation only.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello @jmalak and others,
Over at ELKS, we have made some progress using OpenWatcom to compile the ELKS C library and user applications using the large memory model, and then adapted the kernel to load the 16-bit OS/2 v1.x NE executable format, allowing large model programs to run, providing they'll fit in ~640k.
There has been some discussion on finding a versatile C compiler that could be made to be hosted directly on ELKS, but it was recently pointed out that a "standard" OpenWatcom installation on DOS requires a 386+ processor and 8MB RAM (I'm guessing and DPMI as well).
The question is: could
wcc
(the 16-bit compiler, not thewcc386
32-bit compiler) be built to run on ELKS, using large model and the multisegment OS/2 NE executable format? I am looking for someone with enough internals knowledge to gauge with more accuracy whether this might be possible. Actually,wcc
,wasm
andwlink
would need to be able to be ported to large model OS/2 format in order for this to work. The ELKS C library is already compiled and running well with OpenWatcom, so that's not an issue. Access via far memory pointers outside the process address space using external (but non-DPMI) memory functions is also possible.Thank you!
Beta Was this translation helpful? Give feedback.
All reactions