-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C compiler #1443
Comments
Hello @stevexyz, Thanks for your interest in ELKS. A few years back, the project switched from using bcc to ia16-elf-gcc to build the kernel and all the applications. One of the big reasons was the lack of support for 8086 segmented architecture linker and compiler options that are not present in bcc (or tcc). Unfortunately, gcc is way too large to be able to be included in ELKS runtime, so there isn't a way for ELKS to be self-compiled, but this has been viewed as a reasonable tradeoff, all things considered. I'm a fan of tcc, but the question is, given the limitations of segmented-mode 8086, what purpose would it serve, doing the work to get a self-hosted compiler running, when none available contain the features required to build the current kernel and all of the applications? Thank you! |
To me a C compiler is the base of a complete Linux (Unix) system... |
Hi @stevexyz -
Here's the the thing: ELKS is not a complete Linux or Unix system. Like the name says, it's intended for embedded systems. Embedded systems have limited resources and are rarely if ever selfcompiling. Of course our vintage PCs aren't embedded systems, but they have very limited resources. And - as @ghaerr also alluded to - it just doesn't make sense to have that ambition. Possibly fun, but not useful. Think about it - what we have today is a cross development environment with I have Venix running on one of my machines, a 286/12. It's a complete Unix system. It can compile itself if I had full sources, and I've done a lot of development on it. In the mid 80s and recently. It has
Yes, the compilers you're referring to RUN on the segmented architecture, but they support only parts of it – the small, maybe medium memory model, that's all. They have very limited options and support-tools (like
ELKS has come a long way, the last few years in particular. Your contributions would be very welcome. Even a native C-compiler. It's your time and your choice - and you'll get plenty support from the group regardless of whether the target tool/application is for the few or the many. --M |
Not for self-compiling but to make small debug program, it is nice to have a small compiler on ELKS. I now uses the basic to peek memory or read ports on the real PC from the background but sometimes wants to do a little more complicated. |
As already mentioned by @tyama501 it was not to be used to self compiling, even if it would have been a nice thing. And especially for starting, if there is something that is ready to be used, doesn't really matter if it is supporting just a limited memory model, but at least you can compile and run some programs on the system without always access another computer. For now I've other (unfortunately too many) projects going on and I'll stay on the window looking the ways ELKS will grow up, but in the future if it will still be not developed maybe I'll give it a try! In the meantime keep up the good work and happy hacking! |
I thought more deeply about exactly what is entailed when someone says "I'd like a C compiler" to run native on ELKS. As @tyama501 and @stevexyz mentioned, it would be nice to be able to at least just compile some programs from within ELKS. In order to do that, we'd need the following:
After all this, there are all the issues that @Mellvik brings up, which include problems associated with having no All in all - I have agree with @Mellvik that such a project is not really what people think of "having a C compiler" for ELKS. On another note, I was thinking about some C interpreters that might be able to provide fast execution of simple C programs, such as the C in 4 functions compiler. It is very cool with a small code size, and allows for calling out of various functions like Thank you! |
Hello @stevexyz, @ghaerr, @tyama501, I suspect that the Amsterdam Compiler Kit might be a good candidate for an ELKS-hosted C compiler, though I have not really got around to working on such a thing, and it probably needs a fair amount of effort. I believe ACK used to be the standard toolchain for Minix — including Minix/8086 — and besides, it is written to be able to run on small systems. Thank you! |
Seems to me that https://github.com/alexfru/SmallerC would be a very good start: seems easy enough and producing already 16 bit x86 code in various models, and with self compilation the ported compiler if it will produce the binary elk file. Maybe the author itself would adapt it if requested and specification of the binary file are given: if it is considered good we can try to ask. PS: @ghaerr I had a look at c in 4 functions, and while being an amazing exercise of minimization, seems really not easy to port to minimal memory systems for the way it has been designed |
just as comment, I tried to play with old "ACK for Minix" from https://web.archive.org/web/20070910201015/http://www.laurasia.com.au/ack/index.html#download on Minix i86 (not i386) qemu VM. Well, it ran out of memory :) trying to compile itself under existing 'cc' compiler there. |
Also, Portable C Compiler website seems to be down (and web archive does not have latest copy) so here I found slightly updated (2021) copy of code https://github.com/matijaskala/pcc There seems to be some code related by i86 generation by Alan Cox. Also, someone (Eric J. Korpela) looked at lcc-8086 but not get very far |
Hello @Randrianasulu and @tkchia, Thank you @Randrianasulu for the links to PCC, I'll take a look at it. Same for LCC-8086, that work looks extremely old but could be worthwhile. Of course, it would probably be a good idea to consider only using ANSI-capable (vs K&R) compilers, given where most C code is at today.
It's probably not needed that the compiler be able to compile itself under ELKS (or MINIX), so that's OK. I am not familiar to what degree ACK has been updated to any ANSI standards, and/or long/long log/float support etc. In the case of running on ELKS, we now have the issue that some portions of the C library may be using some @tkchia, you had mentioned you're possibly somewhat familiar with ACK, would that be a version similar to that used for MINIX as described above, or has there been more work done updating it, to your knowledge? Thank you! |
@ghaerr I found little something supposed to help with backtranslating ANSI C to older dialect: Also, may be Xenix (286) a.out variant can be used to get some idea how multiple segments were supported. https://ibcs-us.sourceforge.io/ |
Hello @ghaerr,
I have not yet done a comparison of the "laurasia" copy of ACK, and David Given's current ACK tree — I hope to do that soon. At the moment I am more familiar with Mr. Given's source tree (since I have been working on it a bit). Some impressions:
Thank you! |
slightly newer ackpack for minix (1.1.2) weirdly it comes as tar.tar. I only get file by downloading it via browser, not via wget. Same source should still be in Minix3 git, but a bit obscured because it was deleted years ago ... info from |
so, there was another compiler (c86 ?) but license prohibit commercial use. https://github.com/plusk01/8086-toolchain/tree/master/compiler |
https://web.archive.org/web/20150908032106/http://homepage.ntlworld.com/itimpi/compsrc.htm - so it was named c68, too ... |
ah, it was not complete compiler, just c to asm (nasm in this version) compiler. It needed cc (main driver), ld86 (linker), c preprocessor (it seems for Psion 3 they tried Decus cpp, available in X11R3 distribution - not tried to build it yet). So, some sources are newer in C68 (for QDOS - mk68k/ Sinchlair QL system) but part of older EPOC sources still live at older site: http://web.archive.org/web/20010414060410/http://www.itimpi.freeserve.co.uk/cpocdown.htm#SOURCE |
Seems has already a lot of options, among them the ones for 8086 specific:
|
so, I have something horribly broken, but it makes .o files! https://github.com/Randrianasulu/c86 make on linux/termux should give you some binaries. |
@Randrianasulu : it is almost certainly still not GPL-compatible though. |
seems to be very detailed document about c68 by author (I tried to send email to him, but no idea if old email address still works) |
https://qlforum.co.uk/viewtopic.php?t=2112 - may be he has new email, forwarded to it too |
just at the beginning of the C68 QL manual it says that it is Public Domain (even with capitals): INTRODUCTION |
Hello @stevexyz, I mentioned this because @Randrianasulu stated that the source files themselves seem to prohibit commercial use. And I see that Thank you! |
little aside (feel free to hide) but MAME got Psion 3 emulation inmore working state lately https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=121869&page=3 |
also faucc (286 & 386 codegen only?) https://gitlab.cs.fau.de/faumachine/faucc/-/commits/master EDIT: sadly it does not compile faumachine's new bios :( also, no FP. so, not very useful? |
Just a sidenote, but I think NASM does support ELKS a.out format. LCC port might use NASM too. Anyways, last time I looked into ELKS binary format it had some limits on DATA and CODE segment sizes similar to Minix 1. Is that still the same? What are the limits? Is it now possible to make something like large memory model executables in MS-DOS with GCC-iA16? |
I'm not sure about whether NASM supports a 16-bit MINIX a.out format or not. Does NASM support ELF output? If so, the binary could likely be converted to ELKS a.out format using our own The ELKS toolchain and kernel currently offer the ability to create and run small (64K code, 64K data) and medium (128K code, 64k data) model programs. Access to a larger data segment is possible through C |
I took a peek at NASM. It doesn't support Minix/ELKS directly. It supports as86 obj files though. They could be then linked with ld86 into elks binary, I think. My memory is a bit murky on this. Thanx for the info on memory model support ghaerr. Much appreciated. |
One option for a compiler that will definitely fit into 64K/64K would be the one I've been working on for Fuzix. It's mostly ANSI and it'll run in 48K (total). I've not tackled x86 yet but it's designed so it's very easy to get working but not pretty code out of it, and then to be able to optimize the backend once you have it working. Right now it's doing Z80, 8080, 8085 solidly, passable Z8 and Super8, close to doing 65C816 and 6809 usefully, and with other targets being worked on. In 48K it can build startrek.c as one file on an 8080 so on a 64/64K system it should be pretty much unlimited what you can build natively. It can also build itself, though not optimized yet (copt doesn't fit in 48K and I need to write a replacement). copt should fit in 64K/64K. |
Hello @ghaerr , Do you know this? I haven't tried yet. |
No @tyama501, I hadn't seen that repo. Looks very interesting. I'm not sure OpenWatcom would fit inside 128k and run on ELKS but it could be very interesting for its large data and other model support. I don't think it'd be too hard to get most of the ELKS C library ported to it, if wanted. I'll take a closer look and also see whether the build for OpenWatcom could be ported to macOS, as it appears Linux-only from the repo comments. Thank you! |
Hello @tyama501, I was able to build the entire OpenWatcom on macOS, then compile up the sample programs in owtarget16, and they run! :) The OpenWatcom build took forever, over 45 minutes, but had no errors. Only two small changes were required,
Running For the owtarget16 repo, I copied
Running As far as getting the compiler itself to run on ELKS, I suppose it is possible, as the OW build builds compilers for 16 & 32 bit systems and OS/2, but we'd probably have to make changes to the ELKS a.out loader in order to get the binaries loaded. As you may have seen, the owtarget16 project has as small conversion program Thank you! |
Hello @ghaerr , Good! Thank you:) |
Yes, this would allow compilation of C files in DOS-style large model (far code, far data). But there are still big problems: the ELKS C library would also need to be ported to large model which is somewhat straightforward but still the OW .obj and .lib files are incompatible so could take some effort; and the ELKS kernel loader and a.out header may have to be significantly extended in order to load programs with code segment > 128K or data segment > 64k. The owtarget16 demo files work because they include no header files and make system calls directly with OW ASM code included in the .c file. All this might be made easier for a particular project by copying needed ELKS C library header and C files into your project directory and compiling them all together. The system call portions would have to be added specifically for each system call, since none will be the same as DOS or OS/2. Then, a smallish program could be compiled with large data model for testing, and then the kernel extended for adding support for data < 64k. |
I see. Well, I will try it when I have time just for fun. Thanks:) |
Hi @ghaerr , I could run the OpenWatcom on Ubuntu 20.04.1 on QEMU. |
Hello @tyama501, Nice, I assume those are from the owtarget16 project? I have made some big progress this week starting with those tools. The latest is that I now have various ELKS utilities compiling using OpenWatcom C to produce .obj files, which are then converted using a modified version of the The .c files are compiled with OpenWatcom C using ELKS' C library headers. Finally, I haven't tested too many programs yet, but things are finally looking pretty good. All of this is currently in small model. The first big benefit would be possible compilation of Watcom C projects and running them on ELKS. This will be complicated by the fact that any DOS interrupt revectoring or direct hardware access won't work well. I am hoping the add large data model testing shortly. The other big benefit should be that we can, possibly finally, get a really great C compiler running on ELKS itself! This will take more work, but I am pretty impressed with the compiler and all its utilities. |
Wow, sounds great! Thank you! |
This is really amazing @ghaerr ! OpenWatcom with Elks rocks! |
Hello @toncho11, @tyama501 and @Vutshi: There's a new Using OpenWatcom C with ELKS Wiki page that describes how to build OpenWatcom and the ELKS C library with it, as well as using the Thank you! |
Hello @ghaerr , Thank you for the instructions. My $WATDIR is Am I missing something? |
This is fine, as WATCOM= is supposed to be the path to Watcom tool binaries.
This is incorrect, as WATDIR= is supposed to be the root directory of source files, see libc/wcenv.sh:
Then, in libc/watcom.inc, the headers are found using:
It is still required that a source distribution of OWC be available, as the headers are found in bld/hdr/dos/h/{stdarg.h etc}. |
I may not have the bld directory. EDIT |
Oh, geez. It seems that I should probably provide the correct (bld/hdr/dos/h) files in the libc/include/watcom directory, so that this will work without having to build the large OpenWatcom repo. I will look into doing that and make the changes to the INCLUDE= makefiles. In the meantime, here is the complete bld/hdr/dos/h directory, which you can copy over for the time being. |
I am a bit surprised the DOS header files are not copied over with an OpenWatcom installation. I am wondering whether the installer is assuming that upon installation on Linux/FreeBSD that the OWC Linux header files should be installed. Is there an option to specify that one desires to develop DOS applications from Linux? Perhaps the installer only knows about simple installations instead of cross-compiler/development scenarios.... ? |
Also, there is a possibility that the installed OWC compiler will be the version that compiles and produces 32-bit applications, rather than 16-bit applications. I am not yet familiar enough with OWC to know whether a separate compiler executable is used for these two different cases. I am running on macOS and only built the OWC repo from scratch. |
Hello @ghaerr , Thank you for attaching the zip file. Good reference. Probably we can use /bin/watcom/h |
Ok, we can consider what might need to change with our compiler scripts once we get your and other programmer's installations working. This likely means that those changes need to reside in libc/watcom just like libc/watcom/watcom.model does.
That is normal, there is no os2.lib since we don't want to incorrectly link with an OS/2 library. Instead, you will see that
Yes, that is the correct one. It is smaller because the math routines aren't included yet. Here is my build script for basic:
|
Maybe I'm wrong (I just tried to install elks on an original PC IBM XT), but seems to me that no C compiler is included inside elks (I've found the basic language interpreter though), while I think that's one of the basic thing of every Linux system.
If that's the case, I understand that a mammoth GCC might not really fit the project, but maybe the small and powerful tcc might be an option!
The text was updated successfully, but these errors were encountered: