On 24/03/15 12:30, Jody Bruchon wrote: [...] > ELKS is tightly tied to BCC for now, so some future development will probably require changes to it. A big difference between BCC and GCC is that BCC includes a C library and headers whereas GCC is only a compiler and requires a C library to be built separately. That means I can't fix issues with the C library without bringing the whole thing along. While I wouldn't suggest it for *new* development, because the compiler technology is old and clunky and rather unmaintainable, but the ACK is an ANSI C compiler suite which supports 8086 and comes with a full libc --- this is what Minix used. It's even theoretically possible to run it self-hosted on an ELKS-style machine, although it'd take work to recover that ability these days. The 8086 coded generate isn't too bad. (Minix was developed with it, after all.) The downside is that it lives in its own little universe and doesn't interoperate with anything; you have to use the ACK object file format and the ACK linker etc. I believe it already supports Minix 16/16 segmented binaries. The effort needed to persuade the ACK to produce ELKS executables is probably quite small --- it already has partial support for ix86 and m68k Linux; how different is the ELKS system call model? Making it build the kernel is probably harder due to different dev86 and ACK linker magic. This would only be worthwhile as a stopgap until 8086 gcc or pcc is available, and it would need some careful evaluation of the code quality, but it might be worth looking into. The fairly elderly website is at: http://tack.sourceforge.net/ -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "Sufficiently advanced incompetence is indistinguishable from │ malice." -- Vernon Schryver
Attachment:
signature.asc
Description: OpenPGP digital signature
