So I guess the take-away I'm getting from all this is that having the best applications running on this kind of hardware would lend itself towards using LLVM, the best bang-for-the-buck of coding and contributing to an existing project (with regards to the intrinsic usefulness of the code) is probably SDCC (but in some ways this will treat the system like a glorified microcontroller), and the most practical and demonstratable self-supporting system would probably lead towards TCC, but LLVM would also satisfy this very slowly on a system with enough memory, giving at least the conceptual assurance but without an easy way to show it off besides "come back in a few weeks". ACK is kind of a wildcard that might fit somewhere in-between any of this depending on what exactly it is, but we already know it has some issues. It does presumably work though. Writing our own toolchain... eech. Might have been a neat idea back in the 80's. I suppose without having really dug into any of the options yet, my tentative next move would be to look at what makes an LLVM backend. Does such a backend include a linker? What would be a good C library to use with it? Gawd, this is why I try to stick to assembler, at least then every problem is my own fault. Except assembler bugs (I've hit them already with NASM running on 16 bit, rather bloated too). -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
